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

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

The text above I agree with.

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

This text I have some reservations about. It suffers from the 
all-to-common disease that "we couldn't decide, so we'll agree to 
disagree". That's not the role of a specification. A specification is 
supposed to specify. It reminds me 802.11af (Power over Ethernet) where 
they couldn't decide whether to specify that the power shares the 
100Base-T data pairs, or runs over the two unused pairs, so the 
specification says that switch vendors can do either, and ALL PoE devices 
have to be able to work BOTH ways, thereby increasing cost and complexity 
and opportunity for problems and incompatibility.

I think we all agree that recursive name servers should not allow these 
queries to escape and place a burden on IANA name servers, but all the 
arguments about returning RCODE 3 instead of silently dropping them 
revolve around the purported burden that retransmitting clients impose on 
a recursive name server, and the people making those arguments have 
offered NO operational data showing any evidence that this purported 
burden is real. We've had 169.254 addresses in Mac and Windows for FIVE 
years now, and they are in UPnP devices, every network printer made for 
the last couple of years, and other devices. Where is the evidence of an 
actual burden on local recursive name servers caused by these devices or 
their peers?

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

This text I profoundly disagree with. It looks like it was written by 
someone who knows about DNS, but not about IPv4 Link-Local addressing, 
which is a problem. To write about how DNS and IPv4LL interact, you need 
to understand both.

Consider this sentence:

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

What on earth does that mean? Who is the "site administrator"? The whole 
point of IPv4LL is for small transient ad-hoc networks where there's no 
DHCP server, no DNS server, and definitely no "site administrator"?

The whole point of IPv4LL is that hosts assign their own addresses, at 
random. The "site administrator" is not in control of what IPv4 
Link-Local addresses are in use; the individual devices are. The concept 
of a site administrator manually setting up a reverse tree corresponding 
to IPv4 Link-Local addresses in use, when he or she has no knowledge of 
what 
IPv4 Link-Local addresses will be in use from one minute to the next, is 
utter nonsense. That concept may be applicable to net 10 and the other 
private address ranges, but not to IPv4LL. Each host operates 
autonomously, in cooperation with its peers, to select a unique IPv4LL 
address of its own choosing. Therefore in the IPv4LL world the only 
credible course of action to find out the host name corresponding to a 
given random address is to ask the host that chose that random address 
what it thinks its name is. Asking some other name server makes no sense.

Returning an authoritative NXDOMAIN error for 254.169.in-addr.arpa names 
is not the semantically correct response. The semantically correct 
response for a server to give to such a query is, "Why are you asking 
me?" Possible semantically correct responses are to ignore the query, or 
possibly REFUSED (5), but not an authoritative assertion that no such 
name exists. The name does exist; the client just asked the wrong entity.

Robert Elz suggested this pragmatic solution:

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

Something close to this is already done:

>[chesh7:~] cheshire% dig -t ns 254.169.in-addr.arpa
>
>; <<>> DiG 9.2.2 <<>> -t ns 254.169.in-addr.arpa
>;; global options:  printcmd
>;; Got answer:
>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32401
>;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2
>
>;; QUESTION SECTION:
>;254.169.in-addr.arpa.          IN      NS
>
>;; ANSWER SECTION:
>254.169.in-addr.arpa.   604800  IN      NS      blackhole-1.iana.org.
>254.169.in-addr.arpa.   604800  IN      NS      blackhole-2.iana.org.
>
>;; ADDITIONAL SECTION:
>blackhole-1.iana.org.   2365    IN      A       192.175.48.6
>blackhole-2.iana.org.   452     IN      A       192.175.48.42
>
>;; Query time: 483 msec
>;; SERVER: 17.128.100.10#53(17.128.100.10)
>;; WHEN: Fri Apr 29 14:48:14 2005
>;; MSG SIZE  rcvd: 130

As to the address to give, I'd recommend 169.254.0.0 as the logical 
non-address for this non-server. Our spec already says:

>   The first 256 and last 256 addresses in the 169.254/16
>   prefix are reserved for future use

This could be the first of such "future uses".

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