From owner-namedroppers@ops.ietf.org Thu Mar 1 06:18:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA29476 for ; Thu, 1 Mar 2001 06:18:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14YQZj-000NDA-00 for namedroppers-data@psg.com; Thu, 01 Mar 2001 02:44:47 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14YQZi-000ND4-00 for namedroppers@ops.ietf.org; Thu, 01 Mar 2001 02:44:46 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14YQZi-000838-00 for namedroppers@ops.ietf.org; Thu, 01 Mar 2001 02:44:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <107501c0a215$adf52130$cd4751d1@primedata.org> From: "Erik Aronesty" To: "Kevin Darcy" , References: <1a1901c0a058$aaa1cab0$cd4751d1@primedata.org> <3A9BE8C1.B7FD30E2@san.rr.com> <081a01c0a1bd$fe84a290$cd4751d1@primedata.org> <3A9DA062.63744DB3@daimlerchrysler.com> Subject: Re: cnames are in conflict with soa's... Date: Thu, 1 Mar 2001 01:05:30 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Kevin Darcy" To: Sent: Wednesday, February 28, 2001 8:05 PM Subject: Re: cnames are in conflict with soa's... > Erik Aronesty wrote: > > > Doug, > > > > Clearly, the resolver algorithm already supports this feature - if it plans > > on following the RFC's. This is a completely backward-compatible feature. > > Eliciting dialogue on this forum *is* a part of the process. RFC's are not > > used as "requests for comments" anymore. > > > > Should a DNS server issue an error if a CNAME is at the "zone top"? > > > > DNS is a "tree" of information. CNAME's can be at any node on this tree. > > Subject to the "CNAME and other data" rule, of course. - The restriction on the zone-top has no purpose - other than to follow the RFC. - The purpose in the rule is to insure that a cached CNAME can be used without checking with an authoritative server for other RR types. All other RR's *aside from the SOA/NS records* (which are required) could conflict here. The SOA/NS are for the authority section of a response - and always get transmitted along with the CNAME anyway regardless - so how can this records cause conflicts? - Assuming you are a network admin with a CNAME from ny.x.com to www.y.com in the ny.com zone. A perfectly reasonable config. It becomes necessary to create new zone for ny.x.com. This kind of thing happens. How do you resolve this now? Start copying records around in a batch job? What if there are 50 zones like this? - Erik > > > If the text file they are in has SOA record for the same domain, then > > there's a problem. However the text file is required to have an SOA record > > if it's a "zone top". > > No, this has nothing to do with "text files" _per_se_. Although the RFC's > specify "master file format", I'm not aware of any requirement that text files > be used to load DNS zones. It is more proper, I think, to state that a zone > must have at least 1 SOA RR and 1 NS RR. This is true *regardless* of whether a > text file is used to load the zone. > > > This is an indirect restriction on CNAME's at the zone top and should have > > been clarified in the RFC. > > I suppose we can differ on whether the restriction is "indirect" or not, but it > seems to me to follow, by simple logical implication, from > > 1. CNAME records can't co-exist with records of other types having the same > owner name, and > > 2. The name of a zone must own at least 1 NS and 1 SOA record > > that > > 3. a CNAME can't have the same owner name as that of a zone. > > But then, what do I know from syllogisms? I only have a degree in Philosophy... > > > RFC's should not create "implied rules". They should be careful to list all > > of the rules - so that things like this don't happen. > > > > At the very least, the RFC should be amended to state that CNAMEs are > > restricted from being served from any node that is a "parent" in the tree. > > This would be acceptable - but would expose the obvious problem. But, that > > way none of this would have happened. > > Feel free to submit a clarifying Internet Draft. > > > - Kevin > > > > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Mar 1 06:45:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA29689 for ; Thu, 1 Mar 2001 06:45:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14YRB0-000NxT-00 for namedroppers-data@psg.com; Thu, 01 Mar 2001 03:23:18 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14YRAz-000NxN-00 for namedroppers@ops.ietf.org; Thu, 01 Mar 2001 03:23:17 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14YRAz-00097u-00 for namedroppers@ops.ietf.org; Thu, 01 Mar 2001 03:23:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Masataka Ohta Message-Id: <200103010936.SAA19187@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id SAA19187; Thu, 1 Mar 2001 18:36:17 +0900 Subject: Re: Q: Is authenticated denial needed ?? In-Reply-To: from Olafur Gudmundsson at "Feb 28, 2001 11:01:44 am" To: Olafur Gudmundsson Date: Thu, 1 Mar 2001 18:36:16 +0859 () CC: Ted.Lindgreen@tednet.nl, namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Olafur; > > If we were mistaken to put effort into implementing RFC2535, it > > would have been a rather costly mistake, as some man-years of work > > have been wasted then. > > IF that is the conclusion it is better to come to that conclusion now than > 3-5 years down the road when 10x-100x more man years have been wasted in > operating DNSSEC. The best is to have had come to that conclusion 5 years up the road. > > > > So again my question: > > > > Is there consensus to abort the implementation of RFC2535 > > and wait for a rewrite to defined? > > > > The question on the table is about one aspect of DNSSEC the authenticated > denial, it is the most costly part of the specification and the one with > least benefit. The question is it worth the cost, and if so we better > document why. As I documented 5 years ago in ("Simple Secure DNS"): 6. To authenticate other data types, use authenticated RRD. If the query for RRD returns wildcard, it should also be confirmed that there is no nodes exists to make the wildcard matching impossible. For example, if "a.b.c.d." matches "*.c.d." it should be confirmed that nodes "a.b.c.d." nor "b.c.d." does not exit but a wild card "*.c.d." exists. ZL which exists in the additional section should give the required authentication for non-existent nodes. it is necessary, because, otherwise, authenticated but false answer may be wild card ones, even though exact match exists. It does worth the cost of implementing secure DNS with authencated denial. It took 2 weeks for me to modify BIND to mostly satisfy extensions in . However, it does not worth the cost of implementing RFC2535, I'm afraid. PV> NO looks different but not necessarily better. The only people I'd trust to PV> give an answer are actual engineers and engineering managers who have PV> implemented NXT (operably but not nec'ily interoperabily) and read the draft PV> for NO. If those conditions can't be satisfied, then we're just shooting into PV> the darkness with this whole discussion. Paul, the only people you should trust to give an answer are actual engineers and engineering managers who instantly perceive difficulties of NXT (or RFC2525 as a whole), never bother to implement it, write an alternative draft and implement it. Masataka Ohta to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Mar 1 06:53:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA29794 for ; Thu, 1 Mar 2001 06:53:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14YRLR-000OBb-00 for namedroppers-data@psg.com; Thu, 01 Mar 2001 03:34:05 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14YRLQ-000OBV-00 for namedroppers@ops.ietf.org; Thu, 01 Mar 2001 03:34:04 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14YRLQ-0009RD-00 for namedroppers@ops.ietf.org; Thu, 01 Mar 2001 03:34:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: namedroppers@ops.ietf.org Subject: list policy Message-Id: From: Randy Bush Date: Thu, 01 Mar 2001 03:00:01 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit namedroppers@ops.ietf.org is the mailing list for the ietf dnsext wg. see for the wg charter. messages should be on topics appropriate to the dnsext wg, which are various discussion of the dns protocols or administrivia of the wg itself. the list is moderated. calls for papers, announcements of events not directly relevant to the dns protocols, etc. are not appropriate. discussion of problems with particular implementations, announcements of releases, sites' misconfigurations, etc. should be done on mailing lists for the particular implementations. there is a wg for dns operational practice, dnsop, whose charter can be found at . there is a mailing list for discussion of whose implementation is better, and why someone else's is broken. it is weenie-war@ops.ietf.org. all discussions of such nature should occur there or on /dev/null. unlike the namedroppers list, weenie-war@ops.ietf.org is not archived. discussion of this policy is a topic for the poisson wg. poisson's charter can be found at . to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Mar 1 07:43:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01564 for ; Thu, 1 Mar 2001 07:43:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14YSBT-000PJS-00 for namedroppers-data@psg.com; Thu, 01 Mar 2001 04:27:51 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14YSBT-000PJM-00 for namedroppers@ops.ietf.org; Thu, 01 Mar 2001 04:27:51 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14YSBT-000B18-00 for namedroppers@ops.ietf.org; Thu, 01 Mar 2001 04:27:51 -0800 Message-Id: <200103011218.HAA00182@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-roadmap-02.txt Date: Thu, 01 Mar 2001 07:18:24 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNS Security Document Roadmap Author(s) : S. Rose Filename : draft-ietf-dnsext-dnssec-roadmap-02.txt Pages : 11 Date : 28-Feb-01 DNS Security (DNSSEC)technology is composed of extensions to the Domain Name System (DNS) protocol that provide data integrity and authentication to security aware resolvers and applications through the use of cryptographic digital signatures. Several documents exist to describe these extensions and the implementation specific details regarding specific digital signing schemes. The interrelationship between these different documents is discussed here. A brief overview of what to find in which document and author guidelines for what to include in new DNS Security documents, or revisions to existing documents, is described. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-roadmap-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-roadmap-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-roadmap-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010228145332.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-roadmap-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-roadmap-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010228145332.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Mar 1 07:46:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01649 for ; Thu, 1 Mar 2001 07:46:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14YSBl-000PKe-00 for namedroppers-data@psg.com; Thu, 01 Mar 2001 04:28:09 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14YSBk-000PKY-00 for namedroppers@ops.ietf.org; Thu, 01 Mar 2001 04:28:08 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14YSBk-000B1o-00 for namedroppers@ops.ietf.org; Thu, 01 Mar 2001 04:28:08 -0800 Message-Id: <200103011218.HAA00247@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-edns-zone-option-00.txt Date: Thu, 01 Mar 2001 07:18:36 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : ZONE option in DNS messages Author(s) : M. Sawyer, B. Wellington, M. Graff Filename : draft-ietf-dnsext-edns-zone-option-00.txt Pages : 4 Date : 28-Feb-01 This document defines a new EDNS option code used to specify the zone from which a remote DNS server should answer queries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-edns-zone-option-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-edns-zone-option-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-edns-zone-option-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010228145410.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-edns-zone-option-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-edns-zone-option-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010228145410.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Mar 1 07:46:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01660 for ; Thu, 1 Mar 2001 07:46:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14YSBK-000PJC-00 for namedroppers-data@psg.com; Thu, 01 Mar 2001 04:27:42 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14YSBJ-000PJ6-00 for namedroppers@ops.ietf.org; Thu, 01 Mar 2001 04:27:41 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14YSBJ-000B0k-00 for namedroppers@ops.ietf.org; Thu, 01 Mar 2001 04:27:41 -0800 Message-Id: <200103011218.HAA00156@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-edns-bind-view-option-00.txt Date: Thu, 01 Mar 2001 07:18:19 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Bind VIEW option in DNS messages Author(s) : M. Sawyer, B. Wellington, M. Graff Filename : draft-ietf-dnsext-edns-bind-view-option-00.txt Pages : 4 Date : 28-Feb-01 This document defines a new EDNS option code used to specify what view of the DNS space should be used in query messages to a remote DNS server on servers which support such a concept, such as Bind version 9. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-edns-bind-view-option-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-edns-bind-view-option-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-edns-bind-view-option-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010228145313.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-edns-bind-view-option-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-edns-bind-view-option-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010228145313.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Mar 1 07:46:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01671 for ; Thu, 1 Mar 2001 07:46:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14YSBb-000PKF-00 for namedroppers-data@psg.com; Thu, 01 Mar 2001 04:27:59 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14YSBa-000PK9-00 for namedroppers@ops.ietf.org; Thu, 01 Mar 2001 04:27:58 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14YSBa-000B1L-00 for namedroppers@ops.ietf.org; Thu, 01 Mar 2001 04:27:58 -0800 Message-Id: <200103011218.HAA00205@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-ends-unknown-00.txt Date: Thu, 01 Mar 2001 07:18:28 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Handling of unknown EDNS0 attributes Author(s) : M. Sawyer, A. Gustafsson, M. Graff Filename : draft-ietf-dnsext-ends-unknown-00.txt Pages : 6 Date : 28-Feb-01 This document provides a clarification of the EDNS0 protocol, specifying the behavior of servers when they receive unknown EDNS options. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ends-unknown-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-ends-unknown-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-ends-unknown-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010228145341.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-ends-unknown-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-ends-unknown-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010228145341.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Mar 1 07:51:06 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01780 for ; Thu, 1 Mar 2001 07:51:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14YSBf-000PKP-00 for namedroppers-data@psg.com; Thu, 01 Mar 2001 04:28:03 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14YSBf-000PKJ-00 for namedroppers@ops.ietf.org; Thu, 01 Mar 2001 04:28:03 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14YSBf-000B1V-00 for namedroppers@ops.ietf.org; Thu, 01 Mar 2001 04:28:03 -0800 Message-Id: <200103011218.HAA00226@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-obsolete-iquery-00.txt Date: Thu, 01 Mar 2001 07:18:32 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Obsoleting IQUERY Author(s) : D. Lawrence Filename : draft-ietf-dnsext-obsolete-iquery-00.txt Pages : 4 Date : 28-Feb-01 Based on a lack of working implementations of the IQUERY method of performing inverse DNS lookups, and because an alternative mechanism for doing inverse queries of address records has been successfully used operationally for well over a decade, this draft proposes that the IQUERY operation be entirely obsoleted. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-obsolete-iquery-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-obsolete-iquery-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-obsolete-iquery-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010228145359.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-obsolete-iquery-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-obsolete-iquery-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010228145359.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Mar 1 13:06:01 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13669 for ; Thu, 1 Mar 2001 13:06:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14YWxH-0006of-00 for namedroppers-data@psg.com; Thu, 01 Mar 2001 09:33:31 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14YWxH-0006oY-00 for namedroppers@ops.ietf.org; Thu, 01 Mar 2001 09:33:31 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14YWxG-000Jpr-00 for namedroppers@ops.ietf.org; Thu, 01 Mar 2001 09:33:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <01C0A245.989D9080@INSIDE> From: Erik Aronesty To: "'Mark.Andrews@nominum.com'" Cc: "'Jim Reid'" , "bind-users@isc.org" , "namedroppers@ops.ietf.org" Subject: RE: cname quick question Date: Thu, 1 Mar 2001 11:48:53 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mark, Following your excellent example: There is a CNAME present at the node, so the request for the SOA/NS record will be restarted with the QNAME changed to the target. The SOA will then be returned from the canonical name. --> The query will not fail if the algorithm is follwed. Other results: The SOA present at the zone-top will never be cached/used except in requests which prevent chaining, IE: requests for the CNAME itself or for other domains in the zone file. Likewise, the NS records will only be used for the authority section in non-chained requests. If you consider the meaning of NS/SOA records - this behavior is correct. (Or as close to correct as possible - since there really should have been *two types of NS records*, as was pointed out earlier on namedroppers) That's it. Where do you foresee failure/doom in this? Bear in mind that this is how BIND resolver used to behave in versions 4 through 8.2.2 when CNAME's were not prevented from being in the zone top. - Erik -----Original Message----- From: Mark.Andrews@nominum.com [SMTP:Mark.Andrews@nominum.com] Sent: Thursday, March 01, 2001 10:49 AM To: Erik Aronesty Cc: 'Jim Reid'; bind-users@isc.org Subject: Re: cname quick question > > JIM>Please *read* the extract from RFC1034 above. Now *think* about what > JIM>it says and what that means. Pay particular attention to the last > JIM>sentence. Hint: suppose clueless.example.com was a CNAME pointing at > JIM>moron.example.net. That CNAME is cached by some name server. It can > JIM>safely use that cached CNAME without having to query the example.com > JIM>name servers to check that no other record types exist for > JIM>clueless.example.com. > > 1- Suppose clueless.example.com was at the zone top with a "@ IN CNAME moron. > example.net." > > 2- The CNAME can still get cached by a name server. The CNAME can still be > safely used from the cache -and no other record types ever have to be quer > ied - > since the SOA and NS record types are transmitted in the authority section > . The problem is once the CNAME is cached you can't retrieve the SOA or NS records. i.e. "dig NS clueless.example.com" or "dig SOA clueless.example.com" will FAIL. People have as much right to query for NS and SOA records as any other type. You seem to think that the only way they can be transmitted is as a side effect of a query for some other type. THIS IS FALSE. > > 4- You example just shows that you arent' paying attention. > > - Erik Erik you are the one that is not paying attention. Your changes will not interoperate cleanly with the exist resolvers. It doesn't matter how many time you say they will when you have proved by your own examples that they don't. Mark > > > --- thread below --- > > -----Original Message----- > From: Jim Reid [SMTP:jim@rfc1035.com] > Sent: Thursday, March 01, 2001 5:16 AM > To: Erik Aronesty > Cc: bind-users@isc.org Subject: Re: cname quick question > > >>>>> "Erik" == Erik Aronesty writes: > > >> If a CNAME RR is present at a node, no other data should be > >> present; this ensures that the data for a canonical name and > >> its aliases cannot be different. This rule also insures that a > >> cached CNAME can be used without checking with an authoritative > >> server for other RR types. > > Erik> Exactly. How does having a CNAME at the zone-top cause this > Erik> to be an error? For that mater how does having an SOA > Erik> record fail to allow cached CNAMES to be used without > Erik> checking an authoritative server for other RR types? It > Erik> doesn't. Because the SOA record is used for zone transfers > Erik> and cache/timing information itself. The RFC neglected to > Erik> mention that. That's all. > > JIM>Like Tal Dayan, you are being obtuse or deliberately provocative. > JIM>Please *read* the extract from RFC1034 above. Now *think* about what > JIM>it says and what that means. Pay particular attention to the last > JIM>sentence. Hint: suppose clueless.example.com was a CNAME pointing at > JIM>moron.example.net. That CNAME is cached by some name server. It can > JIM>safely use that cached CNAME without having to query the example.com > JIM>name servers to check that no other record types exist for > JIM>clueless.example.com. > > 1- Suppose clueless.example.com was at the zone top. > > 2- The CNAME can still get cached by a name server. The CNAME can still be > safely used from the cache -and no other record types ever have to be quer > ied - > since the SOA and NS record types are transmitted in the authority section > . > > 4- You example just shows that you arent' paying attention. > > - Erik > > > -- Mark Andrews, Nominum Inc. 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Mar 1 13:20:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14371 for ; Thu, 1 Mar 2001 13:20:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14YX8g-00078C-00 for namedroppers-data@psg.com; Thu, 01 Mar 2001 09:45:18 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14YX8f-000786-00 for namedroppers@ops.ietf.org; Thu, 01 Mar 2001 09:45:17 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14YX8f-000KAI-00 for namedroppers@ops.ietf.org; Thu, 01 Mar 2001 09:45:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: "Erik Aronesty" cc: "Kevin Darcy" , namedroppers@ops.ietf.org Subject: Re: cnames are in conflict with soa's... In-reply-to: Your message of "Thu, 01 Mar 2001 01:05:30 EST." <107501c0a215$adf52130$cd4751d1@primedata.org> Date: Fri, 02 Mar 2001 00:40:14 +0700 Message-ID: <3337.983468414@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Thu, 1 Mar 2001 01:05:30 -0500 From: "Erik Aronesty" Message-ID: <107501c0a215$adf52130$cd4751d1@primedata.org> This whole discussion s truly absurd. You clearly have no idea what the intent of CNAMES was. | - The restriction on the zone-top has no purpose - other than to follow the | RFC. On zone top, in particular, perhaps - but that is a side effect of a rule which does have a purpose, which is not ... | - The purpose in the rule is to insure that a cached CNAME can be used | without checking with an authoritative server for other RR types. That's just a side benefit. The restriction is so that the data for the alias, and the data for the canonical name, are identical. Everything about them is the same. CNAMES are (were) the replacement for the "extra names" (aliases) field in the hosts.txt file. More names that mean exactly the same thing as the canonical name. If it isn't identical in all respects, then it isn't an alias, and should have real data, not a CNAME. Also, only hosts get aliases - domains weren't in hosts.txt, so never had aliases, so still don't get to have aliases. | All other | RR's *aside from the SOA/NS records* (which are required) could conflict | here. The SOA/NS are for the authority section of a response - and always | get transmitted along with the CNAME anyway regardless - so how can this | records cause conflicts? Huh? *always* - now I know you're joking. But just consider A IN CNAME B IN NS C B IN NS D now the NS records for A and B are not identical, and hence A is not an alias for B, and hence A should not have a CNAME record. It doesn't matter what else exists or does not. | - Assuming you are a network admin with a CNAME from ny.x.com to www.y.com | in the ny.com zone. A perfectly reasonable config. It becomes necessary to | create new zone for ny.x.com. This kind of thing happens. How do you | resolve this now? Start copying records around in a batch job? You copy the records from www.y.com to ny.x.com and then modify whatever it is that makes it no longer be an alias. Whether than is to add a delegation below ny.x.com or to alter the A record, or MX record, or anything else where the two names are no longer identical. | What if there are 50 zones like this? Then you have a bit more work to do. Big deal. Please stop bothering people about this - if you have a sensible and well thought out proposal, that documents all of the ramifications, then write it as an I-D. Otherwise, it seems clear that there is *no-one* else here that supports your rather oddball theory on the way things ought to be. Arguing about it is just wasting everyone's time. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Mar 1 13:44:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16252 for ; Thu, 1 Mar 2001 13:44:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14YXg4-0008Bu-00 for namedroppers-data@psg.com; Thu, 01 Mar 2001 10:19:48 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14YXg3-0008Bo-00 for namedroppers@ops.ietf.org; Thu, 01 Mar 2001 10:19:47 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14YXg3-000LAk-00 for namedroppers@ops.ietf.org; Thu, 01 Mar 2001 10:19:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <01C0A252.FA607FA0@INSIDE> From: Erik Aronesty To: "'Robert Elz'" Cc: Kevin Darcy , "namedroppers@ops.ietf.org" Subject: RE: cnames are in conflict with soa's... Date: Thu, 1 Mar 2001 13:24:42 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit | - The restriction on the zone-top has no purpose - other than to follow the | RFC. > On zone top, in particular, perhaps - but that is a side effect of a rule > which does have a purpose, which is not ... That *is* the only issue here. The zone-top restriction. | - The purpose in the rule is to insure that a cached CNAME can be used | without checking with an authoritative server for other RR types. >That's just a side benefit. >The restriction is so that the data for the alias, and the data for the >canonical name, are identical. Everything about them is the same. >CNAMES are (were) the replacement for the "extra names" (aliases) field >in the hosts.txt file. More names that mean exactly the same thing as >the canonical name. >If it isn't identical in all respects, then it isn't an alias, and should >have real data, not a CNAME. >Also, only hosts get aliases - domains weren't in hosts.txt, so never >had aliases, so still don't get to have aliases. I agree. Howeve, it's not the general case of the rule that I am taking issue with. It's the very specific case of a CNAME at the "zone-top". So, lets discuss the specific case of the "zone-top". What data would be "duplicted"? What happens if this were allowed? Remember, all nodes in the DNS tree really "have" an SOA/NS for the authority section. And all CNAME's already have authority information in two places, the alias and the canonical name. Moving forward: Requests for QTYPE=CNAME would respond with the authority information from the local zone file, or inheriting from the parent node. The results, in this case are not contradictory / misleading. Requests for other QTYPE's would respond with the authority information from the target. The results, in this case are still not contradictory or misleading Direct requests for QTYPE=SOA or NS would respond with the information from the canonical name, dutifully following the algorithm. How do CNAME's at the zone-top cause failure/doom? | All other | RR's *aside from the SOA/NS records* (which are required) could conflict | here. The SOA/NS are for the authority section of a response - and always | get transmitted along with the CNAME anyway regardless - so how can this | records cause conflicts? > Huh? *always* - now I know you're joking. > But just consider > A IN CNAME B > IN NS C > B IN NS D > now the NS records for A and B are not identical, and hence A is not > an alias for B, and hence A should not have a CNAME record. It doesn't > matter what else exists or does not. ****I repeat, this is not the case that we have an issue with*** Consider again that this is valid: ----x zone file---- A IN CNAME B.Y A IN NS C ----y zone file---- @ IN NS C B IN A ... Then explain why this is not using the same argument: ----x zone file---- @ IN CNAME B.Y @ IN NS C ----y zone file---- @ IN NS C B IN A ... | - Assuming you are a network admin with a CNAME from ny.x.com to www.y.com | in the ny.com zone. A perfectly reasonable config. It becomes necessary to | create new zone for ny.x.com. This kind of thing happens. How do you | resolve this now? Start copying records around in a batch job? >You copy the records from www.y.com to ny.x.com and then modify whatever it is >that makes it no longer be an alias. Whether than is to add a delegation >below ny.x.com or to alter the A record, or MX record, or anything else >where the two names are no longer identical. | What if there are 50 zones like this? >Then you have a bit more work to do. Big deal. >Please stop bothering people about this - if you have a sensible and >well thought out proposal, that documents all of the ramifications, >then write it as an I-D. Sorry, I'm working on it. Believe it or not your analysis is very helpful. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Mar 1 14:16:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18593 for ; Thu, 1 Mar 2001 14:16:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14YYIP-0009Sb-00 for namedroppers-data@psg.com; Thu, 01 Mar 2001 10:59:25 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14YYIP-0009SV-00 for namedroppers@ops.ietf.org; Thu, 01 Mar 2001 10:59:25 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14YYIP-000MIW-00 for namedroppers@ops.ietf.org; Thu, 01 Mar 2001 10:59:25 -0800 From: Robert Elz To: Erik Aronesty cc: Kevin Darcy , "namedroppers@ops.ietf.org" Subject: Re: cnames are in conflict with soa's... In-reply-to: Your message of "Thu, 01 Mar 2001 13:24:42 EST." <01C0A252.FA607FA0@INSIDE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 02 Mar 2001 01:55:14 +0700 Message-ID: <5836.983472914@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Thu, 1 Mar 2001 13:24:42 -0500 From: Erik Aronesty Message-ID: <01C0A252.FA607FA0@INSIDE> | That *is* the only issue here. The zone-top restriction. You are failing to understand. There is no "zone-top" restriction. There is a general restriction which applies everywhere, zone top or not. | I agree. Howeve, it's not the general case of the rule that I am taking | issue with. It's the very specific case of a CNAME at the "zone-top". So, | lets discuss the specific case of the "zone-top". Why? There's no magic difference. | What data would be "duplicted"? What happens if this were allowed? Exactly the same as can happen anywhere else. Any domain in the DNS can be a zone top, zones are an administrative issue. Allow CNAME at the zone top, and it is instantly allowed everywhere, so that is what you are taking issue with. | Remember, all nodes in the DNS tree really "have" an SOA/NS for | the authority section. This is a total mis-mash of two different concepts. Nodes in the DNS tree do not have an authority section. DNS packets have an authority section (which sometimes contains data). The two things are not very related. | Requests for QTYPE=CNAME would respond with the authority information requests for type CNAME respond with the CNAME RR, if it exists, they don't respond with "authority information". Sometimes, auth info might be included, if it happens to be available. | Consider again that this is valid: | | ----x zone file---- | A IN CNAME B.Y | A IN NS C No it isn't. If A is an alias, it can have no other data, hence it cannot have that NS record. | Then explain why this is not using the same argument: | | ----x zone file---- | @ IN CNAME B.Y | @ IN NS C it is not for the exact same reason, except we have @ ($ORIGIN, or x) instead of A. Except as a thing to do this makes zero sense at all. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Mar 1 14:21:09 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18816 for ; Thu, 1 Mar 2001 14:21:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14YYIs-0009Vb-00 for namedroppers-data@psg.com; Thu, 01 Mar 2001 10:59:54 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14YYIr-0009VV-00 for namedroppers@ops.ietf.org; Thu, 01 Mar 2001 10:59:53 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14YYIr-000MJb-00 for namedroppers@ops.ietf.org; Thu, 01 Mar 2001 10:59:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: namedroppers@ops.ietf.org Subject: Re: cnames are in conflict with soa's... References: <107501c0a215$adf52130$cd4751d1@primedata.org> <3337.983468414@brandenburg.cs.mu.OZ.AU> Message-Id: Date: Thu, 01 Mar 2001 10:59:17 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > This whole discussion s truly absurd. nah, only mostly absurd. so why are folk continuing it? randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Mar 1 14:31:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19198 for ; Thu, 1 Mar 2001 14:31:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14YYVD-0009uQ-00 for namedroppers-data@psg.com; Thu, 01 Mar 2001 11:12:39 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14YYVD-0009uK-00 for namedroppers@ops.ietf.org; Thu, 01 Mar 2001 11:12:39 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14YYVD-000Mfu-00 for namedroppers@ops.ietf.org; Thu, 01 Mar 2001 11:12:39 -0800 From: Robert Elz To: Randy Bush cc: namedroppers@ops.ietf.org Subject: Re: cnames are in conflict with soa's... In-reply-to: Your message of "Thu, 01 Mar 2001 10:59:17 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 02 Mar 2001 02:06:54 +0700 Message-ID: <5933.983473614@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Thu, 01 Mar 2001 10:59:17 -0800 From: Randy Bush Message-ID: | nah, only mostly absurd. so why are folk continuing it? Very good question. You can assume that any more messages from me on the subject must be forgeries, and drop them... kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Mar 1 15:31:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21764 for ; Thu, 1 Mar 2001 15:31:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14YZQy-000Bwu-00 for namedroppers-data@psg.com; Thu, 01 Mar 2001 12:12:20 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14YZQx-000Bwo-00 for namedroppers@ops.ietf.org; Thu, 01 Mar 2001 12:12:19 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14YZQx-000OMp-00 for namedroppers@ops.ietf.org; Thu, 01 Mar 2001 12:12:19 -0800 From: "Jesper G. Hoy" To: Subject: Automation of secondary DNS servers Date: Thu, 1 Mar 2001 14:59:31 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Looking for feedback - and possibly assistance with composing an RFC. Please let me know if I have missed an existing RFC on this topic. A lot of our customers (we write and sell DNS server software) have asked us about a way to automatically create (and delete) zones on secondary servers. Preferably through some type of signaling from the primary and a periodic synchronize mechanism. This would greatly ease administration, as zone administration could be done entirely on the primary server And the chance of lame delegations on secondary servers would be significantly reduced. Currently each new zone must be created on both the primary and all secondary servers (same for deletions). The Notify OpCode (RFC1996) could easily be adopted for the "signaling" from primary to secondary, but a new "zone list transfer" mechanism for periodic synchronization would probably have to be devised. Obviously we could implement a proprietary system, but since secondaries are (or should be) off-site chances are that different software is used. So to ensure cross-implementation compatibility I think a standard for something like this would be very appropriate. Looking forward to hearing your comments. Regards Jesper G. Hoy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Mar 1 18:05:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27622 for ; Thu, 1 Mar 2001 18:05:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14YbfX-000Gkk-00 for namedroppers-data@psg.com; Thu, 01 Mar 2001 14:35:31 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14YbfX-000Gkd-00 for namedroppers@ops.ietf.org; Thu, 01 Mar 2001 14:35:31 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14YbfX-0002MY-00 for namedroppers@ops.ietf.org; Thu, 01 Mar 2001 14:35:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200103012049.MAA02764@redpaul.mfnx.net> To: "Jesper G. Hoy" cc: namedroppers@ops.ietf.org Subject: Re: Automation of secondary DNS servers In-Reply-To: Message from "Jesper G. Hoy" of "Thu, 01 Mar 2001 14:59:31 EST." Date: Thu, 01 Mar 2001 12:49:56 -0800 From: Paul A Vixie Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit the right way to do this is with postprocessing of outofband data, not NOTIFY. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Mar 1 18:05:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27641 for ; Thu, 1 Mar 2001 18:05:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Ybl0-000Gtx-00 for namedroppers-data@psg.com; Thu, 01 Mar 2001 14:41:10 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14Ybl0-000Gtr-00 for namedroppers@ops.ietf.org; Thu, 01 Mar 2001 14:41:10 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14Ybl0-0002Vk-00 for namedroppers@ops.ietf.org; Thu, 01 Mar 2001 14:41:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200103012115.QAA23478@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , IANA Cc: Internet Architecture Board Cc: namedroppers@ops.ietf.org From: The IESG Subject: Protocol Action: DNS Security Extension Clarification on Zone Status to Proposed Standard Date: Thu, 01 Mar 2001 16:15:28 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The IESG has approved the Internet-Draft 'DNS Security Extension Clarification on Zone Status' as a Proposed Standard. This document is the product of the DNS Extensions Working Group. The IESG contact persons are Erik Nordmark and Thomas Narten. Technical Summary The document presents rge definition of a secured zone, clarifying and updating sections of RFC 2535. RFC 2535 defines a zone to be secured based on a per algorithm basis, e.g., a zone can be secured with RSA keys, and not secured with DSA keys. This document changes this to define a zone to be secured or not secured regardless of the key algorithm used (or not used). To further simplify the determination of a zone's status, "experimentally secure" status is deprecated. Working Group Summary There was WG consensus to advance the document. Protocol Quality The specification has been reviewed for the IESG by Erik Nordmark. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Mar 1 18:26:00 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28036 for ; Thu, 1 Mar 2001 18:25:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Yc0E-000HXU-00 for namedroppers-data@psg.com; Thu, 01 Mar 2001 14:56:54 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14Yc0D-000HXK-00 for namedroppers@ops.ietf.org; Thu, 01 Mar 2001 14:56:53 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14Yc0D-0002wg-00 for namedroppers@ops.ietf.org; Thu, 01 Mar 2001 14:56:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A9ED022.69E6B6C5@daimlerchrysler.com> Date: Thu, 01 Mar 2001 17:41:38 -0500 From: Kevin Darcy To: "bind-users@isc.org" , "namedroppers@ops.ietf.org" Subject: Re: cname quick question References: <01C0A245.989D9080@INSIDE> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik Aronesty wrote: > Mark, > > Following your excellent example: > > There is a CNAME present at the node, so the request for the SOA/NS record > will be restarted with the QNAME changed to the target. The SOA will > then be returned from the canonical name. > > --> The query will not fail if the algorithm is follwed. No, Erik, the results will be *inconsistent*, in the case of a non-authoritative, recursive nameserver. If it *only* has the CNAME cached, then the SOA of the alias target will be returned. But if QNAME's SOA record is cached, then it will be returned instead. Work through the algorithm in both cases. Surely you can see how unacceptable it is for a server to give inconsistent answers for the same recursive query, based on the vicissitudes of what records it happens to have cached at any given point in time... > Other results: > > The SOA present at the zone-top will never be cached/used except > in requests which prevent chaining, IE: requests for the CNAME itself or for > other domains in the zone file. What do you mean by "requests which prevent chaining"? With the rules the way they are now, chaining always occurs for CNAMEs, except for the DNSSEC-related records which have already been noted. Or, are you suddenly switching from "the way things are now" to "the way things would be if my 'NS and SOA queries do not chain' proposal were adopted"? In order to avoid misunderstandings, please take care to distinguish between actual and hypothetical situations. > Likewise, the NS records will only be used > for the authority section in non-chained requests. Except for referrals, NS records in the authority section are optional anyway... - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Mar 1 18:59:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28825 for ; Thu, 1 Mar 2001 18:59:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14YchX-000JKG-00 for namedroppers-data@psg.com; Thu, 01 Mar 2001 15:41:39 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14YchX-000JKA-00 for namedroppers@ops.ietf.org; Thu, 01 Mar 2001 15:41:39 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14YchX-0004E0-00 for namedroppers@ops.ietf.org; Thu, 01 Mar 2001 15:41:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200103012337.f21Nb8h55483@drugs.dv.isc.org> To: Erik Aronesty Cc: "'Mark.Andrews@nominum.com'" , "'Jim Reid'" , "bind-users@isc.org" , "namedroppers@ops.ietf.org" From: Mark.Andrews@nominum.com Subject: Re: cname quick question In-reply-to: Your message of "Thu, 01 Mar 2001 11:48:53 CDT." <01C0A245.989D9080@INSIDE> Date: Fri, 02 Mar 2001 10:37:08 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ people, please stop responding to this thread. cluelessness has been sufficiently demonstrated that i prefer to approve no further postings on this topic. -- randy ] > Mark, > > Following your excellent example: > > There is a CNAME present at the node, so the request for the SOA/NS record > will be restarted with the QNAME changed to the target. The SOA will > then be returned from the canonical name. Correct. You want to have both a CNAME and SOA and a NS RRset at the same owner name. Now depending upon the order of queries made I get *different* responses for a SOA and NS queries. This is why your proposal does not interoperate with the current resolvers despite everything you keep saying. > > --> The query will not fail if the algorithm is follwed. The query did fail as it did not return the "correct" SOA / NS record. It did follow the algorithm. It looked for a SOA / NS record in the cache failed to find one, found a CNAME and followed it. Now DNSSEC went ahead with the same problem. However in the DNSSEC case it was with a new types knowing that the existing base would not cache the new types. Anyone look up a DNSSEC record knows that they might have this failure mode and can take steps to ensure that it is not a problem. Your wanting to do the same thing with well known types that will be cached. You are proposing a change that will destabalise the existing base. While failing to acknowledge that it will do that. You keep saying that pre 8.2.3 supports CNAME and SOA / NS records at the same node, despite us telling you as the developers that it was not supported, and that anyone with those versions can check that it was not supported. Use a tool other that nslookup and make the queries of a zone with and without a CNAME at the apex and look at the differences in the answers returned. They don't just vary by just the contents of the records. Try to perform a zone transfer it will FAIL. Now Eric of all the real life examples you have seen for CNAME vs SOA, would they not have also been solved by the solution space to the CNAME vs MX issue. I know I have seen vastly more complaints about CNAME and MX vs CNAME at top of zone. I also know that people want to be able to mail to user@example.com at the same time as the want to be able to use http://example.com where the http is served by a hosting company and the mail is in house. Adding support for CNAMES at top of zone does not solve this problem. It would solve the plain http://example.com but we all know that is the less common and a short term problem that invariable graduates into the bigger problem. You have been told to write your proposal as a draft. Do that listing all the ways that it breaks existing functionality, how existing servers will behave under the new regime including the effect on the old caches when lookup data below the zone apex and the resulting additional traffic, list the percieved benefits over the solution space for MX vs CNAME. Be sure to check a number of different caching servers from different sources. Don't assume that they all have BIND's behaviour when it comes to dealing with proposed change. Go read RFC 2308. It made non-compatible changes. It also listed all the sort of things we have been asking you to list so that they could be evaluated and be documented as a reference for people that were having problems in the future. Mark > > Other results: > > The SOA present at the zone-top will never be cached/used except > in requests which prevent chaining, IE: requests for the CNAME itself or for > > other domains in the zone file. Likewise, the NS records will only be used > for the authority section in non-chained requests. > > If you consider the meaning of NS/SOA records - this behavior is correct. > (Or as close to correct as possible - since there really should have been > *two types of NS records*, as was pointed out earlier on namedroppers) > > That's it. Where do you foresee failure/doom in this? Bear in mind that > this is how BIND resolver used to behave in versions 4 through 8.2.2 > when CNAME's were not prevented from being in the zone top. > > - Erik > > > -----Original Message----- > From: Mark.Andrews@nominum.com [SMTP:Mark.Andrews@nominum.com] > Sent: Thursday, March 01, 2001 10:49 AM > To: Erik Aronesty > Cc: 'Jim Reid'; bind-users@isc.org > Subject: Re: cname quick question > > > > > > JIM>Please *read* the extract from RFC1034 above. Now *think* about what > > JIM>it says and what that means. Pay particular attention to the last > > JIM>sentence. Hint: suppose clueless.example.com was a CNAME pointing at > > JIM>moron.example.net. That CNAME is cached by some name server. It can > > JIM>safely use that cached CNAME without having to query the example.com > > JIM>name servers to check that no other record types exist for > > JIM>clueless.example.com. > > > > 1- Suppose clueless.example.com was at the zone top with a "@ IN CNAME mor > on. > > example.net." > > > > 2- The CNAME can still get cached by a name server. The CNAME can still b > e > > safely used from the cache -and no other record types ever have to be q > uer > > ied - > > since the SOA and NS record types are transmitted in the authority sect > ion > > . > > The problem is once the CNAME is cached you can't retrieve > the SOA or NS records. i.e. "dig NS clueless.example.com" > or "dig SOA clueless.example.com" will FAIL. > > People have as much right to query for NS and SOA records > as any other type. You seem to think that the only way > they can be transmitted is as a side effect of a query for > some other type. THIS IS FALSE. > > > > > 4- You example just shows that you arent' paying attention. > > > > - Erik > > Erik you are the one that is not paying attention. Your > changes will not interoperate cleanly with the exist resolvers. > > It doesn't matter how many time you say they will when you > have proved by your own examples that they don't. > > Mark > > > > > > --- thread below --- > > > > -----Original Message----- > > From: Jim Reid [SMTP:jim@rfc1035.com] > > Sent: Thursday, March 01, 2001 5:16 AM > > To: Erik Aronesty > > Cc: bind-users@isc.org > Subject: Re: cname quick question > > > > >>>>> "Erik" == Erik Aronesty writes: > > > > >> If a CNAME RR is present at a node, no other data should be > > >> present; this ensures that the data for a canonical name and > > >> its aliases cannot be different. This rule also insures that a > > >> cached CNAME can be used without checking with an authoritative > > >> server for other RR types. > > > > Erik> Exactly. How does having a CNAME at the zone-top cause this > > Erik> to be an error? For that mater how does having an SOA > > Erik> record fail to allow cached CNAMES to be used without > > Erik> checking an authoritative server for other RR types? It > > Erik> doesn't. Because the SOA record is used for zone transfers > > Erik> and cache/timing information itself. The RFC neglected to > > Erik> mention that. That's all. > > > > JIM>Like Tal Dayan, you are being obtuse or deliberately provocative. > > JIM>Please *read* the extract from RFC1034 above. Now *think* about what > > JIM>it says and what that means. Pay particular attention to the last > > JIM>sentence. Hint: suppose clueless.example.com was a CNAME pointing at > > JIM>moron.example.net. That CNAME is cached by some name server. It can > > JIM>safely use that cached CNAME without having to query the example.com > > JIM>name servers to check that no other record types exist for > > JIM>clueless.example.com. > > > > 1- Suppose clueless.example.com was at the zone top. > > > > 2- The CNAME can still get cached by a name server. The CNAME can still b > e > > safely used from the cache -and no other record types ever have to be q > uer > > ied - > > since the SOA and NS record types are transmitted in the authority sect > ion > > . > > > > 4- You example just shows that you arent' paying attention. > > > > - Erik > > > > > > > -- > Mark Andrews, Nominum Inc. > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@nominum.com > > -- Mark Andrews, Nominum Inc. 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Mar 1 19:25:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29410 for ; Thu, 1 Mar 2001 19:25:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Ycxi-000JzX-00 for namedroppers-data@psg.com; Thu, 01 Mar 2001 15:58:22 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14Ycxh-000JzR-00 for namedroppers@ops.ietf.org; Thu, 01 Mar 2001 15:58:21 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14Ycxh-0004hh-00 for namedroppers@ops.ietf.org; Thu, 01 Mar 2001 15:58:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A9EE076.C3EAC43B@daimlerchrysler.com> Date: Thu, 01 Mar 2001 18:51:19 -0500 From: Kevin Darcy To: namedroppers@ops.ietf.org Subject: Re: cnames are in conflict with soa's... References: <1a1901c0a058$aaa1cab0$cd4751d1@primedata.org> <3A9BE8C1.B7FD30E2@san.rr.com> <081a01c0a1bd$fe84a290$cd4751d1@primedata.org> <3A9DA062.63744DB3@daimlerchrysler.com> <107501c0a215$adf52130$cd4751d1@primedata.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik Aronesty wrote: > - The restriction on the zone-top has no purpose - other than to follow the > RFC. > > - The purpose in the rule is to insure that a cached CNAME can be used > without checking with an authoritative server for other RR types. All other > RR's *aside from the SOA/NS records* (which are required) could conflict > here. The SOA/NS are for the authority section of a response - and always > get transmitted along with the CNAME anyway regardless - so how can > thisrecords cause conflicts? Are you implying that SOA and NS records can *only* appear in Authority Sections? Clearly that is false; in answers to explicit SOA or NS queries, they may appear in the *Answer* Section. And explicit SOA and NS queries are not only possible, they are quite common: explicit SOA queries are generated routinely and automatically in the serial-number checking step of AXFR/IXFR-based master/slave synchronization; certain Dynamic Update clients generate explicit SOA and/or NS queries also. But, regardless of the circumstances under which SOA and NS records appear in the Answer versus the Authority Sections of responses, the relevant point here is that records of those types can be *cached* from responses. Given this, you create a terrible ambiguity if you allow CNAMEs to co-exist with those record types. As I've explained in my last message in a parallel thread, if a CNAME can be cached and an SOA or NS record with same name could be cached, then the results of issuing an NS or SOA query of that name to a non-authoritative, recursive server would be *unpredictable*, depending on what type of record(s) with that name it happened to have in its cache at any particular time. You can't build a robust nameservice infrastructure on such unpredictability. > - Assuming you are a network admin with a CNAME from ny.x.com to www.y.com > in the ny.com zone. A perfectly reasonable config. It becomes necessary to > create new zone for ny.x.com. This kind of thing happens. How do you > resolve this now? Start copying records around in a batch job? What if > there are 50 zones like this? Erik, admins who read relevant RFC's and/or fix the problems that BIND complains about in log files have been dealing successfully with this rule for 13 years since RFC 1034 first announced it. I personally ran afoul of this rule somewhere around 1991, realized my mistake, corrected it and I've never had a problem with it since that time. It's just a fact of life in the world of DNS administration, and I have accepted it as such. Why then, all of a sudden, do you declare the whole profession of DNS administration incapable of dealing with this rule? Clueless admins need to be *educated* and to *learn* the rules, not for their cluelessness to be accommodated with reckless changes that introduce inefficiency and/or unreliability into the underlying protocol. Another common newbie misconception is that putting an NS record in a zone somewhere other than at the zone top tells a nameserver to "forward" requests (i.e. issue recursive queries) for the name to some other nameserver; shall we accommodate that misconception also, thus mangling the mechanism of delegation and referral? Where does this all end? Or maybe what we actually need are two *different* DNS protocols -- the regular DNS protocol and the Remedial DNS protocol, for those who can't deal with the regular one... - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Mar 1 22:31:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA04452 for ; Thu, 1 Mar 2001 22:31:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Yfkq-000Q05-00 for namedroppers-data@psg.com; Thu, 01 Mar 2001 18:57:16 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14Yfkq-000Pzz-00 for namedroppers@ops.ietf.org; Thu, 01 Mar 2001 18:57:16 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14Yfkq-0009i1-00 for namedroppers@ops.ietf.org; Thu, 01 Mar 2001 18:57:16 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <01a501c0a2c4$bc5c28e0$c8026b83@home.com> From: "Mike Macgowan" To: Subject: DNS Label Intelligence and Management System Date: Thu, 1 Mar 2001 19:59:00 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The following draft is to be considered for adoption into the DNS EXT WG at the meeting in Minneapolis. Although I am new to this workgroup, these ideas were reviewed by Rick Hayes-Roth, CTO at HP. He suggested that these proposed extensions would be a great asset to the Internet. http://www.ietf.org/internet-drafts/draft-macgowan-dnsext-label-intel-manage -00.txt You are the experts in the field. I would appreciate your review and comments so that I may be better prepared to discuss these ideas in person. Here is a quick look at the abstract: A multidimensional array of domain label analysis and extensions are offered to overcome a number of issues with the DNS and its use to locate resources on the Internet. These goals are accomplished by proposing a naming convention to add labels to domain strings. The result will be a rational relationship to the content that will provide a method for meeting the ever-increasing need to expand the namespace, while providing an efficient search system to access content in a user- friendly manner. A fundamental problem exists in the design of DNS. A user must know the domain name including the Top Level Domain, TLD, and type the Uniform Resource Locator, URL, accurately to connect to resources on the Internet. The current lookup organization of the DNS uses domain labels separated by periods to provide hierarchical levels for a resolver to seek in finding a path to an authority. A new masking technique within labels is proposed to accommodate lookups based on the request. Multiple processing trees are proposed to redistribute the requests based on the known pieces of the domain name. Rather than knowing the fully qualified domain name, FQDN, the user can search for content based upon known pieces of the string like group (business), country, area code, phone number, type of organization, street address, zip code and/or GPS location, etc.. Intelligence is added for determining the fastest route to resolution based on user weighting, number of requests, and traffic within the system. A result of the masking technique is an opportunity to provide a completely hidden label(s) for maintenance of the system. A TTL (Time to Live), version, and type of request could be keyed into a label to provide information, which remains with the client but is normally lost after a request is processed. This system could be implemented to create automatically updated records and content. Or hidden labels could be used to distinguish between version 4 and version 6 requests in the TCP/IP, Transmission Control Protocol/ Internet Protocol, rollover. Implementation of the new name system is facilitated by the addition of a client interface for building requests. Longer domain names are enhanced by smart AutoCompletes and group edit boxes. Michael L. Macgowan Jr. mmacgowa@yahoo.com MCT, MCSE to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Mar 1 23:32:08 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA05960 for ; Thu, 1 Mar 2001 23:32:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14YgqD-0002PN-00 for namedroppers-data@psg.com; Thu, 01 Mar 2001 20:06:53 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14YgqC-0002PG-00 for namedroppers@ops.ietf.org; Thu, 01 Mar 2001 20:06:52 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14YgqC-000BcU-00 for namedroppers@ops.ietf.org; Thu, 01 Mar 2001 20:06:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A9F1B8E.9BE6EAC6@daimlerchrysler.com> Date: Thu, 01 Mar 2001 23:03:26 -0500 From: Kevin Darcy To: namedroppers@ops.ietf.org Subject: Re: Automation of secondary DNS servers References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jesper G. Hoy wrote: > Looking for feedback - and possibly assistance with composing an RFC. > > Please let me know if I have missed an existing RFC on this topic. > > A lot of our customers (we write and sell DNS server software) have asked us > about a way to automatically create (and delete) zones on secondary servers. > Preferably through some type of signaling from the primary and a periodic > synchronize mechanism. > > This would greatly ease administration, as zone administration could be done > entirely on the primary server > And the chance of lame delegations on secondary servers would be > significantly reduced. > > Currently each new zone must be created on both the primary and all > secondary servers (same for deletions). > > The Notify OpCode (RFC1996) could easily be adopted for the "signaling" from > primary to secondary, but a new "zone list transfer" mechanism for periodic > synchronization would probably have to be devised. > > Obviously we could implement a proprietary system, but since secondaries are > (or should be) off-site chances are that different software is used. > So to ensure cross-implementation compatibility I think a standard for > something like this would be very appropriate. Why bother with a "zone list transfer" mechanism? Just beef up NOTIFY with some crypto-authentication and more intelligent and long-term retry logic, and servers should be able to rely on it for auto-creation of slave zones. Slave-zone deletions can be handled any number of ways, e.g. a) delete on expiration, b) delete if master responds non-authoritatively X number of times, c) delete if master answers non-authoritatively for Y interval of time. Other than the NOTIFY extensions themselves, none of this should require any protocol changes, since zone-configuration maintenance is pretty much left up to the implementations anyway. - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Mar 2 07:26:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27168 for ; Fri, 2 Mar 2001 07:26:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Yo9S-000FGU-00 for namedroppers-data@psg.com; Fri, 02 Mar 2001 03:55:14 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14Yo9R-000FGO-00 for namedroppers@ops.ietf.org; Fri, 02 Mar 2001 03:55:13 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14Yo9R-000OgB-00 for namedroppers@ops.ietf.org; Fri, 02 Mar 2001 03:55:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: "Mike Macgowan" cc: namedroppers@ops.ietf.org Subject: Re: DNS Label Intelligence and Management System In-reply-to: Your message of "Thu, 01 Mar 2001 19:59:00 MST." <01a501c0a2c4$bc5c28e0$c8026b83@home.com> Date: Fri, 02 Mar 2001 15:19:26 +0700 Message-ID: <1449.983521166@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Please, no, not another attempt to turn the DNS into some kind of directory system. The namedroppers list has been around a very long time, it is one of the older mailing lists on the internet. The resent past is suggesting that senility has arrived... kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Mar 7 09:49:12 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06170 for ; Wed, 7 Mar 2001 09:49:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14aeZZ-0002Fi-00 for namedroppers-data@psg.com; Wed, 07 Mar 2001 06:05:49 -0800 Received: from mg-20425422-73.ricochet.net ([204.254.22.73] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14aeZW-0002Fc-00 for namedroppers@ops.ietf.org; Wed, 07 Mar 2001 06:05:48 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14aeZP-0001TB-00 for namedroppers@ops.ietf.org; Wed, 07 Mar 2001 09:05:39 -0500 Message-Id: <200103071237.HAA00764@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-apl-rr-02.txt Date: Wed, 07 Mar 2001 07:37:19 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : A DNS RR Type for Lists of Address Prefixes (APL RR) Author(s) : P. Koch Filename : draft-ietf-dnsext-apl-rr-02.txt Pages : 7 Date : 06-Mar-01 The Domain Name System is primarily used to translate domain names into IPv4 addresses using A RRs. Several approaches exist to describe networks or address ranges. This document specifies a new DNS RR type 'APL' for address prefix lists. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-apl-rr-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-apl-rr-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-apl-rr-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010306125258.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-apl-rr-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-apl-rr-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010306125258.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Mar 8 08:16:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA25130 for ; Thu, 8 Mar 2001 08:16:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14azla-000FdL-00 for namedroppers-data@psg.com; Thu, 08 Mar 2001 04:43:38 -0800 Received: from [147.28.4.2] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14azlY-000FdF-00 for namedroppers@ops.ietf.org; Thu, 08 Mar 2001 04:43:37 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14azlY-0002Cy-00 for namedroppers@ops.ietf.org; Thu, 08 Mar 2001 07:43:36 -0500 Message-Id: <200103081154.GAA22001@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dhcid-rr-02.txt Date: Thu, 08 Mar 2001 06:54:54 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : A DNS RR for encoding DHCP information Author(s) : M. Stapp, T. Lemon, A. Gustafsson Filename : draft-ietf-dnsext-dhcid-rr-02.txt Pages : 8 Date : 07-Mar-01 A situation can arise where multiple DHCP clients request the same DNS name from their (possibly distinct) DHCP servers. To resolve such conflicts, 'Resolution of DNS Name Conflicts'[7] proposes storing client identifiers in the DNS to unambiguously associate domain names with the DHCP clients 'owning' them. This memo defines a distinct RR type for use by DHCP servers, the 'DHCID' RR. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dhcid-rr-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dhcid-rr-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dhcid-rr-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010307141746.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dhcid-rr-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dhcid-rr-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010307141746.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Mar 8 08:16:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA25131 for ; Thu, 8 Mar 2001 08:16:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14azle-000FdT-00 for namedroppers-data@psg.com; Thu, 08 Mar 2001 04:43:42 -0800 Received: from [147.28.4.2] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14azld-000FdN-00 for namedroppers@ops.ietf.org; Thu, 08 Mar 2001 04:43:42 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14azle-0002D1-00 for namedroppers@ops.ietf.org; Thu, 08 Mar 2001 07:43:42 -0500 Message-Id: <200103081154.GAA22013@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-gss-tsig-02.txt Date: Thu, 08 Mar 2001 06:54:59 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : GSS Algorithm for TSIG (GSS-TSIG) Author(s) : S. Kwan, P. Garg, J. Gilroy, L. Esibov, R. Hall Filename : draft-ietf-dnsext-gss-tsig-02.txt Pages : 21 Date : 07-Mar-01 The TSIG protocol provides transaction level authentication for DNS. TSIG is extensible through the definition of new algorithms. This document specifies an algorithm based on the Generic Security Service Application Program Interface (GSS-API) (RFC2743). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-gss-tsig-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-gss-tsig-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-gss-tsig-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010307141756.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-gss-tsig-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-gss-tsig-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010307141756.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Mar 13 12:14:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24074 for ; Tue, 13 Mar 2001 12:14:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14crsT-0008QG-00 for namedroppers-data@psg.com; Tue, 13 Mar 2001 08:42:29 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14crsS-0008QA-00 for namedroppers@ops.ietf.org; Tue, 13 Mar 2001 08:42:28 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14crsS-000NUa-00 for namedroppers@ops.ietf.org; Tue, 13 Mar 2001 08:42:28 -0800 Message-Id: <5.0.2.1.0.20010313113507.03253ec0@gatt.dc.ogud.com> X-Sender: post@gatt.dc.ogud.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 13 Mar 2001 11:35:43 -0500 To: namedroppers@ops.ietf.org From: Olafur Gudmundsson Subject: DNSEXT WGLC: AXFR Clarify Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This document formalizes the definition of Zone transfer protocol that was unspecified in RFC1035. This document formalizes the zone transfer protocol in accordance with the fielded DNS server software. This WG last call ends March 29'th 2001. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-axfr-clarify-01.txt This draft is on standards track, if you disagree with that please state why in your response. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Mar 13 12:14:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24085 for ; Tue, 13 Mar 2001 12:14:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14crsO-0008Q6-00 for namedroppers-data@psg.com; Tue, 13 Mar 2001 08:42:24 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14crsN-0008Q0-00 for namedroppers@ops.ietf.org; Tue, 13 Mar 2001 08:42:23 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14crsN-000NUO-00 for namedroppers@ops.ietf.org; Tue, 13 Mar 2001 08:42:23 -0800 Message-Id: <5.0.2.1.0.20010313113429.0324e540@gatt.dc.ogud.com> X-Sender: post@gatt.dc.ogud.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 13 Mar 2001 11:35:03 -0500 To: namedroppers@ops.ietf.org From: Olafur Gudmundsson Subject: DNSEXT WG Last Call: AD is Secure Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This document clarifies/updates certain sections of RFC2535 redefines/restricts the use of the AD bit in DNS header to be only set when server has cryptographically verified the answer. The reason for this is to make allow clients to take advantage of server that is willing to perform cryptographic checks for client. This WG last call ends March 29'th 2001. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ad-is-secure-01.txt This draft is on standards track, if you disagree with that please state why in your response. Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Mar 13 12:15:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24110 for ; Tue, 13 Mar 2001 12:15:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14crsZ-0008QO-00 for namedroppers-data@psg.com; Tue, 13 Mar 2001 08:42:35 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14crsY-0008QI-00 for namedroppers@ops.ietf.org; Tue, 13 Mar 2001 08:42:34 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14crsY-000NUl-00 for namedroppers@ops.ietf.org; Tue, 13 Mar 2001 08:42:34 -0800 Message-Id: <5.0.2.1.0.20010313113623.03253060@gatt.dc.ogud.com> X-Sender: post@gatt.dc.ogud.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 13 Mar 2001 11:37:08 -0500 To: namedroppers@ops.ietf.org From: Olafur Gudmundsson Subject: DNSEXT WGLC: NO record Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This document proposes an alternate mechanism to NXT records to give authenticated denial of existence answers. This proposal attempts to address many of the shortcomings of NXT in a different way: - NO record encodes all names as digests using SHA-1 - NO records are all stored in ._no. name space thus avoiding the two NXT sets at the delegation point. - NO doubles the number of names in a zone. This document obsoletes the NXT record, thus updates RFC2535. This WG last call ends April 4'th 2001. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-not-existing-rr.00.txt to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Mar 13 12:17:06 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24143 for ; Tue, 13 Mar 2001 12:17:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14crsd-0008QX-00 for namedroppers-data@psg.com; Tue, 13 Mar 2001 08:42:39 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14crsd-0008QR-00 for namedroppers@ops.ietf.org; Tue, 13 Mar 2001 08:42:39 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14crsd-000NUz-00 for namedroppers@ops.ietf.org; Tue, 13 Mar 2001 08:42:39 -0800 Message-Id: <5.0.2.1.0.20010313113546.032531a0@gatt.dc.ogud.com> X-Sender: post@gatt.dc.ogud.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 13 Mar 2001 11:36:20 -0500 To: namedroppers@ops.ietf.org From: Olafur Gudmundsson Subject: DNSEXT WGLC: DNSSEC Roadmap Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk DNSEXT WGLC: DNSSEC Road map This document explains how the various working group documents related to DNSSEC fit together and what updates what. This WG last call ends March 29'th 2001. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-roadmap-02.txt This draft is to be published as informational RFC, if you disagree with that please state why in your response. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Mar 13 19:28:13 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00879 for ; Tue, 13 Mar 2001 19:28:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14cyh2-000GMs-00 for namedroppers-data@psg.com; Tue, 13 Mar 2001 15:59:08 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14cyh2-000GMm-00 for namedroppers@ops.ietf.org; Tue, 13 Mar 2001 15:59:08 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14cyh2-000A9e-00 for namedroppers@ops.ietf.org; Tue, 13 Mar 2001 15:59:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200103131906.OAA26316@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , IANA Cc: Internet Architecture Board Cc: namedroppers@ops.ietf.org From: The IESG Subject: Protocol Action: DNSSEC and IPv6 A6 aware server/resolver message size requirements to Proposed Standard Date: Tue, 13 Mar 2001 14:06:32 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The IESG has approved the Internet-Draft 'DNSSEC and IPv6 A6 aware server/resolver message size requirements' as a Proposed Standard. This document is the product of the DNS Extensions Working Group. The IESG contact persons are Erik Nordmark and Thomas Narten. Technical Summary This document mandates support for EDNS0 in DNS entities claiming to support either DNS Security Extensions or A6 records. This requirement is necessary because these new features increase the size of DNS messages. If EDNS0 is not supported fall back to TCP will happen, having a detrimental impact on query latency and DNS server load. This document updates [RFC2535] and [RFC2874], by adding new requirements. Working Group Summary There was consensus in the WG for advancing this document. Protocol Quality The specification has been reviewed for the IESG by Erik Nordmark. Note to RFC Editor: Please add the following text at the top of page 4 (near end of Section 4): The current text: The IPv6 datagrams should be 1024 octets, unless the MTU of the path is known. Should be extended to read: The IPv6 datagrams should be 1024 octets, unless the MTU of the path is known. (Note that this is smaller than the minimum IPv6 MTU to allow for some extension headers and/or encapsulation without exceeding the minimum MTU.) to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Mar 14 00:39:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA05229 for ; Wed, 14 Mar 2001 00:39:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14d3Yj-000ODr-00 for namedroppers-data@psg.com; Tue, 13 Mar 2001 21:10:53 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14d3Yj-000ODl-00 for namedroppers@ops.ietf.org; Tue, 13 Mar 2001 21:10:53 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14d3Yi-000ITf-00 for namedroppers@ops.ietf.org; Tue, 13 Mar 2001 21:10:52 -0800 Date: Tue, 13 Mar 2001 21:00:52 -0800 (PST) From: Brian Wellington To: Olafur Gudmundsson Cc: Subject: Re: DNSEXT WGLC: NO record In-Reply-To: <5.0.2.1.0.20010313113623.03253060@gatt.dc.ogud.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 13 Mar 2001, Olafur Gudmundsson wrote: > This document proposes an alternate mechanism to NXT records to give > authenticated denial of existence answers. This proposal attempts to > address many of the shortcomings of NXT in a different way: > - NO record encodes all names as digests using SHA-1 > - NO records are all stored in ._no. name space thus avoiding > the two NXT sets at the delegation point. > - NO doubles the number of names in a zone. > > This document obsoletes the NXT record, thus updates RFC2535. I'm sure it's been said many times before, but it seems like a bad idea to obsolete the NXT record before there's any real operational experience with DNSSEC. Replacing NXT with NO would take a non-trivial amount of time and effort. Also, a problem with the NO draft (as well as other drafts, including opt-in) is that there's no way to specify security characteristics of the zone. Having a resolver support either NO and NXT is hard enough; supporting both with no method of determining which is used for any specific zone is much worse. The SEC RR proposed by Ed Lewis a few years ago would work, and it or something like it needs to be introduced again before specifying alternate mechanisms for authenticated denial. It hasn't been conclusively shown that replacing NXT with NO has enough benefits to outweigh the problems. I don't see a problem with NO continuing as a working group draft, and possibly becoming a standard in the future, but I don't think now is the right time. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Mar 14 05:51:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA21896 for ; Wed, 14 Mar 2001 05:51:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14d8T0-0006vL-00 for namedroppers-data@psg.com; Wed, 14 Mar 2001 02:25:18 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14d8Sx-0006v1-00 for namedroppers@ops.ietf.org; Wed, 14 Mar 2001 02:25:15 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14d8Sx-0001Pr-00 for namedroppers@ops.ietf.org; Wed, 14 Mar 2001 02:25:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Received: (qmail 24893 invoked by uid 1001); 14 Mar 2001 07:10:47 -0000 Date: 14 Mar 2001 07:10:47 -0000 Message-ID: <20010314071047.24164.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: AXFR Clarify References: <5.0.2.1.0.20010313113507.03253ec0@gatt.dc.ogud.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Any other RRs at the zone's apex are transmitted only once Not necessarily. BIND often transmits the same record many times in a zone transfer. > If the master server is unable or unwilling to provide a zone > transfer, it MUST respond with a single DNS message containing an > appropriate RCODE other than NOERROR. I object to this requirement, because (1) it is not necessary for interoperability and (2) it prohibits the behavior of my AXFR server, axfrdns, which simply closes the connection. AXFR is a local matter between a master and its authorized slaves. Clients without authorization have no business asking for AXFR. > RD Copy from request I object to this requirement, because (1) it is not necessary for interoperability and (2) it prohibits the behavior of axfrdns, which always sets RD to 0. I propose that we explicitly prohibit RD in AXFR requests. RD makes no sense for AXFR. > The slave MUST check the RCODE and abort the transfer if it is nonzero I object to this requirement, because (1) it is not necessary for interoperability and (2) it prohibits the behavior of my AXFR client, axfr-get, which doesn't bother checking the RCODE. > It SHOULD check the ID of the first message received and > abort the transfer if it does not match the ID of the request I object to this recommendation, because (1) it is not necessary for interoperability and (2) it discourages the behavior of axfr-get, which doesn't bother checking the IDs. > The initial message of a zone transfer response SHOULD have a question > section identical to that in the request I object to this recommendation, because (1) it is not necessary for interoperability and (2) it discourages the behavior of axfrdns, which doesn't bother repeating the question. > Slaves MUST ignore any authority section contents they may receive [ ... ] > The slave MUST ignore any unexpected RRs in the additional section I object to these two requirements, because (1) they are not necessary for interoperability and (2) they prohibit the behavior of axfr-get, which takes records from all sections. > Zone transfers MUST NOT contain RRs from the authoritative data of > zones other than the one being transferred or from the cache, even > when such RRs are pointed to by NS records in the zone being > transferred. Huh? Every record in the Domain Name System is part of the authoritative data of some zone. See RFC 1034, section 4.2. > The use of TSIG [RFC2845] for this purpose is RECOMMENDED I object to this recommendation. People protecting their communications with IPSEC, for example, shouldn't be encouraged to use TSIG. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Mar 14 14:21:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01814 for ; Wed, 14 Mar 2001 14:21:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14dGHG-000DZJ-00 for namedroppers-data@psg.com; Wed, 14 Mar 2001 10:45:42 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14dGHG-000DZD-00 for namedroppers@ops.ietf.org; Wed, 14 Mar 2001 10:45:42 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14dGHG-0005Ra-00 for namedroppers@ops.ietf.org; Wed, 14 Mar 2001 10:45:42 -0800 Date: Wed, 14 Mar 2001 13:46:07 -0500 (EST) From: Olafur Gudmundsson X-Sender: ogud@hlid.dc.ogud.com To: agenda@ietf.org cc: namedroppers@ops.ietf.org Subject: DNSEXT 50'th IETF agenda Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Agenda (2001/03/21) (as of 2001/03/14) 49'th IETF DNSEXT WG meeting Wednesday March 21'st 2001. 15:30 -- 17:30 Chairs: Randy Bush Olafur Gudmundsson Working group items 03 min Agenda bashing Randy Bush 10 min WG status Olafur Gudmundsson Documents that have passed WGLC. Nickname status Zone Secure RFC Editor Message Size RFC Editor APL IESG DNSSEC OK IESG RSA/SHA IESG RFC161[12] retirement IESG SRVbis WG chair IXFRbis Pending Interop report http://www.ietf.org/internet-drafts/draft-ietf-dnsext-zone-status-05.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-message-size-04.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-apl-rr-02.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-okbit-01.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rsa-02.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnsmib-historical-00.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2877bis-00.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ixfr-01.txt Documents in last call 03 min AXFR Clarify Andreas Gustafsson http://www.ietf.org/internet-drafts/draft-ietf-dnsext-axfr-clarify-01.txt 03 min DNSSEC Roadmap Glen Rose http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-roadmap-02.txt 05 min AD is Secure Brian Wellington 2http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ad-is-secure-01.txt 08 min NO record Simon Josefsson http://www.ietf.org/internet-drafts/draft-ietf-dnsext-not-existing-rr.00.txt2 Other working group documents 05 min ZONE and View options Michael Sawyer http://www.ietf.org/internet-drafts/draft-ietf-dnsext-edns-zone-option-00.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-edns-bind-view-option-00.txt 05 min ENDS handling unknown Michael Sawyer http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ends-unknown-00.txt 02 min EDNS0.5 Harald Alvestrand http://www.ietf.org/internet-drafts/draft-ietf-dnssext-ends0dot5-02.txt 05 min Inverse query obsolete David Lawrence http://www.ietf.org/internet-drafts/draft-ietf-dnsext-obsolete-iquery-00.txt 05 min Unknown RR types Andreas Gustafsson http://www.ietf/org/internet-drafts/draft-ietf-dnsext-unkown-rrs-00.txt 05 min GSSAPI-TSIG Levon Esibov http://www.ietf.org/internet-drafts/draft-ietf-dnsext-gss-tsig-02.txt 05 min DHCID RR Mark Stapp http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dhcid-rr-02.txt 05 min DNSSEC opt IN Mark Kosters http://www.ietf.org/internet-drafts/draft-kosters-dnsext-dnssec-opt-in-01.txt WG future: 10 min New charter discussion Olafur Gudmundsson 10 min RFC2535bis editing Olafur Gudmundsson Introduction of RFC2535bis editors and time-line New non WG documents 05 min NL.NL experiment Miek Gigben 05 min ECC KEY record type Donald Eastlake http://www.ietf.org/internet-drafts/draft-schroeppel-dnsind-ecc-02.txt 03 min Do not update TLD's Levon Esibov http://www.ietf.org/internet-drafts/draft-esibov-dnsext-dynupdtld-00.txt 05 min Top Level private label name Levon Esibov http://www.ietf.org/internet-drafts/draft-coffeystrain-dnsext-privatednstld-00.txt 10 min Label management proposal Michael L. Macgowan Jr. http://www.ietf.org/internet-drafts/draft-macgowan-dnsext-label-intel-manage-00.txt 03 min Wrap-up. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Mar 14 18:33:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA06477 for ; Wed, 14 Mar 2001 18:33:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14dK0w-000Ftc-00 for namedroppers-data@psg.com; Wed, 14 Mar 2001 14:45:06 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14dK0v-000FtS-00 for namedroppers@ops.ietf.org; Wed, 14 Mar 2001 14:45:05 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14dK0v-000C6V-00 for namedroppers@ops.ietf.org; Wed, 14 Mar 2001 14:45:05 -0800 Date: Wed, 14 Mar 2001 13:47:52 -0500 (EST) From: Olafur Gudmundsson X-Sender: ogud@hlid.dc.ogud.com To: namedroppers@ops.ietf.org Subject: Draft of Revised charter Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Comments please Olafur DNSEXT DNS Extensions Working group --------------------------------------------------- Charter Last Modified: 14-March-2001 Current Status: Active Working Group (being rechartered) Chair(s): Randy Bush Olafur Gudmundsson Internet Area Director(s): Thomas Narten Erik Nordmark Internet Area Advisor: Erik Nordmark Mailing Lists: General Discussion: namedroppers@ops.ietf.org To Subscribe: namedroppers-request@ops.ietf.org Archive: ftp://ftp.ops.ietf.org/pub/lists Description of Working Group: DNS is originally specified in RFC's 1034 and 1035, with subsequent updates. Within the scope of this WG are protocol issues, including message formats, message handling, and data formats. New work items and milestones may be added from time-to-time with the approval of the Working Group and the IESG. Issues surrounding the operation of DNS, recommendations concerning the configuration of DNS servers, and other issues with the use of the protocol are out of this Working Group's charter. These issues are considered in other venues, such as operational issues in the DNS Operations Working Group. Broad topics under consideration in DNSEXT are dynamic update, notify, zone transfers, security and adjustments to address the requirements of IPv6 addressing. Other issues that the working group will entertain are topics related to protocol changes to support for languages that can not be represented by US-ASCII. Security topics, mostly inherited from the erstwhile DNS Security Extensions Working Group, will be addressed in cooperation with the DNS Operations Working Group. The principal task within this Working Group is to advance several documents describing proposed extensions to DNS. Specific work items are: o Protocol clarifications and corrections for DNSSEC o DNS clarification and extensions DNS Server requirments DNS Resolver requirements o IPv6 support in DNS records and IPv6 DNS services o Specification of multicast DNS service Local link Multicast without DNS servers Enterprice wide with DNS servers o Extensions to DNS protocol required for Internationalized Domain Names. New work items may be added from time-to-time with the approval of the Working Group and the IESG. Goals and Milestones: Where there is no milestone for a work item mentioned above, the working group has not yet decided upon the priority for the item, or, in some cases, whether active work will be undertaken, and no target milestone has yet been set. Apr 01 Advance last updates for RFC2535 to IESG Apr 01 Advance SRV to draft standard. 2 Apr 01 Advance AXFR clarify to IESG Apr 01 RFC1995bis avanced to Draft standard Apr 01 Start rewrite of RFC2535 and related docs to reflect updates. May 01 Advance Notify (RFC19 May 01 Forward Unknown types to IESG Jun 01 Advance TSIG to Draft standard. Jun 01 Advance TKEY to Draft standard. Jun 01 Advance Clarify to Draft Standard Jul 01 Determine fate of "DNSSEC Opt-in plans" Jul 01 First WG last call on RFC2535-bis Jul 01 Advance RFC2308 (Neg Caching) to draft Standard Sep 01 Dynamic Update-bis advanced to IESG. Oct 01 Forward RFC2535-bis to IESG. Oct 01 Advance Secure Update RFC3007-bis to Draft standard. Dec 01 Forward Server requirements to IESG Dec 01 Forward Iquery obsolete to IESG. Feb 02 Forward IPv6 Dynamic update guidelines to IESG. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Mar 14 18:34:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA06504 for ; Wed, 14 Mar 2001 18:34:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14dKAI-000FyP-00 for namedroppers-data@psg.com; Wed, 14 Mar 2001 14:54:46 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14dKAI-000FyJ-00 for namedroppers@ops.ietf.org; Wed, 14 Mar 2001 14:54:46 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14dKAI-000CNf-00 for namedroppers@ops.ietf.org; Wed, 14 Mar 2001 14:54:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 14 Mar 2001 12:09:08 -0800 (PST) From: Brian Wellington To: "D. J. Bernstein" cc: Subject: Re: DNSEXT WGLC: AXFR Clarify In-Reply-To: <20010314071047.24164.qmail@cr.yp.to> Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 14 Mar 2001, D. J. Bernstein wrote: > > Any other RRs at the zone's apex are transmitted only once > > Not necessarily. BIND often transmits the same record many times in a > zone transfer. Not any modern version of BIND. And any version that does is noncompliant. > > RD Copy from request > > I object to this requirement, because (1) it is not necessary for > interoperability and (2) it prohibits the behavior of axfrdns, which > always sets RD to 0. > > I propose that we explicitly prohibit RD in AXFR requests. RD makes no > sense for AXFR. Yes, RD makes no sense on an AXFR query. But RFC 1035 (section 4.1.1) says: RD Recursion Desired - this bit may be set in a query and is copied into the response. The server is obviously not going to do a recursive AXFR, but the client really did request it, and the RD bit in the response should indicate what the client requested. > > The slave MUST check the RCODE and abort the transfer if it is nonzero > > I object to this requirement, because (1) it is not necessary for > interoperability and (2) it prohibits the behavior of my AXFR client, > axfr-get, which doesn't bother checking the RCODE. Then axfr-get is broken. There's no excuse for not doing a simple sanity check, especially since the contents of the message are meaningless unless RCODE is NOERROR. > > It SHOULD check the ID of the first message received and > > abort the transfer if it does not match the ID of the request > > I object to this recommendation, because (1) it is not necessary for > interoperability and (2) it discourages the behavior of axfr-get, which > doesn't bother checking the IDs. Again, this is a simple sanity check. Failing to check the ID opens a server to spoofing. This is also a SHOULD, so axfr-get is still compliant. > > The initial message of a zone transfer response SHOULD have a question > > section identical to that in the request > > I object to this recommendation, because (1) it is not necessary for > interoperability and (2) it discourages the behavior of axfrdns, which > doesn't bother repeating the question. I have no strong opinion on this. It's an arbitrary decision based on existing practice, and bind has been around much longer than axfrdns. It's also only a SHOULD. > > Slaves MUST ignore any authority section contents they may receive > [ ... ] > > The slave MUST ignore any unexpected RRs in the additional section > > I object to these two requirements, because (1) they are not necessary > for interoperability and (2) they prohibit the behavior of axfr-get, > which takes records from all sections. Why does axfr-get take records from all sections? That sounds broken. > > Zone transfers MUST NOT contain RRs from the authoritative data of > > zones other than the one being transferred or from the cache, even > > when such RRs are pointed to by NS records in the zone being > > transferred. > > Huh? Every record in the Domain Name System is part of the authoritative > data of some zone. See RFC 1034, section 4.2. Huh? Of course every record is in some zone. This says that zone transfers must only contain records from the zone being transferred, not from any zone. > > The use of TSIG [RFC2845] for this purpose is RECOMMENDED > > I object to this recommendation. People protecting their communications > with IPSEC, for example, shouldn't be encouraged to use TSIG. I agree. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Mar 14 20:16:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA07407 for ; Wed, 14 Mar 2001 20:16:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14dLnV-000Har-00 for namedroppers-data@psg.com; Wed, 14 Mar 2001 16:39:21 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14dLnU-000Hal-00 for namedroppers@ops.ietf.org; Wed, 14 Mar 2001 16:39:20 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14dLnU-000FLJ-00 for namedroppers@ops.ietf.org; Wed, 14 Mar 2001 16:39:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20010315003418.25656.qmail@softhome.net> References: <5.0.2.1.0.20010313113507.03253ec0@gatt.dc.ogud.com> <20010314071047.24164.qmail@cr.yp.to> In-Reply-To: <20010314071047.24164.qmail@cr.yp.to> From: adurch@softhome.net To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: AXFR Clarify Date: Thu, 15 Mar 2001 00:34:18 GMT Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit D. J. Bernstein writes: >> If the master server is unable or unwilling to provide a zone >> transfer, it MUST respond with a single DNS message containing an >> appropriate RCODE other than NOERROR. > I object to this requirement, because (1) it is not necessary for > interoperability and (2) it prohibits the behavior of my AXFR server, > axfrdns, which simply closes the connection. > > AXFR is a local matter between a master and its authorized slaves. > Clients without authorization have no business asking for AXFR. What if an "used to be authorized" slave became unauthorized due to the master's misconfiguration? A little bit RCODE and NOERROR would be better than just simply connection closing. -- Aaron Durchgaloch -- Haifa High Tech Commerce R&D, Matam, IL-31905. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Mar 15 11:21:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02254 for ; Thu, 15 Mar 2001 11:21:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14dZq5-00097R-00 for namedroppers-data@psg.com; Thu, 15 Mar 2001 07:38:57 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14dZq4-00097K-00 for namedroppers@ops.ietf.org; Thu, 15 Mar 2001 07:38:56 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14dZq4-000EZW-00 for namedroppers@ops.ietf.org; Thu, 15 Mar 2001 07:38:56 -0800 Date: Thu, 15 Mar 2001 12:40:15 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Draft of Revised charter To: Olafur Gudmundsson Cc: namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Specific work items are: > o Protocol clarifications and corrections for DNSSEC Since the question recently came up it might make sense to add to the above bullet: Initially these clarifications will be done as separate RFCs which will later be folded into a revised RFC 2535 etc. > Apr 01 Advance last updates for RFC2535 to IESG Add "as separate specifications" > Apr 01 Start rewrite of RFC2535 and related docs to reflect updates. "to reflect the updates that have already been approved as RFCs"? (If the intent is that this work be 100% editorial, i.e. that the fixes that impact implementations have already been specified in RFCs, it would make sense to state that very explicitly to avoid lots of new requests for tweaks.) > May 01 Advance Notify (RFC19 Missing characters at end of line. Erik to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Mar 15 11:29:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02434 for ; Thu, 15 Mar 2001 11:29:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14dZwW-0009JN-00 for namedroppers-data@psg.com; Thu, 15 Mar 2001 07:45:36 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14dZwV-0009JG-00 for namedroppers@ops.ietf.org; Thu, 15 Mar 2001 07:45:35 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14dZwV-000Eli-00 for namedroppers@ops.ietf.org; Thu, 15 Mar 2001 07:45:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: namedroppers@ops.ietf.org Cc: bernarda@microsoft.com Subject: Question about mDNS Message-Id: <20010315214738Y.tomohide@japan-telecom.co.jp> Date: Thu, 15 Mar 2001 21:47:38 +0900 From: Tomohide Nagashima Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I have a question about mDNS(draft-ietf-dnsext-mdns-00.txt). 1) When node is attached with two or more subnetworks, and all node in these subnetworks shared same domain, how should do ? ex1) node that have same name are in differnt subnetworks: ---------- ---------- | | | | [A] [myhost] [A] ex2) one subnet, my host's name conflicts some node but another subnet does not: ---------- ---------- | | | | [A] [myhost] [myhost] I belived mDNS should be used just for node that have only one interface. but I cannot find some comment about it. some comment is needed. else, we must prepare some reaction for these two cases. 2) Why local name is made with FQDN , not with just hostname ? if original FQDN of myhost is "host.example.com." then local name is "host.example.com.local.arpa." but I thought this is too long. at 1st, I thought "host.local.arpa." . in original case, there must be some reason why we need FQDN. the reason may be two or more domains in same subnet. but I cannot enter such case. would you tell me such case ? Regards, ---- Tomohide Nagashima (tomohide@japan-telecom.co.jp) to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Mar 15 11:38:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02648 for ; Thu, 15 Mar 2001 11:38:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14da6e-0009RN-00 for namedroppers-data@psg.com; Thu, 15 Mar 2001 07:56:04 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14da6d-0009RH-00 for namedroppers@ops.ietf.org; Thu, 15 Mar 2001 07:56:03 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14da6d-000F42-00 for namedroppers@ops.ietf.org; Thu, 15 Mar 2001 07:56:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 15 Mar 2001 13:56:03 -0000 Message-ID: <20010315135603.13247.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: AXFR Clarify References: <20010314071047.24164.qmail@cr.yp.to> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit As I said, BIND often transmits the same record many times in its AXFR responses. But I was wrong when I said this could happen at the top of the zone. It happens for a glue A record used by many child zones. Brian Wellington writes: > zone transfers must only contain records from the zone being transferred, That's less restrictive than the current text, but I still object to it. Clients discard undesired records; servers don't have to. > Failing to check the ID opens a server to spoofing. False. TCP connections already have sequence numbers---and anyone who wants serious security for AXFR can run AXFR over IPSEC or ssh. You've already agreed that IPSEC-protected AXFR shouldn't bother with TSIG, so why do you think it should bother checking IDs? > Then axfr-get is broken. There's no excuse for not doing a simple sanity > check, especially since the contents of the message are meaningless unless > RCODE is NOERROR. axfr-get is working just fine. A properly constructed message doesn't _have_ any records unless RCODE is NOERROR; the zone transfer will end up being aborted. What I'm objecting to is your overly narrow view of how clients should check for errors. > The server is obviously not going to do a recursive AXFR, but the client > really did request it, and the RD bit in the response should indicate what > the client requested. Clients _don't_ do that. You are violating RFC 2119, section 6, second sentence, by demanding that my server go to extra effort for the sake of nonexistent slaves. In the meantime, of course, you _aren't_ demanding that servers stick to the one-answer format, even though there's still a huge installed base of clients that can't handle your multiple-answer format. [ repeating the question section at the start of the AXFR response ] > It's an arbitrary decision based on existing practice, It's a pointless recommendation that doesn't take full account of existing practice. > Why does axfr-get take records from all sections? Because it's the simplest strategy that works. Please stop trying to throw roadblocks in the way of competing implementations. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Mar 15 14:22:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06075 for ; Thu, 15 Mar 2001 14:22:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14dcS2-000BDu-00 for namedroppers-data@psg.com; Thu, 15 Mar 2001 10:26:18 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14dcS1-000BDo-00 for namedroppers@ops.ietf.org; Thu, 15 Mar 2001 10:26:17 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14dcS1-000JPN-00 for namedroppers@ops.ietf.org; Thu, 15 Mar 2001 10:26:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200103151825.TAA25485@grimsvotn.TechFak.Uni-Bielefeld.DE> To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: AXFR Clarify In-reply-to: Your message of "Tue, 13 Mar 2001 11:35:43 EST." <5.0.2.1.0.20010313113507.03253ec0@gatt.dc.ogud.com> Date: Thu, 15 Mar 2001 19:25:34 +0100 From: Peter Koch Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > 4. Glue The term "glue" unfortunately has been fuzzy for quite some time now and seems to be used in slightly different meanings throughout DNS literature - RFCs and other. This is at least a major source of confusion whenever you try to teach someone DNS. The following paragraph essentially (and en passant) opens the definition to "any nonauthoritative data associated with the zone", so I'd like to suggest the heading be renamed to "Out of zone data". > A master transmitting a zone transfer MUST include the full set of > zone data it loaded from the zone's master file, from an incoming > zone transfer, or other similar means of configuring zone data. This > includes any nonauthoritative data ("glue") associated with the zone Similar here (and further below), remove the term in parentheses. > by being present in the zone's master file or the incoming transfer > along with the authoritative data. This glue data includes any > configured zone data obscured by zone cuts or otherwise outside the > zone in case; it is not limited to RRs pointed to by NS records. > > The glue RRs are transmitted in the answer section along with the > authoritative data. This is unlike ordinary DNS responses where glue > is transmitted in the authority or additional section. Strictly speaking, "ordinary", i.e. non-AXFR responses do not have any glue at all, because that term is restricted to the zone file or the zone itself, isn't it? > Zone transfers MUST NOT contain RRs from the authoritative data of > zones other than the one being transferred or from the cache, even > when such RRs are pointed to by NS records in the zone being > transferred. You want to say that a master MUST NOT mix different sources for the outgoing AXFR? > A slave receiving a zone transfer MUST accept glue data and recognize > it as such; glue MUST NOT be treated as authoritative data nor > entered into the cache. Note that classifying an RR as glue or non- [Side note: Servers do not have caches, resolvers do.] So, under which conditions may these out-of-zone RRs be handed out again? The slave MUST NOT put the out-of-zone data in an answer section of non-AXFR responses? The slave MAY use it in the additional section of a response iff it corresponds to a query for authoritative data from this particular zone? > glue may not be possible until the entire zone has been received so > that the zone cuts defined by the zone's NS records can be > determined. Glue data that is not below the zone origin ("cross-zone > glue") MAY be discarded by the slave. Unless, however, the slave is also a master for the zone (which it is, if *anyone* was allowed to AXFR the zone from the slave). >From the above I read the following motivation: The information (RRs) associated with the zone at the primary master shall remain the same, complete and unaltered regardless of how many and which intermediate masters/slaves are involved and especially regardless of what other zones those intermediate masters/slaves do or do not serve. Justification of any such association is out of the scope of this document, RRs are associated with the zone by appearing in the zone file at and being accepted by the primary master. Provided that this summary matches Andreas' intent, would you mind adding a sentence like this? -Peter to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Mar 15 20:32:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11862 for ; Thu, 15 Mar 2001 20:32:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14diRu-000F4R-00 for namedroppers-data@psg.com; Thu, 15 Mar 2001 16:50:34 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14diRu-000F4L-00 for namedroppers@ops.ietf.org; Thu, 15 Mar 2001 16:50:34 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14diRu-00049S-00 for namedroppers@ops.ietf.org; Thu, 15 Mar 2001 16:50:34 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 15 Mar 2001 16:46:47 -0800 (PST) From: Brian Wellington To: "D. J. Bernstein" cc: Subject: Re: DNSEXT WGLC: AXFR Clarify In-Reply-To: <20010315135603.13247.qmail@cr.yp.to> Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 15 Mar 2001, D. J. Bernstein wrote: > As I said, BIND often transmits the same record many times in its AXFR > responses. But I was wrong when I said this could happen at the top of > the zone. It happens for a glue A record used by many child zones. OK. I know bind 9 does not do this. If bind 8 or 4 does, they're not compliant. > > zone transfers must only contain records from the zone being transferred, > > That's less restrictive than the current text, but I still object to it. They sound about the same to me. > Clients discard undesired records; servers don't have to. What exactly do you mean here? > > Failing to check the ID opens a server to spoofing. > > False. TCP connections already have sequence numbers---and anyone who > wants serious security for AXFR can run AXFR over IPSEC or ssh. You've > already agreed that IPSEC-protected AXFR shouldn't bother with TSIG, so > why do you think it should bother checking IDs? Because it's there, and should be the same as the query. I would ask why you wouldn't check them? It can't be for performance reasons, since it's an integer compare. > > Then axfr-get is broken. There's no excuse for not doing a simple sanity > > check, especially since the contents of the message are meaningless unless > > RCODE is NOERROR. > > axfr-get is working just fine. A properly constructed message doesn't > _have_ any records unless RCODE is NOERROR; the zone transfer will end > up being aborted. What I'm objecting to is your overly narrow view of > how clients should check for errors. Yes, a properly constructed message with a non-NOERROR rcode will not contain any records. But that's still not a good reason to not check. I'm not sure how "sanity check everything" is a narrow view. It sounds like robust programming to me. > > The server is obviously not going to do a recursive AXFR, but the client > > really did request it, and the RD bit in the response should indicate what > > the client requested. > > Clients _don't_ do that. You are violating RFC 2119, section 6, second > sentence, by demanding that my server go to extra effort for the sake of > nonexistent slaves. I wouldn't call copying one bit "extra effort", but I also don't think this is important enough to argue about, since the RD bit should be ignored by the slave anyway. > In the meantime, of course, you _aren't_ demanding that servers stick to > the one-answer format, even though there's still a huge installed base > of clients that can't handle your multiple-answer format. While ISC BIND was the first implementation to use many-answers (in wide use), it's not "our format". Nowhere in 1034/1035 is is stated that AXFRs must only put one record in each message. Any clients that cannot accept many-answer format are not compliant with this spec. > [ repeating the question section at the start of the AXFR response ] > > It's an arbitrary decision based on existing practice, > > It's a pointless recommendation that doesn't take full account of > existing practice. It's a recommendation. Your server can ignore it and still be compliant. > > Why does axfr-get take records from all sections? > > Because it's the simplest strategy that works. Please stop trying to > throw roadblocks in the way of competing implementations. In my opinion, it's simpler to only read records from the answer section, since it requires less code, and there shouldn't be anything useful in other sections. I have no problem with competing implementations, as long as the specifications are written from a correctness point of view, not a "let's make this server compliant" point of view. Note that most versions of BIND are _not_ compliant with this spec. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Mar 15 21:49:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA13315 for ; Thu, 15 Mar 2001 21:49:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14djrE-000FxU-00 for namedroppers-data@psg.com; Thu, 15 Mar 2001 18:20:48 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14djrD-000FxO-00 for namedroppers@ops.ietf.org; Thu, 15 Mar 2001 18:20:47 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14djrD-0006gH-00 for namedroppers@ops.ietf.org; Thu, 15 Mar 2001 18:20:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200103160212.f2G2Cjh55805@drugs.dv.isc.org> To: Brian Wellington Cc: "D. J. Bernstein" , namedroppers@ops.ietf.org From: Mark.Andrews@nominum.com Subject: Re: DNSEXT WGLC: AXFR Clarify In-reply-to: Your message of "Thu, 15 Mar 2001 16:46:47 -0800." Date: Fri, 16 Mar 2001 13:12:45 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On top of this RFC 103[45] currently allow you to have multiple queries outstanding on a TCP connection, including AXFR and IXFR. The server is currently free to return answers to these in any order it cares to. Potentially you could even multiplex multiple AXFR/IXFR streams, sorting the answers by id. This is all currently allowed, even if there are no implementations that do this. Sending multiple AXFR requests (whether by queuing or multiplexing) on the one socket should provide similar gains to sending multiple HTTP requests on the one socket. We should not be braking the ability to do this. Not sending a negative answers breaks the ability to have multiple AXFR's on one socket. Not check response ID's breaks the ability to have multiple outstanding queries. Also on the contention that AXFR is only for slaves, there are currently people who have RRsets that are bigger than what will fit in a DNS/TCP message. The only way to retrieve these RRsets it to perform a AXFR and extract the RRset from the response. Mark -- Mark Andrews, Nominum Inc. 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Mar 16 08:42:02 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA03336 for ; Fri, 16 Mar 2001 08:42:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14dtyv-000OdC-00 for namedroppers-data@psg.com; Fri, 16 Mar 2001 05:09:25 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14dtyu-000Od6-00 for namedroppers@ops.ietf.org; Fri, 16 Mar 2001 05:09:24 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14dtyu-000Nqf-00 for namedroppers@ops.ietf.org; Fri, 16 Mar 2001 05:09:24 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 16 Mar 2001 11:26:08 -0000 Message-ID: <20010316112608.17239.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: AXFR Clarify References: <200103160212.f2G2Cjh55805@drugs.dv.isc.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mark.Andrews@nominum.com writes: > Also on the contention that AXFR is only for slaves, there > are currently people who have RRsets that are bigger than > what will fit in a DNS/TCP message. The only way to retrieve > these RRsets it to perform a AXFR and extract the RRset > from the response. The standard query procedure, as specified in RFC 1123 section 6.1.3.2, is to try DNS-over-UDP first, and then to try DNS-over-TCP if the UDP response was truncated and TCP is supported. This procedure does not include your absurd DNS-over-AXFR. The configurations you refer to simply don't work. > Not sending a negative answers breaks the ability to have > multiple AXFR's on one socket. False. The client can try sending multiple AXFRs. In the extremely rare case that the connection is abruptly closed, the client can try again, one AXFR at a time. > Not check response ID's breaks the ability to have multiple > outstanding queries. If multiplexing is allowed, yes, these nonexistent multiplexing clients will have to check IDs. Now, why do you think that _my_ client should check IDs? It uses a new TCP connection for each zone transfer. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Mar 16 08:42:04 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA03339 for ; Fri, 16 Mar 2001 08:42:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14dttP-000Oa6-00 for namedroppers-data@psg.com; Fri, 16 Mar 2001 05:03:43 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14dttP-000Oa0-00 for namedroppers@ops.ietf.org; Fri, 16 Mar 2001 05:03:43 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14dttL-000Ngp-00 for namedroppers@ops.ietf.org; Fri, 16 Mar 2001 05:03:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 16 Mar 2001 10:35:42 -0000 Message-ID: <20010316103542.14117.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Extra records in zone transfers References: <20010315135603.13247.qmail@cr.yp.to> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 1. Suppose I'm a slave transferring the princeton.edu zone. I will discard aol.com information from the princeton.edu servers. This is required for security: the princeton.edu servers aren't authorized to provide aol.com information. Once you accept that this is the slave's responsibility, you have no reason to demand that the princeton.edu AXFR servers omit aol.com information. 2. Suppose I'm transferring both princeton.edu and cs.princeton.edu. I will discard all princeton.edu AXFR results below cs.princeton.edu, in favor of the cs.princeton.edu AXFR results. To the extent that there's a difference, the princeton.edu servers are wrong. For example, the princeton.edu servers say cs.princeton.edu NS {cs.princeton.edu,engram.cs.princeton.edu}, while the cs.princeton.edu servers say cs.princeton.edu NS {dns1,dns2}.cs.princeton.edu. If someone asks me for the cs.princeton.edu NS records, I'm going to report {dns1,dns2}.cs.princeton.edu. Once you accept that this is the slave's responsibility, you have no reason to demand that the princeton.edu AXFR servers omit unnecessary cs.princeton.edu information. Note that my decision to discard the cs.princeton.edu NS records from the princeton.edu servers won't happen when I transfer princeton.edu: I don't know at that point whether I'm also transferring cs.princeton.edu. 3. As a convenience to the administrator, my servers automatically treat all records from child zones (and grandchild zones and so on) as non-authoritative records for the parent zone. When axfrdns has both princeton.edu and cs.princeton.edu, for example, its AXFR results for princeton.edu won't include anything in aol.com but will include everything in cs.princeton.edu. This works just fine. Once again: slaves discard undesired records; servers don't have to. Brian Wellington writes: > They sound about the same to me. The text says ``MUST NOT contain RRs from the authoritative data of zones other than the one being transferred.'' What you're missing, apparently, is that a record can be from the zone being transferred _and_ from another zone. The text prohibits child NS records that are copied to the parent zone, for example. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Mar 16 08:42:08 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA03358 for ; Fri, 16 Mar 2001 08:42:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14dty4-000Obi-00 for namedroppers-data@psg.com; Fri, 16 Mar 2001 05:08:32 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14dty4-000Obc-00 for namedroppers@ops.ietf.org; Fri, 16 Mar 2001 05:08:32 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14dty4-000NpE-00 for namedroppers@ops.ietf.org; Fri, 16 Mar 2001 05:08:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 16 Mar 2001 10:59:53 -0000 Message-ID: <20010316105953.20572.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: AXFR Clarify References: <20010315135603.13247.qmail@cr.yp.to> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ this is verging on material more appropriate for weenie-war@ops.ietf.org or bind-users than namedroppers. last message in this vein please -- rb ] Brian Wellington writes: > Note that most versions of BIND are _not_ compliant with this spec. That's a rather shocking statement. Your coworker has presented this document to us as a clarification, a ``more complete definition of the protocol.'' He claims to have ``codified existing practice.'' But now you seem to be saying that you don't care whether the document accurately describes existing practice. > I'm not sure how "sanity check everything" is a narrow view. It sounds > like robust programming to me. So why does this document recommend that slaves ignore IDs in messages past the first? Seems rather inconsistent. Why aren't you asking for ``sanity checks'' of all those IDs, just like the first one? The answer, of course, is that unnecessary checks aren't ``robust programming.'' They're interoperability hazards. What's narrow about your view is that you don't see anything beyond BIND. You're trying to force everyone to do exactly what BIND 9 does, in violation of RFC 2119, instead of focusing on interoperability. > In my opinion, it's simpler to only read records from the answer section, > since it requires less code, False. I simply read records to the end of the packet. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Mar 16 11:13:03 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05957 for ; Fri, 16 Mar 2001 11:13:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14dwJi-0000ut-00 for namedroppers-data@psg.com; Fri, 16 Mar 2001 07:39:02 -0800 Received: from [147.28.4.2] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14dwJg-0000um-00 for namedroppers@ops.ietf.org; Fri, 16 Mar 2001 07:39:01 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14dvBv-0000t2-00 for namedroppers@ops.ietf.org; Fri, 16 Mar 2001 06:26:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200103161409.f2GE94h59368@drugs.dv.isc.org> To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org From: Mark.Andrews@nominum.com Subject: Re: DNSEXT WGLC: AXFR Clarify In-reply-to: Your message of "16 Mar 2001 11:26:08 -0000." <20010316112608.17239.qmail@cr.yp.to> Date: Sat, 17 Mar 2001 01:09:03 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Mark.Andrews@nominum.com writes: > > Also on the contention that AXFR is only for slaves, there > > are currently people who have RRsets that are bigger than > > what will fit in a DNS/TCP message. The only way to retrieve > > these RRsets it to perform a AXFR and extract the RRset > > from the response. > > The standard query procedure, as specified in RFC 1123 section 6.1.3.2, > is to try DNS-over-UDP first, and then to try DNS-over-TCP if the UDP > response was truncated and TCP is supported. > > This procedure does not include your absurd DNS-over-AXFR. The > configurations you refer to simply don't work. They only "don't work" if you block AXFR. Using AXFR to retrieve a RRset that doesn't fit in a TCP response is a logical action to take if you need to see the contents of the RRset. > > > Not sending a negative answers breaks the ability to have > > multiple AXFR's on one socket. > > False. The client can try sending multiple AXFRs. In the extremely rare > case that the connection is abruptly closed, the client can try again, > one AXFR at a time. As I said it breaks the ability to get multiple AXFR responses on one socket. > > > Not check response ID's breaks the ability to have multiple > > outstanding queries. > > If multiplexing is allowed, yes, these nonexistent multiplexing clients > will have to check IDs. Now, why do you think that _my_ client should > check IDs? It uses a new TCP connection for each zone transfer. We are describing how to build robust clients. Give the errors I've see servers produce I think that checking the query id is one of the cheaper checks that can be done. Mark > > ---Dan > > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. -- Mark Andrews, Nominum Inc. 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Mar 16 14:38:09 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09153 for ; Fri, 16 Mar 2001 14:38:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14dzgW-0006o9-00 for namedroppers-data@psg.com; Fri, 16 Mar 2001 11:14:48 -0800 Received: from [147.28.4.2] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14dzgV-0006o0-00 for namedroppers@ops.ietf.org; Fri, 16 Mar 2001 11:14:47 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14dzgT-00011V-00 for namedroppers@ops.ietf.org; Fri, 16 Mar 2001 11:14:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 16 Mar 2001 11:12:41 -0800 (PST) Message-Id: <200103161912.LAA17037@gulag.araneus.fi> To: "D. J. Bernstein" CC: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: AXFR Clarify In-Reply-To: <20010316105953.20572.qmail@cr.yp.to> References: <20010315135603.13247.qmail@cr.yp.to> <20010316105953.20572.qmail@cr.yp.to> From: gson@nominum.com (Andreas Gustafsson) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Brian Wellington writes: > > Note that most versions of BIND are _not_ compliant with this spec. > > That's a rather shocking statement. > > Your coworker has presented this document to us as a clarification, a > ``more complete definition of the protocol.'' He claims to have > ``codified existing practice.'' But now you seem to be saying that you > don't care whether the document accurately describes existing practice. The draft attempts to codify *reasonable* existing practice. Some existing implementations are simply broken. For example, BIND 4 sends AXFR responses where some of the messages have QR=0 and others have QR=1, violating the fundamental property of the DNS protocol that all response messages have QR=1. I do not believe that this particular existing brokenness should be codified. Instead, the draft explicitly forbids it, thereby making BIND 4 noncompliant. On the other hand, the draft does account for existing practice in that it recommends against checking the QR bit and most other header fields since they are known to be incorrectly transmitted by existing implementations. > So why does this document recommend that slaves ignore IDs in messages > past the first? Seems rather inconsistent. Why aren't you asking for > ``sanity checks'' of all those IDs, just like the first one? Because existing implementations are known to send incorrect IDs in messages other than the first. -- Andreas Gustafsson, gson@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Mar 16 14:38:10 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09154 for ; Fri, 16 Mar 2001 14:38:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14dzcZ-0006gK-00 for namedroppers-data@psg.com; Fri, 16 Mar 2001 11:10:43 -0800 Received: from [147.28.4.2] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14dzcX-0006gE-00 for namedroppers@ops.ietf.org; Fri, 16 Mar 2001 11:10:42 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14dzcV-000110-00 for namedroppers@ops.ietf.org; Fri, 16 Mar 2001 11:10:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Brian Wellington Cc: Olafur Gudmundsson , Subject: Re: DNSEXT WGLC: NO record References: From: Simon Josefsson In-Reply-To: (Brian Wellington's message of "Tue, 13 Mar 2001 21:00:52 -0800 (PST)") User-Agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/21.0.100 Date: 16 Mar 2001 18:44:04 +0100 Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian Wellington writes: > I'm sure it's been said many times before, but it seems like a bad idea to > obsolete the NXT record before there's any real operational experience > with DNSSEC. Replacing NXT with NO would take a non-trivial amount of > time and effort. I agree that more operational experience of DNSSEC/NXT would be good, but I also think that the lack of deployment would make now a good time for us to replace NXT and get away cheaper in the end. Any "real" operational experience is still some years ahead, getting DNSSEC in .com, .se etc is only a first step before organization's start to use it for anything useful (secure name lookups, SSH keys, PGP keys etc) and it's not until then "real" operational experience can be collected. > Also, a problem with the NO draft (as well as other drafts, including > opt-in) is that there's no way to specify security characteristics of the > zone. Having a resolver support either NO and NXT is hard enough; > supporting both with no method of determining which is used for any > specific zone is much worse. The SEC RR proposed by Ed Lewis a few years > ago would work, and it or something like it needs to be introduced again > before specifying alternate mechanisms for authenticated denial. I'm dense; could you elaborate on this? Why do you need to know before-hand if a certain zone uses NXT or NO? I don't see how it affects how you construct the query -- if the query doesn't return useful information, you either get nothing, NXT or perhap NO back. If you try to verify whatever you get back, you'll end up in either one of two cases A) you trust that the query doesn't have an answer, or B) you can't tell anything securely. And that's it. Please enlighten me. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Mar 16 14:38:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09189 for ; Fri, 16 Mar 2001 14:38:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14dzek-0006jY-00 for namedroppers-data@psg.com; Fri, 16 Mar 2001 11:12:58 -0800 Received: from [147.28.4.2] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14dzej-0006jS-00 for namedroppers@ops.ietf.org; Fri, 16 Mar 2001 11:12:57 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14dzeh-00011C-00 for namedroppers@ops.ietf.org; Fri, 16 Mar 2001 11:12:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 16 Mar 2001 10:37:06 -0800 (PST) From: Brian Wellington To: Simon Josefsson Cc: Subject: Re: DNSEXT WGLC: NO record In-Reply-To: Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 16 Mar 2001, Simon Josefsson wrote: > Brian Wellington writes: > > > I'm sure it's been said many times before, but it seems like a bad idea to > > obsolete the NXT record before there's any real operational experience > > with DNSSEC. Replacing NXT with NO would take a non-trivial amount of > > time and effort. > > I agree that more operational experience of DNSSEC/NXT would be good, > but I also think that the lack of deployment would make now a good > time for us to replace NXT and get away cheaper in the end. Maybe, but there is a widespread implementation implementation of NXT, and not one of NO. Adding NO support would take a while. > Any "real" operational experience is still some years ahead, getting > DNSSEC in .com, .se etc is only a first step before organization's > start to use it for anything useful (secure name lookups, SSH keys, > PGP keys etc) and it's not until then "real" operational experience > can be collected. That's arguable. The European registries experimenting with DNSSEC (.nl, .se, and maybe others) are getting real operation experience. Hopefully, if something is unusable, they'll find it. It's not as widespread as if .com is signed, but signing .com before others have operational experience would be a disaster. > > Also, a problem with the NO draft (as well as other drafts, including > > opt-in) is that there's no way to specify security characteristics of the > > zone. Having a resolver support either NO and NXT is hard enough; > > supporting both with no method of determining which is used for any > > specific zone is much worse. The SEC RR proposed by Ed Lewis a few years > > ago would work, and it or something like it needs to be introduced again > > before specifying alternate mechanisms for authenticated denial. > > I'm dense; could you elaborate on this? Why do you need to know > before-hand if a certain zone uses NXT or NO? > > I don't see how it affects how you construct the query -- if the query > doesn't return useful information, you either get nothing, NXT or > perhap NO back. If you try to verify whatever you get back, you'll > end up in either one of two cases A) you trust that the query doesn't > have an answer, or B) you can't tell anything securely. And that's > it. Please enlighten me. For a simple negative answer, it's probably easy enough to just look at the answer and see if it contains NXT or NO records. What happens if a (possibly spoofed) response contains both NXT and NO records? Attempting to validate both makes an already complicated state machine even worse. How does the resolver know which one to verify? I don't think this is an unsolvable problem; it's just that the validation process can be simplified by knowing whether to look for NXT or NO before beginning the negative proof. We will definitely need something that gives information about a zones security (and other) status for the opt-in draft. It doesn't make sense to complicate validation for this and then go back and add an "NXT or NO" bit later. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Mar 16 20:53:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA17198 for ; Fri, 16 Mar 2001 20:53:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14e5Be-000Eqt-00 for namedroppers-data@psg.com; Fri, 16 Mar 2001 17:07:18 -0800 Received: from [135.222.64.10] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14e5Bd-000Eqm-00 for namedroppers@ops.ietf.org; Fri, 16 Mar 2001 17:07:17 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14e5BY-000176-00 for namedroppers@ops.ietf.org; Fri, 16 Mar 2001 17:07:12 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 16 Mar 2001 13:27:51 -0800 (PST) To: namedroppers@ops.ietf.org Subject: Re: Extra records in zone transfers In-Reply-To: <20010316103542.14117.qmail@cr.yp.to> References: <20010315135603.13247.qmail@cr.yp.to> <20010316103542.14117.qmail@cr.yp.to> Message-Id: <200103162113.NAA17071@gulag.araneus.fi> From: gson@nominum.com (Andreas Gustafsson) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit D. J. Bernstein writes: > 1. Suppose I'm a slave transferring the princeton.edu zone. I will > discard aol.com information from the princeton.edu servers. This is > required for security: the princeton.edu servers aren't authorized to > provide aol.com information. > > Once you accept that this is the slave's responsibility, you have no > reason to demand that the princeton.edu AXFR servers omit aol.com > information. > > 2. Suppose I'm transferring both princeton.edu and cs.princeton.edu. I > will discard all princeton.edu AXFR results below cs.princeton.edu, in > favor of the cs.princeton.edu AXFR results. > > To the extent that there's a difference, the princeton.edu servers are > wrong. For example, the princeton.edu servers say cs.princeton.edu NS > {cs.princeton.edu,engram.cs.princeton.edu}, while the cs.princeton.edu > servers say cs.princeton.edu NS {dns1,dns2}.cs.princeton.edu. If someone > asks me for the cs.princeton.edu NS records, I'm going to report > {dns1,dns2}.cs.princeton.edu. > > Once you accept that this is the slave's responsibility, you have no > reason to demand that the princeton.edu AXFR servers omit unnecessary > cs.princeton.edu information. > > Note that my decision to discard the cs.princeton.edu NS records from > the princeton.edu servers won't happen when I transfer princeton.edu: I > don't know at that point whether I'm also transferring cs.princeton.edu. Suppose the master is a primary master, loading its zone data from master files. What I'm trying to say is that in a zone transfer of princeton.edu, the master must transmit exactly the information it loaded from the princeton.edu master file. If the princeton.edu master file contained data below cs.princeton.edu, it MUST be transmitted. Records below cs.princeton.edu that were not present in the princeton.edu master file MUST NOT be transmitted, even if the server happens to have such records because it is also authoritative for cs.princeton.edu. As you say, it is the responsibility of the slave to NOT include any cs.princeton.edu data received in a princeton.edu zone transfer in the answer section when responding to an ordinary query. However, it MUST include such data in an outgoing transfer of princeton.edu to a subordinate slave. The reason for these rules is to ensure that for a particular zone serial number, all the authoritative servers agree on the contents of the zone (including glue data associated with the zone). The IXFR protocol relies on this being the case. See also RFC2136 section 7.18. The case of aol.com data in the princeton.edu zone file is more of a grey area. I do not think there is a clear consensus in the DNSEXT WG as to whether cross-zone glue like the A record in the following example (from a hypothetical princeton.edu zone file) should be supported: cs.princeton.edu NS ns2.aol.com. ns2.aol.com A 10.0.0.1 The issue of whether servers should support such cross-zone glue is outside the scope of the draft under discussion. However, supposing that both servers do support it, it makes sense for the princeton.edu master to include an ns2.aol.com A record loaded from the princeton.edu zone file in an outgoing transfer of princeton.edu, and to NOT include aol.com data from any other zone file. Again, it is the responsibility of the slave to not use the out-of-zone data in answers to ordinary queries, but it may be used as glue in referrals out of the princeton.edu zone and in outgoing transfers to subordinate slaves. > 3. As a convenience to the administrator, my servers automatically treat > all records from child zones (and grandchild zones and so on) as > non-authoritative records for the parent zone. > > When axfrdns has both princeton.edu and cs.princeton.edu, for example, > its AXFR results for princeton.edu won't include anything in aol.com but > will include everything in cs.princeton.edu. I consider that behavior to be incorrect. The handling of out-of-zone data in BIND 4 and BIND 8 is also incorrect, for different reasons. -- Andreas Gustafsson, gson@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Mar 16 20:53:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA17197 for ; Fri, 16 Mar 2001 20:53:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14e58q-000ElH-00 for namedroppers-data@psg.com; Fri, 16 Mar 2001 17:04:24 -0800 Received: from [135.222.64.10] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14e58p-000ElA-00 for namedroppers@ops.ietf.org; Fri, 16 Mar 2001 17:04:23 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14e58j-00016t-00 for namedroppers@ops.ietf.org; Fri, 16 Mar 2001 17:04:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Brian Wellington Cc: Subject: Re: DNSEXT WGLC: NO record References: From: Simon Josefsson In-Reply-To: (Brian Wellington's message of "Fri, 16 Mar 2001 10:37:06 -0800 (PST)") Date: 16 Mar 2001 21:33:05 +0100 Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian Wellington writes: > > Any "real" operational experience is still some years ahead, getting > > DNSSEC in .com, .se etc is only a first step before organization's > > start to use it for anything useful (secure name lookups, SSH keys, > > PGP keys etc) and it's not until then "real" operational experience > > can be collected. > > That's arguable. The European registries experimenting with DNSSEC (.nl, > .se, and maybe others) are getting real operation experience. Hopefully, > if something is unusable, they'll find it. It's not as widespread as if > .com is signed, but signing .com before others have operational experience > would be a disaster. I agree with this. What I thought about was that some of the problems with NXT might not be visible at the registry level -- like the zone walking problem. Registries won't consider it to be an issue, they don't store SSH host keys, personal PGP keys etc in DNS. Registries aren't the "end-users" of DNS data. Once the registries (the infrastructure) use DNSSEC, end-users are going to trust DNS more (SSH host keys etc) and maybe then NXT will be regarded as a larger problem than before. I dunno. My point is that we don't get much "end-user" operational experience unless DNSSEC is already deployed within the infrastructure, and then the cost for changing things might be too high. But this is irrelevant if we reserve an enumerated type for different authenticated denial mechanisms in a to-be-designed zone-security-status information today. > What happens if a (possibly spoofed) response contains both NXT and NO > records? Attempting to validate both makes an already complicated state > machine even worse. How does the resolver know which one to verify? >From a security point of view; if either one verifies, that's good enough. From a technical point of view; reject the packet as invalid or outdated (it must be either one) and talk to someone else to get more recent data. There are some alternatives. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Mar 17 10:37:17 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07105 for ; Sat, 17 Mar 2001 10:37:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14eIGm-0003OJ-00 for namedroppers-data@psg.com; Sat, 17 Mar 2001 07:05:28 -0800 Received: from [135.222.64.10] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14eIGl-0003OD-00 for namedroppers@ops.ietf.org; Sat, 17 Mar 2001 07:05:27 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14eIGk-0002Ei-00 for namedroppers@ops.ietf.org; Sat, 17 Mar 2001 07:05:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 17 Mar 2001 14:28:17 -0000 Message-ID: <20010317142817.24001.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: Extra records in zone transfers References: <20010315135603.13247.qmail@cr.yp.to> <20010316103542.14117.qmail@cr.yp.to> <200103162113.NAA17071@gulag.araneus.fi> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Andreas Gustafsson writes: [ aol.com records in a zone transferred from princeton.edu ] > it may be used as glue in referrals No. That is completely unacceptable from a security perspective. Consider, as an easy example, a server handling both the .net zone and the microsoft.net zone. Suppose the microsoft.net people say blah.microsoft.net NS ns.slashdot.net ns.slashdot.net A 207.46.232.37 in an AXFR response to this server. It is essential for the server to discard the glue A record; otherwise it will poison caches, because caches trust ns.slashdot.net information from .net servers. If IXFR relies on the server keeping this record, then IXFR is broken. Furthermore, the IXFR protocol has an official status of Elective, and my users have a better protocol (rsync), so I am not going to support IXFR, and I object to IXFR-induced complications in the AXFR protocol. > Records below cs.princeton.edu that were not present in > the princeton.edu master file MUST NOT be transmitted, My servers use a redesigned unified configuration-file format, different from your master-file format. As I said, they automatically treat all *.cs.princeton.edu records as non-authoritative records for the princeton.edu zone, as a convenience for the system administrator. Everything works. You claim without justification that it is ``incorrect'' for the princeton.edu zone to contain (e.g.) www.cs.princeton.edu records, even though you say that www.aol.com records are okay. I don't see any support for your views in the DNS specifications. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Mar 17 16:13:13 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09449 for ; Sat, 17 Mar 2001 16:13:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14eNZC-0008Nx-00 for namedroppers-data@psg.com; Sat, 17 Mar 2001 12:44:50 -0800 Received: from [135.222.64.12] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14eNZB-0008Nr-00 for namedroppers@ops.ietf.org; Sat, 17 Mar 2001 12:44:49 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14eNZ0-0002XJ-00 for namedroppers@ops.ietf.org; Sat, 17 Mar 2001 12:44:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 17 Mar 2001 15:38:26 -0500 (EST) From: Olafur Gudmundsson To: namedroppers@ops.ietf.org cc: agenda@ietf.org Subject: DNSEXT IETF50 Revised agenda Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Some minor changes in order and slot size. 2 new items and one typo fixed. There is no spare time left so please stick to the agenda anyone willing to surrender slot please contact me ASAP. Olafur ------- Agenda (2001/03/21) (as of 2001/03/17 Revision #2) 49'th IETF DNSEXT WG meeting Wednesday March 21'st 2001. 15:30 -- 17:30 Chairs: Randy Bush Olafur Gudmundsson Working group items 03 min Agenda bashing Randy Bush 05 min WG status Olafur Gudmundsson Status of documents WG has advanced: Zone Secure RFC Editor Message Size RFC Editor APL IESG DNSSEC OK IESG RSA/SHA IESG RFC161[12] retirement IESG SRVbis WG chair IXFRbis Pending Interop report http://www.ietf.org/internet-drafts/draft-ietf-dnsext-zone-status-05.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-message-size-04.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-apl-rr-02.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-okbit-01.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rsa-02.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnsmib-historical-00.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2877bis-00.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ixfr-01.txt WG future: 08 min New charter discussion Olafur Gudmundsson 08 min RFC2535bis editing Olafur Gudmundsson Introduction of RFC2535bis editors and time-line Documents in last call 03 min DNSSEC Roadmap Glen Rose http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-roadmap-02.txt 03 min AXFR Clarify Andreas Gustafsson http://www.ietf.org/internet-drafts/draft-ietf-dnsext-axfr-clarify-01.txt 05 min AD is Secure Olafur Gudmundsson 2http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ad-is-secure-01.txt 08 min NO record Simon Josefsson http://www.ietf.org/internet-drafts/draft-ietf-dnsext-not-existing-rr.00.txt2 Other working group documents 04 min Inverse query obsolete David Lawrence http://www.ietf.org/internet-drafts/draft-ietf-dnsext-obsolete-iquery-00.txt 05 min DNSSEC opt IN Mark Kosters http://www.ietf.org/internet-drafts/draft-kosters-dnsext-dnssec-opt-in-01.txt 04 min Unknown RR types Andreas Gustafsson http://www.ietf/org/internet-drafts/draft-ietf-dnsext-unkown-rrs-00.txt 05 min GSSAPI-TSIG Levon Esibov http://www.ietf.org/internet-drafts/draft-ietf-dnsext-gss-tsig-02.txt 03 min DHCID RR Mark Stapp http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dhcid-rr-02.txt 04 min ZONE and View options Michael Sawyer http://www.ietf.org/internet-drafts/draft-ietf-dnsext-edns-zone-option-00.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-edns-bind-view-option-00.txt 04 min ENDS handling unknown Michael Sawyer http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ends-unknown-00.txt 02 min EDNS0.5 Harald Alvestrand http://www.ietf.org/internet-drafts/draft-ietf-dnssext-ends0dot5-02.txt New non WG documents 05 min NIST DNSSec Implementation testing Scott Rose 05 min NL.NL experiment Miek Gieben 10 min IPNG DDDT Dave Thaler http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-dns-discovery-00.txt 05 min ECC KEY record type Donald Eastlake http://www.ietf.org/internet-drafts/draft-schroeppel-dnsind-ecc-02.txt 03 min Do not update TLD's Levon Esibov http://www.ietf.org/internet-drafts/draft-esibov-dnsext-dynupdtld-00.txt 05 min Top Level private label name Levon Esibov http://www.ietf.org/internet-drafts/draft-coffeystrain-dnsext-privatednstld-00.txt 10 min Label management proposal Michael L. Macgowan Jr. http://www.ietf.org/internet-drafts/draft-macgowan-dnsext-label-intel-manage-00.txt 03 min Wrap-up. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Mar 17 18:42:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10378 for ; Sat, 17 Mar 2001 18:42:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14ePtd-000Ajs-00 for namedroppers-data@psg.com; Sat, 17 Mar 2001 15:14:05 -0800 Received: from pcp000512pcs.wireless.meeting.ietf.org ([135.222.64.12] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14ePtb-000Ajm-00 for namedroppers@ops.ietf.org; Sat, 17 Mar 2001 15:14:03 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14ePta-0002ef-00 for namedroppers@ops.ietf.org; Sat, 17 Mar 2001 15:14:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Masataka Ohta Message-Id: <200103172254.HAA03218@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id HAA03218; Sun, 18 Mar 2001 07:53:49 +0859 Subject: Re: Extra records in zone transfers To: djb@cr.yp.to (D. J. Bernstein) Date: Sun, 18 Mar 1 7:53:47 JST Cc: namedroppers@ops.ietf.org In-Reply-To: <20010317142817.24001.qmail@cr.yp.to>; from "D. J. Bernstein" at Mar 18, 101 12:43 am Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dan; > Andreas Gustafsson writes: > [ aol.com records in a zone transferred from princeton.edu ] > > it may be used as glue in referrals > > No. That is completely unacceptable from a security perspective. > > Consider, as an easy example, a server handling both the .net zone and > the microsoft.net zone. Suppose the microsoft.net people say > > blah.microsoft.net NS ns.slashdot.net > ns.slashdot.net A 207.46.232.37 > > in an AXFR response to this server. It is essential for the server to > discard the glue A record; otherwise it will poison caches, because > caches trust ns.slashdot.net information from .net servers. In an AXFR, exactly what is contained in the master zone file is transferred. The primary server transmit exactly what is contained in a master zone file of a zone. Secondary servers transmit exactly what is received from upstream server. AXFR and IXFR has nothing to do with caching. > My servers use a redesigned unified configuration-file format, Your server is wrongly implemented, then. (FYI, last time I checked BIND code in detail several years ago, it was wrong too.) Glue information is local to a zone (actually, local to a referral point that same name server may have different A records referral by referral, though such information can not be represented by standard zone file or zone transfer format), that same name server may have different A records zone by zone. That is the reality of the database and the behaviour is not forbidden by the specification. Thus, glue information may be chached not in global cache but in cache local to a zone (or, better, local to a referral point). Then, different A records from different referral points can be cached independently and replies can choose appropriate chache. Note that your server is wrongly implemented in a way not directly related to AXFR nor IXFR that, if you want to continue this thread on correct chaching, you should better use a subject like "multiple chache". Masataka Ohta to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Mar 18 08:59:01 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08126 for ; Sun, 18 Mar 2001 08:58:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14ed9g-000Nx7-00 for namedroppers-data@psg.com; Sun, 18 Mar 2001 05:23:32 -0800 Received: from pcp017500pcs.wireless.meeting.ietf.org ([135.222.64.2] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14ed9d-000Nx1-00 for namedroppers@ops.ietf.org; Sun, 18 Mar 2001 05:23:29 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14ed9f-0000Rv-00 for namedroppers@ops.ietf.org; Sun, 18 Mar 2001 05:23:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 18 Mar 2001 06:07:29 -0000 Message-ID: <20010318060729.2828.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: Extra records in zone transfers References: <20010317142817.24001.qmail@cr.yp.to> <200103172254.HAA03218@necom830.hpcl.titech.ac.jp> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Masataka Ohta writes: > same name server may have different A records zone by zone. That's the BIND 9 model, but it is _not_ consistent with RFC 1034. Here's what the DNS specifications actually say: * DNS is divided into zones. Names are partitioned among zones. Each zone is authoritative for all records under its names. See RFC 1034, section 4.1. * Zones may---and sometimes must---contain records for which they aren't authoritative, i.e., records from other zones. These records are supposed to be EXACT COPIES of the authoritative records. See RFC 1034, section 4.2.1, last paragraph on page 20. I realize that people often make mistakes in copying records: look at cs.princeton.edu, for example. Those people are violating the protocol. They have no right to expect clients to preserve both sets of records. Clients can and do assume the accuracy of any record set received from any server authorized to provide that set. > > My servers use a redesigned unified configuration-file format, > Your server is wrongly implemented, then. Don't be ridiculous. I'm not going to force my users to deal with that horrendous format. If they want painful configuration, they can use the BIND master-file format. That format is, by the way, neither stable nor identical to the standard RFC 1034 master-file format, so you can't justify it on interoperability grounds. ---Dan P.S. One of my recent messages hasn't shown up on the list. Is Bush censoring messages again, or is he simply incompetent? For previous incidents see http://cr.yp.to/djbdns/namedroppers.html. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Mar 19 01:02:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA19708 for ; Mon, 19 Mar 2001 01:02:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14esJv-000Dug-00 for namedroppers-data@psg.com; Sun, 18 Mar 2001 21:35:07 -0800 Received: from pcp000682pcs.wireless.meeting.ietf.org ([135.222.64.182] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14esJt-000DuL-00 for namedroppers@ops.ietf.org; Sun, 18 Mar 2001 21:35:05 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14esJs-0001LZ-00 for namedroppers@ops.ietf.org; Sun, 18 Mar 2001 21:35:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 19 Mar 2001 03:05:35 -0000 Message-ID: <20010319030535.15805.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: Extra records in zone transfers References: <20010318060729.2828.qmail@cr.yp.to> <200103190217.LAA06070@necom830.hpcl.titech.ac.jp> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Masataka Ohta writes: > "supposed to be" is not a protocol standard but a best current practice. False. Please read RFC 1034. The paragraph that I cited says, among other things, that the non-authoritative NS records in the parent zone should be ``exactly the same as the corresponding RRs in the top node of the subzone.'' The current cs.princeton.edu NS records flunk this test. > What is the problem, then? The problem is that this document, in violation of RFC 2119 section 6, imposes requirements that aren't needed for interoperability. If I'm transferring both princeton.edu and cs.princeton.edu, I'm going to throw away the bogus set of NS records in favor of the authoritative set, and everything will work. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Mar 19 01:07:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA19998 for ; Mon, 19 Mar 2001 01:07:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14esBV-000Dma-00 for namedroppers-data@psg.com; Sun, 18 Mar 2001 21:26:25 -0800 Received: from pcp000682pcs.wireless.meeting.ietf.org ([135.222.64.182] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14esBU-000DmH-00 for namedroppers@ops.ietf.org; Sun, 18 Mar 2001 21:26:24 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14esBW-0001Kz-00 for namedroppers@ops.ietf.org; Sun, 18 Mar 2001 21:26:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Masataka Ohta Message-Id: <200103190217.LAA06070@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id LAA06070; Mon, 19 Mar 2001 11:17:25 +0900 Subject: Re: Extra records in zone transfers In-Reply-To: <20010318060729.2828.qmail@cr.yp.to> from "D. J. Bernstein" at "Mar 18, 2001 06:07:29 am" To: "D. J. Bernstein" Date: Mon, 19 Mar 2001 11:17:24 +0859 () CC: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dan; > Masataka Ohta writes: > > same name server may have different A records zone by zone. > > That's the BIND 9 model, but it is _not_ consistent with RFC 1034. > Here's what the DNS specifications actually say: > > * DNS is divided into zones. Names are partitioned among zones. Each > zone is authoritative for all records under its names. See RFC > 1034, section 4.1. > > * Zones may---and sometimes must---contain records for which they > aren't authoritative, i.e., records from other zones. These records > are supposed to be EXACT COPIES of the authoritative records. See > RFC 1034, section 4.2.1, last paragraph on page 20. Glue records are provided by (sometimes malicious) human intervention. "supposed to be" is not a protocol standard but a best current practice. Protocols must assume they are supposed to be but may not be the exact copies. > Clients can and do assume the accuracy of any record set received from > any server authorized to provide that set. It's OK as long as the clients can reach the desired data. > > > My servers use a redesigned unified configuration-file format, > > Your server is wrongly implemented, then. > > Don't be ridiculous. I'm not going to force my users to deal with that > horrendous format. If they want painful configuration, they can use the > BIND master-file format. So, your server works just fine with the real world BIND master-file content. What is the problem, then? > That format is, by the way, neither stable nor > identical to the standard RFC 1034 master-file format, so you can't > justify it on interoperability grounds. I know. Several years ago, I found a bug on escape characters. But, a problem here is that binary zone transfer format is not good enough to distinguish glues of each referral. Masataka Ohta to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Mar 19 15:01:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20080 for ; Mon, 19 Mar 2001 15:01:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14f5H0-0004qg-00 for namedroppers-data@psg.com; Mon, 19 Mar 2001 11:24:58 -0800 Received: from pcp000682pcs.wireless.meeting.ietf.org ([135.222.64.182] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14f5Gz-0004qa-00 for namedroppers@ops.ietf.org; Mon, 19 Mar 2001 11:24:57 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14f5H0-000261-00 for namedroppers@ops.ietf.org; Mon, 19 Mar 2001 13:24:58 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 19 Mar 2001 09:52:52 -0800 (PST) Message-Id: <200103191752.JAA17826@gulag.araneus.fi> To: "D. J. Bernstein" CC: namedroppers@ops.ietf.org Subject: Re: Extra records in zone transfers In-Reply-To: <20010317142817.24001.qmail@cr.yp.to> References: <20010315135603.13247.qmail@cr.yp.to> <20010316103542.14117.qmail@cr.yp.to> <200103162113.NAA17071@gulag.araneus.fi> <20010317142817.24001.qmail@cr.yp.to> From: gson@nominum.com (Andreas Gustafsson) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit D. J. Bernstein writes: > [ aol.com records in a zone transferred from princeton.edu ] > > it may be used as glue in referrals > > No. That is completely unacceptable from a security perspective. > > Consider, as an easy example, a server handling both the .net zone and > the microsoft.net zone. Suppose the microsoft.net people say > > blah.microsoft.net NS ns.slashdot.net > ns.slashdot.net A 207.46.232.37 > > in an AXFR response to this server. It is essential for the server to > discard the glue A record; otherwise it will poison caches, because > caches trust ns.slashdot.net information from .net servers. Yes, this is a potential security problem, and dropping cross-zone glue is one possible way of dealing with it. Another would be to not host a parent and mutually untrusting children on the same server. This and related security issues could be fruitful topics for a separate I-D. If we do choose the solution of outlawing cross-zone glue, I think the zone transfer protocol is the wrong place to enforce it, because the restriction should apply to primary masters as well as slaves. > You claim without justification that it is ``incorrect'' for the > princeton.edu zone to contain (e.g.) www.cs.princeton.edu records, even > though you say that www.aol.com records are okay. I did not say that. Records for www.cs.princeton.edu (or www.aol.com) can be part of a princeton.edu zone transfer, if and only if they are part of data configured specifically for the princeton.edu zone (whether by means of a princeton.edu zone file, an incoming princeton.edu zone transfer, or some other configuration mechanism). Neither www.cs.princeton.edu nor www.aol.com may be included in a princeton.edu zone transfer merely as a result of the master also being authoritative for the cs.princeton.edu or aol.com zone. -- Andreas Gustafsson, gson@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Mar 19 15:03:50 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20153 for ; Mon, 19 Mar 2001 15:03:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14f5Iw-0004ua-00 for namedroppers-data@psg.com; Mon, 19 Mar 2001 11:26:58 -0800 Received: from pcp000682pcs.wireless.meeting.ietf.org ([135.222.64.182] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14f5Iw-0004uU-00 for namedroppers@ops.ietf.org; Mon, 19 Mar 2001 11:26:58 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14f5Iw-00026A-00 for namedroppers@ops.ietf.org; Mon, 19 Mar 2001 13:26:58 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Masataka Ohta Message-Id: <200103191755.CAA11588@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id CAA11588; Tue, 20 Mar 2001 02:55:35 +0900 Subject: Re: Extra records in zone transfers In-Reply-To: <20010319030535.15805.qmail@cr.yp.to> from "D. J. Bernstein" at "Mar 19, 2001 03:05:35 am" To: "D. J. Bernstein" Date: Tue, 20 Mar 2001 02:55:34 +0859 () CC: namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dan; > > "supposed to be" is not a protocol standard but a best current practice. > > False. Please read RFC 1034. The paragraph that I cited says, among > other things, that the non-authoritative NS records in the parent zone > should be ``exactly the same as the corresponding RRs in the top node of > the subzone.'' The current cs.princeton.edu NS records flunk this test. "should be" is not a protocol standard but a best current practice. RFC 1034 says: : 4.3.5. Zone maintenance and transfers : : Part of the job of a zone administrator is to maintain the zones at all : of the name servers which are authoritative for the zone. The fundamental property of distributed database is that there will be some inconsistencies. Accept it. > The problem is that this document, in violation of RFC 2119 section 6, > imposes requirements that aren't needed for interoperability. If I'm > transferring both princeton.edu and cs.princeton.edu, I'm going to throw > away the bogus set of NS records in favor of the authoritative set, and > everything will work. Your intelligent intermediate entities are not allowed to try to administrate the zones, even if the administrators are dumb. Zone administrators are responsible for the content of zones. If you want to reduce the inconsistency prolem, you should develop tools for zone administrators to maintain the zones at all of the ^^^^^^^^^^ name servers. Masataka Ohta to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Mar 21 17:24:10 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18552 for ; Wed, 21 Mar 2001 17:24:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14fqQD-000JVl-00 for namedroppers-data@psg.com; Wed, 21 Mar 2001 13:45:37 -0800 Received: from pcp000682pcs.wireless.meeting.ietf.org ([135.222.64.182] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14fqQC-000JVf-00 for namedroppers@ops.ietf.org; Wed, 21 Mar 2001 13:45:36 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14fqQC-0004BS-00 for namedroppers@ops.ietf.org; Wed, 21 Mar 2001 15:45:36 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: namedroppers@ops.ietf.org Subject: FW: AAAA/A6 From: itojun@iijlab.net Date: Thu, 22 Mar 2001 06:37:50 +0900 Message-ID: <14115.985210670@coconut.itojun.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit i'm not sure which wg is the better place. itojun ------- Forwarded Message Subject: Re: The case against A6 and DNAME From: itojun@iijlab.net Date: Thu, 22 Mar 2001 01:59:24 +0900 Message-ID: <8442.985193964@coconut.itojun.org> i guess i prefer AAAA much more than A6, because of the following logic. could someone shed some light on the following items? i don't think i'm convinced yet. i agree that we need to test A6 in the real world situation. however, for a guy who is using IPv6 in a daily basis, i cannot wait till the test gets done... so i prefer AAAA gets deployed and kept. (note: the following is separate from topics raised by DJB) itojun real dns cloud: - - if we end up using "A6 0 <128bit>" everywhere, there's no benefit against AAAA. - - if we are to use fragmented A6s (128bit splitted into multiple A6s), i got couple of issues/worries. (1) query delays bothers me and we don't know how the additional delays interact with various timeout parameters. also, are we sure that we have no problem with additional query/reply traffic imposed by fragmented A6? (2) some says that caches will avoid querying fragmented A6s again and again. however, most of the libc resolver implementations do not cache anything. (3) if some of the fragments are DNSSEC-signed and some are not, how should we treat that address? RFC2874 section 6 briefly talks about it, not sure if complete answer is given. (4) it is much harder to code A6 fragment reassemble code, i expect to see a lot of security-issue bugs in the future (from our experiences). (5) i don't think there's too big benefits from renumbering. query-replace over AAAA zone file is easy enough. you may need to sign zones on renumber, but given that the frequency of renumber is fairly low it shouldn't be an issue. to those who says that we can renumber frequently: from rrenum discussion it is clear that we cannot renumber more frequently than DNS TTL (or TTL*2). (6) there were some mentions about limiting # of fragments, but there's no such guarantee. resolver issues: suppose that we synthesize AAAA, or A6 0 <128bit>, at the DNS server contacted by libc resolver, to avoid some of the complexities given above (see BIND 9.2.0 snap behavior). the approach has the following drawbacks: - - DNSSEC signs will get removed, making it impossible for libc resolvers - - when do we decide to synthesize A6 0 <128bit>? client may be asking for raw A6 record (can be fragmented), client may be asking for synthesized A6 0 <128bit> record. - - synthesized records have TTL=0. is it really okay? (most of libc resolvers do not cache, so it should not be too bad) we at least need a flag to determine when to synthesize, and when we do not. (note that if we simply use AAAA in all places, we have no such problem at all) deplyment issue: we can't wait till BIND9 gets deployed everywhere. - -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com - -------------------------------------------------------------------- ------- End of Forwarded Message to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Mar 21 17:29:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18843 for ; Wed, 21 Mar 2001 17:29:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14fqlr-000K8J-00 for namedroppers-data@psg.com; Wed, 21 Mar 2001 14:07:59 -0800 Received: from pcp000682pcs.wireless.meeting.ietf.org ([135.222.64.182] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14fqlq-000K85-00 for namedroppers@ops.ietf.org; Wed, 21 Mar 2001 14:07:58 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14fqlq-0004Ce-00 for namedroppers@ops.ietf.org; Wed, 21 Mar 2001 16:07:58 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <5.0.2.1.0.20010313113546.032531a0@gatt.dc.ogud.com> Date: Wed, 21 Mar 2001 17:02:08 -0500 To: Olafur Gudmundsson From: Edward Lewis Subject: Re: DNSEXT WGLC: DNSSEC Roadmap Cc: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The document refers to at least one expired draft (not the fault of the Roadmap author) and to other progressing drafts. As no RFC can refer to Internet Drafts, it would be hard to progress this document to an RFC. IMHO, this is a worthy document whose time has not come - in its present scope. At 11:36 AM -0500 3/13/01, Olafur Gudmundsson wrote: >DNSEXT WGLC: DNSSEC Road map > >This document explains how the various working group documents related >to DNSSEC fit together and what updates what. > >This WG last call ends March 29'th 2001. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Mar 21 17:59:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20709 for ; Wed, 21 Mar 2001 17:59:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14frNA-000L6W-00 for namedroppers-data@psg.com; Wed, 21 Mar 2001 14:46:32 -0800 Received: from pcp000682pcs.wireless.meeting.ietf.org ([135.222.64.182] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14frN9-000L6O-00 for namedroppers@ops.ietf.org; Wed, 21 Mar 2001 14:46:32 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14frN8-0004Ek-00 for namedroppers@ops.ietf.org; Wed, 21 Mar 2001 16:46:30 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: References: Date: Wed, 21 Mar 2001 16:30:12 -0600 To: Edward Lewis , Olafur Gudmundsson From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: DNSEXT WGLC: DNSSEC Roadmap Cc: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 17.02 -0500 01-03-21, Edward Lewis wrote: >As no RFC can refer to Internet Drafts It can, if the reference is non-normative. I would not suggest to have even non-normative references to "work in progress", but if you really need to, that is possible. paf to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Mar 21 18:21:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21981 for ; Wed, 21 Mar 2001 18:21:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14frgv-000LkJ-00 for namedroppers-data@psg.com; Wed, 21 Mar 2001 15:06:57 -0800 Received: from pcp000682pcs.wireless.meeting.ietf.org ([135.222.64.182] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14frgv-000Lk4-00 for namedroppers@ops.ietf.org; Wed, 21 Mar 2001 15:06:57 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14frgr-0004G5-00 for namedroppers@ops.ietf.org; Wed, 21 Mar 2001 17:06:53 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: Date: Wed, 21 Mar 2001 17:50:06 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt) Cc: lewis@tislabs.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I don't know what to think about this proposal. It is counter to a lot of background of DNS (e.g., the child's apex data being more credible than that at the parent). I see that this issue gives rise to a conflict of credible vs. valid. There are a number of cases to consider but are uninteresting (like the parent and child having the same KEY RR set for the child). The interesting cases are when there are different data and when there is the concern of liability. When there are different data (probably just a different SIG RR) between the child and the parent, it will probably be true that the (parent) key validating the SIG RR at the child is not available from an authoritative source (just caches). This means that unless there is a glitch, the child's more credible key set won't be validated by a third party. Question: is it acceptable to accept less credibile data if it validates over more credible but unvalid data? (Seems so.) Note that there is that "glitch." This is essentially the time that an undesired key remains alive in a cache - up to a TTL value. I don't think there is a way around this, DNS is not real time and we don't have a way to publish revokation lists. (And I don't think that we want to define this.) If someone has discovered the private key and this is the reason for the key change, the attacker can get away with misuse of the key for only as long as the discovered key is signed by its parent. Again, for the same reason above, I don't think we have a way to stop this period of vulnerability. In other words, so far, this new proposal doesn't generate any other solvable problems. (;)) Now, as far as liability - that the parent might present data that invalidates a child or allows for a child to continue to fall prey to an attack (because a key is not withdrawn), I don't think this is an area we can engineer around. Same arguement about the non-real time-ness and no revokation list ability. Finally, there is something that I am concerned about. When a child changes their key, the key is sent to the parent who then signs it. If the parent then publishes the key, the child hasn't had a chance to make sure the key wasn't substituted on the way to the parent. So, I suggest that if we accept parent publication of the child's signature, then we require that in the key "rollover" process, there is enough security to make it very hard to substitute keys in transit. (This is a rough statement written on the fly.) Perhaps this should be in dnsop...but I wrote this in response to the discussion in the in-person meeting. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Mar 21 18:43:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23400 for ; Wed, 21 Mar 2001 18:43:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14frzw-000ML9-00 for namedroppers-data@psg.com; Wed, 21 Mar 2001 15:26:36 -0800 Received: from pcp000682pcs.wireless.meeting.ietf.org ([135.222.64.182] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14frzv-000ML3-00 for namedroppers@ops.ietf.org; Wed, 21 Mar 2001 15:26:35 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14frzu-0004H9-00 for namedroppers@ops.ietf.org; Wed, 21 Mar 2001 17:26:34 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <001701c0b276$9771da40$5e40de87@antd.nist.gov> From: "Scott Rose" To: "Olafur Gudmundsson" , "Edward Lewis" Cc: References: Subject: Re: DNSEXT WGLC: DNSSEC Roadmap Date: Wed, 21 Mar 2001 18:19:57 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit There is some precedence on this matter. RFC 2411 (IP Security Document Roadmap) places references for RFC in the "official" references section, and references to Internet Drafts in the acknowledgements. While I dislike referencing Inet Drafts, I thought that placing the references in the acknowledgement and not the formal references was enough to indicate that they are "work in progress". Some of the drafts that are mentioned are also in Last Call, and will hopefully be assigned an RFC number before the roadmap progresses and then correctly referenced in the roadmap. Scott ----- Original Message ----- From: "Edward Lewis" To: "Olafur Gudmundsson" Cc: Sent: Wednesday, March 21, 2001 2:02 PM Subject: Re: DNSEXT WGLC: DNSSEC Roadmap > The document refers to at least one expired draft (not the fault of the > Roadmap author) and to other progressing drafts. > > As no RFC can refer to Internet Drafts, it would be hard to progress this > document to an RFC. IMHO, this is a worthy document whose time has not > come - in its present scope. > > At 11:36 AM -0500 3/13/01, Olafur Gudmundsson wrote: > >DNSEXT WGLC: DNSSEC Road map > > > >This document explains how the various working group documents related > >to DNSSEC fit together and what updates what. > > > >This WG last call ends March 29'th 2001. > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis NAI Labs > Phone: +1 443-259-2352 Email: lewis@tislabs.com > > Dilbert is an optimist. > > Opinions expressed are property of my evil twin, not my employer. > > > > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Mar 21 21:44:09 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03640 for ; Wed, 21 Mar 2001 21:44:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14fuij-0001D1-00 for namedroppers-data@psg.com; Wed, 21 Mar 2001 18:21:01 -0800 Received: from pcp000682pcs.wireless.meeting.ietf.org ([135.222.64.182] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14fuii-0001Cv-00 for namedroppers@ops.ietf.org; Wed, 21 Mar 2001 18:21:00 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14fuij-0004JK-00 for namedroppers@ops.ietf.org; Wed, 21 Mar 2001 20:21:01 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit to: namedroppers@ops.ietf.org cc: kato@wide.ad.jp In-reply-to: itojun's message of Thu, 22 Mar 2001 06:37:50 JST. <14115.985210670@coconut.itojun.org> Subject: Re: FW: AAAA/A6 From: itojun@iijlab.net Date: Thu, 22 Mar 2001 08:44:56 +0900 Message-ID: <16934.985218296@coconut.itojun.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on AAAA/A6, there was a comment in wg meeting that basically says: - A6 helps very very large multihomed IPv6 network. - those who says "AAAA is just fine" has never operated large-enough IPv6 network yet. for very very large multihomed IPv6 network, i guess A6 does not work either. if we cross the limit where zone files are over manageable size, none of A6 nor AAAA with manually managed zone file, will work. we need solution from different aspect something, including: - dynamic updates, to remove management burdens from client - name server with good backend database (in this case AAAA and A6 management costs are requal) - good perl script with AAAA (easy enough, deployable now) i don't think it wise to delegate management labor into protocol. the second bullet sounded a bit harsh to me, unless you have already opreated large-enough IPv6 network with A6. i believe our network is already large enough, and i'm happy with AAAA. itojun to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Mar 21 21:54:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03641 for ; Wed, 21 Mar 2001 21:44:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14fulj-0001JF-00 for namedroppers-data@psg.com; Wed, 21 Mar 2001 18:24:07 -0800 Received: from pcp000682pcs.wireless.meeting.ietf.org ([135.222.64.182] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14fulj-0001J9-00 for namedroppers@ops.ietf.org; Wed, 21 Mar 2001 18:24:07 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14fulk-0004Jb-00 for namedroppers@ops.ietf.org; Wed, 21 Mar 2001 20:24:08 -0600 Message-Id: <200103220030.f2M0Ut528681@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 3090 on DNS Security Extension on Zone Status Cc: rfc-ed@ISI.EDU, namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 21 Mar 2001 16:30:55 -0800 From: RFC Editor Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3090 Title: DNS Security Extension Clarification on Zone Status Author(s): E. Lewis Status: Standards Track Date: March 2001 Mailbox: lewis@tislabs.com Pages: 11 Characters: 24166 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dnsext-zone-status-05.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3090.txt The definition of a secured zone is presented, clarifying and updating sections of RFC 2535. RFC 2535 defines a zone to be secured based on a per algorithm basis, e.g., a zone can be secured with RSA keys, and not secured with DSA keys. This document changes this to define a zone to be secured or not secured regardless of the key algorithm used (or not used). To further simplify the determination of a zone's status, "experimentally secure" status is deprecated. This document is a product of the DNS Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <010321162841.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3090 --OtherAccess Content-Type: Message/External-body; name="rfc3090.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <010321162841.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Mar 21 22:24:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA05567 for ; Wed, 21 Mar 2001 22:24:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14fvNC-0002YM-00 for namedroppers-data@psg.com; Wed, 21 Mar 2001 19:02:50 -0800 Received: from pcp000682pcs.wireless.meeting.ietf.org ([135.222.64.182] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14fvNB-0002Xx-00 for namedroppers@ops.ietf.org; Wed, 21 Mar 2001 19:02:49 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14fvNA-0004L6-00 for namedroppers@ops.ietf.org; Wed, 21 Mar 2001 21:02:48 -0600 Message-Id: In-Reply-To: <001701c0b276$9771da40$5e40de87@antd.nist.gov> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 21 Mar 2001 21:00:15 -0500 To: "Scott Rose" From: Edward Lewis Subject: Re: DNSEXT WGLC: DNSSEC Roadmap Cc: "Olafur Gudmundsson" , "Edward Lewis" , Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 9:19 PM -0500 3/21/01, Scott Rose wrote: >While I dislike referencing Inet Drafts, I thought that placing the >references in the acknowledgement and not the formal references was enough >to indicate that they are "work in progress". Some of the drafts that are >mentioned are also in Last Call, and will hopefully be assigned an RFC >number before the roadmap progresses and then correctly referenced in the >roadmap. Okay. In that case, I'd recommend putting in "-nn.txt" instead of the extension number. This is what appears in some WG charters when a draft is mentioned. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Mar 21 22:35:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA07018 for ; Wed, 21 Mar 2001 22:35:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14fvXz-0002w2-00 for namedroppers-data@psg.com; Wed, 21 Mar 2001 19:13:59 -0800 Received: from pcp000682pcs.wireless.meeting.ietf.org ([135.222.64.182] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14fvXy-0002vw-00 for namedroppers@ops.ietf.org; Wed, 21 Mar 2001 19:13:58 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14fvXy-0004Mh-00 for namedroppers@ops.ietf.org; Wed, 21 Mar 2001 21:13:58 -0600 Date: Wed, 21 Mar 2001 22:08:37 -0500 From: Dan Massey To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt) Message-ID: <20010321220837.A18814@snarl.east.isi.edu> Mail-Followup-To: Edward Lewis , namedroppers@ops.ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from lewis@tislabs.com on Wed, Mar 21, 2001 at 05:50:06PM -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wednesday, March 21, 2001 at 05:50PM, Ed Lewis wrote: | | When there are different data (probably just a different SIG RR) between | the child and the parent, it will probably be true that the (parent) key | validating the SIG RR at the child is not available from an authoritative | source (just caches). This means that unless there is a glitch, the | child's more credible key set won't be validated by a third party. | Question: is it acceptable to accept less credibile data if it validates | over more credible but unvalid data? (Seems so.) | Ed raises some good questions, but first some clarification on what is stored at the child would be helpful. The proposal authors do not store the SIG from the parent at the child. For example, look at the keys for stack.nl.nl: At nl.nl you have: the stack.nl.nl KEY the SIG from nl.nl (parent signed key) At stack.nl.nl you have: the stack.nl.nl KEY the SIG from stack.nl.nl (self signed key) In this scheme, there is always a difference in SIG records between the parent and child. A more fundamental question is which SIGs must be stored at the child and which SIGs may be stored at the child. Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Mar 22 08:59:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA11135 for ; Thu, 22 Mar 2001 08:59:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14g5H1-000MHo-00 for namedroppers-data@psg.com; Thu, 22 Mar 2001 05:37:07 -0800 Received: from pcp000682pcs.wireless.meeting.ietf.org ([135.222.64.182] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14g5H0-000MHi-00 for namedroppers@ops.ietf.org; Thu, 22 Mar 2001 05:37:06 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14g5H3-0004Wz-00 for namedroppers@ops.ietf.org; Thu, 22 Mar 2001 07:37:09 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15033.39961.20690.906478@gro.dd.org> Date: Thu, 22 Mar 2001 01:30:49 -0500 (EST) From: tale@nominum.com (David C Lawrence) To: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-obsolete-iquery-00.txt In-Reply-To: <200103011218.HAA00226@ietf.org> References: <200103011218.HAA00226@ietf.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The consensus of the room today was to move this draft forward. There are a couple of minor typos in the draft that I will fix to submit version -01, but I have no notable changes planned. Please send me any substatiative comments for the draft so that I can incorporate them before sending in the next version next week. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Mar 22 09:32:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12029 for ; Thu, 22 Mar 2001 09:32:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14g5oB-000NJf-00 for namedroppers-data@psg.com; Thu, 22 Mar 2001 06:11:23 -0800 Received: from pcp000682pcs.wireless.meeting.ietf.org ([135.222.64.182] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14g5oA-000NJX-00 for namedroppers@ops.ietf.org; Thu, 22 Mar 2001 06:11:22 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14g5o6-0004ZT-00 for namedroppers@ops.ietf.org; Thu, 22 Mar 2001 08:11:18 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200103221358.FAA22464@redpaul.mfnx.net> To: namedroppers@ops.ietf.org Subject: Re: FW: AAAA/A6 In-Reply-To: Message from itojun@iijlab.net of "Thu, 22 Mar 2001 08:44:56 +0900." <16934.985218296@coconut.itojun.org> Date: Thu, 22 Mar 2001 05:58:39 -0800 From: Paul A Vixie Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit A6 wasn't originated by the DNS community, it was a response to the IPv6 community's desire to push their rapid/continuous renumbering requirement into DNS rather than having to invent new support protocols in IPv6 itself. Therefore if the IPv6 community withdraws its rapid/continuous renumbering requirement then the DNS community will absolutely withdraw its A6 proposal. I do not consider this likely, and moreover, while I'm not a direct participant in the IPv6 community, I think that rapid/continuous renumbering is the only thing that makes IPv6 worth deploying. > - name server with good backend database > (in this case AAAA and A6 management costs are requal) For any given network this may or may not be the case. Sounds like for the IIJLab network it is the case. But I know of hundreds of networks for whom it is NOT the case (starting with most of PAIX's customers.) Good backend databases, or even... > - good perl script with AAAA (easy enough, deployable now) ...good perl scripts, are not universally applicable or scalable, and will not lead to transit-provider fluidity. Some of the stickiness of a network to its transit provider has to do with the cost of renumbering. And at the moment, multihoming is hellishly expensive since it requires portable address space which most networks don't have the resources to qualify for. > i believe our network is already large enough, and i'm happy with AAAA. in contrast, i believe that IPv6 is not worth its deployment cost, not even in a testbed, unless we deploy (or test) the rapid/continuous renumbering features. if you don't believe me, find a member of the GPRS community and ask *them*. or anyone in the mobile data community. or anyone whose network touches PAIX or Equinix or similar for the majority purpose of selecting their transit providers based on price and quality and without regard to renumbering cost. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Mar 22 10:52:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13538 for ; Thu, 22 Mar 2001 10:52:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14g70Y-000Poc-00 for namedroppers-data@psg.com; Thu, 22 Mar 2001 07:28:14 -0800 Received: from pcp000682pcs.wireless.meeting.ietf.org ([135.222.64.182] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14g70W-000PoW-00 for namedroppers@ops.ietf.org; Thu, 22 Mar 2001 07:28:13 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14g70V-0004dV-00 for namedroppers@ops.ietf.org; Thu, 22 Mar 2001 09:28:11 -0600 From: Miek Gieben Date: Thu, 22 Mar 2001 15:54:16 +0100 To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt) Message-ID: <20010322155416.A40764@open.nlnetlabs.nl> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from lewis@tislabs.com on Wed, Mar 21, 2001 at 05:50:06PM -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > When there are different data (probably just a different SIG RR) between > the child and the parent, it will probably be true that the (parent) key > validating the SIG RR at the child is not available from an authoritative > source (just caches). This means that unless there is a glitch, the > child's more credible key set won't be validated by a third party. > Question: is it acceptable to accept less credibile data if it validates > over more credible but unvalid data? (Seems so.) Dan also makes some good points, it is entirely true what he says (at least in the way I see it) > Finally, there is something that I am concerned about. When a child > changes their key, the key is sent to the parent who then signs it. If the > parent then publishes the key, the child hasn't had a chance to make sure > the key wasn't substituted on the way to the parent. as it works now, the child puts the new key in its zone and signs the whole thing and then triggers the parent. The parent will get the new key and a sig over the new key made with the old key. This sig will be the safeguard against any substitution. The parent will also have to check this sig with the old key from the child which it already own. > So, I suggest that if we accept parent publication of the child's > signature, then we require that in the key "rollover" process, there is > enough security to make it very hard to substitute keys in transit. (This > is a rough statement written on the fly.) true :) grtz Miek NLnet Labs to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Mar 22 11:19:04 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13981 for ; Thu, 22 Mar 2001 11:19:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14g7KJ-0000X6-00 for namedroppers-data@psg.com; Thu, 22 Mar 2001 07:48:39 -0800 Received: from pcp000682pcs.wireless.meeting.ietf.org ([135.222.64.182] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14g7KJ-0000Wz-00 for namedroppers@ops.ietf.org; Thu, 22 Mar 2001 07:48:39 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14g7KI-0004f4-00 for namedroppers@ops.ietf.org; Thu, 22 Mar 2001 09:48:38 -0600 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Paul A Vixie Cc: namedroppers@ops.ietf.org Subject: Re: FW: AAAA/A6 References: <16934.985218296@coconut.itojun.org> <200103221358.FAA22464@redpaul.mfnx.net> Message-Id: Date: Thu, 22 Mar 2001 09:41:57 -0600 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > A6 wasn't originated by the DNS community, it was a response to the IPv6 > community's desire to push their rapid/continuous renumbering requirement > into DNS rather than having to invent new support protocols in IPv6 > itself. > > Therefore if the IPv6 community withdraws its rapid/continuous renumbering > requirement then the DNS community will absolutely withdraw its A6 > proposal. sorry, but i have a small problem with some choices of words, though not necessarily deep semantics. the a6 document was an ipngwg document. hence the dns community can not withdraw the proposal, it was not ours to withdraw. we can work with the v6 community to find what is best, in our small and oh so fallable views, for the internet. also, i don't think either you, i, or any other single person should be speaking in the name of the dns community. personally, i am as tempted by the large address space of v6 as i am by renumbering. i suspect the latter has feet of clay, and the former badly needs a better routing architecture. but this may be the wrong wg for this part of the discussion. randy, just another bozo on this bus to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Mar 22 11:43:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14378 for ; Thu, 22 Mar 2001 11:43:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14g7rq-0001mN-00 for namedroppers-data@psg.com; Thu, 22 Mar 2001 08:23:18 -0800 Received: from pcp000682pcs.wireless.meeting.ietf.org ([135.222.64.182] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14g7rp-0001mH-00 for namedroppers@ops.ietf.org; Thu, 22 Mar 2001 08:23:17 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14g7rp-0004hn-00 for namedroppers@ops.ietf.org; Thu, 22 Mar 2001 10:23:17 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Paul A Vixie cc: namedroppers@ops.ietf.org In-reply-to: vixie's message of Thu, 22 Mar 2001 05:58:39 PST. <200103221358.FAA22464@redpaul.mfnx.net> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: FW: AAAA/A6 From: itojun@iijlab.net Date: Fri, 23 Mar 2001 01:19:03 +0900 Message-ID: <8274.985277943@coconut.itojun.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >A6 wasn't originated by the DNS community, it was a response to the IPv6 >community's desire to push their rapid/continuous renumbering requirement >into DNS rather than having to invent new support protocols in IPv6 itself. > >Therefore if the IPv6 community withdraws its rapid/continuous renumbering >requirement then the DNS community will absolutely withdraw its A6 proposal. >I do not consider this likely, and moreover, while I'm not a direct >participant in the IPv6 community, I think that rapid/continuous renumbering >is the only thing that makes IPv6 worth deploying. if this is the case, ipngwg would need to supply the requirement to renumbering (like frequency, network size, whether it covers multiple admin boundary or not, whatever). i have never seen such document. >> i believe our network is already large enough, and i'm happy with AAAA. >in contrast, i believe that IPv6 is not worth its deployment cost, not even >in a testbed, unless we deploy (or test) the rapid/continuous renumbering >features. (this is outside of the topic, i guess) deployment cost is high partly because there are too fancy proposals thrown into it. we, those who are trying hard to deploy IPv6 sooner, are trying to seek the ways to make it really work. i believe this A6/AAAA debate, as well as our tests of IPv6 router renumbering protocol, are part of the effort. itojun to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Mar 22 15:06:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19777 for ; Thu, 22 Mar 2001 15:06:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14gAt8-0008kt-00 for namedroppers-data@psg.com; Thu, 22 Mar 2001 11:36:50 -0800 Received: from pcp000682pcs.wireless.meeting.ietf.org ([135.222.64.182] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14gAt7-0008kn-00 for namedroppers@ops.ietf.org; Thu, 22 Mar 2001 11:36:49 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14gAt8-0004oU-00 for namedroppers@ops.ietf.org; Thu, 22 Mar 2001 13:36:50 -0600 Message-Id: <200103221628.KAA23702@gungnir.fnal.gov> To: tale@nominum.com (David C Lawrence) Cc: namedroppers@ops.ietf.org From: "Matt Crawford" Subject: Re: I-D ACTION:draft-ietf-dnsext-obsolete-iquery-00.txt In-reply-to: Your message of Thu, 22 Mar 2001 01:30:49 EST. <15033.39961.20690.906478@gro.dd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23698.985278508.1@gungnir.fnal.gov> Date: Thu, 22 Mar 2001 10:28:28 -0600 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Because implementations of IQUERY do exist, and are generally bad and/or unwanted, I would suggest changing Furthermore, many organizations would opt to disable IQUERY, if it existed, because it could expose large blocks of names in their zones, such as if many of those names have a common mail exchanger. to something beginning with Operators of servers that do support IQUERY often opt to disable it, due to bugs in insufficiently-exercised code, or concerns about exposure of expose large blocks of names in their zones by probes like inverse MX queries. and This would undeniably be handy at times as a diagnostic tool, but apparently not enough so that anyone's bothered to implement it since it was described in 1987. to This is sometimes a handy diagnostic tool, but apparently not enough so that server operators like to enable it, or request implementation where it's lacking. The bit about no known clients using IQUERY for any meaningful service is still true, as far as I know. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Mar 23 09:49:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15859 for ; Fri, 23 Mar 2001 09:49:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14gSQ2-000Jyw-00 for namedroppers-data@psg.com; Fri, 23 Mar 2001 06:19:58 -0800 Received: from pcp000682pcs.wireless.meeting.ietf.org ([135.222.64.182] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14gSQ2-000Jyq-00 for namedroppers@ops.ietf.org; Fri, 23 Mar 2001 06:19:58 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14gSQC-0004yt-00 for namedroppers@ops.ietf.org; Fri, 23 Mar 2001 08:20:08 -0600 Date: Thu, 22 Mar 2001 13:19:05 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: DNSEXT WGLC: DNSSEC Roadmap To: Edward Lewis Cc: Olafur Gudmundsson , namedroppers@ops.ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > As no RFC can refer to Internet Drafts, it would be hard to progress this > document to an RFC. IMHO, this is a worthy document whose time has not > come - in its present scope. To be exact there are two issues here: 1. A standards track document can't have normative references (i.e. things an implementor would need to read) to internet drafts. 2. Any remaining references to I-Ds will have the internet draft name replaced by "works in progress". Thus for a roadmap it might make sense to have references to works in progress; it is up to the WG to decide. Erik to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Mar 23 18:07:07 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA05587 for ; Fri, 23 Mar 2001 18:07:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14gaFE-000A4h-00 for namedroppers-data@psg.com; Fri, 23 Mar 2001 14:41:20 -0800 Received: from [147.28.4.2] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14gaFD-000A4b-00 for namedroppers@ops.ietf.org; Fri, 23 Mar 2001 14:41:19 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14gaBK-0005Ti-00 for namedroppers@ops.ietf.org; Fri, 23 Mar 2001 16:37:18 -0600 Message-ID: <3ABBC216.D17617A9@daimlerchrysler.com> Date: Fri, 23 Mar 2001 16:37:26 -0500 From: Kevin Darcy X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.8 sun4u) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: DNSEXT WGLC: AXFR Clarify References: <20010315135603.13247.qmail@cr.yp.to> <20010316105953.20572.qmail@cr.yp.to> <200103161912.LAA17037@gulag.araneus.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The draft says (Section 3): > If the master server is unable or unwilling to provide a zone > transfer, it MUST respond with a single DNS message containing an > appropriate RCODE other than NOERROR. Later (Section 3.2), it says that the AA flag in the response is "1 (but MAY be 0 when RCODE is nonzero)". (By the way, is it good form to equate "other than NOERROR" with "nonzero"?) I would prefer things to be more explicit, in the case where the server is not authoritative for the requested zone. Either a) return RCODE=NOTAUTH, or b) at the very least, *require* AA=0 in this situation, and AA=1 in all other RCODE!=NOERROR situations. The ultimate goal should be the ability for the client to know unambiguously that the server is not authoritative for the zone. - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Mar 25 17:57:44 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21424 for ; Sun, 25 Mar 2001 17:57:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14hIst-000JaL-00 for namedroppers-data@psg.com; Sun, 25 Mar 2001 14:21:15 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14hIss-000JaE-00 for namedroppers@ops.ietf.org; Sun, 25 Mar 2001 14:21:14 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14hIss-000ALi-00 for namedroppers@ops.ietf.org; Sun, 25 Mar 2001 14:21:14 -0800 Date: Sun, 25 Mar 2001 17:16:55 -0500 (EST) From: Olafur Gudmundsson X-Sender: ogud@hlid.dc.ogud.com To: namedroppers@ops.ietf.org cc: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: notes on A6 transition from AAAA (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Included is the "infamus" beer plan, on how to retire AAAA everywhere but stub resolvers. Please send all followup to namedroppers. Olafur (DNSEXT WG co-chair) ps: The peole haching this plan were Mark Andrews, Rob Austein, Alain Durand and Olafur Gudmundsson ---------- Forwarded message ---------- Date: Sun, 18 Mar 2001 20:05:32 -0800 From: Alain Durand To: sra@hactrn.net, ogud@ogud.com Subject: notes on A6 transition from AAAA Transition from AAAA to A6 Stub resolvers that ask for AAAA in queries with the RD bit turn ON will be returned AAAA answers. Resolvers that have send queries with RD bit OFF and ask for AAAA will be returned whatever is available, A6 or AAAA. Note that they SHOULD issues A6 queries in the first place. The entity that in its server role received a query with the RD bit turn ON and process that request in its resolver role issues A6 queries with the RD bit turned OFF is responsible for the systhesis of AAAA from A6 records. This entity MUST try first A6 then MAY try AAAA queries to process the request. A authoritative server that only has AAAA entries and is asked for an A6 record MUST NOT synthesize A6 records from the AAAA ones. There is no restriction on populating both types, but it is strongly recommended against, and in such a case, both RRsets MUST be identical. If a query does not contain EDNS indicator, then any IPv6 addresses contain in additional data section MUST be AAAA. Root and TLD zones MUST only contain A6 with prefix of 0. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Mar 26 03:22:06 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA06705 for ; Mon, 26 Mar 2001 03:22:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14hRnf-0007pR-00 for namedroppers-data@psg.com; Sun, 25 Mar 2001 23:52:27 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14hRne-0007pL-00 for namedroppers@ops.ietf.org; Sun, 25 Mar 2001 23:52:26 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14hRne-000Pij-00 for namedroppers@ops.ietf.org; Sun, 25 Mar 2001 23:52:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit to: namedroppers@ops.ietf.org In-reply-to: ogud's message of Sun, 25 Mar 2001 17:16:55 EST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: notes on A6 transition from AAAA (fwd) From: itojun@iijlab.net Date: Mon, 26 Mar 2001 16:30:39 +0900 Message-ID: <29686.985591839@coconut.itojun.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >Included is the "infamus" beer plan, on how to retire AAAA >everywhere but stub resolvers. >Please send all followup to namedroppers. I have a couple of questions here. Regarding to additional delays imposed to existing libc resolvers. it seems that there will be additional delays imposed during transition period, due to "A6 then AAAA" retries in multiple places in the query chain. was it taken into account? (see the end of the email for some details - hope I made no mistake) for a certain FQDN, supposed we have different values registered onto DNS database, like: z.itojun.org. IN AAAA xxxx z.itojun.org. IN A6 0 yyy what should a client see in this case? yyy, xxxx, or both? for clients that send A6 queries RD=1, is it assumed that they are able to reassemble A6 fragments? or, is it okay for them to be able to decipher "A6 0 <128bit>" only? (whether it is good idea to switch to A6 or not, is another question - it should be discussed separately in "case for/against A6") itojun scenarios: - machine X implements the proposed behavior. - machine A has old libc resolver, whch queries AAAA only for IPv6 name resolution. A will contact X with RD=1. - machine B has new libc resolver, which queries A6 then AAAA. B will contact X with RD=1. - foo.itojun.org. has AAAA record only. - bar.itojun.org. has "A6 0 <128bit>" record only. - baz.itojun.org. has "A6 0 <64bit> subnet.itojun.org." record only. - moo.itojun.org. has "A6 0 <128bit>" and AAAA record. when A queries AAAA RR of of foo.itojun.org.: A sends AAAA query to X. X will try to query A6 RR of foo.itojun.org., RD=0, to synthesize. X gets no reply. X will try to query AAAA RR of foo.itojun.org., RD=0. X gets AAAA reply. A will get an AAAA. when B queries A6 then AAAA of foo.itojun.org.: B sends A6 query to X. X will try to query A6 RR of foo.itojun.org., RD=0. X gets no reply. B gets no reply. B sends AAAA query to X. X will try to query A6 RR of foo.itojun.org., RD=0, to synthesize. X gets no reply. X will try to query AAAA RR of foo.itojun.org., RD=0. X gets AAAA reply. B will get an AAAA. when A queries AAAA RR of bar.itojun.org.: A sends AAAA query to X. X will try to query A6 RR of foo.itojun.org., RD=0, to synthesize. X will get "A6 0 <128bit>". A will get an AAAA, synthesized. when B queries A6 then AAAA of bar.itojun.org.: B sends A6 query to X. X will try to query A6 RR of foo.itojun.org., RD=0. X gets A6 reply, "A6 0 <128bit>". B will get an A6, "A6 0 <128bit>". when A queries AAAA RR of baz.itojun.org.: A sends AAAA query to X. X will try to query A6 RR of baz.itojun.org., RD=0, to synthesize. X will get "A6 0 <64bit> subnet.itojun.org.". A6 chain traversals happen from X. X gets all A6 fragments for baz.itojun.org. X reassembles A6 fragments. A will get an AAAA, synthesized. when B queries A6 then AAAA of baz.itojun.org: B sends A6 query to X. X will try to query A6 RR of foo.itojun.org., RD=0. X gets A6 reply, "A6 0 <64bit> subnet.itojun.org.". B will get A6 reply, "A6 0 <64bit> subnet.itojun.org.". B sends A6 query X for subnet.itojun.org. A6 chain traversals happen from B. B gets all A6 fragments for baz.itojun.org. B reassembles A6 fragments. when A queries AAAA RR of moo.itojun.org.: same story as bar.itojun.org. case. when B queries A6 then AAAA of moo.itojun.org.: same story as bar.itojun.org. case. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Mar 26 15:48:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16095 for ; Mon, 26 Mar 2001 15:48:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14hdPm-0002wj-00 for namedroppers-data@psg.com; Mon, 26 Mar 2001 12:16:34 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14hdPl-0002wd-00 for namedroppers@ops.ietf.org; Mon, 26 Mar 2001 12:16:33 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14hdPl-000JSH-00 for namedroppers@ops.ietf.org; Mon, 26 Mar 2001 12:16:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200103262014.f2QKEq904247@thunk.east.sun.com> From: Bill Sommerfeld To: Olafur Gudmundsson cc: namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: notes on A6 transition from AAAA (fwd) In-reply-to: Your message of "Sun, 25 Mar 2001 17:16:55 EST." Reply-to: sommerfeld@east.sun.com Date: Mon, 26 Mar 2001 15:14:52 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > A authoritative server that only has AAAA entries and > is asked for an A6 record MUST NOT synthesize A6 records > from the AAAA ones. There is no restriction on populating both > types, but it is strongly recommended against, and in such a case, > both RRsets MUST be identical. This proposal does not formally define equivalence of AAAA and A6. is this limited to zero-prefix A6, or does it include A6's with non-zero prefixes which just happen to resolve to the same thing? Based on Rob's "zero prefix A6 is equivalent to AAAA" slide, I assume the former.. > If a query does not contain EDNS indicator, then any IPv6 addresses > contain in additional data section MUST be AAAA. > > Root and TLD zones MUST only contain A6 with prefix of 0. Following the "prohibit on primary load, grumble on secondary load, allow through on cached queries" interpretation of the "be conservative in what you send, and liberal in what you accept" principle, I also assume that the "MUST"s on zone contents should be be enforced only when loading a primary.. - Bill to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Mar 26 20:19:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA23746 for ; Mon, 26 Mar 2001 20:19:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14hhsq-000Blb-00 for namedroppers-data@psg.com; Mon, 26 Mar 2001 17:02:52 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14hhsp-000BlV-00 for namedroppers@ops.ietf.org; Mon, 26 Mar 2001 17:02:51 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14hhsp-00053P-00 for namedroppers@ops.ietf.org; Mon, 26 Mar 2001 17:02:51 -0800 To: namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: notes on A6 transition from AAAA (fwd) In-Reply-To: Message from Bill Sommerfeld dated "Mon, 26 Mar 2001 15:14:52 EST" <200103262014.f2QKEq904247@thunk.east.sun.com> References: <200103262014.f2QKEq904247@thunk.east.sun.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Date: Mon, 26 Mar 2001 19:05:37 -0500 From: Rob Austein Message-Id: <20010327000539Z23296-220+147@thrintun.hactrn.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Mon, 26 Mar 2001 15:14:52 -0500 From: Bill Sommerfeld This proposal does not formally define equivalence of AAAA and A6. Right. There's still a bit of an open issue about what to do with AAAA in the long run, perhaps declare it to be a form of meta query for stub resolvers to use that means "get me an address, however that's implemented this week, and just return me the bits please". > A authoritative server that only has AAAA entries and > is asked for an A6 record MUST NOT synthesize A6 records > from the AAAA ones. There is no restriction on populating both > types, but it is strongly recommended against, and in such a case, > both RRsets MUST be identical. is this limited to zero-prefix A6, or does it include A6's with non-zero prefixes which just happen to resolve to the same thing? Based on Rob's "zero prefix A6 is equivalent to AAAA" slide, I assume the former.. No, our theory was that we really didn't want synthesized A6 RRs at all, full stop. We're not trying for parallel mechanisms here, the idea is that A6 would become the "real" data and AAAA would become the way that certain clients chose to retrieve a simplified form of it. > If a query does not contain EDNS indicator, then any IPv6 addresses > contain in additional data section MUST be AAAA. > > Root and TLD zones MUST only contain A6 with prefix of 0. Following the "prohibit on primary load, grumble on secondary load, allow through on cached queries" interpretation of the "be conservative in what you send, and liberal in what you accept" principle, I also assume that the "MUST"s on zone contents should be be enforced only when loading a primary.. As far as the software would be concerned, you're right. We were, however, also recommending that these limits be enforced by administrative policy for the root, TLDs, and other big public zones. That's out of the IETF's scope, other than making the recommendation. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Mar 26 20:21:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA23806 for ; Mon, 26 Mar 2001 20:21:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14hhoV-000Ban-00 for namedroppers-data@psg.com; Mon, 26 Mar 2001 16:58:23 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14hhoU-000Bah-00 for namedroppers@ops.ietf.org; Mon, 26 Mar 2001 16:58:22 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14hhoU-0004vj-00 for namedroppers@ops.ietf.org; Mon, 26 Mar 2001 16:58:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: namedroppers@ops.ietf.org Subject: Re: notes on A6 transition from AAAA (fwd) In-Reply-To: Message from itojun@iijlab.net dated "Mon, 26 Mar 2001 16:30:39 +0900" <29686.985591839@coconut.itojun.org> References: <29686.985591839@coconut.itojun.org> Date: Mon, 26 Mar 2001 18:53:22 -0500 From: Rob Austein Message-Id: <20010326235323Z23296-220+146@thrintun.hactrn.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Mon, 26 Mar 2001 16:30:39 +0900 From: itojun@iijlab.net Regarding to additional delays imposed to existing libc resolvers. it seems that there will be additional delays imposed during transition period, due to "A6 then AAAA" retries in multiple places in the query chain. was it taken into account? (see the end of the email for some details - hope I made no mistake) Yes, retrying for AAAA at the end adds an extra step with corresponding extra delay. This is why the proposed rule is "This entity MUST try first A6 then MAY try AAAA queries to process the request." If we go with this transition plan, we want to encourage zone admins to switch over to putting A6 into the zone files as quickly as possible so that the QTYPE=AAAA RD=0 query will become unnecessary, but implementors who are willing to suffer the additional delay and want to perform the extra query are free to do so. for a certain FQDN, supposed we have different values registered onto DNS database, like: z.itojun.org. IN AAAA xxxx z.itojun.org. IN A6 0 yyy what should a client see in this case? yyy, xxxx, or both? yyy. for clients that send A6 queries RD=1, is it assumed that they are able to reassemble A6 fragments? or, is it okay for them to be able to decipher "A6 0 <128bit>" only? In the long run, any resolver (stub or otherwise) that understands A6 should be prepared to splice the fragments together. In the short run, we're proposing that only the limited form of A6 be allowed, until developers have time to implement the full form of A6. (whether it is good idea to switch to A6 or not, is another question - it should be discussed separately in "case for/against A6") Agreed. This discussion is just about how we would transition, not about whether we should transition. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Mar 26 20:22:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA23843 for ; Mon, 26 Mar 2001 20:22:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14hhuP-000Bp2-00 for namedroppers-data@psg.com; Mon, 26 Mar 2001 17:04:29 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14hhuP-000Bow-00 for namedroppers@ops.ietf.org; Mon, 26 Mar 2001 17:04:29 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14hhuP-00056J-00 for namedroppers@ops.ietf.org; Mon, 26 Mar 2001 17:04:29 -0800 Date: Mon, 26 Mar 2001 16:10:33 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Last Call: DNS Server MIB Extensions to Historic To: Jon Saperia Cc: iesg@ietf.org, namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [Resent with correct addresses] >----------------Begin Forwarded Message----------------< Date: Mon, 26 Mar 2001 16:04:39 -0800 (PST) From: "Erik Nordmark" Subject: Re: Last Call: DNS Server MIB Extensions to Historic To: "Jon Saperia" Cc: iesg@ietf.org, namedroppers@nic.ddn.mil.cnri.reston.va > > > > > The IESG has received a request to consider reclassifying the following > > RFCs as Historic: > > > > RFC1611 'DNS Server MIB Extensions' > > RFC1612 'DNS Resolver MIB Extensions' > > > > The IESG will also consider publication of Applicability Statement for > > DNS MIB Extensions as an > > Informational RFC. > > > > draft-ietf-dnsext-dnsmib-historical-00.txt, needs revision to be a > useful document. While I do not support the move of 1611 and 1612 to > historic and would rather that the documents be revised in light of > current requirements, I am happy to work with Rob to revise the proposed > document that explains the change in status. Jon, Can you provide some more detail on what you believe is wrong in the current I-D? It was clear from the rough concensus in dnsext that the WG doesn't want to fix 1611 and 1612 but instead invites others to go off and form design team(s) to come up with relatively complete proposals for replacement MIBs. Thanks, Erik >----------------End Forwarded Message----------------< to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Mar 27 08:41:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17939 for ; Tue, 27 Mar 2001 08:41:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14htGl-00087q-00 for namedroppers-data@psg.com; Tue, 27 Mar 2001 05:12:19 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14htGk-00087k-00 for namedroppers@ops.ietf.org; Tue, 27 Mar 2001 05:12:18 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14ht56-000Ocr-00 for namedroppers@ops.ietf.org; Tue, 27 Mar 2001 05:00:16 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200103271217.HAA10224@europa-h0001027441c5.ne.mediaone.net> To: Erik.Nordmark@eng.sun.com cc: iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: Last Call: DNS Server MIB Extensions to Historic (fwd) From: Jon Saperia Date: Tue, 27 Mar 2001 07:17:41 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>> The IESG has received a request to consider reclassifying the following >>> RFCs as Historic: >>> >>> RFC1611 'DNS Server MIB Extensions' >>> RFC1612 'DNS Resolver MIB Extensions' >>> >>> The IESG will also consider publication of Applicability Statement for >>> DNS MIB Extensions as an >>> Informational RFC. >>> >> >> draft-ietf-dnsext-dnsmib-historical-00.txt, needs revision to be a >> useful document. While I do not support the move of 1611 and 1612 to >> historic and would rather that the documents be revised in light of >> current requirements, I am happy to work with Rob to revise the proposed >> document that explains the change in status. > > Jon, > > Can you provide some more detail on what you believe is wrong in > the current I-D? > > It was clear from the rough concensus in dnsext that the WG doesn't > want to fix 1611 and 1612 but instead invites others to go off and form > design team(s) to come up with relatively complete proposals for replacement > MIBs. > > Thanks, > Erik > There is only one significant issue even though I disagree with the movement to historic in this context since is rare. The issue is the language in the ID. Specifically a number of comments like: "In retrospect, it's obvious that the working group never had much agreement on what belonged in the MIB extensions, just that we should have some." The document was well discussed during it's creation and created with considerable input from a number of people involved with the technology at the time. "This happened during the height of the craze for MIB extensions in virtually every protocol that the IETF was working on at the time, so the question of why we were doing this in the first place never got a lot of scrutiny." Also incorrect, in fact there was a version that was created with configuration objects - I know I wrote them - that was asked to be removed during a review because some felt concern for security. The document does point to some of this which does suggest that there was review and thinking about what should have gone in at that time. Unless things have changed, protocols developed in WGs do require MIB Modules since that is at present still the standard management we use. The DNS Server and Resolver MIB extensions were one of the first attempts to write MIB extensions for a protocol usually considered to be at the application layer. Fairly early on it became clear that, while it was certainly possible to write MIB extensions for DNS, the SMI was not really designed with this sort of thing in mind. A case in point was the attempt to provide direct indexing into the caches in the resolver MIB extensions: while arguably the only sane way to do this for a large cache, this required much more complex indexing clauses than is usual, and ended up running into known length limits for object identifiers in some SNMP implementations. We have learned a lot in the past few years about how to write MIB Modules. The DNS Resolver and Server Modules are among the first using SMIv2. If the WG wishes to 'do it over' rather than fix these, that is one approach. Finally, the MIB extensions took much too long to produce. In retrospect, this should have been a clear warning sigh, particularly when the WG had clearly become so tired of the project that the authors found it impossible to elicit any comments whatsoever on the documents. Or it may have been that the WG at the time was more interested in the protocol an not management. The author would like to thank all the people who were involved in this silly project over the years for their optimism and patience, misguided though it may have been. I do agree that it was a silly little project if we learned something. It is not my intent to make more of this than is needed. I am fine with the movement to historic even though that is not the approach I would take, much of the 1611 and 1612 documents were based on the foundation DNS RFCs - the fact that a 'commonly' available implementation supported them is a good thing. My issue is more one of tone and poorly supported conclusions that seem rooted in a predisposition to use alternate methods. Some of the other conclusions are valuable and have been included in various other documents - repeating them here is harmless and perhaps even beneficial. An example: - Keep the MIB extensions short, and don't add variables just because somebody in the WG thinks they'd be a cool thing to measure. Thanks for giving me the opportunity to comment. I will not raise further objections. Thanks, /jon -- Jon Saperia saperia@jdscons.com Phone: 617-744-1079 Fax: 617-249-0874 http://www.jdscons.com/ to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Mar 28 00:00:44 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA18537 for ; Wed, 28 Mar 2001 00:00:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14i7Ym-000PsJ-00 for namedroppers-data@psg.com; Tue, 27 Mar 2001 20:27:52 -0800 Received: from [206.163.43.51] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14i7Yk-000PsD-00 for namedroppers@ops.ietf.org; Tue, 27 Mar 2001 20:27:51 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14i7Yk-00031x-00 for namedroppers@ops.ietf.org; Tue, 27 Mar 2001 23:27:50 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200103271936.f2RJae919544@thunk.east.sun.com> From: Bill Sommerfeld To: Rob Austein cc: namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: notes on A6 transition from AAAA (fwd) In-reply-to: Your message of "Mon, 26 Mar 2001 19:05:37 EST." <20010327000539Z23296-220+147@thrintun.hactrn.net> Reply-to: sommerfeld@east.sun.com Date: Tue, 27 Mar 2001 14:36:39 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > A authoritative server that only has AAAA entries and > > is asked for an A6 record MUST NOT synthesize A6 records > > from the AAAA ones. There is no restriction on populating both > > types, but it is strongly recommended against, and in such a case, > > both RRsets MUST be identical. > > is this limited to zero-prefix A6, or does it include A6's with > non-zero prefixes which just happen to resolve to the same thing? > Based on Rob's "zero prefix A6 is equivalent to AAAA" slide, I assume > the former.. > > No, our theory was that we really didn't want synthesized A6 RRs at > all, full stop. I was asking about the "populating both types as long as both RRsets are identical" approach -- you need to define what you mean by "identical". to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Mar 28 00:17:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA19224 for ; Wed, 28 Mar 2001 00:17:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14i85P-0000aU-00 for namedroppers-data@psg.com; Tue, 27 Mar 2001 21:01:35 -0800 Received: from [206.163.43.51] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14i85M-0000ZL-00 for namedroppers@ops.ietf.org; Tue, 27 Mar 2001 21:01:33 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14i85K-00036x-00 for namedroppers@ops.ietf.org; Wed, 28 Mar 2001 00:01:30 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: RE: comments on mnds-00 Date: Tue, 27 Mar 2001 16:13:00 -0800 Message-ID: <5B90AD65A9E8934987DB0C8C0762657420FDD3@DF-BOWWOW.platinum.corp.microsoft.com> From: "Dave Thaler" To: "Erik Guttman" , Cc: , "Bernard Aboba" , "Levon Esibov" , Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik, I'll reply to one of your comments and leave the others for others to respond to. > >The responder MUST set the Hop Limit > >field in IPv6 header and TTL field in IPv4 header of all responses to > >the multicast DNS query to 255. The sender MUST verify that the Hop > >Limit field in IPv6 header and TTL field in IPv4 header of=20 > each response > >to the multicast DNS query is set to 255. If it is not, then=20 > sender MUST > >ignore such response. >=20 > Shouldn't IPv6 hop count / IPv4 TTL be 1 for link-local multicast dns? > If this is a 'clever trick' which will cause listeners to=20 > drop messages > after they've traversed a single router (they will always be=20 > less than=20 > 255 in this case), I claim this is not a good idea. A link-local=20 > protocol shouldn't be routed at all: We choose an address we specify=20 > routers must not forward, and we send with hop count/ttl =3D 1=20 > to further=20 > reduce this possibility. This rule is basically stolen from RFC 2461 which solves the same problem the same way. It's true that what we really want is to ensure that a packet we got was not routed. The TTL=3D255 method is safe, and solves the problem regardless of how we got the message (i.e. via either unicast or multicast). An equivalent method would probably be to verify that the destination address was the link-scoped address (and not one of our unicast addresses, for example). In an attempt to avoid the debate over which mechanism is best, the=20 draft just copied the one that is already at Draft Standard for=20 another link-local protocol (ND). -Dave to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Mar 28 00:18:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA19264 for ; Wed, 28 Mar 2001 00:18:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14i84F-0000Ym-00 for namedroppers-data@psg.com; Tue, 27 Mar 2001 21:00:23 -0800 Received: from [206.163.43.51] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14i84B-0000Yc-00 for namedroppers@ops.ietf.org; Tue, 27 Mar 2001 21:00:20 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14i849-00036o-00 for namedroppers@ops.ietf.org; Wed, 28 Mar 2001 00:00:17 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200103272347.BAA20439@efra05-home.Germany.Sun.COM> Date: Tue, 27 Mar 2001 15:47:03 -0800 (PST) From: Erik Guttman Reply-To: Erik Guttman Subject: comments on mnds-00 To: namedroppers@psg.com Cc: erik.guttman@sun.com, dthaler@microsoft.com, bernarda@microsoft.com, levone@microsoft.com, cheshire@apple.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Levon, Bernard, The following comments concern draft-ietf-dnsext-mdns-00.txt >A sender sends multicast DNS query for any legal Type of resource record >(e.g. A, PTR, etc=E0) for a name within the ".local.arpa." domain to the ^ word cruft >LINKLOCAL address. If the name is in .local.arpa that indicates it MUST be multicast. That is, there is no sense in unicasting this request elsewhere=20 since it will have only local significance. The converse is not true: Why can't a host multicast a request for a host name which is not qualified with '.local.arpa'? If this is=20 not allowed, it severely limits the utility of mdns. FQDNs are present in many protocols, configuration files, documents... If these cannot be resolved locally, what is the point of mdns? =20 I suggest that a mdns name server serve only those names which the host has been configured with - suggesting the addition of a local name (alias). This name can be used by protocols which advertise local services, which are found via a link-local service discovery protocol. =20 The advantage of using a local name instead of a string representation=20 of an IP address is that the local name will remain valid even when the=20 host renumbers (which it could do at any time when using IPv4 link-local=20 autoconfiguraion). This alone is not a compelling reason to use local names. >In this example (unless this >limitation introduced) the multicast query for an A record for the name >"child.host.example.com.local.arpa." would cause two authoritative >responses: name error received from "host.example.com.local.arpa.", and >requested A record - from "child.host.example.com.local.arpa.". 1. Multicast DNS servers should not send error replies - these=20 should be dropped. =20 Multicast discovery protocols which require all listeners to respond with a unicast error reply cause broadcast storms. =20 This is undesirable on a link-local network. If mdns were=20 ever to be defined at a larger scope (say administrative=20 scope) in the future, this would be completely unacceptable. =20 The protocol has to return correct replies to correct=20 requests, that's all. 2. Given that, I do not understand the ambiguity. A host not=20 configured with a name would not respond to a request for it. =20 >The responder MUST set the Hop Limit >field in IPv6 header and TTL field in IPv4 header of all responses to >the multicast DNS query to 255. The sender MUST verify that the Hop >Limit field in IPv6 header and TTL field in IPv4 header of each response >to the multicast DNS query is set to 255. If it is not, then sender MUST >ignore such response. Shouldn't IPv6 hop count / IPv4 TTL be 1 for link-local multicast dns? If this is a 'clever trick' which will cause listeners to drop messages after they've traversed a single router (they will always be less than=20 255 in this case), I claim this is not a good idea. A link-local=20 protocol shouldn't be routed at all: We choose an address we specify=20 routers must not forward, and we send with hop count/ttl =3D 1 to further= =20 reduce this possibility. >The responder includes in the additional and authority section of the >response the same records, as a DNS server would insert in the response >to the unicast DNS query. Please reword: The responder SHOULD include an NS record for itself in the authority=20 section and an A record in the additional section of the response. =20 This is behavior is consistent with existing DNS server implementations. >Sender MUST anticipate receiving no replies to some multicasted queries, >in the event that no responders are available within the multicast >scope, or in the event that no positive non-null responses exist to the >transmitted query. A responder must not send anything except a positive non-null response. That is, a null response or a negative response MUST NOT be sent. The argument for this is given above. >If no positive response is received, a resolver treats it as a response >that no records of the specified type and class for the specified name >exist (NXRRSET), which SHOULD be cached for a period that SHOULD NOT >exceed 5 seconds. =20 Why define this behavior? This is complicated and will make little difference when a single mdns request is already takes a few seconds=20 to complete. =20 >Sender MUST anticipate receiving multiple replies to the same >multicasted query, in the event that several multicast DNS enabled >computers receive the query and respond with valid answers. When this >occurs, the responses MAY first be concatenated, and then treated in the >same manner that multiple RRs received from the same DNS server would, >ordinarily. With 'MAY' an existing resolver can simply use the mdns address and accept the first result, where an enhanced resolver would do something slicker. The problem here is you don't get back the same info as you would from a DNS server. Collecting the duplicates and collating them requires additional code, but perhaps it 'SHOULD' be done. >Any device whose domain search configuration contains ".local.arpa."=20 >domain is configured to behave as "responder". Why should this behavior be configured using the search path? Why should the resolver search path IN ANY CASE determine the=20 multicast dns server behavior? I suggest that, just as other zeroconf protocols, a host may either run this zeroconf protocol service or not. This need not be something that can be turned off by DHCP, nor should it be - any more than v4LL autoconfiguration. >It is not expected that a device "host.example.com." will be manually >configured to have additional name "host.example.com.local.arpa." when >it is configured to use multicast DNS. Instead, a responder with a name >"host.example.com." configured with ".local.arpa." suffix in its domain >search configuration is authoritative for the name >"host.example.com.local.arpa.". I.e. when responder with the name >"host.example.com." receives an A type query for the name >"host.example.com.local.arpa." it authoritatively responds to the query. Why attache the suffix '.local.arpa' stuff? Why not just multicast a request for 'host.example.com'? I thought '.local.arpa' allowed a separate namespace for queries which would not be in the DNS. If you append it, you effectively alias names in the DNS to the local namespace - buying you nothing. A host may have a '.local.arpa' name, entirely self administered, *in addition* to its normal (fully qualified) domain name. An=20 mdns responder should respond to either. In any case, why should the resolver search path effect responder behavior? >The same device may use multicast DNS queries for the name resolution of >the names ending with ".local.arpa.", and unicast DNS queries for name >resolution of all other names. Why can't a resolver multicast *any* request as a last resort. For=20 example if no DNS server responds. This would be the effect of putting if the link-local mdns address as the last nameserver entry=20 in /etc/resolv.conf. I think this makes tremendous sense and provides the primary benefit of using mdns: reliability. >It is required to verify the uniqueness of the host DNS name when a host >boots, when its name is changed, or when it is configured to use >multicast DNS (such as when the domain search option is changed to >include ".local.arpa."). Why is it required? I could desire to have multiple devices respond to the same name for some conceivable application (the devices are all redundent identical stateless doodads, for example.) =20 This may be desirable, but at most a SHOULD. >A gratuitous name resolution query SHOULD be done to check for a name >conflict. This is done by having the resolver send a multicast query for >a SOA type query for its own name (i.e. for the name it is authoritative >for). Why not just look for an A or PTR RR. If another mdns server respondes to= =20 the request, there's a conflict. Do mdns servers need to support SOA RR requests? The zeroconf requirements only state A and PTRs are required. >A host that has detected a name conflict MUST NOT use the name. SHOULD NOT >Note that this name conflict detection mechanism doesn't prevent name >conflicts when previously separate networks are connected by a bridge. >Name conflict in such situation is detected when a sender receives more >than one response to its multicasted DNS query. This is not catastrophic. This is like getting back multiple results. >8. Acknowledgements > >The authors would like to thank Stuart Cheshire, Michael Patton, Erik >Guttman, Olafur Gudmundsson, Thomas Narten, Mark Andrews, Erik Nordmark, >Myrong Hattig, Bill Manning and James Gilroy for comments on this draft. I believe that this section should read: This work builds upon original work done on multicast DNS by Bill Manning= =20 and Bill Woodcock. The authors gratefully acknowledge their contribution to the current specification. Constructive input has also been received=20 from Mark Andrews, Stuart Cheshire, James Gilroy, Olafur Gudmundsson,=20 Erik Guttman, Myron Hattig, Thomas Narten and Erik Nordmark. Erik =20 to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Mar 28 06:51:10 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA23797 for ; Wed, 28 Mar 2001 06:51:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14iE7D-0009DZ-00 for namedroppers-data@psg.com; Wed, 28 Mar 2001 03:27:51 -0800 Received: from [147.28.4.2] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14iE7C-0009DS-00 for namedroppers@ops.ietf.org; Wed, 28 Mar 2001 03:27:51 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14iE7D-0003K8-00 for namedroppers@ops.ietf.org; Wed, 28 Mar 2001 06:27:51 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 28 Mar 2001 00:21:50 -0500 (EST) From: Olafur Gudmundsson To: Bill Sommerfeld cc: Rob Austein , namedroppers@ops.ietf.org Subject: Re: notes on A6 transition from AAAA (fwd) In-Reply-To: <200103271936.f2RJae919544@thunk.east.sun.com> Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 27 Mar 2001, Bill Sommerfeld wrote: >> > A authoritative server that only has AAAA entries and >> > is asked for an A6 record MUST NOT synthesize A6 records >> > from the AAAA ones. There is no restriction on populating both >> > types, but it is strongly recommended against, and in such a case, >> > both RRsets MUST be identical. >> >> is this limited to zero-prefix A6, or does it include A6's with >> non-zero prefixes which just happen to resolve to the same thing? >> Based on Rob's "zero prefix A6 is equivalent to AAAA" slide, I assume >> the former.. >> >> No, our theory was that we really didn't want synthesized A6 RRs at >> all, full stop. > > I was asking about the "populating both types as long as both RRsets > are identical" approach -- you need to define what you mean by > "identical". > Identical == same number of records in both sets and for each AAAA record there exists A6/0 record with same address An A6/n (where n> 0) pointing at an routing prefix does not count even if A6 synthesis would generate an A6/0 identical to one of the AAAA. Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Mar 28 12:23:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05479 for ; Wed, 28 Mar 2001 12:23:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14iJIX-000GWk-00 for namedroppers-data@psg.com; Wed, 28 Mar 2001 08:59:53 -0800 Received: from cbb-sc2.cbbtier3.att.net ([12.0.1.9] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 14iJHS-000GTs-00 for namedroppers@ops.ietf.org; Wed, 28 Mar 2001 08:59:49 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14iJGx-0003Wu-00 for namedroppers@ops.ietf.org; Wed, 28 Mar 2001 11:58:15 -0500 Message-Id: In-Reply-To: <200103281417.f2SEHRi62887@open.nlnetlabs.nl> References: "Edward Lewis's message as of Mar 22, 0:29" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 28 Mar 2001 10:48:07 -0500 To: Ted.Lindgreen@tednet.nl From: Edward Lewis Subject: Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt) Cc: Edward Lewis , namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I was about send another message on this topic today even before I saw your reply. We (CAIRN) were discussing this proposal and had a few questions. (Coincidently referencing this section: At 9:17 AM -0500 3/28/01, Ted Lindgreen wrote: > Now having dealt with the parental SIG, how about the KEY? > In contrast to the SIG, I can think of philosofical arguments > to have either child or parent to be authoritive. However, the > technical arguments are straightforward to make the same zone > authoritive for this RR as its SIG. ) Some folks have A records at the zone apex (cnn.com comes to mind), which leads me to believe that in the future some folks may have non-zone keys at the apex. This implies that the parent will be signing a mix of zone and non-zone keys for such a delegation. The idea of having the parent (.com) being authoritative for cnn.com's IPSEC key seems somewhat "hard to sell." I see the point of having the SIG be at .com, and therefore the KEYs be from .com, but when we look at the non-zone keys, having the parent be authoritative is a hard sell. 'Course there is the debate of whether a A at the apex is tasteful, but that's not our call (we're just engineers). > For DNS to work, there is no reason to include the zone-KEY in > the child-zone, when its already in the parent-zone, blessed > with a parental SIG. The only reason, we have proposed to > have it self-signed in the child-zone is to make a key-rollover > work securily without additional security methods. With this > RRset in two places, there will be instances where both RRsets > are different. In order to have the resolver pick the right > one in case of a conflict, we propose that the child does not > set the AA-flag on queries for its KEY-RRset, and the parent > does. There is a few reasons to have the data in the parent. Cement trucks, backhoes, and (for those in certain areas) shotguns are reasons. (;)) We just had a cable cut severing us from the Internet, so we couldn't get to the parent zone. The upshot of this is that I may want to have self-signed keys configured locally to continue secure lookups. ('Course, who am I protecting myself against - if the Internet "is down.") -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Mar 28 12:24:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05509 for ; Wed, 28 Mar 2001 12:24:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14iJAr-000GHj-00 for namedroppers-data@psg.com; Wed, 28 Mar 2001 08:51:57 -0800 Received: from cbb-sc2.cbbtier3.att.net ([12.0.1.9] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 14iJAq-000GHQ-00 for namedroppers@ops.ietf.org; Wed, 28 Mar 2001 08:51:56 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14iJAL-0003WS-00 for namedroppers@ops.ietf.org; Wed, 28 Mar 2001 11:51:25 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200103281417.f2SEHRi62887@open.nlnetlabs.nl> From: ted@tednet.nl (Ted Lindgreen) Date: Wed, 28 Mar 2001 16:17:27 +0200 In-Reply-To: "Edward Lewis's message as of Mar 22, 0:29" Reply-To: Ted.Lindgreen@tednet.nl To: Edward Lewis , namedroppers@ops.ietf.org Subject: Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Quoting Edward Lewis, on Mar 22, 0:29, in "Signature at parent ..."] > I don't know what to think about this proposal. It is counter to a lot of > background of DNS (e.g., the child's apex data being more credible than > that at the parent). I see that this issue gives rise to a conflict of > credible vs. valid. Yes, we agree that this is an anomaly. However, having been thinking about it for a long time, I think I can explain it. There are more anomalies at a delegation point. For instance, both parent and child have the child's NS records. And at some time we saw the statement: "the child is more authoritive" for these RRs, very confusing.... I could explain this strangeness to students by comparing it with roadsigns: In the country (parent) there signs with a cityname giving directional information how to get there. At the city (child) boundary, the city has placed similar signs, but now they are declaring "the city starts here". The country-signs are informational, thus not authoritive, the city-signs are declarations, thus authoritive. Once this is understood, explaining glue-records is even more simple. However, with the parental SIG over the child's KEY, I could not possibly get away with this line of explaining, as it is clear that the parent is declaring "I have delegated this zone to the holder of this KEY, and I am signing for it with this SIG". Clearly, philosofically speaking, the parent is authoritive, not the child. From our testbed, we learned that also technically there are strong arguments to let the parent be authoritive for its own SIG, arguments are maintainability, responsibility, and scalability. We know this conflicts with the background of DNS, but so be it. Also, this anomaly is not new, it was introduced already with the parental NULL-KEY for clueless childs. Now having dealt with the parental SIG, how about the KEY? In contrast to the SIG, I can think of philosofical arguments to have either child or parent to be authoritive. However, the technical arguments are straightforward to make the same zone authoritive for this RR as its SIG. Now for the childs zone file. We found that there are strong technical arguments to NOT have the parental SIG in the childs zone, even when its just glue. The same arguments as mentioned above (maintainability, responsibility, and scalability) are valid here. I know we accept the same NS and (glue)-A RRset's at parent and child, but there is little harm done when these RRset are not completely identical: we have a lame or an unused server, ugly, but not desasterous. However, having an invalid SIG causes a subtree to drop of the Internet. So, a SIG must not be in two places, thus the child must not include the parental SIG in its zone file. For DNS to work, there is no reason to include the zone-KEY in the child-zone, when its already in the parent-zone, blessed with a parental SIG. The only reason, we have proposed to have it self-signed in the child-zone is to make a key-rollover work securily without additional security methods. With this RRset in two places, there will be instances where both RRsets are different. In order to have the resolver pick the right one in case of a conflict, we propose that the child does not set the AA-flag on queries for its KEY-RRset, and the parent does. > There are a number of cases to consider but are uninteresting (like the > parent and child having the same KEY RR set for the child). The > interesting cases are when there are different data and when there is the > concern of liability. Yes, liability is an important concern. We think that this is served best with our proposal: when the signer has its own sigs under his own control there is less possibility to screw it up, but if screwed up it's clear who is to blame for it. With the original idea, where KEY and SIG records are sent out-of-band and having parent-SIGs in childs zonefiles, the chance of a screwup is much larger, and the various involved system administrators will certainly point to each other to blame. > When there are different data (probably just a different SIG RR) between > the child and the parent, it will probably be true that the (parent) key > validating the SIG RR at the child is not available from an authoritative > source (just caches). This means that unless there is a glitch, the > child's more credible key set won't be validated by a third party. > Question: is it acceptable to accept less credibile data if it validates > over more credible but unvalid data? (Seems so.) I'm not sure I understand this. In our proposal, the parent's SIG over the childs KEY-RRset is in the parents zone file, and only there. So, there are no conflicting SIGs. With the parent being also (more) authoritive over the childs KEY RRset I don't think this scheme can happen. > Note that there is that "glitch." This is essentially the time that an > undesired key remains alive in a cache - up to a TTL value. I don't think > there is a way around this, DNS is not real time and we don't have a way to > publish revokation lists. (And I don't think that we want to define this.) True, we think the secure aware resolver must be aware of the possibility of such glitches and that we must write up an unambigious way to solve it while preventing loops. > If someone has discovered the private key and this is the reason for the > key change, the attacker can get away with misuse of the key for only as > long as the discovered key is signed by its parent. Again, for the same > reason above, I don't think we have a way to stop this period of > vulnerability. Yes, very true. Even when the parent performs an emergency key-rollover, there will be cached (but valid!) old info around for some time. For this reason, we think that parents SIGs over childs KEYs must have a short lifetime. Making re-signing easy helps. In our testbed, we re-sign daily, so this vulnerability lasts one day. > Now, as far as liability - that the parent might present data that > invalidates a child or allows for a child to continue to fall prey to an > attack (because a key is not withdrawn), I don't think this is an area we > can engineer around. Same arguement about the non-real time-ness and no > revokation list ability. True. But if a parent, especially a TLD, screws up in such a way, it is not doing what it is paid for and should be liable IMHO. It can also happen nowadays already when a TLD puts in wrong NS or glue records. > Finally, there is something that I am concerned about. When a child > changes their key, the key is sent to the parent who then signs it. If the > parent then publishes the key, the child hasn't had a chance to make sure > the key wasn't substituted on the way to the parent. This is not how it is proposed in draft-ietf-dnsop-parent-sig-00.txt. The child only notifies the parent (such notify can be spoofed, but is this is harmless). After the notify, the parent collects the new KEYset, and checks that it is signed with the old KEY that the parent still has in its zonefile. Only when it validates, the parent will update it. So, substituting with a false KEY won't work. Thanks Ed for your questions, regards, -- Ted. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Mar 28 12:28:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05542 for ; Wed, 28 Mar 2001 12:28:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14iJPD-000Gia-00 for namedroppers-data@psg.com; Wed, 28 Mar 2001 09:06:47 -0800 Received: from cbb-sc2.cbbtier3.att.net ([12.0.1.9] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 14iJPA-000GhX-00 for namedroppers@ops.ietf.org; Wed, 28 Mar 2001 09:06:47 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14iJOf-0003Xe-00 for namedroppers@ops.ietf.org; Wed, 28 Mar 2001 12:06:13 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WG Last Call: AD is Secure References: <5.0.2.1.0.20010313113429.0324e540@gatt.dc.ogud.com> From: Bob Halley Date: 28 Mar 2001 08:39:34 -0800 In-Reply-To: Olafur Gudmundsson's message of "Tue, 13 Mar 2001 11:35:03 -0500" Message-ID: Lines: 29 X-Mailer: Gnus v5.7/Emacs 20.5 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Olafur Gudmundsson writes: > This draft is on standards track, if you disagree with that please state why > in your response. The draft says: If the answer section contains any data, the server MUST NOT include data in the authority section that would cause the AD bit to be unset. This is a problem, since we could have a CNAME/DNAME chain that started in a secure zone and ended in an unsecure zone where the name exists but the desired rdata type does not. We'd like to put the (unsigned) SOA into the authority section to make a negative response, but the text of the draft forbids this. The only value of AD is to a "DNSSEC mostly unaware" client who wants to know that "the answer" to its question was authenticated; a fully aware implementation will simply ignore AD and validate the signatures itself. I think the draft should be revised, saying something like: AD should be set if and only if all RRs in the answer section, and any relevant negative response RRs in the authority section are Authenticated. /Bob to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Mar 28 21:35:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA18930 for ; Wed, 28 Mar 2001 21:35:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14iRqW-00040e-00 for namedroppers-data@psg.com; Wed, 28 Mar 2001 18:07:32 -0800 Received: from [206.163.43.51] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14iRqV-00040X-00 for namedroppers@ops.ietf.org; Wed, 28 Mar 2001 18:07:32 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14iJPt-0003Xm-00 for namedroppers@ops.ietf.org; Wed, 28 Mar 2001 12:07:29 -0500 Date: Wed, 28 Mar 2001 08:58:17 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: comments on mnds-00 To: Erik Guttman Cc: namedroppers@psg.com, erik.guttman@sun.com, dthaler@microsoft.com, bernarda@microsoft.com, levone@microsoft.com, cheshire@apple.com In-Reply-To: "Your message with ID" <200103272347.BAA20439@efra05-home.Germany.Sun.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Shouldn't IPv6 hop count / IPv4 TTL be 1 for link-local multicast dns? > If this is a 'clever trick' which will cause listeners to drop messages > after they've traversed a single router (they will always be less than=20 > 255 in this case), I claim this is not a good idea. A link-local=20 > protocol shouldn't be routed at all: We choose an address we specify=20 > routers must not forward, and we send with hop count/ttl =3D 1 to further= > =20 > reduce this possibility. You seem to be touching on two issues: 1. should be able to span more than one link 2. even on one link the ttl 255 trick is undesired or broken. Did I get that right? The issue the 255 trick is addressing is attacks from far away by injecting bogus unicast responses. Using ttl=1 doesn't address that. Requiring that both source and destination be link local unicast/multicast would accomplish close to the same thing as the ttl 255 trick, but RFC 2461 uses non-link local addresses in some cases which is why it mandates ttl 255. Erik to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Mar 28 21:39:07 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA19172 for ; Wed, 28 Mar 2001 21:39:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14iS3H-0004H6-00 for namedroppers-data@psg.com; Wed, 28 Mar 2001 18:20:43 -0800 Received: from [206.163.43.51] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14iS3G-0004Gx-00 for namedroppers@ops.ietf.org; Wed, 28 Mar 2001 18:20:43 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14iS3J-0003aA-00 for namedroppers@ops.ietf.org; Wed, 28 Mar 2001 21:20:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3AC2326B.981A90C9@daimlerchrysler.com> Date: Wed, 28 Mar 2001 13:50:19 -0500 From: Kevin Darcy To: namedroppers@ops.ietf.org Subject: Further Comment, DNSEXT WGLC: AXFR Clarify Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The draft says (Section 3): > If the master server is unable or unwilling to provide a zone > transfer, it MUST respond with a single DNS message containing an > appropriate RCODE other than NOERROR. > Later (Section 3.2), it says that the AA flag in the response is "1 (but MAY be 0 when RCODE is nonzero)". (By the way, is it good form to equate "other than NOERROR" with "nonzero"?) I would prefer things to be more explicit, in the case where the server is not authoritative for the requested zone. Either a) return RCODE=NOTAUTH, or b) at the very least, *require* AA=0 in this situation, and AA=1 in all other RCODE!=NOERROR situations. The ultimate goal should be the ability for the client to know unambiguously that the server is not authoritative for the zone. - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Mar 28 22:10:01 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA20692 for ; Wed, 28 Mar 2001 22:10:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14iSVm-0005FJ-00 for namedroppers-data@psg.com; Wed, 28 Mar 2001 18:50:10 -0800 Received: from [206.163.43.51] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14iSVR-0005Ef-00 for namedroppers@ops.ietf.org; Wed, 28 Mar 2001 18:49:52 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14iSVP-0003cY-00 for namedroppers@ops.ietf.org; Wed, 28 Mar 2001 21:49:47 -0500 Message-Id: <200103290212.EAA14494@efra05-home.Germany.Sun.COM> Date: Wed, 28 Mar 2001 18:11:57 -0800 (PST) From: Erik Guttman Reply-To: Erik Guttman Subject: comments on mnds-00 To: namedroppers@psg.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=ISO-8859-1 Content-MD5: TDpYZkUh8M9vIZ7qidil0w== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id WAA20692 Levon, Bernard, Apologies if this is a duplicate message. The following comments concern draft-ietf-dnsext-mdns-00.txt >A sender sends multicast DNS query for any legal Type of resource record >(e.g. A, PTR, etcà) for a name within the ".local.arpa." domain to the ^ word cruft >LINKLOCAL address. If the name is in .local.arpa that indicates it MUST be multicast. That is, there is no sense in unicasting this request elsewhere since it will have only local significance. The converse is not true: Why can't a host multicast a request for a host name which is not qualified with '.local.arpa'? If this is not allowed, it severely limits the utility of mdns. FQDNs are present in many protocols, configuration files, documents... If these cannot be resolved locally, what is the point of mdns? I suggest that a mdns name server serve only those names which the host has been configured with - suggesting the addition of a local name (alias). This name can be used by protocols which advertise local services, which are found via a link-local service discovery protocol. The advantage of using a local name instead of a string representation of an IP address is that the local name will remain valid even when the host renumbers (which it could do at any time when using IPv4 link-local autoconfiguraion). This alone is not a compelling reason to use local names. >In this example (unless this >limitation introduced) the multicast query for an A record for the name >"child.host.example.com.local.arpa." would cause two authoritative >responses: name error received from "host.example.com.local.arpa.", and >requested A record - from "child.host.example.com.local.arpa.". 1. Multicast DNS servers should not send error replies - these should be dropped. Multicast discovery protocols which require all listeners to respond with a unicast error reply cause broadcast storms. This is undesirable on a link-local network. If mdns were ever to be defined at a larger scope (say administrative scope) in the future, this would be completely unacceptable. The protocol has to return correct replies to correct requests, that's all. 2. Given that, I do not understand the ambiguity. A host not configured with a name would not respond to a request for it. >The responder MUST set the Hop Limit >field in IPv6 header and TTL field in IPv4 header of all responses to >the multicast DNS query to 255. The sender MUST verify that the Hop >Limit field in IPv6 header and TTL field in IPv4 header of each response >to the multicast DNS query is set to 255. If it is not, then sender MUST >ignore such response. Shouldn't IPv6 hop count / IPv4 TTL be 1 for link-local multicast dns? If this is a 'clever trick' which will cause listeners to drop messages after they've traversed a single router (they will always be less than 255 in this case), I claim this is not a good idea. A link-local protocol shouldn't be routed at all: We choose an address we specify routers must not forward, and we send with hop count/ttl = 1 to further reduce this possibility. >The responder includes in the additional and authority section of the >response the same records, as a DNS server would insert in the response >to the unicast DNS query. Please reword: The responder SHOULD include an NS record for itself in the authority section and an A record in the additional section of the response. This is behavior is consistent with existing DNS server implementations. >Sender MUST anticipate receiving no replies to some multicasted queries, >in the event that no responders are available within the multicast >scope, or in the event that no positive non-null responses exist to the >transmitted query. A responder must not send anything except a positive non-null response. That is, a null response or a negative response MUST NOT be sent. The argument for this is given above. >If no positive response is received, a resolver treats it as a response >that no records of the specified type and class for the specified name >exist (NXRRSET), which SHOULD be cached for a period that SHOULD NOT >exceed 5 seconds. Why define this behavior? This is complicated and will make little difference when a single mdns request is already takes a few seconds to complete. >Sender MUST anticipate receiving multiple replies to the same >multicasted query, in the event that several multicast DNS enabled >computers receive the query and respond with valid answers. When this >occurs, the responses MAY first be concatenated, and then treated in the >same manner that multiple RRs received from the same DNS server would, >ordinarily. With 'MAY' an existing resolver can simply use the mdns address and accept the first result, where an enhanced resolver would do something slicker. The problem here is you don't get back the same info as you would from a DNS server. Collecting the duplicates and collating them requires additional code, but perhaps it 'SHOULD' be done. >Any device whose domain search configuration contains ".local.arpa." >domain is configured to behave as "responder". Why should this behavior be configured using the search path? Why should the resolver search path IN ANY CASE determine the multicast dns server behavior? I suggest that, just as other zeroconf protocols, a host may either run this zeroconf protocol service or not. This need not be something that can be turned off by DHCP, nor should it be - any more than v4LL autoconfiguration. >It is not expected that a device "host.example.com." will be manually >configured to have additional name "host.example.com.local.arpa." when >it is configured to use multicast DNS. Instead, a responder with a name >"host.example.com." configured with ".local.arpa." suffix in its domain >search configuration is authoritative for the name >"host.example.com.local.arpa.". I.e. when responder with the name >"host.example.com." receives an A type query for the name >"host.example.com.local.arpa." it authoritatively responds to the query. Why attache the suffix '.local.arpa' stuff? Why not just multicast a request for 'host.example.com'? I thought '.local.arpa' allowed a separate namespace for queries which would not be in the DNS. If you append it, you effectively alias names in the DNS to the local namespace - buying you nothing. A host may have a '.local.arpa' name, entirely self administered, *in addition* to its normal (fully qualified) domain name. An mdns responder should respond to either. In any case, why should the resolver search path effect responder behavior? >The same device may use multicast DNS queries for the name resolution of >the names ending with ".local.arpa.", and unicast DNS queries for name >resolution of all other names. Why can't a resolver multicast *any* request as a last resort. For example if no DNS server responds. This would be the effect of putting if the link-local mdns address as the last nameserver entry in /etc/resolv.conf. I think this makes tremendous sense and provides the primary benefit of using mdns: reliability. >It is required to verify the uniqueness of the host DNS name when a host >boots, when its name is changed, or when it is configured to use >multicast DNS (such as when the domain search option is changed to >include ".local.arpa."). Why is it required? I could desire to have multiple devices respond to the same name for some conceivable application (the devices are all redundent identical stateless doodads, for example.) This may be desirable, but at most a SHOULD. >A gratuitous name resolution query SHOULD be done to check for a name >conflict. This is done by having the resolver send a multicast query for >a SOA type query for its own name (i.e. for the name it is authoritative >for). Why not just look for an A or PTR RR. If another mdns server respondes to the request, there's a conflict. Do mdns servers need to support SOA RR requests? The zeroconf requirements only state A and PTRs are required. >A host that has detected a name conflict MUST NOT use the name. SHOULD NOT >Note that this name conflict detection mechanism doesn't prevent name >conflicts when previously separate networks are connected by a bridge. >Name conflict in such situation is detected when a sender receives more >than one response to its multicasted DNS query. This is not catastrophic. This is like getting back multiple results. >8. Acknowledgements > >The authors would like to thank Stuart Cheshire, Michael Patton, Erik >Guttman, Olafur Gudmundsson, Thomas Narten, Mark Andrews, Erik Nordmark, >Myrong Hattig, Bill Manning and James Gilroy for comments on this draft. I believe that this section should read: This work builds upon original work done on multicast DNS by Bill Manning and Bill Woodcock. The authors gratefully acknowledge their contribution to the current specification. Constructive input has also been received from Mark Andrews, Stuart Cheshire, James Gilroy, Olafur Gudmundsson, Erik Guttman, Myron Hattig, Thomas Narten and Erik Nordmark. Erik to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Mar 29 04:17:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA28631 for ; Thu, 29 Mar 2001 04:17:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14iY5i-000ESL-00 for namedroppers-data@psg.com; Thu, 29 Mar 2001 00:47:38 -0800 Received: from [147.28.4.2] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14iY5e-000ES9-00 for namedroppers@ops.ietf.org; Thu, 29 Mar 2001 00:47:34 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14iY5c-0003na-00 for namedroppers@ops.ietf.org; Thu, 29 Mar 2001 03:47:32 -0500 Message-ID: From: sander.van-valkenburg@nokia.com To: namedroppers@psg.com Cc: erik.guttman@sun.com, dthaler@microsoft.com, bernarda@microsoft.com, levone@microsoft.com, cheshire@apple.com Subject: RE: comments on mnds-00 Date: Thu, 29 Mar 2001 10:56:49 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Is it possible and allowed for mDNS responders to send gratuitous responses? This would solve the following problem that could occur in a Zeroconf environment: Say one device accesses a web-server, and both (mobile) devices have configured a link-local IP address. In the middle of the session an address conflict is detected and the server has to change its IP address, e.g. the network joins another network, where a third device is using the same link-local IP address as the web-server. The mobile device accessing the web-server would not notice anything, except that it looks like the server is not responding anymore. A solution to this would be a unicast DNS response from the server (the mDNS responder) to the client, binding the name to the new link-local IP address. Nothing is stated about this in the draft, but it is also not explicitly prohibited. Does anyone have an opinion on this? Also one small comment on the draft: > A device configured to be a "responder" may also be a > "sender". A device > configured to not be a "responder" cannot be a "sender". > > Multicast DNS usage is determined by the domain search configuration as > well as by special treatment of the ".local.arpa." namespace. Any > device whose domain search configuration contains ".local.arpa." domain > is configured to behave as "responder". A device configured to be a > "responder" may also be a "sender". A device cannot be configured to > behave as one (i.e. sender or responder), but not another. The first statement says a responder MAY also be a sender, while the second statement says a responder CANNOT be configured to behave as a responder only, and not as a sender. There seems to be a conflict here. IMHO, a device should be able to be responder only, when it will never do any name resolution using mDNS itself, but responds to mDNS queries (as an example, again the local web server). Regards, Sander > -----Original Message----- > From: ext Erik Guttman [mailto:erikg@efra05-home.Germany.Sun.COM] > Sent: 28. March 2001 02:47 > To: namedroppers@psg.com > Cc: erik.guttman@sun.com; dthaler@microsoft.com; > bernarda@microsoft.com; > levone@microsoft.com; cheshire@apple.com > Subject: comments on mnds-00 > > > Levon, Bernard, > > The following comments concern draft-ietf-dnsext-mdns-00.txt > > >A sender sends multicast DNS query for any legal Type of > resource record > >(e.g. A, PTR, etc=E0) for a name within the ".local.arpa." > domain to the > ^ > word cruft > >LINKLOCAL address. > > If the name is in .local.arpa that indicates it MUST be multicast. > That is, there is no sense in unicasting this request elsewhere=20 > since it will have only local significance. > > The converse is not true: Why can't a host multicast a request for > a host name which is not qualified with '.local.arpa'? If this is=20 > not allowed, it severely limits the utility of mdns. FQDNs > are present > in many protocols, configuration files, documents... If these cannot > be resolved locally, what is the point of mdns? =20 > > I suggest that a mdns name server serve only those names which the > host has been configured with - suggesting the addition of a local > name (alias). This name can be used by protocols which advertise > local services, which are found via a link-local service discovery > protocol. =20 > > The advantage of using a local name instead of a string > representation=20 > of an IP address is that the local name will remain valid > even when the=20 > host renumbers (which it could do at any time when using IPv4 > link-local=20 > autoconfiguraion). This alone is not a compelling reason to use local > names. > > >In this example (unless this > >limitation introduced) the multicast query for an A record > for the name > >"child.host.example.com.local.arpa." would cause two authoritative > >responses: name error received from > "host.example.com.local.arpa.", and > >requested A record - from "child.host.example.com.local.arpa.". > > 1. Multicast DNS servers should not send error replies - these=20 > should be dropped. =20 > > Multicast discovery protocols which require all listeners to > respond with a unicast error reply cause broadcast storms. =20 > This is undesirable on a link-local network. If mdns were=20 > ever to be defined at a larger scope (say administrative=20 > scope) in the future, this would be completely unacceptable. =20 > The protocol has to return correct replies to correct=20 > requests, that's all. > > 2. Given that, I do not understand the ambiguity. A host not=20 > configured with a name would not respond to a request for it. =20 > > >The responder MUST set the Hop Limit > >field in IPv6 header and TTL field in IPv4 header of all responses to > >the multicast DNS query to 255. The sender MUST verify that the Hop > >Limit field in IPv6 header and TTL field in IPv4 header of > each response > >to the multicast DNS query is set to 255. If it is not, then > sender MUST > >ignore such response. > > Shouldn't IPv6 hop count / IPv4 TTL be 1 for link-local multicast dns? > If this is a 'clever trick' which will cause listeners to > drop messages > after they've traversed a single router (they will always be > less than=20 > 255 in this case), I claim this is not a good idea. A link-local=20 > protocol shouldn't be routed at all: We choose an address we > specify=20 > routers must not forward, and we send with hop count/ttl =3D > 1 to further= > =20 > reduce this possibility. > > >The responder includes in the additional and authority section of the > >response the same records, as a DNS server would insert in > the response > >to the unicast DNS query. > > Please reword: > > The responder SHOULD include an NS record for itself in the > authority=20 > section and an A record in the additional section of the response. =20 > This is behavior is consistent with existing DNS server > implementations. > > >Sender MUST anticipate receiving no replies to some > multicasted queries, > >in the event that no responders are available within the multicast > >scope, or in the event that no positive non-null responses > exist to the > >transmitted query. > > A responder must not send anything except a positive non-null > response. > That is, a null response or a negative response MUST NOT be sent. The > argument for this is given above. > > >If no positive response is received, a resolver treats it as > a response > >that no records of the specified type and class for the > specified name > >exist (NXRRSET), which SHOULD be cached for a period that SHOULD NOT > >exceed 5 seconds. > =20 > Why define this behavior? This is complicated and will make little > difference when a single mdns request is already takes a few > seconds=20 > to complete. > =20 > >Sender MUST anticipate receiving multiple replies to the same > >multicasted query, in the event that several multicast DNS enabled > >computers receive the query and respond with valid answers. > When this > >occurs, the responses MAY first be concatenated, and then > treated in the > >same manner that multiple RRs received from the same DNS > server would, > >ordinarily. > > With 'MAY' an existing resolver can simply use the mdns address and > accept the first result, where an enhanced resolver would do something > slicker. The problem here is you don't get back the same info as you > would from a DNS server. Collecting the duplicates and collating > them requires additional code, but perhaps it 'SHOULD' be done. > > >Any device whose domain search configuration contains > ".local.arpa."=20 > >domain is configured to behave as "responder". > > Why should this behavior be configured using the search path? > Why should the resolver search path IN ANY CASE determine the=20 > multicast dns server behavior? > > I suggest that, just as other zeroconf protocols, a host may either > run this zeroconf protocol service or not. This need not be something > that can be turned off by DHCP, nor should it be - any more than v4LL > autoconfiguration. > > >It is not expected that a device "host.example.com." will be manually > >configured to have additional name > "host.example.com.local.arpa." when > >it is configured to use multicast DNS. Instead, a responder > with a name > >"host.example.com." configured with ".local.arpa." suffix in > its domain > >search configuration is authoritative for the name > >"host.example.com.local.arpa.". I.e. when responder with the name > >"host.example.com." receives an A type query for the name > >"host.example.com.local.arpa." it authoritatively responds > to the query. > > Why attache the suffix '.local.arpa' stuff? Why not just multicast > a request for 'host.example.com'? > > I thought '.local.arpa' allowed a separate namespace for queries > which would not be in the DNS. If you append it, you effectively > alias names in the DNS to the local namespace - buying you nothing. > > A host may have a '.local.arpa' name, entirely self administered, > *in addition* to its normal (fully qualified) domain name. An=20 > mdns responder should respond to either. > > In any case, why should the resolver search path effect responder > behavior? > > >The same device may use multicast DNS queries for the name > resolution of > >the names ending with ".local.arpa.", and unicast DNS > queries for name > >resolution of all other names. > > Why can't a resolver multicast *any* request as a last resort. For=20 > example if no DNS server responds. This would be the effect of > putting if the link-local mdns address as the last nameserver entry=20 > in /etc/resolv.conf. I think this makes tremendous sense and provides > the primary benefit of using mdns: reliability. > > >It is required to verify the uniqueness of the host DNS name > when a host > >boots, when its name is changed, or when it is configured to use > >multicast DNS (such as when the domain search option is changed to > >include ".local.arpa."). > > Why is it required? I could desire to have multiple devices respond > to the same name for some conceivable application (the devices are > all redundent identical stateless doodads, for example.) =20 > > This may be desirable, but at most a SHOULD. > > >A gratuitous name resolution query SHOULD be done to check for a name > >conflict. This is done by having the resolver send a > multicast query for > >a SOA type query for its own name (i.e. for the name it is > authoritative > >for). > > Why not just look for an A or PTR RR. If another mdns server > respondes to= > =20 > the request, there's a conflict. Do mdns servers need to > support SOA RR > requests? The zeroconf requirements only state A and PTRs > are required. > > >A host that has detected a name conflict MUST NOT use the name. > > SHOULD NOT > > >Note that this name conflict detection mechanism doesn't prevent name > >conflicts when previously separate networks are connected by > a bridge. > >Name conflict in such situation is detected when a sender > receives more > >than one response to its multicasted DNS query. > > This is not catastrophic. This is like getting back multiple results. > > > >8. Acknowledgements > > > >The authors would like to thank Stuart Cheshire, Michael Patton, Erik > >Guttman, Olafur Gudmundsson, Thomas Narten, Mark Andrews, > Erik Nordmark, > >Myrong Hattig, Bill Manning and James Gilroy for comments on > this draft. > > I believe that this section should read: > > This work builds upon original work done on multicast DNS by > Bill Manning= > =20 > and Bill Woodcock. The authors gratefully acknowledge their > contribution > to the current specification. Constructive input has also > been received=20 > from Mark Andrews, Stuart Cheshire, James Gilroy, Olafur > Gudmundsson,=20 > Erik Guttman, Myron Hattig, Thomas Narten and Erik Nordmark. > > > Erik > =20 > > > > to unsubscribe send a message to > namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Mar 29 08:17:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13289 for ; Thu, 29 Mar 2001 08:17:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14ic1w-000L3H-00 for namedroppers-data@psg.com; Thu, 29 Mar 2001 05:00:00 -0800 Received: from [206.163.43.51] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14ic1t-000L3A-00 for namedroppers@ops.ietf.org; Thu, 29 Mar 2001 04:59:58 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14ic1s-0003pD-00 for namedroppers@ops.ietf.org; Thu, 29 Mar 2001 07:59:56 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200103290948.f2T9mn865737@open.nlnetlabs.nl> From: ted@tednet.nl (Ted Lindgreen) Date: Thu, 29 Mar 2001 11:48:49 +0200 In-Reply-To: "Edward Lewis's message as of Mar 28, 19:41" Reply-To: Ted.Lindgreen@tednet.nl To: Edward Lewis , Ted.Lindgreen@tednet.nl Subject: Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt) Cc: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Quoting Edward Lewis, on Mar 28, 19:41, in "Re: Signature at par ..."] > Some folks have A records at the zone apex (cnn.com comes to mind), which > leads me to believe that in the future some folks may have non-zone keys at > the apex. This implies that the parent will be signing a mix of zone and > non-zone keys for such a delegation. > > The idea of having the parent (.com) being authoritative for cnn.com's > IPSEC key seems somewhat "hard to sell." I see the point of having the SIG > be at .com, and therefore the KEYs be from .com, but when we look at the > non-zone keys, having the parent be authoritative is a hard sell. Hmm, interesting complication, haven't thought of that before! After spending a sleepless night on it (not really :-), I came to the following conclusions: 1. If (when?) zone administrators are putting local-keys (keys to be used locally for things like ipsec and whatever else) into the zone-key-set, both this administrator and his/her parents administrator will not be amused later on. 2. The problem is not really a "draft-ietf-dnsop-parent-sig-00"problem, but merely an RFC2535 problem: even if we ignore the formal authority, having local keys signed, and thus maintained, by outside organisations is a bad idea. 3. The only thing we plead guilty for, is highlighting the problem by throwing words as "authoritative" at it, and then you are guilty of noticing it :-) Of course, it's much better recognizing it now then to find out and be sorry later. So, we better find ways to discourage zone administrators to put local keys into the externally signed zone-key-set. The alternative is easy: put these under a label (keys.child.parent or ipsec.child.parent), so that this RRset is signed by their own zone-KEY instead of their parents. Next question is: how to discourage it. I see three possibilities, but I have no strong opinion about it yet: 1. Have it forbidden by the protocol. In that case, we must hope that implementations really enforce it, to prevent discussions like the current "CNAME at the apex" later. 2. Let the market take care of it, i.e. watch TLDs and/or external signing authoraties charge obseen amounts of money to sign and resign key-sets full of non-zone-keys. 3. Let's hope for the best and feel pity for zone administrators children and their parents that are stupid enough to fall into this trap afterall. Hmm, perhaps, 1 is the best afterall :-) > There is a few reasons to have the data in the parent. Cement trucks, > backhoes, and (for those in certain areas) shotguns are reasons. (;)) We > just had a cable cut severing us from the Internet, so we couldn't get to > the parent zone. The upshot of this is that I may want to have self-signed > keys configured locally to continue secure lookups. ('Course, who am I > protecting myself against - if the Internet "is down.") Yes, agree. We think the local secure aware forwarder/resolver could (should?) have the local zone-key preconfigured. By the way, this will be automatically the case when the local nameservers are used both for internally use as caching forwarder and externally as authorative server for the local zone, a configuration we often see in networks of medium and large organisations. For small organisations, not running there own nameserver, we need to think of something else, I'm affraid. Regards, -- Ted. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Mar 30 03:54:13 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA23718 for ; Fri, 30 Mar 2001 03:54:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14iuFU-000Ioz-00 for namedroppers-data@psg.com; Fri, 30 Mar 2001 00:27:12 -0800 Received: from roam.psg.com ([147.28.0.38] ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14iuFM-000IoL-00 for namedroppers@ops.ietf.org; Fri, 30 Mar 2001 00:27:04 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14itVX-0000qB-00 for namedroppers@ops.ietf.org; Thu, 29 Mar 2001 23:39:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 29 Mar 2001 15:06:39 -0800 (PST) From: Brian Wellington To: Edward Lewis cc: , Subject: Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt) In-Reply-To: Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 28 Mar 2001, Edward Lewis wrote: > There is a few reasons to have the data in the parent. Cement trucks, > backhoes, and (for those in certain areas) shotguns are reasons. (;)) We > just had a cable cut severing us from the Internet, so we couldn't get to > the parent zone. The upshot of this is that I may want to have self-signed > keys configured locally to continue secure lookups. ('Course, who am I > protecting myself against - if the Internet "is down.") With this logic, why not just store everything at the parent? In DNS, key records are really no different than any other records. A child should be authoritative for and hold its own key record, just like it holds everything else. The argument about about whether to store KEYs and SIG KEYs in the child or the parent was pretty well hashed out 3 years ago or so. There were many reasons to go either way, but a decision was made, and there exists at least one implementation. Changing this now would be a bad idea. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Mar 30 03:54:14 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA23719 for ; Fri, 30 Mar 2001 03:54:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14iuFP-000Ioq-00 for namedroppers-data@psg.com; Fri, 30 Mar 2001 00:27:07 -0800 Received: from roam.psg.com ([147.28.0.38] ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14iuFM-000IoQ-00 for namedroppers@ops.ietf.org; Fri, 30 Mar 2001 00:27:04 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14itJr-0000oo-00 for namedroppers@ops.ietf.org; Thu, 29 Mar 2001 23:27:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: RE: comments on mnds-00 Date: Thu, 29 Mar 2001 13:18:23 -0800 Message-ID: <605B31B648AE63449410E3C37BD6AFD4F294C5@DF-MAX.platinum.corp.microsoft.com> From: "Bernard Aboba" To: "Erik Nordmark" , "Erik Guttman" Cc: , , "Dave Thaler" , "Levon Esibov" , , Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit To provide some perspective on this, recently I noticed multiple attempted breakins to a system coming from the 169.254/16 prefix. I then did a traceroute, and discovered that routers up to 4 hops away were forwarding packets destined to this prefix. When the packets reached the core routers running BGP, a host unreachable message was returned.=20 The implication is that an attacker using this (bogus) source address could reach hosts up to 4 hops away, and possibly more if the path did not traverse a backbone router. Declaring=20 169.254/16 a linklocal prefix is unlikely to have much effect in the short term; after all, IANA has listed this as a linklocal prefix for more than a year now, apparently with minimal effect. It is likely that it will take several years for the necessary router upgrades to be widely deployed.=20 Given this reality, we feel that it is necessary for hosts to incorporate their own protection mechanisms, rather than relying on routers to do the right thing. Requiring TTL=3D255 provides a mechanism for hosts to protect themselves against off-segment attackers, since routers that do not recognize 169.254/16 as a linklocal prefix will still decrement TTL.=20 This issue exists not only for mDNS but also for all use of IPv4 linklocal addresses.=20 -----Original Message----- From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com] Sent: Wednesday, March 28, 2001 8:58 AM To: Erik Guttman Cc: namedroppers@psg.com; erik.guttman@sun.com; Dave Thaler; Bernard Aboba; Levon Esibov; cheshire@apple.com Subject: Re: comments on mnds-00 > Shouldn't IPv6 hop count / IPv4 TTL be 1 for link-local multicast dns? > If this is a 'clever trick' which will cause listeners to drop messages > after they've traversed a single router (they will always be less than=3D20 > 255 in this case), I claim this is not a good idea. A link-local=3D20 > protocol shouldn't be routed at all: We choose an address we specify=3D20 > routers must not forward, and we send with hop count/ttl =3D3D 1 to further=3D > =3D20 > reduce this possibility. You seem to be touching on two issues: 1. should be able to span more than one link 2. even on one link the ttl 255 trick is undesired or broken. Did I get that right? The issue the 255 trick is addressing is attacks from far away by injecting bogus unicast responses. Using ttl=3D1 doesn't address that. Requiring that both source and destination be link local unicast/multicast would accomplish close to the same thing as the ttl 255 trick, but RFC 2461 uses non-link local addresses in some cases which is why it mandates ttl 255. Erik to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Mar 30 03:54:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA23720 for ; Fri, 30 Mar 2001 03:54:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14iuFQ-000Ios-00 for namedroppers-data@psg.com; Fri, 30 Mar 2001 00:27:08 -0800 Received: from roam.psg.com ([147.28.0.38] ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14iuFM-000IoW-00 for namedroppers@ops.ietf.org; Fri, 30 Mar 2001 00:27:04 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14itV0-0000q7-00 for namedroppers@ops.ietf.org; Thu, 29 Mar 2001 23:39:10 -0800 Date: Thu, 29 Mar 2001 15:03:07 -0800 (PST) From: Brian Wellington X-Sender: To: cc: Edward Lewis , Subject: Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt) In-Reply-To: <200103290948.f2T9mn865737@open.nlnetlabs.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 29 Mar 2001, Ted Lindgreen wrote: > [Quoting Edward Lewis, on Mar 28, 19:41, in "Re: Signature at par ..."] > > > Some folks have A records at the zone apex (cnn.com comes to mind), which > > leads me to believe that in the future some folks may have non-zone keys at > > the apex. This implies that the parent will be signing a mix of zone and > > non-zone keys for such a delegation. > > > > The idea of having the parent (.com) being authoritative for cnn.com's > > IPSEC key seems somewhat "hard to sell." I see the point of having the SIG > > be at .com, and therefore the KEYs be from .com, but when we look at the > > non-zone keys, having the parent be authoritative is a hard sell. > > Hmm, interesting complication, haven't thought of that before! > > After spending a sleepless night on it (not really :-), I came to > the following conclusions: > > 1. If (when?) zone administrators are putting local-keys (keys to > be used locally for things like ipsec and whatever else) into > the zone-key-set, both this administrator and his/her parents > administrator will not be amused later on. > 2. The problem is not really a "draft-ietf-dnsop-parent-sig-00"problem, > but merely an RFC2535 problem: even if we ignore the formal authority, > having local keys signed, and thus maintained, by outside > organisations is a bad idea. > 3. The only thing we plead guilty for, is highlighting the > problem by throwing words as "authoritative" at it, and then > you are guilty of noticing it :-) > Of course, it's much better recognizing it now > then to find out and be sorry later. > > So, we better find ways to discourage zone administrators to put > local keys into the externally signed zone-key-set. > > The alternative is easy: put these under a label (keys.child.parent > or ipsec.child.parent), so that this RRset is signed by their own > zone-KEY instead of their parents. > > Next question is: how to discourage it. I see three possibilities, but > I have no strong opinion about it yet: > > 1. Have it forbidden by the protocol. In that case, we must hope > that implementations really enforce it, to prevent discussions > like the current "CNAME at the apex" later. That seems like overkill. > 2. Let the market take care of it, i.e. watch TLDs and/or external > signing authoraties charge obseen amounts of money to sign and > resign key-sets full of non-zone-keys. Again, overkill. Having larger keysets doesn't really hurt anything. > 3. Let's hope for the best and feel pity for zone administrators > children and their parents that are stupid enough to fall into > this trap afterall. That wouldn't be very productive. > Hmm, perhaps, 1 is the best afterall :-) A simple SHOULD in the spec would work. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Mar 30 03:54:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA23775 for ; Fri, 30 Mar 2001 03:54:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14iuFP-000Ior-00 for namedroppers-data@psg.com; Fri, 30 Mar 2001 00:27:07 -0800 Received: from roam.psg.com ([147.28.0.38] ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14iuFN-000Ioa-00 for namedroppers@ops.ietf.org; Fri, 30 Mar 2001 00:27:05 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14itXM-0000qR-00 for namedroppers@ops.ietf.org; Thu, 29 Mar 2001 23:41:36 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200103300009.CAA02738@efra05-home.Germany.Sun.COM> Date: Thu, 29 Mar 2001 16:09:30 -0800 (PST) From: Erik Guttman Reply-To: Erik Guttman Subject: RE: comments on mnds-00 To: bernarda@Exchange.Microsoft.com, dthaler@Exchange.Microsoft.com, levone@Exchange.Microsoft.com Cc: cheshire@apple.com, namedroppers@psg.com, erik.guttman@sun.com, Erik.Nordmark@eng.sun.com, narten@raleigh.ibm.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Bernard, >Given this reality, we feel that it is necessary for hosts to >incorporate their own protection mechanisms, rather than relying on >routers to do the right thing. Requiring TTL=255 provides a mechanism >for hosts to protect themselves against off-segment attackers, since >routers that do not recognize 169.254/16 as a linklocal prefix will >still decrement TTL. > >This issue exists not only for mDNS but also for all use of IPv4 >linklocal addresses. I am sensitive to your issue, but your proposed solution will not work. Neither the sockets API nor XTI allows the receiver to determine the TTL of a received datagram. This is not an issue for IPv6 neighbor discovery but it would be for any user-level application (like mdns). The only way to implement this on most platforms would be to write mdns over raw IP sockets (yuck). Erik ._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._. E r i k G u t t m a n Email: erik.guttman@sun.com Sr Staff Engineer, Sun Microsystems Cell # 415 420 4425 to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Mar 30 11:27:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23922 for ; Fri, 30 Mar 2001 11:27:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14j1H2-0003Le-00 for namedroppers-data@psg.com; Fri, 30 Mar 2001 07:57:16 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14j1H2-0003LY-00 for namedroppers@ops.ietf.org; Fri, 30 Mar 2001 07:57:16 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14j1H1-000JEH-00 for namedroppers@ops.ietf.org; Fri, 30 Mar 2001 07:57:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200103300927.LAA20380@omval.tednet.nl> From: ted@tednet.nl (Ted Lindgreen) Date: Fri, 30 Mar 2001 11:27:26 +0200 In-Reply-To: "Brian Wellington's message as of Mar 30, 0:03" To: Brian Wellington Subject: Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt) Cc: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Quoting Brian Wellington, on Mar 30, 0:03, in "Re: Signature at par ..."] > A simple SHOULD in the spec would work. OK, we will add that to the next version of draft-ietf-dnsop-parent-sig-00.txt. Thanks, -- Ted. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Mar 30 11:28:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24025 for ; Fri, 30 Mar 2001 11:28:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14j1UN-0003hV-00 for namedroppers-data@psg.com; Fri, 30 Mar 2001 08:11:03 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14j1UN-0003hP-00 for namedroppers@ops.ietf.org; Fri, 30 Mar 2001 08:11:03 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14j1UN-000Jb7-00 for namedroppers@ops.ietf.org; Fri, 30 Mar 2001 08:11:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200103301002.MAA07885@kantoor.ripe.net> To: namedroppers@ops.ietf.org Subject: QST: opt-in draft and resolver behaviour Date: Fri, 30 Mar 2001 12:02:35 +0200 From: Olaf Kolkman Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ref: draft-kosters-dnsext-opt-in-01.txt Hi Mark, I've been reading your draft a few times and I think I got the gist of it. Still a few questions come to mind, they are mostly focused around authenticated denial of zones. Let's first focus on a world in transition to resolvers being RETRY-NO-SEC-AWARE compliant; In the 2nd example one queries for 5 RR type A with the DO bit set only. It is clear that you follow the 2nd of the two lines of possible server responses and the server searches the non-secure view. The answer is: RCODE=NOERROR Answer Section: 5 NS Authority Section: 3 NXT (6), SIG NXT Aditional Section KEY, SIG KEY I can't really find in the RFCs what a security aware resolver should do with the answer, but based on the data in the authority section I'd say that the resolver should interpret the answer as '5 RR NS does not exist', but then again the server is authoritative (?) for this answer... In the case a resolvers is RETRY-NO-SEC-AWARE compliant it will go back and try the non-secure tree. But that opens the possibility for a a spoof and there is no way I can authenticate denial of a domain. My interpretation is that in the context of your draft NXT indicates which children are secured and not which labels exist. In other words authenicated denial will be broken. --Olaf ----------------------------------------------------- Olaf M. Kolkman | RIPE NCC ----------- | --------------- RIPE NCC | Phone: +31 20 535 4444 Singel 258 | Fax: +31 20 535 4445 1016 AB Amsterdam | http://www.ripe.net The Netherlands | OKolkman@ripe.net to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Mar 30 11:30:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24174 for ; Fri, 30 Mar 2001 11:30:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14j1V3-0003jq-00 for namedroppers-data@psg.com; Fri, 30 Mar 2001 08:11:45 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14j1V2-0003jj-00 for namedroppers@ops.ietf.org; Fri, 30 Mar 2001 08:11:44 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14j1V2-000JcL-00 for namedroppers@ops.ietf.org; Fri, 30 Mar 2001 08:11:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200103301035.MAA20499@omval.tednet.nl> From: ted@tednet.nl (Ted Lindgreen) Date: Fri, 30 Mar 2001 12:35:04 +0200 In-Reply-To: "Brian Wellington's message as of Mar 30, 0:06" To: Brian Wellington Subject: Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt) Cc: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Quoting Brian Wellington, on Mar 30, 0:06, in "Re: Signature at par ..."] > The argument about about whether to store KEYs and SIG KEYs in the child > or the parent was pretty well hashed out 3 years ago or so. There were I have read this statement before and tried to find out what consensus had been achieved. However, I have not been able to find it. On the other side, IF consensus had been achieved in 1998, I would expect that to be reflected in RFC 2535, which was finalized in 1999. RFC 2535 is only specific when it comes to storing a (null)KEY for a clue-less child (MUST be stored at the parent), for all other cases, RFC 2535 uses frases like "normally" and "may" when it comes to where zone KEYs and parental SIGs are stored. So, if the definite answer is at hand, please tell what it is, and please give me pointers where I can find more info on it. > many reasons to go either way, but a decision was made, and there exists > at least one implementation. Changing this now would be a bad idea. I am not sure what you mean by this, and certainly not why adopting one or another scheme would conflict with existing implementations. If you refer to named implementations: As far as I know there are 2 and a half (see NOTE below) implementations for nameserver software, that deal with DNSSEC. From our experiments we found, that all of them work with the parental SIG over the childs KEY @parent, @child, and @both. So, I see no conflicts here to go either way. But, perhaps you refer to registry testbeds? I know of two implementations: one at CAIRN and one over here at NLnet Labs. The former uses the KEY+parentalSIG @child scheme. From private communication during the last IETF (50th) with the authors/zoneadministrators I know that most, of not all, of their test child zones are currently BAD. They told me that they consider their setup as very difficult, if not impossible, to maintain, and that they are considering to adopt the parental-SIG@parent scheme. The other testbed implementation (the .nl.nl zone at NLnet Labs) uses the parental-SIG@parent scheme with some reasonable success. So, in conclusion: 1. The decision you refer to is, at least for some of us, unclear. 2. Clearing up this issue, whatever the decision is, seems to me to be a good idea. Regards, -- Ted. NOTE. The 2 working named implementations I know are: 1. bind-8.2.2p5 2. bind-9.1.x The half implementation is bind-8.2.3. I refer to this as 1/2, because DNSSEC in this version has effectively been disabled (intentionally?) by inverting an if statement in the code, invalidating positive (==valid) original TTL values. By re-inverting this test, like it was in bind-8.2.2p5, DNSSEC appears to be fully functional again, and in fact is used on one of our testsystems, as we like to gain experience with as much as systems and implementations as we can lay our hands on.. For the interested, this is the patch to re-enable DNSSEC in bind-8.2.3: =================================================================== RCS file: /home/ted/src/SunOS/bind-8.2.3/src/bin/named/db_load.c,v retrieving revision 1.1 diff -u -r1.1 /home/ted/src/SunOS/bind-8.2.3/src/bin/named/db_load.c --- 1.1 2001/02/07 17:59:36 +++ /home/ted/src/SunOS/bind-8.2.3/src/bin/named/db_load.c 2001/02/07 18:08:11 @@ -2178,7 +2178,7 @@ } else { /* Parse and output OTTL; scan TEXP */ origTTL = wordtouint32(buf); - if (origTTL >= 0 || wordtouint32_error || + if (origTTL <= 0 || wordtouint32_error || (origTTL > 0x7fffffff)) ERRTO("Original TTL value bad"); cp = &data[i]; ================================================================== to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Mar 30 11:45:11 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25060 for ; Fri, 30 Mar 2001 11:45:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14j1ja-0004CI-00 for namedroppers-data@psg.com; Fri, 30 Mar 2001 08:26:46 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14j1jZ-0004CC-00 for namedroppers@ops.ietf.org; Fri, 30 Mar 2001 08:26:45 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14j1jZ-000K0y-00 for namedroppers@ops.ietf.org; Fri, 30 Mar 2001 08:26:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Bill Manning Message-Id: <200103301226.f2UCQmP06702@zed.isi.edu> Subject: Re: comments on mnds-00 To: bernarda@Exchange.Microsoft.com (Bernard Aboba) Date: Fri, 30 Mar 2001 04:26:48 -0800 (PST) Cc: Erik.Nordmark@eng.sun.com (Erik Nordmark), erikg@efra05-home.germany.sun.com (Erik Guttman), namedroppers@psg.com, erik.guttman@sun.com, dthaler@Exchange.Microsoft.com (Dave Thaler), levone@Exchange.Microsoft.com (Levon Esibov), cheshire@apple.com, aboba@internaut.com In-Reply-To: <605B31B648AE63449410E3C37BD6AFD4F294C5@DF-MAX.platinum.corp.microsoft.com> from "Bernard Aboba" at Mar 29, 2001 01:18:23 PM Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % To provide some perspective on this, recently I noticed multiple % attempted breakins to a system coming from the 169.254/16 prefix. I then % did a traceroute, and discovered that routers up to 4 hops away were % forwarding packets destined to this prefix. When the packets reached the % core routers running BGP, a host unreachable message was returned.=20 From the current DSUA draft, draft-manning-dsua-06.txt: 169.254.0.0/16 has been ear-marked as the IP range to use for end node auto-configuration when a DHCP server may not be found. As such, network operations and administrators should be VERY aggressive in ensuring that neither route advertisements nor packet forwarding should occur across any media boundaries. This is true for the Internet as well as any private networks that use the IP protocols. End node administrators should be aware that some vendors will auto-configure and add this prefix to the nodes forwarding table. This will cause problems with sites that run router discovery or deprecated routing protocols such as RIP. -- --bill to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Mar 30 13:24:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02213 for ; Fri, 30 Mar 2001 13:24:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14j3Al-0006jh-00 for namedroppers-data@psg.com; Fri, 30 Mar 2001 09:58:55 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14j3Al-0006jb-00 for namedroppers@ops.ietf.org; Fri, 30 Mar 2001 09:58:55 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14j3Al-000MY3-00 for namedroppers@ops.ietf.org; Fri, 30 Mar 2001 09:58:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Bill Manning Cc: bernarda@Exchange.Microsoft.com (Bernard Aboba), Erik.Nordmark@eng.sun.com (Erik Nordmark), erikg@efra05-home.germany.sun.com (Erik Guttman), namedroppers@psg.com, erik.guttman@sun.com, dthaler@Exchange.Microsoft.com (Dave Thaler), levone@Exchange.Microsoft.com (Levon Esibov), cheshire@apple.com, aboba@internaut.com Subject: Re: comments on mnds-00 References: <605B31B648AE63449410E3C37BD6AFD4F294C5@DF-MAX.platinum.corp.microsoft.com> <200103301226.f2UCQmP06702@zed.isi.edu> Message-Id: Date: Fri, 30 Mar 2001 09:48:41 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > 169.254.0.0/16 has been ear-marked as the IP range to use for end node > auto-configuration when a DHCP server may not be found. could we have a document reference for this? randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Mar 30 13:53:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04636 for ; Fri, 30 Mar 2001 13:53:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14j3OP-000796-00 for namedroppers-data@psg.com; Fri, 30 Mar 2001 10:13:01 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14j3OO-000790-00 for namedroppers@ops.ietf.org; Fri, 30 Mar 2001 10:13:00 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14j3OO-000Mvr-00 for namedroppers@ops.ietf.org; Fri, 30 Mar 2001 10:13:00 -0800 From: Bill Manning Message-Id: <200103301758.f2UHwfu07191@zed.isi.edu> Subject: Re: comments on mnds-00 To: randy@psg.com (Randy Bush) Date: Fri, 30 Mar 2001 09:58:41 -0800 (PST) Cc: bmanning@ISI.EDU (Bill Manning), bernarda@Exchange.Microsoft.com (Bernard Aboba), Erik.Nordmark@eng.sun.com (Erik Nordmark), erikg@efra05-home.germany.sun.com (Erik Guttman), namedroppers@psg.com, erik.guttman@sun.com, dthaler@Exchange.Microsoft.com (Dave Thaler), levone@Exchange.Microsoft.com (Levon Esibov), cheshire@apple.com, aboba@internaut.com In-Reply-To: from "Randy Bush" at Mar 30, 2001 09:48:41 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % % > 169.254.0.0/16 has been ear-marked as the IP range to use for end node % > auto-configuration when a DHCP server may not be found. % % could we have a document reference for this? % % randy % Sure. 62% whois 169.254.0.0@whois.arin.net [whois.arin.net] Internet Assigned Numbers Authority (IANA) (NETBLK-LINKLOCAL) For use with Link Local Networks Information Sciences Institute University of Southern California 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292-6695 US Netname: LINKLOCAL Netblock: 169.254.0.0 - 169.254.255.255 Coordinator: Internet Corporation for Assigned Names and Numbers (IANA-ARIN) iana@IANA.ORG (310) 823-9358 .... Based on the now expired draft: draft-ietf-dhc-ipv4-autoconfig-04.txt, October 1998 See: RFC 2563 for documentation on how to disable this feature. (Note to self. Its odd that the prefix for Autoconfig & associated documentation never made RFC status but how to disable it did...) ... -- --bill to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Mar 30 14:25:09 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07374 for ; Fri, 30 Mar 2001 14:25:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14j4Hg-0008qv-00 for namedroppers-data@psg.com; Fri, 30 Mar 2001 11:10:08 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14j4Hg-0008qp-00 for namedroppers@ops.ietf.org; Fri, 30 Mar 2001 11:10:08 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14j4Hg-000OSp-00 for namedroppers@ops.ietf.org; Fri, 30 Mar 2001 11:10:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200103301841.UAA16651@efra05-home.Germany.Sun.COM> Date: Fri, 30 Mar 2001 10:41:49 -0800 (PST) From: Erik Guttman Reply-To: Erik Guttman Subject: Re: comments on mnds-00 To: bmanning@ISI.EDU Cc: namedroppers@psg.com, erik.guttman@sun.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit From: Bill Manning >% could we have a document reference for this? draft-ietf-zeroconf-ipv4-linklocal-02.txt is in working group last call. It will be a proposed standard Real Soon Now. > draft-ietf-dhc-ipv4-autoconfig-04.txt, October 1998 This draft has expired and is not being pursued. The right draft to look at is the official, chartered, zeroconf draft. > See: RFC 2563 for documentation on how to disable this feature. This draft has not been implemented by any vendors I know of. There is even interest in reclassifying this RFC as historic as we are no longer supporting the idea of transitioning from link local to dhcp configuration. Rather link local should be used exclusively or in addition to other configuration. Erik ._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._. E r i k G u t t m a n Email: erik.guttman@sun.com Sr Staff Engineer, Sun Microsystems Cell # 415 420 4425 to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Mar 30 14:25:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07400 for ; Fri, 30 Mar 2001 14:25:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14j4IM-0008td-00 for namedroppers-data@psg.com; Fri, 30 Mar 2001 11:10:50 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14j4IM-0008tX-00 for namedroppers@ops.ietf.org; Fri, 30 Mar 2001 11:10:50 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14j4IM-000OU2-00 for namedroppers@ops.ietf.org; Fri, 30 Mar 2001 11:10:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: References: Date: Fri, 30 Mar 2001 13:52:11 -0500 To: Brian Wellington From: Edward Lewis Subject: Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt) Cc: Edward Lewis , , Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 6:06 PM -0500 3/29/01, Brian Wellington wrote: >On Wed, 28 Mar 2001, Edward Lewis wrote: > >> There is a few reasons to have the data in the parent. Cement trucks, >> backhoes, and (for those in certain areas) shotguns are reasons. (;)) We >> just had a cable cut severing us from the Internet, so we couldn't get to >> the parent zone. The upshot of this is that I may want to have self-signed >> keys configured locally to continue secure lookups. ('Course, who am I >> protecting myself against - if the Internet "is down.") > >With this logic, why not just store everything at the parent? In DNS, key >records are really no different than any other records. A child should >be authoritative for and hold its own key record, just like it holds >everything else. I don't follow this answer. I was trying to support holding data at the child (because the parent may be unavailable), meaning the child would be authoritative. Why did you think this implies that everything should be stored at the parent? >The argument about about whether to store KEYs and SIG KEYs in the child >or the parent was pretty well hashed out 3 years ago or so. There were >many reasons to go either way, but a decision was made, and there exists >at least one implementation. Changing this now would be a bad idea. This doesn't mean it can't be discussed again. If the decision 3 years ago was "arbitrary" - meaning it was close and we just chose and implemented one - then it holds no more bearing than a decision made with more operational and implementation experience. I do recall the dicsussion that lead to the recommendation to leave keys out of the parent. But this was a discussion that did not include TLD operators. We were concerned more about the liability of the parent than in the workload encured in managing delegations. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Mar 30 16:51:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16447 for ; Fri, 30 Mar 2001 16:51:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14j6T4-000D2u-00 for namedroppers-data@psg.com; Fri, 30 Mar 2001 13:30:02 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14j6T4-000D2o-00 for namedroppers@ops.ietf.org; Fri, 30 Mar 2001 13:30:02 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14j6T4-000HrB-00 for namedroppers@ops.ietf.org; Fri, 30 Mar 2001 13:30:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 30 Mar 2001 12:28:16 -0800 (PST) From: Brian Wellington To: Edward Lewis cc: , Subject: Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt) In-Reply-To: Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 30 Mar 2001, Edward Lewis wrote: > At 6:06 PM -0500 3/29/01, Brian Wellington wrote: > >On Wed, 28 Mar 2001, Edward Lewis wrote: > > > >> There is a few reasons to have the data in the parent. Cement trucks, > >> backhoes, and (for those in certain areas) shotguns are reasons. (;)) We > >> just had a cable cut severing us from the Internet, so we couldn't get to > >> the parent zone. The upshot of this is that I may want to have self-signed > >> keys configured locally to continue secure lookups. ('Course, who am I > >> protecting myself against - if the Internet "is down.") > > > >With this logic, why not just store everything at the parent? In DNS, key > >records are really no different than any other records. A child should > >be authoritative for and hold its own key record, just like it holds > >everything else. > > I don't follow this answer. I was trying to support holding data at the > child (because the parent may be unavailable), meaning the child would be > authoritative. Why did you think this implies that everything should be > stored at the parent? Because that's what you said. "There is [sic] a few reasons to have the data in the parent.", followed by said reasons. > >The argument about about whether to store KEYs and SIG KEYs in the child > >or the parent was pretty well hashed out 3 years ago or so. There were > >many reasons to go either way, but a decision was made, and there exists > >at least one implementation. Changing this now would be a bad idea. > > This doesn't mean it can't be discussed again. If the decision 3 years ago > was "arbitrary" - meaning it was close and we just chose and implemented > one - then it holds no more bearing than a decision made with more > operational and implementation experience. True. But I'm not convinced that operation experience has shown that the decision was wrong. The argument now is that it's somehow easier to store keys in the parent. This is not true. In both cases, the key must be sent from the child to the parent. In both cases, something must be sent from the parent back to the child, whether this something may either be a signed keyset or a confirmation doesn't change the fact that it's still a message. > I do recall the dicsussion that lead to the recommendation to leave keys > out of the parent. But this was a discussion that did not include TLD > operators. We were concerned more about the liability of the parent than > in the workload encured in managing delegations. I believe we were also concerned about the size of the parent zone if it stored the KEY sets and their SIGs for each child. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body.