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

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?

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