10 ms·
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
by mrb 12y ago
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.
- marcosdumay 12y agoUse the Kitchen Sink[1] record type. It's more appropriated than TXT. [1] https://tools.ietf.org/html/draft-ietf-dnsind-kitchen-sink-02 https://tools.ietf.org/html/draft-ietf-dnsind-kitchen-sink-0...
- 0x0 12y agoI saw "ASN.1" in the draft and immediately thought "over-engineered".
- jbert 12y agoWhen 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 12y agoASN.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 http://tools.ietf.org/html/rfc1697)
- ryan-c 12y agoNot even an April fools' RFC. Wow.
- oddtarball 12y agoMeh, 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 12y agoUsed 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 12y agoI 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 12y agoI think the rise of no-fixed-IP load balancers like Amazon ELB has dramatically reduced that.
- rev_bird 12y agoAren't the IPs of the load balancers more or less fixed, though?
- syncsynchalt 12y agoUsing 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 12y ago
- dsl 12y agoMalware 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.
- michaelmior 12y agoIf 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 12y agoBut DNS is cached; to some degree you're getting a free CDN when you do this.
- michaelmior 12y agoNot 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.
- larrys 12y ago"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 12y agoAs 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 12y agoWanted 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 12y ago"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 12y ago> 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 12y ago
- BuildTheRobots 12y agoFor another fantastic abuse of DNS, the Iodine* project uses DNS to tunnel IP which is just obscene. http://code.kryo.se/iodine/ 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 12y agoAh, 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 12y agoI usually just spoof mac addresses of people who already paid in most of those cases, the caveat usually being somebody had to pay.
- UVB-76 12y agoIf those people have a download limit that's rather unscrupulous.
- Steuard 12y agoI 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 12y ago802.1x covers access control to networks. MAC addresses are not for access control. Not that a court would agree with my logic, of course.
- Joyfield 12y agoI wrote something like that but distributing torrents. Wrote it AGES ago : http://netrogenic.com/dnstorrent/ http://netrogenic.com/dnstorrent/
- jacquesm 12y agoThe phrase 'knows just enough to be dangerous' comes to mind :)
- TeMPOraL 12y ago> 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 ;).
- zackb 12y agoI 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 12y agoIt 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 12y agoTCP 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 http://tools.ietf.org/html/rfc6891
- callesgg 12y agoA 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 12y agoFalse. IP fragmentation allows the size of a single UDP DNS response to be up to 65535 bytes, regardless of the network MTU.
- callesgg 12y agoIt 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 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 12y agoEDNS(0) allows for larger responses and is both commonly implemented and widely deployed. http://tools.ietf.org/html/rfc6891 http://tools.ietf.org/html/rfc6891
- peterwwillis 12y agoThe 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.
- tantalor 12y agoisinterneton.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 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>
- jingo 12y ago"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.
- vdm 12y agoVan 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/ http://named-data.net/