On Sun, 16 May 2004, Thomas Bocek wrote: > Hi > > I?m confused with the fact than the number of root servers is limited to 13. > From RFC 3226: > > "The current number of root servers is limited to 13 as that is the maximum > number of name servers and their address records that fit in one 512-octet > answer for a SOA record. If root servers start advertising A6 or KEY records > then the answer for the root NS records will not fit in a single 512-octet DNS > message, resulting in a large number of TCP query connections to the root > servers." > > A query send to one of the root servers with a long name (length 255) > shows that the answer is 511 bytes, returning one A and 13 NS records. > My question is: Why are all 13 NS returned? BIND adds an additional section that is optional. If this section weren't provided, then more root servers could be added. It has been pointed out that this additional section information is ignored by most resolvers, and so it useless, except to persons manually interpreting the output of DNS query details. Some nameservers do not provide this additional data. It would be operationally advantageous to use a nameserver software on the Root servers that did not provide the additional section. However, I think your interest is in regard to DNSSEC deployment. There are other problems with DNSSEC deployment, that limit or preclude widespread utility. I can't cover them all in one message. But suffice it to say that DNSSEC isn't really secure, and that further, the root servers operators have widely adopted a dubious anycast replication model that won't work well with TCP and load-balancing BGP configurations that are gaining the interest of ISPs. Such load balancing configurations will send packets over different paths to the same IP address. This is significant because an Anycast server is two (or more) physical servers with the same IP address, but with different paths to each server to distribute load. Anycast will not cause problems with single packet UDP DNS queries, but will have problems with load balanced, TCP connections, especially where BGP load balancing configurations would be likely to send packets over different paths (and thus to different anycast servers) within a very short period of time, perhaps even sequential packets could sent over different paths. This dubious anycast configuration was discussed and "approved" by the NAMEDROPPERS Working Group in late November, 2002. Unfortunately for the anycast discussion, the list then became distracted by discussions concerning procedural irregularities involving the AXFR-clarify Draft, which would have altered the DNS AXFR and IXFR protocol to conform to the non-standard ISC/BIND implementation, despite a number of other implementations being able to follow the AXFR and IXFR specifications. This quickly developed into a discussion regarding abuse by the list administrator (Randy Bush) with respect to Dan Bernstein, and so the anycast discussion was abandoned. As the IETF list members are perhaps unaware, the charges of abuse by ISC and ISC-promoters is hardly new. It is very hard to get real work done in the DNS working groups as a result. ISC/BIND promoters have the working group tied up with gratuitous alterations to widely implemented protocols (eg AXFR-clarify) and irrational and misleading changes (eg IN-ADDR required) that have been demonstrated to either be security risks or dangerously misleading security placebo's, and have tried to suppress dissent on these issues by refusing to accept email, and in the past, silently discarding email, and otherwise harrassing people who offer reasoned and detailed objections. I and others would probably be more involved in issues like DNSSEC, and no doubt more progress would be made, if it weren't for the distractions of the mismanagement of the IETF and its working groups. Dean Anderson Av8 Internet, Inc _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf