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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf