Reason for Limited number of Root DNS Servers
kcd at chrysler.com
Fri Nov 11 16:20:30 UTC 2011
On 11/11/2011 4:30 AM, Gaurav Kansal wrote:
> Thanks a lot Mark.
> But I don't understand the calculation part.
> Is there any source available from which I can get detail information
> regarding the same??????
> Thanks and Regards,
> Gaurav Kansal
> -----Original Message-----
> From: Mark Andrews [mailto:marka at isc.org]
> Sent: Friday, 11 November, 2011 12:14 PM
> To: Gaurav Kansal
> Cc: bind-users at isc.org
> Subject: Re: Reason for Limited number of Root DNS Servers
> In message<firstname.lastname@example.org>, Gaurav Kansal writes:
>> Dear All,
>> Somewhere I read that number of ROOT DNS servers is limited to 13
>> because of protocol limitation of DNS and UDP.
>> Exact writing was "A combination of limits in the DNS and certain
>> protocols, namely the practical size of unfragmented User Datagram
>> (UDP) packets, resulted in a limited number of root server addresses
>> that can be accommodated in DNS name query responses. This limit has
>> determined the number of name server installations at (currently) 13
>> clusters, serving the needs of the entire public Internet worldwide."
>> As root DNS are running in anycast so number is not an issue at all.
>> But I don't understand where exactly is this limitation exists???
>> Please some elaborate on this.
>> Thanks and Regards,
>> Gaurav Kansal
> Actually despite the words above it has *nothing* to do
> with unfragmented UDP and everything to with being able to
> reassemble fragmented UDP.
> All IPv4 hosts MUST accept fragmented packets up to 576
> octets (RFC 791). DNS's 512 octet UDP limit was choosen to
> ensure that the UDP datagram can always be reassembled and
> for there to be room for some IP options in addition to the
> IP and UDP headers.
> Originally there wasn't commonality in the root server's
> names. Then it was said if we make the maximum use of
> compression how root servers can we fit into a DNS/UDP
> The first NS record takes 31 octets (1 + 2 + 2 + 4 + 2 + 20).
> Additional a NS records for . takes 15 octets (1 octets for
> the name, 2 octets for the class, 2 octets for the type, 4
> octets for the ttl, 2 octet for length and 4 of actual data).
> A "A" record with a compressed ownername takes 16 octets
> (2 octets for the name, 2 octets for the class, 2 octets for the
> type, 4 octets for the ttl, 2 octet for length and 4 of actual
> Then there is the 12 octet header and the 5 octet question.
> Doing the math on priming queries you get the following:
> 13 names uses 436 octets
> 14 names uses 467 octets
> 15 names uses 498 octets
> If you have a referral to the root with a maximum sized qname
> it takes 482 octets (12 + 255 + 4 + 31 + 15 * 12).
I believe you only need to read RFCs 1034 and 1035 thoroughly to
understand the structure and size of a response packet, including label
compression. Mark's calculations didn't include any later protocol
extensions like EDNS0 or DNSSEC-related records, although with a modern
resolver you might see those come into play.
More information about the bind-users