Re: draft-ietf-dnsop-serverid-01.txt

[David Conrad <david.conrad@nominum.com>]

Peter,

Thanks for the comments (sorry for the slow reply)...

On Tuesday, April 29, 2003, at 12:23  PM, Peter Koch wrote:
> To answer David's initial question, I do not feel it's ready for last 
> call.

OK.

> First, I agree that the en passant reassignment of the CHAOS class is a
> problem. It's not even clear that IANA (whichever instance) is in 
> charge of
> allocating a TLD there, at least I do not see a hint in RFC 2929.

Yeah.  So, I looked into this a (very small) bit and couldn't figure 
out who to ask at MIT to see if anyone there still uses CHAOSNet and/or 
whether it would be OK to use the .SERVER domain for this purpose (or 
perhaps to see what their reaction is to the existing use of .BIND).

> Since it's probably unwise to wait for an officially blessed TLD, it 
> might
> be better to change to a subdomain of the ARPA TLD.

I am highly skeptical this would be faster, but maybe I'm too cynical.

> The problem remains
> to find who's in charge of managing that in the CH class.

Yes.  Suggestions welcome.

> That aside, it should be explicitly stated that queries MUST NOT be
> processed with recursion.

Agreed.

> With respect to the Security Considerations I think it supports 
> "security by
> obscurity" a bit. While it may be useful to conceal or even change the
> "real" IP address of an anycast nameserver in critical infrastructure 
> to
> avoid (D)DoS to this address, I'd rather not encourage filtering 
> identity
> queries.

I tend to agree that not providing identifying information sort of 
defeats the purpose, however my thought here was that if I didn't put 
"implementors SHOULD provide a way to limit who can query" we'd get 
stuck in the privacy/security swamp.

Rgds,
-drc


#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request@cafax.se>.