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

> Thomas is suggesting the proper response by a server is to
> either RCODE 3 them unless the administrator of the server has
> specifically configured information or automation that will
> produce a useful response.
> 
> Stuart's language that the server MUST NOT send any response
> whatsoever back to the client is at odds with this. In general
> I am concerned about a client knowing enough about a DNS
> server to be able to ask it a question, and that server simply
> ignoring it. At the least, this results in timeouts, something
> I think we'd prefer to avoid.

That last statement is the key point.

It depends on whether we're looking at this short-term, or long-term.

The long-term goal is that compliant clients should NEVER issue unicast 
DNS queries for names within the "254.169.in-addr.arpa." domain (i.e. 
reverse lookups for IPv4 link-local addresses). Clearly today there are 
some clients that violate this.

Another important goal in the meantime is to reduce or eliminate the 
burden imposed on top-level name servers by those non-compliant clients, 
while at the same time encouraging those product developers to update 
their code to stop sending the bogus queries in the first place.

Having recursive DNS servers stonewall those queries meets our goal of 
reducing the burden imposed on top-level name servers. I think we all 
agree on that. The question is whether those recursive DNS servers should 
silently ignore the bogus queries, or answer them.

My prediction is that if we have recursive DNS servers return valid DNS 
response packets in answer to those invalid DNS queries, then we 
legitimize the bad behaviour. Many device vendors will see this state of 
affairs as "good enough". It is, they will say, the DNS server's 
responsibility to return NXDOMAIN, not their responsibility to suppress 
the query in the first place. There will be plenty of finger pointing, 
and no action. Many device vendors will not fix their code, and many 
recursive DNS servers (think cheap home NAT gateways) will not be fixed 
either. The problem will persist. If, on the other hand, the recursive 
DNS servers silently ignore the queries, then the bad clients will suffer 
timeouts, as you say, and device vendors will have an incentive to do 
something about it. They won't be able to point to RFC 3927 and insist 
that it's the DNS server's RESPONSIBILITY to give them a valid response 
to that query. The only solution endorsed by RFC 3927 will be for them to 
fix their code, which helps us achieve the long-term goal of stopping the 
bogus queries at the source.

Of course, you or anyone else is free to configure your own DNS server to 
respond to "254.169.in-addr.arpa." queries however you choose. The point 
that I care about is that RFC 3927 should not sanction this as the 
long-term solution, so that end-system vendors conclude that they don't 
need to do anything. If we encourage end-system vendors to do nothing, 
we'll still have this problem ten years from now.

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