Anycast is of no interest here. The regional disemination of Root Servers requested by the WSIS should not to be read as a dissemination of the NTIA root file, but as a regional/national redundant generation of the root file, with mutual cross verification. Each national/regional identical root file can then have 13 servers and enhance the reliablity of the whole system, providing root system failure / hacking / attack fall-out / DoS containment.
Under the current deployement the DNS reference is not the network reality, nor the TLD Managers and Regiistrants decision. This is in blattant opposition with the "Internet core values" the IETF draft describes. The reference is a single master file on which ICANN/IANA acknowledges having no direct power. This is not something the Tunis 2005 meeting will accept when you consider the positions in Geneva 2003, so we are better off presenting an acceptable solution.
All the more than regional root file compilation addresses the IPv6 concern: each root sever system may have only a few machines. If only 1/10h of the countries run a root compilation/server system, we could have from 60 to 240 root servers. 20 root servers system would be a good back-up and for the users to chose from (RFC 883). The cost would ^probably be lower as the load on each machine will be much lower than today. Most of the 97.5% illigitimate load on the existing single system will probably only partly export to others. This means that we could decrease the load on an aveage root server machine down to 0.25% of the today load.
I know that you do not trust DNSSEC, but accessing randomly two or three different root server systems to verify a received info is another way towards security without taking risk of implementing a new system as DNSSEC. Even if this results in 3 times more traffic the load per machine would stay around less than 1% of the today load and the load on the network would probably be reduced with information travelling more locally.
jfc
At 00:22 17/05/04, Dean Anderson wrote:
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
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf