[address-policy-wg] 2007-02 New Policy Proposal (Change in IP Assignments for Anycasting DNS Policy)

-----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-----