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. From momar1955@hotmail.com Tue Apr 19 14:35:00 2005 Received: from mxcson215.com ([196.200.95.108]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06308 for ; Tue, 19 Apr 2005 14:34:59 -0400 (EDT) Message-Id: <200504191834.OAA06308@ietf.org> From: "Musa OMAR" Reply-To: momar1955@yahoo.com Date: Tue, 19 Apr 2005 18:35:10 +0000 Subject: URGENT RESPONS REQUIRED. X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sir=2C I am Dr=2E Musa OMAR=2C Project director Senegal National Petroleum Corporation =28SNPC=29 and a member of Contract Tenders Board of the same parastatals=2E Your contact was reliably introduced to me at the Foreign chamber of commerce and industry in my search for a reliable individual and=2For company who can handle a strictly confidential transaction=2Cwhichinvolves Transfer of reasonable sum of money to a foreign account=2E This money results from various contracts awarded by our corporation on behalf of the Federal Government=2C which was deliberately over invoiced tothe tune of $15=2E500=2E000=2E00 =28Fifteen Million Five Hundred Thousand United States dollars=29=2E After the completion and commissioning of the contract=2C the contractual sum was paid to the contractors=2C leaving the over invoiced sum in the reserve account with the Pacific Bank Plc=2E We therefore requirethe partnership of a foreigner or foreign firm to assist us in form of a trustee and provide an account for this transfer=2E In my last meeting with my colleagues=2C it was unanimously agreed that 25% of the total sum would be given to you=2E 70% for me and my colleagues=2Cwhile 5% will be used to reimburse the expenses that may be incurred during the course of this transaction I assure you that his transaction is 100% risk free as we have concluded every arrangement to protect the interest of everyone involved=2ELikewise all modalities for the successful transfer of this money have been worked out with the Finance Ministry to facilitate the remittance of this money to your designated bank account=2E However=2C I will want to believe that you are honest enough and will not raise any misgiving with respect to this transaction=2E More importantly=2Cyou will keep this transaction very confidential so as not to jeopardize this once in a lifetime ambition Finally if this business is of interest to you=2C then kindly contact me via email address herein =2EYour immediate response will be highly appreciated Best regards=2C Dr =2EMusa OMAR=2E From owner-zeroconf@merit.edu Thu Apr 21 05:05:00 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 FAA08059 for ; Thu, 21 Apr 2005 05:05:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D51FB91248; Thu, 21 Apr 2005 05:04:59 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9C90191338; Thu, 21 Apr 2005 05:04:59 -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 7E69E91248 for ; Thu, 21 Apr 2005 05:04:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 62E9D5829C; Thu, 21 Apr 2005 05:04:58 -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 4DD6958280 for ; Thu, 21 Apr 2005 05:04:58 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id 34DE1188C; Thu, 21 Apr 2005 05:04:58 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) by testbed9.merit.edu (Postfix) with ESMTP id 2561E1877 for ; Thu, 21 Apr 2005 05:04:58 -0400 (EDT) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.44) id 1DOXcH-000O38-Hz for zeroconf@merit.edu; Thu, 21 Apr 2005 05:04:57 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j3L94u126780 for ; Thu, 21 Apr 2005 02:04:56 -0700 Date: Thu, 21 Apr 2005 02:04:55 -0700 (PDT) From: Bernard Aboba To: zeroconf@merit.edu Subject: Are we done? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Sender: owner-zeroconf@merit.edu Precedence: bulk In looking at the mailing list postings, there are several signs of an emerging consensus, including cessation of discussion, some level of agreement on various points, attempts at compromise, etc. However, I don't yet see proposed text that pulls all the various issues together. Can those people who believe there is consensus on at least some points please state where you think we are and put forward some text that describes this. This document has been in the IETF for a very long time, and I know we are all exhausted. But we are only a few steps from the finish line, so it's time to summon that last ounce of energy... From owner-zeroconf@merit.edu Sat Apr 23 00:15:21 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 AAA03064 for ; Sat, 23 Apr 2005 00:15:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A3A30912D9; Sat, 23 Apr 2005 00:14:48 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 70B6D912DE; Sat, 23 Apr 2005 00:14:48 -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 A1454912D9 for ; Sat, 23 Apr 2005 00:14:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7DF4B58289; Sat, 23 Apr 2005 00:14:45 -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 66CA158283 for ; Sat, 23 Apr 2005 00:14:45 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id 4D19F1894; Sat, 23 Apr 2005 00:14:45 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) by testbed9.merit.edu (Postfix) with ESMTP id 3DF34185C for ; Sat, 23 Apr 2005 00:14:45 -0400 (EDT) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.44) id 1DPC2W-000JVL-JG for zeroconf@merit.edu; Sat, 23 Apr 2005 00:14:44 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j3N4Eh724638 for ; Fri, 22 Apr 2005 21:14:43 -0700 Date: Fri, 22 Apr 2005 21:14:42 -0700 (PDT) From: Bernard Aboba To: zeroconf@merit.edu Subject: Proposed resolution: PTR queries for 254.169.in-addr.arpa Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Sender: owner-zeroconf@merit.edu Precedence: bulk Here is a proposed resolution to the Issue: "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. DNS clients MUST NOT send unicast DNS queries for any name that falls within the "254.169.in-addr.arpa." domain. 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. 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." From owner-zeroconf@merit.edu Sat Apr 23 02:06:03 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 CAA14388 for ; Sat, 23 Apr 2005 02:06:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 041F9912C8; Sat, 23 Apr 2005 02:05:57 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C3530912C9; Sat, 23 Apr 2005 02:05:56 -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 D6494912C8 for ; Sat, 23 Apr 2005 02:05:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BCAB458299; Sat, 23 Apr 2005 02:05:55 -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 A2B0E58297 for ; Sat, 23 Apr 2005 02:05:55 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id 8884D1881; Sat, 23 Apr 2005 02:05:55 -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 6C474185C for ; Sat, 23 Apr 2005 02:05:55 -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 j3N65oMC029238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 Apr 2005 02:05:51 -0400 Message-Id: <6.2.1.2.2.20050423020342.04bf8958@mail.amaranth.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sat, 23 Apr 2005 02:05:30 -0400 To: Bernard Aboba , zeroconf@merit.edu From: Daniel Senie Subject: Re: Proposed resolution: PTR queries for 254.169.in-addr.arpa Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: ClamAV 0.83/849/Fri Apr 22 11:52:53 2005 on parsley.amaranth.net X-Virus-Status: Clean Sender: owner-zeroconf@merit.edu Precedence: bulk This looks fine. I'm in favor of accepting this wording, and putting this document to bed. At 12:14 AM 4/23/2005, you wrote: >Here is a proposed resolution to the Issue: > >"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. >DNS clients MUST NOT send unicast DNS queries for any name that >falls within the "254.169.in-addr.arpa." domain. > >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. > >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." From owner-zeroconf@merit.edu Sun Apr 24 14:18:54 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 OAA09401 for ; Sun, 24 Apr 2005 14:18:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 34AB891249; Sun, 24 Apr 2005 14:17:05 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0029F91275; Sun, 24 Apr 2005 14:17:04 -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 089C391249 for ; Sun, 24 Apr 2005 14:17:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ECB0F5828A; Sun, 24 Apr 2005 14:17:03 -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 D65CC58287 for ; Sun, 24 Apr 2005 14:17:03 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id BC6C21853; Sun, 24 Apr 2005 14:17:03 -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 86DE1180C for ; Sun, 24 Apr 2005 14:17:03 -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 41C71732 for ; Sun, 24 Apr 2005 14:17:02 -0400 (EDT) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 8E7CE41EA for ; Sun, 24 Apr 2005 14:17:01 -0400 (EDT) Date: Sun, 24 Apr 2005 14:17:01 -0400 From: Rob Austein To: zeroconf@merit.edu Subject: Re: Proposed resolution: PTR queries for 254.169.in-addr.arpa In-Reply-To: References: MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20050424181701.8E7CE41EA@thrintun.hactrn.net> Sender: owner-zeroconf@merit.edu Precedence: bulk At Fri, 22 Apr 2005 21:14:42 -0700 (PDT), Bernard Aboba wrote: > > Here is a proposed resolution to the Issue: > > "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. > DNS clients MUST NOT send unicast DNS queries for any name that > falls within the "254.169.in-addr.arpa." domain. > > 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. > > 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. Er, s/SHOULD/MUST/ here. Hard wiring this into a recursive name server with no way to override it is probably not wise. > 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." Other than the above, this seems ok. From owner-zeroconf@merit.edu Sun Apr 24 17:18: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 RAA23238 for ; Sun, 24 Apr 2005 17:18:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 893719126F; Sun, 24 Apr 2005 17:17:10 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 509A291275; Sun, 24 Apr 2005 17:17:10 -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 48CCA9126F for ; Sun, 24 Apr 2005 17:17:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3108258287; Sun, 24 Apr 2005 17:17:09 -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 1A17458281 for ; Sun, 24 Apr 2005 17:17:09 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id F3F72186B; Sun, 24 Apr 2005 17:17:09 -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 DB02D1853 for ; Sun, 24 Apr 2005 17:17:08 -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 j3OLH4i1026968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 24 Apr 2005 17:17:05 -0400 Message-Id: <6.2.1.2.2.20050424171219.04a61f30@mail.amaranth.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sun, 24 Apr 2005 17:16:59 -0400 To: Rob Austein , zeroconf@merit.edu From: Daniel Senie Subject: Re: Proposed resolution: PTR queries for 254.169.in-addr.arpa In-Reply-To: <20050424181701.8E7CE41EA@thrintun.hactrn.net> References: <20050424181701.8E7CE41EA@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: ClamAV 0.83/850/Sun Apr 24 00:08:28 2005 on parsley.amaranth.net X-Virus-Status: Clean Sender: owner-zeroconf@merit.edu Precedence: bulk At 02:17 PM 4/24/2005, Rob Austein wrote: >At Fri, 22 Apr 2005 21:14:42 -0700 (PDT), Bernard Aboba wrote: > > > > Here is a proposed resolution to the Issue: > > > > "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. > > DNS clients MUST NOT send unicast DNS queries for any name that > > falls within the "254.169.in-addr.arpa." domain. > > > > 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. > > > > 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. > >Er, s/SHOULD/MUST/ here. Hard wiring this into a recursive name >server with no way to override it is probably not wise. Since the text said "configured to act" not "hard programmed to act" I took this to mean the default configuration file supplied with the name server implementation had it set that way, vs. programmed in as a default response. To my thinking, a default config file shipping with the DNS server software that claims to be authoritative for 169.254/16 would meet the text above. The user is free to remove or change that default configuration. Indeed, the fact that the text talks about this as a default condition seems to imply the ability to change it. Long way of saying that, at least to my reading, "hard wiring" was not implied, even with the SHOULD present. That said, if the text changed to "Implementations MUST allow this default to be overridden" I would still approve of the document. > > 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." > >Other than the above, this seems ok. From owner-zeroconf@merit.edu Mon Apr 25 04:23:30 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 EAA23994 for ; Mon, 25 Apr 2005 04:23:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 977BD91273; Mon, 25 Apr 2005 04:23:27 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 58C0C9126C; Mon, 25 Apr 2005 04:23:27 -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 3931091273 for ; Mon, 25 Apr 2005 04:23:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1E9A158285; Mon, 25 Apr 2005 04:23:25 -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 C5F1858281 for ; Mon, 25 Apr 2005 04:23:24 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id A38E01867; Mon, 25 Apr 2005 04:23:24 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by testbed9.merit.edu (Postfix) with ESMTP id 5937C180C for ; Mon, 25 Apr 2005 04:23:23 -0400 (EDT) Received: from phys-mayi-2 ([129.157.128.115]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j3P8N7iF027477 for ; Mon, 25 Apr 2005 02:23:22 -0600 (MDT) Received: from conversion-daemon.mayi-mail1.germany.sun.com by mayi-mail1.germany.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IFH00G01TXXCK@mayi-mail1.germany.sun.com> (original mail from Erik.Guttman@Sun.COM) for zeroconf@merit.edu; Mon, 25 Apr 2005 10:23:11 +0200 (MEST) Received: from [217.88.232.218] (vpn-129-150-112-184.Holland.Sun.COM [129.150.112.184]) by mayi-mail1.germany.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0IFH00472TYKGE@mayi-mail1.germany.sun.com>; Mon, 25 Apr 2005 10:23:11 +0200 (MEST) Date: Mon, 25 Apr 2005 10:23:07 +0200 From: Erik Guttman Subject: Re: Proposed resolution: PTR queries for 254.169.in-addr.arpa In-reply-to: <6.2.1.2.2.20050424171219.04a61f30@mail.amaranth.net> To: Daniel Senie Cc: Rob Austein , zeroconf@merit.edu, Margaret Wasserman , Thomas Narten , Mark Townsley Message-id: <426CA8EB.2050401@sun.com> Organization: Sun Microsystems - N1 Architecture & Strategy MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_ipR+FRpu4pjXHUo6CVyn+w)" X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) References: <20050424181701.8E7CE41EA@thrintun.hactrn.net> <6.2.1.2.2.20050424171219.04a61f30@mail.amaranth.net> Sender: owner-zeroconf@merit.edu Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_ipR+FRpu4pjXHUo6CVyn+w) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7BIT Folks, [This page should be viewed as HTML, sorry if this inconveniences you!] I support the text proposed by Bernard with the changes by Rob. - - - Let's see if we have closure on all items. Going back over the email sent in the past weeks, I believe the points made are the following. If I have left anything out or misrepresented the dialog, please reply with a revised version of the table. If anyone has any concern with the final suggested resolution (24 Apr 05), please send email to the list by next Monday, May 1. *Date * *Who * *Problem * *Suggested Resolution * 05 Oct 04 RFC Editor Starts 48 hour last call on RFC 3927 06 Oct 04 Stuart Cheshire Several changes requested. 03 Mar 05 Authors, RFC Editor, post-WG The requested changes were reviewed and the resolution was agreed to by all parties. 15 Mar 05 Margaret Wasserman Concern was raised due to related work in the IPv6 WG related to reverse lookup of local addresses. Bernard suggested a straw man resolution: Here is a strawman: This text will be added to a new 'DNS Server Considerations' section: "Reverse (address-to-name) queries for IPv4 Link-Local addresses MUST NOT be sent to name servers for the global DNS. The recommended way to avoid sending such queries to nameservers for the global DNS is for recursive name server implementations 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 that choose this strategy should allow it to be overridden, but returning an RCODE 3 response for such queries should be the default, both because this will reduce the query load problem and 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." 24 Mar 05 Stuart Cheshire Counter proposal: The DNS experts are the one who have alerted us to the issue. While I >agree there is probably room for debate as to "how big a problem this >really is in practice", I doubt any one will argue that PTR queries >for these addresses should be forwarded off link. Seems a no-brainer >to just state that in the document. That is all that is being asked. At the high level I agree that there is no point sending these PTR queries off-link. Where I disagree is in the details, particularly in caching servers returning authoritative NXDomain answers. This is what I propose, and would support in the document: 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. DNS clients MUST NOT send unicast DNS queries for any name that falls within the "254.169.in-addr.arpa." domain. DNS caching servers receiving queries from non-compliant clients for names within the "254.169.in-addr.arpa." domain MUST silently ignore them. A caching server MUST NOT attempt to complete such queries on behalf of the client, and MUST NOT send any DNS response back to the client. This leads to debate that has not yet been resolved. The individual problems and attempted resolutions are summarized below. The point of debate is whether recursive DNS servers MUST silently drop queries for reverse lookup of LL addressses or whether they should return error code 3. Stuart suggests that servers silently drop requests. Thomas and Dan suggest that returning an error would help with diagnosing failure conditions at the client and reduce time outs. 27 Mar 05 Rob Austein Stuart Cheshire wrote: > The ONLY DIFFERENCE between what I'm saying here and what you're saying > is that I want the recursive name servers to provide this defense in a > form that encourages end-system devices to be fixed to not issue the > queries in the first place, rather than a form that encourages end-system > devices to continue with the bad behaviour forever. Rob Austein replied: It was not at all clear to me from the earlier exchange that this was the only point on which we disagreed, but if so, I'm glad to hear it. We should probably take this one point to the zeroconf list, since Bernard has started the discussion there, but, in brief, I see two issues here: a) Whether silently dropping bogons is more likely to cause buggy clients to upgrade than supplying RCODE 3 answers. This is not obvious to me. I would think that users would be about as likely to figure out that something's broken from being told that names don't exist as they would from having queries time out, but I'll stipulate that this is a matter of opinion on which reasonable people might disagree in the absence of empirical data. b) *Which solution is easier on the recursive name servers. This is slightly more complex than it might seem at first, since presumably if there were a clear answer to (a) that caused buggy clients to upgrade, that would be the right long term answer. As a short term answer, however, and in the absence of a clear answer to (a), sending RCODE 3 responses will cause the buggy clients to shut up and go away more quickly. As a result, I'm pretty sure that this is the path ISPs will choose regardless of what we tell them unless we give them a really good reason why they should do otherwise. Given my opinions on (a), I don't believe that such a reason exists, but if one does, best make it blindingly obvious.* 23Apr 05 Bernard Aboba This text will be added to a new 'DNS Server Considerations' section: "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. DNS clients MUST NOT send unicast DNS queries for any name that falls within the "254.169.in-addr.arpa." domain. 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. 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." 24 Apr 05 Rob Austein Er, s/SHOULD/MUST/ here. Hard wiring this into a recursive name server with no way to override it is probably not wise. The revised proposal is below, with the changes in bold face: This text will be added to a new 'DNS Server Considerations' section: "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. DNS clients MUST NOT send unicast DNS queries for any name that falls within the "254.169.in-addr.arpa." domain. 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. By default, recursive name server implementations *MUST* 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 *MUST* 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." Best regards, Erik ._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._. E r i k G u t t m a n - Sun Microsystems - cell: +49 162 790 1116 --Boundary_(ID_ipR+FRpu4pjXHUo6CVyn+w) Content-type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7BIT Folks,

