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

At Thu, 5 May 2005 14:42:27 +0100, Stuart Cheshire wrote:
> 
>    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.

Ok.

>    DNS clients MUST NOT send unicast DNS queries for any name that
>    falls within the "254.169.in-addr.arpa." domain.

Substantive: While I understand why you want to say "unicast" here, it
doesn't work.  First of all, you're leaving out anycast, which some
people use.  Secondly, the door you're trying to leave open is
presumably for LLMNR (or mDNS if you prefer), which is a different
protocol on a different port that just happens to reuse DNS data
formats.  I think it would be best just to drop "unicast" here;
failing that (ie, if we can't agree that LLMNR is a different
protocol), we'll have to qualify it by port number or something
equally pedantic.

>    DNS caching servers receiving queries from non-compliant clients
>    for names within the "254.169.in-addr.arpa." domain MUST return
>    RCODE 3, authoritatively asserting that no such name exists in
>    the unicast Domain Name System.

Nit: s/DNS caching servers/DNS recursive name servers/

Substantive: s/unicast// (see above).

Substantive: s/MUST return RCODE 3/MUST return RCODE 3 by default/

I'd be willing to drop the last point, but in some cases (eg, on a
typical corporate network) there most certainly is a site
administrator, who might choose to populate a local reverse tree for
254.169.in-addr.arpa for reasons of his or her own -- none of our
business, so long as it doesn't escape the local link.