[mrb]

I am half serious, but how about making HTML served in TXT records a standard trick for serving small web pages very quickly? There are way fewer network round trips:

  1. DNS query for TXT record for example.com
  2. DNS reply with HTML content

Compared with the traditional 7 steps:

  1. DNS query for A record for example.com
  2. DNS reply with x.x.x.x
  3. TCP SYN to port 80
  4. TCP SYN/ACK
  5. TCP ACK
  6. HTTP GET
  7. HTTP reply with HTML content

It would also make the content super-distributed, super-reliable, as DNS servers cache it worldwide (and for free so it would reduce hosting costs :D). Also TXT records can contain more than 255 bytes as long as they are split on multiple strings of 255 bytes in a DNS reply.

Again, I am only half serious, but this is an interesting thought experiment...

Edit: oddtarball: DNSSEC would solve spoofing. And updates should take no longer than the DNS TTL to propagate: the TTL is under your control; you could set it to 60 seconds if you wanted. It is a common, false misconception that many DNS resolvers ignore the TTL. Some large web provider (was it Amazon? I forget) ran an experiment and demonstrated that across tens or hundreds of thousands of clients wordlwide, 99% of them saw DNS updates propagated within X seconds if the TTL was set to X seconds. Only <1% of DNS resolvers were ignoring it.

[BuildTheRobots]

For another fantastic abuse of DNS, the Iodine* project uses DNS to tunnel IP which is just obscene.

http://code.kryo.se/iodine/

(Why? Lots of captive portal wifi hotspots (think hotel/train etc) seem to allow DNS resolutions before stopping your other traffic.)

* DNS uses port 53 which is the same as the atomic number for Iodine ;)

[galvan]

Ah, iodine. I've used it in airports, hotels, cafes - it's great. The only drawback is that it's slower than dialup and latency is off the charts. But when you're stuck on a cruise ship and internet access is $8 a minute, being able to ssh somewhere and browse the web and check your mail very slowly through links is worth it.

[batbomb]

I usually just spoof mac addresses of people who already paid in most of those cases, the caveat usually being somebody had to pay.

[Steuard]

