Internet and e-mail policy and practice
including Notes on Internet E-mail


2011
Months
Sep

Click the comments link on any story to see comments or add your own.


Subscribe to this blog


RSS feed

Add to My Yahoo!

Subscribe with Bloglines


[Valid RSS]

Home :: Internet

07 Sep 2011

The design of the Domain Name System (Part V) - Large data Internet

In the previous four installments, we've been looking at aspects of the design of the DNS. Today we look at the amount of data one can ask the DNS to store and to serve to clients.

Most DNS queries are made via UDP, a single packet for query and a single packet for the response, with the packet size traditionally limited to 512 bytes. This limits the payload of the returned records in a response packet to about 400 bytes, after allowing for the overhead in a DNS response. Many clients and caches (about half in my experience) support the EDNS0 extension, which lets the client specify the maximum packet size, usually 4096. The length fields in DNS records are 16 bits, so the absolute limit on a packet or a record is 64K bytes. The DNS spec says that if a response is too big to fit in a UDP packet, the server sends a partial response with the truncation bit set, which tells the client to retry the query over TCP.

Until a year or two ago, it was rare to see a DNS response that didn't fit in a 512 byte packet other than for AXFR and IXFR. Now, as DNSSEC is starting to become more widespread, larger packets are becoming more common, since DNSSEC adds a great deal of signature material to every response and requires EDNS0.

Although it is possible in principle to put large chunks of data into the DNS, up to 64K, the bigger a response is, the less likely it is to be returned reliably. Some DNS servers still don't support TCP, far too many firewalls don't allow TCP DNS traffic, a few broken firewalls won't pass DNS packets bigger than 512 bytes, and DNS caches are not tuned to cache large data well. I've seen the occasional proposal to store chunks of XML in the DNS, but they generally seem to be from people who want to see XML everywhere.

Since a TCP query requires a UDP query and response, which includes the truncation flag, and a subsequent TCP session, a more sensible way to handle large data is to put a pointer to the data such as a URI in the DNS which can be returned via UDP, and then have the application use another scheme such as HTTP to retrieve the large data. That's about the same amount of net traffic (a UDP round trip followed by a query and response via TCP), but HTTP servers and HTTP caches are designed to handle large data that DNS servers and caches aren't.

In our next installment, we'll look at the ever vexing issue of overloaded record types or, why everything shouldn't be a TXT record.


posted at: 22:43 :: permanent link to this entry :: 0 comments
Trackback link is http://jl.ly/Internet/dnsdesign5.trackback

Topics


My other sites

Who is this guy?

Airline ticket info

Taughannock Networks

Other blogs

CAUCE
CASL Comes into Force
113 days ago

A keen grasp of the obvious
Progress in e-mail
34 days ago

Related sites

Coalition Against Unsolicited Commercial E-mail

Network Abuse Clearinghouse



© 2005-2014 John R. Levine.
CAN SPAM address harvesting notice: the operator of this website will not give, sell, or otherwise transfer addresses maintained by this website to any other party for the purposes of initiating, or enabling others to initiate, electronic mail messages.