[This page should be viewed as HTML, sorry if this inconveniences you!]

I support the text proposed by Bernard with the changes by Rob.

- - -

Let's see if we have closure on all items.  Going back over the email sent in the past weeks, I believe the points made are the following.  If I have left anything out or misrepresented the dialog, please reply with a revised version of the table.

If anyone has any concern with the final suggested resolution (24 Apr 05), please send email to the list by next Monday, May 1.

Date
 Who
 Problem
 Suggested Resolution
05 Oct 04
 RFC Editor
 Starts 48 hour last call on RFC 3927

06 Oct 04
 Stuart Cheshire
 Several changes requested.
03 Mar 05
 Authors, RFC Editor, post-WG
The requested changes were reviewed and the resolution was agreed to by all parties.
15 Mar 05
 Margaret Wasserman
 Concern was raised due to related work in the IPv6 WG related to reverse lookup of local addresses.
 Bernard suggested a straw man resolution:

Here is a strawman:

This text will be added to a new 'DNS Server Considerations' section:

"Reverse (address-to-name) queries for IPv4 Link-Local
addresses MUST NOT be sent to name servers for the global DNS.
The recommended way to avoid sending such queries to nameservers for
the global DNS is for recursive name server implementations 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 that choose this
strategy should allow it to be overridden, but returning an RCODE 3
response for such queries should be the default, both because this
will reduce the query load problem and 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."
24 Mar 05
 Stuart Cheshire
 Counter proposal:

The DNS experts are the one who have alerted us to the issue. While I
>agree there is probably room for debate as to "how big a problem this
>really is in practice", I doubt any one will argue that PTR queries
>for these addresses should be forwarded off link. Seems a no-brainer
>to just state that in the document. That is all that is being asked.
      

At the high level I agree that there is no point sending these PTR 
queries off-link. Where I disagree is in the details, particularly in 
caching servers returning authoritative NXDomain answers.

This is what I propose, and would support in the document:

   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.

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

   DNS caching servers receiving queries from non-compliant clients
   for names within the "254.169.in-addr.arpa." domain MUST silently
   ignore them. A caching server MUST NOT attempt to complete such
   queries on behalf of the client, and MUST NOT send any DNS
   response back to the client.

 This leads to debate that has not yet been
resolved.   The individual problems and
attempted resolutions are summarized
below.

The point of debate is whether recursive
DNS servers MUST silently drop queries
for reverse lookup of LL addressses
or whether they should return error code 3.

Stuart suggests that servers silently drop
requests.  Thomas and Dan suggest that
returning an error would help with
diagnosing failure conditions at the client
and reduce time outs.
27 Mar 05
 Rob Austein
 
Stuart Cheshire wrote:
> The ONLY DIFFERENCE between what I'm saying here and what you're saying 
> is that I want the recursive name servers to provide this defense in a 
> form that encourages end-system devices to be fixed to not issue the 
> queries in the first place, rather than a form that encourages end-system 
> devices to continue with the bad behaviour forever.
      
