From owner-zeroconf@merit.edu Sun Apr 3 16:03:51 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23106 for ; Sun, 3 Apr 2005 16:03:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 54CD79123E; Sun, 3 Apr 2005 16:01:03 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 207689123F; Sun, 3 Apr 2005 16:01:03 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 084449123E for ; Sun, 3 Apr 2005 16:01:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E79CC5828D; Sun, 3 Apr 2005 16:01:01 -0400 (EDT) Delivered-To: zeroconf@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id A15E258282 for ; Sun, 3 Apr 2005 16:01:01 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id A6DE41869; Sun, 3 Apr 2005 16:01:01 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from cyteen.hactrn.net (cyteen.hactrn.net [66.92.66.68]) by testbed9.merit.edu (Postfix) with ESMTP id 5E5E71861 for ; Sun, 3 Apr 2005 16:01:01 -0400 (EDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:250:daff:fe82:1c39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id 324BC11F for ; Sun, 3 Apr 2005 16:01:00 -0400 (EDT) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 7701741EA for ; Sun, 3 Apr 2005 16:00:59 -0400 (EDT) Date: Sun, 03 Apr 2005 16:00:59 -0400 From: Rob Austein To: zeroconf@merit.edu Subject: Re: Issue: PTR RR queries for 254.169.in-addr.arpa In-Reply-To: <6.2.1.2.2.20050329203224.0539ddf8@mail.amaranth.net> References: <200503290405.j2T45BUK025185@relay1.apple.com> <20050329182916.38A0941EA@thrintun.hactrn.net> <6.2.1.2.2.20050329203224.0539ddf8@mail.amaranth.net> MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20050403200059.7701741EA@thrintun.hactrn.net> Sender: owner-zeroconf@merit.edu Precedence: bulk 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 owner-zeroconf@merit.edu Sun Apr 3 16:42:46 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25181 for ; Sun, 3 Apr 2005 16:42:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9E9F39123F; Sun, 3 Apr 2005 16:42:42 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6E4CC91242; Sun, 3 Apr 2005 16:42:42 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 666A19123F for ; Sun, 3 Apr 2005 16:42:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 525715829A; Sun, 3 Apr 2005 16:42:41 -0400 (EDT) Delivered-To: zeroconf@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id 0B50958282 for ; Sun, 3 Apr 2005 16:42:41 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id 0ED7A1869; Sun, 3 Apr 2005 16:42:41 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from parsley.amaranth.net (parsley.amaranth.net [204.10.1.23]) by testbed9.merit.edu (Postfix) with ESMTP id E7BE81861 for ; Sun, 3 Apr 2005 16:42:40 -0400 (EDT) Received: from ancho.senie.com (c-24-34-19-2.hsd1.ma.comcast.net [24.34.19.2]) (authenticated bits=0) by parsley.amaranth.net (8.12.11/8.12.11) with ESMTP id j33KgY5p031100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Apr 2005 16:42:37 -0400 Message-Id: <6.2.1.2.2.20050403163201.03db71e8@mail.amaranth.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sun, 03 Apr 2005 16:37:35 -0400 To: Rob Austein , zeroconf@merit.edu From: Daniel Senie Subject: Re: Issue: PTR RR queries for 254.169.in-addr.arpa In-Reply-To: <20050403200059.7701741EA@thrintun.hactrn.net> References: <200503290405.j2T45BUK025185@relay1.apple.com> <20050329182916.38A0941EA@thrintun.hactrn.net> <6.2.1.2.2.20050329203224.0539ddf8@mail.amaranth.net> <20050403200059.7701741EA@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: ClamAV 0.83/804/Mon Apr 4 10:38:58 2005 on parsley.amaranth.net X-Virus-Status: Clean Sender: owner-zeroconf@merit.edu Precedence: bulk At 04:00 PM 4/3/2005, Rob Austein wrote: >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? 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. >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. 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. >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. 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). > > 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. From owner-zeroconf@merit.edu Sun Apr 3 17:07:40 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26508 for ; Sun, 3 Apr 2005 17:07:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E3E0B91242; Sun, 3 Apr 2005 17:07:37 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A93A891261; Sun, 3 Apr 2005 17:07:37 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 913FC91242 for ; Sun, 3 Apr 2005 17:07:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 78DFA5829A; Sun, 3 Apr 2005 17:07:36 -0400 (EDT) Delivered-To: zeroconf@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id 32B0D5828D for ; Sun, 3 Apr 2005 17:07:36 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id 381121869; Sun, 3 Apr 2005 17:07:36 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from cyteen.hactrn.net (cyteen.hactrn.net [66.92.66.68]) by testbed9.merit.edu (Postfix) with ESMTP id CE0FC1861 for ; Sun, 3 Apr 2005 17:07:35 -0400 (EDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:250:daff:fe82:1c39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id 7EEFA11F for ; Sun, 3 Apr 2005 17:07:34 -0400 (EDT) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id CC7C441EA for ; Sun, 3 Apr 2005 17:07:33 -0400 (EDT) Date: Sun, 03 Apr 2005 17:07:33 -0400 From: Rob Austein To: zeroconf@merit.edu Subject: Re: Issue: PTR RR queries for 254.169.in-addr.arpa In-Reply-To: <6.2.1.2.2.20050403163201.03db71e8@mail.amaranth.net> References: <200503290405.j2T45BUK025185@relay1.apple.com> <20050329182916.38A0941EA@thrintun.hactrn.net> <6.2.1.2.2.20050329203224.0539ddf8@mail.amaranth.net> <20050403200059.7701741EA@thrintun.hactrn.net> <6.2.1.2.2.20050403163201.03db71e8@mail.amaranth.net> MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20050403210733.CC7C441EA@thrintun.hactrn.net> Sender: owner-zeroconf@merit.edu Precedence: bulk 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.