I hope you're not still talking cruise ships here! Those folks are often paying high prices by the minute or by the megabyte for access: you'd be pretty literally stealing from your neighbors in that situation. (The moral issue for pay-by-the-day systems is one step further removed, but I think it's still real.)

[jrockway]

802.1x covers access control to networks. MAC addresses are not for access control.

Not that a court would agree with my logic, of course.

[WiseWeasel]

Yeah, you might have a tough time explaining to the judge that Media Access Control addresses are not for access control.

[annnnd]

Doesn't really matter - it might (!) be legal, but it is immoral (if they really are paying by MB).

[brianpgordon]

I was staying at a Hilton (Omaha, NE) last night and their captive portal scared me off by putting the MAC address, IP address, and user agent in the query string, plus network stuff like the VLAN id and the MAC address of some piece of network gear that's servicing you. It seemed like they had a pretty complex system to deter abuse.

Of course, I just tethered my phone and got way better service than their crappy $10/day wifi.

[UVB-76]

If those people have a download limit that's rather unscrupulous.

[xymostech]

Woah, awesome. I've used the http://dnstunnel.de/ tunneling scripts before, and they're a bit of a pain to setup (mostly because of the perl library requirements).

[sajal83]

I remember using these scripts years ago when wifi hotspots used to charge obscene amounts of money...

[milkshakes]

malware authors have been using this technique for some time: http://www.cs.berkeley.edu/~mobin/publications/2013/DNS_USEN...

[click170]

How to start protecting yourself against this.

http://www.neustar.biz/blog/how-to-identify-prevent-dns-tunn...

[TeMPOraL]

> I am half serious

Good. Still, it needs to be pointed out. This idea is an awesome hack to show how can you piggyback on existing infrastructure to make it work as something it was not intended to.

But it absolutely, terribly sucks at anything practical. Actually, it's a non-solution. Here's why.

> There are way fewer network round trips:

> 1. DNS query for TXT record for example.com

> 2. DNS reply with HTML content

Let me show an exactly equivalent alternative implementation of the above concept.

    1. HTTP GET x.x.x.x/example
    2. HTTP reply with HTML content

Both of them require you to do exactly the same steps - that is, connect to a hardcoded port of a server at a hardcoded IP address, request a user-defined resource, receive and display reply. DNS is not magic, IP addresses of DNS servers are hardcoded in your network configuration and/or in your router configuration and/or in your ISP configuration.

I know you're half-serious with this idea, but I'm going to play along. So to continue with the interesting thought experiment... if people were to start actually using DNS records to smuggle websites, they'd quickly overwhelm the capabilities of the DNS network, so the reliability and free hosting would quicky go out of window, along with all hope of ever having anything even resembling consistency in the Internet.

So yeah; a nice hack, but kids, don't try to deploy it at scale ;).

[paulfurtado]

> Both of them require you to do exactly the same steps - that is, connect to a hardcoded port of a server at a hardcoded IP address, request a user-defined resource, receive and display reply. DNS is not magic, IP addresses of DNS servers are hardcoded in your network configuration and/or in your router configuration and/or in your ISP configuration.

The steps are not exactly the same. Any sensible ISP give you at least two redundant DNS servers with your DHCP response and most public DNS providers also give you multiple redundant servers. When you do a DNS lookup, your OS or browser handles failover between the DNS servers automatically, client side. When accessed by IP address, as you've demonstrated, HTTP offers no client-side failover mechanism built into web browsers to fall back to a different IP.

It's additionally important to note that architecturally, DNS servers are far more scaleable than most HTTP servers. They don't run anywhere near as much code per request and don't require the overhead of TCP or HTTP.

Note that I'm also not encouraging using DNS instead of HTTP for serving websites, I'm just pointing out that DNS is a more reliable technology and has client-side failover mechanisms so the pros which mrb listed are very real.

[javajosh]

I don't think you understand his hack - but then, that's understandable, because it wouldn't work anyway without modifying the browser. You'd need a special client (or a proxy) to feed the content of DNS TXT record directly to the browser, because you're not using HTTP (or even TCP) anymore.

Exercise for the reader (the proxy soln): write a server called txtdns.com that returns the content of TXT records as HTML. The path would look like http://txtdns.com/example.com - and the key is that the server is only accessing DNS, even though your client is using TCP and HTTP.

[tripzilch]

would make more sense to have it be a local proxy, IMO?

(and probably be easier to boot, given the right scripting language/libraries that should be doable in 10-30 lines of code or so)

[zackb]

I think his point is that DNS doesn't require the TCP or HTTP overhead. There are more steps and layers involved with an HTTP GET and reply than with DNS resolution.

[peterwwillis]

It requires TCP overhead if the dns packet is bigger than 512 bytes. You could abuse the DNS protocol to carry HTTP-esque metadata but it would be a small victory over standard HTTP. Reusing an existing TCP connection is more efficient.

[EA597C6C]

TCP is not required for larger messages if EDNS(0) is available--which it probably is--and the network allows; which conservatively, it probably does at least till the 1280~1450 byte mark.

http://tools.ietf.org/html/rfc6891

[cgjaro]

Your suggestion is not equivalent. It is not realistic to ask the user to memorize the x.x.x.x IP address. The point of mrb's solution is that it fully takes care of problem of "typing <domainname> in the address bar and getting the content as quickly as possible without having to memorize IP addresses".

[venaoy]

You are incorrect. An HTTP GET still requires a 3-way TCP handshake, so your suggestion requires 5 steps not 2:

  1. TCP SYN to port 80
  2. TCP SYN/ACK
  3. TCP ACK
  4. HTTP GET
  5. HTTP reply with HTML content

[dschatz]

FYI both a TCP SYN and SYN/ACK can carry a payload (which could be the GET and RESPONSE)

[caf]

The SYN packet can contain data, but the spec requires that it not be passed down to the application until the three-way handshake is complete (so a SYN-with-data from a spoofed source address won't elicit a response).

The TCP Fast Open proposal gets around this by using a cookie, so that the first connection requires a normal three-way-handshake, but subsequent connections between the same client and host can use an expedited handshake that eliminates a round trip.

[cgjaro]

Yeah but in practice no browser does this. There is no system call on Linux or Windows to push data as part of the SYN packet. You would have to craft TCP/IP packets and their headers with a raw socket...

[caf]

Linux does support this for "TCP Fast Open" - the system call used is sendto() or sendmsg() with the MSG_FASTOPEN flag set, in place of the usual connect().

[opejn]

Even if you did do this, any server implementing SYN cookies would ignore the payload and require you to retransmit anyway.

[wiml]

IIRC, both the Linux and BSD socket implementations let you do this with a combination of a few sockopts.

[dsl]

Malware has been putting updates and command and control instructions inside DNS records for a while now, so they get the benefits you mention as well as continued availability even when the original authoritative servers are taken down.

[oddtarball]

Meh, interesting thought, but a few things come to mind:

- It could take multiple days to update the website for the entire world

- It would be very easy to spoof the entire site

- It would probably slow down the rest of the queries the DNS server would be responding to at the time.

Also, updating DNS can be a pain for sites that aren't managing their own records.

[jameshart]

Used to work in the DNS business. "It will take up to 24 hours to propagate" is a way to manage expectations and prevent support calls from coming in within the first 24 hours after a DNS change, not a reflection of actual DNS propagation times.

[aroch]

I don't know how things work now, but at least a few years ago there were plenty of DNS server that would take basically the full 48hours to update, regardless of TTL.

[ceejayoz]

I think the rise of no-fixed-IP load balancers like Amazon ELB has dramatically reduced that.

[rev_bird]

Aren't the IPs of the load balancers more or less fixed, though?

[syncsynchalt]

Using a PaaS like Elastic Beanstalk will mean a new load balancer on each publish, and those can happen multiple times per hour in a busy day.

[vacri]

I'm not a netadmin, so don't know the innards of how it all works, but one day I watched a domain of ours pointing to an amazon load-balancer spread across multiple AZs - the IP address would change in DNS every so often, flipping between the AZs, presumably.

[danellis]

I hate the term "DNS propagation". It confuses people, and makes them think things that aren't true, like a new domain isn't usable until it "propagates" through the Internet.

[nucleardog]

Again, managing expectations.

We tell clients that we've launched their site, but that the DNS changes might take up to 48 hours to propagate.

Realistically, from our office and to most of the world it's probably live within 5 minutes. One of our local ISPs happens to be one of those irritating ones that just ignores your TTL and caches records for days at a time.

Sometimes one of their servers will end up with the new record and one with the old. That combined with peoples' home routers caching records (again, sometimes ignoring TTLs) can lead to fun situations where the site might load fine for a couple hours (hit the good ISP server, local router cached) then the old site for a couple of hours (hit the bad server, local router cached...).

I used to try and explain it to people but after having enough people freak out about how their site switched back, it's not live yet, etc, etc... I just tell them it's going to take 48 hours. If it's visible earlier it's a pleasant surprise, and if it takes two days I don't get any panicked phone calls.

[marcosdumay]

Use the Kitchen Sink[1] record type. It's more appropriated than TXT.

[1] https://tools.ietf.org/html/draft-ietf-dnsind-kitchen-sink-0...

[0x0]

I saw "ASN.1" in the draft and immediately thought "over-engineered".

[jbert]

When bytes count (and they often don't, but in this case they probably do), what would be your preferred system? And what do you see as your favoured approach's main advantage(s) over ASN.1/BER?

[dbrower]

ASN.1/BER is a pain in the ass. I'd rather gzip json. Or poke chopsticks in my eyes.

(creds: http://tools.ietf.org/html/rfc1697)

[0x0]

^ What that guy said. ASN.1 parsers are super complicated and have been the cause of remote exploits more than once.

[sitkack]

I'd say that is by design.

[lionet]

MIBs are not ASN.1, actually.

[ryan-c]

Not even an April fools' RFC. Wow.

[michaelmior]

If you want to access this in a web browser, you still need some server which speaks HTTP and makes the DNS request and forwards the result to the browser. So you're really not saving much there. In fact, you'll have higher latency since you now need HTTP plus an extra DNS request. Unless of course browsers support dns://...

[aidenn0]

But DNS is cached; to some degree you're getting a free CDN when you do this.

[michaelmior]

Not really. Unless you have direct browser support for these DNS pages, you still need the proxy server close to your client to get the benefits of a CDN. Besides, the content is static, you could just dump that on a web server anyway.

[jingo]

"HTML served in TXT records a standard trick for serving small web pages"

I already did this many years ago. It works well.

I also do not use DNSSEC (unencrypted DNS packets) opting instead for dnscurve (encrypted DNS packets).

What is still missing from the DNS world is a server that can handle pipelined (TCP) DNS queries (multiple lookups in the same request). I think the spec allows for it but no one ever implemented it as far as I know.

In your thought experiment, that would be "HTTP/1.1 pipelining".

I use HTTP pipelining everyday via command line utlities and where "web browsing" is concerned I find it hard to live without.

[Joyfield]

I wrote something like that but distributing torrents. Wrote it AGES ago : http://netrogenic.com/dnstorrent/

[jacquesm]

The phrase 'knows just enough to be dangerous' comes to mind :)

[tantalor]

isinterneton.com implemented something like this circa 2011 but it looks dead now.

You can still see how it worked: http://whois.domaintools.com/isinterneton.com

It defined a few nameservers,

  IS-INTERNET-ON.TITLE.ISINTERNETON.COM 
  YES.BODY.ISINTERNETON.COM

The server reads these values and constructs a page like,

  <title>Is Internet On</title>
  <body>Yes</body>

[vdm]

Van Jacobsen's NDN (née CCNX) does this by replacing the entire HTTP to IP stack with a hierarchical key-value protocol using only two packet types: Interest (GET) and Data (PUT). It can overlay UDP or any layer 2 directly, and tunnel IP. http://named-data.net/

[callesgg]

A UDP dns response will be truncated if it is longer than 512 bytes.

If you want more stuff you have to use TCP and that is not very preferable.

[venaoy]

False. IP fragmentation allows the size of a single UDP DNS response to be up to 65535 bytes, regardless of the network MTU.

[peterwwillis]

The great majority of networks out in the world discard UDP DNS packets bigger than 512 bytes. Firewall admins do it, DNS admins do it, application proxies do it, birds do it, bees do it, even educated fleas do it....

As far as the 65535 limit, from RFC 2671:

  4.5.5. Due to transaction overhead, it is unwise to advertise an
       architectural limit as a maximum UDP payload size.  Just because
       your stack can reassemble 64KB datagrams, don't assume that you
       want to spend more than about 4KB of state memory per ongoing
       transaction.

[callesgg]

It does not have to to with link, udp or ip it is a limitation of the dns spec.

Here is a extention that "fixes" it: https://tools.ietf.org/html/draft-ietf-dnsind-udp-size-02 I have not seen that spec extention implemented in the wild. I just found the extention so I have on the other side not looked for it.

[EA597C6C]

EDNS(0) allows for larger responses and is both commonly implemented and widely deployed.

http://tools.ietf.org/html/rfc6891

[larrys]

"Again, I am only half serious" (said two times...)

Why say that at all? Is it a way to fend off ridicule? Or does this show a lack of confidence in the idea and what you are saying?

Reminds me of comments that start "Am I the only one who thinks that..."

I've gotten out of the habit of apologizing for things that I say or prefacing them with phrases such as that. The reason is that I found that it was a lazy way to not give as much thought to what I was saying and whether I needed to vet my thoughts more.

[existencebox]

As someone who prefaces comments with similar things, I don't think it's unreasonable. Sometimes we know ideas are a bit of a cludge (Thinking back to the first time I did an IP over DNS tunnel) but it's still fun and interesting; but that doesn't stop some people jumping down your throat if they think you're suggesting it in earnest. Twice, maybe much? But the sentiment itself, I can see where it's coming from.

[larrys]

Wanted to add that what you said above such as "this maybe a bit of a cludge" seems better than "only half serious" as a preface because you are acknowledging the possible problem in the idea procactively if you want to call it that.

[larrys]

"but that doesn't stop some people jumping down your throat if they think you're suggesting it in earnest. "

Or downvoting as they have done with my comment.

[tripzilch]

> Or downvoting as they have done with my comment.

That's because nobody came to this thread because they wanted to read your meta-discussion.

[angelortega]

Because two half serious make a full serious.