Rob Austein replied:

It was not at all clear to me from the earlier exchange that this was
the only point on which we disagreed, but if so, I'm glad to hear it.

We should probably take this one point to the zeroconf list, since
Bernard has started the discussion there, but, in brief, I see two
issues here:

a) Whether silently dropping bogons is more likely to cause buggy
   clients to upgrade than supplying RCODE 3 answers.  This is not
   obvious to me.  I would think that users would be about as likely
   to figure out that something's broken from being told that names
   don't exist as they would from having queries time out, but I'll
   stipulate that this is a matter of opinion on which reasonable
   people might disagree in the absence of empirical data.

b) Which solution is easier on the recursive name servers.  This is
   slightly more complex than it might seem at first, since presumably
   if there were a clear answer to (a) that caused buggy clients to
   upgrade, that would be the right long term answer.  As a short term
   answer, however, and in the absence of a clear answer to (a),
   sending RCODE 3 responses will cause the buggy clients to shut up
   and go away more quickly.  As a result, I'm pretty sure that this
   is the path ISPs will choose regardless of what we tell them unless
   we give them a really good reason why they should do otherwise.
   Given my opinions on (a), I don't believe that such a reason
   exists, but if one does, best make it blindingly obvious.

23Apr 05
 Bernard Aboba
 
