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

From: Rob Austein <[email-masked]>
Date: Sun, 03 Apr 2005 16:00:59 -0400

At Wed, 30 Mar 2005 09:47:59 -0500, Daniel Senie wrote:
> At 01:29 PM 3/29/2005, Rob Austein wrote:
> >
> >I think there's a compromise position here:
> >
> >- Clients MUST NOT expect recursive name servers to answer these
> >   queries.
> >
> >- Recursive name servers MUST NOT allow these queries to escape the
> >   local scope.
> >
> >- Recursive name servers MAY reply with RCODE 3 for their own reasons.
> 
> I think the name servers SHOULD reply with an RCODE 3.

I'm right on the edge with MAY vs SHOULD on this one.

The argument for MAY is that, if the operators of the recursive name
server(s) in question are willing to take the load hit, that's their
choice, and who am I to tell them how to spend their resources?

I could certainly live with SHOULD if that be the consensus.  In case
it wasn't obvious from my previous message, I'm proposing to agree to
disagree with Stuart on his claim that dropping bad queries is somehow
more likely to cause clients to upgrade than an RCODE 3 reply.

> Silently dropping packets also increases the difficulty of determining 
> network problems. Better to see the request AND response on a packet trace, 
> and know what happened.

I have some sympathy for this, but if the spec says "clients that send
this are broken and servers are allowed to drop it", it's pretty clear
what's going on in a packet trace if no response comes back.

If it were me, I'd always configure my recursive name servers to send
RCODE 3, presumably you would too, and I know which way I expect the
default to be set out of the box in at least one implementation if we
achieve consensus on MAY.  I just don't see an obvious public harm in
allowing people who agree with Stuart to do it his way.

Note that in extreme cases one might end up dropping bogons in
something that looked more like a packet filter than like a recursive
name server, in which case one could not count on responses anyway.

Hmm.  At the risk of splitting hairs and getting further into
implementation rules than I'd like, one could split the last rule
above into two separate rules:

- Recursive name servers MAY reply with RCODE 3.

- Recursive name server implementations SHOULD default to sending
  RCODE 3 out of the box unless explictly configured otherwise.

Which is indeed getting pretty close to plain SHOULD, but perhaps is a
bit clearer on the intent.

> I'd also recommend a new, separate document, possibly in DNSOP, to put 
> forth the requirements about handling 169.254. Of course these requirements 
> will be as well implemented and deployed as those in RFC1918, but it's 
> worth documenting them nonetheless.

Yep, several folks have suggested that we need such a doc.  These
addreses, RFC 1918 addresses, the recent IPv6 ULA stuff, ....

I have it on good authority that at least one of the DNSOP WG chairs
would be sympathetic to such a document were it to appear.

---

From: Daniel Senie <[email-masked]>
Date: Sun, 03 Apr 2005 16:37:35 -0400

>choice, and who am I to tell them how to spend their resources?

With SHOULD, we're still giving them the option, I think. We're just giving 
a bit stronger guidance as to the preferred way of operating.

>what's going on in a packet trace if no response comes back.

Which clients? I think this is the root cause of my concern. If you're 
talking about zeroconf clients, I agree. But 169.254/16 has, until a few 
years ago, just been another block of addresses in the address space. It's 
entirely possible to have any random machine ask for information on 
169.254.x.x. If that machine isn't zeroconf aware, for example because it's 
some embedded system or older router or whatever, why are we deciding to 
change the world and give it the silent treatment? This is what makes no 
sense to me.

>bit clearer on the intent.

That could work. It's similar in ways to some things in RFC 1812, where we 
specified the options and recommended the default (note for example 
directed broadcasts, though we had to change the default on that one in RFC 
2644).

>would be sympathetic to such a document were it to appear.

I'd be willing to co-author such if there's interest from one or more other 
parties.

---

From: Rob Austein <[email-masked]>
Date: Sun, 03 Apr 2005 17:07:33 -0400

> a bit stronger guidance as to the preferred way of operating.

Yep, assuming we can achieve consensus on that preference.

> change the world and give it the silent treatment? This is what makes no 

Good point.

> directed broadcasts, though we had to change the default on that one in RFC 

Yep.

Odd that you should mention RFC 1812's directed broadcast misfeature,
that being one of the few times I can remember shipping product code
that deliberately violated the spec.  We (not ISC, this was a long
time ago at a company far far away) put directed broadcast under a
compile time option that would enable spec compliance, and documented
it thusly: "We don't care what the IETF says, directed broadcast is a
disaster waiting to happen and we could not in good conscience ship
code to our customers with this misfeature enabled, so we added this
option to enable full compliance with the spec and satisfy our
contractual obligations.  Do not enable this option in production code
under any circumstances.  You have been warned."

But I digress.

> > > I'd also recommend a new, separate document, possibly in DNSOP,
> > > to put forth the requirements about handling 169.254. Of course
> > > these requirements will be as well implemented and deployed as
> > > those in RFC1918, but it's worth documenting them nonetheless.
> >
> I'd be willing to co-author such if there's interest from one or
> more other parties.

Cool.