Re: Issue: PTR RR queries for 254.169.in-addr.arpa

At Wed, 30 Mar 2005 09:47:59 -0500, Daniel Senie wrote:
> At 01:29 PM 3/29/2005, Rob Austein wrote:
> >
> >I think there's a compromise position here:
> >
> >- Clients MUST NOT expect recursive name servers to answer these
> >   queries.
> >
> >- Recursive name servers MUST NOT allow these queries to escape the
> >   local scope.
> >
> >- Recursive name servers MAY reply with RCODE 3 for their own reasons.
> 
> I think the name servers SHOULD reply with an RCODE 3.

I'm right on the edge with MAY vs SHOULD on this one.

The argument for MAY is that, if the operators of the recursive name
server(s) in question are willing to take the load hit, that's their
choice, and who am I to tell them how to spend their resources?

I could certainly live with SHOULD if that be the consensus.  In case
it wasn't obvious from my previous message, I'm proposing to agree to
disagree with Stuart on his claim that dropping bad queries is somehow
more likely to cause clients to upgrade than an RCODE 3 reply.

> Silently dropping packets also increases the difficulty of determining 
> network problems. Better to see the request AND response on a packet trace, 
> and know what happened.

I have some sympathy for this, but if the spec says "clients that send
this are broken and servers are allowed to drop it", it's pretty clear
what's going on in a packet trace if no response comes back.

If it were me, I'd always configure my recursive name servers to send
RCODE 3, presumably you would too, and I know which way I expect the
default to be set out of the box in at least one implementation if we
achieve consensus on MAY.  I just don't see an obvious public harm in
allowing people who agree with Stuart to do it his way.

Note that in extreme cases one might end up dropping bogons in
something that looked more like a packet filter than like a recursive
name server, in which case one could not count on responses anyway.

Hmm.  At the risk of splitting hairs and getting further into
implementation rules than I'd like, one could split the last rule
above into two separate rules:

- Recursive name servers MAY reply with RCODE 3.

- Recursive name server implementations SHOULD default to sending
  RCODE 3 out of the box unless explictly configured otherwise.

Which is indeed getting pretty close to plain SHOULD, but perhaps is a
bit clearer on the intent.

> I'd also recommend a new, separate document, possibly in DNSOP, to put 
> forth the requirements about handling 169.254. Of course these requirements 
> will be as well implemented and deployed as those in RFC1918, but it's 
> worth documenting them nonetheless.

Yep, several folks have suggested that we need such a doc.  These
addreses, RFC 1918 addresses, the recent IPv6 ULA stuff, ....

I have it on good authority that at least one of the DNSOP WG chairs
would be sympathetic to such a document were it to appear.