This text will be added to a new 'DNS Server Considerations' section:

"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.
DNS clients MUST NOT send unicast DNS queries for any name that
falls within the "254.169.in-addr.arpa." domain.

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.

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."
24 Apr 05
 Rob Austein
 
Er, s/SHOULD/MUST/ here.  Hard wiring this into a recursive name
server with no way to override it is probably not wise.

The revised proposal is below, with the changes in bold face:

This text will be added to a new 'DNS Server Considerations' section:

"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.
DNS clients MUST NOT send unicast DNS queries for any name that
falls within the "254.169.in-addr.arpa." domain.

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.

By default, recursive name server implementations MUST 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 MUST 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."



Best regards,

Erik
._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._.
 E r i k   G u t t m a n   - Sun Microsystems -   cell: +49 162 790 1116
--Boundary_(ID_ipR+FRpu4pjXHUo6CVyn+w)-- From owner-zeroconf@merit.edu Mon Apr 25 05: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 FAA26723 for ; Mon, 25 Apr 2005 05:03:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3191E91277; Mon, 25 Apr 2005 05:01:51 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AB86791278; Mon, 25 Apr 2005 05:01:50 -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 1E5A09126C for ; Mon, 25 Apr 2005 05:01:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0D91658285; Mon, 25 Apr 2005 05:01:49 -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 E9B5758281 for ; Mon, 25 Apr 2005 05:01:48 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id CC9751867; Mon, 25 Apr 2005 05:01:48 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by testbed9.merit.edu (Postfix) with ESMTP id 8BBBF180C for ; Mon, 25 Apr 2005 05:01:48 -0400 (EDT) Received: from phys-mayi-2 ([129.157.128.115]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j3P91jjS006964 for ; Mon, 25 Apr 2005 03:01:46 -0600 (MDT) Received: from conversion-daemon.mayi-mail1.germany.sun.com by mayi-mail1.germany.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IFH00D01VJGYS@mayi-mail1.germany.sun.com> (original mail from Erik.Guttman@Sun.COM) for zeroconf@merit.edu; Mon, 25 Apr 2005 11:00:29 +0200 (MEST) Received: from [217.88.232.218] (vpn-129-150-112-184.Holland.Sun.COM [129.150.112.184]) by mayi-mail1.germany.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0IFH004P6VORGE@mayi-mail1.germany.sun.com>; Mon, 25 Apr 2005 11:00:29 +0200 (MEST) Date: Mon, 25 Apr 2005 11:00:26 +0200 From: Erik Guttman Subject: Re: Proposed resolution: PTR queries for 254.169.in-addr.arpa In-reply-to: <426CA8EB.2050401@sun.com> To: Erik Guttman Cc: Daniel Senie , Rob Austein , zeroconf@merit.edu, Margaret Wasserman , Thomas Narten , Mark Townsley Message-id: <426CB1AA.2090009@sun.com> Organization: Sun Microsystems - N1 Architecture & Strategy MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_MkazUNJouYmflY3OB6i4/w)" X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) References: <20050424181701.8E7CE41EA@thrintun.hactrn.net> <6.2.1.2.2.20050424171219.04a61f30@mail.amaranth.net> <426CA8EB.2050401@sun.com> Sender: owner-zeroconf@merit.edu Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_MkazUNJouYmflY3OB6i4/w) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7BIT Erik Guttman wrote: > If anyone has any concern with the final suggested resolution (24 Apr > 05), please send email to the list by next Monday, May 1. Heh - I meant Monday, May 2, 2005. For old time's sake, let's consider this a one week last call with the default decision being ACCEPT. Best regards to y'all, Erik --Boundary_(ID_MkazUNJouYmflY3OB6i4/w) Content-type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7BIT Erik Guttman wrote:
If anyone has any concern with the final suggested resolution (24 Apr 05), please send email to the list by next Monday, May 1.
Heh - I meant Monday, May 2, 2005. 

