-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Peter, On 02.05.2007 19:07, Peter Koch wrote:
6.9 Anycasting Name servers
If the name server set of an organisation running DNS without using
It is unclear to me whether "an organisation" refers to the domain holder, zone maintainer or the DNS infrastructure provider, if any. The original proposal deliberately chose the term TLD here, referring to the TLD manager, not the service provider and if this proposal intends to change that, it should be made more explicit.
As the proposal intends to open the policy not only to TLD nameservers but to all Anycasting DNS setups (with some more requirements than just anycasting), you can't refer only to the TLD manager anymore. "An organisation" is the organisation that operates the DNS servers. One could include again the term of the TLD manager, but I think it doesn't make much sense here as operating a TLD is not a requirement anymore.
anycasting technology would not pass the 'IANA Administrative Procedure for Root Zone Name Server Delegation and Glue Data' the organisation may receive a single dedicated /24 network prefix for the sole purpose of anycasting name servers, as described in RFC 3258.
The organisation should demonstrate that the number of name servers or IP addresses for these name servers in the delegation exceeds eight and that without anycasting their zone size exceeds the UDP datagram size.
During the discussion of the original anycast policy proposal it was carefully avoided -- after some looping debate -- to encode explicit DNS parameters into said proposal. That's the whole point of referring to IANA's delegation procedure. Now, I understand that IANA's procedures aren't applicable to non-TLDs, but at the same time it isn't obvious where the number "eight" originates from.
Why is the IANA procedure not applicable to non-TLDs? It is clear that the IANA document only refers to TLD nameservers, but one can apply the requirements to other DNS setups as well. And in my opinion this is a good procedure, as the IANA policy in regards to the UDP packet size is a reasonably clear and well-defined requirement for having the need of an anycasting setup.
To make matters more complicated, the basic procedure IANA is supposed to apply would indeed fit well, but then depends on the respective parent's glue and registration policy.
Sorry, can you explain this a bit further?
Again, I'm not sure anyone would want the RIPE NCC to engage in cumbersome tests and judgements, so even a fixed number might be fine - if there's some rationale given.
Yes, basically we can refer to the number of nameservers instead solely, but I meant to have a more technical justification (the size of the UDP datagrams) would be helpful.
NIT: "their zone size exceeds the UDP datagram size" should probably read "a referral response for their domain would exceed the 512 octet UDP payload limit".
I'd be fine with changing the text accordingly.
The organisation should also demonstrate that they need to do anycasting due to the geographical diversity of their DNS setup. The organisation will be required to demonstrate that anycasting will be used in diverse geographical locations. The existence of the real servers should be demonstrated with anycasting nodes that can be pinged and tracerouted.
That should be topological diversity instead. I'm not so confident that pings and traceroutes can differentiate between anycast and multihoming uses. The basic question is whether checks should be applied at all.
The checks were meant to provide a possibility for a check as last means if the application is clear enough. And for maintenance reasons, every anycasting DNS server is reachable by a dedicated IP, right?
Actually, the proliferation of anycast assignments could lead to more rigid filtering.
If that's the case, the current practice and policy of PI address assignments should lead to that as well. Regards: Tobias - -- Tobias Cremer M.A. IP Admin Engineer Cable & Wireless Telecommunication Services GmbH Landsbergerstr. 155 80687 Muenchen Germany Tel +49 89 926 99 0 -- FAX +49 89 926 99 180 -- COMNET 7 49 9169 Geschäftsführer Francois Goreux, Richard Pennal Amtsgericht München HRB 146 617 www.cw.com/de - -- Every message GnuPG signed -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGOvxVhC6y11CNwvcRAmCwAJ44LwLrB+FIGsmDNI2lO8vU0lT2pgCgxEzP KLL+TVQcNN69Rk7YQLvf+5w= =qVfh -----END PGP SIGNATURE-----