EDIT: Soon after I wrote this article I found out about EDNS, which allows for DNS responses >512 bytes. Read all about it here.
While playing around with some DNS tools I discovered a few oddities.
Lets start with a small note: When I speak of a root server, I am actually talking about the group of name servers that listen to a certain name. Let me explain: There are thirteen root server names, a.root-server.net, b.root-server.net etcetera up till m.root-servers.net. Each of these names resolves to a single IP address. In turn, each IP adresses has many, many servers listening to that address. So when I speak of a root server, I am actually referring to the group of servers that are behind that name. I have some links with more detailed info at the end of this text.
Back to the story now...
First, I noticed not all rootservers issue the same TTL for the A records of the rootservers. Most servers issue the following TTLs for the resource records of the root-servers:
TTL of NS records: 518400
TTL of A records: 3600000
But three servers (h, k and l) have decided to be different and issue a TTL of 518400 for the A records. See for yourself, by running the following command. It gets the root servers addresses for all thirteen root servers (output is here )
for server in `echo a b c d e f g h i j k l m`; do echo ===$server; dig @$server.root-servers.net ns . +tcp ; done > /tmp/dnsroots-tcp.txt ; less /tmp/dnsroots-tcp.txt
The difference in TTL's is quite big, 41 days compared to 6 days. One could conclude that a consequence of this is that the root servers with the lower TTL get a slightly bigger network load. I cannot think of any logical reason for this situation to be, other than this is a result of a mismatching policy between the organisations that provide the root name servers.
Another thing I found was that when you query root servers for NS records for the "." domain, in the reply to that query, not all root servers issue the glue (A and AAAA) records in the same order. You can see this by browsing through the file /tmp/dnsroots.txt that the previous command generated. Some servers sort the glue records by record type and by record name. This is a list of servers and how they sort their records:
Sorted by A record contents : a c e f i j
Sorted bi record type : b d g h k l m
Servers that sort by record type, always send the A records first. The other servers send a mix of A and AAAA. The consequence of the latter baffles me somewhat: If you do a UDP based query for NS records for the "." domain, then you will not always receive the complete list of root server A records in that single reply, as was the case in the past, because a DNS UDP reply may never be bigger than 512 bytes. As I understand it, the whole reason that there are 'only' 13 root server adresses is because then the root servers could then reply with a list of NS records and accompanying glue A records in a single UDP packet. Now, with the IPv6 records being sent along as glue records, the whole thing won't fit in single UDP packet anymore and you get sent a truncated package. Seeing as how most of the world is still using IPv4, and will be for a long time, it would be a wisest to at least put all the IPv4 (A) glue records first. If you run the following script, you can see what the truncated replies looks like (output is here ) :
for server in `echo a b c d e f g h i j k l m`; do echo ===$server; dig @$server.root-servers.net ns . ; done > /tmp/dnsroots-udp.txt ; less /tmp/dnsroots-udp.txt
I looked up the list of who actually runs the root servers to see if there was any pattern to be found; None. The two oddities I just spoke of probably don't have much impact because there are hardly any queries for the NS records for "." anyway. The TTLs for the NS and A records for "." are probably blatantly disregarded, because most if not all DNS caches use a hardcoded list of root servers, or 'hints' servers in BIND-speak. But I must admit I have no numbers to back this up, so I might be wrong.