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

From: Bernard Aboba <[email-masked]>
Date: Fri, 22 Apr 2005 21:14:42 -0700 (PDT)

Here is a proposed resolution to the Issue:

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

Recursive name servers MUST NOT allow these queries to
escape the local scope.  Recursive name servers MAY reply
with RCODE 3, or they MAY silently discard the request.

By default, recursive name server implementations SHOULD be
configured to act as if they were authoritative for an
empty 254.169.in-addr.arpa zone and return RCODE 3 for any
such query.  Implementations SHOULD allow this default to
be overridden.  Returning an RCODE 3 is the correct default
setting because it reduces the query load but also because if
the site administrator has not set up the reverse tree
corresponding to IPv4 Link-Local addresses in use,
returning RCODE 3 is in fact the correct answer."

---

From: Rob Austein <[email-masked]>
Date: Sun, 24 Apr 2005 14:17:01 -0400

At Fri, 22 Apr 2005 21:14:42 -0700 (PDT), Bernard Aboba wrote:
> be overridden.

Er, s/SHOULD/MUST/ here.  Hard wiring this into a recursive name
server with no way to override it is probably not wise.

>		  Returning an RCODE 3 is the correct default

Other than the above, this seems ok.

---

From: Daniel Senie <[email-masked]>
Date: Sun, 24 Apr 2005 17:16:59 -0400

>server with no way to override it is probably not wise.

Since the text said "configured to act" not "hard programmed to act" I took 
this to mean the default configuration file supplied with the name server 
implementation had it set that way, vs. programmed in as a default response.

To my thinking, a default config file shipping with the DNS server software 
that claims to be authoritative for 169.254/16 would meet the text above. 
The user is free to remove or change that default configuration. Indeed, 
the fact that the text talks about this as a default condition seems to 
imply the ability to change it.

Long way of saying that, at least to my reading, "hard wiring" was not 
implied, even with the SHOULD present. That said, if the text changed to 
"Implementations MUST allow this default to be overridden" I would still 
approve of the document.

---

From: Erik Guttman <[email-masked]>
Date: Mon, 25 Apr 2005 10:23:07 +0200

Folks,

[This page should be viewed as HTML, sorry if this inconveniences you!]

I support the text proposed by Bernard with the changes by Rob.

- - -

Let's see if we have closure on all items.  Going back over the email 
sent in the past weeks, I believe the points made are the following.  If 
I have left anything out or misrepresented the dialog, please reply with 
a revised version of the table.

If anyone has any concern with the final suggested resolution (24 Apr 
05), please send email to the list by next Monday, May 1.

*Date
* 	*Who
* 	*Problem
* 	*Suggested Resolution
*
05 Oct 04
	RFC Editor
	Starts 48 hour last call on RFC 3927
	
06 Oct 04
	Stuart Cheshire
	Several changes requested.
	
03 Mar 05
	Authors, RFC Editor, post-WG
	
	The requested changes were reviewed and the resolution was agreed to by 
all parties.
15 Mar 05
	Margaret Wasserman
	Concern was raised due to related work in the IPv6 WG related to 
reverse lookup of local addresses.
	Bernard suggested a straw man resolution:

Here is a strawman:

This text will be added to a new 'DNS Server Considerations' section:

"Reverse (address-to-name) queries for IPv4 Link-Local
addresses MUST NOT be sent to name servers for the global DNS.
The recommended way to avoid sending such queries to nameservers for
the global DNS is for recursive name server implementations to act as
if they were authoritative for an empty 254.169.in-addr.arpa zone and
return RCODE 3 for any such query.  Implementations that choose this
strategy should allow it to be overridden, but returning an RCODE 3
response for such queries should be the default, both because this
will reduce the query load problem and also because, if the site
administrator has not set up the reverse tree corresponding to
IPv4 Link-Local addresses in use, returning RCODE 3 is in
fact the correct answer."

24 Mar 05
	Stuart Cheshire
	Counter proposal:

The DNS experts are the one who have alerted us to the issue. While I
>agree there is probably room for debate as to "how big a problem this
>really is in practice", I doubt any one will argue that PTR queries
>for these addresses should be forwarded off link. Seems a no-brainer
>to just state that in the document. That is all that is being asked.

At the high level I agree that there is no point sending these PTR 
queries off-link. Where I disagree is in the details, particularly in 
caching servers returning authoritative NXDomain answers.

This is what I propose, and would support in the document:

   Mapping from IPv4 addresses to host names is conventionally done

   DNS caching servers receiving queries from non-compliant clients
   for names within the "254.169.in-addr.arpa." domain MUST silently
   ignore them. A caching server MUST NOT attempt to complete such
   queries on behalf of the client, and MUST NOT send any DNS
   response back to the client.

	This leads to debate that has not yet been
resolved.   The individual problems and
attempted resolutions are summarized
below.

The point of debate is whether recursive
DNS servers MUST silently drop queries
for reverse lookup of LL addressses
or whether they should return error code 3.

Stuart suggests that servers silently drop
requests.  Thomas and Dan suggest that
returning an error would help with
diagnosing failure conditions at the client
and reduce time outs.
27 Mar 05
	Rob Austein

Stuart Cheshire wrote:
> The ONLY DIFFERENCE between what I'm saying here and what you're saying 
> is that I want the recursive name servers to provide this defense in a 
> form that encourages end-system devices to be fixed to not issue the 
> queries in the first place, rather than a form that encourages end-system 
> devices to continue with the bad behaviour forever.

Rob Austein replied:

It was not at all clear to me from the earlier exchange that this was
the only point on which we disagreed, but if so, I'm glad to hear it.

We should probably take this one point to the zeroconf list, since
Bernard has started the discussion there, but, in brief, I see two
issues here:

a) Whether silently dropping bogons is more likely to cause buggy
   clients to upgrade than supplying RCODE 3 answers.  This is not
   obvious to me.  I would think that users would be about as likely
   to figure out that something's broken from being told that names
   don't exist as they would from having queries time out, but I'll
   stipulate that this is a matter of opinion on which reasonable
   people might disagree in the absence of empirical data.

b) *Which solution is easier on the recursive name servers.  This is
   slightly more complex than it might seem at first, since presumably
   if there were a clear answer to (a) that caused buggy clients to
   upgrade, that would be the right long term answer.  As a short term
   answer, however, and in the absence of a clear answer to (a),
   sending RCODE 3 responses will cause the buggy clients to shut up
   and go away more quickly.  As a result, I'm pretty sure that this
   is the path ISPs will choose regardless of what we tell them unless
   we give them a really good reason why they should do otherwise.
   Given my opinions on (a), I don't believe that such a reason
   exists, but if one does, best make it blindingly obvious.*

23Apr 05
	Bernard Aboba

This text will be added to a new 'DNS Server Considerations' section:

24 Apr 05
	Rob Austein

The revised proposal is below, with the changes in bold face:

This text will be added to a new 'DNS Server Considerations' section:

By default, recursive name server implementations *MUST* be
configured to act as if they were authoritative for an
empty 254.169.in-addr.arpa zone and return RCODE 3 for any
such query.  Implementations *MUST* allow this default to
be overridden.  Returning an RCODE 3 is the correct default
setting because it reduces the query load but also because if
the site administrator has not set up the reverse tree
corresponding to IPv4 Link-Local addresses in use,
returning RCODE 3 is in fact the correct answer."

Best regards,

Erik

._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._.
 E r i k   G u t t m a n   - Sun Microsystems -   cell: +49 162 790 1116

---

From: Erik Guttman <[email-masked]>
Date: Mon, 25 Apr 2005 11:00:26 +0200

> 05), please send email to the list by next Monday, May 1.

Heh - I meant Monday, May 2, 2005. 

For old time's sake, let's consider this a one week last call with the 
default decision being ACCEPT.

Best regards to y'all,

Erik