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

At 07:06 PM 3/26/2005, Bernard Aboba wrote:
>Yet another issue has come up with respect to RFC 3927, which is still in
>48 hours.
>
>Thomas Narten has brought up a concern relating to the handling of
>DNS PTR RR queries for 254.169.in-addr.arpa.  The text of his email
>is enclosed at the end of this message.
>
>Here is the text I have proposed to add in order to address this issue:
>
>"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."
>
>This is the text that Stuart has proposed:
>
>"  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 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."
>
>We would like participants in the former ZEROCONF WG to weigh in on
>this issue.  Opinions?

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.

On first reading of the two sets of text, without the benefit of hearing 
supporting arguments, I think Bernard's text covers the issue sufficiently.

>--------------------------------------------------------------------------------
>Date: Wed, 09 Mar 2005 11:34:10 -0600
>From: Thomas Narten <[email protected]>
>To: Bernard Aboba <[email protected]>
>Cc: RFC Editor <[email protected]>, Bernard Aboba
><[email protected]>, Stuart Cheshire <[email protected]>,
>      Margaret Wasserman <[email protected]>, Erik Guttman
><[email protected]>
>Subject: Re: ADs - Re: authors 48 hours: RFC 3927
><draft-ietf-zeroconf-ipv4-linklocal-17.txt> NOW AVAILABLE
>
>RFC Editor;
>
>(other parties may  want to sit down before reading further)
>
>Are we all seated? :-)
>
>Can we stop the presses on this document?
>
>One other issue has come up that I think we should address. The issue
>is analogous to the one being discussed on the IPv6 list under the
>subject heading:
>
>Subject: Proposed Changes to ULA DNS section
>
>(see below)
>
>I propose we craft similar text, circulate _very_ briefly on zeroconf,
>and then move on.
>
>Sorry, this document seems to continually take 1/2 more step towards
>the finish line, but we can't quite get there, and this is actually a
>very important issue...
>
>Thomas
>
>From: Margaret Wasserman <[email protected]>
>To: [email protected]
>Date: Tue, 8 Mar 2005 11:18:41 -0500
>
>Hi All,
>
>During IESG review, Mark Andrews raised a significant operational
>concern regarding the DNS section of the ULA document
>(draft-ietf-ipv6-unique-local-addr-09.txt), and I am currently
>delaying approval of the document until the issue can be resolved.
>
>The concern, which is shared by other DNS experts, is that widespread
>use of these addresses could cause a significant, and pointless, load
>on servers in the ip6.arpa zone -- a problem that could be avoided by
>different recommendations in the DNS section of this document.  The
>DNS directorate met on Sunday evening and came up with the attached
>wording (to replace the current DNS section in the ULA draft) that
>will address this concern.
>
>We will discuss this issue briefly at the IPv6 meeting this
>afternoon, but I wanted to make sure that you all have a copy of the
>text for consideration before the meeting (since it can't reasonably
>fit on a single slide).
>
>I'd also like to know if there are any objections to making this
>change to the ULA document.
>
>Margaret
>
>---
>
>OLD:
>
>4.4 DNS Issues
>
>     At the present time AAAA and PTR records for locally assigned local
>     IPv6 addresses are not recommended to be installed in the global DNS.
>     The operational issues relating to this are beyond the scope of this
>     document.
>
>     For background on this recommendation, the concern about adding AAAA
>     and PTR records to the global DNS for locally assigned Local IPv6
>     addresses stems from the lack of complete assurance that the prefixes
>     are unique.  There is a small possibility that the same PTR record
>     might be registered by two different organizations.  Due to this
>     concern, adding AAAA records is thought to be unwise because matching
>     PTR records can not be registered
>
>NEW:
>
>4.4 DNS Issues
>
>At the present time AAAA and PTR records for locally assigned local
>IPv6 addresses are not recommended to be installed in the global DNS.
>
>For background on this recommendation, one of the concerns about
>adding AAAA and PTR records to the global DNS for locally assigned
>Local IPv6 addresses stems from the lack of complete assurance
>that the prefixes are unique.  There is a small possibility that
>the same IPv6 Local addresses will be used by two different organizations
>both claiming to be authoritative with different contents.  Due to this
>concern, adding AAAA records for these addresses to the global
>DNS is thought to be unwise.
>
>Reverse (address-to-name) queries for IPv6 Local  addresses must
>not be sent to name servers for the global DNS, due to the load that such
>queries would create for the authoritative name servers for the
>ip6.arpa zone.  This form of query load is not specific to Local IPv6
>addresses; any current form of local addressing creates additional
>load of this kind, due to reverse queries leaking out of the site.
>However,
>since allowing such queries to escape from the site serves
>no useful purpose, there is no good reason to make the existing
>load problems worse.
>
>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 c.f.ip6.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 bothered to set up
>the reverse tree corresponding to the IPv6 Local addresses in use,
>returning RCODE 3 is in fact the correct answer.
>
>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>[email protected]
>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------