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

[Peter Koch <pk@TechFak.Uni-Bielefeld.DE>]

> 	Regretfully, in a load-balanced world this won't work.  An 

You're right, but the draft targets another problem. It documents existing
practise while suggesting to change some implementation specific identifiers
to more generic ones. The draft's topic is initiated by an operational
question, i.e. identifying servers in an "anycast set". There's nothing I can
see in the dnsop charter that precludes this from being dealt with here,
so I'm in favor of keeping the document here and advance it.

To answer David's initial question, I do not feel it's ready for last call.

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.
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. The problem remains
to find who's in charge of managing that in the CH class.

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

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. People may do so anyway, but even today I may choose (although it
wouldn't be too wise) not to answer DNS queries originating from certain IP
addresses. If it were that critical, IP address based filtering wouldn't
suffice. And, if Joe user is expected to submit the IDENT string with a
problem report, he should be able to retrieve it in the first place.

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