For old time's sake, let's consider this a one week last call with the default decision being ACCEPT.

Best regards to y'all,

Erik

--Boundary_(ID_MkazUNJouYmflY3OB6i4/w)-- From owner-zeroconf@merit.edu Mon Apr 25 09:55:32 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 JAA16682 for ; Mon, 25 Apr 2005 09:55:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5FA6491203; Mon, 25 Apr 2005 09:55:29 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2729F91279; Mon, 25 Apr 2005 09:55:29 -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 0F0B991203 for ; Mon, 25 Apr 2005 09:55:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E917258288; Mon, 25 Apr 2005 09:55:27 -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 CF94458287 for ; Mon, 25 Apr 2005 09:55:27 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id B61E11874; Mon, 25 Apr 2005 09:55:27 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by testbed9.merit.edu (Postfix) with ESMTP id 877DD1801 for ; Mon, 25 Apr 2005 09:55:27 -0400 (EDT) Received: from phys-mayi-2 ([129.157.128.115]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j3PDtQjO001907 for ; Mon, 25 Apr 2005 07:55:26 -0600 (MDT) Received: from conversion-daemon.mayi-mail1.germany.sun.com by mayi-mail1.germany.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IFI00L019AFB8@mayi-mail1.germany.sun.com> (original mail from Erik.Guttman@Sun.COM) for zeroconf@merit.edu; Mon, 25 Apr 2005 15:55:25 +0200 (MEST) Received: from [217.88.232.218] (vpn-129-150-112-209.Holland.Sun.COM [129.150.112.209]) by mayi-mail1.germany.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0IFI00BBK9CCJ0@mayi-mail1.germany.sun.com> for zeroconf@merit.edu; Mon, 25 Apr 2005 15:55:25 +0200 (MEST) Date: Mon, 25 Apr 2005 15:55:23 +0200 From: Erik Guttman Subject: [Fwd: Re: Proposed resolution: PTR queries for 254.169.in-addr.arpa] To: zeroconf@merit.edu Message-id: <426CF6CB.1040906@sun.com> Organization: Sun Microsystems - N1 Architecture & Strategy MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_UZaBClbGEOL6R8X6vwFCag)" X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) Sender: owner-zeroconf@merit.edu Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_UZaBClbGEOL6R8X6vwFCag) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7BIT Forwarded for Eric Hall. -------- Original Message -------- Subject: Re: Proposed resolution: PTR queries for 254.169.in-addr.arpa Date: Mon, 25 Apr 2005 09:44:26 -0400 From: Eric A. Hall To: Erik Guttman CC: Daniel Senie , Rob Austein , zeroconf@merit.edu, Margaret Wasserman , Thomas Narten , Mark Townsley References: <20050424181701.8E7CE41EA@thrintun.hactrn.net> <6.2.1.2.2.20050424171219.04a61f30@mail.amaranth.net> <426CA8EB.2050401@sun.com> > By default, recursive name server implementations *MUST* 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 *MUST* 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." My posts aren't getting on the list and I haven't figured out why yet, but anyway I have said three times now that silently dropping queries is unacceptable behavior. Clients will treat such a signal as time-out error, and will simply move on to ask another server. Eventually they will find one that doesn't know about this rule, and the queries will escape. It is very bad mojo to silently drop DNS lookups. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ --Boundary_(ID_UZaBClbGEOL6R8X6vwFCag) Content-type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7BIT Forwarded for Eric Hall.

