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

At 01:29 PM 3/29/2005, Rob Austein wrote:
>[There's another message from me to this list on this subject waiting
>  in a moderation queue somewhere, oh well.]
>
>There's one thing missing from Stuart's picture here: in cases where
>the load from these queries on a recursive name server is significant,
>it's less expensive (in terms of resources consumed) for the recursive
>name server to answer with RCODE 3 than for the name server just to
>drop the queries.  An RCODE 3 error will cause the client to shut up,
>while dropping the query will cause the client to retransmit.

This was part of what I had in mind with my response. I think it important 
to keep in mind the DNS servers may wind up answering the 169.254/16 INADDR 
questions for more than just zeroconf clients. In fact it is likely we will 
continue to see some traffic for these addresses from various sources for a 
good while to come. Telling a requestor to shut up and go away is the best 
recourse here for keeping excess traffic off the 'net.


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

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