Re: Proposed resolution: PTR queries for 254.169.in-addr.arpa

>> This text I have some reservations about. It suffers from the 
>> all-to-common disease that "we couldn't decide, so we'll agree to 
>> disagree".
>
>Yes, it does.  It should have just required recursive name servers to
>reply with RCODE 3 rather than allowing them to drop queries silently,
>but some of us were trying to be nice and compromise with those who
>claim that silently dropping queries is better than answering them.

Thanks for being nice, but lets not let that get in the way of making a 
good specification.

I'm the last person to want some kind of Pyrrhic victory ("sure the 
document sucks, but at least I got some of my words in it as one of the 
options").

The goal of silently dropping queries was to remove the ability for 
device vendors to use that as a crutch to justify why they don't need to 
fix their products not to send these bogus queries. (e.g. Customer 
reports a problem, and vendor replies, "RFC 3927 says that 'Recursive 
name servers MAY reply with RCODE 3', and the reason our product doesn't 
work is because you failed to follow the RFC and do that.")

Having a MAY serves neither purpose -- we leave the DNS administrator and 
DNS vendors without clear instruction what to do, we burden the software 
and the user with yet more configuration options to learn and understand, 
and we provide a crutch for lazy device vendors who want to point to an 
alternative way to solve their timeout and delay problems, rather than 
changing their product.

If we're going to allow name servers to return RCODE 3, we may as well 
require it, since lazy device vendors will. I'd rather have a good 
specification with parts I disagree with, than a vague waffly 
specification where everyone can read it a different way and thereby 
delude themselves into thinking they agree with what it says.

Here is some proposed text. I don't like it and I don't agree with it, 
but at least it's clear and unambiguous, which is better than being vague 
for the sake of letting everyone think they got their way. A protocol 
specification is not complete when there are no more choices left to add; 
it is complete when there are no more choices left to take away.

   Mapping from IPv4 addresses to host names is conventionally done
   by issuing DNS queries for names of the form,
   "x.x.x.x.in-addr.arpa." When used for link-local addresses, which
   have significance only on the local link, it is inappropriate to
   send such DNS queries beyond the local link.

   DNS clients MUST NOT send unicast DNS queries for any name that
   falls within the "254.169.in-addr.arpa." domain.

   DNS caching servers receiving queries from non-compliant clients
   for names within the "254.169.in-addr.arpa." domain MUST return
   RCODE 3, authoritatively asserting that no such name exists in
   the unicast Domain Name System.

>> Where is the evidence of an  actual burden on local recursive
>> name servers caused by these devices or their peers?
>
>Not being measured, or not being reported.  Do you need every ISP in
>the world to drop a book in their machine rooms to verify that the law
>of gravity also applies in their location?

Yes, but wouldn't it be nice if someone, somewhere had actually measured 
it, just once?

Stuart Cheshire <[email protected]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org