[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.