-------- Original Message --------
Subject: Re: Proposed resolution: PTR queries for 254.169.in-addr.arpa
Date: Mon, 25 Apr 2005 09:44:26 -0400
From: Eric A. Hall <ehall@ehsco.com>
To: Erik Guttman <Erik.Guttman@Sun.COM>
CC: Daniel Senie <dts@senie.com>, Rob Austein <sra+zeroconf@hactrn.net>, zeroconf@merit.edu, Margaret Wasserman <margaret@thingmagic.com>, Thomas Narten <narten@us.ibm.com>, Mark Townsley <townsley@cisco.com>
References: <Pine.LNX.4.56.0504222112350.23401@internaut.com> <20050424181701.8E7CE41EA@thrintun.hactrn.net> <6.2.1.2.2.20050424171219.04a61f30@mail.amaranth.net> <426CA8EB.2050401@sun.com> 


> By default, recursive name server implementations *MUST* 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 *MUST* 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."

My posts aren't getting on the list and I haven't figured out why yet, but
anyway I have said three times now that silently dropping queries is
unacceptable behavior. Clients will treat such a signal as time-out error,
and will simply move on to ask another server. Eventually they will find
one that doesn't know about this rule, and the queries will escape.

It is very bad mojo to silently drop DNS lookups.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

