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

From: Stuart Cheshire <[email-masked]>
Date: Mon, 28 Mar 2005 20:05:09 -0800

> 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-masked]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org

---

From: Robert Elz <[email-masked]>
Date: Tue, 29 Mar 2005 14:01:05 +0700

Date:        Mon, 28 Mar 2005 20:05:09 -0800
    From:        Stuart Cheshire <[email-masked]>
    Message-ID:  <[email-masked]>

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

I wouldn't go quite that far, but I appreciate your argument, and think
your suggestion is probably the best solution.

For ...

  | Having recursive DNS servers stonewall those queries meets our goal of 
  | reducing the burden imposed on top-level name servers.

we should probably notice that what kills the upper level servers is
requests for data that doesn't exist.   When the server can answer,
rational caching is generally fairly effective, whereas negative
caching isn't (even when implemented, the TTL is generally severely
limited).

So, to keep the query rate on the in-addr.arpa servers rational, they
should simply delegate this domain somewhere, with a lengthy TTL.
It could delegate it to nowhere, one solution might be

	254.169.in-addr.arpa.    2592000 IN NS ns.254.169.in-addr.arpa.
	ns.254.169.in-addr.arpa. 2592000 IN A  169.254.103.76 ; glue

which would get the queries off the in-addr.arpa servers for a month,
then result in timeouts from anything actually doing lookups - help
get people to fix implementations or configurations to avoid the lookups
in the first place.

This is effective, even before any servers get to implement whatever
restrictions are eventually agreed.

kre

---

From: Aidan Williams <[email-masked]>
Date: Tue, 29 Mar 2005 17:16:10 +1000

> restrictions are eventually agreed.

That's a nice idea -- I think it will be more effective
than the previous suggestions.

Whilst I appreciate the sentiment of the previous
suggestions I don't think they will be very effective
for the following reasons:

   1. Most home existing home networks will NAT the
      DNS traffic to their local ISP recursive resolver
      OR use a local recursive resolver on the RG.

   2. I don't think there is a burning reason why an
      RG vendor would need to read the IPv4-LL spec
      to build a working gateway and so they would
      not know to silently discard bogus IPv4-LL
      queries or respond negatively.

How do we make an in-addr.arpa delegation happen?
A dnsop draft?

- aidan

---

From: Rob Austein <[email-masked]>
Date: Tue, 29 Mar 2005 13:29:16 -0500

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

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.

---

From: Daniel Senie <[email-masked]>
Date: Wed, 30 Mar 2005 09:47:59 -0500

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

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