|
Re: 13 Root Server Limitation
2004-05-16 20:33:29
Dear Dean,
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
|
|