--Boundary_(ID_UZaBClbGEOL6R8X6vwFCag)-- From owner-zeroconf@merit.edu Fri Apr 29 10:39:17 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 KAA01874 for ; Fri, 29 Apr 2005 10:39:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4F03D9137F; Fri, 29 Apr 2005 10:39:14 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 17C8E91381; Fri, 29 Apr 2005 10:39:14 -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 0EA2E9137F for ; Fri, 29 Apr 2005 10:39:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F18C558284; Fri, 29 Apr 2005 10:39:12 -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 D73C458281 for ; Fri, 29 Apr 2005 10:39:12 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id BC7211869; Fri, 29 Apr 2005 10:39:12 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by testbed9.merit.edu (Postfix) with ESMTP id 7F662185B for ; Fri, 29 Apr 2005 10:39:12 -0400 (EDT) Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id j3TEdBLi028266 for ; Fri, 29 Apr 2005 07:39:11 -0700 (PDT) Received: from relay4.apple.com (relay4.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Fri, 29 Apr 2005 07:39:11 -0700 Received: from [17.219.197.213] ([17.219.197.213]) by relay4.apple.com (8.12.11/8.12.11) with SMTP id j3TEd4I5005886 for ; Fri, 29 Apr 2005 07:39:07 -0700 (PDT) Message-Id: <200504291439.j3TEd4I5005886@relay4.apple.com> Subject: Re: Proposed resolution: PTR queries for 254.169.in-addr.arpa Date: Fri, 29 Apr 2005 15:39:07 +0100 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >Here is a proposed resolution to the Issue: > >"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. >DNS clients MUST NOT send unicast DNS queries for any name that >falls within the "254.169.in-addr.arpa." domain. The text above I agree with. >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". That's not the role of a specification. A specification is supposed to specify. It reminds me 802.11af (Power over Ethernet) where they couldn't decide whether to specify that the power shares the 100Base-T data pairs, or runs over the two unused pairs, so the specification says that switch vendors can do either, and ALL PoE devices have to be able to work BOTH ways, thereby increasing cost and complexity and opportunity for problems and incompatibility. 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? >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, 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"? The whole point of IPv4LL is that hosts assign their own addresses, at random. The "site administrator" is not in control of what IPv4 Link-Local addresses are in use; the individual devices are. The concept of a site administrator manually setting up a reverse tree corresponding to IPv4 Link-Local addresses in use, when he or she has no knowledge of what IPv4 Link-Local addresses will be in use from one minute to the next, is utter nonsense. That concept may be applicable to net 10 and the other private address ranges, but not to IPv4LL. Each host operates autonomously, in cooperation with its peers, to select a unique IPv4LL address of its own choosing. Therefore in the IPv4LL world the only credible course of action to find out the host name corresponding to a given random address is to ask the host that chose that random address what it thinks its name is. Asking some other name server makes no sense. 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. 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. Something close to this is already done: >[chesh7:~] cheshire% dig -t ns 254.169.in-addr.arpa > >; <<>> DiG 9.2.2 <<>> -t ns 254.169.in-addr.arpa >;; global options: printcmd >;; Got answer: >;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32401 >;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2 > >;; QUESTION SECTION: >;254.169.in-addr.arpa. IN NS > >;; ANSWER SECTION: >254.169.in-addr.arpa. 604800 IN NS blackhole-1.iana.org. >254.169.in-addr.arpa. 604800 IN NS blackhole-2.iana.org. > >;; ADDITIONAL SECTION: >blackhole-1.iana.org. 2365 IN A 192.175.48.6 >blackhole-2.iana.org. 452 IN A 192.175.48.42 > >;; Query time: 483 msec >;; SERVER: 17.128.100.10#53(17.128.100.10) >;; WHEN: Fri Apr 29 14:48:14 2005 >;; MSG SIZE rcvd: 130 As to the address to give, I'd recommend 169.254.0.0 as the logical non-address for this non-server. Our spec already says: > The first 256 and last 256 addresses in the 169.254/16 > prefix are reserved for future use This could be the first of such "future uses". Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org