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

At Sun, 03 Apr 2005 16:37:35 -0400, Daniel Senie wrote:
> At 04:00 PM 4/3/2005, Rob Austein wrote:
> 
> 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.

Yep, assuming we can achieve consensus on that preference.

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

Good point.

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

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.
> >
> >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.
> 
> I'd be willing to co-author such if there's interest from one or
> more other parties.

Cool.