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

At 04:00 PM 4/3/2005, Rob Austein wrote:
>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?

With SHOULD, we're still giving them the option, I think. We're just giving 
a bit stronger guidance as to the preferred way of operating.


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

Which clients? I think this is the root cause of my concern. If you're 
talking about zeroconf clients, I agree. But 169.254/16 has, until a few 
years ago, just been another block of addresses in the address space. It's 
entirely possible to have any random machine ask for information on 
169.254.x.x. If that machine isn't zeroconf aware, for example because it's 
some embedded system or older router or whatever, why are we deciding to 
change the world and give it the silent treatment? This is what makes no 
sense to me.


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

That could work. It's similar in ways to some things in RFC 1812, where we 
specified the options and recommended the default (note for example 
directed broadcasts, though we had to change the default on that one in RFC 
2644).


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

I'd be willing to co-author such if there's interest from one or more other 
parties.