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

Well, I thought we had a compromise, but Stuart appears to be having
second thoughts, so I guess we're back to square one.

At Fri, 29 Apr 2005 15:39:07 +0100, Stuart Cheshire wrote:
> 
> >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".

Yes, it does.  It should have just required recursive name servers to
reply with RCODE 3 rather than allowing them to drop queries silently,
but some of us were trying to be nice and compromise with those who
claim that silently dropping queries is better than answering them.

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

Not being measured, or not being reported.  Do you need every ISP in
the world to drop a book in their machine rooms to verify that the law
of gravity also applies in their location?

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

Wrong.

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

Fine, so change it to "person who should have set up a DNS reverse
zone to handle these bogus queries but didn't do so because somebody
sold them on the idea that no expertise is needed to connect to the
Internet."

It is exactly the absence of a site administrator that makes it
necessary to set up a default reverse zone (or behave as if one had
been set up, same thing) out of the box.

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

Via the wrong protocol.  LLMNR is not the DNS.  The name does not
exist in the DNS.  DNS name servers should say that it does not exist.
Unless of course the nonexistant site administrator does set up and
populate a DNS reverse zone.

You were saying something about needing to understand both IPv4LL and
DNS?

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

Unless you were planning to endow a fund that will cover the costs of
operating the name servers needed to soak up the load for the lifetime
of IPv4LL, please stop volunteering to spend other people's money
coping with evil side effects of your protocol.