From owner-namedroppers@ops.ietf.org Sat Feb 1 06:12:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04246 for ; Sat, 1 Feb 2003 06:12:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18evNU-000GGi-00 for namedroppers-data@psg.com; Sat, 01 Feb 2003 03:00:04 -0800 Received: from randy by psg.com with local (Exim 3.36 #1) id 18evNR-000GGG-00 for namedroppers@ops.ietf.org; Sat, 01 Feb 2003 03:00:01 -0800 To: namedroppers@ops.ietf.org Subject: list policy Message-Id: From: Randy Bush Date: Sat, 01 Feb 2003 03:00:01 -0800 X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_02_03,SUBJECT_IS_LIST version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk 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. 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. posts are only accepted from subscribers. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to namedroppers-owner@ops.ietf.org and ask to have your alternate address added to the list of addresses from which submissions are automatically accepted. 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. questions or concerns related to the acceptance or rejection of specific messages to the namedroppers mailing list should first be discussed with the wg chairs, with followup appeals using the normal appeals process of rfc 2026 (i.e., follup with area directors, then iesg, etc.). there is a mailing list for the discussion of ietf processes, which includes any general discussion of the moderation of ietf mailing lists. it is poised@lists.tislabs.com --- NOTE WELL: All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Feb 1 15:43:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15716 for ; Sat, 1 Feb 2003 15:43:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18f4BM-0004Vq-00 for namedroppers-data@psg.com; Sat, 01 Feb 2003 12:24:08 -0800 Received: from ip239.gte12.rb1.bel.nwlink.com ([207.202.147.239] helo=Gatekeeper.dunlap.org) by psg.com with esmtp (Exim 3.36 #1) id 18f4BI-0004VY-00 for namedroppers@ops.ietf.org; Sat, 01 Feb 2003 12:24:04 -0800 Received: from Gatekeeper.dunlap.org (localhost [127.0.0.1]) by Gatekeeper.dunlap.org (8.11.6/8.11.6) with ESMTP id h11KQUc08129; Sat, 1 Feb 2003 12:26:31 -0800 (PST) (envelope-from kevin@Gatekeeper.dunlap.org) Message-Id: <200302012026.h11KQUc08129@Gatekeeper.dunlap.org> To: namedroppers@ops.ietf.org cc: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: Re: Q: Conflict between TSIG RFC and GSS-API documents In-reply-to: Your message of "Fri, 31 Jan 2003 14:36:24 EST." <5.1.1.6.2.20030131124656.0191dd50@localhost> Date: Sat, 01 Feb 2003 12:26:30 -0800 From: "Kevin J. Dunlap" X-Spam-Status: No, hits=-0.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03, TO_BE_REMOVED_REPLY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk As the implementor that found the problem that placed the lock on the GSS-API document, I belive that the lock should be removed once the TSIG RFC has the appropriate modifications made to allow the GSS-TSIG draft to advance. I don't think we should advance a Draft that is not in compliance with the RFC it is ment to enhance. -Kevin Your message dated: Fri, 31 Jan 2003 14:36:24 EST > From the minutes in ATLANTA: > > >>GSSAPI and TSIG conflict: >> DNSEXT wg generated TSIG RFC >> DNSEXT wg processed gssapi TSIG >> just before rfc editor started 48hour period we got a report >> that there was a conflict between two the documents. >> TSIG specifies that TSIG can only be used if original query >> contains TSIG >> GSSAPI specifies that last message in TKEY exchange has TSIG >> last message is empty, and this proves the key negotiated is >> working from security point of view this is a good thing >> >> TSIG needs minor updates before advancing to draft standard: >> is this extensions one of them? >> >>The sense of the room was that this was a reasonable extensions and the >>chair is instructed to take this question to the mailing list. > >Does the mailing list agree with this assessment and give >its consensus that the lock on the GSS-API document be lifted ? > >Silence will be taken as agreement. > >Please post objections before Feb 12'th. > >thanks > 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. >archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Feb 1 17:09:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16659 for ; Sat, 1 Feb 2003 17:09:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18f5eG-000899-00 for namedroppers-data@psg.com; Sat, 01 Feb 2003 13:58:04 -0800 Received: from [2001:4f8:3:bb:2e0:81ff:fe23:7b5a] (helo=as.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 18f5eE-00088u-00 for namedroppers@ops.ietf.org; Sat, 01 Feb 2003 13:58:02 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 597DE379EF3 for ; Sat, 1 Feb 2003 21:57:47 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Q: Conflict between TSIG RFC and GSS-API documents In-Reply-To: Message from "Kevin J. Dunlap" of "Sat, 01 Feb 2003 12:26:30 PST." <200302012026.h11KQUc08129@Gatekeeper.dunlap.org> X-Mailer: MH-E 7.1; nmh 1.0.4; Emacs 21.2 Date: Sat, 01 Feb 2003 21:57:47 +0000 Message-Id: <20030201215747.597DE379EF3@as.vix.com> X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > As the implementor that found the problem that placed the lock > on the GSS-API document, I belive that the lock should be removed > once the TSIG RFC has the appropriate modifications made to allow > the GSS-TSIG draft to advance. I don't think we should advance a > Draft that is not in compliance with the RFC it is ment to enhance. procedurally, there's also the option of adding an "Amends:" header to the gss-tsig rfc, and putting in a paragraph that says "for the purpose of gss-tsig, the following restriction in the original tsig rfc is relaxed." that seems like the easiest, fastest solution. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 3 13:47:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17052 for ; Mon, 3 Feb 2003 13:47:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18flQV-000I6M-00 for namedroppers-data@psg.com; Mon, 03 Feb 2003 10:34:39 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 18flQS-000I69-00 for namedroppers@ops.ietf.org; Mon, 03 Feb 2003 10:34:36 -0800 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 36A96137F03; Mon, 3 Feb 2003 10:34:35 -0800 (PST) Date: Mon, 3 Feb 2003 10:34:34 -0800 Subject: Re: DNSEXT WGLC: DNSSEC Opt-in Content-Type: text/plain; delsp=yes; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: namedroppers@ops.ietf.org To: =?ISO-8859-1?Q?=D3lafur_Gudmundsson/DNSEXT_co-chair?= From: David Conrad In-Reply-To: <5.1.1.6.2.20021114114119.0167f7e8@localhost> Message-Id: <244B987E-37A6-11D7-B86C-000393DB42B2@nominum.com> X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,TO_BE_REMOVED_REPLY,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA17052 Hi, So, isn't it time to pass/kill this one? Rgds, -drc On Thursday, November 14, 2002, at 08:56 AM, Ólafur Gudmundsson/DNSEXT co-chair wrote: > > This is the beginning of a 3 week working group last call. > This last call ends on December 6'th. > > This document updates RFC2535 to allow NXT chain to omit insecure > delegations. This document covers the implications this has on > servers and resolvers. > > This document is on standards track and is available via following URL: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-opt-in- > 04.txt > > 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. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 3 16:18:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22147 for ; Mon, 3 Feb 2003 16:18:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18fntt-000Ovu-00 for namedroppers-data@psg.com; Mon, 03 Feb 2003 13:13:09 -0800 Received: from [2001:4f8:3:bb:2e0:81ff:fe23:7b5a] (helo=as.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 18fntr-000OvU-00 for namedroppers@ops.ietf.org; Mon, 03 Feb 2003 13:13:07 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id ECFF9379EF3 for ; Mon, 3 Feb 2003 21:12:53 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: DNSSEC Opt-in In-Reply-To: Message from David Conrad of "Mon, 03 Feb 2003 10:34:34 PST." <244B987E-37A6-11D7-B86C-000393DB42B2@nominum.com> X-Mailer: MH-E 7.1; nmh 1.0.4; Emacs 21.2 Date: Mon, 03 Feb 2003 21:12:53 +0000 Message-Id: <20030203211253.ECFF9379EF3@as.vix.com> X-Spam-Status: No, hits=0.7 required=5.0 tests=IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > So, isn't it time to pass/kill this one? dunno. but in any case i am strongly in favour of it, both because it softens the privacy-related impact of early dnssec deployment (walking a short nxt chain exposes less information than walking a full nxt chain would) and because of some obscure corner cases which have shown up in private workshops that are much easier to isolate and to think about in an opt-in world. re: > > This is the beginning of a 3 week working group last call. > > This last call ends on December 6'th. > > > > This document updates RFC2535 to allow NXT chain to omit insecure > > delegations. This document covers the implications this has on > > servers and resolvers. > > > > This document is on standards track and is available via following URL: > > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-opt-in- > > 04.txt > > > > 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. archive: From owner-namedroppers@ops.ietf.org Mon Feb 3 16:38:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22621 for ; Mon, 3 Feb 2003 16:38:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18foA3-000PlU-00 for namedroppers-data@psg.com; Mon, 03 Feb 2003 13:29:51 -0800 Received: from numenor.qualcomm.com ([129.46.51.58]) by psg.com with esmtp (Exim 3.36 #1) id 18foA1-000PlI-00 for namedroppers@ops.ietf.org; Mon, 03 Feb 2003 13:29:49 -0800 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.3/8.12.5/1.0) with ESMTP id h13LTk2d015013 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 3 Feb 2003 13:29:47 -0800 (PST) Received: from CAMITLOAN6.qualcomm.com (camitloan6.qualcomm.com [129.46.225.112]) by sabrina.qualcomm.com (8.12.3/8.12.5/1.0) with ESMTP id h13LTiQi028299; Mon, 3 Feb 2003 13:29:44 -0800 (PST) Message-Id: <5.1.0.14.2.20030203132229.00a5fda0@mage.qualcomm.com> X-Sender: hardie@mage.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 03 Feb 2003 13:25:09 -0800 To: Paul Vixie , namedroppers@ops.ietf.org From: Ted Hardie Subject: Re: DNSEXT WGLC: DNSSEC Opt-in In-Reply-To: <20030203211253.ECFF9379EF3@as.vix.com> References: <244B987E-37A6-11D7-B86C-000393DB42B2@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=1.5 required=5.0 tests=IN_REP_TO,OPT_IN,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 09:12 PM 2/3/2003 +0000, Paul Vixie wrote: > > So, isn't it time to pass/kill this one? > >dunno. but in any case i am strongly in favour of it, both because it >softens the privacy-related impact of early dnssec deployment (walking >a short nxt chain exposes less information than walking a full nxt chain >would) and because of some obscure corner cases which have shown up in >private workshops that are much easier to isolate and to think about in >an opt-in world. One of the concerns that I have heard is that DS without Opt-In really needed those workshops in order to expose some corner cases and that Opt-In really has not had the kind of workshop trials that DS has had. Have I missed those workshop announcements, and, if so, are there public results I could catch up on? regards, Ted Hardie -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 3 16:39:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22675 for ; Mon, 3 Feb 2003 16:39:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18foGt-00007V-00 for namedroppers-data@psg.com; Mon, 03 Feb 2003 13:36:55 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 18foGr-00007E-00 for namedroppers@ops.ietf.org; Mon, 03 Feb 2003 13:36:53 -0800 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 42CBD137F03; Mon, 3 Feb 2003 13:36:52 -0800 (PST) Date: Mon, 3 Feb 2003 13:36:51 -0800 Subject: Re: DNSEXT WGLC: DNSSEC Opt-in Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: namedroppers@ops.ietf.org To: Paul Vixie From: David Conrad In-Reply-To: <20030203211253.ECFF9379EF3@as.vix.com> Message-Id: <9B8E4052-37BF-11D7-B86C-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,TO_BE_REMOVED_REPLY,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit To be perfectly honest, I no longer care which direction is chosen as long as a direction is chosen. Rgds, -drc On Monday, February 3, 2003, at 01:12 PM, Paul Vixie wrote: >> So, isn't it time to pass/kill this one? > > dunno. but in any case i am strongly in favour of it, both because it > softens the privacy-related impact of early dnssec deployment (walking > a short nxt chain exposes less information than walking a full nxt > chain > would) and because of some obscure corner cases which have shown up in > private workshops that are much easier to isolate and to think about in > an opt-in world. > > re: > >>> This is the beginning of a 3 week working group last call. >>> This last call ends on December 6'th. >>> >>> This document updates RFC2535 to allow NXT chain to omit insecure >>> delegations. This document covers the implications this has on >>> servers and resolvers. >>> >>> This document is on standards track and is available via following >>> URL: >>> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-opt-in- >>> 04.txt >>> >>> 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. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 3 16:43:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22756 for ; Mon, 3 Feb 2003 16:43:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18foFi-00001v-00 for namedroppers-data@psg.com; Mon, 03 Feb 2003 13:35:42 -0800 Received: from [2001:4f8:3:bb:2e0:81ff:fe23:7b5a] (helo=as.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 18foFc-000Q0e-00 for namedroppers@ops.ietf.org; Mon, 03 Feb 2003 13:35:36 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id B3D9D379EF3 for ; Mon, 3 Feb 2003 21:35:23 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: DNSSEC Opt-in In-Reply-To: Message from Ted Hardie of "Mon, 03 Feb 2003 13:25:09 PST." <5.1.0.14.2.20030203132229.00a5fda0@mage.qualcomm.com> X-Mailer: MH-E 7.1; nmh 1.0.4; Emacs 21.2 Date: Mon, 03 Feb 2003 21:35:23 +0000 Message-Id: <20030203213523.B3D9D379EF3@as.vix.com> X-Spam-Status: No, hits=0.7 required=5.0 tests=IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > One of the concerns that I have heard is that DS without Opt-In really > needed those workshops in order to expose some corner cases and that > Opt-In really has not had the kind of workshop trials that DS has had. yes, i saw that same kind of ballotbox stuffing going on, too. > Have I missed those workshop announcements, and, if so, are there public > results I could catch up on? fun was had in amsterdam, the week before ripe, and opt-in saw some testing. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 4 02:21:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12745 for ; Tue, 4 Feb 2003 02:21:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18fxBL-0001Iw-00 for namedroppers-data@psg.com; Mon, 03 Feb 2003 23:07:47 -0800 Received: from spratly.wl.nominum.com ([128.177.195.135]) by psg.com with esmtp (Exim 3.36 #1) id 18fxBH-0001Ii-00 for namedroppers@ops.ietf.org; Mon, 03 Feb 2003 23:07:43 -0800 Received: from spratly.wl.nominum.com (spratly [127.0.0.1]) by spratly.wl.nominum.com (8.12.5/8.12.5) with ESMTP id h1476Utl025258; Mon, 3 Feb 2003 23:06:30 -0800 Received: from localhost (bwelling@localhost) by spratly.wl.nominum.com (8.12.5/8.12.5/Submit) with ESMTP id h1476TCX025255; Mon, 3 Feb 2003 23:06:29 -0800 X-Authentication-Warning: spratly.wl.nominum.com: bwelling owned process doing -bs Date: Mon, 3 Feb 2003 23:06:29 -0800 (PST) From: Brian Wellington X-X-Sender: bwelling@spratly.wl.nominum.com To: Paul Vixie cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: DNSSEC Opt-in In-Reply-To: <20030203211253.ECFF9379EF3@as.vix.com> Message-ID: References: <20030203211253.ECFF9379EF3@as.vix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT, REFERENCES,SPAM_PHRASE_00_01,USER_AGENT_PINE,X_AUTH_WARNING version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 3 Feb 2003, Paul Vixie wrote: > dunno. but in any case i am strongly in favour of it, both because it > softens the privacy-related impact of early dnssec deployment (walking > a short nxt chain exposes less information than walking a full nxt chain > would) and because of some obscure corner cases which have shown up in > private workshops that are much easier to isolate and to think about in > an opt-in world. Are you (or someone else) planning to share what these corner cases are? 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. archive: From owner-namedroppers@ops.ietf.org Tue Feb 4 10:24:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25066 for ; Tue, 4 Feb 2003 10:24:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18g4de-000K7V-00 for namedroppers-data@psg.com; Tue, 04 Feb 2003 07:05:30 -0800 Received: from [2001:4f8:3:bb:2e0:81ff:fe23:7b5a] (helo=as.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 18g4db-000K7B-00 for namedroppers@ops.ietf.org; Tue, 04 Feb 2003 07:05:27 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 9FA30379EF3 for ; Tue, 4 Feb 2003 15:05:14 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: DNSSEC Opt-in In-Reply-To: Message from Brian Wellington of "Mon, 03 Feb 2003 23:06:29 PST." X-Mailer: MH-E 7.1; nmh 1.0.4; Emacs 21.2 Date: Tue, 04 Feb 2003 15:05:14 +0000 Message-Id: <20030204150514.9FA30379EF3@as.vix.com> X-Spam-Status: No, hits=0.7 required=5.0 tests=IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Are you (or someone else) planning to share what these corner cases are? as far as i know the notes and observations from the pre-ripe workshop were not published immediately on account of everybody was then busy at the ripe meeting itself. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 4 13:25:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00610 for ; Tue, 4 Feb 2003 13:25:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18g7h0-00044r-00 for namedroppers-data@psg.com; Tue, 04 Feb 2003 10:21:10 -0800 Received: from one.elistx.com ([209.116.252.130]) by psg.com with esmtp (Exim 3.36 #1) id 18g7gy-00044d-00 for namedroppers@ops.ietf.org; Tue, 04 Feb 2003 10:21:08 -0800 Received: from ogud.com (pcp816081pcs.nrockv01.md.comcast.net [68.49.60.118]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0H9S008CWQZOX4@eListX.com> for namedroppers@ops.ietf.org; Tue, 04 Feb 2003 13:21:24 -0500 (EST) Received: from ENGILL.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.3/8.12.3) with ESMTP id h14IKVts064349 for ; Tue, 04 Feb 2003 13:20:31 -0500 (EST envelope-from ogud@ogud.com) Date: Tue, 04 Feb 2003 13:20:34 -0500 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: Re: DNSEXT WGLC: RFC1886bis-01 In-reply-to: <5.1.1.6.2.20021114115616.02177250@localhost> X-Sender: (Unverified) To: namedroppers@ops.ietf.org Message-id: <5.1.1.6.2.20030204131832.01c52af0@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=iso-8859-1 X-Spam-Status: No, hits=2.3 required=5.0 tests=IN_REP_TO,RCVD_IN_RFCI,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA00610 At 13:43 2002-11-14, Ólafur Gudmundsson/DNSEXT co-chair wrote: >This is the beginning of a 3 week working group last call. >This last call ends on December 6'th. There where 0 comments on this document during last call. If there are no statements received supporting this document by February 10'th the chairs will not advance this document. Olafur >This document replaces RFC1886 with minimal changes incorporated from >interoperabilty testing and RFC3152 (ip6.arpa. delegation) > >This document is on standards track and is to be advanced to Draft >Standard it and supporting interoperabilty test report and is available >via following URLs: >http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc1886bis-01.txt > >http://www.6wind.com/RFC1886/testRFC1886.html > > 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. archive: From owner-namedroppers@ops.ietf.org Tue Feb 4 13:28:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00713 for ; Tue, 4 Feb 2003 13:28:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18g7eD-0003uI-00 for namedroppers-data@psg.com; Tue, 04 Feb 2003 10:18:17 -0800 Received: from one.elistx.com ([209.116.252.130]) by psg.com with esmtp (Exim 3.36 #1) id 18g7eA-0003u6-00 for namedroppers@ops.ietf.org; Tue, 04 Feb 2003 10:18:15 -0800 Received: from ogud.com (pcp816081pcs.nrockv01.md.comcast.net [68.49.60.118]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0H9S007JNQUUI1@eListX.com> for namedroppers@ops.ietf.org; Tue, 04 Feb 2003 13:18:31 -0500 (EST) Received: from ENGILL.ogud.com (mail.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.3/8.12.3) with ESMTP id h14IHbts064334 for ; Tue, 04 Feb 2003 13:17:37 -0500 (EST envelope-from ogud@ogud.com) Date: Tue, 04 Feb 2003 13:17:38 -0500 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: Re: DNSEXT WGLC: DNSSEC Opt-in In-reply-to: <20030204150514.9FA30379EF3@as.vix.com> X-Sender: (Unverified) To: namedroppers@ops.ietf.org Message-id: <5.1.1.6.2.20030204125500.00bad680@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=us-ascii References: <"Message from Brian Wellington X-Spam-Status: No, hits=3.6 required=5.0 tests=IN_REP_TO,OPT_IN,RCVD_IN_RFCI,REFERENCES,SPAM_PHRASE_03_05 version=2.43 X-Spam-Level: *** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This working group last call concluded in December with NO comments, there have been some comments in the last 24 hours. The chairs would like a more affirmative statements from the working group about this document. Default action: if there is NO response to these questions Opt-in document will be removed from the working group. Note: We are only asking the technical questions about Opt-in, the political question if we want to standardize this will be addressed if the technical questions are affirmative. Q: Is the description in the document of Opt-In complete ? Q: Does this document satisfy people as being implement able and testable specification ? Q: Are there implementations of opt-in and have there been any tests ? The chairs will consider any response received on the mailing list or sent privately to BOTH chairs, by February 12'th. 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. archive: From owner-namedroppers@ops.ietf.org Tue Feb 4 13:32:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00839 for ; Tue, 4 Feb 2003 13:32:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18g7no-0004TS-00 for namedroppers-data@psg.com; Tue, 04 Feb 2003 10:28:12 -0800 Received: from one.elistx.com ([209.116.252.130]) by psg.com with esmtp (Exim 3.36 #1) id 18g7nl-0004TF-00 for namedroppers@ops.ietf.org; Tue, 04 Feb 2003 10:28:09 -0800 Received: from ogud.com (pcp816081pcs.nrockv01.md.comcast.net [68.49.60.118]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0H9S008DCRBDX4@eListX.com> for namedroppers@ops.ietf.org; Tue, 04 Feb 2003 13:28:26 -0500 (EST) Received: from ENGILL.ogud.com (ns.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.3/8.12.3) with ESMTP id h14IRWts064370 for ; Tue, 04 Feb 2003 13:27:32 -0500 (EST envelope-from ogud@ogud.com) Date: Tue, 04 Feb 2003 13:27:38 -0500 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: Re: DNSEXT WGLC: TKEY Renewal Mode-02 In-reply-to: <5.1.1.6.2.20021114134710.0158ffa8@localhost> X-Sender: (Unverified) To: namedroppers@ops.ietf.org Message-id: <5.1.1.6.2.20030204132050.023f37b8@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=iso-8859-1 X-Spam-Status: No, hits=2.3 required=5.0 tests=IN_REP_TO,RCVD_IN_RFCI,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA00839 At 13:50 2002-11-14, Ólafur Gudmundsson/DNSEXT co-chair wrote: >This is the beginning of a 3 week working group last call. >This last call ends on December 6'th. > >This document updates RFC2930 to allow atomic updating of TKEY secrets. >This document defines a new mode for each algorithm supported, and >how the "key rollover" takes place. > >This document is on standards track and is available via following URL: >http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tkey-renewal-mode-02.txt > > Olafur The last call on this document resulted in few messages, raising two issues: 1. the complexity of the protocol 2. The document gave impression that some valid TKEY behavior was outlawed. The second issue requires minor text change to the document to fix. The first issue is much larger and requires more feedback for chairs I would like to pose the following questions to the working group Q: Is the technical description in the document sufficient and complete to implement ? Q: Are there any implementations or are there plans to implement ? Q: Is this overly complex and we should not do this ? Q: Is standards track appropriate for this, is experimental status better ? Silence will be taken as request to chairs to remove this document from working group consideration. Deadline for feedback is February 20'th. 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. archive: From owner-namedroppers@ops.ietf.org Tue Feb 4 13:50:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01161 for ; Tue, 4 Feb 2003 13:50:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18g82Y-0005IG-00 for namedroppers-data@psg.com; Tue, 04 Feb 2003 10:43:26 -0800 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 18g82V-0005I1-00 for namedroppers@ops.ietf.org; Tue, 04 Feb 2003 10:43:23 -0800 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 4D29818DF for ; Tue, 4 Feb 2003 13:43:09 -0500 (EST) Date: Tue, 04 Feb 2003 13:43:09 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: RFC1886bis-01 In-Reply-To: <5.1.1.6.2.20030204131832.01c52af0@localhost> References: <5.1.1.6.2.20021114115616.02177250@localhost> <5.1.1.6.2.20030204131832.01c52af0@localhost> User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030204184309.4D29818DF@thrintun.hactrn.net> X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Tue, 04 Feb 2003 13:20:34 -0500, Olafur Gudmundsson wrote: > > There where 0 comments on this document during last call. > If there are no statements received supporting this document by > February 10'th the chairs will not advance this document. > > >This document replaces RFC1886 with minimal changes incorporated from > >interoperabilty testing and RFC3152 (ip6.arpa. delegation) I support this document. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 4 14:45:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02649 for ; Tue, 4 Feb 2003 14:45:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18g8uR-0008PO-00 for namedroppers-data@psg.com; Tue, 04 Feb 2003 11:39:07 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 18g8uM-0008P1-00 for namedroppers@ops.ietf.org; Tue, 04 Feb 2003 11:39:02 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18g8ow-0000kf-00; Tue, 04 Feb 2003 14:33:26 -0500 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: RFC1886bis-01 References: <5.1.1.6.2.20021114115616.02177250@localhost> <5.1.1.6.2.20030204131832.01c52af0@localhost> Message-Id: Date: Tue, 04 Feb 2003 14:33:26 -0500 X-Spam-Status: No, hits=-0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > There where 0 comments on this document during last call. > If there are no statements received supporting this document by > February 10'th the chairs will not advance this document. this should be a no-brainer. we need 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. archive: From owner-namedroppers@ops.ietf.org Tue Feb 4 15:01:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02930 for ; Tue, 4 Feb 2003 15:01:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18g96c-0009Al-00 for namedroppers-data@psg.com; Tue, 04 Feb 2003 11:51:42 -0800 Received: from one.elistx.com ([209.116.252.130]) by psg.com with esmtp (Exim 3.36 #1) id 18g96X-00098c-00 for namedroppers@ops.ietf.org; Tue, 04 Feb 2003 11:51:37 -0800 Received: from ogud.com (pcp816081pcs.nrockv01.md.comcast.net [68.49.60.118]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0H9S00E9ZV6G43@eListX.com> for namedroppers@ops.ietf.org; Tue, 04 Feb 2003 14:51:52 -0500 (EST) Received: from ENGILL.ogud.com (ns.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.3/8.12.3) with ESMTP id h14Jowts064612 for ; Tue, 04 Feb 2003 14:50:58 -0500 (EST envelope-from ogud@ogud.com) Date: Tue, 04 Feb 2003 14:51:01 -0500 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: DNSEXT WGLC: IPv6 Name Auto Registration X-Sender: (Unverified) To: namedroppers@ops.ietf.org Message-id: <5.1.1.6.2.20030204144231.01e22c70@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=us-ascii X-Spam-Status: No, hits=3.1 required=5.0 tests=RCVD_IN_RFCI,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: *** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This starts a 2 week Working Group last call on this document, concluding on February 19'th. This document defines a mechanism to register IPv6 auto configuration in DNS. This document does not change the DNS protocol in any way or add new requirements for DNS servers or resolvers. This document is on experimental track and is available via following URL: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ipv6-name-auto-reg-00.txt Silence on this document during the last call will be taken as instruction to chairs to drop this document from consideration. 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. archive: From owner-namedroppers@ops.ietf.org Tue Feb 4 15:05:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02990 for ; Tue, 4 Feb 2003 15:05:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18g9Aq-0009fl-00 for namedroppers-data@psg.com; Tue, 04 Feb 2003 11:56:04 -0800 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #1) id 18g9Am-0009fT-00 for namedroppers@ops.ietf.org; Tue, 04 Feb 2003 11:56:01 -0800 Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.12.1/) with ESMTP id h14JtMq4021878; Tue, 4 Feb 2003 11:55:22 -0800 (PST) Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Feb 2003 11:55:57 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: =?iso-8859-1?Q?=27=D3lafur_Gudmundsson/DNSEXT_co-chair=27?= , namedroppers@ops.ietf.org Subject: RE: DNSEXT WGLC: DNSSEC Opt-in Date: Tue, 4 Feb 2003 11:55:52 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0022_01C2CC5D.839D8AC0" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=2.2 required=5.0 tests=EXCHANGE_SERVER,MISSING_OUTLOOK_NAME,OPT_IN, QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0022_01C2CC5D.839D8AC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > Default action: if there is NO response to these questions > Opt-in document > will be removed from the working group. That is a curious choice of default action. OK I will state for the record yet again. Without OPT-IN there is no prospect of DNS-SEC being deployable in the large zones. OPT-IN thus meets a critical requirement for which no competeing solution has been proposed. The choices facing this group are therefore 1) Accept Opt-in 2) Abandon DNS-SEC The lack of technical objections in last call is more usually taken as an indication that there are no technical objections to the proposal. > Note: We are only asking the technical questions about > Opt-in, the political > question if we want to standardize this will be addressed if the > technical questions are affirmative. If you don't want to discuss the requirement then the only thing that is left to discuss is technical objections. So silence can only mean consent. > Q: Is the description in the document of Opt-In complete ? How on earth is this meant to get a positive response? No IETF specification has ever been "complete". The authors believe the draft to be complete or they would not have proposed it go into last call. This appears to me to be yet another attempt to legitimate fuzzy objections that dare not speak their name as in: 'I'm not happy but I think I'm too important to have to give reasons why'. 'we have discussed this draft in the context of the TIA project, objections were raised but they are classified'. 'This draft does not explain the consequences of 20% of microfleems being subjugdanate' A compelling requirement has been described. No technical objections were raised during last call. Therefore the draft should go forward. > Q: Does this document satisfy people as being implement able > and testable specification ? It is a heck of a lot more implementable that what we have at present. I repeat, either the .com issue is addressed or DNSSEC DIES NOW. > Q: Are there implementations of opt-in and have there been any tests ? Yes, see comments by Paul. > The chairs will consider any response received on the mailing list or > sent privately to BOTH chairs, by February 12'th. If someone has a technical objection they should be able to discuss it in public. The working group process is a public process. No cabals, no directorates, no veto for the chairs. As RFC 2026 states: No contribution that is subject to any requirement of confidentiality or any restriction on its dissemination may be considered in any part of the Internet Standards Process, and there must be no assumption of any confidentiality obligation with respect to any such contribution. Phill ------=_NextPart_000_0022_01C2CC5D.839D8AC0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1 3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1 81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK +gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/ H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDIwNDE5 NTU1M1owIwYJKoZIhvcNAQkEMRYEFDkYRXJV88kPZlypFCiDd0SXwVnoMFgGCSqGSIb3DQEJDzFL MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO rwvJMA0GCSqGSIb3DQEBAQUABIGAUsEiPqDwsJ7YLlaPp2waGu3ogEjgblbJ982Ddj0sOpxVP5cu S1bohIjC5TC+LS1Cwmy0fMfbOtgOIe5c1Z3zAF9hQOaNQd7exOS05jAd+wqN+Ppfg5RIpU1vdYNg TEasB7aBIM6tJ7tUQoc38J7pNGPiLcJPoy8jpAFoOvSMBJQAAAAAAAA= ------=_NextPart_000_0022_01C2CC5D.839D8AC0-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 4 15:35:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03594 for ; Tue, 4 Feb 2003 15:35:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18g9iD-000BvN-00 for namedroppers-data@psg.com; Tue, 04 Feb 2003 12:30:33 -0800 Received: from h87.s239.netsol.com ([216.168.239.87] helo=localhost.localdomain) by psg.com with esmtp (Exim 3.36 #1) id 18g9iA-000BvA-00 for namedroppers@ops.ietf.org; Tue, 04 Feb 2003 12:30:30 -0800 Received: (from markk@localhost) by localhost.localdomain (8.11.6/8.11.6) id h14KUJu03333; Tue, 4 Feb 2003 15:30:19 -0500 Date: Tue, 4 Feb 2003 15:30:19 -0500 From: Mark Kosters To: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: DNSSEC Opt-in Message-ID: <20030204203019.GF2151@verisignlabs.com> References: <5.1.1.6.2.20030204125500.00bad680@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5.1.1.6.2.20030204125500.00bad680@localhost> User-Agent: Mutt/1.3.25i X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit On Tue, Feb 04, 2003 at 01:17:38PM -0500, Ólafur Gudmundsson/DNSEXT co-chair wrote: > Note: We are only asking the technical questions about Opt-in, the political > question if we want to standardize this will be addressed if the > technical questions are affirmative. I'm really puzzled by this process. Can you map this out for me please? > Q: Is the description in the document of Opt-In complete ? Yes. We had one quibble with opt-in using wildcards. The current draft forbids the negative wildcard proof to be returned but the implementation we used did return the negative wildcard proof (that is, an additional NXT record was sent covering the non-existant wildcard). Perhaps the draft needs to be relaxed to allow for the proof to be sent since it seems to do no harm. > Q: Does this document satisfy people as being implement able and testable > specification ? WRT opt-in, we tested with two authoritative servers (ISC and VeriSign) and one opt-in aware recursive server (ISC). A mixture of delegations were tested (fully secure, opt-in, and insecure) and all worked. So, it looks to me like the specifications are clear. > Q: Are there implementations of opt-in and have there been any tests ? Yes. See above. We had a workshop Jan 21-23 @ RIPE and I understand the results are going to be posted soon. Some of the tests run are listed at http://www.verisignlabs.com/workshop/index.html. And, I guess it should be no surprise that I support the advancement of opt-in. Mark -- Mark Kosters markk@verisignlabs.com Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 4 15:39:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03757 for ; Tue, 4 Feb 2003 15:39:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18g9nn-000CFa-00 for namedroppers-data@psg.com; Tue, 04 Feb 2003 12:36:19 -0800 Received: from ithilien.qualcomm.com ([129.46.51.59]) by psg.com with esmtp (Exim 3.36 #1) id 18g9nh-000CFO-00 for namedroppers@ops.ietf.org; Tue, 04 Feb 2003 12:36:13 -0800 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.3/8.12.5/1.0) with ESMTP id h14Ka7mI008616; Tue, 4 Feb 2003 12:36:07 -0800 (PST) Received: from CAMITLOAN6.qualcomm.com (camitloan6.qualcomm.com [129.46.225.112]) by neophyte.qualcomm.com (8.12.3/8.12.5/1.0) with ESMTP id h14Ka4sd025724; Tue, 4 Feb 2003 12:36:04 -0800 (PST) Message-Id: <5.1.0.14.2.20030204120228.00aefbf8@mage.qualcomm.com> X-Sender: hardie@mage.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 04 Feb 2003 12:32:02 -0800 To: "Hallam-Baker, Phillip" , "=?iso-8859-1?Q?=27=D3lafur?= Gudmundsson/DNSEXT co-chair'" , namedroppers@ops.ietf.org From: Ted Hardie Subject: RE: DNSEXT WGLC: DNSSEC Opt-in In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-1.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:55 AM 2/4/2003 -0800, Hallam-Baker, Phillip wrote: > > Default action: if there is NO response to these questions > > Opt-in document > > will be removed from the working group. > >That is a curious choice of default action. OK I will state for >the record yet again. > >Without OPT-IN there is no prospect of DNS-SEC being deployable >in the large zones. OPT-IN thus meets a critical requirement for >which no competeing solution has been proposed. The working group chairs asked for us to first consider the question of whether this draft sufficiently specifies the mechanisms it proposes. They asked to delay the question of whether it is required for deployment until that question has been answered. That seems to me a reasonable process, as it gives us a focused topic. That does not mean the second question will not be considered. >The choices facing this group are therefore > > 1) Accept Opt-in > 2) Abandon DNS-SEC > >The lack of technical objections in last call is more usually taken >as an indication that there are no technical objections to the >proposal. The lack of technical commentary can indicate a lack of review, rather than a lack of objections. Requesting comments (positive or negative) is a way of ensuring the review occurs. > > Note: We are only asking the technical questions about > > Opt-in, the political > > question if we want to standardize this will be addressed if the > > technical questions are affirmative. > >If you don't want to discuss the requirement then the only thing >that is left to discuss is technical objections. So silence can >only mean consent. See above. > > Q: Is the description in the document of Opt-In complete ? > >How on earth is this meant to get a positive response? No IETF >specification has ever been "complete". The authors believe >the draft to be complete or they would not have proposed it >go into last call. This is a request by the WG chairs for other members of the working group to state whether or not they concur or can point to areas where it is not complete. >This appears to me to be yet another attempt to legitimate fuzzy >objections that dare not speak their name as in: > > 'I'm not happy but I think I'm too important to have to > give reasons why'. > > 'we have discussed this draft in the context of the TIA project, > > objections were raised but they are classified'. > > 'This draft does not explain the consequences of 20% of > microfleems being subjugdanate' > >A compelling requirement has been described. No technical objections >were raised during last call. Therefore the draft should go forward. Again, the WG chairs asked us to discuss the spec first, then the question of whether the requirement is or is not compelling. > > Q: Does this document satisfy people as being implement able > > and testable specification ? > >It is a heck of a lot more implementable that what we have at presen >I repeat, either the .com issue is addressed or DNSSEC DIES NOW. If you have *implementation experience* that OPT-IN is better than DS without OPT-IN, now would be a good time to share it. > > Q: Are there implementations of opt-in and have there been any tests ? > >Yes, see comments by Paul. If you have pointers to results of those tests, that would be valuable. > > The chairs will consider any response received on the mailing list or > > sent privately to BOTH chairs, by February 12'th. > >If someone has a technical objection they should be able to discuss it >in public. I agree that all issues raised should be made public, and I suggest that the chairs send email to the list summarizing or excerpting any concerns they receive privately. Since the decision to advance or not advance the standards will be made on the technical merits of the review, it should not matter what names are associated with the review. > regards, Ted Hardie -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 4 15:41:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03860 for ; Tue, 4 Feb 2003 15:41:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18g9ou-000CJJ-00 for namedroppers-data@psg.com; Tue, 04 Feb 2003 12:37:28 -0800 Received: from [2001:4f8:3:bb:2e0:81ff:fe23:7b5a] (helo=as.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 18g9os-000CIo-00 for namedroppers@ops.ietf.org; Tue, 04 Feb 2003 12:37:26 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 82CE0379EF3 for ; Tue, 4 Feb 2003 20:37:13 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: DNSSEC Opt-in In-Reply-To: Message from =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair of "Tue, 04 Feb 2003 13:17:38 EST." <5.1.1.6.2.20030204125500.00bad680@localhost> X-Mailer: MH-E 7.2; nmh 1.0.4; GNU Emacs 21.2.1 Date: Tue, 04 Feb 2003 20:37:13 +0000 Message-Id: <20030204203713.82CE0379EF3@as.vix.com> X-Spam-Status: No, hits=0.7 required=5.0 tests=IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Q: Is the description in the document of Opt-In complete ? i believe that the current version of the specification is complete. > Q: Does this document satisfy people as being implement able and testable > specification ? yes. > Q: Are there implementations of opt-in and have there been any tests ? yes. (notes to be posted here shortly, so they tell 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. archive: From owner-namedroppers@ops.ietf.org Tue Feb 4 16:26:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04753 for ; Tue, 4 Feb 2003 16:26:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gAUy-000EnR-00 for namedroppers-data@psg.com; Tue, 04 Feb 2003 13:20:56 -0800 Received: from pushme.nist.gov ([129.6.16.92] helo=postmark.nist.gov) by psg.com with esmtp (Exim 3.36 #1) id 18gAUu-000EnF-00 for namedroppers@ops.ietf.org; Tue, 04 Feb 2003 13:20:52 -0800 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h14LKjf1020768 for ; Tue, 4 Feb 2003 16:20:45 -0500 (EST) Message-ID: <013301c2cc93$48e4acc0$b9370681@barnacle> From: "Scott Rose" To: References: <"Message from Brian Wellington <5.1.1.6.2.20030204125500.00bad680@localhost> Subject: Re: DNSEXT WGLC: DNSSEC Opt-in Date: Tue, 4 Feb 2003 16:20:47 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=1.2 required=5.0 tests=OPT_IN,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_OE version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Note: We are only asking the technical questions about Opt-in, the political > question if we want to standardize this will be addressed if the > technical questions are affirmative. > > Q: Is the description in the document of Opt-In complete ? > I believe it is. > Q: Does this document satisfy people as being implement able and testable > specification ? > > Q: Are there implementations of opt-in and have there been any tests ? > Hopefully this has been done and no show-stoppers have appeared. Barring any problems that appeared from the test, I would like to see the draft advanced. Scott -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 4 16:44:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05217 for ; Tue, 4 Feb 2003 16:44:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gAoA-000FsQ-00 for namedroppers-data@psg.com; Tue, 04 Feb 2003 13:40:46 -0800 Received: from mclmx.mail.saic.com ([149.8.64.10]) by psg.com with esmtp (Exim 3.36 #1) id 18gAo7-000FsD-00 for namedroppers@ops.ietf.org; Tue, 04 Feb 2003 13:40:43 -0800 Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for namedroppers@ops.ietf.org; Tue, 4 Feb 2003 16:39:41 -0500 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.2.17) with SMTP id M2003020416402701804 for ; Tue, 04 Feb 2003 16:40:27 -0500 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2653.19) id <1A8KG5AB>; Tue, 4 Feb 2003 16:42:21 -0500 Message-Id: <4E25ECBBC03F874CBAD03399254ADFDE104A5D@US-Columbia-CIST.mail.saic.com> From: "Loomis, Rip" To: namedroppers@ops.ietf.org Subject: RE: DNSEXT WGLC: DNSSEC Opt-in Date: Tue, 4 Feb 2003 16:40:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=1.4 required=5.0 tests=EXCHANGE_SERVER,OPT_IN,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I was one of those who had previously objected to Opt-In, although I was never able to clearly formulate a strong objection. At the time I felt it weakened the security model and made things more complex for administrators. I still think that it may make things more complex for administrators--but that additional complexity pales next to the complexity of DNSSEC zone signing. I no longer believe that Opt-In weakens the security model in any way. To answer the questions posed by the WG chair(s): > Q: Is the description in the document of Opt-In complete ? I believe so. > Q: Does this document satisfy people as being implement able > and testable specification ? I believe that the specification can be implemented and tested. > Q: Are there implementations of opt-in and have there been > any tests ? I have no personal experience with either, although I've heard reports. I support the advancement of the current Opt-In draft along the standards track. -- Rip Loomis Senior Systems Security Engineer SAIC Enterprise Security Solutions Group www.saic.com/securebiz Center for Information Security Technology www.cist-east.saic.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. archive: From owner-namedroppers@ops.ietf.org Tue Feb 4 16:47:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05371 for ; Tue, 4 Feb 2003 16:47:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gAqv-000G0t-00 for namedroppers-data@psg.com; Tue, 04 Feb 2003 13:43:37 -0800 Received: from pigeon.verisign.com ([65.205.251.71]) by psg.com with esmtp (Exim 3.36 #1) id 18gAqr-000G0g-00 for namedroppers@ops.ietf.org; Tue, 04 Feb 2003 13:43:33 -0800 Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by pigeon.verisign.com (8.12.1/) with ESMTP id h14Lfe3k021355; Tue, 4 Feb 2003 13:41:40 -0800 (PST) Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2656.59) id ; Tue, 4 Feb 2003 13:43:30 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Ted Hardie'" , "Hallam-Baker, Phillip" , =?iso-8859-1?Q?=27=D3lafur_Gudmundsson/DNSEXT_?= =?iso-8859-1?Q?_co-chair=27?= , namedroppers@ops.ietf.org Subject: Second OPT IN last call results in postponed decision Date: Tue, 4 Feb 2003 13:43:20 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_002F_01C2CC6C.8715EAD0" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=2.5 required=5.0 tests=EXCHANGE_SERVER,MISSING_OUTLOOK_NAME,OPT_IN, QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_002F_01C2CC6C.8715EAD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Ordinarily the chairs set the process for WG last call. However this is actually the SECOND last call for opt-in. http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg00398.html The result of the last working group last call was that after the discussion on the list clearly supported opt-in the chairs decided to take the matter to a forum of their own chosing - the DNS directorate, even though if you read the IETF process you will see that this is a step that only the IESG Area Directorate for the WG could take. It is not a step that Randy was entitled to take. The DNS Directorate never made any report back to the WG so what exactly was the point? So now we are expected to meakly go off again with a second unorthodox detour because the chairs want to change the rules again? No, Ted, the chairs do not at this point get the benefit of the doubt. Not the second time arround. Splitting the discussion so we hold the discussion on the technical issues before the requirements appears to be more a filibuster device than an attempt to focus the debate. The debate was completely focused, in fact it was so focused it had ended, no technical objections existed. If past experience is a guide 12th Feb will simply be the starting point for another round of discussion on the political issues, after which there will be a further consultation with the DNS Directorate which will do nothing for six months. After which there will be a THIRD 'last call' where OPT-IN will be postponed yet again because the emails written in support used the wrong font. So as Mark asked, just what is the procedure here? > The lack of technical commentary can indicate a lack of > review, rather than a lack of objections. Requesting > comments (positive or negative) is a way of ensuring the review > occurs. Given the length of time the group has been discussing this issue I believe that it strains anyones credulity to claim that there was a lack of review. If the specifications have not been adequately reviewed by the fabled DNS directorate then why did the specifications go there in the first place? If the people who have used every non-technical means to prevent this necessary fix to the spec taking place had a technical argument we can be sure that they would have used it. Or are you arguing that a specification should be held up because people opposed to it on ideological grounds did not bother to read it but might have found technical objections had they done so? In case it is not obvious I am in favour of OPT-IN. Phill ------=_NextPart_000_002F_01C2CC6C.8715EAD0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1 3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1 81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK +gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/ H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDIwNDIx NDMyMVowIwYJKoZIhvcNAQkEMRYEFAal7R6aF04PSTMz8nWhN2I/pXh3MFgGCSqGSIb3DQEJDzFL MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO rwvJMA0GCSqGSIb3DQEBAQUABIGAS5WfWyU8ih09wOzPcIm36ptuBfAfa4LsgXlwImZGpTG6bm3R f2JTJCSCd5tTQQNA4N5/21I0jzli2pWEvPqOaiqPS/W11wSbPVIOgVKsw7AR/joLqR94EX+ANnCE DDsGhUuQy+0qlXjwS0IGy+0AE/0E32oWewD2FQP9YSrjkvQAAAAAAAA= ------=_NextPart_000_002F_01C2CC6C.8715EAD0-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 4 18:30:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07949 for ; Tue, 4 Feb 2003 18:30:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gCRY-000Ll3-00 for namedroppers-data@psg.com; Tue, 04 Feb 2003 15:25:32 -0800 Received: from ithilien.qualcomm.com ([129.46.51.59]) by psg.com with esmtp (Exim 3.36 #1) id 18gCR4-000LkN-00 for namedroppers@ops.ietf.org; Tue, 04 Feb 2003 15:25:02 -0800 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.3/8.12.5/1.0) with ESMTP id h14NOwmI019252; Tue, 4 Feb 2003 15:24:58 -0800 (PST) Received: from CAMITLOAN6.qualcomm.com (camitloan6.qualcomm.com [129.46.225.112]) by neophyte.qualcomm.com (8.12.3/8.12.5/1.0) with ESMTP id h14NOtsd021658; Tue, 4 Feb 2003 15:24:55 -0800 (PST) Message-Id: <5.1.0.14.2.20030204145859.00a754e0@mage.qualcomm.com> X-Sender: hardie@mage.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 04 Feb 2003 15:19:17 -0800 To: "Hallam-Baker, Phillip" , "Hallam-Baker, Phillip" , "=?iso-8859-1?Q?=27=D3lafur?= Gudmundsson/DNSEXT co-chair'" , namedroppers@ops.ietf.org From: Ted Hardie Subject: Re: Second OPT IN last call results in postponed decision In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=0.4 required=5.0 tests=IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 01:43 PM 2/4/2003 -0800, Hallam-Baker, Phillip wrote: >Ordinarily the chairs set the process for WG last call. However this is >actually the SECOND last call for opt-in. > >http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg00398.html I went back and re-read that thread and the surrounding threads. I don't think the wg came to consensus. Others are welcome to re-read them and come to their own conclusions. I saw several different viewpoints ranging from "Delegation only OPT-IN gives us all the hassle and none of the advantages" to "OPT-IN is a rope mainly useful for hanging" with a lot of confusion remaining on what the spec actually said. At least one of the authors (Roy) indicated that the spec needed further work before it could go forward. This is not an unusual result to a working group last-call, frankly, but it is also not a signal that the draft is ready. >The result of the last working group last call was that after the >discussion on the list clearly supported opt-in the chairs decided to >take the matter to a forum of their own chosing - the DNS directorate, >even though if you read the IETF process you will see that this is a >step that only the IESG Area Directorate for the WG could take. It is >not a step that Randy was entitled to take. > >The DNS Directorate never made any report back to the WG so what exactly >was the point? This was hashed over many, many times on the mailing list, so I refer folks back to that. I'd say DRC's comment and the follow ups are reasonable places to start: http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg00742.html Other starting places and other conclusions are, of course, possible. >So now we are expected to meakly go off again with a second unorthodox >detour because the chairs want to change the rules again? > >No, Ted, the chairs do not at this point get the benefit of the doubt. >Not the second time arround. > >Splitting the discussion so we hold the discussion on the technical >issues before the requirements appears to be more a filibuster device >than an attempt to focus the debate. The debate was completely focused, >in fact it was so focused it had ended, no technical objections existed. Again, I went back and looked at the sum total of comments received during the last call response period. If it had ended, no one really bothered to state the conclusions during the last call. Asking for an explicit yes seems reasonable to me. > Given the length of time the group has been discussing this >issue I believe that it strains anyones credulity to claim that there >was a lack of review. Possibly I'm credulous. But my experience has been that many groups lose energy to give real review to specs as they go through the process. As Derek put it one of his messages: >One of the real issues is that opt-in severly changes the security >properties of DNSsec in a way that is not completely understood and >without a clear and comprehensive security analysis. Being a security >person myself I am uncomfortable mucking with security properties >without a clear analysis of the ramifications. Said cache-poisoning >attacks are one such ramification. Are there others? We don't know. >And there-in lies the potential gotchas. (from http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg00744.html ) I'd say ensuring that this analysis had been done and had some testing is a reasonable precursor to moving forward (and I'm very glad to hear that the write-up from the pre-RIPE meeting will be soon available). > Or are you arguing that a specification should be held up >because people opposed to it on ideological grounds did not bother to >read it but might have found technical objections had they done so? Nope. I'm arguing that requesting a positive assertion that something is the right thing to do is a reasonable way to gauge a working group's confidence in a specification. > In case it is not obvious I am in favour of OPT-IN. > > Phill In case it is not obvious, I think the quality of the outcome is more important than adherence to a timetable, and I have occasional heretical thoughts that it might even be more important than adherence to a particular process. regards, Ted Hardie -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 4 19:13:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08523 for ; Tue, 4 Feb 2003 19:13:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gD7p-000OF7-00 for namedroppers-data@psg.com; Tue, 04 Feb 2003 16:09:13 -0800 Received: from ithilien.qualcomm.com ([129.46.51.59]) by psg.com with esmtp (Exim 3.36 #1) id 18gD7k-000OEu-00 for namedroppers@ops.ietf.org; Tue, 04 Feb 2003 16:09:09 -0800 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.3/8.12.5/1.0) with ESMTP id h15094mI021990; Tue, 4 Feb 2003 16:09:04 -0800 (PST) Received: from CAMITLOAN6.qualcomm.com (camitloan6.qualcomm.com [129.46.225.112]) by crowley.qualcomm.com (8.12.3/8.12.5/1.0) with ESMTP id h150915O000471; Tue, 4 Feb 2003 16:09:01 -0800 (PST) Message-Id: <5.1.0.14.2.20030204155836.00b09640@mage.qualcomm.com> X-Sender: hardie@mage.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 04 Feb 2003 16:06:04 -0800 To: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair , namedroppers@ops.ietf.org From: Ted Hardie Subject: Re: DNSEXT WGLC: DNSSEC Opt-in In-Reply-To: <5.1.1.6.2.20030204125500.00bad680@localhost> References: <20030204150514.9FA30379EF3@as.vix.com> <"Message from Brian Wellington Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-Spam-Status: No, hits=1.0 required=5.0 tests=IN_REP_TO,OPT_IN,REFERENCES,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA08523 I had originally planned to wait to see what the test results showed before posing this question, but given the exchange thus far it is probably worth asking now. At 01:17 PM 2/4/2003 -0500, Ólafur Gudmundsson/DNSEXT co-chair wrote: >Q: Is the description in the document of Opt-In complete ? I'm not sure that section 3.1.1 (delegations only) is complete. Section 3.1.1 notes that servers and signers must enforce the restriction that only delegations may exist between the owner and "next" names of an Opt-In tagged NXT record. It was not obvious to me how to handle the error condition. If, for example, a caching resolver receives a request for some record, and gets an answer back that does not conform to 3.1.1, how should it indicate the error to the original requester? Was this one of the conditions tested in the recent set of tests? If so, how was this handled? I'm also not sure that section 7 adequately describes the risks inherent in how Opt-In interacts with NXDOMAIN. Though it makes the point that all unsigned names are at risk for insertion, modification, or deletion, it does not describe either the need for cryptographically assured denial of existence or the affect that Opt-In would have on the ability to provide it. Were others satisfied that this text handled the issue? regards, Ted Hardie -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 4 20:06:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09660 for ; Tue, 4 Feb 2003 20:06:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gDw0-0001KH-00 for namedroppers-data@psg.com; Tue, 04 Feb 2003 17:01:04 -0800 Received: from bulkregister-ldap.verisignlabs.com ([65.201.175.62] helo=cliffie.verisignlabs.com) by psg.com with esmtp (Exim 3.36 #1) id 18gDvv-0001Ju-00 for namedroppers@ops.ietf.org; Tue, 04 Feb 2003 17:00:59 -0800 Received: from pinion.admin.cto.netsol.com (h87.s239.netsol.com [216.168.239.87]) (AUTH: LOGIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by cliffie.verisignlabs.com with esmtp; Tue, 04 Feb 2003 20:00:57 -0500 From: David Blacka Organization: Verisign, Inc. To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: DNSSEC Opt-in Date: Tue, 4 Feb 2003 20:00:56 -0500 User-Agent: KMail/1.5 References: <20030204150514.9FA30379EF3@as.vix.com> <5.1.0.14.2.20030204155836.00b09640@mage.qualcomm.com> In-Reply-To: <5.1.0.14.2.20030204155836.00b09640@mage.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200302042000.56899.davidb@verisignlabs.com> X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC,OPT_IN, QUOTED_EMAIL_TEXT,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday 04 February 2003 07:06 pm, Ted Hardie wrote: > I'm not sure that section 3.1.1 (delegations only) is complete. Section 3.1.1 > notes that servers and signers must enforce the restriction that only > delegations may exist between the owner and "next" names of an Opt-In > tagged NXT record. It was not obvious to me how to handle the error > condition. If, for example, a caching resolver receives a request for some > record, and gets an answer back that does not conform to 3.1.1, how > should it indicate the error to the original requester? Was this one > of the conditions tested in the recent set of tests? If so, how was this > handled? This actually was tested. Violations of any of the requirements of the spec result in a validation error, which is reported as a SERVFAIL. When we tested this against our resolver implementation, we got SERVFAIL. So it worked. At the moment, I can't put my finger on where the protocol behavior of a validation failure is defined, but it probably should not be defined in the opt-in draft. Editorially, I can see adding language that make it clear that violations of 3.1.1 must be handed as a validation error, but I'm not sure that it is necessary. What do others think? -- David Blacka Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 4 20:51:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10716 for ; Tue, 4 Feb 2003 20:51:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gEfR-0004DE-00 for namedroppers-data@psg.com; Tue, 04 Feb 2003 17:48:01 -0800 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 18gEfN-0004Cs-00 for namedroppers@ops.ietf.org; Tue, 04 Feb 2003 17:47:57 -0800 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 70CB918EE for ; Tue, 4 Feb 2003 20:47:41 -0500 (EST) Date: Tue, 04 Feb 2003 20:47:41 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: DNSSEC Opt-in In-Reply-To: <200302042000.56899.davidb@verisignlabs.com> References: <20030204150514.9FA30379EF3@as.vix.com> <5.1.0.14.2.20030204155836.00b09640@mage.qualcomm.com> <200302042000.56899.davidb@verisignlabs.com> User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030205014741.70CB918EE@thrintun.hactrn.net> X-Spam-Status: No, hits=0.5 required=5.0 tests=IN_REP_TO,OPT_IN,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Tue, 4 Feb 2003 20:00:56 -0500, David Blacka wrote: > > At the moment, I can't put my finger on where the protocol behavior of a > validation failure is defined, but it probably should not be defined in the > opt-in draft. Editorially, I can see adding language that make it clear > that violations of 3.1.1 must be handed as a validation error, but I'm not > sure that it is necessary. What do others think? It would be a good idea to mention the issue explictly, but it's not a showstopper. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 4 21:09:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11152 for ; Tue, 4 Feb 2003 21:09:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gExD-0005Mv-00 for namedroppers-data@psg.com; Tue, 04 Feb 2003 18:06:23 -0800 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 18gExA-0005Mj-00 for namedroppers@ops.ietf.org; Tue, 04 Feb 2003 18:06:20 -0800 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 9EA2F18EE for ; Tue, 4 Feb 2003 21:06:06 -0500 (EST) Date: Tue, 04 Feb 2003 21:06:06 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: DNSSEC Opt-in In-Reply-To: <20030204203019.GF2151@verisignlabs.com> User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=X-UNKNOWN Message-Id: <20030205020606.9EA2F18EE@thrintun.hactrn.net> X-Spam-Status: No, hits=0.2 required=5.0 tests=IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA11152 At Tue, 4 Feb 2003 15:30:19 -0500, Mark Kosters wrote: > > On Tue, Feb 04, 2003 at 01:17:38PM -0500, Ólafur Gudmundsson/DNSEXT co-chair wrote: > > > Q: Does this document satisfy people as being implement able and testable > > specification ? > > WRT opt-in, we tested with two authoritative servers (ISC and VeriSign) and > one opt-in aware recursive server (ISC). A mixture of delegations were > tested (fully secure, opt-in, and insecure) and all worked. So, it looks > to me like the specifications are clear. Not to be difficult, but the resolver side of opt-in is the hard part. Is there a second iterative resolver implementation, and has it been through any interoperability testing? Not faulting anybody, just digging for whatever data we have. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 4 21:13:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11251 for ; Tue, 4 Feb 2003 21:13:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gF0o-0005eJ-00 for namedroppers-data@psg.com; Tue, 04 Feb 2003 18:10:06 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 18gF0k-0005dt-00 for namedroppers@ops.ietf.org; Tue, 04 Feb 2003 18:10:02 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18gEz1-0001Pr-00 for namedroppers@ops.ietf.org; Tue, 04 Feb 2003 21:08:15 -0500 Message-Id: <5.1.0.14.2.20030204205436.0340fa98@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Date: Tue, 04 Feb 2003 20:57:35 -0500 To: namedroppers@ops.ietf.org From: Margaret Wasserman Subject: Re: DNSEXT WGLC: RFC1886bis-01 Cc: =?iso-8859-1?Q?=D3lafur?= Gudmundsson X-Spam-Status: No, hits=0.7 required=5.0 tests=RESENT_TO,SPAM_PHRASE_01_02,TO_BE_REMOVED_REPLY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA11251 [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] This draft is widely implemented, technically sound and a very important part of IPv6. IMO, it is ready to advance to DS. Thanks, Margaret >Date: Tue, 04 Feb 2003 13:20:34 -0500 >From: Ólafur Gudmundsson/DNSEXT co-chair >Subject: Re: DNSEXT WGLC: RFC1886bis-01 > >At 13:43 2002-11-14, Ólafur Gudmundsson/DNSEXT co-chair wrote: >>This is the beginning of a 3 week working group last call. >>This last call ends on December 6'th. > >There where 0 comments on this document during last call. >If there are no statements received supporting this document by >February 10'th the chairs will not advance this document. > > Olafur > >>This document replaces RFC1886 with minimal changes incorporated from >>interoperabilty testing and RFC3152 (ip6.arpa. delegation) >> >>This document is on standards track and is to be advanced to Draft >>Standard it and supporting interoperabilty test report and is available >>via following URLs: >>http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc1886bis-01.txt >> >>http://www.6wind.com/RFC1886/testRFC1886.html >> >> 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. >archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 4 21:17:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11329 for ; Tue, 4 Feb 2003 21:17:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gF6U-000604-00 for namedroppers-data@psg.com; Tue, 04 Feb 2003 18:15:58 -0800 Received: from [2001:298:308:1:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 18gF6S-0005zr-00 for namedroppers@ops.ietf.org; Tue, 04 Feb 2003 18:15:56 -0800 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id A351F4B25; Wed, 5 Feb 2003 11:15:54 +0900 (JST) To: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Cc: namedroppers@ops.ietf.org In-reply-to: ogud's message of Thu, 14 Nov 2002 13:43:18 EST. <5.1.1.6.2.20021114115616.02177250@localhost> 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: DNSEXT WGLC: RFC1886bis-01 From: itojun@iijlab.net Date: Wed, 05 Feb 2003 11:15:54 +0900 Message-Id: <20030205021554.A351F4B25@coconut.itojun.org> X-Spam-Status: No, hits=1.3 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >This is the beginning of a 3 week working group last call. >This last call ends on December 6'th. >This document replaces RFC1886 with minimal changes incorporated from >interoperabilty testing and RFC3152 (ip6.arpa. delegation) i support this document. 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. archive: From owner-namedroppers@ops.ietf.org Tue Feb 4 21:20:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11431 for ; Tue, 4 Feb 2003 21:20:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gF8c-000698-00 for namedroppers-data@psg.com; Tue, 04 Feb 2003 18:18:10 -0800 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 18gF8Y-00068s-00 for namedroppers@ops.ietf.org; Tue, 04 Feb 2003 18:18:06 -0800 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 1030B18EE for ; Tue, 4 Feb 2003 21:17:53 -0500 (EST) Date: Tue, 04 Feb 2003 21:17:53 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Notes from my presentation on opt-in at IETF 55 References: <20030203231145.856C582@thangorodrim.hactrn.net> User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030205021753.1030B18EE@thrintun.hactrn.net> X-Spam-Status: No, hits=1.3 required=5.0 tests=OPT_IN,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk For those who missed it at the time, here's approximately what I said about opt-in at the DNSEXT meeting in Atlanta (IETF 55). Please note that implementation and testing status has progressed since this was written, so the comment about workshop experience is a bit dated. === Technical State Of Play So far, almost all the opt-in corner cases we've investigated have turned out to be base DNSSEC corner cases, not opt-in specific. In a few corner cases, opt-in requires special treatment, (eg: the AD bit); as far as we know none of the opt-in-specific stuff is major. As far as we know, delegation-only opt-in with DS is just as capable of providing a secure path down from the root as non-opt-in DNSSEC. Signed delegations are handled with NXT and DS RRs down from the parent whether one is using opt-in or not; the difference is just how one handles unsigned delegations. One important thing that the opt-in investigation has taught us is that caching in a DNSSEC universe probably needs to be blobs of stuff keyed by , rather than any attempt to cache under the actual record types in the returned response. Opt-in makes the need for this a little more obvious, but the need is there even without opt-in. Chosing opt-in does impose a more complex code path (have to handle both senses of the NXT bit). Once chosen, opt-in is "forever", although we might deprecate one value of the bit eventually. Complexity is almost always the enemy of security. DNSSEC is a complex protocol even without opt-in. Opt-in does make this a little worse. We do not yet have workshop experience with opt-in. We have just had our noses rubbed in the need for testing yet again with DS (psuedo lame delegation and wildcard proof surprise issues). Opt-in looks workable on paper, but there seems no way that we could chose opt-in without adding at least another N months for development and testing. The one thing that (almost) all sides of the "are anycast roots a good idea?" debate agree on is that the sooner we get a working DNSSEC out there, the less scary anycast roots will be. === Does Opt-In Benefit Anybody? Opt-in does help authoritative name server operators by allowing (some) costs to scale with deployment. Opt-in does not help resolver (aka "caching server") operators; it probably makes things worse, because additional complexity almost always means more failure modes. Opt-in does not help developers; again, it probably makes things worse, because additional complexity almost always means more failure modes. We don't really know whether opt-in helps users. More precisely, we know that is likely to help users with some things (reduction of some costs passed along by authoritative zone operators) and hurt with other things (increased cost of software development and maintenance). === My Personal Opinions On the whole, the strictly technical costs of opt-in are higher than the strictly technical benefits. The cost vs benefit to the Internet as a whole is not just a technical issue. If the cost of non-opt-in DNSSEC is so high that authoritative zone operators refuse to deploy it, it does not matter whether non-opt-in DNSSEC is "better". One day real soon now we really do need to make a decision and stick to it. We are probably getting to the point where we need DNSSEC badly enough that the cost of not having DNSSEC is going to outweigh the cost of DNSSEC either with or without opt-in. === "This holy war is not the first one, and probably will not be the last one either.... I do hope that my way will be chosen, but I believe that, after all, which way is chosen does not make too much difference. It is more important to agree upon an order than which order is agreed upon. How about tossing a coin ???" Danny Cohen, "On Holy Wars And A Plea For Peace", Internet Engineering Note 137, 1 April 1980. === -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 4 23:09:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14830 for ; Tue, 4 Feb 2003 23:09:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gGlm-000CxE-00 for namedroppers-data@psg.com; Tue, 04 Feb 2003 20:02:42 -0800 Received: from one.elistx.com ([209.116.252.130]) by psg.com with esmtp (Exim 3.36 #1) id 18gGlb-000CwX-00 for namedroppers@ops.ietf.org; Tue, 04 Feb 2003 20:02:31 -0800 Received: from ogud.com (pcp816081pcs.nrockv01.md.comcast.net [68.49.60.118]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0H9T00G6UHWMZB@eListX.com> for namedroppers@ops.ietf.org; Tue, 04 Feb 2003 23:02:46 -0500 (EST) Received: from ENGILL.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.3/8.12.3) with ESMTP id h1541ntu065827; Tue, 04 Feb 2003 23:01:50 -0500 (EST envelope-from ogud@ogud.com) Date: Tue, 04 Feb 2003 23:01:52 -0500 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: Re: DNSEXT WGLC: DNSSEC Opt-in In-reply-to: <20030204203019.GF2151@verisignlabs.com> X-Sender: (Unverified) To: Mark Kosters , =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Cc: namedroppers@ops.ietf.org Message-id: <5.1.1.6.2.20030204221837.023bffa0@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=iso-8859-1 References: <5.1.1.6.2.20030204125500.00bad680@localhost> X-Spam-Status: No, hits=2.2 required=5.0 tests=IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI,REFERENCES, SPAM_PHRASE_01_02 version=2.43 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA14830 At 15:30 2003-02-04, Mark Kosters wrote: >On Tue, Feb 04, 2003 at 01:17:38PM -0500, Ólafur Gudmundsson/DNSEXT >co-chair wrote: > > Note: We are only asking the technical questions about Opt-in, the > political > > question if we want to standardize this will be addressed if the > > technical questions are affirmative. > >I'm really puzzled by this process. Can you map this out for me please? I'm real sorry to have to do this to you, but recent history of DNSEXT forces us chairs to be extra careful and make sure there is documentation in the working group mailing list supporting all actions we take. Process for Opt-in: Step 1: force people to publicly state that they have reviewed the document and what changes if any are needed. At the same time extract what ever information possible about implementations and testing for the public record. Step 2: Chairs make a statement about technical soundness of document Step 3: Once chairs declare specification is sufficiently good, the political discussion on "do we want to do Opt-in" will be started. The thing that Randy and I want to avoid is people pointing at minor document defect and use that to object to Opt-in in general. > > Q: Is the description in the document of Opt-In complete ? > >Yes. We had one quibble with opt-in using wildcards. The current draft >forbids the negative wildcard proof to be returned but the implementation >we used did return the negative wildcard proof (that is, an additional NXT >record was sent covering the non-existant wildcard). Perhaps the draft >needs to be relaxed to allow for the proof to be sent since it seems to >do no harm. > > > Q: Does this document satisfy people as being implement able and testable > > specification ? > >WRT opt-in, we tested with two authoritative servers (ISC and VeriSign) and >one opt-in aware recursive server (ISC). A mixture of delegations were s/server/resolver/ ? >tested (fully secure, opt-in, and insecure) and all worked. So, it looks >to me like the specifications are clear. This is exactly the kind of information we need. > > Q: Are there implementations of opt-in and have there been any tests ? > >Yes. See above. We had a workshop Jan 21-23 @ RIPE and I understand the >results are going to be posted soon. Some of the tests run are listed >at http://www.verisignlabs.com/workshop/index.html. please post the contents of this web page to the mailing list or include relevant details in the report.[1] >And, I guess it should be no surprise that I support the advancement >of opt-in. Thanks Olafur [1] The reason I sometimes insist on posting the contents of web pages to the mailing list has to do with my history background. Message to mailing list is a record at particular time instant that can be attributed to certain person, Web page is a living thing that can be updated. The analogy is the difference between a letter and word-of-mouth. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 4 23:10:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14844 for ; Tue, 4 Feb 2003 23:10:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gGlf-000Cwn-00 for namedroppers-data@psg.com; Tue, 04 Feb 2003 20:02:35 -0800 Received: from one.elistx.com ([209.116.252.130]) by psg.com with esmtp (Exim 3.36 #1) id 18gGlb-000CwW-00 for namedroppers@ops.ietf.org; Tue, 04 Feb 2003 20:02:31 -0800 Received: from ogud.com (pcp816081pcs.nrockv01.md.comcast.net [68.49.60.118]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0H9T00I0CHWMAQ@eListX.com> for namedroppers@ops.ietf.org; Tue, 04 Feb 2003 23:02:46 -0500 (EST) Received: from ENGILL.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.3/8.12.3) with ESMTP id h1541nts065827; Tue, 04 Feb 2003 23:01:49 -0500 (EST envelope-from ogud@ogud.com) Date: Tue, 04 Feb 2003 22:55:32 -0500 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: RE: DNSEXT WGLC: DNSSEC Opt-in In-reply-to: X-Sender: (Unverified) To: "Hallam-Baker, Phillip" , "=?iso-8859-1?Q?=27=D3lafur?= Gudmundsson/DNSEXT co-chair'" , namedroppers@ops.ietf.org Message-id: <5.1.1.6.2.20030204220054.022d8008@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=us-ascii X-Spam-Status: No, hits=1.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT, RCVD_IN_RFCI,SPAM_PHRASE_01_02 version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 14:55 2003-02-04, Hallam-Baker, Phillip wrote: > > Default action: if there is NO response to these questions > > Opt-in document > > will be removed from the working group. > >That is a curious choice of default action. OK I will state for >the record yet again. Not at all, Chairs are asking for guidance and warning what the action is going to be if there is no guidance from the working group. For wg-chairs it is much simpler to drop a document than continue processing it, thus that was selected as the default action (this was done after consulting with the AD). >Without OPT-IN there is no prospect of DNS-SEC being deployable >in the large zones. OPT-IN thus meets a critical requirement for >which no competeing solution has been proposed. > >The choices facing this group are therefore > > 1) Accept Opt-in > 2) Abandon DNS-SEC > >The lack of technical objections in last call is more usually taken >as an indication that there are no technical objections to the >proposal. The problem during the last call, was NO COMMENTS. There where no objections no suggested text changes, no requests for clarification and NO statements of SUPPORT. How can we as chairs interpret silence ? The questions posted are indented to drive a discussion, nothing more nothing less. > > Note: We are only asking the technical questions about > > Opt-in, the political > > question if we want to standardize this will be addressed if the > > technical questions are affirmative. > >If you don't want to discuss the requirement then the only thing >that is left to discuss is technical objections. So silence can >only mean consent. We have discussed the requirement in the past and the justification for Opt-in, and every time the debate deteriorates quickly. In this case we are trying to drive a civil discussion on the "pure" technical issues. Nothing more, nothing less. If the technical specification is of sufficient quality then we can go on to the bigger picture. > > Q: Is the description in the document of Opt-In complete ? > >How on earth is this meant to get a positive response? No IETF >specification has ever been "complete". The authors believe >the draft to be complete or they would not have proposed it >go into last call. I as a author of few ID's know that it takes one or more Last call(s) and someone implementing the specification to shake out all the under/over specifications and other mistakes. Authors like to think that each version is the final one. If the comments are all nit picks then the specification is "complete" in my mind, if the comments require major change the document is not "complete", it is up to Randy and me to evaluate which category the changes (if any) fall into. >This appears to me to be yet another attempt to legitimate fuzzy >objections that dare not speak their name as in: > > 'I'm not happy but I think I'm too important to have to > give reasons why'. > > 'we have discussed this draft in the context of the TIA project, > > objections were raised but they are classified'. > > 'This draft does not explain the consequences of 20% of > microfleems being subjugdanate' > >A compelling requirement has been described. No technical objections >were raised during last call. Therefore the draft should go forward. Again, not a single statement was received saying the document was ready. > > Q: Does this document satisfy people as being implement able > > and testable specification ? > >It is a heck of a lot more implementable that what we have at present. We need someone to say so in public. >I repeat, either the .com issue is addressed or DNSSEC DIES NOW. This is out of scope at this point. > > Q: Are there implementations of opt-in and have there been any tests ? > >Yes, see comments by Paul. Evidence needs to be posted to the mailing list[1]. > > The chairs will consider any response received on the mailing list or > > sent privately to BOTH chairs, by February 12'th. > >If someone has a technical objection they should be able to discuss it >in public. Yes, any relevant comment sent to chairs will either be forwarded to mailing list or summarized. The main reason for this procedure is to allow people to post comments anonymously for what ever reason they have. We also wanted to make sure both of us where in the loop on all discussions in the past comments where frequently only sent to the chair that issued the last call. So far we have received 2 private messages, one was asking for guidance on how to constructively submit a comment, the other one a joke. >The working group process is a public process. No cabals, no >directorates, >no veto for the chairs. As RFC 2026 states: > > No contribution that is subject to any requirement of confidentiality > or any restriction on its dissemination may be considered in any part > of the Internet Standards Process, and there must be no assumption of > any confidentiality obligation with respect to any such contribution. Agree Olafur [1] In the past I received lots of flack for insisting that contents of relevant URL's be posted to the mailing list, this is done for archival reason more than anything else. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 5 03:49:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14587 for ; Wed, 5 Feb 2003 03:49:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gL3c-00044M-00 for namedroppers-data@psg.com; Wed, 05 Feb 2003 00:37:24 -0800 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 18gL3Z-000440-00 for namedroppers@ops.ietf.org; Wed, 05 Feb 2003 00:37:22 -0800 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.6/8.12.6/Debian-7) with ESMTP id h158bBIn016836; Wed, 5 Feb 2003 09:37:11 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.6/8.12.6/Debian-7) with ESMTP id h158bA3d016833; Wed, 5 Feb 2003 09:37:10 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 5 Feb 2003 09:37:10 +0100 (CET) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: DNSSEC Opt-in In-Reply-To: <5.1.1.6.2.20030204125500.00bad680@localhost> Message-ID: References: <"Message from Brian Wellington <5.1.1.6.2.20030204125500.00bad680@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-2.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT, REFERENCES,SPAM_PHRASE_00_01,USER_AGENT_PINE,X_AUTH_WARNING version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id DAA14587 On Tue, 4 Feb 2003, Ólafur Gudmundsson/DNSEXT co-chair wrote: > Q: Is the description in the document of Opt-In complete ? Yes. > Q: Does this document satisfy people as being implement able and testable > specification ? I did not implement it, nor was I able to test it during the last test-round. No opinion here. > Q: Are there implementations of opt-in and have there been any tests ? Yes, Verisignlabs and ISC have auth.server implementations, ISC has a resolver implementation. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 5 04:49:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15518 for ; Wed, 5 Feb 2003 04:49:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gM6k-00067q-00 for namedroppers-data@psg.com; Wed, 05 Feb 2003 01:44:42 -0800 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by psg.com with esmtp (Exim 3.36 #1) id 18gM6h-00067X-00 for namedroppers@ops.ietf.org; Wed, 05 Feb 2003 01:44:40 -0800 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id h159iZh16083; Wed, 5 Feb 2003 10:44:35 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h159hUof064868; Wed, 5 Feb 2003 10:43:30 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200302050943.h159hUof064868@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration In-reply-to: Your message of Tue, 04 Feb 2003 14:51:01 EST. <5.1.1.6.2.20030204144231.01e22c70@localhost> Date: Wed, 05 Feb 2003 10:43:30 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In your previous mail you wrote: This document is on experimental track and is available via following URL: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ipv6-name-auto-reg-00.txt => I support this document. Regards Francis.Dupont@enst-bretagne.fr -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 5 05:47:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16792 for ; Wed, 5 Feb 2003 05:47:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gN1J-0008N3-00 for namedroppers-data@psg.com; Wed, 05 Feb 2003 02:43:09 -0800 Received: from oban.autonomica.se ([192.71.80.69] helo=oban.autonomica.net) by psg.com with esmtp (Exim 3.36 #1) id 18gN1F-0008Mr-00 for namedroppers@ops.ietf.org; Wed, 05 Feb 2003 02:43:06 -0800 Received: by oban.autonomica.net (Postfix, from userid 501) id 74435119C65; Wed, 5 Feb 2003 11:43:04 +0100 (CET) To: Francis Dupont Cc: =?iso-8859-1?q?=D3lafur?= Gudmundsson/DNSEXT co-chair , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration References: <200302050943.h159hUof064868@givry.rennes.enst-bretagne.fr> From: Johan Ihren Date: 05 Feb 2003 11:43:03 +0100 In-Reply-To: <200302050943.h159hUof064868@givry.rennes.enst-bretagne.fr> Message-ID: Lines: 34 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Spam-Status: No, hits=-2.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, REFERENCES,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_GNUS_UA version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA16792 Francis Dupont writes: > In your previous mail you wrote: > > This document is on experimental track and is available via following URL: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ipv6-name-auto-reg-00.txt > > => I support this document. I don't. I think this is a really bad idea that would be much better solved by a combination of DHCPv6 and dynamic updates. Either the v6 devices need cuddly infrastructure to be happy (that's called DHCP) or they don't (that's called ad-hoc networking). As far as I understand arguments have been in favour of supporting the latter and then it seems a rather bad idea to start reinventing the support services of the infrastructure that was rejected in the first place. Furthermore, since: > This document defines a mechanism to register IPv6 auto > configuration in DNS. This document does not change the DNS > protocol in any way or add new requirements for DNS servers or > resolvers. I don't really see what it is doing in DNSEXT. But, of course, it is likely that I have not really understood this and that I'm just acting in the tradition of being mistaken ;-) Johan Ihrén Autonomica -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 5 06:50:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19438 for ; Wed, 5 Feb 2003 06:50:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gO1p-000Arr-00 for namedroppers-data@psg.com; Wed, 05 Feb 2003 03:47:45 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 18gO1m-000ArW-00 for namedroppers@ops.ietf.org; Wed, 05 Feb 2003 03:47:42 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18898; Wed, 5 Feb 2003 06:44:01 -0500 (EST) Message-Id: <200302051144.GAA18898@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-lewis-dns-wildcard-clarify-00.txt Date: Wed, 05 Feb 2003 06:44:01 -0500 X-Spam-Status: No, hits=4.6 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.43 X-Spam-Level: **** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Clarifying the Role of Wild Card Domains in the Domain Name System Author(s) : E. Lewis Filename : draft-lewis-dns-wildcard-clarify-00.txt Pages : 10 Date : 2003-2-4 The definition of wild cards is recast from the original in RFC 1034, in words that are more specific and in line with RFC 2119. This document is meant to supplement the definition in RFC 1034 and to alter neither the spirit nor intent of that definition. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lewis-dns-wildcard-clarify-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-lewis-dns-wildcard-clarify-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-lewis-dns-wildcard-clarify-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: <2003-2-4133920.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-lewis-dns-wildcard-clarify-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-lewis-dns-wildcard-clarify-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-4133920.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. archive: From owner-namedroppers@ops.ietf.org Wed Feb 5 06:50:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19454 for ; Wed, 5 Feb 2003 06:50:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gO1j-000ArS-00 for namedroppers-data@psg.com; Wed, 05 Feb 2003 03:47:39 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 18gO1g-000ArG-00 for namedroppers@ops.ietf.org; Wed, 05 Feb 2003 03:47:36 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18875; Wed, 5 Feb 2003 06:43:56 -0500 (EST) Message-Id: <200302051143.GAA18875@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-insensitive-01.txt Date: Wed, 05 Feb 2003 06:43:55 -0500 X-Spam-Status: No, hits=4.6 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.43 X-Spam-Level: **** 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 : Domain Name System (DNS) Case Insensitivity Clarification Author(s) : D. Eastlake Filename : draft-ietf-dnsext-insensitive-01.txt Pages : 10 Date : 2003-2-4 Domain Name System (DNS) names are 'case insensitive'. This document explains exactly what that means and provides a clear specification of the rules. This clarification should not have any interoperability consequences. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-insensitive-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-insensitive-01.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-insensitive-01.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: <2003-2-4133910.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-insensitive-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-insensitive-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-4133910.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. archive: From owner-namedroppers@ops.ietf.org Wed Feb 5 07:33:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22426 for ; Wed, 5 Feb 2003 07:33:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gOhU-000Cj7-00 for namedroppers-data@psg.com; Wed, 05 Feb 2003 04:30:48 -0800 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by psg.com with esmtp (Exim 3.36 #1) id 18gOhR-000CiV-00 for namedroppers@ops.ietf.org; Wed, 05 Feb 2003 04:30:46 -0800 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id h15CUfh19778; Wed, 5 Feb 2003 13:30:42 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h15CTZof065277; Wed, 5 Feb 2003 13:29:35 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200302051229.h15CTZof065277@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Johan Ihren cc: =?iso-8859-1?q?=D3lafur?= Gudmundsson/DNSEXT co-chair , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration In-reply-to: Your message of 05 Feb 2003 11:43:03 +0100. Date: Wed, 05 Feb 2003 13:29:35 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In your previous mail you wrote: > => I support this document. I don't. I think this is a really bad idea that would be much better solved by a combination of DHCPv6 and dynamic updates. => near 100% of current IPv6 networks don't use DHCPv6 for address allocation, and most won't. Dynamic updates alone are not easy to use, IMHO the basic idea of the IPv6 NAR draft is a good one. But the question here is not if we believe it is or not a good idea, it is if there is or is not enough interest... Either the v6 devices need cuddly infrastructure to be happy (that's called DHCP) => unfortunateley DHCP is not that. DHCPv6 is an IPv6 version of DHCP with addresses considered as a very rare resource... even if there are near 2^64 available addresses per link. or they don't (that's called ad-hoc networking). => no, this is "plug and play". Furthermore, since: > This document defines a mechanism to register IPv6 auto > configuration in DNS. This document does not change the DNS > protocol in any way or add new requirements for DNS servers or > resolvers. I don't really see what it is doing in DNSEXT. => DNSEXT was proposed by the chairs of the WGs. This draft needs a WG and DNSEXT is not so bad. Regards Francis.Dupont@enst-bretagne.fr -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 5 08:20:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24037 for ; Wed, 5 Feb 2003 08:20:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gPHu-000EFY-00 for namedroppers-data@psg.com; Wed, 05 Feb 2003 05:08:26 -0800 Received: from pushme.nist.gov ([129.6.16.92] helo=postmark.nist.gov) by psg.com with esmtp (Exim 3.36 #1) id 18gPHk-000EFM-00 for namedroppers@ops.ietf.org; Wed, 05 Feb 2003 05:08:16 -0800 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h15D7pf1014247 for ; Wed, 5 Feb 2003 08:07:51 -0500 (EST) Message-ID: <00f901c2cd17$97d66fb0$b9370681@barnacle> From: "Scott Rose" To: References: <5.1.1.6.2.20030204132050.023f37b8@localhost> Subject: Re: DNSEXT WGLC: TKEY Renewal Mode-02 Date: Wed, 5 Feb 2003 08:07:53 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_OE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit > At 13:50 2002-11-14, Ólafur Gudmundsson/DNSEXT co-chair wrote: > >This is the beginning of a 3 week working group last call. > >This last call ends on December 6'th. > The last call on this document resulted in few messages, > raising two issues: > 1. the complexity of the protocol > 2. The document gave impression that some valid TKEY behavior was outlawed. > > The second issue requires minor text change to the document to fix. > The first issue is much larger and requires more feedback for chairs > I would like to pose the following questions to the working group > > Q: Is the technical description in the document sufficient and complete to > implement ? > > Q: Are there any implementations or are there plans to implement ? > > Q: Is this overly complex and we should not do this ? > I read over the draft, and it seems complete. However, I don't know if it is implemented anywhere, nor has anyone I met plans on implementation. There might be some hidden pitfalls that come out then. > Q: Is standards track appropriate for this, is experimental status better ? > Unless there is a case for doing secret key rollover in the DNS instead of some previously known out-of-band method, it should be dropped. Otherwise, proceed as experimental due to cost versus benefit. I doubt most DNS operators will have the need to do secret key exchanges over DNS. > Silence will be taken as request to chairs to remove this document from > working group consideration. > Deadline for feedback is February 20'th. > > Olafur > Scott -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 5 10:28:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28456 for ; Wed, 5 Feb 2003 10:28:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gRFs-000Jg8-00 for namedroppers-data@psg.com; Wed, 05 Feb 2003 07:14:28 -0800 Received: from ms1.nttdata.co.jp ([163.135.193.232]) by psg.com with esmtp (Exim 3.36 #1) id 18gRFo-000Jfq-00 for namedroppers@ops.ietf.org; Wed, 05 Feb 2003 07:14:25 -0800 Received: from mail1.nttdata.co.jp ([163.135.10.21]) by ms1.nttdata.co.jp (8.9.3/3.7W-NTTDATA-TOP-01/14/03) with ESMTP id AAA18437 for ; Thu, 6 Feb 2003 00:14:22 +0900 (JST) Received: from noanetmx0.noanet.nttdata.co.jp (localhost [127.0.0.1]) by mail1.nttdata.co.jp (8.9.3/3.7W-NTTDATA-TOP-11/07/02) with ESMTP id AAA21742; Thu, 6 Feb 2003 00:11:51 +0900 (JST) Received: from noanet01.noanet.nttdata.co.jp (noanet01.noanet.nttdata.co.jp [10.1.49.11]) by noanetmx0.noanet.nttdata.co.jp (8.9.3/3.7W) with ESMTP id AAA23685; Thu, 6 Feb 2003 00:14:20 +0900 (JST) Received: from nttdata.co.jp (10.0.70.15 [10.0.70.15]) by noanet01.noanet.nttdata.co.jp with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DVMRAZNW; Thu, 6 Feb 2003 00:14:20 +0900 Message-ID: <3E412A47.70607@nttdata.co.jp> Date: Thu, 06 Feb 2003 00:14:15 +0900 From: Tatsuya Baba User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; ja-JP; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: ja MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: I-D regarding access control in DNS Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.3 required=5.0 tests=SEARCH_ENGINE_PROMO,SPAM_PHRASE_01_02,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, I wrote an I-D regarding access control in DNS. draft-baba-dnsext-acl-reqts-00.txt I know that DNSSEC specification states "the DNS design philosophy calls for all DNS data to be public." However, I also know that there are many people who would like to control access to DNS data. Is there anyone who is interested in this area? Any comments, questions, or corrections are appreciated. Regards. -- Tatsuya Baba -------- Original Message -------- Subject: I-D ACTION:draft-baba-dnsext-acl-reqts-00.txt Date: Wed, 05 Feb 2003 06:44:12 -0500 From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org To: IETF-Announce: ; A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for Access Control in Domain Name Systems Author(s) : T. Baba Filename : draft-baba-dnsext-acl-reqts-00.txt Pages : 6 Date : 2003-2-4 This document describes the requirements for access control mechanisms in the Domain Name System (DNS), which authenticate clients and then allow or deny access to resource records in the zone according to the access control list (ACL). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-baba-dnsext-acl-reqts-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-baba-dnsext-acl-reqts-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-baba-dnsext-acl-reqts-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. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 5 11:00:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29408 for ; Wed, 5 Feb 2003 11:00:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gRs0-000LVJ-00 for namedroppers-data@psg.com; Wed, 05 Feb 2003 07:53:52 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #1) id 18gRrw-000LUM-00 for namedroppers@ops.ietf.org; Wed, 05 Feb 2003 07:53:48 -0800 Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.5/8.11.6) with SMTP id h15FrlAq022681 for ; Wed, 5 Feb 2003 16:53:47 +0100 Date: Wed, 5 Feb 2003 16:53:47 +0100 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: OPT-IN workshop Report Message-Id: <20030205165347.42800ef7.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=2.1 required=5.0 tests=NOSPAM_INC,OPT_IN,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jan 21-23 RIPE NCC hosted a workshop to test OPT-IN specs and code. In addition to the OPT-IN code we looked at a number of recent open issues and tested possible solutions for which code was available. The workshop summary is below. More detailed notes (daily log) can be found at http://www.ripe.net/DISI/optin-workshop/. --Olaf -------------------------------------------------------------------- Initial goals: test opt-in for basic functioning time permitting, additional testing of DNSSEC functionality Opt-in results: * basically works as far as we can tell * specification issues - draft & implementation behavior WRT NXT is different, probably draft needs to change, on inclusion of negative wildcard proof in the answer (draft says MUST NOT, code does it, it's probably harmless, draft should say MAY) - insecure delegation with opt-in NXT is semantically ambiguous, useless, and doesn't work (SERVFAIL) - draft should mention dynamic update behavior. It should caution against dyanmic update with opt-in. * code bugs found in signer (VRSN) and ISC-integrated Nominum code, mostly minor and easily fixed during the workshop Additional testing and observations: KSK * signer shows some minor bugs, no impact on protocol seen (ISC) as expected. Operationally it is easy and convenient to be able to tell which is the KSK from the parity of the flag field. Having the signer distinguish between KSK and ZSK automatically is a good feature DS (research?) DS "Signaling" There are several identified problems with DS. They all seem to converge to problems with data being received that is not expected. One of the identified problems is that currently Bind 9.1/9.2 resolvers choke on a referral from a secure to an insecure zone that comes with a NXT RR, which is taken to prove the non-existence of a delegation according to old DNSSEC semantics" Currently some people are thinking about two possible solutions to this problem. The workshot had code available that allowed us to experiment with both. The workshop realizes that these experiments are very preliminary, we tested for basic feasibility of these approaches. We believe that there is further analysis to be done on both the protocol implications and the code for either of these, or even, alternative approaches. The two approaches that were tried to circumvent the problems that are introduced with the current modifications of DNSSEC are: - using a signaling bit (DA) in the OPT RR and; - the use of alternative type codes and mnemonics for SIG, NXT and KEY. With the DA signaling the identified problems problems do disappear, as also with changing type codes. Both act as "Flag" date options, they do not inter-operate with any previous DNSSEC implementations with respect to DNSSEC operations. Both seem to meet the basic need of keeping old DNSSEC implementations from having to cope with new DNSSEC data. No new problems are seen for normal resolving. In our limited tests we did not identify new corner cases with either approach. Note more testing and analysis are needed, this was a preliminary effort only. Recommendations on approaches will need to be proposed to the dnsext-wg, any recommendation was deemed premature by the workshop. Further discussion is needed on the operational and protocol implications of any approach to this problem. DS 'Grand parent' problem The grand parent problem (what if a grand parent and child are authoritative for a DS and the parent lives on another server) was to be tested but because of an inconsistent setup we did not come to a conclusion. General comment useful for other workshops or operations 'dig +multiline' is ones friend for troubleshooting which keys are returned. For troubleshooting one needs more than just the logs from the verifier. A perl resolver that turns out to be useful is available at www.nlnetlabs.nl/dnssec/ (we know of more efforts to make them). A server to hand out preconfigured incorrect answers seems to be a useful tool. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 5 11:24:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00251 for ; Wed, 5 Feb 2003 11:24:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gSF7-000MbK-00 for namedroppers-data@psg.com; Wed, 05 Feb 2003 08:17:45 -0800 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 18gSF3-000Mb1-00 for namedroppers@ops.ietf.org; Wed, 05 Feb 2003 08:17:41 -0800 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 9597F18EC for ; Wed, 5 Feb 2003 11:17:27 -0500 (EST) Date: Wed, 05 Feb 2003 11:17:27 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: OPT-IN workshop Report In-Reply-To: <20030205165347.42800ef7.olaf@ripe.net> References: <20030205165347.42800ef7.olaf@ripe.net> User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030205161727.9597F18EC@thrintun.hactrn.net> X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Wed, 5 Feb 2003 16:53:47 +0100, Olaf Kolkman wrote: ... > One of the identified problems is that currently Bind 9.1/9.2 > resolvers choke on a referral from a secure to an insecure zone > that comes with a NXT RR, which is taken to prove the > non-existence of a delegation according to old DNSSEC > semantics" ... > - the use of alternative type codes and mnemonics for SIG, NXT > and KEY. Not obvious to me why one would need to change SIG and KEY here. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 5 12:23:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02546 for ; Wed, 5 Feb 2003 12:23:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gT8f-000PNf-00 for namedroppers-data@psg.com; Wed, 05 Feb 2003 09:15:09 -0800 Received: from pigeon.verisign.com ([65.205.251.71]) by psg.com with esmtp (Exim 3.36 #1) id 18gT8d-000PNS-00 for namedroppers@ops.ietf.org; Wed, 05 Feb 2003 09:15:07 -0800 Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by pigeon.verisign.com (8.12.1/) with ESMTP id h15HDC3k007562; Wed, 5 Feb 2003 09:13:12 -0800 (PST) Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2656.59) id ; Wed, 5 Feb 2003 09:15:04 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Tatsuya Baba'" , namedroppers@ops.ietf.org Subject: RE: I-D regarding access control in DNS Date: Wed, 5 Feb 2003 09:14:58 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0023_01C2CD10.325DBCD0" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=3.5 required=5.0 tests=EXCHANGE_SERVER,MISSING_OUTLOOK_NAME,QUOTED_EMAIL_TEXT, SEARCH_ENGINE_PROMO,SPAM_PHRASE_02_03,TO_BE_REMOVED_REPLY version=2.43 X-Spam-Level: *** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0023_01C2CD10.325DBCD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Attempting to move from a public protocol to a private one is difficult. A particular problem that you would face is the fact that implementations are likely to cache information and forward it in ways that do not conform with the access control policy that you are attempting to impose. Furthermore DNS stacks are deep integrated into O/S layers so you have the potential for lots of confusion if person A who is not authorized to know X puts in a request before person B who is. This problem has hit the WebDav group which has been suggesting all manner of unlikely solutions. The proposal 'don't try caching then' falling on stony ground. If you really want to do this you will also need privacy enhancements to the DNS protocol. So you are going to end up requiring a key agreement. So why not do a key agreement against a separate service, perform any access control you might want to do at that point and then use a cryptographic encapsulation? That would appear to describe IPSEC. Incidentally the lack of access control is one reason why it is not a good idea to attempt to lard every possible lookup function into the DNS. Phill > -----Original Message----- > From: Tatsuya Baba [mailto:babatt@nttdata.co.jp] > Sent: Wednesday, February 05, 2003 10:14 AM > To: namedroppers@ops.ietf.org > Subject: I-D regarding access control in DNS > > > Hi all, > > I wrote an I-D regarding access control in DNS. > > draft-baba-dnsext-acl-reqts-00.txt > > I know that DNSSEC specification states "the DNS design > philosophy calls > for all DNS data to be public." However, I also know that there are > many people who would like to control access to DNS data. > > Is there anyone who is interested in this area? > > Any comments, questions, or corrections are appreciated. > > Regards. > > -- Tatsuya Baba > > -------- Original Message -------- > Subject: I-D ACTION:draft-baba-dnsext-acl-reqts-00.txt > Date: Wed, 05 Feb 2003 06:44:12 -0500 > From: Internet-Drafts@ietf.org > Reply-To: Internet-Drafts@ietf.org > To: IETF-Announce: ; > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Requirements for Access Control in > Domain Name Systems > Author(s) : T. Baba > Filename : draft-baba-dnsext-acl-reqts-00.txt > Pages : 6 > Date : 2003-2-4 > > This document describes the requirements for access control > mechanisms in the Domain Name System (DNS), which authenticate > clients and then allow or deny access to resource records in the > zone according to the access control list (ACL). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-baba-dnsext-acl-reqts-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body > of the message. > > 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-baba-dnsext-acl-reqts-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-baba-dnsext-acl-reqts-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. > > > > -- > to unsubscribe send a message to > namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > ------=_NextPart_000_0023_01C2CD10.325DBCD0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1 3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1 81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK +gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/ H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDIwNTE3 MTQ1NlowIwYJKoZIhvcNAQkEMRYEFIWGQmdIOHVEYjdclG9IhjBuktUsMFgGCSqGSIb3DQEJDzFL MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO rwvJMA0GCSqGSIb3DQEBAQUABIGAFk6B8ZrXbCMrSIHtEZ67LaQfV8qxyz3E0yEn9E3BKy54OmUA qCkmKofwz6vWRkQdAUnCs9RiVZZ294cDcckja2B0VJTYh/vaBfGkyZSoTNQZRtABHxjtzd8/+WGC bvEusS7GPVRtmQdKxzNuncFz700oUGKy3PI1nOmTHVZcPDkAAAAAAAA= ------=_NextPart_000_0023_01C2CD10.325DBCD0-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 5 12:30:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02788 for ; Wed, 5 Feb 2003 12:30:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gTJG-000PvE-00 for namedroppers-data@psg.com; Wed, 05 Feb 2003 09:26:06 -0800 Received: from pushme.nist.gov ([129.6.16.92] helo=postmark.nist.gov) by psg.com with esmtp (Exim 3.36 #1) id 18gTJC-000PuP-00 for namedroppers@ops.ietf.org; Wed, 05 Feb 2003 09:26:02 -0800 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h15HPsf1015579; Wed, 5 Feb 2003 12:25:54 -0500 (EST) Message-ID: <003a01c2cd3b$a4979fc0$b9370681@barnacle> From: "Scott Rose" To: "Tatsuya Baba" , References: <3E412A47.70607@nttdata.co.jp> Subject: Re: I-D regarding access control in DNS Date: Wed, 5 Feb 2003 12:25:56 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_OE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I don't know if this is something the WG should be looking at. Besides making a decision not to include confidentiality into the DNSSEC extensions and I believe there are good reasons not too: 1. Many DNS implementations have some sort of acl functionality built in. It is also easier to do access control outside of the DNS protocol. 2. IPSec can be used to provide confidentiality at a lower level (hard to imagine DNS would be the only network traffic that a network wants encrypted). minor problems 3. New records will have to be introduced for the ACL (TXT RRs probably won't do), 4. new RCODEs would have to be introduced/redefined for security. That might affect backwards compatibility when older resolvers try to communicate with a AC aware server. I do not believe that the benefit of adding this functionality outweights the cost and burden it would place on the DNS. This benefit already exists to some degree by other protocols and implementations. Scott ----- Original Message ----- From: "Tatsuya Baba" To: Sent: Wednesday, February 05, 2003 10:14 AM Subject: I-D regarding access control in DNS > Hi all, > > I wrote an I-D regarding access control in DNS. > > draft-baba-dnsext-acl-reqts-00.txt > > I know that DNSSEC specification states "the DNS design philosophy calls > for all DNS data to be public." However, I also know that there are > many people who would like to control access to DNS data. > > Is there anyone who is interested in this area? > > Any comments, questions, or corrections are appreciated. > > Regards. > > -- Tatsuya Baba > > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 5 12:39:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03181 for ; Wed, 5 Feb 2003 12:39:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gTR9-0000P0-00 for namedroppers-data@psg.com; Wed, 05 Feb 2003 09:34:15 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 18gTR8-0000Oo-00 for namedroppers@ops.ietf.org; Wed, 05 Feb 2003 09:34:14 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18gTPI-0002ah-00 for namedroppers@ops.ietf.org; Wed, 05 Feb 2003 12:32:20 -0500 Message-Id: <4.3.2.7.2.20030205080905.02f85da8@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Date: Wed, 05 Feb 2003 08:13:41 -0800 To: namedroppers@ops.ietf.org From: Bob Hinden Subject: Re: DNSEXT WGLC: RFC1886bis-01 Cc: hinden@IPRG.nokia.com, =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair X-Spam-Status: No, hits=0.3 required=5.0 tests=RESENT_TO,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA03181 [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] I support this document being advanced. It is widely implemented and stable, and meets the requirement for Draft Standard. Bob >Date: Tue, 04 Feb 2003 13:20:34 -0500 >From: Ólafur Gudmundsson/DNSEXT co-chair >Subject: Re: DNSEXT WGLC: RFC1886bis-01 >In-reply-to: <5.1.1.6.2.20021114115616.02177250@localhost> >X-Sender: (Unverified) >To: namedroppers@ops.ietf.org > >At 13:43 2002-11-14, Ólafur Gudmundsson/DNSEXT co-chair wrote: >This is the beginning of a 3 week working group last call. >This last call ends on December 6'th. > >There where 0 comments on this document during last call. >If there are no statements received supporting this document by >February 10'th the chairs will not advance this document. > > Olafur > >This document replaces RFC1886 with minimal changes incorporated from >interoperabilty testing and RFC3152 (ip6.arpa. delegation) > >This document is on standards track and is to be advanced to Draft >Standard it and supporting interoperabilty test report and is available >via following URLs: >http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc1886bis-01.txt > >http://www.6wind.com/RFC1886/testRFC1886.html > > 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. archive: From owner-namedroppers@ops.ietf.org Wed Feb 5 13:27:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05569 for ; Wed, 5 Feb 2003 13:27:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gU8D-0002o4-00 for namedroppers-data@psg.com; Wed, 05 Feb 2003 10:18:45 -0800 Received: from oban.autonomica.se ([192.71.80.69] helo=oban.autonomica.net) by psg.com with esmtp (Exim 3.36 #1) id 18gU85-0002no-00 for namedroppers@ops.ietf.org; Wed, 05 Feb 2003 10:18:37 -0800 Received: by oban.autonomica.net (Postfix, from userid 501) id 3C85911A545; Wed, 5 Feb 2003 19:18:37 +0100 (CET) To: Francis Dupont Cc: =?iso-8859-1?q?=D3lafur?= Gudmundsson/DNSEXT co-chair , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration References: <200302051229.h15CTZof065277@givry.rennes.enst-bretagne.fr> From: Johan Ihren Date: 05 Feb 2003 19:18:36 +0100 In-Reply-To: <200302051229.h15CTZof065277@givry.rennes.enst-bretagne.fr> Message-ID: Lines: 84 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-1.8 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, REFERENCES,SPAM_PHRASE_03_05,USER_AGENT,USER_AGENT_GNUS_UA version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Francis Dupont writes: Hi Francis, > In your previous mail you wrote: > > > => I support this document. > > I don't. > > I think this is a really bad idea that would be much better solved by > a combination of DHCPv6 and dynamic updates. > > => near 100% of current IPv6 networks don't use DHCPv6 for > address allocation, and most won't. Dynamic updates alone > are not easy to use, IMHO the basic idea of the IPv6 NAR draft > is a good one. But the question here is not if we believe it > is or not a good idea, it is if there is or is not enough interest... They don't use DHCPv6 since there (as far as I know) was a concious design decision made that it was not possible to rely on "infrastructure services" being available on every piece of cable (or air wave) that a v6 device would like to connect to. Which is fine. But you got what you asked for: no services. No DHCP server that can tell you about your FQDN, no trust relationship with the friendly nearby DNS infrastructure (that you get via DHCP and use for updating DNS). Nor will you get NTP clocks (available through DHCP), printers (guess) or the location of the local cola vending machine, etc, etc... Design decision --> expected results followed --> no one is surprised. > either the v6 devices need cuddly infrastructure to be happy (that's > called DHCP) > > => unfortunateley DHCP is not that. DHCPv6 is an IPv6 version of > DHCP with addresses considered as a very rare resource... even > if there are near 2^64 available addresses per link. Red herring (or I should perhaps say "fermented herring", a well known swedish delicacy ;-). DHCP for v6 is not primarily about address allocation (that is obviously not the major issue that it was for v4). DHCP is about a standardized mechanism for "newly connected" devices to locate stuff it has a need for (and possibly some stuff it doesn't care about). > or they don't (that's called ad-hoc networking). > > => no, this is "plug and play". There are two kinds of networks (yes, we all know that there are two kinds of everything, but that includes networks...): those with infrastructure services and those without. You can plug-and-pray on both types. But the rules are different. And *if* (please note the *if*) your requirements also are different (let's say you suddenly feel an urge to update DNS), then you should play by the rules. For a network *with* infrastructure services the rule is: "Don't invent your own mechanism to locate stuff, use DHCP". > Furthermore, since: > > > This document defines a mechanism to register IPv6 auto > > configuration in DNS. This document does not change the DNS > > protocol in any way or add new requirements for DNS servers or > > resolvers. > > I don't really see what it is doing in DNSEXT. > > => DNSEXT was proposed by the chairs of the WGs. This draft needs > a WG and DNSEXT is not so bad. Hmm. Wrong choice. This should clearly be sent to DHC ;-) Anyway, the point wasn't to spur discussion about this but rather to argue that it should die. So I'll just shut up now and let everyone get back to the previous programme... Regards, Johan -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 5 13:28:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05634 for ; Wed, 5 Feb 2003 13:28:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gUDb-00036p-00 for namedroppers-data@psg.com; Wed, 05 Feb 2003 10:24:19 -0800 Received: from oban.autonomica.se ([192.71.80.69] helo=oban.autonomica.net) by psg.com with esmtp (Exim 3.36 #1) id 18gUDY-00036d-00 for namedroppers@ops.ietf.org; Wed, 05 Feb 2003 10:24:16 -0800 Received: by oban.autonomica.net (Postfix, from userid 501) id 8E9C011A5B1; Wed, 5 Feb 2003 19:24:18 +0100 (CET) To: Rob Austein Cc: namedroppers@ops.ietf.org Subject: Re: OPT-IN workshop Report References: <20030205165347.42800ef7.olaf@ripe.net> <20030205161727.9597F18EC@thrintun.hactrn.net> From: Johan Ihren Date: 05 Feb 2003 19:24:17 +0100 In-Reply-To: <20030205161727.9597F18EC@thrintun.hactrn.net> Message-ID: Lines: 10 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-0.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT, RCVD_IN_RFCI,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_GNUS_UA version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Rob Austein writes: > > - the use of alternative type codes and mnemonics for SIG, NXT > > and KEY. > > Not obvious to me why one would need to change SIG and KEY here. One doesn't. NXT would be sufficient. Johan -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 5 14:21:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07224 for ; Wed, 5 Feb 2003 14:21:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gUzY-0005nv-00 for namedroppers-data@psg.com; Wed, 05 Feb 2003 11:13:52 -0800 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 18gUzQ-0005mx-00 for namedroppers@ops.ietf.org; Wed, 05 Feb 2003 11:13:44 -0800 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id F3B1918ED for ; Wed, 5 Feb 2003 14:13:30 -0500 (EST) Date: Wed, 05 Feb 2003 14:13:30 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration In-Reply-To: References: <200302051229.h15CTZof065277@givry.rennes.enst-bretagne.fr> User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030205191331.F3B1918ED@thrintun.hactrn.net> X-Spam-Status: No, hits=-1.0 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I think that Johan's analysis is correct. DHCP combined with DNS dynamic update already covers this space. Having sent far too much mail about IPv6 and DHCP to the ipng list in the past, I won't repeat all of that here, see the ipng list archives for details. Summary: with all due respect, most DHCP discussion in the IPv6 WG has been heavily influenced by well-meaning people who do not understand DHCP and are thus doomed to reinvent it. So, while I can live with this draft going forward as experimental if that's the DNSEXT WG consensus, I don't think it's necessary, and I don't support it. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 5 14:56:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08310 for ; Wed, 5 Feb 2003 14:56:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gVYZ-0007oi-00 for namedroppers-data@psg.com; Wed, 05 Feb 2003 11:50:03 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 18gVYV-0007o3-00 for namedroppers@ops.ietf.org; Wed, 05 Feb 2003 11:49:59 -0800 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 3DD07137F05; Wed, 5 Feb 2003 11:49:59 -0800 (PST) To: Johan Ihren Cc: Francis Dupont , =?iso-8859-1?q?=D3lafur?= Gudmundsson/DNSEXT co-chair , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration In-Reply-To: Message from Johan Ihren of "05 Feb 2003 19:18:36 +0100." Date: Wed, 05 Feb 2003 11:49:59 -0800 Message-ID: <63154.1044474599@shell.nominum.com> From: Jim Reid X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I agree wholeheartedly with Johan. If IPv6 devices need configuration data to locate things like DNS and NTP servers, they should use DHCP and not re-invent the wheel. If DHCPv6 does not meet those needs, it should be fixed. I suspect that even "plug and play" networks will require DHCP too. There doesn't seem to be much point having a network that's totally isolated from the internet. [The chances are than even in those unconnected networks -- say my mother's house -- there will be some smart device like a video recorder that would have a simple DHCP server embedded in it. My $400 AirPort base station has a DHCP server and it's been simple to set up and even simpler to look after.] And anyway a DHCP based solution is likely to be much cleaner than an ever-increasing bunch of discovery protocols to find out how many lightbulbs or whatever are on some local IPv6 subnet. This draft should die in dnsext and go to dhc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 5 16:06:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10782 for ; Wed, 5 Feb 2003 16:06:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gWYp-000Bfj-00 for namedroppers-data@psg.com; Wed, 05 Feb 2003 12:54:23 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 18gWYm-000BfX-00 for namedroppers@ops.ietf.org; Wed, 05 Feb 2003 12:54:20 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18gWUt-0002ls-00; Wed, 05 Feb 2003 15:50:19 -0500 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Rob Austein Cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration References: <200302051229.h15CTZof065277@givry.rennes.enst-bretagne.fr> <20030205191331.F3B1918ED@thrintun.hactrn.net> Message-Id: Date: Wed, 05 Feb 2003 15:50:19 -0500 X-Spam-Status: No, hits=-0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Having sent far too much mail about IPv6 and DHCP to the ipng list in > the past, I won't repeat all of that here, see the ipng list archives > for details. Summary: with all due respect, most DHCP discussion in > the IPv6 WG has been heavily influenced by well-meaning people who do > not understand DHCP and are thus doomed to reinvent it. > > So, while I can live with this draft going forward as experimental if > that's the DNSEXT WG consensus, I don't think it's necessary, and I > don't support it. up a few thousand meters there is a dichotomy between server-based resource discovery, e.g., dhcp, and distributed service discovery, where the services announce themselves or are discovered by non-centralized means. the dchp-based approach has been deployed for some time, enhanced, and is generally well-understood. the distributed approach is less explored and well-documented. various bits of it keep rising, most especially in the ipv6 world. the problem is there has never been a coherent architecture of the distributed approach, heck not even a picture or diagram of how it all fits together. so we get ad hoc pieces and no way to judge how they all fit together, whether they are complete, etc. imiho, unless and until we get a sufficient coherent picture of distributed discovery with all the services explained, the pieces that float up should be treated politely, but put aside as experimental at best. until the distributed architecture is well described and well understood, the dhcp approach is well understood, well documented, and well deployed. 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. archive: From owner-namedroppers@ops.ietf.org Wed Feb 5 16:26:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11416 for ; Wed, 5 Feb 2003 16:26:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gWvf-000DGb-00 for namedroppers-data@psg.com; Wed, 05 Feb 2003 13:17:59 -0800 Received: from rtp-msg-core-1.cisco.com ([161.44.11.97]) by psg.com with esmtp (Exim 3.36 #1) id 18gWvd-000DGL-00 for namedroppers@ops.ietf.org; Wed, 05 Feb 2003 13:17:57 -0800 Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h15LIlUo000602; Wed, 5 Feb 2003 16:18:47 -0500 (EST) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-75.cisco.com [161.44.150.75]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA12487; Wed, 5 Feb 2003 16:17:53 -0500 (EST) Message-Id: <4.3.2.7.2.20030205160932.051c5948@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 05 Feb 2003 16:17:49 -0500 To: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org From: Ralph Droms Subject: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=0.5 required=5.0 tests=SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This message announces a WG last call on "DNS Configuration options for DHCPv6" . The last call will conclude on Friday, 2/21. Note that this is a parallel WG last call in the dhc, ipv6 and dnsext WGs. draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt describes two options for DHCPv6: the Domain Name Server option and the Domain Search List option. This document is being considered for Proposed Standard as an extension to the base DHCPv6 specification, and is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt - Ralph Droms -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 5 16:31:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11692 for ; Wed, 5 Feb 2003 16:31:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gX5V-000Dtt-00 for namedroppers-data@psg.com; Wed, 05 Feb 2003 13:28:09 -0800 Received: from mx03.covadmail.net ([63.65.120.63] helo=smtp.covadmail.net) by psg.com with smtp (Exim 3.36 #1) id 18gX5R-000Dsy-00 for namedroppers@ops.ietf.org; Wed, 05 Feb 2003 13:28:05 -0800 Received: (covad.net 14349 invoked from network); 5 Feb 2003 21:28:04 -0000 Received: from unknown (HELO STUDY) (66.166.57.89) by sun-qmail12 with SMTP; 5 Feb 2003 21:28:04 -0000 To: Randy Bush Cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration References: <200302051229.h15CTZof065277@givry.rennes.enst-bretagne.fr> <20030205191331.F3B1918ED@thrintun.hactrn.net> From: Scott Lawrence Date: 05 Feb 2003 16:27:57 -0500 In-Reply-To: Message-ID: Lines: 22 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-1.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, RCVD_IN_UNCONFIRMED_DSBL,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_GNUS_UA version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Randy Bush writes: > > > > imiho, unless and until we get a sufficient coherent picture of > distributed discovery with all the services explained, the pieces > that float up should be treated politely, but put aside as > experimental at best. As someone who's been interested in and working with a few different discovery schemes for some time, I appreciate your inclusion of 'politely'; that has, regretably, not always been the case in some IETF discussions. I would also like to remind everyone concerned that the Internet family of protocols was not developed by developing them from a "coherent picture [...] with all the services explained". There's nothing wrong with the Experimental status; it should not be considered a dead end into which rejected ideas are shunted. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 5 16:51:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12323 for ; Wed, 5 Feb 2003 16:51:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gXP3-000FKZ-00 for namedroppers-data@psg.com; Wed, 05 Feb 2003 13:48:21 -0800 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 18gXP0-000FKJ-00; Wed, 05 Feb 2003 13:48:18 -0800 Received: from nominum.com (dsl093-187-100.chi2.dsl.speakeasy.net [66.93.187.100]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h15Lm8P20904; Wed, 5 Feb 2003 15:48:09 -0600 (CST) Date: Wed, 5 Feb 2003 15:48:12 -0600 Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Randy Bush , namedroppers@ops.ietf.org To: Scott Lawrence From: Ted Lemon In-Reply-To: Message-Id: <864DCEA9-3953-11D7-A2AE-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > There's > nothing wrong with the Experimental status; it should not be > considered a dead end into which rejected ideas are shunted. Hear, hear! -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 6 04:30:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09818 for ; Thu, 6 Feb 2003 04:30:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18giDB-0009j9-00 for namedroppers-data@psg.com; Thu, 06 Feb 2003 01:20:49 -0800 Received: from tyo201.gate.nec.co.jp ([210.143.35.51]) by psg.com with esmtp (Exim 3.36 #1) id 18giD8-0009iu-00 for namedroppers@ops.ietf.org; Thu, 06 Feb 2003 01:20:46 -0800 Received: from mailgate3.nec.co.jp ([10.7.69.194]) by TYO201.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id h169KSw00947; Thu, 6 Feb 2003 18:20:28 +0900 (JST) Received: from mailsv.nec.co.jp (mailgate51.nec.co.jp [10.7.69.190]) by mailgate3.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id h169KRi06306; Thu, 6 Feb 2003 18:20:27 +0900 (JST) Received: from dns02.netlab.nec.co.jp (dns02.netlab.nec.co.jp [10.17.225.2]) by mailsv.nec.co.jp (8.11.6/3.7W-MAILSV-NEC) with ESMTP id h169KMq25949; Thu, 6 Feb 2003 18:20:26 +0900 (JST) Received: from dns03.netlab.nec.co.jp (dns03.netlab.nec.co.jp [10.17.225.65]) by dns02.netlab.nec.co.jp (8.11.6/3.7W) with ESMTP id h169KMZ03899; Thu, 6 Feb 2003 18:20:22 +0900 (JST) Received: from potsdam.lab5.netlab.nec.co.jp (potsdam.lab5.netlab.nec.co.jp [10.17.226.96]) by dns03.netlab.nec.co.jp (8.11.6/3.7W) with ESMTP id h169KMW13712; Thu, 6 Feb 2003 18:20:22 +0900 (JST) Received: from localhost (localhost.lab5.netlab.nec.co.jp [127.0.0.1]) by potsdam.lab5.netlab.nec.co.jp (8.9.3/3.7W20020312HK) with ESMTP id SAA07054; Thu, 6 Feb 2003 18:20:21 +0900 (JST) To: namedroppers@ops.ietf.org Cc: ogud@ogud.com From: kitamura@da.jp.nec.com Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration In-Reply-To: <5.1.1.6.2.20030204144231.01e22c70@localhost> References: <5.1.1.6.2.20030204144231.01e22c70@localhost> X-Mailer: Mew version 1.94.2 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20030206182021K.kitamura@netlab.nec.co.jp> Date: Thu, 06 Feb 2003 18:20:21 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 80 X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > This document defines a mechanism to register IPv6 auto configuration in DNS. > This document does not change the DNS protocol in any way or add new > requirements for DNS servers or resolvers. > > This document is on experimental track and is available via following URL: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ipv6-name-auto-reg-00.txt I think most people are missing some important points which described in this document. 1. This document provides GOOD NEWS to administrators of DNS servers. Most administrators of DNS servers are meeting problems how to collect IPv6 address information that should be registered to the DNS and how to prepare IPv6 address Data Base files for DNS servers. Especially, IPv6 addresses are too long to remember and EUI64-based addresses are too complicated to remember. Collecting such IPv6 address information by hand is a terribly hard work. By using proposed mechanism, such IPv6 address information is collected automatically. Since the mechanism has intelligent candidates check functions, only IPv6 address information that should be registered is collected (there are no noise). # Dynamic Update in the DNS is a final procedure of the mechanism. Under some situations, Dynamic Update can be omitted. Namely, this mechanism can be used only for the IPv6 addresses collection. Administrators of DNS servers can used the collected data for the hints to prepare IPv6 address Data Base files for DNS servers. This usage helps administrators of DNS servers very much. 2. This document is on experimental track (not standard track) This information helps people. At least, administrators of DNS servers will become happy with this information. 3. This document provides a solution that can be used right now. This is a current applicable solution (not future solution). This mechanism can be introduced without modifying the existing DNS nor other IPv6 related implementations. This mechanism is highly modularized, it dose not cause any bad effects to other current existing mechanisms. Only sites which introduced this mechanism can get rewards. Introduce or not introduce is decided by sites' policies. 4. This mechanism is based on detecting DAD (Duplicate Address Detection) packets. So, the mechanism does not care about IPv6 address setting methods to nodes (by DHCPv6 or IPv6 Stateless Address Autoconfiguration [RFC2462] etc.). Only DAD packets are issued, the mechanism works under such situations. 5. This document do NOT prevent a future DHCPv6-based solution. DAD detection based solution and DHCPv6-based solution are NOT alternative. Please reconsider above issues. Regards, Hiroshi -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 6 04:34:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09894 for ; Thu, 6 Feb 2003 04:34:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18giL0-0009vr-00 for namedroppers-data@psg.com; Thu, 06 Feb 2003 01:28:54 -0800 Received: from oban.autonomica.se ([192.71.80.69] helo=oban.autonomica.net) by psg.com with esmtp (Exim 3.36 #1) id 18giKy-0009vf-00 for namedroppers@ops.ietf.org; Thu, 06 Feb 2003 01:28:52 -0800 Received: by oban.autonomica.net (Postfix, from userid 501) id EDB8E11D8AD; Thu, 6 Feb 2003 09:25:01 +0100 (CET) To: JINMEI Tatuya / =?iso-2022-jp?b?GyRCP0BMQEMjOkgbKEI=?= Cc: Francis Dupont , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration References: <200302051229.h15CTZof065277@givry.rennes.enst-bretagne.fr> From: Johan Ihren Date: 06 Feb 2003 09:25:00 +0100 In-Reply-To: Message-ID: Lines: 29 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 MIME-Version: 1.0 Content-Type: text/plain; charset=euc-jp X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, REFERENCES,SPAM_PHRASE_01_02,USER_AGENT,USER_AGENT_GNUS_UA version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA09894 JINMEI Tatuya / żŔĚŔĂŁşČ writes: Hi Jinmei, > >> I think this is a really bad idea that would be much better solved by > >> a combination of DHCPv6 and dynamic updates. > > Please let me make it sure. Could you be more specific about "a > combination of DHCPv6 (and dynamic updates)"? For what purpose are > you intending to use DHCPv6? I see two individual problems: 1. The device (according to the draft) has a problem knowing its FQDN. DHCP will happily supply that information. 2. The device has a problem establishing a trust relationship with the nameserver maintaining the reverse zone the allocated address resides in. DHCP will assist with this, since it already has such a relationship (or at least can be configured to have that). Regards, Johan -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 6 06:34:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13904 for ; Thu, 6 Feb 2003 06:34:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gkD2-000Dwz-00 for namedroppers-data@psg.com; Thu, 06 Feb 2003 03:28:48 -0800 Received: from oban.autonomica.se ([192.71.80.69] helo=oban.autonomica.net) by psg.com with esmtp (Exim 3.36 #1) id 18gkCw-000Dwl-00 for namedroppers@ops.ietf.org; Thu, 06 Feb 2003 03:28:42 -0800 Received: by oban.autonomica.net (Postfix, from userid 501) id 6734C11D922; Thu, 6 Feb 2003 12:28:42 +0100 (CET) To: Randy Bush Cc: Rob Austein , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration References: <200302051229.h15CTZof065277@givry.rennes.enst-bretagne.fr> <20030205191331.F3B1918ED@thrintun.hactrn.net> From: Johan Ihren Date: 06 Feb 2003 12:28:41 +0100 In-Reply-To: Message-ID: Lines: 68 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-1.8 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, REFERENCES,SPAM_PHRASE_03_05,USER_AGENT,USER_AGENT_GNUS_UA version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Randy Bush writes: Hi Randy, > there is a dichotomy between server-based resource discovery, > e.g., dhcp, and distributed service discovery, where the services > announce themselves or are discovered by non-centralized means. > > the dchp-based approach has been deployed for some time, enhanced, > and is generally well-understood. > > the distributed approach is less explored and well-documented. > various bits of it keep rising, most especially in the ipv6 world. > > the problem is there has never been a coherent architecture of the > distributed approach, heck not even a picture or diagram of how it > all fits together. so we get ad hoc pieces and no way to judge > how they all fit together, whether they are complete, etc. I think this is wrong for two reasons. One: this is about *discovery*. Discovery protocols are a special case, requiring special care, since they will typically have to be encoded into zillions of end devices, including the fabled v6 enabled light bulbs. Keeping an open ended definition of what should be encoded in end devices to enable discovery seems to be a really Bad Idea. Ideally there should be exactly one "bootstrapping" protocol (i.e. DHCP in v4), but we already blew that for v6 since apparently RS/RA isn't enough (no surprise). So perhaps we need two protocols, but in that case the second one (RS/RA being the first) should be generic enough to avoid the need for a third, and a fourth, and a .... DHCPv6 fits this bill rather neatly. Two: this is not about *distributed* service discovery, this is by definition about *local* discovery. The situation is that a v6 device is present on a particular physical link and doesn't know where to go for support. You take your v6 light bulb out for a spin on the water and find this new cable that you've never visited before. What do you do? You shouldn't just sail into the harbor, wildly firing all kinds of discovery bullets on various ports. Instead, just go and see the harbormaster and he'll tell you where the showers are. For every cable there should be at most one harbormaster. Having none is called "ad hoc". Having more than one is called "mistake". > imiho, unless and until we get a sufficient coherent picture of > distributed discovery with all the services explained, the pieces > that float up should be treated politely, but put aside as > experimental at best. until the distributed architecture is well > described and well understood, the dhcp approach is well > understood, well documented, and well deployed. Polite is good. We like that. However not speaking up when something is wrong is not being polite, it is being overly passive. We all know that it is important to do house cleaning because otherwise we will suffocate under the burden of our collective bad ideas. Johan -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 6 06:58:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14650 for ; Thu, 6 Feb 2003 06:58:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gkb3-000EvX-00 for namedroppers-data@psg.com; Thu, 06 Feb 2003 03:53:37 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 18gkb1-000EvL-00 for namedroppers@ops.ietf.org; Thu, 06 Feb 2003 03:53:35 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18gkXa-0004YG-00 for namedroppers@ops.ietf.org; Thu, 06 Feb 2003 06:50:02 -0500 In-Reply-To: <4.3.2.7.2.20030205160932.051c5948@funnel.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Thu, 6 Feb 2003 11:00:38 +0200 (EET) From: Pekka Savola To: Ralph Droms cc: dhcwg@ietf.org, , Subject: Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt X-Spam-Status: No, hits=-1.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RESENT_TO, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] On Wed, 5 Feb 2003, Ralph Droms wrote: > DHCPv6" . The last call will > conclude on Friday, 2/21. > > Note that this is a parallel WG last call in the dhc, ipv6 and dnsext WGs. > > draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt describes two options for > DHCPv6: the Domain Name Server option and the Domain Search List option. > This document is being considered for Proposed Standard as an extension > to the base DHCPv6 specification, and is available as > http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt A few comments; I haven't looked too deep into DHCPv6 to be able to comment on those parts, but there are some definite need for revisal in the doc..: 2. Requirements The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, [...] ==> I'd put these under Introduction or Terminology sections, no use having a separate section with a questionable title. option-length: Length of the 'options' field in octets; must be a multiple of 16 ==> 'options' field has not been defined. Is it the whole option or just the length of DNS-server address options (I assume so)? If the former, there must be 32 bits of zero padding. Is it ok that the options aren't 64-bit aligned? The list of domain names in the 'searchstring' MUST be encoded as specified in section "Representation and use of domain names" of the DHCPv6 specification [4]. ==> I didn't bother to check, but I guess this document also defines how to pad the names to get some desired level of alignment? 6. Appearance of these options The Domain Name Server option MUST appear only in the following messages: Solicit, Advertise, Request, Confirm, Renew, Rebind, Information-Request, Reply. The Domain Search List option MUST appear only in the following messages: Solicit, Advertise, Request, Confirm, Renew, Rebind, Information-Request, Reply. ==> I would reword these differently, like: The Domain Name Server option MUST NOT appear in other than the following messages: .... ==> is it ok to server to give only one of these options but not the other? References ==> split the references [4] Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and R. Droms (ed.), "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", draft-ietf-dhc-dhcpv6-23 (work in progress), February 2002. ==> update this draft version Author's Address Ralph Droms (ed.) ==> the author is an editor, but the draft does not have acknowledgements or contributors section. Just remove Editor if nobody else contributed to the document. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 6 08:19:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17012 for ; Thu, 6 Feb 2003 08:19:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gls5-000IPN-00 for namedroppers-data@psg.com; Thu, 06 Feb 2003 05:15:17 -0800 Received: from [3ffe:501:100f:0:200:f8ff:fe01:61cf] (helo=shuttle.wide.toshiba.co.jp) by psg.com with esmtp (Exim 3.36 #1) id 18gls4-000IPB-00 for namedroppers@ops.ietf.org; Thu, 06 Feb 2003 05:15:16 -0800 Received: from localhost ([3ffe:501:4819:2000:61fd:54c6:2303:b850]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id h16DF1P02250; Thu, 6 Feb 2003 22:15:01 +0900 (JST) Date: Thu, 06 Feb 2003 22:14:59 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Johan Ihren Cc: Francis Dupont , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration In-Reply-To: References: <200302051229.h15CTZof065277@givry.rennes.enst-bretagne.fr> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 26 X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_02_03,USER_AGENT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> On 06 Feb 2003 09:25:00 +0100, >>>>> Johan Ihren said: >> >> I think this is a really bad idea that would be much better solved by >> >> a combination of DHCPv6 and dynamic updates. >> >> Please let me make it sure. Could you be more specific about "a >> combination of DHCPv6 (and dynamic updates)"? For what purpose are >> you intending to use DHCPv6? > I see two individual problems: > 1. The device (according to the draft) has a problem knowing its > FQDN. > DHCP will happily supply that information. Okay, then are you also assuming the DHCPv6 server assigns the IPv6 address(es) of the client? Or are you thinking of some registration mechanism from the client (that configures its address(es) in a stateless manner) to the server? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.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. archive: From owner-namedroppers@ops.ietf.org Thu Feb 6 08:21:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17080 for ; Thu, 6 Feb 2003 08:21:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18glv9-000IXh-00 for namedroppers-data@psg.com; Thu, 06 Feb 2003 05:18:27 -0800 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by psg.com with esmtp (Exim 3.36 #1) id 18glv2-000IXQ-00 for namedroppers@ops.ietf.org; Thu, 06 Feb 2003 05:18:20 -0800 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id h16DIAh11936; Thu, 6 Feb 2003 14:18:10 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h16DGvof069471; Thu, 6 Feb 2003 14:16:57 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200302061316.h16DGvof069471@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Johan Ihren cc: =?iso-8859-1?q?=D3lafur?= Gudmundsson/DNSEXT co-chair , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration In-reply-to: Your message of 05 Feb 2003 19:18:36 +0100. Date: Thu, 06 Feb 2003 14:16:57 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=0.8 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_05_08 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In your previous mail you wrote: > => near 100% of current IPv6 networks don't use DHCPv6 for > address allocation, and most won't. Dynamic updates alone > are not easy to use, IMHO the basic idea of the IPv6 NAR draft > is a good one. But the question here is not if we believe it > is or not a good idea, it is if there is or is not enough interest... They don't use DHCPv6 since there (as far as I know) was a concious design decision made that it was not possible to rely on "infrastructure services" being available on every piece of cable (or air wave) that a v6 device would like to connect to. Which is fine. But you got what you asked for: no services. => no, we asked for no address allocation service, not for no services but in the address allocation is main function of DHCPv6... No DHCP server that can tell you about your FQDN, no trust relationship with the friendly nearby DNS infrastructure (that you get via DHCP and use for updating DNS). Nor will you get NTP clocks (available through DHCP), printers (guess) or the location of the local cola vending machine, etc, etc... => this is the DNS server discovery (or SLP server discovery), and *not* the issue addressed by the IPv6 NAR draft. DHCP for v6 is not primarily about address allocation (that is obviously not the major issue that it was forv4). DHCP is about a standardized mechanism for "newly connected" devices to locate stuff it has a need for (and possibly some stuff it doesn't care about). => I'd like you are right but DHCPv6 is not what you describe. Hmm. Wrong choice. This should clearly be sent to DHC ;-) => no, the DHC WG has only one idea: how to fix all the issues of DHCP in DHCPv6. The result is only few people still believe in DHCPv6 and major implementors already claimed they'll *never* implement the address allocation part of DHCPv6. Regards Francis.Dupont@enst-bretagne.fr -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 6 08:35:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17445 for ; Thu, 6 Feb 2003 08:35:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gm6N-000J7E-00 for namedroppers-data@psg.com; Thu, 06 Feb 2003 05:30:03 -0800 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by psg.com with esmtp (Exim 3.36 #1) id 18gm6H-000J6V-00 for namedroppers@ops.ietf.org; Thu, 06 Feb 2003 05:29:57 -0800 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id h16DTrh12453; Thu, 6 Feb 2003 14:29:53 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h16DSeof069567; Thu, 6 Feb 2003 14:28:41 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200302061328.h16DSeof069567@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Rob Austein cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration In-reply-to: Your message of Wed, 05 Feb 2003 14:13:30 EST. <20030205191331.F3B1918ED@thrintun.hactrn.net> Date: Thu, 06 Feb 2003 14:28:40 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In your previous mail you wrote: I think that Johan's analysis is correct. DHCP combined with DNS dynamic update already covers this space. => this is the case for IPv4 but not for IPv6 where the stateless auto-configuration is used in place of DHCPv6. Having sent far too much mail about IPv6 and DHCP to the ipng list in the past, I won't repeat all of that here, see the ipng list archives for details. Summary: with all due respect, most DHCP discussion in the IPv6 WG has been heavily influenced by well-meaning people who do not understand DHCP and are thus doomed to reinvent it. => the DHCP style of address allocation is not needed in IPv6 and IMHO it even doesn't make sense. DHPCv6 is not published yet when IPv6 networks exist for many years... Regards Francis.Dupont@enst-bretagne.fr -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 6 08:36:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17466 for ; Thu, 6 Feb 2003 08:36:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gm9F-000JGg-00 for namedroppers-data@psg.com; Thu, 06 Feb 2003 05:33:01 -0800 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by psg.com with esmtp (Exim 3.36 #1) id 18gm9C-000JGL-00 for namedroppers@ops.ietf.org; Thu, 06 Feb 2003 05:32:58 -0800 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id h16DWsh12504; Thu, 6 Feb 2003 14:32:54 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h16DVfof069596; Thu, 6 Feb 2003 14:31:42 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200302061331.h16DVfof069596@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jim Reid cc: Johan Ihren , =?iso-8859-1?q?=D3lafur?= Gudmundsson/DNSEXT co-chair , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration In-reply-to: Your message of Wed, 05 Feb 2003 11:49:59 PST. <63154.1044474599@shell.nominum.com> Date: Thu, 06 Feb 2003 14:31:41 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In your previous mail you wrote: I agree wholeheartedly with Johan. If IPv6 devices need configuration data to locate things like DNS and NTP servers, they should use DHCP and not re-invent the wheel... => please read the IPv6 Name Auto Registration draft! Francis.Dupont@enst-bretagne.fr -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 6 08:43:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17636 for ; Thu, 6 Feb 2003 08:43:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gmHY-000JjK-00 for namedroppers-data@psg.com; Thu, 06 Feb 2003 05:41:36 -0800 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by psg.com with esmtp (Exim 3.36 #1) id 18gmHW-000Jj0-00; Thu, 06 Feb 2003 05:41:34 -0800 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id h16DfSh12786; Thu, 6 Feb 2003 14:41:28 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h16DeGof069668; Thu, 6 Feb 2003 14:40:16 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200302061340.h16DeGof069668@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Randy Bush cc: Rob Austein , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration In-reply-to: Your message of Wed, 05 Feb 2003 15:50:19 EST. Date: Thu, 06 Feb 2003 14:40:16 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In your previous mail you wrote: there is a dichotomy between server-based resource discovery, e.g., dhcp, and distributed service discovery, where the services announce themselves or are discovered by non-centralized means. ... => please note that the IPv6 Name Auto Registration is *not* about resource discovery. Regards Francis.Dupont@enst-bretagne.fr PS: the draft is about a mechanism to replace the "+" in the standard DHCP+DDNS when DHCPv6 is not used for address allocation (as nearly everybody use the stateless auto-configuration in existing IPv6 networks and don't want to switch to something else, this "when" is the common 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. archive: From owner-namedroppers@ops.ietf.org Thu Feb 6 09:38:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19450 for ; Thu, 6 Feb 2003 09:38:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gn3x-000MCv-00 for namedroppers-data@psg.com; Thu, 06 Feb 2003 06:31:37 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 18gn3u-000MCj-00 for namedroppers@ops.ietf.org; Thu, 06 Feb 2003 06:31:34 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18817; Thu, 6 Feb 2003 09:27:54 -0500 (EST) Message-Id: <200302061427.JAA18817@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-intro-04.txt Date: Thu, 06 Feb 2003 09:27:54 -0500 X-Spam-Status: No, hits=4.6 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.43 X-Spam-Level: **** 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 Introduction and Requirements Author(s) : R. Arends, M. Larson, D. Massey, S. Rose Filename : draft-ietf-dnsext-dnssec-intro-04.txt Pages : 20 Date : 2003-2-5 The Domain Name System Security Extensions (DNSSEC) provide data origin authentication and data integrity. This document introduces these extensions and describes their capabilities and limitations. The services that the security extensions provide and do not provide are discussed. Lastly, the group of documents that describe the DNS security extensions and their interrelationships is discussed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-intro-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-intro-04.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-intro-04.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: <2003-2-5135926.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-intro-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-intro-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-5135926.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. archive: From owner-namedroppers@ops.ietf.org Thu Feb 6 09:39:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19483 for ; Thu, 6 Feb 2003 09:39:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gn3Z-000MAS-00 for namedroppers-data@psg.com; Thu, 06 Feb 2003 06:31:13 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 18gn3W-000MAG-00 for namedroppers@ops.ietf.org; Thu, 06 Feb 2003 06:31:10 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18795; Thu, 6 Feb 2003 09:27:31 -0500 (EST) Message-Id: <200302061427.JAA18795@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-07.txt Date: Thu, 06 Feb 2003 09:27:30 -0500 X-Spam-Status: No, hits=4.6 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.43 X-Spam-Level: **** 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-07.txt Pages : 16 Date : 2003-2-5 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-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-07.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-07.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: <2003-2-5135906.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-roadmap-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-roadmap-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-5135906.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. archive: From owner-namedroppers@ops.ietf.org Thu Feb 6 10:11:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20691 for ; Thu, 6 Feb 2003 10:11:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gndC-000OIX-00 for namedroppers-data@psg.com; Thu, 06 Feb 2003 07:08:02 -0800 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 18gnd9-000OHe-00 for namedroppers@ops.ietf.org; Thu, 06 Feb 2003 07:07:59 -0800 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h16F7Sn08907; Thu, 6 Feb 2003 22:07:28 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h16F6tb14448; Thu, 6 Feb 2003 22:06:59 +0700 (ICT) From: Robert Elz To: Johan Ihren cc: Francis Dupont , =?iso-8859-1?q?=D3lafur?= Gudmundsson/DNSEXT co-chair , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration In-Reply-To: References: <200302051229.h15CTZof065277@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 06 Feb 2003 22:06:55 +0700 Message-ID: <14446.1044544015@munnari.OZ.AU> X-Spam-Status: No, hits=-0.2 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_03_05 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: 05 Feb 2003 19:18:36 +0100 From: Johan Ihren Message-ID: Note, in the message below, please do not infer that I am disparaging the usefulness of DHCP. That is not the intent. However, I also do not believe that one can always require DHCP exist (especially not in IPv6 networks). | No DHCP server that can tell you about your FQDN, True, but in many cases, the node already knows that (my nodes certainly do, and when some DHCP server presumes to tell me different, I ignore it). | no trust relationship with the friendly nearby DNS infrastructure | (that you get via DHCP and use for updating DNS). When I first read your message, this one I thought to be an important point, but upon reflection, it isn't. It is certainly true that the DHCP server can have a trust relationship with the DNS server, but if the DHCP server is just going to blindly forward an update request, sent by some client, to the DNS server, then the DNS server may just as well have received it directly from the client - whatever trust was assumed to exist, is all cast away. For v4 things aren't quite as bad, as DHCP servers update the DNS only with addresses the DHCP server has assigned, so there is at least some general reason for believing the DHCP server there. But for v6, DHCP servers will almost never be actually assigning addresses, so the server is just believing the client, and then taking that (unsubstantiated) data and sending it to the DNS server. That doesn't sound good. The experiment proposed in this draft also has an entity (the registrar) that can form a trust relationship with the DNS server, and but it doesn't get its data from what some random client tells it, but from what another (trusted) agent (the detector) tells it from what it observes of the network. Personally I have my doubts that this can really work well - but what is being proposed is an experiment, discovering whether things do work or not is what experiments are all about, so I see no problem with doing it (nor with publishing the doc that tells people how). | Nor will you get NTP clocks | (available through DHCP), printers (guess) or the location of the | local cola vending machine, etc, etc... That's nonsense. DHCP isn't the only way to obtain that kind of information. And while it is sometimes the best way, when it is available, it isn't always going to work. And note - it isn't the availability of a DHCP server implementation that matters here, as has been pointed out, these days every matchstick seems to come complete with a (rudimentary) DHCP server inside it. What matters is collecting the data for the DHCP server to hand over to clients, and then keeping it up to date. On a well managed net, that's not too hard. On a (more or less) ad-hoc net, it is way too hard. If the DHCP server can somehow automate that, then clients can just copy its mechanism, and the DHCP server is redundant. If it can't, then you're requiring manual configuration. Nasty. | For a network *with* infrastructure services the rule is: | "Don't invent your own mechanism to locate stuff, use DHCP". I don't know where that rule came from. It is useful sometimes, but not always. But in any case, who says that the network where I'm currently connected (which may have little or no services) has anything to do with the network with the DNS server I want to update? | Anyway, the point wasn't to spur discussion about this but rather to | argue that it should die. There is no reason for that. I suspect that might be what will eventually happen, as (to me) it looks like an over-elaborate mechanism with too many problems left, but the way to find out that for sure, is to actually have people (in different environments) try it, and see whether or not it works. Certainly just falling back on "worship no others before DHCP" dogma isn't an appropriate response. 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. archive: From owner-namedroppers@ops.ietf.org Thu Feb 6 10:15:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20938 for ; Thu, 6 Feb 2003 10:15:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gnfK-000OSW-00 for namedroppers-data@psg.com; Thu, 06 Feb 2003 07:10:14 -0800 Received: from rtp-msg-core-1.cisco.com ([161.44.11.97]) by psg.com with esmtp (Exim 3.36 #1) id 18gnfH-000OSJ-00 for namedroppers@ops.ietf.org; Thu, 06 Feb 2003 07:10:11 -0800 Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h16FB3Wu026982 for ; Thu, 6 Feb 2003 10:11:03 -0500 (EST) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-75.cisco.com [161.44.150.75]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA05119 for ; Thu, 6 Feb 2003 10:10:09 -0500 (EST) Message-Id: <4.3.2.7.2.20030206100033.00b94208@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 06 Feb 2003 10:10:05 -0500 To: namedroppers@ops.ietf.org From: Ralph Droms Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration In-Reply-To: <200302061328.h16DSeof069567@givry.rennes.enst-bretagne.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-0.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, TO_BE_REMOVED_REPLY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Francis, At this point I must take exception with some of your recent statements about DHCPv6. DHCPv6 has been accepted as a proposed standard and is in the RFC Editor queue for publication. DHCPv6 is not just for address allocation. "Stateless" DHCPv6, or DHCPv6-lite, is an integral part of the specification and guidelines for implementation are published as an I-D. Stateless DHCPv6 ([opinion] which will be widely used for DNS configuration) can be used with DDNS for autoregistration of nodes that are incapable of registering themselves. Cisco has an implementation of stateless DHCPv6 that can be used without address assignment; that implementation is almost trivial (it must be; I contributed to the implementation and I have a PhD in CS). We successfully demonstrated DHCPv6 interoperability at TAHI last month and will test other implementations at Connectathon next month. We have a published spec for DHCPv6, running code and proven interoperability of independent implementations. - Ralph At 02:28 PM 2/6/2003 +0100, Francis Dupont wrote: > In your previous mail you wrote: > > I think that Johan's analysis is correct. DHCP combined with DNS > dynamic update already covers this space. > >=> this is the case for IPv4 but not for IPv6 where the stateless >auto-configuration is used in place of DHCPv6. > > Having sent far too much mail about IPv6 and DHCP to the ipng list in > the past, I won't repeat all of that here, see the ipng list archives > for details. Summary: with all due respect, most DHCP discussion in > the IPv6 WG has been heavily influenced by well-meaning people who do > not understand DHCP and are thus doomed to reinvent it. > >=> the DHCP style of address allocation is not needed in IPv6 and >IMHO it even doesn't make sense. DHPCv6 is not published yet >when IPv6 networks exist for many years... > >Regards > >Francis.Dupont@enst-bretagne.fr > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 6 10:18:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21080 for ; Thu, 6 Feb 2003 10:18:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gnjp-000Oed-00 for namedroppers-data@psg.com; Thu, 06 Feb 2003 07:14:53 -0800 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by psg.com with esmtp (Exim 3.36 #1) id 18gnjm-000OeK-00 for namedroppers@ops.ietf.org; Thu, 06 Feb 2003 07:14:50 -0800 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id h16FEkh19331; Thu, 6 Feb 2003 16:14:46 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h16FDXof070336; Thu, 6 Feb 2003 16:13:33 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200302061513.h16FDXof070336@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Johan Ihren cc: JINMEI Tatuya / =?iso-2022-jp?b?GyRCP0BMQEMjOkgbKEI=?= , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration In-reply-to: Your message of 06 Feb 2003 09:25:00 +0100. Date: Thu, 06 Feb 2003 16:13:33 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In your previous mail you wrote: I see two individual problems: => can you rephrase this with the assumption the address was NOT allocated by DHCP? 1. The device (according to the draft) has a problem knowing its FQDN. DHCP will happily supply that information. 2. The device has a problem establishing a trust relationship with the nameserver maintaining the reverse zone the allocated address resides in. DHCP will assist with this, since it already has such a relationship (or at least can be configured to have that). Regards Francis.Dupont@enst-bretagne.fr -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 6 10:30:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22175 for ; Thu, 6 Feb 2003 10:30:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gnsn-000PHp-00 for namedroppers-data@psg.com; Thu, 06 Feb 2003 07:24:09 -0800 Received: from rtp-msg-core-1.cisco.com ([161.44.11.97]) by psg.com with esmtp (Exim 3.36 #1) id 18gnsk-000PGa-00 for namedroppers@ops.ietf.org; Thu, 06 Feb 2003 07:24:06 -0800 Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h16FOvsr029098 for ; Thu, 6 Feb 2003 10:24:58 -0500 (EST) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-75.cisco.com [161.44.150.75]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA06167 for ; Thu, 6 Feb 2003 10:24:04 -0500 (EST) Message-Id: <4.3.2.7.2.20030206102242.00b93940@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 06 Feb 2003 10:24:01 -0500 To: namedroppers@ops.ietf.org From: Ralph Droms Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration In-Reply-To: References: <200302051229.h15CTZof065277@givry.rennes.enst-bretagne.fr> <20030205191331.F3B1918ED@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-2.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk What he said (far more concisely and elegantly than I ever could)... - Ralph At 03:50 PM 2/5/2003 -0500, Randy Bush wrote: >up a few thousand meters > >there is a dichotomy between server-based resource discovery, >e.g., dhcp, and distributed service discovery, where the services >announce themselves or are discovered by non-centralized means. > >the dchp-based approach has been deployed for some time, enhanced, >and is generally well-understood. > >the distributed approach is less explored and well-documented. >various bits of it keep rising, most especially in the ipv6 world. > >the problem is there has never been a coherent architecture of the >distributed approach, heck not even a picture or diagram of how it >all fits together. so we get ad hoc pieces and no way to judge >how they all fit together, whether they are complete, etc. > > > > >imiho, unless and until we get a sufficient coherent picture of >distributed discovery with all the services explained, the pieces >that float up should be treated politely, but put aside as >experimental at best. until the distributed architecture is well >described and well understood, the dhcp approach is well >understood, well documented, and well deployed. > >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. archive: From owner-namedroppers@ops.ietf.org Thu Feb 6 11:21:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24370 for ; Thu, 6 Feb 2003 11:21:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gohx-0002Il-00 for namedroppers-data@psg.com; Thu, 06 Feb 2003 08:17:01 -0800 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by psg.com with esmtp (Exim 3.36 #1) id 18gohv-0002IZ-00 for namedroppers@ops.ietf.org; Thu, 06 Feb 2003 08:16:59 -0800 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id h16GGsh21069; Thu, 6 Feb 2003 17:16:54 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h16GFfof070918; Thu, 6 Feb 2003 17:15:41 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200302061615.h16GFfof070918@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Ralph Droms cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration In-reply-to: Your message of Thu, 06 Feb 2003 10:10:05 EST. <4.3.2.7.2.20030206100033.00b94208@funnel.cisco.com> Date: Thu, 06 Feb 2003 17:15:41 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In your previous mail you wrote: DHCPv6 has been accepted as a proposed standard and is in the RFC Editor queue for publication. => so it is not today published as a RFC, i.e., we don't have a published spec, we have a to be published soon spec (this discussion should make it magically publish in some hours :-). DHCPv6 is not just for address allocation. "Stateless" DHCPv6, or DHCPv6-lite, is an integral part of the specification and guidelines for implementation are published as an I-D. Stateless DHCPv6 ([opinion] which will be widely used for DNS configuration) can be used with DDNS for autoregistration of nodes that are incapable of registering themselves. => I disagree about the level of help/assistance DHCPv6-Lite can give for the DDNS autoregistration because the real issue is the security issue (DDNS without security is not usable) and as the addresses are not allocated by DHCPv6 the standard assumption that DHCP allocates the addresses so has the authority at least on the PTR RRs is no more true (this is a part of the "+" in DHCP+DDNS). Robert Elz' message gives a good description of this issue. Regards Francis.Dupont@enst-bretagne.fr PS: I have a real problem to solve: - to manage by hand the DNS zones is not a good solution - DDNS startup scripts don't work well because of the security pb and of the difference of nature between address management and RR management (which gives years of DHCP/DNS interaction drafts) - etc. So even if the IPv6 NAR draft is far to be perfect, it is the beginning of a solution and I wouldn't like to see further works on it stopped (i.e., I support it as a WG document). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 6 11:35:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25042 for ; Thu, 6 Feb 2003 11:35:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18govW-00036a-00 for namedroppers-data@psg.com; Thu, 06 Feb 2003 08:31:02 -0800 Received: from rtp-msg-core-1.cisco.com ([161.44.11.97]) by psg.com with esmtp (Exim 3.36 #1) id 18govU-00036M-00 for namedroppers@ops.ietf.org; Thu, 06 Feb 2003 08:31:00 -0800 Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h16GVmLZ009991 for ; Thu, 6 Feb 2003 11:31:49 -0500 (EST) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-75.cisco.com [161.44.150.75]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA11394 for ; Thu, 6 Feb 2003 11:30:55 -0500 (EST) Message-Id: <4.3.2.7.2.20030206113001.00b974e8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 06 Feb 2003 11:30:51 -0500 To: namedroppers@ops.ietf.org From: Ralph Droms Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration In-Reply-To: <5.1.1.6.2.20030204144231.01e22c70@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=0.3 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_03_05 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I do not support the publication of this specification on experimental track, for the following reasons: What, exactly, is being standardized as an experimental protocol in this document; why is the IETF publishing it? The detector function is a set of heuristics which may be of use in detecting newly connected nodes, but it's not a protocol. The detector<->registrar communication is only described as an example in Appendix A. The registrar then uses DDNS to change the information in DNS. The registrar function is a set of rules for generating names for nodes and for managing information about nodes. What is the protocol that must be standardized for interoperability among different implementations? I don't understand the motivation for registering the information collected by this mechanism. Registering a binding between a name and an address assigned to a device is of no value unless that name is known to the entities that want to interact with the device. My newly connected device is assigned the FQDN 00-03-47-0F-2D-44.example.com, that name is useless unless I can somehow discover it and use it elsewhere. Similarly, what is the "IP address information that should be registered in the DNS"? The information should go in the DNS only if it's used as part of a name-address binding. If the name is generated automatically and isn't a name chosen to be associated with a device, it's useless. How do independent Registrars cooperate to resolve name conflicts? (This is an issue we've spent a lot of time trying to resolve in DHCP-DDNS interaction.) Suppose I connect a device that indicates a preference of "joe.example.com" that is registered by Registrar R1, and you connect a device that also indicated a preference of "joe.example.com" that is registered by Registrar R2. Which device is assigned joe.example.com, and how does the network administrator control the resolution process? - Ralph -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 6 12:27:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26920 for ; Thu, 6 Feb 2003 12:27:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gpg3-0005qa-00 for namedroppers-data@psg.com; Thu, 06 Feb 2003 09:19:07 -0800 Received: from [3ffe:501:100f:0:200:f8ff:fe01:61cf] (helo=shuttle.wide.toshiba.co.jp) by psg.com with esmtp (Exim 3.36 #1) id 18gpfq-0005oj-00 for namedroppers@ops.ietf.org; Thu, 06 Feb 2003 09:18:54 -0800 Received: from localhost ([3ffe:501:100f:f::6]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id h16H9xP05088; Fri, 7 Feb 2003 02:09:59 +0900 (JST) Date: Fri, 07 Feb 2003 02:09:52 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Robert Elz Cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration In-Reply-To: <14446.1044544015@munnari.OZ.AU> References: <200302051229.h15CTZof065277@givry.rennes.enst-bretagne.fr> <14446.1044544015@munnari.OZ.AU> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 20 X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> On Thu, 06 Feb 2003 22:06:55 +0700, >>>>> Robert Elz said: > Note, in the message below, please do not infer that I am disparaging the > usefulness of DHCP. That is not the intent. However, I also do not > believe that one can always require DHCP exist (especially not in IPv6 > networks). ... Excellent points, so can we stop using DHCPv6 as an excuse to deny the draft and concentrate on the proposal itself? (The latest message from Ralph would be a good restart of the discussion.) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.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. archive: From owner-namedroppers@ops.ietf.org Thu Feb 6 16:38:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05285 for ; Thu, 6 Feb 2003 16:38:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gtWB-000LYc-00 for namedroppers-data@psg.com; Thu, 06 Feb 2003 13:25:11 -0800 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #1) id 18gtW9-000LYO-00; Thu, 06 Feb 2003 13:25:09 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA18159; Thu, 6 Feb 2003 14:25:07 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h16LP2P22124; Thu, 6 Feb 2003 22:25:02 +0100 (MET) Date: Thu, 6 Feb 2003 22:21:25 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: draft-ietf-dnsext-unknown-rrs-04.txt To: ogud@ogud.com, randy@psg.com Cc: namedroppers@ops.ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I've done the AD review of this document and I have some questions. To avoid such corruption, servers MUST NOT compress domain names embedded in the RDATA of types that are class-specific or not well- known. This requirement was stated in RFC1123 without defining the term "well-known"; it is hereby specified that only the RR types defined in RFC1035 are to be considered "well-known". The above seems to change the current standard behavior for SIG, NXT, and perhaps others. Is this the intent? If so the document should explicitly state this and also add an "updates RFC 2535" up front. (It also needs an "updates RFC 1035" up front but that is just an editorial nit). For all other RR types, the canonical form is hereby changed such that no downcasing of embedded domain names takes place. The owner name is always set to lower case according to the DNS rules for character comparisons, regardless of the RR type. It would be useful to explicitly list the RR types to which this change applies. Nits (by themselves not necessitating an updated I-D at this point in time): The references should be split into normative and non-normative. A boilerplate IPR section should be added. (I haven't explicitly checked against the ID-nits page to see if there are others.) 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. archive: From owner-namedroppers@ops.ietf.org Thu Feb 6 16:55:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06092 for ; Thu, 6 Feb 2003 16:55:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gttv-000NTG-00 for namedroppers-data@psg.com; Thu, 06 Feb 2003 13:49:43 -0800 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 18gttr-000NSy-00 for namedroppers@ops.ietf.org; Thu, 06 Feb 2003 13:49:39 -0800 Received: from nominum.com (dsl093-187-100.chi2.dsl.speakeasy.net [66.93.187.100]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h16Ln9P02750; Thu, 6 Feb 2003 15:49:09 -0600 (CST) Date: Thu, 6 Feb 2003 15:49:25 -0600 Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Johan Ihren , Francis Dupont , namedroppers@ops.ietf.org To: =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= From: Ted Lemon In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Okay, then are you also assuming the DHCPv6 server assigns the IPv6 > address(es) of the client? Or are you thinking of some registration > mechanism from the client (that configures its address(es) in a > stateless manner) to the server? The way that was proposed in the DHC working group to solve this problem was to update the PTR record in the DNS on receipt of the DHCP Information Request packet. I think the question of the client knowing its domain name is overstated - if it's going to update the DNS itself, it knows its domain name. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 6 16:59:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06218 for ; Thu, 6 Feb 2003 16:59:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gtw1-000Ne6-00 for namedroppers-data@psg.com; Thu, 06 Feb 2003 13:51:53 -0800 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 18gtvy-000Nd1-00 for namedroppers@ops.ietf.org; Thu, 06 Feb 2003 13:51:50 -0800 Received: from nominum.com (dsl093-187-100.chi2.dsl.speakeasy.net [66.93.187.100]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h16LpUP02771; Thu, 6 Feb 2003 15:51:30 -0600 (CST) Date: Thu, 6 Feb 2003 15:51:46 -0600 Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Johan Ihren , =?ISO-8859-1?Q?=D3lafur_Gudmundsson/DNSEXT_co-chair?= , namedroppers@ops.ietf.org To: Francis Dupont From: Ted Lemon In-Reply-To: <200302061316.h16DGvof069471@givry.rennes.enst-bretagne.fr> Message-Id: <303F2CC5-3A1D-11D7-A2AE-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > no, we asked for no address allocation service, not for no services > but in the address allocation is main function of DHCPv6... Address allocation is _not_ the main function of DHCPv6. It is one of the *two* main functions of DHCPv6. The other main function of DHCPv6 is network configuration/resource discovery - that is, what are the local constants, and what are the local services? DHCPv6 works fine if you just use it for the second of the two functions. There was a recent interoperability test where only this functionality was tested, and it apparently did quite nicely (I wasn't there). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 6 17:52:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07653 for ; Thu, 6 Feb 2003 17:52:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18guof-0001bY-00 for namedroppers-data@psg.com; Thu, 06 Feb 2003 14:48:21 -0800 Received: from [2001:4f8:3:bb:2e0:81ff:fe23:7b5a] (helo=as.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 18guoc-0001Zi-00 for namedroppers@ops.ietf.org; Thu, 06 Feb 2003 14:48:18 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 18349379EF5; Thu, 6 Feb 2003 22:48:05 +0000 (GMT) From: Paul Vixie To: Ted Lemon Cc: =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= , Johan Ihren , Francis Dupont , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration In-Reply-To: Message from Ted Lemon of "Thu, 06 Feb 2003 15:49:25 CST." X-Mailer: MH-E 7.2; nmh 1.0.4; GNU Emacs 21.2.1 Date: Thu, 06 Feb 2003 22:48:05 +0000 Message-Id: <20030206224805.18349379EF5@as.vix.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk this seemingly interminable thread may actually be ready to shed some light. i am no fan of dhcp. isc's implementation (mostly written by ted lemon, to whom i am apparently but accidentally replying) is excellent, but the client side (mostly windows and mac) has taken a terrible toll on resources. just this morning a client was once again stuck and only a release/renew cycle made it work again. as a distributed system (sorry johan, you missed the reference, a distributed system is anything limited to message passing and possessing asynchrony, so a dhcp server + its clients definitely qualifies) dhcp in practice is just terrible. compared to dhcp, the ipv6 autoconf ("EUI64") is wonderful. since it is stateless, there's no opportunity for the client to disagree with the server or with other clients what the state currently is. Hashing Is Your Friend. all i personally need is a working dns-update strategy based on ipv6 autoconf. this involves two changes: (1) a hook on the client side so i can update the A and PTR following a successful autoconf (and again, just before shutdown); (2) syntactic sugar in the dns server so that any host is allowed to update (using tcp, not udp, to avoid spoofing) the PTR for their own address. (the A RR update can involve tsig, but for the PTR RR update tsig is impractical.) dhcpv6 might be useful for learning a dns search list or discovering local servers (though stuart cheshire's way is more dynamic and therefore better) but it's a silly "cling to the past" solution compared to ipv6 autoconfig. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 6 18:05:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07988 for ; Thu, 6 Feb 2003 18:05:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gv1r-0002cU-00 for namedroppers-data@psg.com; Thu, 06 Feb 2003 15:01:59 -0800 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 18gv1o-0002cD-00 for namedroppers@ops.ietf.org; Thu, 06 Feb 2003 15:01:56 -0800 Received: from nominum.com (dsl093-187-100.chi2.dsl.speakeasy.net [66.93.187.100]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h16N1RP03275; Thu, 6 Feb 2003 17:01:27 -0600 (CST) Date: Thu, 6 Feb 2003 17:01:42 -0600 Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= , Johan Ihren , Francis Dupont , namedroppers@ops.ietf.org To: Paul Vixie From: Ted Lemon In-Reply-To: <20030206224805.18349379EF5@as.vix.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I would argue, by the way, that the right way to do DNS updates in IPv6 with stateless addrconf is this: 1. Client gets address. 2. Client discovers route to outside world. 3. Client, which knows its FQDN, and has a private key matching the public key in a SIG record on that FQDN, updates the primary nameserver for its FQDN with its new IP address, using SIG(0) with its key. 4. Client queries to find out who owns the reverse zone it needs to update. It can do this either by walking the chain from the root, or by asking the local name server if it's gotten DNS server configuration information through DHCPv6. 5. Client sends a DNS update to the primary server for the reverse zone that owns its name, again using SIG(0) with the signature from its FQDN. 6. DNS server looks up the key on the FQDN, verifies that the client knows the private key, verifies that there is an A4 record for the IP address corresponding to the PTR the client is updating, and then does the update. Now you have an automatic, standards-compliant update mechanism that doesn't require DHCP, is reasonably secure, and places the responsibility for doing the update on the device that is most capable of deciding to do it. The one thing that's missing is a step for removing the name later. Probably this would involve a step 7, where the client sends a delete, again signed with the private half of the SIG on its FQDN, and the DNS server verifies that the A4 record is gone, and then does the delete. BTW, I used the term "client" above even though we're not doing DHCP, simply because it was easier than saying "configuring node." I don't mean to imply anything by using the term "client" - it's just what rolled off my keyboard. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 6 18:24:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08545 for ; Thu, 6 Feb 2003 18:23:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gvIM-0003dI-00 for namedroppers-data@psg.com; Thu, 06 Feb 2003 15:19:02 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 18gvII-0003c4-00 for namedroppers@ops.ietf.org; Thu, 06 Feb 2003 15:18:58 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h16NItYm033260 for ; Thu, 6 Feb 2003 18:18:56 -0500 (EST) Received: from [198.202.64.202] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id SAA17573 for ; Thu, 6 Feb 2003 18:18:53 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <200302051229.h15CTZof065277@givry.rennes.enst-bretagne.fr> References: <200302051229.h15CTZof065277@givry.rennes.enst-bretagne.fr> Date: Thu, 6 Feb 2003 15:15:59 -0800 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-1.1 required=5.0 tests=IN_REP_TO,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 13:29 +0100 2/5/03, Francis Dupont wrote: >=> DNSEXT was proposed by the chairs of the WGs. This draft needs >a WG and DNSEXT is not so bad. But, as was true when we met in Yokohama, this document does not fit within the charter of DNSEXT. (This is not a comment on the content of the document.) It's never been clear to me what is the justification for discussing this document on this mail list. After an initial reading back then, I haven't considered it further as it looks to be out of scope to me. I might be convinced to read it if the charter were to be changed to cover it. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 6 18:45:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09123 for ; Thu, 6 Feb 2003 18:45:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gvgB-0005PD-00 for namedroppers-data@psg.com; Thu, 06 Feb 2003 15:43:39 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 18gvg8-0005Ot-00 for namedroppers@ops.ietf.org; Thu, 06 Feb 2003 15:43:36 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18gvft-0005RF-00; Thu, 06 Feb 2003 18:43:21 -0500 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Ted Lemon Cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration References: <20030206224805.18349379EF5@as.vix.com> Message-Id: Date: Thu, 06 Feb 2003 18:43:21 -0500 X-Spam-Status: No, hits=-0.8 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > 4. Client queries to find out who owns the reverse zone it needs to > update. It can do this either by walking the chain from the root, or > by asking the local name server if it's gotten DNS server configuration > information through DHCPv6. > 5. Client sends a DNS update to the primary server for the reverse zone > that owns its name, again using SIG(0) with the signature from its FQDN. if it does not know who holds the reverse zone, and, in fact, is not preconfigured, how the heck does it send a _validly signed_ sig(0) update to the reverse server if and when it finds 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. archive: From owner-namedroppers@ops.ietf.org Thu Feb 6 18:58:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09588 for ; Thu, 6 Feb 2003 18:58:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gvrn-0006M4-00 for namedroppers-data@psg.com; Thu, 06 Feb 2003 15:55:39 -0800 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 18gvrj-0006Ln-00; Thu, 06 Feb 2003 15:55:35 -0800 Received: from nominum.com (dsl093-187-100.chi2.dsl.speakeasy.net [66.93.187.100]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h16NtGP03593; Thu, 6 Feb 2003 17:55:18 -0600 (CST) Date: Thu, 6 Feb 2003 17:55:31 -0600 Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: namedroppers@ops.ietf.org To: Randy Bush From: Ted Lemon In-Reply-To: Message-Id: <79A2A8A4-3A2E-11D7-A2AE-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> 5. Client sends a DNS update to the primary server for the reverse >> zone >> that owns its name, again using SIG(0) with the signature from its >> FQDN. > > if it does not know who holds the reverse zone, and, in fact, is not > preconfigured, how the heck does it send a _validly signed_ sig(0) > update to the reverse server if and when it finds it? Sorry, misuse of terminology. It sends an update to the reverse server signed in the private half of the SIG key from its forward FQDN. The reverse server has to know to do step 6 to validate the update. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 6 19:09:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09843 for ; Thu, 6 Feb 2003 19:09:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gw0V-0006yH-00 for namedroppers-data@psg.com; Thu, 06 Feb 2003 16:04:39 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 18gw0S-0006y1-00 for namedroppers@ops.ietf.org; Thu, 06 Feb 2003 16:04:36 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18gvzc-0005Sf-00; Thu, 06 Feb 2003 19:03:44 -0500 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Ted Lemon Cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration References: <79A2A8A4-3A2E-11D7-A2AE-00039367340A@nominum.com> Message-Id: Date: Thu, 06 Feb 2003 19:03:44 -0500 X-Spam-Status: No, hits=-0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>> 5. Client sends a DNS update to the primary server for the reverse >>> zone >>> that owns its name, again using SIG(0) with the signature from its >>> FQDN. >> if it does not know who holds the reverse zone, and, in fact, is not >> preconfigured, how the heck does it send a _validly signed_ sig(0) >> update to the reverse server if and when it finds it? > Sorry, misuse of terminology. It sends an update to the reverse > server signed in the private half of the SIG key from its forward FQDN. > The reverse server has to know to do step 6 to validate the update. because my laptop has a relationship to the server for psg.com, and can put something kinky into the forward name should not mean that the owner of the reverse zone should trust the data in the forward zone or that the laptop asserts. is the attack not pretty obvious? 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. archive: From owner-namedroppers@ops.ietf.org Thu Feb 6 21:35:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13222 for ; Thu, 6 Feb 2003 21:35:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gy9p-000BVJ-00 for namedroppers-data@psg.com; Thu, 06 Feb 2003 18:22:25 -0800 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 18gy9m-000BUp-00; Thu, 06 Feb 2003 18:22:22 -0800 Received: from nominum.com (dsl093-187-100.chi2.dsl.speakeasy.net [66.93.187.100]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h172M0P04494; Thu, 6 Feb 2003 20:22:02 -0600 (CST) Date: Thu, 6 Feb 2003 20:22:15 -0600 Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: namedroppers@ops.ietf.org To: Randy Bush From: Ted Lemon In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> Sorry, misuse of terminology. It sends an update to the reverse >> server signed in the private half of the SIG key from its forward >> FQDN. >> The reverse server has to know to do step 6 to validate the update. > > because my laptop has a relationship to the server for psg.com, and > can put something kinky into the forward name should not mean that > the owner of the reverse zone should trust the data in the forward > zone or that the laptop asserts. is the attack not pretty obvious? It was a rough outline. Obviously the checking the reverse server has to do to make it work is more than what I said, but it's totally doable. The validation I described prevents a random host on the network from trivially stuffing the DNS server with bogus PTR records. You could do an additional validation where if someone wants to stuff a new valid into an old PTR record, the DNS server looks to see if the old FQDN in that PTR record still points back to the address referred to by the PTR record, and if it does, refuses the update. This prevents PTR record stealing. Is there some other attack I'm not thinking of here? Obviously this assumes that the DNS server for the zone in question is willing to have arbitrary clients establish PTR records. I can imagine a variety of administrative policies, from "allow all domains" to "allow only this set of domains" to "allow only my domain" to "allow no PTR updates at all." -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 7 05:52:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04626 for ; Fri, 7 Feb 2003 05:52:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18h60K-0001qJ-00 for namedroppers-data@psg.com; Fri, 07 Feb 2003 02:45:08 -0800 Received: from cyphermail.sandelman.ottawa.on.ca ([192.139.46.78] helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 3.36 #1) id 18h60H-0001nP-00 for namedroppers@ops.ietf.org; Fri, 07 Feb 2003 02:45:06 -0800 Received: from sandelman.ottawa.on.ca ([2002:c08b:2e21:2:204:76ff:fe2d:8c]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h15El3L22735 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Wed, 5 Feb 2003 09:47:04 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h15El1r7021772 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 5 Feb 2003 09:47:03 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h15El1XB021769; Wed, 5 Feb 2003 09:47:01 -0500 Message-Id: <200302051447.h15El1XB021769@marajade.sandelman.ottawa.on.ca> To: Mark Kosters cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: DNSSEC Opt-in In-reply-to: Your message of "Tue, 04 Feb 2003 15:30:19 EST." <20030204203019.GF2151@verisignlabs.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 05 Feb 2003 09:47:00 -0500 From: Michael Richardson X-Spam-Status: No, hits=1.2 required=5.0 tests=IN_REP_TO,LINES_OF_YELLING,OPT_IN,PGP_SIGNATURE, SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I wonder if the final zone files, plus public and private keys from the opt-in workshop could be made available fot FTP somewhere? This would help others to duplicate this test environment in vitro, (via bind9's on multiple aliases, or via User-Mode-Linux, or even by getting X-many machines) to best understand the setup and configuration that was done. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPkEj44qHRg3pndX9AQEtrwP/SQuH8ZvvaRHY7iOLKwcn0nmxiK0oGs83 4nFKj9k5vo+I38dPa+ZfWJHaFG4M+JKsy9qlYoJQPYgqiqXA3MIrEXa3RVqjPV1M eF13RPaYuvJLuF/QGvFpAtfavyTVkKVbFIH2HjOWxwqOsqtr/vR9IDfh1M5KjLum vjoaqEqh8io= =b9jv -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 7 05:52:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04641 for ; Fri, 7 Feb 2003 05:52:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18h5z9-0001nb-00 for namedroppers-data@psg.com; Fri, 07 Feb 2003 02:43:55 -0800 Received: from cyphermail.sandelman.ottawa.on.ca ([192.139.46.78] helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 3.36 #1) id 18h5z2-0001nP-00 for namedroppers@ops.ietf.org; Fri, 07 Feb 2003 02:43:48 -0800 Received: from sandelman.ottawa.on.ca ([2002:c08b:2e21:2:204:76ff:fe2d:8c]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h15KNvL24749 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Wed, 5 Feb 2003 15:23:59 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h15KNtr7003277 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Wed, 5 Feb 2003 15:23:57 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h15KNsLo003273 for ; Wed, 5 Feb 2003 15:23:55 -0500 Message-Id: <200302052023.h15KNsLo003273@marajade.sandelman.ottawa.on.ca> To: namedroppers@ops.ietf.org Subject: Re: OPT-IN workshop Report In-reply-to: Your message of "05 Feb 2003 19:24:17 +0100." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 05 Feb 2003 15:23:54 -0500 From: Michael Richardson X-Spam-Status: No, hits=1.2 required=5.0 tests=IN_REP_TO,LINES_OF_YELLING,OPT_IN,PGP_SIGNATURE, SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Johan" == Johan Ihren writes: Johan> Rob Austein writes: >> > - the use of alternative type codes and mnemonics for SIG, NXT >> > and KEY. >> >> Not obvious to me why one would need to change SIG and KEY here. Johan> One doesn't. NXT would be sufficient. The reason to rev SIG and KEY as well is so that the new infrastructure will be distinct from the old infrastructure. While the computers may be happy with just NXT2, the humans may not be as "compliant". ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPkFy2IqHRg3pndX9AQGYFQQA2pNZSDokOSMhRRh4qTSApD54OSoKeVMs e0eCf5KJjY1pZsVeJk2FmnjdMTuwksbMVUPdVqrVwxAoBRi38vpZcDHBTlz6KgjE BcaVDDi56xAmI2a22P0W+lkVn9Jl+HLfpZbyaOYTSC2jcvTbmeZzIYIE6YlFf4RC xXIWUlOhP+w= =6Wb4 -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 7 06:54:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05969 for ; Fri, 7 Feb 2003 06:53:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18h726-000446-00 for namedroppers-data@psg.com; Fri, 07 Feb 2003 03:51:02 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #1) id 18h724-00043u-00 for namedroppers@ops.ietf.org; Fri, 07 Feb 2003 03:51:00 -0800 Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.5/8.11.6) with SMTP id h17BowAq005854; Fri, 7 Feb 2003 12:50:58 +0100 Date: Fri, 7 Feb 2003 12:50:58 +0100 From: "Olaf M. Kolkman" To: Michael Richardson Cc: markk@verisignlabs.com, namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: DNSSEC Opt-in Message-Id: <20030207125058.5525498e.olaf@ripe.net> In-Reply-To: <200302051447.h15El1XB021769@marajade.sandelman.ottawa.on.ca> References: <20030204203019.GF2151@verisignlabs.com> <200302051447.h15El1XB021769@marajade.sandelman.ottawa.on.ca> Organization: RIPE NCC X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,NOSPAM_INC,OPT_IN,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I wonder if the final zone files, plus public and private keys from the > opt-in workshop could be made available fot FTP somewhere? As the setup was distributed over many laptops and the laptop have dispersed this is at this point close to impossible. > This would help others to duplicate this test environment in vitro, > (via bind9's on multiple aliases, or via User-Mode-Linux, or even by > getting X-many machines) to best understand the setup and > configuration that was done. I think you have a good point. Any future workshop should record all zonefiles and keys. Maybe it's time to write up an I-D (BCP style) on test setups. (Or is there allready an RFC) --Olaf --------------------------------------------| Olaf M. Kolkman | www.ripe.net/disi -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 7 07:50:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07487 for ; Fri, 7 Feb 2003 07:50:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18h7th-000653-00 for namedroppers-data@psg.com; Fri, 07 Feb 2003 04:46:25 -0800 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by psg.com with esmtp (Exim 3.36 #1) id 18h7te-00064W-00 for namedroppers@ops.ietf.org; Fri, 07 Feb 2003 04:46:22 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA00787; Fri, 7 Feb 2003 04:46:20 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h17CkJP27925; Fri, 7 Feb 2003 13:46:19 +0100 (MET) Date: Fri, 7 Feb 2003 13:42:44 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Q: Conflict between TSIG RFC and GSS-API documents To: Edward Lewis Cc: =?iso-8859-1?Q?=D3lafur_Gudmundsson/DNSEXT_co-chair?= , namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Although I agree with that assessment, that doesn't mean that I think > it is a good idea to thaw the GSS-API document. I think it should be > thawed in tandem with a document that proscribes the needed > improvement to the TSIG base. I.e., a document specifying an > extension to TSIG's base is needed before allowing an extension that > would otherwise be in conflict. Would it be acceptable to add text to the GSS-TSIG document to make it clear that it updates the TSIG RFC? I can see that it is desirable to get this change applied to the TSIG spec, but in the interim I think the best is to get it documented somewhere. And having rfc-index.txt indicate that there is an update to the TSIG document helps people find this. Comments? 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. archive: From owner-namedroppers@ops.ietf.org Fri Feb 7 10:07:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13031 for ; Fri, 7 Feb 2003 10:07:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18h9xu-000Bb5-00 for namedroppers-data@psg.com; Fri, 07 Feb 2003 06:58:54 -0800 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 18h9xo-000Bar-00; Fri, 07 Feb 2003 06:58:49 -0800 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA19111; Fri, 7 Feb 2003 09:58:45 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA18823; Fri, 7 Feb 2003 09:58:42 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id JAA23580; Fri, 7 Feb 2003 09:58:41 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id JAA16898; Fri, 7 Feb 2003 09:58:41 -0500 (EST) To: Ted Lemon Cc: Randy Bush , namedroppers@ops.ietf.org From: Derek Atkins Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration References: Date: 07 Feb 2003 09:58:41 -0500 In-Reply-To: Message-ID: Lines: 27 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-1.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,RCVD_IN_RELAYS_ORDB_ORG,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_GNUS_UA,X_OSIRU_OPEN_RELAY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Ted Lemon writes: > You could do an additional validation where if someone wants to stuff > a new valid into an old PTR record, the DNS server looks to see if the > old FQDN in that PTR record still points back to the address referred > to by the PTR record, and if it does, refuses the update. This > prevents PTR record stealing. > > Is there some other attack I'm not thinking of here? I rightfully grab an address and go through the process. Then I go offnet without removing my forward pointer. My "lease" expires. The next person who happens to get my address can no longer get the PTR entry because the old (stale) forward entry is still there. > Obviously this assumes that the DNS server for the zone in question is > willing to have arbitrary clients establish PTR records. I can > imagine a variety of administrative policies, from "allow all domains" > to "allow only this set of domains" to "allow only my domain" to > "allow no PTR updates at all." -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.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. archive: From owner-namedroppers@ops.ietf.org Fri Feb 7 10:22:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13294 for ; Fri, 7 Feb 2003 10:22:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18hAF9-000CN6-00 for namedroppers-data@psg.com; Fri, 07 Feb 2003 07:16:43 -0800 Received: from one.elistx.com ([209.116.252.130]) by psg.com with esmtp (Exim 3.36 #1) id 18hAF6-000CMp-00 for namedroppers@ops.ietf.org; Fri, 07 Feb 2003 07:16:40 -0800 Received: from ogud.com (pcp816081pcs.nrockv01.md.comcast.net [68.49.60.118]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0H9Y008C92GAKA@eListX.com> for namedroppers@ops.ietf.org; Fri, 07 Feb 2003 10:16:58 -0500 (EST) Received: from hlid.dc.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.3/8.12.3) with ESMTP id h17FFetr078021; Fri, 07 Feb 2003 10:15:40 -0500 (EST envelope-from ogud@ogud.com) Received: from localhost (ogud@localhost) by hlid.dc.ogud.com (8.12.3/8.12.3/Submit) with ESMTP id h17FFeh0078018; Fri, 07 Feb 2003 10:15:40 -0500 (EST) Date: Fri, 07 Feb 2003 10:15:40 -0500 (EST) From: Olafur Gudmundsson Subject: Re: Q: Conflict between TSIG RFC and GSS-API documents In-reply-to: X-X-Sender: ogud@hlid.dc.ogud.com To: Erik Nordmark Cc: Edward Lewis , namedroppers@ops.ietf.org Message-id: <20030207101418.H78008-100000@hlid.dc.ogud.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII X-Authentication-warning: hlid.dc.ogud.com: ogud owned process doing -bs X-Spam-Status: No, hits=-0.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, SPAM_PHRASE_00_01,X_AUTH_WARNING version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I support this way to go forward. So far there has only be support expressed for this change, not that I'm declaring consensus yet. Olafur On Fri, 7 Feb 2003, Erik Nordmark wrote: > > Although I agree with that assessment, that doesn't mean that I think > > it is a good idea to thaw the GSS-API document. I think it should be > > thawed in tandem with a document that proscribes the needed > > improvement to the TSIG base. I.e., a document specifying an > > extension to TSIG's base is needed before allowing an extension that > > would otherwise be in conflict. > > Would it be acceptable to add text to the GSS-TSIG document to make it > clear that it updates the TSIG RFC? > I can see that it is desirable > to get this change applied to the TSIG spec, but in the interim I think > the best is to get it documented somewhere. And having rfc-index.txt indicate > that there is an update to the TSIG document helps people find this. > > Comments? > > 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. archive: From owner-namedroppers@ops.ietf.org Fri Feb 7 10:36:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13639 for ; Fri, 7 Feb 2003 10:36:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18hATU-000D2J-00 for namedroppers-data@psg.com; Fri, 07 Feb 2003 07:31:32 -0800 Received: from [2001:4f8:3:bb:2e0:81ff:fe23:7b5a] (helo=as.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 18hATR-000Czz-00 for namedroppers@ops.ietf.org; Fri, 07 Feb 2003 07:31:30 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id B489D379E40 for ; Fri, 7 Feb 2003 15:31:16 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Q: Conflict between TSIG RFC and GSS-API documents In-Reply-To: Message from Erik Nordmark of "Fri, 07 Feb 2003 13:42:44 +0100." X-Mailer: MH-E 7.2; nmh 1.0.4; GNU Emacs 21.2.1 Date: Fri, 07 Feb 2003 15:31:16 +0000 Message-Id: <20030207153116.B489D379E40@as.vix.com> X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Would it be acceptable to add text to the GSS-TSIG document to make it > clear that it updates the TSIG RFC? i think that this is the best possible solution. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 7 11:03:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14208 for ; Fri, 7 Feb 2003 11:03:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18hApW-000EDv-00 for namedroppers-data@psg.com; Fri, 07 Feb 2003 07:54:18 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 18hApR-000EDf-00; Fri, 07 Feb 2003 07:54:13 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h17Fs7Ym043934; Fri, 7 Feb 2003 10:54:07 -0500 (EST) Received: from [198.202.64.232] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id KAA18757; Fri, 7 Feb 2003 10:54:05 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 (Unverified) Message-Id: In-Reply-To: References: <200302051229.h15CTZof065277@givry.rennes.enst-bretagne.fr> <20030205191331.F3B1918ED@thrintun.hactrn.net> Date: Fri, 7 Feb 2003 07:52:51 -0800 To: Randy Bush From: Edward Lewis Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration Cc: Rob Austein , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk To some degree I agree with what Randy means here, but I'm not sure I agree with the logic. At 15:50 -0500 2/5/03, Randy Bush wrote: >the distributed approach is less explored and well-documented. >various bits of it keep rising, most especially in the ipv6 world. Academically, I think the distributed approach has been explored a good deal. I haven't the time to spend in a literature search, but I'm sure there are some research papers on the topic. (I recall attending an IETF meeting in '94 on v6 address discovery and muttered - 'that's what Apple does' and 'that's what OSI does' to two of the tree approaches.) 'Course, Appletalk has gone IP and OSI has gone to rest, I think that says quite a bit about the promise of the approach. Don't get me wrong, I think it's really cool, but empirical evidence says it isn't stable. >the problem is there has never been a coherent architecture of the >distributed approach, heck not even a picture or diagram of how it >all fits together. so we get ad hoc pieces and no way to judge >how they all fit together, whether they are complete, etc. There are a lot of needed components. That means it is fertile ground for a Rube Goldberg design. >imiho, unless and until we get a sufficient coherent picture of >distributed discovery with all the services explained, the pieces >that float up should be treated politely, but put aside as >experimental at best. until the distributed architecture is well >described and well understood, the dhcp approach is well >understood, well documented, and well deployed. That I agree with. --- I thought more about Randy's assessment overnight. I think there's more to the issue that what I saw at first. Back when I taught a class on networking, I covered the topic of client-server. After spending some time on that topic alone I recall making the comment that networking and distributed processing is not just client-server. There are peer to peer approaches, etc. I recall at the time having a nagging suspicion that client-server, although not exclusive would eventually dominate. (This was even pre-WWW). It seems that client-server has come to dominate, my guess is that it is because client-server is easier to operate and manage than hierarchy-less peer to peer. This hypothesis seems to be tested again by this thread - whether one plucks an address from the ether and reports it to DNS (peer-based) or one consults a server for an assignment. It's not that peer to peer is less worthy than client and server, it's that operators (enterprise in this context) will prefer the latter as it gives them a better ability to run a workable network. --- And another thing. One of the main principles that I apply to DNS is to keep it a simple service, to not add a lot of fancy feature cruft. This means that the features have to appear elsewhere. What gives me pause in maintaining a hard line like this is that this philosophy runs counter to the peer-to-peer vs client-server ideas above. Although client-server is easier to manage from some points of view, relying on it totally is wrong. Client-server is counter to the philosophy of having strong end points and a passive core, which is a big part of the spirit of the Internet. Perhaps there's some not yet understood (by me) threshold where client-server and peer-to-peer comparisons change the recommendation of the approach. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 7 11:21:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14587 for ; Fri, 7 Feb 2003 11:21:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18hBA8-000FMS-00 for namedroppers-data@psg.com; Fri, 07 Feb 2003 08:15:36 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 18hBA6-000FMG-00 for namedroppers@ops.ietf.org; Fri, 07 Feb 2003 08:15:34 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h17GFVYm044359; Fri, 7 Feb 2003 11:15:31 -0500 (EST) Received: from [198.202.64.232] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA21317; Fri, 7 Feb 2003 11:15:29 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Fri, 7 Feb 2003 07:58:02 -0800 To: Erik Nordmark From: Edward Lewis Subject: Re: Q: Conflict between TSIG RFC and GSS-API documents Cc: Edward Lewis , =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-1.2 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,TO_BE_REMOVED_REPLY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I would ask that the GSS-TSIG document not only say that it updates the TSIG spec but that the document also contains the suggested change to the TSIG document. This is the approach followed in other DNSSEC documents. At 13:42 +0100 2/7/03, Erik Nordmark wrote: >> Although I agree with that assessment, that doesn't mean that I think >> it is a good idea to thaw the GSS-API document. I think it should be >> thawed in tandem with a document that proscribes the needed >> improvement to the TSIG base. I.e., a document specifying an >> extension to TSIG's base is needed before allowing an extension that >> would otherwise be in conflict. > >Would it be acceptable to add text to the GSS-TSIG document to make it >clear that it updates the TSIG RFC? >I can see that it is desirable >to get this change applied to the TSIG spec, but in the interim I think >the best is to get it documented somewhere. And having rfc-index.txt indicate >that there is an update to the TSIG document helps people find this. > >Comments? > > 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. >archive: -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 7 11:31:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14783 for ; Fri, 7 Feb 2003 11:31:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18hBJ4-000Fnk-00 for namedroppers-data@psg.com; Fri, 07 Feb 2003 08:24:50 -0800 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 18hBJ3-000FnW-00 for namedroppers@ops.ietf.org; Fri, 07 Feb 2003 08:24:49 -0800 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id EE97C18ED for ; Fri, 7 Feb 2003 11:24:34 -0500 (EST) Date: Fri, 07 Feb 2003 11:24:34 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Q: Conflict between TSIG RFC and GSS-API documents In-Reply-To: References: User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030207162435.EE97C18ED@thrintun.hactrn.net> X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Fri, 7 Feb 2003 13:42:44 +0100 (CET), Erik Nordmark wrote: > > Would it be acceptable to add text to the GSS-TSIG document to make it > clear that it updates the TSIG RFC? Sounds right to 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. archive: From owner-namedroppers@ops.ietf.org Fri Feb 7 14:17:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18750 for ; Fri, 7 Feb 2003 14:17:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18hDrO-000OJ1-00 for namedroppers-data@psg.com; Fri, 07 Feb 2003 11:08:26 -0800 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 18hDrL-000OHj-00; Fri, 07 Feb 2003 11:08:23 -0800 Received: from nominum.com (dsl093-187-100.chi2.dsl.speakeasy.net [66.93.187.100]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h17J7rP12256; Fri, 7 Feb 2003 13:07:53 -0600 (CST) Date: Fri, 7 Feb 2003 13:08:17 -0600 Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: namedroppers@ops.ietf.org, Randy Bush To: Derek Atkins From: Ted Lemon In-Reply-To: Message-Id: <83A6334F-3ACF-11D7-A2AE-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I rightfully grab an address and go through the process. Then I go > offnet without removing my forward pointer. My "lease" expires. The > next person who happens to get my address can no longer get the PTR > entry because the old (stale) forward entry is still there. Yup. We can't do much about this case without adding extra complexity we'd probably rather avoid. Does that render the technique Not Useful? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 7 15:04:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20159 for ; Fri, 7 Feb 2003 15:04:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18hEel-0001BG-00 for namedroppers-data@psg.com; Fri, 07 Feb 2003 11:59:27 -0800 Received: from gusto.araneus.fi ([204.152.186.164]) by psg.com with esmtp (Exim 3.36 #1) id 18hEei-0001AR-00; Fri, 07 Feb 2003 11:59:25 -0800 Received: from guava.araneus.fi (adsl-63-197-0-204.dsl.snfc21.pacbell.net [63.197.0.204]) by gusto.araneus.fi (8.11.6/8.11.6) with ESMTP id h17JxHZ19674; Fri, 7 Feb 2003 11:59:17 -0800 (PST) Received: (from gson@localhost) by guava.araneus.fi (8.11.6/8.11.6) id h17JxDT14464; Fri, 7 Feb 2003 11:59:13 -0800 (PST) Date: Fri, 7 Feb 2003 11:59:13 -0800 (PST) Message-Id: <200302071959.h17JxDT14464@guava.araneus.fi> To: Erik Nordmark Cc: ogud@ogud.com, randy@psg.com, namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-unknown-rrs-04.txt In-Reply-To: References: X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Erik Nordmark writes: > I've done the AD review of this document and I have some questions. > > To avoid such corruption, servers MUST NOT compress domain names > embedded in the RDATA of types that are class-specific or not well- > known. This requirement was stated in RFC1123 without defining the > term "well-known"; it is hereby specified that only the RR types > defined in RFC1035 are to be considered "well-known". > > The above seems to change the current standard behavior for > SIG, NXT, and perhaps others. Is this the intent? Yes. RFC2065 explicitly allowed compression of names in SIG and NXT records, and this is no longer allowed per the unknown-RRs draft. As for "perhaps others", I could find one other case where an RR specification explicitly allows compression: RFC2163 allows compression in the PX records, which appears to be in direct conflict with the RFC1035 statement that "Pointers can only be used for occurances of a domain name where the format is not class specific" since RFC2163 restricts the PX record to the IN class. > If so the document should explicitly state this > and also add an "updates RFC 2535" up front. I will add this and "updates RFC2163". > For all other RR types, the canonical form is hereby changed such > that no downcasing of embedded domain names takes place. The owner > name is always set to lower case according to the DNS rules for > character comparisons, regardless of the RR type. > > It would be useful to explicitly list the RR types to which this change > applies. That's not really practical since there is more than 65000 of them. While you could attempt to list the currently allocated post-RFC2915 types, such a list would soon become inaccurate as additional types are allocated. > Nits (by themselves not necessitating an updated I-D at this point in time): > The references should be split into normative and non-normative. Will do. It appears there have been quite a number of changes to the I-D requirements since the initial publication of the draft... > A boilerplate IPR section should be added. Can you please point me to a document describing this requirement and the form of the required boilerplate? -- 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. archive: From owner-namedroppers@ops.ietf.org Fri Feb 7 17:44:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23800 for ; Fri, 7 Feb 2003 17:44:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18hH4N-000AMG-00 for namedroppers-data@psg.com; Fri, 07 Feb 2003 14:34:03 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 18hH4L-000AM3-00 for namedroppers@ops.ietf.org; Fri, 07 Feb 2003 14:34:01 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h17MXxYm058174 for ; Fri, 7 Feb 2003 17:33:59 -0500 (EST) Received: from [198.202.64.232] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id RAA20179 for ; Fri, 7 Feb 2003 17:33:58 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <200302051144.GAA18898@ietf.org> References: <200302051144.GAA18898@ietf.org> Date: Fri, 7 Feb 2003 14:34:11 -0800 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: I-D ACTION:draft-lewis-dns-wildcard-clarify-00.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=0.7 required=5.0 tests=IN_REP_TO,OPT_IN,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk After submitting, this requirement became apparent: # Wild Cards MUST be signed (covered by auth denial of existence if the zone # offers auth denial of existence) when assuming authenticated denial of # existence, otherwise the detection of the "closest encloser" might not be # possible. I.e., Wild cards cannot be opted out...yes I know that according to the opt-in draft they cannot be opted out, this requirement just strengthens the reason why. At 6:44 -0500 2/5/03, Internet-Drafts@ietf.org wrote: > Title : Clarifying the Role of Wild Card Domains in >the Domain > Name System -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 7 18:48:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25334 for ; Fri, 7 Feb 2003 18:48:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18hIAy-000Ecz-00 for namedroppers-data@psg.com; Fri, 07 Feb 2003 15:44:56 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 18hIAw-000Ecl-00 for namedroppers@ops.ietf.org; Fri, 07 Feb 2003 15:44:54 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18hI5L-0006QM-00; Fri, 07 Feb 2003 18:39:07 -0500 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Ted Lemon Cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration References: <83A6334F-3ACF-11D7-A2AE-00039367340A@nominum.com> Message-Id: Date: Fri, 07 Feb 2003 18:39:07 -0500 X-Spam-Status: No, hits=-0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> I rightfully grab an address and go through the process. Then I go >> offnet without removing my forward pointer. My "lease" expires. The >> next person who happens to get my address can no longer get the PTR >> entry because the old (stale) forward entry is still there. > Yup. We can't do much about this case without adding extra complexity > we'd probably rather avoid. Does that render the technique Not Useful? well, imiho, you were already three klud^H^H^Hheuristics deep and the basic dynmaic update it all relies on is still not reliable in my daily use experience. 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. archive: From owner-namedroppers@ops.ietf.org Fri Feb 7 19:29:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26054 for ; Fri, 7 Feb 2003 19:29:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18hInf-000H7d-00 for namedroppers-data@psg.com; Fri, 07 Feb 2003 16:24:55 -0800 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 18hInd-000H7P-00; Fri, 07 Feb 2003 16:24:53 -0800 Received: from nominum.com (dsl093-187-100.chi2.dsl.speakeasy.net [66.93.187.100]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h180OOP17146; Fri, 7 Feb 2003 18:24:24 -0600 (CST) Date: Fri, 7 Feb 2003 18:24:50 -0600 Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: namedroppers@ops.ietf.org To: Randy Bush From: Ted Lemon In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > well, imiho, you were already three klud^H^H^Hheuristics deep Heh! I have to admit that it has its problems, but it seems like not a completely rotten idea. In order for it to work nicely, you probably need an extra protocol, so that the DNS server doesn't have to be responsible for all the validation and bookkeeping, and so that you can have, *ahem*, leases on the PTR records, so that they get cleaned up when the registrant goes away. I think we've pretty soundly rejected the idea that the DNS server might have such a mechanism. But this seems more functional than a solution that doesn't involve any actual communication with the device that has autoconfigured. > and the basic dynmaic update it all relies on is still not reliable in > my daily use experience. All of the solutions we've talked about rely on the basic dynamic update mechanism, which I have to say works just fine for me (I wish more DHCP clients supported it, though). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 7 21:35:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28533 for ; Fri, 7 Feb 2003 21:35:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18hKlK-000Md4-00 for namedroppers-data@psg.com; Fri, 07 Feb 2003 18:30:38 -0800 Received: from one.elistx.com ([209.116.252.130]) by psg.com with esmtp (Exim 3.36 #1) id 18hKlI-000Mcs-00 for namedroppers@ops.ietf.org; Fri, 07 Feb 2003 18:30:36 -0800 Received: from ogud.com (pcp816081pcs.nrockv01.md.comcast.net [68.49.60.118]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0H9Y00JMVXNH99@eListX.com> for namedroppers@ops.ietf.org; Fri, 07 Feb 2003 21:30:53 -0500 (EST) Received: from ENGILL.ogud.com (mail.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.3/8.12.3) with ESMTP id h182TTts079722 for ; Fri, 07 Feb 2003 21:29:32 -0500 (EST envelope-from ogud@ogud.com) Date: Fri, 07 Feb 2003 21:23:35 -0500 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: DNSSEC editing process (Periodic posting) X-Sender: (Unverified) To: namedroppers@ops.ietf.org Message-id: <5.1.1.6.2.20030207211528.015d3f78@wheresmymailserver.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=iso-8859-1 X-Spam-Status: No, hits=3.1 required=5.0 tests=RCVD_IN_RFCI,SPAM_PHRASE_02_03 version=2.43 X-Spam-Level: *** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA28533 The DNSEXT working group has started a rewrite of the DNSSEC specification into a documents that better reflect the protocol and allow a test plan to be constructed from the specification. To accomplish this, a team of volunteers has been formed to generate the documents. The document editing team is tasked with documenting the protocol as specified in RFC's generated by this group and id's that have been passed on by the working group to the IESG. The editors are NOT ALLOWED to make ANY changes in the protocol. If clarifications are needed due to conflicting definitions, imprecise specification, omission or other reason, the editors MUST bring these issues to the attention of the working group on the namedroppers mailing list. To assist the editors, a small group of people with good understanding of DNSSEC have been recruited to review document drafts and answer questions that the editors have. For simplified communication a mailing list has been created, anyone can send messages to the editors via this mailing list DNSSEC-editors@east.isi.edu. Archive of this mailing list will be made available. Please send minor corrections, comments, suggestions about the DNSSECbis documents to dnssec-editors@east.isi.edu. All major issues should be brought up on namedroppers, editors MAY forward any correspondence to namedroppers, without asking permission, if they deem the issues raised require wider attention. DNSEXT co-chair Ólafur Guđmundsson approves new members on the dnssec-editors malling list. DNSSEC-editors is NOT a design group, it is a document maintenance group. The current members of the mailing list are: Editors: Roy Arends Rob Austein Matt Larson Dan Massey Scott Rose Advisors: Donald Eastlake Brian Wellington Edward Lewis Randy Bush Olafur Gudmundsson The current set of documents produced by dnssec-editors is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-intro-04.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-records-02.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-protocol-00.txt Supporting documents include: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-threats-02.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2536bis-dsa-02.txt All the documents will be undergoing rapid updates during the next month, please review new version as they become available. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Feb 9 09:31:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29355 for ; Sun, 9 Feb 2003 09:31:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18hsIl-000Iif-00 for namedroppers-data@psg.com; Sun, 09 Feb 2003 06:19:23 -0800 Received: from [133.11.205.136] (helo=hoge.kaynet.ecc.u-tokyo.ac.jp) by psg.com with esmtp (Exim 3.36 #1) id 18hsIh-000IiT-00 for namedroppers@ops.ietf.org; Sun, 09 Feb 2003 06:19:19 -0800 Received: from KOALA (localhost.nc.u-tokyo.ac.jp [127.0.0.1]) by hoge.kaynet.ecc.u-tokyo.ac.jp (8.9.3/3.7W) with SMTP id XAA29229; Sun, 9 Feb 2003 23:19:05 +0900 (JST) Reply-To: From: "Yuji KAMITE" To: Cc: , "Yuji KAMITE" , Subject: RE: DNSEXT WGLC: TKEY Renewal Mode-02 Date: Sun, 9 Feb 2003 23:18:03 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <00f901c2cd17$97d66fb0$b9370681@barnacle> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_OUTLOOK version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit We would like to present our opinion as this draft's authors. > > > At 13:50 2002-11-14, Ólafur Gudmundsson/DNSEXT co-chair wrote: > > >This is the beginning of a 3 week working group last call. > > >This last call ends on December 6'th. > > > The last call on this document resulted in few messages, > > raising two issues: > > 1. the complexity of the protocol > > 2. The document gave impression that some valid TKEY behavior was > outlawed. > > > > The second issue requires minor text change to the document to fix. We're going to do minor revision soon, before San Francisco, on this issue. This would not become critical obstacle. > > The first issue is much larger and requires more feedback for chairs > > I would like to pose the following questions to the working group > > > > Q: Is the technical description in the document sufficient and > complete to > > implement ? > > > > Q: Are there any implementations or are there plans to implement ? > > > > Q: Is this overly complex and we should not do this ? Basically, this draft makes use of existing RFC2930 framework for the purpose of perparing new keys. This aims at simple extension that will not be burden for current TKEY operation. And so its original design is not complecated. (In the draft, the procedure to rollover is described in detail because it requires high reliability -- perahaps that might give you some complex impression. However, basic principle of operation is not intricate -- partial revoke notification, key rollover preparation, confrimation of adoption: these steps only. Message structure and exchage style of each process is friendly with RFC2930 specification, not complex. ) > > > I read over the draft, and it seems complete. However, I don't know if it > is implemented anywhere, nor has anyone I met plans on implementation. > There might be some hidden pitfalls that come out then. > We also think protocol specification is complete. And we have already made a simple prototype implementation for experiment (available at URL below), and have seen it works well generally. But this implemenation was based on the first released draft (-00.txt version). Unfortunately, complete implementation hasn't been finished that follows the today's latest draft (-02.txt). http://www.kaynet.ecc.u-tokyo.ac.jp/~kamite/research/dns.html#tkey-renew The implementation difference from today's draft is, whether or not TKEY adoption messageexchange is used. Originally, this messge was introduced to enhance rollover operation's reliablility more, but its basic exchange process is quite simple ( that's only final confirmation of rollover commit). We beleive it is fairly easy to give some additional changes and make it work well following today's -02 draft. > > > Q: Is standards track appropriate for this, is experimental > status better > ? > > > Unless there is a case for doing secret key rollover in the DNS instead of > some previously known out-of-band method, it should be dropped. > Otherwise, > proceed as experimental due to cost versus benefit. I doubt most DNS > operators will have the need to do secret key exchanges over DNS. > We think this is the first document that describes tsig-key online rollover process in detail. We also think It is valuable and useful method because it provides us with key refreshment in an easy automatic way. It also prevent memory waste on receiving continuous only-adding-key, by being careful of systematic schedule. That's why this draft helps RFC 2930 TKEY become more available and popular. So, it would be peferred to progress this draft as standard track. However, on the other hand, we also think that unless any other groups is planning this implementation for the time being, it might be better to progress it as experimental status. Anyway, it is necessary for us to guide and help complete implemenation (e.g., getting new numbers from IANA) by issuing this as RFC. -- Kamite --- Yuji Kamite (E-mail y.kamite@ntt.com) NTT Communications Corporation TEL: +81-3-6800-3261 FAX: +81-3-5365-2990 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 10 03:47:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00503 for ; Mon, 10 Feb 2003 03:47:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18i9Oj-000I67-00 for namedroppers-data@psg.com; Mon, 10 Feb 2003 00:34:41 -0800 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by psg.com with esmtp (Exim 3.36 #1) id 18i9Oh-000I5h-00 for namedroppers@ops.ietf.org; Mon, 10 Feb 2003 00:34:39 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA19312; Mon, 10 Feb 2003 00:34:37 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h1A8YWP18749; Mon, 10 Feb 2003 09:34:32 +0100 (MET) Date: Mon, 10 Feb 2003 09:30:52 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Q: Conflict between TSIG RFC and GSS-API documents To: Edward Lewis Cc: Erik Nordmark , =?iso-8859-1?Q?=D3lafur_Gudmundsson/DNSEXT_co-chair?= , namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I would ask that the GSS-TSIG document not only say that it updates > the TSIG spec but that the document also contains the suggested > change to the TSIG document. This is the approach followed in other > DNSSEC documents. That was what I meant (but failed to explicitly say). 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. archive: From owner-namedroppers@ops.ietf.org Mon Feb 10 04:10:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01136 for ; Mon, 10 Feb 2003 04:10:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18i9mF-000IdK-00 for namedroppers-data@psg.com; Mon, 10 Feb 2003 00:58:59 -0800 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by psg.com with esmtp (Exim 3.36 #1) id 18i9mD-000Id7-00; Mon, 10 Feb 2003 00:58:57 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA10416; Mon, 10 Feb 2003 00:58:54 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h1A8wnP21735; Mon, 10 Feb 2003 09:58:49 +0100 (MET) Date: Mon, 10 Feb 2003 09:55:10 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: draft-ietf-dnsext-unknown-rrs-04.txt To: Andreas Gustafsson Cc: Erik Nordmark , ogud@ogud.com, randy@psg.com, namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" <200302071959.h17JxDT14464@guava.araneus.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Yes. RFC2065 explicitly allowed compression of names in SIG and NXT > records, and this is no longer allowed per the unknown-RRs draft. But this isn't consistent with draft-ietf-dnsext-dnssec-records-02.txt which allows compression of SIG and NXT. Seems like the WG needs to figure out whether they want to allow or prohibit compression in SIG and NXT. And the WG might also want to figure out how to avoid having the AD be the only one that reads the documents for consistency :-)/2 > As for "perhaps others", I could find one other case where an RR > specification explicitly allows compression: RFC2163 allows > compression in the PX records, which appears to be in direct conflict > with the RFC1035 statement that "Pointers can only be used for > occurances of a domain name where the format is not class specific" > since RFC2163 restricts the PX record to the IN class. > > > If so the document should explicitly state this > > and also add an "updates RFC 2535" up front. > > I will add this and "updates RFC2163". It should also have a paragraph which says exactly what it is updating e.g. "RFC 2163 allows compression of the xyz field in PX records which is no longer permitted according to this document ..." > > For all other RR types, the canonical form is hereby changed such > > that no downcasing of embedded domain names takes place. The owner > > name is always set to lower case according to the DNS rules for > > character comparisons, regardless of the RR type. > > > > It would be useful to explicitly list the RR types to which this change > > applies. > > That's not really practical since there is more than 65000 of them. > While you could attempt to list the currently allocated post-RFC2915 > types, such a list would soon become inaccurate as additional types > are allocated. I wasn't asking about listing all current and potential future RRs. I'm asking about a specification of what "hereby changed" actually means for an implementor. Being able to list the RRs which are subject to this change seems like a requirement. If you don't have the list how can we guage the impact of this change? > > Nits (by themselves not necessitating an updated I-D at this point in time): > > The references should be split into normative and non-normative. > > Will do. It appears there have been quite a number of changes to the > I-D requirements since the initial publication of the draft... Yep. This particular one about separating references is from the rfc-editor. > > A boilerplate IPR section should be added. > > Can you please point me to a document describing this requirement and > the form of the required boilerplate? http://www.ietf.org/ID-nits.html 1.2 says: # IPR notices From RFC 2026 sec 10.4 (A) and 10.4(B) and possibly 10.4(D) 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. archive: From owner-namedroppers@ops.ietf.org Mon Feb 10 04:33:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01670 for ; Mon, 10 Feb 2003 04:33:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iA8N-000JFt-00 for namedroppers-data@psg.com; Mon, 10 Feb 2003 01:21:51 -0800 Received: from ms1.nttdata.co.jp ([163.135.193.232]) by psg.com with esmtp (Exim 3.36 #1) id 18iA8G-000JFg-00 for namedroppers@ops.ietf.org; Mon, 10 Feb 2003 01:21:44 -0800 Received: from mail0.nttdata.co.jp ([163.135.10.20]) by ms1.nttdata.co.jp (8.9.3/3.7W-NTTDATA-TOP-01/14/03) with ESMTP id SAA16449; Mon, 10 Feb 2003 18:21:33 +0900 (JST) Received: from noanetmx0.noanet.nttdata.co.jp (localhost [127.0.0.1]) by mail0.nttdata.co.jp (8.9.3/3.7W-NTTDATA-TOP-11/07/02) with ESMTP id SAA27972; Mon, 10 Feb 2003 18:21:32 +0900 (JST) Received: from noanet01.noanet.nttdata.co.jp (noanet01.noanet.nttdata.co.jp [10.1.49.11]) by noanetmx0.noanet.nttdata.co.jp (8.9.3/3.7W) with ESMTP id SAA29686; Mon, 10 Feb 2003 18:21:31 +0900 (JST) Received: from nttdata.co.jp (10.8.131.50 [10.8.131.50]) by noanet01.noanet.nttdata.co.jp with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DVMRC26H; Mon, 10 Feb 2003 18:21:32 +0900 Message-ID: <3E476F48.4020001@nttdata.co.jp> Date: Mon, 10 Feb 2003 18:22:16 +0900 From: Tatsuya Baba User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; ja-JP; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: ja MIME-Version: 1.0 To: "Hallam-Baker, Phillip" CC: namedroppers@ops.ietf.org Subject: Re: I-D regarding access control in DNS References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_05_08,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Phillip, thank you for your comments. Hallam-Baker, Phillip wrote: > Attempting to move from a public protocol to a private one is difficult. > > A particular problem that you would face is the fact that > implementations are likely to cache information and forward it in ways > that do not conform with the access control policy that you are > attempting to impose. I understand that there is a caching problem (section 3.2.3). There might be implementations that cache RRs whose TTL is zero. I think that direct communication between client and server, bypassing caching name server, is needed. > If you really want to do this you will also need privacy enhancements to > the DNS protocol. So you are going to end up requiring a key agreement. > So why not do a key agreement against a separate service, perform any > access control you might want to do at that point and then use a > cryptographic encapsulation? > > That would appear to describe IPSEC. If IPsec is applicable for this, I think it is OK. In this case, resolver must control IPsec policy. For example, when AC-aware client accesses to an RRset on AC-aware server, it should use IPsec. But when it accesses to an RRset on normal name server, it should not use IPsec. > Incidentally the lack of access control is one reason why it is not a > good idea to attempt to lard every possible lookup function into the > DNS. AC-aware resolver usually behaves as a normal resolver. When the host lookups RRs in access-controlled zones, it uses SIG(0) for authentication. -- Tatsuya Baba >>-----Original Message----- >>From: Tatsuya Baba [mailto:babatt@nttdata.co.jp] >>Sent: Wednesday, February 05, 2003 10:14 AM >>To: namedroppers@ops.ietf.org >>Subject: I-D regarding access control in DNS >> >> >>Hi all, >> >>I wrote an I-D regarding access control in DNS. >> >> draft-baba-dnsext-acl-reqts-00.txt >> >>I know that DNSSEC specification states "the DNS design >>philosophy calls >>for all DNS data to be public." However, I also know that there are >>many people who would like to control access to DNS data. >> >>Is there anyone who is interested in this area? >> >>Any comments, questions, or corrections are appreciated. >> >>Regards. >> >>-- Tatsuya Baba -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 10 04:40:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01980 for ; Mon, 10 Feb 2003 04:40:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iAEH-000JOS-00 for namedroppers-data@psg.com; Mon, 10 Feb 2003 01:27:57 -0800 Received: from ms1.nttdata.co.jp ([163.135.193.232]) by psg.com with esmtp (Exim 3.36 #1) id 18iAEE-000JO5-00 for namedroppers@ops.ietf.org; Mon, 10 Feb 2003 01:27:54 -0800 Received: from mail0.nttdata.co.jp ([163.135.10.20]) by ms1.nttdata.co.jp (8.9.3/3.7W-NTTDATA-TOP-01/14/03) with ESMTP id SAA18132; Mon, 10 Feb 2003 18:27:50 +0900 (JST) Received: from noanetmx0.noanet.nttdata.co.jp (localhost [127.0.0.1]) by mail0.nttdata.co.jp (8.9.3/3.7W-NTTDATA-TOP-11/07/02) with ESMTP id SAA29081; Mon, 10 Feb 2003 18:27:49 +0900 (JST) Received: from noanet01.noanet.nttdata.co.jp (noanet01.noanet.nttdata.co.jp [10.1.49.11]) by noanetmx0.noanet.nttdata.co.jp (8.9.3/3.7W) with ESMTP id SAA01193; Mon, 10 Feb 2003 18:27:48 +0900 (JST) Received: from nttdata.co.jp (10.8.131.50 [10.8.131.50]) by noanet01.noanet.nttdata.co.jp with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DVMRC29F; Mon, 10 Feb 2003 18:27:48 +0900 Message-ID: <3E4770C1.6050904@nttdata.co.jp> Date: Mon, 10 Feb 2003 18:28:33 +0900 From: Tatsuya Baba User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; ja-JP; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: ja MIME-Version: 1.0 To: Scott Rose CC: namedroppers@ops.ietf.org Subject: Re: I-D regarding access control in DNS References: <3E412A47.70607@nttdata.co.jp> <003a01c2cd3b$a4979fc0$b9370681@barnacle> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-3.4 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_02_03,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Scott, thank you for your comments. Scott Rose wrote: > I don't know if this is something the WG should be looking at. Besides > making a decision not to include confidentiality into the DNSSEC extensions > and I believe there are good reasons not too: > > 1. Many DNS implementations have some sort of acl functionality built in. > It is also easier to do access control outside of the DNS protocol. Yes. I know that BIND has access control functionality based on TSIG, but I think that TSIG does not scale. Moreover, BIND controls access based on entire zone (not indivisual RRset). But I don't know about other implementations. > 2. IPSec can be used to provide confidentiality at a lower level (hard to > imagine DNS would be the only network traffic that a network wants > encrypted). If the authoritative name server is also deployed in the network protected by IPsec, this is the case. IPsec can be used to provide confidentiality if resolver can control IPsec policy and set up security associations between clients and authoritative name servers when required. But I think it is difficult. > minor problems > 3. New records will have to be introduced for the ACL (TXT RRs probably > won't do), Yes. I think new RRs should be introduced. > 4. new RCODEs would have to be introduced/redefined for security. That > might affect backwards compatibility when older resolvers try to communicate > with a AC aware server. It might be, but I would like to avoid discussions about actual protocols now. I think this functionality should not affect existing resolvers. > I do not believe that the benefit of adding this functionality outweights > the cost and burden it would place on the DNS. This benefit already exists > to some degree by other protocols and implementations. > > Scott It is not required to introduce this functionaly on root/TLD servers. Only those who want to control access to RRsets on their name servers should introduce this functionality on their servers and their user's clients. To summarize draft, 1) client identification and authentication using SIG(0) (or TSIG) 2) direct communication between client and server (bypassing caching name server) 3) ACL in zone file using new RR (or TXT RR?) 4) DNS message encryption using new RR (or IPsec?) Above (1) and (2) do not affect existing DNS protocol. (3) and (4) require standard action, but if TXT RR and IPsec can be used for this, no standard action is needed. This draft is intended for starting point of discussions. Any comments are appreciated. -- Tatsuya Baba > ----- Original Message ----- > From: "Tatsuya Baba" > To: > Sent: Wednesday, February 05, 2003 10:14 AM > Subject: I-D regarding access control in DNS > > > >>Hi all, >> >>I wrote an I-D regarding access control in DNS. >> >> draft-baba-dnsext-acl-reqts-00.txt >> >>I know that DNSSEC specification states "the DNS design philosophy calls >>for all DNS data to be public." However, I also know that there are >>many people who would like to control access to DNS data. >> >>Is there anyone who is interested in this area? >> >>Any comments, questions, or corrections are appreciated. >> >>Regards. >> >>-- Tatsuya Baba -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 10 05:51:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03863 for ; Mon, 10 Feb 2003 05:51:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iBTM-000L9n-00 for namedroppers-data@psg.com; Mon, 10 Feb 2003 02:47:36 -0800 Received: from [2002:c08b:2e21:3:250:baff:fe2d:b704] (helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 3.36 #1) id 18iBTD-000L9W-00 for namedroppers@ops.ietf.org; Mon, 10 Feb 2003 02:47:33 -0800 Received: from sandelman.ottawa.on.ca ([2002:c08b:2e21:2:204:76ff:fe2d:8c]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h17IHdL18667 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Fri, 7 Feb 2003 13:17:41 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h17IHbFZ025625 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Fri, 7 Feb 2003 13:17:39 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h17IHZGL025621 for ; Fri, 7 Feb 2003 13:17:37 -0500 Message-Id: <200302071817.h17IHZGL025621@marajade.sandelman.ottawa.on.ca> To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: DNSSEC Opt-in In-reply-to: Your message of "Fri, 07 Feb 2003 12:50:58 +0100." <20030207125058.5525498e.olaf@ripe.net> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 07 Feb 2003 13:17:35 -0500 From: Michael Richardson X-Spam-Status: No, hits=1.2 required=5.0 tests=IN_REP_TO,LINES_OF_YELLING,OPT_IN,PGP_SIGNATURE, SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Olaf" == Olaf M Kolkman writes: >> I wonder if the final zone files, plus public and private keys from the >> opt-in workshop could be made available fot FTP somewhere? Olaf> As the setup was distributed over many laptops and the laptop have Olaf> dispersed this is at this point close to impossible. well, perhaps we can try. Three pieces out of ten is better than zero. Olaf> I think you have a good point. Any future workshop should record all Olaf> zonefiles and keys. Maybe it's time to write up an I-D (BCP style) on Olaf> test setups. (Or is there allready an RFC) Yes, we need to do this. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPkP4M4qHRg3pndX9AQE62wQAj2F6qJFE/Q8fiHTdV467aSyKnWcZq3k6 8XCwzDPdJAi2lsEfXW7sVlrENDxlAZKbbMtsNo6qmLwrFoFikckW383bjlMpg42+ WOknWSnW3er7jNqU1ds5IQ6u+B0Ck1WuEF11QAyXgGO5CpHTn0BNlQQQwyXCk5fw Yo7dNINdyZI= =mYN4 -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 10 06:07:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04251 for ; Mon, 10 Feb 2003 06:07:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iBm3-000Lc4-00 for namedroppers-data@psg.com; Mon, 10 Feb 2003 03:06:55 -0800 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 18iBm1-000Lbk-00 for namedroppers@ops.ietf.org; Mon, 10 Feb 2003 03:06:53 -0800 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1AB6an05990; Mon, 10 Feb 2003 18:06:37 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1AB68b12876; Mon, 10 Feb 2003 18:06:15 +0700 (ICT) From: Robert Elz To: Tatsuya Baba cc: "Hallam-Baker, Phillip" , namedroppers@ops.ietf.org Subject: Re: I-D regarding access control in DNS In-Reply-To: <3E476F48.4020001@nttdata.co.jp> References: <3E476F48.4020001@nttdata.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Feb 2003 18:06:08 +0700 Message-ID: <12874.1044875168@munnari.OZ.AU> X-Spam-Status: No, hits=-0.5 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Mon, 10 Feb 2003 18:22:16 +0900 From: Tatsuya Baba Message-ID: <3E476F48.4020001@nttdata.co.jp> | I think that direct communication between client and server, bypassing | caching name server, is needed. Aside from that defeating the whole purpose of DNS caching, anything that were to require that is going to fail in the world as it is. There are way too many nets that block all packets to/from port 53, other than those going to/from the known DNS cache(s) to ever reasonably expect random clients to be able to talk directly to DNS servers. Other nets silently redirect packets aimed at port 53 to a cache instead of whatever IP address they were previously directed at. 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. archive: From owner-namedroppers@ops.ietf.org Mon Feb 10 06:23:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04496 for ; Mon, 10 Feb 2003 06:23:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iByW-000Lvt-00 for namedroppers-data@psg.com; Mon, 10 Feb 2003 03:19:48 -0800 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 18iByS-000Lvc-00 for namedroppers@ops.ietf.org; Mon, 10 Feb 2003 03:19:44 -0800 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.6/8.12.6/Debian-7) with ESMTP id h1ABJA4n016578; Mon, 10 Feb 2003 12:19:10 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.6/8.12.6/Debian-7) with ESMTP id h1ABJAaw016575; Mon, 10 Feb 2003 12:19:10 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Mon, 10 Feb 2003 12:19:10 +0100 (CET) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: Robert Elz cc: Tatsuya Baba , "Hallam-Baker, Phillip" , namedroppers@ops.ietf.org Subject: Re: I-D regarding access control in DNS In-Reply-To: <12874.1044875168@munnari.OZ.AU> Message-ID: References: <3E476F48.4020001@nttdata.co.jp> <12874.1044875168@munnari.OZ.AU> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-3.7 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT_PINE,X_AUTH_WARNING version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 10 Feb 2003, Robert Elz wrote: > Date: Mon, 10 Feb 2003 18:22:16 +0900 > From: Tatsuya Baba > Message-ID: <3E476F48.4020001@nttdata.co.jp> > > | I think that direct communication between client and server, bypassing > | caching name server, is needed. > > Aside from that defeating the whole purpose of DNS caching, anything > that were to require that is going to fail in the world as it is. > > There are way too many nets that block all packets to/from port 53, > other than those going to/from the known DNS cache(s) to ever > reasonably expect random clients to be able to talk directly to DNS > servers. > > Other nets silently redirect packets aimed at port 53 to a cache > instead of whatever IP address they were previously directed at. And for the rest of the nets that do not do the above, it would not scale. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 10 10:05:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11474 for ; Mon, 10 Feb 2003 10:05:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iFGe-0000gN-00 for namedroppers-data@psg.com; Mon, 10 Feb 2003 06:50:44 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 18iFGZ-0000g4-00 for namedroppers@ops.ietf.org; Mon, 10 Feb 2003 06:50:39 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h1AEoaYm090871; Mon, 10 Feb 2003 09:50:36 -0500 (EST) Received: from [192.35.165.240] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id JAA22883; Mon, 10 Feb 2003 09:50:34 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Mon, 10 Feb 2003 07:48:16 -0700 To: Erik Nordmark From: Edward Lewis Subject: Re: Q: Conflict between TSIG RFC and GSS-API documents Cc: Edward Lewis , Erik Nordmark , =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk okey-dokey. At 9:30 +0100 2/10/03, Erik Nordmark wrote: >> I would ask that the GSS-TSIG document not only say that it updates >> the TSIG spec but that the document also contains the suggested >> change to the TSIG document. This is the approach followed in other >> DNSSEC documents. > >That was what I meant (but failed to explicitly say). > > Erik -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 10 11:30:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14586 for ; Mon, 10 Feb 2003 11:30:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iGiE-0003BO-00 for namedroppers-data@psg.com; Mon, 10 Feb 2003 08:23:18 -0800 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by psg.com with esmtp (Exim 3.36 #1) id 18iGiB-0003BB-00 for namedroppers@ops.ietf.org; Mon, 10 Feb 2003 08:23:15 -0800 Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1AGNANh009669; Mon, 10 Feb 2003 11:23:11 -0500 (EST) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-75.cisco.com [161.44.150.75]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA02979; Mon, 10 Feb 2003 11:23:10 -0500 (EST) Message-Id: <4.3.2.7.2.20030210111614.00bb13d0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 10 Feb 2003 11:23:07 -0500 To: dhcwg@ietf.org, , From: Ralph Droms Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-Reply-To: References: <4.3.2.7.2.20030205160932.051c5948@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Pekka, Thanks for the review and feedback; my comments are in line... And - for other members of the dhc, dnsext and ipv6 WGS: please respond to this last call notice with comments or an explicit ack to indicate you accept the draft as published. Thanks... - Ralph At 11:00 AM 2/6/2003 +0200, Pekka Savola wrote: >On Wed, 5 Feb 2003, Ralph Droms wrote: > > DHCPv6" . The last call will > > conclude on Friday, 2/21. > > > > Note that this is a parallel WG last call in the dhc, ipv6 and dnsext WGs. > > > > draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt describes two options for > > DHCPv6: the Domain Name Server option and the Domain Search List option. > > This document is being considered for Proposed Standard as an extension > > to the base DHCPv6 specification, and is available as > > > http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt > >A few comments; I haven't looked too deep into DHCPv6 to be able to >comment on those parts, but there are some definite need for revisal in >the doc..: > >2. Requirements > > The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, > [...] > >==> I'd put these under Introduction or Terminology sections, no use >having a separate section with a questionable title. > > option-length: Length of the 'options' field in octets; must be a > multiple of 16 Should read "Length of the list of DNS servers in octets; ..." >==> 'options' field has not been defined. Is it the whole option or just >the length of DNS-server address options (I assume so)? If the former, >there must be 32 bits of zero padding. Is it ok that the options aren't >64-bit aligned? It's OK that options are not 64-bit aligned; I don't think the padding is necessary. > The list of domain names in the 'searchstring' MUST be encoded as > specified in section "Representation and use of domain names" of the > DHCPv6 specification [4]. > >==> I didn't bother to check, but I guess this document also defines how >to pad the names to get some desired level of alignment? DHCPv6 doesn't require alignment of the contents of options. >6. Appearance of these options > > The Domain Name Server option MUST appear only in the following > messages: Solicit, Advertise, Request, Confirm, Renew, Rebind, > Information-Request, Reply. > > The Domain Search List option MUST appear only in the following > messages: Solicit, Advertise, Request, Confirm, Renew, Rebind, > Information-Request, Reply. > > >==> I would reword these differently, like: > > The Domain Name Server option MUST NOT appear in other than the following >messages: .... OK. >==> is it ok to server to give only one of these options but not the >other? Yes. >References > >==> split the references OK. > [4] Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and R. > Droms (ed.), "Dynamic Host Configuration Protocol for IPv6 > (DHCPv6)", draft-ietf-dhc-dhcpv6-23 (work in progress), February > 2002. > >==> update this draft version OK. >Author's Address > > Ralph Droms (ed.) > >==> the author is an editor, but the draft does not have acknowledgements >or contributors section. Just remove Editor if nobody else contributed to >the document. Thanks for noticing the oversight. I'll add an acknowledgments seciton. >-- >Pekka Savola "You each name yourselves king, yet the >Netcore Oy kingdom bleeds." >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 10 12:21:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16557 for ; Mon, 10 Feb 2003 12:21:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iHL9-0004cK-00 for namedroppers-data@psg.com; Mon, 10 Feb 2003 09:03:31 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 18iHL5-0004c4-00 for namedroppers@ops.ietf.org; Mon, 10 Feb 2003 09:03:27 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15654; Mon, 10 Feb 2003 11:59:42 -0500 (EST) Message-Id: <200302101659.LAA15654@ietf.org> To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: The IESG SUBJECT: Last Call: DNS Zone Transfer Protocol Clarifications to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 10 Feb 2003 11:59:42 -0500 X-Spam-Status: No, hits=1.6 required=5.0 tests=ALL_CAPS_HEADER,SPAM_PHRASE_00_01,TO_MALFORMED version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The IESG has received a request from the DNS Extensions Working Group to consider DNS Zone Transfer Protocol Clarifications as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-2-24. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dnsext-axfr-clarify-05.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. archive: From owner-namedroppers@ops.ietf.org Mon Feb 10 12:36:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17416 for ; Mon, 10 Feb 2003 12:36:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iHfg-0005Yh-00 for namedroppers-data@psg.com; Mon, 10 Feb 2003 09:24:44 -0800 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by psg.com with esmtp (Exim 3.36 #1) id 18iHfe-0005YV-00 for namedroppers@ops.ietf.org; Mon, 10 Feb 2003 09:24:42 -0800 Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1AHOcNh015648; Mon, 10 Feb 2003 12:24:38 -0500 (EST) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-75.cisco.com [161.44.150.75]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA08035; Mon, 10 Feb 2003 12:24:37 -0500 (EST) Message-Id: <4.3.2.7.2.20030210122210.00b665a0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 10 Feb 2003 12:24:34 -0500 To: "'dhcwg@ietf.org'" , namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com From: Ralph Droms Subject: Re: [dhcwg] Comments to draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-Reply-To: <1254192C94D3D411B8060008C7E6AEEBF9DF19@esealnt408> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Tony, Thanks for the feedback...I've responded in line. - Ralph At 08:58 AM 2/7/2003 +0100, EAB wrote: >In chapter 6. Appearance of these options > >'The Domain Name Server option MUST appear only in the following messages: >Solicit, Advertise, Request, Confirm, Renew, Rebind, Information-Request, >Reply.' > >Confirm message should be removed becaue it is not valid anymore. > >This is even valid for 'Domain Search List' option. Yes. >In References number 4, > >The draft should be update with the RFC number when you know it (for >"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"). OK. >// Tony >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 10 13:26:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19403 for ; Mon, 10 Feb 2003 13:26:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iIWm-0007eB-00 for namedroppers-data@psg.com; Mon, 10 Feb 2003 10:19:36 -0800 Received: from [2002:425c:4242:0:250:daff:fe82:1c39] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 18iIWf-0007Yj-00 for namedroppers@ops.ietf.org; Mon, 10 Feb 2003 10:19:33 -0800 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 8030118EC for ; Mon, 10 Feb 2003 13:18:56 -0500 (EST) Date: Mon, 10 Feb 2003 13:18:56 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-unknown-rrs-04.txt In-Reply-To: References: <200302071959.h17JxDT14464@guava.araneus.fi> User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030210181856.8030118EC@thrintun.hactrn.net> X-Spam-Status: No, hits=-1.0 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Presumably we could turn the question around and specify the list of RR types for which compression of DNS names in the RDATA -is- allowed. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 10 13:54:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20706 for ; Mon, 10 Feb 2003 13:54:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iIwb-0008iP-00 for namedroppers-data@psg.com; Mon, 10 Feb 2003 10:46:17 -0800 Received: from [208.237.135.240] (helo=imr1.ericy.com) by psg.com with esmtp (Exim 3.36 #1) id 18iIwY-0008g8-00 for namedroppers@ops.ietf.org; Mon, 10 Feb 2003 10:46:14 -0800 Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id h1AIjUd06705; Mon, 10 Feb 2003 12:45:30 -0600 (CST) Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id h1AIjUx03167; Mon, 10 Feb 2003 12:45:30 -0600 (CST) Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Mon, 10 Feb 2003 12:45:29 -0600 Message-ID: From: "Bernie Volz (EUD)" To: "'Ralph Droms'" , dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: RE: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconf ig-02.txt Date: Mon, 10 Feb 2003 12:43:54 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D134.5C6074C8" X-Spam-Status: No, hits=0.5 required=5.0 tests=EXCHANGE_SERVER,MAILTO_LINK,MIME_NULL_BLOCK, SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2D134.5C6074C8 Content-Type: text/plain; charset="ISO-8859-1" Ralph: All of the previous comments should be incorporated. But, in addition: Section 4 and 5 state that a "Server sends ... option to the DHCP client". However, the list of messages in which these options may appear includes client generated messages (Solicit, Request, Renew, Rebind, Information-Request). I believe that client generated messages can request these option codes in an ORO option, but should they include these options? There may be little harm in allowing them? Though it is difficult to see how they could appear in a Solicit even in that case. In section 7, for: Because the Domain Search List option may be used to spoof DNS name resolution in a way that cannot be detected by DNS security mechanisms like DNSSEC [5], DHCP clients and servers MUST use authenticated DHCP when a Domain Search List option is included in a DHCP message. Might it be better to instead state that a client MUST NOT install the Domain Search List unless the message was authenticated? This is cleaner as to what it requires a client and server to do. It is difficult for a client to know in advance whether a server will supply the option? The same might be true of the Domain Name Server option?? Otherwise, the draft looks fine and I would like to see it advanced. - Bernie Volz -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Monday, February 10, 2003 11:23 AM To: dhcwg@ietf.org; ipng@sunroof.eng.sun.com; namedroppers@ops.ietf.org Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Pekka, Thanks for the review and feedback; my comments are in line... And - for other members of the dhc, dnsext and ipv6 WGS: please respond to this last call notice with comments or an explicit ack to indicate you accept the draft as published. Thanks... - Ralph ------_=_NextPart_001_01C2D134.5C6074C8 Content-Type: text/html; charset="ISO-8859-1" RE: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt

Ralph:

All of the previous comments should be incorporated. But, in addition:

Section 4 and 5 state that a "Server sends ... option to the DHCP client".
However, the list of messages in which these options may appear includes
client generated messages (Solicit, Request, Renew, Rebind,
Information-Request).

I believe that client generated messages can request these option codes
in an ORO option, but should they include these options? There may be
little harm in allowing them? Though it is difficult to see how they
could appear in a Solicit even in that case.

In section 7, for:

   Because the Domain Search List option may be used to spoof DNS name
   resolution in a way that cannot be detected by DNS security
   mechanisms like DNSSEC [5], DHCP clients and servers MUST use
   authenticated DHCP when a Domain Search List option is included in a
   DHCP message.

Might it be better to instead state that a client MUST NOT install the Domain
Search List unless the message was authenticated? This is cleaner as to what
it requires a client and server to do. It is difficult for a client to know
in advance whether a server will supply the option?

The same might be true of the Domain Name Server option??

Otherwise, the draft looks fine and I would like to see it advanced.

- Bernie Volz

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Monday, February 10, 2003 11:23 AM
To: dhcwg@ietf.org; ipng@sunroof.eng.sun.com; namedroppers@ops.ietf.org
Subject: Re: [dhcwg] Re: WG last call on
draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt


Pekka,

Thanks for the review and feedback; my comments are in line...

And - for other members of the dhc, dnsext and ipv6 WGS: please
respond to this last call notice with comments or an explicit
ack to indicate you accept the draft as published.  Thanks...

- Ralph

------_=_NextPart_001_01C2D134.5C6074C8-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 10 13:55:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20769 for ; Mon, 10 Feb 2003 13:55:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iJ0L-0008u6-00 for namedroppers-data@psg.com; Mon, 10 Feb 2003 10:50:09 -0800 Received: from [2001:4f8:3:bb:2e0:81ff:fe23:7b5a] (helo=as.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 18iJ0F-0008rr-00 for namedroppers@ops.ietf.org; Mon, 10 Feb 2003 10:50:03 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 94E71379E40 for ; Mon, 10 Feb 2003 18:49:49 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-unknown-rrs-04.txt In-Reply-To: Message from Erik Nordmark of "Mon, 10 Feb 2003 09:55:10 +0100." X-Mailer: MH-E 7.2; nmh 1.0.4; GNU Emacs 21.2.1 Date: Mon, 10 Feb 2003 18:49:49 +0000 Message-Id: <20030210184949.94E71379E40@as.vix.com> X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Seems like the WG needs to figure out whether they want to allow or > prohibit compression in SIG and NXT. there are two cases, which might be different. one case is when dnssec is signalled by a requestor, causing a responder to add SIG and NXT RR's to the response to prove the validity of the answer. the other case is when a normal query (including zone transfers) are used, targetting or including SIG and NXT RR's. in the first case, compression could be used, since there is no reason to believe that the requestor will not understand compression. dnssec signalling is a hop by hop affair, based on EDNS0 and new flag bits. we are going to change the flag bits or even type codes to ensure that the 2065 or 2535 implementations will not be confused by new things like DS. in the second case, compression must not be used, since there is every reason to believe that the requestor will not know the details of the RDATA layout of these record types, and they need to be able to handle them as opaque data, including storing zones on disk, caching and reusing the data in responding to recursive queries, and so on. the question is, whether compression of the names buys us enough octets to pay for the complexity of a strategy like "you can use compression if using this data in an EDNS0-signalled proof, but not in response to a normal query or transfer". my own thinking on this is, "not." that's because the names aren't always going to have similarities with other names in the same message (making compression nonbneficial), and also even a successful compression delta will be dwarfed by the size of the signature and key data (making compression irrelevant overall). > And the WG might also want to figure out how to avoid having the AD be > the only one that reads the documents for consistency :-)/2 one of the things which has characterized the long continuing failure of dnssec as a standard is a lack of openness. people mostly won't read drafts if they believe that they're being written in a star chamber anyway. that said, i apologize as an individual for humming in the positive on this draft, without having checked it for consistency. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 10 14:27:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21654 for ; Mon, 10 Feb 2003 14:27:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iJUb-000AC7-00 for namedroppers-data@psg.com; Mon, 10 Feb 2003 11:21:25 -0800 Received: from gusto.araneus.fi ([204.152.186.164]) by psg.com with esmtp (Exim 3.36 #1) id 18iJUX-000ABt-00 for namedroppers@ops.ietf.org; Mon, 10 Feb 2003 11:21:21 -0800 Received: from guava.araneus.fi (adsl-63-197-0-204.dsl.snfc21.pacbell.net [63.197.0.204]) by gusto.araneus.fi (8.11.6/8.11.6) with ESMTP id h1AJLJZ29172; Mon, 10 Feb 2003 11:21:19 -0800 (PST) Received: (from gson@localhost) by guava.araneus.fi (8.11.6/8.11.6) id h1AJLIW17691; Mon, 10 Feb 2003 11:21:18 -0800 (PST) Date: Mon, 10 Feb 2003 11:21:18 -0800 (PST) Message-Id: <200302101921.h1AJLIW17691@guava.araneus.fi> To: Rob Austein Cc: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-unknown-rrs-04.txt In-Reply-To: <20030210181856.8030118EC@thrintun.hactrn.net> References: <200302071959.h17JxDT14464@guava.araneus.fi> <20030210181856.8030118EC@thrintun.hactrn.net> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Rob Austein writes: > Presumably we could turn the question around and specify the list of > RR types for which compression of DNS names in the RDATA -is- allowed. Erik Nordmark is not asking about compression (section 4), he is asking about DNSSEC canonicalization (section 7). The lists of RRs pertaining by these two issues (and their complements) are different. See the discussion on namedroppers on October 25, 2002. -- 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. archive: From owner-namedroppers@ops.ietf.org Mon Feb 10 14:40:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22201 for ; Mon, 10 Feb 2003 14:40:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iJc9-000ATA-00 for namedroppers-data@psg.com; Mon, 10 Feb 2003 11:29:13 -0800 Received: from momotombo.techfak.uni-bielefeld.de ([129.70.136.107]) by psg.com with esmtp (Exim 3.36 #1) id 18iJbd-000ARM-00 for namedroppers@ops.ietf.org; Mon, 10 Feb 2003 11:28:41 -0800 Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.11.6+Sun/8.11.6/TechFak/pk+ro20010720) with ESMTP id h1AJRdU09073; Mon, 10 Feb 2003 20:27:39 +0100 (MET) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.6+Sun/8.9.1) with SMTP id h1AJRdu16843; Mon, 10 Feb 2003 20:27:39 +0100 (MET) Message-Id: <200302101927.h1AJRdu16843@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: Ralph Droms Cc: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-reply-to: Your message of "Wed, 05 Feb 2003 16:17:49 EST." <4.3.2.7.2.20030205160932.051c5948@funnel.cisco.com> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Date: Mon, 10 Feb 2003 20:27:39 +0100 From: Peter Koch X-Spam-Status: No, hits=-0.2 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_05_08, X_AUTH_WARNING version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt describes two options for > DHCPv6: the Domain Name Server option and the Domain Search List > This document uses terminology specific to IPv6 and DHCPv6 as defined > in section "Terminology" of the DHCP specification. Might want to add an explicit normative reference here? > 4. Domain Name Server option > > The Domain Name Server option provides a list of one or more IP > addresses of DNS servers to which a client's DNS resolver MAY send From a purist's point of view I'm tempted to say that you're not really looking for a DNS server here but instead for a (list of) recursive resolvers. > DNS-server: IP address of DNS server I did not follow the DHCPv6 effort too close, so I must admit not knowing the usual "culture", but wouldn't it be better to say IPv6 address here? > A server sends a Domain Search List option to the DHCP client to > specify the domain search list the client is to use when resolving > hostnames with DNS. This option does not apply to other name > resolution mechanisms. The draft does not say for which kind of domain names the client is expected to process the list, i.e. one-label names only, n-label names (how to communicate the 'n', aka 'ndots', then?) or whether this is left to the application(s). > Because the Domain Search List option may be used to spoof DNS name > resolution in a way that cannot be detected by DNS security > mechanisms like DNSSEC [5], DHCP clients and servers MUST use Apart from the sad fact that DNSSEC isn't yet deployed I don't see why it wouldn't be able to detect spoofing. If, however, you want to say that using domain names in the search list you don't control is a dangerous thing, that could be emphazised by a reference to RFC 1535. > authenticated DHCP when a Domain Search List option is included in a > DHCP message. Why is this a MUST while there's a SHOULD only for the server option? -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. archive: From owner-namedroppers@ops.ietf.org Mon Feb 10 16:19:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26296 for ; Mon, 10 Feb 2003 16:19:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iL4r-000EOf-00 for namedroppers-data@psg.com; Mon, 10 Feb 2003 13:02:57 -0800 Received: from pushme.nist.gov ([129.6.16.92] helo=postmark.nist.gov) by psg.com with esmtp (Exim 3.36 #1) id 18iL4n-000EOP-00 for namedroppers@ops.ietf.org; Mon, 10 Feb 2003 13:02:53 -0800 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h1AL2Wf1013024 for ; Mon, 10 Feb 2003 16:02:32 -0500 (EST) Message-ID: <00d901c2d147$bb2f5600$b9370681@barnacle> From: "Scott Rose" To: Subject: Questions on the new DNSSEC spec Date: Mon, 10 Feb 2003 16:02:33 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=1.0 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT_OE version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit While the newest version of the RR draft is being edited, there are points that need to be agreed on before they make it into the spec. These issues are thought to be too minor on their own to warrant a full fledged Internet Draft describing these changes. Q1: From the current discussion on name compression and DNSSEC RRs: The text describing the "signer's name" of the SIG RR and "next domain name" of the NXT field should be changed along the lines of the Unknown RR types draft. That is, name compression MUST NOT be used in these fields when sending on the wire, but a resolver should be able to handle name compression in these fields if they encounter it without error. a. "MUST NOT compress DNS names found in the RDATA" is the paraphrased text in the -04 version of the unknown RRs draft. Q2: Crypto Algorithm status: The new (proposed) algorithm status is - VALUE Algorithm RFC STATUS 0 Reserved 1 RSA/MD5 NOT RECOMMENDED 2 Diffie-Hellman OPTIONAL 3 DSA OPTIONAL 4 elliptic curve OPTIONAL 5 RSA/SHA1 REQUIRED 6-251 available for assignment - 252 indirect OPTIONAL 253 private OPTIONAL 254 private OPTIONAL 255 reserved The changes are that DSA is made OPTIONAL and RSA/SHA1 is now the only mandatory to implement algorithm. Everything else remains as it was. The WG needs to reach consensus on these issues, silence will be assumed to mean that the changes are acceptable. I don't think we need a hard deadline on these issues, but answers ASAP please. Scott -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 10 16:25:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26579 for ; Mon, 10 Feb 2003 16:25:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iLHv-000Ez1-00 for namedroppers-data@psg.com; Mon, 10 Feb 2003 13:16:27 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 18iLHr-000Eyn-00 for namedroppers@ops.ietf.org; Mon, 10 Feb 2003 13:16:23 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h1ALGMYm005980; Mon, 10 Feb 2003 16:16:22 -0500 (EST) Received: from [192.35.165.240] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id QAA01892; Mon, 10 Feb 2003 16:16:21 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <20030210184949.94E71379E40@as.vix.com> References: <20030210184949.94E71379E40@as.vix.com> Date: Mon, 10 Feb 2003 14:16:26 -0700 To: Paul Vixie From: Edward Lewis Subject: Re: draft-ietf-dnsext-unknown-rrs-04.txt Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-1.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 18:49 +0000 2/10/03, Paul Vixie wrote: >> Seems like the WG needs to figure out whether they want to allow or >> prohibit compression in SIG and NXT. > >the question is, whether compression of the names buys us enough octets >to pay for the complexity of a strategy like "you can use compression if >using this data in an EDNS0-signalled proof, but not in response to a >normal query or transfer". my own thinking on this is, "not." that's >because the names aren't always going to have similarities with other >names in the same message (making compression nonbneficial), and also >even a successful compression delta will be dwarfed by the size of the >signature and key data (making compression irrelevant overall). I was going to argue with Paul until I saw the above paragraph. Compression in these two records is not worth the cost needed to be able to do it. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 10 17:23:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28289 for ; Mon, 10 Feb 2003 17:23:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iMEG-000HbN-00 for namedroppers-data@psg.com; Mon, 10 Feb 2003 14:16:44 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18iME5-000HaL-00; Mon, 10 Feb 2003 14:16:34 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18iME3-000AJb-00; Mon, 10 Feb 2003 17:16:31 -0500 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 10 Feb 2003 17:16:30 -0500 To: "Scott Rose" Cc: Subject: Re: Questions on the new DNSSEC spec References: <00d901c2d147$bb2f5600$b9370681@barnacle> Message-Id: X-Spam-Status: No, hits=-0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Q1: From the current discussion on name compression and DNSSEC RRs: The > text describing the "signer's name" of the SIG RR and "next domain name" of > the NXT field should be changed along the lines of the Unknown RR types > draft. That is, name compression MUST NOT be used in these fields when > sending on the wire, but a resolver should be able to handle name > compression in these fields if they encounter it without error. > a. "MUST NOT compress DNS names found in the RDATA" is the > paraphrased text in the -04 version of the unknown RRs draft. uh, scott. i miss that the above is a question. i believe the goal here is too seek consensus in the wg, and your words are more like an assertion. i know this is unintentional, but i am sure it will be misread by the black helicopter afficianados and maybe even normal humans as well. folk, please consider these to be questions, and the proposed answers to be simply scott's (and maybe others' and maybe not) opinions. 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. archive: From owner-namedroppers@ops.ietf.org Tue Feb 11 00:12:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08930 for ; Tue, 11 Feb 2003 00:12:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iSaa-0006e2-00 for namedroppers-data@psg.com; Mon, 10 Feb 2003 21:04:12 -0800 Received: from [3ffe:501:100f:0:200:f8ff:fe01:61cf] (helo=shuttle.wide.toshiba.co.jp) by psg.com with esmtp (Exim 3.36 #1) id 18iSaY-0006dj-00 for namedroppers@ops.ietf.org; Mon, 10 Feb 2003 21:04:10 -0800 Received: from localhost ([3ffe:501:4819:2000:200:39ff:fe10:85d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id h1B53vP54529; Tue, 11 Feb 2003 14:03:57 +0900 (JST) Date: Tue, 11 Feb 2003 14:03:58 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Cc: dhcwg@ietf.org, , Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-Reply-To: <4.3.2.7.2.20030210111614.00bb13d0@funnel.cisco.com> References: <4.3.2.7.2.20030205160932.051c5948@funnel.cisco.com> <4.3.2.7.2.20030210111614.00bb13d0@funnel.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 15 X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> On Mon, 10 Feb 2003 11:23:07 -0500, >>>>> Ralph Droms said: > And - for other members of the dhc, dnsext and ipv6 WGS: please > respond to this last call notice with comments or an explicit > ack to indicate you accept the draft as published. Thanks... I'm okay to publish the draft. I've reviewed it, and implemented the Domain Name Server option. The specification is useful and important, and (at least regarding the part I implemented) working well. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.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. archive: From owner-namedroppers@ops.ietf.org Tue Feb 11 03:32:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23522 for ; Tue, 11 Feb 2003 03:32:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iVi2-000FFK-00 for namedroppers-data@psg.com; Tue, 11 Feb 2003 00:24:06 -0800 Received: from outpost.ds9a.nl ([213.244.168.210]) by psg.com with esmtp (Exim 3.36 #1) id 18iVhw-000FF3-00 for namedroppers@ops.ietf.org; Tue, 11 Feb 2003 00:24:01 -0800 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id E52F440F4; Tue, 11 Feb 2003 09:23:55 +0100 (CET) Date: Tue, 11 Feb 2003 09:23:55 +0100 From: bert hubert To: iesg@ietf.org Cc: namedroppers@ops.ietf.org Subject: Re: Last Call: DNS Zone Transfer Protocol Clarifications to Proposed Standard Message-ID: <20030211082355.GD14583@outpost.ds9a.nl> References: <200302101659.LAA15654@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200302101659.LAA15654@ietf.org> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-4.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MUTT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, Feb 10, 2003 at 11:59:42AM -0500, The IESG wrote: > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2003-2-24. This version of the draft looks just fine. I have no real issues with any of the content as far as I can see after reading it for an hour or so. Bert Hubert PowerDNS -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing & Traffic Control HOWTO http://netherlabs.nl Consulting -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 11 04:23:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24583 for ; Tue, 11 Feb 2003 04:23:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iWZY-000GX1-00 for namedroppers-data@psg.com; Tue, 11 Feb 2003 01:19:24 -0800 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 18iWZV-000GWo-00 for namedroppers@ops.ietf.org; Tue, 11 Feb 2003 01:19:22 -0800 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1B9Ixn11951; Tue, 11 Feb 2003 16:19:00 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1B9IOb19962; Tue, 11 Feb 2003 16:18:25 +0700 (ICT) From: Robert Elz To: Ralph Droms cc: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-Reply-To: <4.3.2.7.2.20030210111614.00bb13d0@funnel.cisco.com> References: <4.3.2.7.2.20030210111614.00bb13d0@funnel.cisco.com> <4.3.2.7.2.20030205160932.051c5948@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Feb 2003 16:18:24 +0700 Message-ID: <19960.1044955104@munnari.OZ.AU> X-Spam-Status: No, hits=-0.5 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Mon, 10 Feb 2003 11:23:07 -0500 From: Ralph Droms Message-ID: <4.3.2.7.2.20030210111614.00bb13d0@funnel.cisco.com> | And - for other members of the dhc, dnsext and ipv6 WGS: please | respond to this last call notice with comments or an explicit | ack to indicate you accept the draft as published. Thanks... With the various changes (mostly fairly minor) that have been suggested, it looks Ok to me. 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. archive: From owner-namedroppers@ops.ietf.org Tue Feb 11 05:03:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25426 for ; Tue, 11 Feb 2003 05:03:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iX7M-000I6B-00 for namedroppers-data@psg.com; Tue, 11 Feb 2003 01:54:20 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #1) id 18iX7I-000I5w-00; Tue, 11 Feb 2003 01:54:16 -0800 Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.5/8.11.6) with SMTP id h1B9rbAq016057; Tue, 11 Feb 2003 10:53:37 +0100 Date: Tue, 11 Feb 2003 10:53:37 +0100 From: "Olaf M. Kolkman" To: Derek Atkins Cc: Ted.Lemon@nominum.com, randy@psg.com, namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration Message-Id: <20030211105337.14244395.olaf@ripe.net> In-Reply-To: References: Organization: RIPE NCC X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.5 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > > You could do an additional validation where if someone wants to stuff > > a new valid into an old PTR record, the DNS server looks to see if the > > old FQDN in that PTR record still points back to the address referred > > to by the PTR record, and if it does, refuses the update. This > > prevents PTR record stealing. > > > > Is there some other attack I'm not thinking of here? > > I rightfully grab an address and go through the process. Then I go > offnet without removing my forward pointer. My "lease" expires. The > next person who happens to get my address can no longer get the PTR > entry because the old (stale) forward entry is still there. > Huhhh??? The host that is managing the addresses also manages the reverse tree. As soon as an address is assigned to a new MAC address the PTR should change to a default vallue or be dynamically updated by the new host. It would be a strange world if I would not be able to get a PTR RR because somebody else uses a stale forward mapping. --Olaf --------------------------------------------| Olaf M. Kolkman | www.ripe.net/disi -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 11 07:25:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01001 for ; Tue, 11 Feb 2003 07:25:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iZQn-000N4R-00 for namedroppers-data@psg.com; Tue, 11 Feb 2003 04:22:33 -0800 Received: from pushme.nist.gov ([129.6.16.92] helo=postmark.nist.gov) by psg.com with esmtp (Exim 3.36 #1) id 18iZQl-000N4E-00 for namedroppers@ops.ietf.org; Tue, 11 Feb 2003 04:22:31 -0800 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h1BCM2f1009986 for ; Tue, 11 Feb 2003 07:22:02 -0500 (EST) Message-ID: <007201c2d1c8$2ec4f7c0$b9370681@barnacle> From: "Scott Rose" To: References: <00d901c2d147$bb2f5600$b9370681@barnacle> Subject: Re: Questions on the new DNSSEC spec Date: Tue, 11 Feb 2003 07:22:02 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=0.1 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, TO_BE_REMOVED_REPLY,USER_AGENT_OE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I've learned from experience it is easier to ask yes/no answers than more general "what should we do". Otherwise, we will end up with too many different opinions. I will change the messages so that one question appears in a message. Scott ----- Original Message ----- From: "Randy Bush" To: "Scott Rose" Cc: Sent: Monday, February 10, 2003 5:16 PM Subject: Re: Questions on the new DNSSEC spec > > > > Q1: From the current discussion on name compression and DNSSEC RRs: The > > text describing the "signer's name" of the SIG RR and "next domain name" of > > the NXT field should be changed along the lines of the Unknown RR types > > draft. That is, name compression MUST NOT be used in these fields when > > sending on the wire, but a resolver should be able to handle name > > compression in these fields if they encounter it without error. > > a. "MUST NOT compress DNS names found in the RDATA" is the > > paraphrased text in the -04 version of the unknown RRs draft. > > uh, scott. i miss that the above is a question. i believe the goal > here is too seek consensus in the wg, and your words are more like an > assertion. i know this is unintentional, but i am sure it will be > misread by the black helicopter afficianados and maybe even normal > humans as well. > > folk, please consider these to be questions, and the proposed answers > to be simply scott's (and maybe others' and maybe not) opinions. > > 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. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 11 07:33:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01214 for ; Tue, 11 Feb 2003 07:33:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iZYm-000NNt-00 for namedroppers-data@psg.com; Tue, 11 Feb 2003 04:30:48 -0800 Received: from pushme.nist.gov ([129.6.16.92] helo=postmark.nist.gov) by psg.com with esmtp (Exim 3.36 #1) id 18iZYk-000NNg-00 for namedroppers@ops.ietf.org; Tue, 11 Feb 2003 04:30:46 -0800 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h1BCUUf1015037 for ; Tue, 11 Feb 2003 07:30:30 -0500 (EST) Message-ID: <007c01c2d1c9$5da52190$b9370681@barnacle> From: "Scott Rose" To: Subject: Q1: Should we allow name compression in the RDATA of DNSSEC RRs? Date: Tue, 11 Feb 2003 07:30:30 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=1.0 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT_OE version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Though it isn't just my opinion, there seems to be some concensus around the WG that name compression in the RDATA of the DNSSEC RRs (SIG and NXT). Generally, that it is a not something desired. Q: Should the text in the Resource Records draft of the DNSSEC spec be changed to indicated that name compression "SHOULD NOT" be used when sending security RRs over the wire? This only applies to the "signer's name" field of the SIG RR and "next domain name" of the NXT RR. note: "SHOULD NOT" would be the suggestion. "MUST NOT" may be too strong, but if that is the concensus, then that will be the language. The same requirements should not be applied to the resolver. i.e. that resolvers should still accept and process RRs that use name compression in the next domain name field of the NXT RR and signer's name of the SIG RR. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 11 07:43:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01928 for ; Tue, 11 Feb 2003 07:43:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iZia-000NnT-00 for namedroppers-data@psg.com; Tue, 11 Feb 2003 04:40:56 -0800 Received: from pushme.nist.gov ([129.6.16.92] helo=postmark.nist.gov) by psg.com with esmtp (Exim 3.36 #1) id 18iZiX-000Nn7-00 for namedroppers@ops.ietf.org; Tue, 11 Feb 2003 04:40:53 -0800 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h1BCeNf1018695 for ; Tue, 11 Feb 2003 07:40:23 -0500 (EST) Message-ID: <008801c2d1ca$bf14de10$b9370681@barnacle> From: "Scott Rose" To: Subject: Q2: crypto algorithm requirements for DNSSEC Date: Tue, 11 Feb 2003 07:40:23 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=1.0 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT_OE version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit There have been previous updates to the requirement levels of the cryptographic algorithms for DNSSEC (RFC 3110 updating RFC2535 for example). There has been previous talk on this list regarding dropping DSA as a mandatory to implement algorithm. Instead of writing a whole RFC just to propose making DSA optional and RSA/SHA1 the only required algorithm, it would be nice to seek consensus here. In other words, the new algorithm table from 2535 and 3110 would look like: code name 0 reserved 1 RSA/MD5 NOT RECOMMENDED 2 D-H OPTIONAL 3 DSA OPTIONAL 4 ECC(reserved) OPTIONAL 5 RSA/SHA1 REQUIRED 6-251 available for assignment 252 indirect OPTIONAL 253 private 254 private 255 reserved Q: Is the change of DSA to OPTIONAL acceptable? That will leave only RSA/SHA1 as the only mandatory to implement algorithm. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 11 08:44:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04599 for ; Tue, 11 Feb 2003 08:44:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iadA-00005Q-00 for namedroppers-data@psg.com; Tue, 11 Feb 2003 05:39:24 -0800 Received: from nic.crt.se ([193.12.107.10]) by psg.com with esmtp (Exim 3.36 #1) id 18iad7-00005C-00 for namedroppers@ops.ietf.org; Tue, 11 Feb 2003 05:39:21 -0800 Received: from mail.crt.se (postiljon.crt.se [172.16.1.14]) by nic.crt.se (Postfix) with ESMTP id A1A4B5284; Tue, 11 Feb 2003 14:39:15 +0100 (MET) Received: from crt.se (stargate.crt.se [172.16.0.11]) by mail.crt.se (Postfix) with ESMTP id 6FC011D99; Tue, 11 Feb 2003 14:39:15 +0100 (MET) Date: Tue, 11 Feb 2003 14:39:15 +0100 (CET) From: Jakob Schlyter To: Scott Rose Cc: namedroppers@ops.ietf.org Subject: Re: Q1: Should we allow name compression in the RDATA of DNSSEC RRs? In-Reply-To: <007c01c2d1c9$5da52190$b9370681@barnacle> Message-ID: References: <007c01c2d1c9$5da52190$b9370681@barnacle> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 11 Feb 2003, Scott Rose wrote: > Q: Should the text in the Resource Records draft of the DNSSEC spec be > changed to indicated that name compression "SHOULD NOT" be used when > sending security RRs over the wire? yes, but I would prefer a MUST NOT. jakob -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 11 08:45:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04638 for ; Tue, 11 Feb 2003 08:45:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iadv-00007p-00 for namedroppers-data@psg.com; Tue, 11 Feb 2003 05:40:11 -0800 Received: from nic.crt.se ([193.12.107.10]) by psg.com with esmtp (Exim 3.36 #1) id 18iads-000079-00 for namedroppers@ops.ietf.org; Tue, 11 Feb 2003 05:40:08 -0800 Received: from mail.crt.se (postiljon.crt.se [172.16.1.14]) by nic.crt.se (Postfix) with ESMTP id 324ED5284; Tue, 11 Feb 2003 14:40:07 +0100 (MET) Received: from crt.se (stargate.crt.se [172.16.0.11]) by mail.crt.se (Postfix) with ESMTP id E9D9D1D99; Tue, 11 Feb 2003 14:40:06 +0100 (MET) Date: Tue, 11 Feb 2003 14:40:06 +0100 (CET) From: Jakob Schlyter To: Scott Rose Cc: namedroppers@ops.ietf.org Subject: Re: Q2: crypto algorithm requirements for DNSSEC In-Reply-To: <008801c2d1ca$bf14de10$b9370681@barnacle> Message-ID: References: <008801c2d1ca$bf14de10$b9370681@barnacle> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 11 Feb 2003, Scott Rose wrote: > Q: Is the change of DSA to OPTIONAL acceptable? That will leave only > RSA/SHA1 as the only mandatory to implement algorithm. yes. jakob -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 11 10:12:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07718 for ; Tue, 11 Feb 2003 10:12:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ibu9-0003T4-00 for namedroppers-data@psg.com; Tue, 11 Feb 2003 07:01:01 -0800 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 18ibu3-0003Rk-00; Tue, 11 Feb 2003 07:00:55 -0800 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id KAA05082; Tue, 11 Feb 2003 10:00:48 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA17510; Tue, 11 Feb 2003 10:00:43 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id KAA15294; Tue, 11 Feb 2003 10:00:42 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id KAA26858; Tue, 11 Feb 2003 10:00:42 -0500 (EST) To: "Olaf M. Kolkman" Cc: Ted.Lemon@nominum.com, randy@psg.com, namedroppers@ops.ietf.org From: Derek Atkins Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration References: <20030211105337.14244395.olaf@ripe.net> Date: 11 Feb 2003 10:00:42 -0500 In-Reply-To: <20030211105337.14244395.olaf@ripe.net> Message-ID: Lines: 30 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-1.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,RCVD_IN_RELAYS_ORDB_ORG,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_GNUS_UA,X_OSIRU_OPEN_RELAY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Olaf M. Kolkman" writes: > Huhhh??? The host that is managing the addresses also manages the > reverse tree. As soon as an address is assigned to a new MAC address > the PTR should change to a default vallue or be dynamically updated by > the new host. You're thinking of a V4 world. Think "V6 Autoconfiguration". When using autoconfig the "host that is managing the address" is "MY HOST". My host, plugging into a v6 network, is certainly not in charge or managing the reverse tree. Not everyone in the v6 world is using DHCPv6. In fact the IETF in Atlanta certainly wasn't. However we still want "proper" dns in such a world. > It would be a strange world if I would not be able to get a PTR RR > because somebody else uses a stale forward mapping. Agreed, which is why I brought up the issue. > --Olaf -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.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. archive: From owner-namedroppers@ops.ietf.org Tue Feb 11 15:26:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17636 for ; Tue, 11 Feb 2003 15:26:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iglZ-000DsQ-00 for namedroppers-data@psg.com; Tue, 11 Feb 2003 12:12:29 -0800 Received: from [2001:470:1f00:ffff::5a1] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 18iglW-000Dre-00 for namedroppers@ops.ietf.org; Tue, 11 Feb 2003 12:12:27 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h1BKBUd6006463; Wed, 12 Feb 2003 07:11:31 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200302112011.h1BKBUd6006463@drugs.dv.isc.org> To: Jakob Schlyter Cc: Scott Rose , namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: Q1: Should we allow name compression in the RDATA of DNSSEC RRs? In-reply-to: Your message of "Tue, 11 Feb 2003 14:39:15 BST." Date: Wed, 12 Feb 2003 07:11:30 +1100 X-Spam-Status: No, hits=0.5 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > On Tue, 11 Feb 2003, Scott Rose wrote: > > > Q: Should the text in the Resource Records draft of the DNSSEC spec be > > changed to indicated that name compression "SHOULD NOT" be used when > > sending security RRs over the wire? > > yes, but I would prefer a MUST NOT. > > jakob > seconded. -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 11 15:41:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17905 for ; Tue, 11 Feb 2003 15:41:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ih4T-000EPg-00 for namedroppers-data@psg.com; Tue, 11 Feb 2003 12:32:01 -0800 Received: from [2001:470:1f00:ffff::5a1] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 18ih4L-000EOh-00 for namedroppers@ops.ietf.org; Tue, 11 Feb 2003 12:31:54 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h1BKVGd6006592; Wed, 12 Feb 2003 07:31:16 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200302112031.h1BKVGd6006592@drugs.dv.isc.org> To: "Scott Rose" Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: Q2: crypto algorithm requirements for DNSSEC In-reply-to: Your message of "Tue, 11 Feb 2003 07:40:23 CDT." <008801c2d1ca$bf14de10$b9370681@barnacle> Date: Wed, 12 Feb 2003 07:31:16 +1100 X-Spam-Status: No, hits=0.8 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > There have been previous updates to the requirement levels of the > cryptographic algorithms for DNSSEC (RFC 3110 updating RFC2535 for example). > There has been previous talk on this list regarding dropping DSA as a > mandatory to implement algorithm. Instead of writing a whole RFC just to > propose making DSA optional and RSA/SHA1 the only required algorithm, it > would be nice to seek consensus here. > > In other words, the new algorithm table from 2535 and 3110 would look like: > > code name > 0 reserved > 1 RSA/MD5 NOT RECOMMENDED > 2 D-H OPTIONAL > 3 DSA OPTIONAL > 4 ECC(reserved) OPTIONAL > 5 RSA/SHA1 REQUIRED > 6-251 available for assignment > 252 indirect OPTIONAL > 253 private > 254 private > 255 reserved > > > Q: Is the change of DSA to OPTIONAL acceptable? That will leave only > RSA/SHA1 as the only mandatory to implement algorithm. One of the purposes of two manditory protocols was to ensure that we could always have working DNSSEC in the event that a way to compromise a algorithm was found. You could then switch off that algorithm and still have a secure system while another algorithm was deployed to replace the compromised one. [ Yes, named is missing the switches to turn this off algorithms at runtime. This will be addressed. ] This would remove the fallback solution and require massive quick redeployment of dnssec suites in the event of a compromise to RSA/SHA1. The down side of having two manditory algorithms is that you should be signing with both all the time otherwise when one is compromised you will have whole branches being isolated. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 11 15:42:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17958 for ; Tue, 11 Feb 2003 15:42:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ih56-000ER1-00 for namedroppers-data@psg.com; Tue, 11 Feb 2003 12:32:40 -0800 Received: from mclmx.mail.saic.com ([149.8.64.10]) by psg.com with esmtp (Exim 3.36 #1) id 18ih53-000EQp-00 for namedroppers@ops.ietf.org; Tue, 11 Feb 2003 12:32:37 -0800 Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for namedroppers@ops.ietf.org; Tue, 11 Feb 2003 15:31:30 -0500 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.2.17) with SMTP id M2003021115321921897 for ; Tue, 11 Feb 2003 15:32:19 -0500 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2653.19) id <1XS6PHY8>; Tue, 11 Feb 2003 15:32:02 -0500 Message-Id: <4E25ECBBC03F874CBAD03399254ADFDE104A83@US-Columbia-CIST.mail.saic.com> From: "Loomis, Rip" To: namedroppers@ops.ietf.org Subject: RE: Q2: crypto algorithm requirements for DNSSEC Date: Tue, 11 Feb 2003 15:32:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-0.4 required=5.0 tests=EXCHANGE_SERVER,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > There has been previous talk on this list regarding dropping DSA as a > mandatory to implement algorithm. My summary of those previous discussions, testing of which I'm aware, and my own thoughts: - RSA was patented at the time of the original DNSSEC work, so a patent-free alternative was desired. RSA can now be implemented without patent encumbrances--that doesn't mean that DSA isn't useful as an alternative. - DSA has significantly lower performance in all current implementations of which I'm aware. Some of that is related to characteristics of DSA, in that the "sign once, verify many" model works better with an algorithm like RSA (verification time is << signing time) than it does with a balanced algorithm like DSA (verification time is similar to signing time). That means DSA is currently less useful than RSA for most real-world applications, but doesn't mean it's useless. - If at some point there's a significant cryptographic problem found with RSA, It Would Be Nice if there were an alternative already deployed. Then again, if there's a major new cryptographic attack found to which RSA is vulnerable, DSA might be vulnerable as well. - If we require one less algorithm to be implemented in the software, then it might make it easier on implementers. That argument seems to me not to carry much weight--there are already RSA and DSA crypto implementations out there and I doubt any DNS software author will be writing their own. > Q: Is the change of DSA to OPTIONAL acceptable? That will > leave only RSA/SHA1 as the only mandatory to implement algorithm. I never saw a convincing argument, given the above items, as to why this was a *useful* change. Whose time are we really saving by making this change? DSA might not be incredibly useful today, but I guess I don't see why it's useful to "unspecify" it when it's already documented and specified. Yes, I just tried to look through my archives and notes to see if I missed the convincing argument. If I've missed some past convincing argument, or if I've screwed up anything in my summary above, I'm sure someone will re-calibrate me. If the question is "Could I *live* with this change?" then the answer would be Yes. I'm just not sure why the change is desired. --Rip -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 11 16:18:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18783 for ; Tue, 11 Feb 2003 16:18:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ihg7-000Fc2-00 for namedroppers-data@psg.com; Tue, 11 Feb 2003 13:10:55 -0800 Received: from [2002:425c:4242:0:250:daff:fe82:1c39] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 18ihg5-000FbQ-00 for namedroppers@ops.ietf.org; Tue, 11 Feb 2003 13:10:53 -0800 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 1FDB118ED for ; Tue, 11 Feb 2003 16:10:18 -0500 (EST) Date: Tue, 11 Feb 2003 16:10:18 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Q2: crypto algorithm requirements for DNSSEC In-Reply-To: <200302112031.h1BKVGd6006592@drugs.dv.isc.org> References: <008801c2d1ca$bf14de10$b9370681@barnacle> <200302112031.h1BKVGd6006592@drugs.dv.isc.org> User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030211211018.1FDB118ED@thrintun.hactrn.net> X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03, USER_AGENT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Wed, 12 Feb 2003 07:31:16 +1100, Mark Andrews wrote: > > One of the purposes of two manditory protocols was to ensure > that we could always have working DNSSEC in the event that > a way to compromise a algorithm was found. You could then > switch off that algorithm and still have a secure system > while another algorithm was deployed to replace the compromised > one. [ Yes, named is missing the switches to turn this off > algorithms at runtime. This will be addressed. ] > > This would remove the fallback solution and require massive > quick redeployment of dnssec suites in the event of a > compromise to RSA/SHA1. > > The down side of having two manditory algorithms is that > you should be signing with both all the time otherwise when > one is compromised you will have whole branches being > isolated. Counter argument is that having two algorithms means that one can be attacked via a break in either algorithm. So, while I understand the desire to have a fallback strategy, I'm not sure that we really have one whether DSA is mandatory or not. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 11 16:21:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18851 for ; Tue, 11 Feb 2003 16:21:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ihjh-000Fi4-00 for namedroppers-data@psg.com; Tue, 11 Feb 2003 13:14:37 -0800 Received: from gusto.araneus.fi ([204.152.186.164]) by psg.com with esmtp (Exim 3.36 #1) id 18ihjd-000Fhq-00; Tue, 11 Feb 2003 13:14:33 -0800 Received: from guava.araneus.fi (adsl-63-197-0-204.dsl.snfc21.pacbell.net [63.197.0.204]) by gusto.araneus.fi (8.11.6/8.11.6) with ESMTP id h1BLEOZ04050; Tue, 11 Feb 2003 13:14:24 -0800 (PST) Received: (from gson@localhost) by guava.araneus.fi (8.11.6/8.11.6) id h1BLELR19705; Tue, 11 Feb 2003 13:14:21 -0800 (PST) Date: Tue, 11 Feb 2003 13:14:21 -0800 (PST) Message-Id: <200302112114.h1BLELR19705@guava.araneus.fi> To: Erik Nordmark Cc: Andreas Gustafsson , ogud@ogud.com, randy@psg.com, namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-unknown-rrs-04.txt In-Reply-To: References: <200302071959.h17JxDT14464@guava.araneus.fi> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Erik Nordmark writes: > > Yes. RFC2065 explicitly allowed compression of names in SIG and NXT > > records, and this is no longer allowed per the unknown-RRs draft. > > But this isn't consistent with draft-ietf-dnsext-dnssec-records-02.txt > which allows compression of SIG and NXT. Right. draft-ietf-dnsext-dnssec-records needs to be fixed. > > > For all other RR types, the canonical form is hereby changed such > > > that no downcasing of embedded domain names takes place. The owner > > > name is always set to lower case according to the DNS rules for > > > character comparisons, regardless of the RR type. > > > > > > It would be useful to explicitly list the RR types to which this change > > > applies. > > > > That's not really practical since there is more than 65000 of them. > > While you could attempt to list the currently allocated post-RFC2915 > > types, such a list would soon become inaccurate as additional types > > are allocated. > > I wasn't asking about listing all current and potential future RRs. > I'm asking about a specification of what "hereby changed" actually > means for an implementor. Being able to list the RRs which are subject > to this change seems like a requirement. If you don't have the list > how can we guage the impact of this change? An implementor can construct this list for any given implementation by finding all RR types the implementation knows about and determining which ones were defined in an RFC later than RFC2931 (the "2915" in the quoted text above is a typo and should be "2931" as in the draft). This will always yield a complete and up-to-date list, unlike any fixed list that could be embedded in the draft. Assuming the list of RR type assignments at is complete, there is currently exactly one post-RFC2931 RR type, the APL record defined in RFC3123, but the APL RR does not contain any embedded domain names and is therefore unaffected by the canonicalization change. In other words, the impact of this change on existing implementations is zero. -- 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. archive: From owner-namedroppers@ops.ietf.org Tue Feb 11 17:00:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19723 for ; Tue, 11 Feb 2003 17:00:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iiLu-000GmV-00 for namedroppers-data@psg.com; Tue, 11 Feb 2003 13:54:06 -0800 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #1) id 18iiLq-000Glw-00; Tue, 11 Feb 2003 13:54:02 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA12990; Tue, 11 Feb 2003 14:53:59 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h1BLrrP09477; Tue, 11 Feb 2003 22:53:53 +0100 (MET) Date: Tue, 11 Feb 2003 22:50:12 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: draft-ietf-dnsext-unknown-rrs-04.txt To: Andreas Gustafsson Cc: Erik Nordmark , Andreas Gustafsson , ogud@ogud.com, randy@psg.com, namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" <200302112114.h1BLELR19705@guava.araneus.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > An implementor can construct this list for any given implementation by > finding all RR types the implementation knows about and determining > which ones were defined in an RFC later than RFC2931 (the "2915" in > the quoted text above is a typo and should be "2931" as in the draft). > This will always yield a complete and up-to-date list, unlike any > fixed list that could be embedded in the draft. Future RRs will presumably not have this issue - they will be done right from the start. I'm specifically concerned about the statement that unknown-rrs changes something without being specific about what defined RRs it is changing. > Assuming the list of RR type assignments at > is complete, there is > currently exactly one post-RFC2931 RR type, the APL record defined in > RFC3123, but the APL RR does not contain any embedded domain names and > is therefore unaffected by the canonicalization change. In other > words, the impact of this change on existing implementations is zero. Then it makes sense stating this in unknown-rrs as it *creating a new rule* that downcasing canocalization of embedded domain names is not performed for newly created RR types (and perhaps add the list of the defined RR types that have embedded domain names where downcasing canonicalization is performed), instead of as current stating as a *change* to any existing RRs. That would be much clearer. (And the stuff in parenthesis could be something which could be deferred to the new dnssec drafts - being explicit about which RRs have their embedded domain names downcased). 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. archive: From owner-namedroppers@ops.ietf.org Tue Feb 11 18:10:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21294 for ; Tue, 11 Feb 2003 18:10:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ijOn-000IpB-00 for namedroppers-data@psg.com; Tue, 11 Feb 2003 15:01:09 -0800 Received: from [2001:470:1f00:ffff::5a1] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 18ijOk-000Io6-00 for namedroppers@ops.ietf.org; Tue, 11 Feb 2003 15:01:07 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h1BN0Ld6007434; Wed, 12 Feb 2003 10:00:24 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200302112300.h1BN0Ld6007434@drugs.dv.isc.org> To: Rob Austein Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: Q2: crypto algorithm requirements for DNSSEC In-reply-to: Your message of "Tue, 11 Feb 2003 16:10:18 CDT." <20030211211018.1FDB118ED@thrintun.hactrn.net> Date: Wed, 12 Feb 2003 10:00:21 +1100 X-Spam-Status: No, hits=0.5 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Counter argument is that having two algorithms means that one can be > attacked via a break in either algorithm. That is why the use of a particular algorithm MUST be selectable at runtime both in the signer and resolver. We already have had to withdraw one algorithm. > So, while I understand the desire to have a fallback strategy, I'm not > sure that we really have one whether DSA is mandatory or not. Well the choices are: * Immediate replacement of all resolvers. * Immediate disabling of a algorithm and gradual replacement of all resolvers. You will get *much* higher success with the second vs the first. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 11 18:35:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21847 for ; Tue, 11 Feb 2003 18:35:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ijqU-000Jg2-00 for namedroppers-data@psg.com; Tue, 11 Feb 2003 15:29:46 -0800 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 18ijqP-000Jfq-00 for namedroppers@ops.ietf.org; Tue, 11 Feb 2003 15:29:41 -0800 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA23491; Tue, 11 Feb 2003 18:29:39 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA06223; Tue, 11 Feb 2003 18:29:39 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id SAA05088; Tue, 11 Feb 2003 18:29:37 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id SAA27780; Tue, 11 Feb 2003 18:29:37 -0500 (EST) To: Mark.Andrews@isc.org Cc: Rob Austein , namedroppers@ops.ietf.org From: Derek Atkins Subject: Re: Q2: crypto algorithm requirements for DNSSEC References: <200302112300.h1BN0Ld6007434@drugs.dv.isc.org> Date: 11 Feb 2003 18:29:37 -0500 In-Reply-To: <200302112300.h1BN0Ld6007434@drugs.dv.isc.org> Message-ID: Lines: 42 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-0.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,RCVD_IN_RELAYS_ORDB_ORG,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_02_03, TO_BE_REMOVED_REPLY,USER_AGENT,USER_AGENT_GNUS_UA, X_OSIRU_OPEN_RELAY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk There is a difference between "MUST implement" and "MUST use". We could always specify "must implement" for two algorithms, but provide language that suggests that you should use one and should not use the other. -derek Mark.Andrews@isc.org writes: > > Counter argument is that having two algorithms means that one can be > > attacked via a break in either algorithm. > > That is why the use of a particular algorithm MUST be > selectable at runtime both in the signer and resolver. We > already have had to withdraw one algorithm. > > > So, while I understand the desire to have a fallback strategy, I'm not > > sure that we really have one whether DSA is mandatory or not. > > Well the choices are: > * Immediate replacement of all resolvers. > * Immediate disabling of a algorithm and gradual replacement > of all resolvers. > > You will get *much* higher success with the second vs the first. > > Mark > > -- > Mark Andrews, Internet Software Consortium > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.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. archive: From owner-namedroppers@ops.ietf.org Tue Feb 11 18:37:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21922 for ; Tue, 11 Feb 2003 18:37:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ijuY-000JoO-00 for namedroppers-data@psg.com; Tue, 11 Feb 2003 15:33:58 -0800 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 18ijuU-000JoB-00 for namedroppers@ops.ietf.org; Tue, 11 Feb 2003 15:33:54 -0800 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA25160; Tue, 11 Feb 2003 18:33:53 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA06798; Tue, 11 Feb 2003 18:33:52 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id SAA18089; Tue, 11 Feb 2003 18:33:52 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id SAA27785; Tue, 11 Feb 2003 18:33:52 -0500 (EST) To: "Loomis, Rip" Cc: namedroppers@ops.ietf.org From: Derek Atkins Subject: Re: Q2: crypto algorithm requirements for DNSSEC References: <4E25ECBBC03F874CBAD03399254ADFDE104A83@US-Columbia-CIST.mail.saic.com> Date: 11 Feb 2003 18:33:52 -0500 In-Reply-To: <4E25ECBBC03F874CBAD03399254ADFDE104A83@US-Columbia-CIST.mail.saic.com> Message-ID: Lines: 37 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-1.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,RCVD_IN_RELAYS_ORDB_ORG,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_02_03,USER_AGENT, USER_AGENT_GNUS_UA,X_OSIRU_OPEN_RELAY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Loomis, Rip" writes: > > Q: Is the change of DSA to OPTIONAL acceptable? That will > > leave only RSA/SHA1 as the only mandatory to implement algorithm. > > I never saw a convincing argument, given the above items, as to why this > was a *useful* change. Whose time are we really saving by making this > change? DSA might not be incredibly useful today, but I guess I don't > see why it's useful to "unspecify" it when it's already documented and > specified. Yes, I just tried to look through my archives and notes to > see if I missed the convincing argument. The only argument I've seen (note: I'm repeating it here to answer your question, not because I necessarily agree with it) is that is embedded devices (like an IP Phone that does its own DNSSec verfication) you don't want to have to implement more than you really need. A "must" algorithm that is never used is just a lot of wasted bits in a very restricted space. Note that I'm not convinced this is a compelling argument, but it's the best one I've heard so far. > If I've missed some past convincing argument, or if I've screwed up > anything in my summary above, I'm sure someone will re-calibrate me. > If the question is "Could I *live* with this change?" then the answer > would be Yes. I'm just not sure why the change is desired. See my previous mail on "must implement" v "must use". > --Rip -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.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. archive: From owner-namedroppers@ops.ietf.org Tue Feb 11 19:45:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23146 for ; Tue, 11 Feb 2003 19:45:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ikvb-000LqW-00 for namedroppers-data@psg.com; Tue, 11 Feb 2003 16:39:07 -0800 Received: from [2001:470:1f00:ffff::5a1] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 18ikvY-000Lpd-00 for namedroppers@ops.ietf.org; Tue, 11 Feb 2003 16:39:05 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h1C0a8d6007757; Wed, 12 Feb 2003 11:36:08 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200302120036.h1C0a8d6007757@drugs.dv.isc.org> To: Derek Atkins Cc: Rob Austein , namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: Q2: crypto algorithm requirements for DNSSEC In-reply-to: Your message of "11 Feb 2003 18:29:37 CDT." Date: Wed, 12 Feb 2003 11:36:08 +1100 X-Spam-Status: No, hits=1.7 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_05_08, TO_BE_REMOVED_REPLY version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > There is a difference between "MUST implement" and "MUST use". We > could always specify "must implement" for two algorithms, but provide > language that suggests that you should use one and should not use the > other. The problem is that if you don't sign with both you can't easily withdraw one of them when you need to. The resolver can protect itself if both signatures are there. It can simple choose to ignore one of them. If they are both not there then it doesn't get this choice and you will get dead branchs as a result. Manditory to implement also applies to signing. You havn't implemented if you are not using it. Mark > -derek > > Mark.Andrews@isc.org writes: > > > > Counter argument is that having two algorithms means that one can be > > > attacked via a break in either algorithm. > > > > That is why the use of a particular algorithm MUST be > > selectable at runtime both in the signer and resolver. We > > already have had to withdraw one algorithm. > > > > > So, while I understand the desire to have a fallback strategy, I'm not > > > sure that we really have one whether DSA is mandatory or not. > > > > Well the choices are: > > * Immediate replacement of all resolvers. > > * Immediate disabling of a algorithm and gradual replacement > > of all resolvers. > > > > You will get *much* higher success with the second vs the first. > > > > Mark > > > > -- > > Mark Andrews, Internet Software Consortium > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org > > > > -- > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > > -- > Derek Atkins > Computer and Internet Security Consultant > derek@ihtfp.com www.ihtfp.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. > archive: -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 11 20:16:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23871 for ; Tue, 11 Feb 2003 20:16:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ilNr-000Mo2-00 for namedroppers-data@psg.com; Tue, 11 Feb 2003 17:08:19 -0800 Received: from gusto.araneus.fi ([204.152.186.164]) by psg.com with esmtp (Exim 3.36 #1) id 18ilNo-000Mnm-00 for namedroppers@ops.ietf.org; Tue, 11 Feb 2003 17:08:16 -0800 Received: from guava.araneus.fi (adsl-63-197-0-204.dsl.snfc21.pacbell.net [63.197.0.204]) by gusto.araneus.fi (8.11.6/8.11.6) with ESMTP id h1C18DZ04692; Tue, 11 Feb 2003 17:08:13 -0800 (PST) Received: (from gson@localhost) by guava.araneus.fi (8.11.6/8.11.6) id h1C18D619888; Tue, 11 Feb 2003 17:08:13 -0800 (PST) Date: Tue, 11 Feb 2003 17:08:13 -0800 (PST) Message-Id: <200302120108.h1C18D619888@guava.araneus.fi> To: "Scott Rose" Cc: Subject: Re: Q1: Should we allow name compression in the RDATA of DNSSEC RRs? In-Reply-To: <007c01c2d1c9$5da52190$b9370681@barnacle> References: <007c01c2d1c9$5da52190$b9370681@barnacle> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Scott Rose writes: > Q: Should the text in the Resource Records draft of the DNSSEC spec be > changed to indicated that name compression "SHOULD NOT" be used when sending > security RRs over the wire? This only applies to the "signer's name" field > of the SIG RR and "next domain name" of the NXT RR. > note: "SHOULD NOT" would be the suggestion. "MUST NOT" may be too > strong, but if that is the concensus, then that will be the language. It should be changed to MUST NOT. A SHOULD NOT would be inconsistent with the unknown-rrs draft. -- 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. archive: From owner-namedroppers@ops.ietf.org Tue Feb 11 21:29:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25297 for ; Tue, 11 Feb 2003 21:29:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18imar-000PUK-00 for namedroppers-data@psg.com; Tue, 11 Feb 2003 18:25:49 -0800 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 18imap-000PU2-00 for namedroppers@ops.ietf.org; Tue, 11 Feb 2003 18:25:47 -0800 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id VAA26531; Tue, 11 Feb 2003 21:25:40 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id VAA17978; Tue, 11 Feb 2003 21:25:35 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id VAA14563; Tue, 11 Feb 2003 21:25:35 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id VAA28084; Tue, 11 Feb 2003 21:25:35 -0500 (EST) To: Mark.Andrews@isc.org Cc: Rob Austein , namedroppers@ops.ietf.org From: Derek Atkins Subject: Re: Q2: crypto algorithm requirements for DNSSEC References: <200302120036.h1C0a8d6007757@drugs.dv.isc.org> Date: 11 Feb 2003 21:25:35 -0500 In-Reply-To: <200302120036.h1C0a8d6007757@drugs.dv.isc.org> Message-ID: Lines: 37 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-0.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,RCVD_IN_RELAYS_ORDB_ORG,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_08_13,USER_AGENT, USER_AGENT_GNUS_UA,X_OSIRU_OPEN_RELAY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mark.Andrews@isc.org writes: > > There is a difference between "MUST implement" and "MUST use". We > > could always specify "must implement" for two algorithms, but provide > > language that suggests that you should use one and should not use the > > other. > > The problem is that if you don't sign with both you can't > easily withdraw one of them when you need to. The resolver > can protect itself if both signatures are there. It can > simple choose to ignore one of them. If they are both not > there then it doesn't get this choice and you will get dead > branchs as a result. So you re-sign your zone. You have to re-sign it periodically anyways, so what's the big deal? Why have twice the data and perform twice the work on the miniscule chance that one of the algorithms will be broken during the time your signatures are valid? From a security viewpoint, you want the code deployed to allow you to quickly move from one algorithm to another -- but that does *NOT* mean that you need to use (or WANT to use) both algorithms for all your data all the time. > Manditory to implement also applies to signing. You havn't > implemented if you are not using it. I completely disagree. You can implement something but not use it. > Mark -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.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. archive: From owner-namedroppers@ops.ietf.org Tue Feb 11 21:50:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26101 for ; Tue, 11 Feb 2003 21:50:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18imwg-0000YM-00 for namedroppers-data@psg.com; Tue, 11 Feb 2003 18:48:22 -0800 Received: from gusto.araneus.fi ([204.152.186.164]) by psg.com with esmtp (Exim 3.36 #1) id 18imwe-0000Y9-00; Tue, 11 Feb 2003 18:48:20 -0800 Received: from guava.araneus.fi (adsl-63-197-0-204.dsl.snfc21.pacbell.net [63.197.0.204]) by gusto.araneus.fi (8.11.6/8.11.6) with ESMTP id h1C2mFZ04891; Tue, 11 Feb 2003 18:48:15 -0800 (PST) Received: (from gson@localhost) by guava.araneus.fi (8.11.6/8.11.6) id h1C2mFq19962; Tue, 11 Feb 2003 18:48:15 -0800 (PST) Date: Tue, 11 Feb 2003 18:48:15 -0800 (PST) Message-Id: <200302120248.h1C2mFq19962@guava.araneus.fi> To: Erik Nordmark Cc: Andreas Gustafsson , ogud@ogud.com, randy@psg.com, namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-unknown-rrs-04.txt In-Reply-To: References: <200302112114.h1BLELR19705@guava.araneus.fi> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Erik Nordmark writes: > I'm specifically concerned about the statement that unknown-rrs > changes something without being specific about what defined RRs it > is changing. And I'm concerned about the use of terms like "defined RRs" and "existing RRs" since their meaning changes over time. The draft already precisely specifies which RRs use which canonicalization rule; talking about "defined RRs" would be irrelevant and only confuse the matter, especially for someone reading the RFC ten years from now. > > Assuming the list of RR type assignments at > > is complete, there is > > currently exactly one post-RFC2931 RR type, the APL record defined in > > RFC3123, but the APL RR does not contain any embedded domain names and > > is therefore unaffected by the canonicalization change. In other > > words, the impact of this change on existing implementations is zero. > > Then it makes sense stating this in unknown-rrs as it *creating a new > rule* that downcasing canocalization of embedded domain names is not performed > for newly created RR types How is this different from what the draft says now? Could you suggest a wording which better captures "creating a new rule"? > (and perhaps add the list of the defined > RR types that have embedded domain names where downcasing canonicalization > is performed), There is already such a list: "the domain names embedded in RRs of type NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV, DNAME, and A6 are converted to lower case according to the DNS rules for character comparisons" > instead of as current stating as a *change* to any existing RRs. I'm still not sure how you get that impression. The draft does not talk about a "changing RRs", it talks about "changing the canonical form". Also, it does not talk about "existing RRs", but of "RR types defined in RFC2931 or earlier" and "other RR types". Would changing the text "all other RR types" into "post-RFC2931 RR types" make it clearer which RRs the new canonical form applies to? -- 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. archive: From owner-namedroppers@ops.ietf.org Tue Feb 11 21:54:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26217 for ; Tue, 11 Feb 2003 21:54:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18imzs-0000hj-00 for namedroppers-data@psg.com; Tue, 11 Feb 2003 18:51:40 -0800 Received: from [2001:470:1f00:ffff::5a1] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 18imzo-0000fS-00 for namedroppers@ops.ietf.org; Tue, 11 Feb 2003 18:51:37 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h1C2opd6008251; Wed, 12 Feb 2003 13:50:51 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200302120250.h1C2opd6008251@drugs.dv.isc.org> To: Derek Atkins Cc: Rob Austein , namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: Q2: crypto algorithm requirements for DNSSEC In-reply-to: Your message of "11 Feb 2003 21:25:35 CDT." Date: Wed, 12 Feb 2003 13:50:51 +1100 X-Spam-Status: No, hits=1.1 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_08_13 version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Mark.Andrews@isc.org writes: > > > > There is a difference between "MUST implement" and "MUST use". We > > > could always specify "must implement" for two algorithms, but provide > > > language that suggests that you should use one and should not use the > > > other. > > > > The problem is that if you don't sign with both you can't > > easily withdraw one of them when you need to. The resolver > > can protect itself if both signatures are there. It can > > simple choose to ignore one of them. If they are both not > > there then it doesn't get this choice and you will get dead > > branchs as a result. > > So you re-sign your zone. You have to re-sign it periodically > anyways, so what's the big deal? Why have twice the data and perform > twice the work on the miniscule chance that one of the algorithms will > be broken during the time your signatures are valid? It's not just re-signing the zone. It's generating a new key, passing it to the parent, waiting for the DS to be published. (I would love to see how well Verisign copes with 10% of COM trying to get new DS records generated simultaniously) It's waiting for the majority of sites to do this before you can disable the vulnerable algorithm in your resolvers. If the keys and sigs are already deployed all you need to do is disable the algorithm. > >From a security viewpoint, you want the code deployed to allow you to > quickly move from one algorithm to another -- but that does *NOT* mean > that you need to use (or WANT to use) both algorithms for all your > data all the time. > > > Manditory to implement also applies to signing. You havn't > > implemented if you are not using it. > > I completely disagree. You can implement something but not use it. > > > Mark > > -derek > > -- > Derek Atkins > Computer and Internet Security Consultant > derek@ihtfp.com www.ihtfp.com -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 11 23:24:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27966 for ; Tue, 11 Feb 2003 23:24:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ioHX-0003xI-00 for namedroppers-data@psg.com; Tue, 11 Feb 2003 20:13:59 -0800 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 18ioHV-0003x6-00 for namedroppers@ops.ietf.org; Tue, 11 Feb 2003 20:13:57 -0800 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id XAA29983; Tue, 11 Feb 2003 23:13:54 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id XAA02349; Tue, 11 Feb 2003 23:13:52 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id XAA07235; Tue, 11 Feb 2003 23:09:54 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id XAA28265; Tue, 11 Feb 2003 23:09:54 -0500 (EST) To: Mark.Andrews@isc.org Cc: Rob Austein , namedroppers@ops.ietf.org From: Derek Atkins Subject: Re: Q2: crypto algorithm requirements for DNSSEC References: <200302120250.h1C2opd6008251@drugs.dv.isc.org> Date: 11 Feb 2003 23:09:53 -0500 In-Reply-To: <200302120250.h1C2opd6008251@drugs.dv.isc.org> Message-ID: Lines: 61 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,RCVD_IN_RELAYS_ORDB_ORG,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_08_13, TO_BE_REMOVED_REPLY,USER_AGENT,USER_AGENT_GNUS_UA, X_OSIRU_OPEN_RELAY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is an operational problem, not an implementation problem. Also, I HIGHLY doubt this situation will occur (if it occurs at all). Besides, if it does I think we'll have bigger problems than key rollovers. There is a time and a place to worry about eventualities. This is not one of them. Besides, what do you do if both RSA and DSA are broken together? Or what if both MD5 and SHA-1 are broken together? You can't forsee all eventualities... So you go with what you have and leave room in the protocol for changing it later. It does NOT mean that you double or triple all the data because there is a chance that 10 or 20 years from now someone might make a startling discovery. -derek Mark.Andrews@isc.org writes: > It's not just re-signing the zone. It's generating a new key, > passing it to the parent, waiting for the DS to be published. > (I would love to see how well Verisign copes with 10% of COM > trying to get new DS records generated simultaniously) > It's waiting for the majority of sites to do this before you > can disable the vulnerable algorithm in your resolvers. > > If the keys and sigs are already deployed all you need to > do is disable the algorithm. > > > >From a security viewpoint, you want the code deployed to allow you to > > quickly move from one algorithm to another -- but that does *NOT* mean > > that you need to use (or WANT to use) both algorithms for all your > > data all the time. > > > > > Manditory to implement also applies to signing. You havn't > > > implemented if you are not using it. > > > > I completely disagree. You can implement something but not use it. > > > > > Mark > > > > -derek > > > > -- > > Derek Atkins > > Computer and Internet Security Consultant > > derek@ihtfp.com www.ihtfp.com > -- > Mark Andrews, Internet Software Consortium > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.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. archive: From owner-namedroppers@ops.ietf.org Tue Feb 11 23:34:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28149 for ; Tue, 11 Feb 2003 23:34:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ioWg-0004dG-00 for namedroppers-data@psg.com; Tue, 11 Feb 2003 20:29:38 -0800 Received: from [2001:470:1f00:ffff::5a1] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 18ioWd-0004bo-00 for namedroppers@ops.ietf.org; Tue, 11 Feb 2003 20:29:35 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h1C4Sjd6009438; Wed, 12 Feb 2003 15:28:45 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200302120428.h1C4Sjd6009438@drugs.dv.isc.org> To: Derek Atkins Cc: Rob Austein , namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: Q2: crypto algorithm requirements for DNSSEC In-reply-to: Your message of "11 Feb 2003 23:09:53 CDT." Date: Wed, 12 Feb 2003 15:28:45 +1100 X-Spam-Status: No, hits=1.3 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_05_08 version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > This is an operational problem, not an implementation problem. Also, > I HIGHLY doubt this situation will occur (if it occurs at all). > Besides, if it does I think we'll have bigger problems than key > rollovers. It doesn't require key rollover. It involves disabling a algorithm. This can be done in the resolver without having to change what is being served provide both algorithms are used. Keeping the DNS working through such a event will very much speedup the recovery from such a event. > There is a time and a place to worry about eventualities. This is not > one of them. This is exactly the time when we should be worring about this. We are making decisions now which affect the ability to recover from failures like this. > Besides, what do you do if both RSA and DSA are broken together? Or > what if both MD5 and SHA-1 are broken together? You can't forsee all > eventualities... So you go with what you have and leave room in the > protocol for changing it later. It does NOT mean that you double or > triple all the data because there is a chance that 10 or 20 years from > now someone might make a startling discovery. No you can't forsee all eventualities. You can however plan to recover from single points of failure. Mark > -derek -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 11 23:48:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28427 for ; Tue, 11 Feb 2003 23:48:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ioi4-00059e-00 for namedroppers-data@psg.com; Tue, 11 Feb 2003 20:41:24 -0800 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 18ioi0-00059O-00 for namedroppers@ops.ietf.org; Tue, 11 Feb 2003 20:41:20 -0800 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id XAA12224; Tue, 11 Feb 2003 23:41:12 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id XAA05381; Tue, 11 Feb 2003 23:41:11 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id XAA26896; Tue, 11 Feb 2003 23:41:09 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id XAA28333; Tue, 11 Feb 2003 23:41:08 -0500 (EST) To: Mark.Andrews@isc.org Cc: Rob Austein , namedroppers@ops.ietf.org From: Derek Atkins Subject: Re: Q2: crypto algorithm requirements for DNSSEC References: <200302120428.h1C4Sjd6009438@drugs.dv.isc.org> Date: 11 Feb 2003 23:41:08 -0500 In-Reply-To: <200302120428.h1C4Sjd6009438@drugs.dv.isc.org> Message-ID: Lines: 28 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-1.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,RCVD_IN_RELAYS_ORDB_ORG,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_GNUS_UA,X_OSIRU_OPEN_RELAY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mark.Andrews@isc.org writes: > No you can't forsee all eventualities. You can however plan > to recover from single points of failure. Fine, then let's define 10 different algorithms, call them all MUST, and require everyone to sign their zone 10 times... Where does it end? Seriously, you're over-engineering a solution to something I consider a non-problem. And honestly I think that Mr. Bellovin or Mr. Schiller would agree with me that this is a non-problem. The problem we want to solve here is that DNS Resolvers, Caching Services, and Primary Servers are slow to deploy/upgrade. Changing the software is HARD. However, the DATA in the DNS is _EASY_ to change... Let's not lose sight of the forest for the trees.... > Mark -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.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. archive: From owner-namedroppers@ops.ietf.org Wed Feb 12 00:11:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28910 for ; Wed, 12 Feb 2003 00:11:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ip6X-0006JI-00 for namedroppers-data@psg.com; Tue, 11 Feb 2003 21:06:41 -0800 Received: from [2001:470:1f00:ffff::5a1] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 18ip6T-0006Gr-00 for namedroppers@ops.ietf.org; Tue, 11 Feb 2003 21:06:38 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h1C55Od6010145; Wed, 12 Feb 2003 16:05:24 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200302120505.h1C55Od6010145@drugs.dv.isc.org> To: Derek Atkins Cc: Mark_Andrews@isc.org, Rob Austein , namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: Q2: crypto algorithm requirements for DNSSEC In-reply-to: Your message of "11 Feb 2003 23:41:08 CDT." Date: Wed, 12 Feb 2003 16:05:24 +1100 X-Spam-Status: No, hits=0.5 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Mark.Andrews@isc.org writes: > > > No you can't forsee all eventualities. You can however plan > > to recover from single points of failure. > > Fine, then let's define 10 different algorithms, call them all MUST, > and require everyone to sign their zone 10 times... > > Where does it end? Well you only need two at any point in time to deal with a single failure. > Seriously, you're over-engineering a solution to something I consider > a non-problem. And honestly I think that Mr. Bellovin or Mr. Schiller > would agree with me that this is a non-problem. The problem we want > to solve here is that DNS Resolvers, Caching Services, and Primary > Servers are slow to deploy/upgrade. Changing the software is HARD. > > However, the DATA in the DNS is _EASY_ to change... No. It's not easy. It's easier but it's still hard. When it happens it is going to be hard enough just to get the word out to say "don't use this algorithm anymore". It will be MUCH harder to get the new data deployed if it is not deployed as part of standard procedures. MUCH HARDER still will be the job to roll out the new manditory it implement algorithm to replace the corrupted one. > Let's not lose sight of the forest for the trees.... > > > Mark > > -derek > > -- > Derek Atkins > Computer and Internet Security Consultant > derek@ihtfp.com www.ihtfp.com -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 12 00:44:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29485 for ; Wed, 12 Feb 2003 00:44:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ipYW-0007de-00 for namedroppers-data@psg.com; Tue, 11 Feb 2003 21:35:36 -0800 Received: from thing.verisignlabs.com ([65.201.175.62] helo=cliffie.verisignlabs.com) by psg.com with esmtp (Exim 3.36 #1) id 18ipYS-0007dS-00 for namedroppers@ops.ietf.org; Tue, 11 Feb 2003 21:35:32 -0800 Received: from piston.dyn.verisignlabs.com (piston.dyn.verisignlabs.com [68.48.27.14]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by cliffie.verisignlabs.com with esmtp; Wed, 12 Feb 2003 00:35:30 -0500 From: David Blacka To: namedroppers@ops.ietf.org Subject: Re: Q2: crypto algorithm requirements for DNSSEC Date: Wed, 12 Feb 2003 00:35:23 -0500 User-Agent: KMail/1.5 References: <200302120428.h1C4Sjd6009438@drugs.dv.isc.org> In-Reply-To: Organization: Verisign, Inc. Cc: Derek Atkins MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200302120035.23161.davidb@verisignlabs.com> X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, REFERENCES,SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02, USER_AGENT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday 11 February 2003 11:41 pm, Derek Atkins wrote: > Mark.Andrews@isc.org writes: > > No you can't forsee all eventualities. You can however plan > > to recover from single points of failure. > > Fine, then let's define 10 different algorithms, call them all MUST, > and require everyone to sign their zone 10 times... > > Where does it end? I'd like to point out that because of the way DNSSEC verifiers are defined to work, when you sign your zone with more than one algorithm, you become open to attack when *any one* of those algorithms is found weak. Verifiers just ignore non-validating SIGs. To my thinking, signing with more than one algorithm is less secure than signing with just one. Or, at best, no more secure. Honestly, I understand where Mark is coming from. He is optimizing for the resolver perspective. From the resolvers point of view, being able to just "turn off" the broken algorithm and then have the entire DNSSEC tree suddenly be secure again must be pretty attractive. But from the zone owner's perspective, his zone will be vulnerable until either he re-signs the zone or all resolvers are reconfigured to not use the bad algorithm. From the zone owner's perspective the fastest way back to security is to resign the zone. Who knows how long it will take for all the security aware resolvers to change their configurations? > Seriously, you're over-engineering a solution to something I consider > a non-problem. And honestly I think that Mr. Bellovin or Mr. Schiller > would agree with me that this is a non-problem. The problem we want > to solve here is that DNS Resolvers, Caching Services, and Primary > Servers are slow to deploy/upgrade. Changing the software is HARD. > > However, the DATA in the DNS is _EASY_ to change... -- David Blacka Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 12 01:52:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00442 for ; Wed, 12 Feb 2003 01:52:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iqem-000BNF-00 for namedroppers-data@psg.com; Tue, 11 Feb 2003 22:46:08 -0800 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 18iqej-000BN2-00 for namedroppers@ops.ietf.org; Tue, 11 Feb 2003 22:46:05 -0800 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id BAA14279; Wed, 12 Feb 2003 01:46:03 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id BAA08504; Wed, 12 Feb 2003 01:41:31 -0500 (EST) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id BAA29752; Wed, 12 Feb 2003 01:41:30 -0500 (EST) Received: (from ghudson@localhost) by error-messages.mit.edu (8.9.3) id BAA15210; Wed, 12 Feb 2003 01:41:29 -0500 Subject: Re: Q2: crypto algorithm requirements for DNSSEC From: Greg Hudson To: David Blacka Cc: namedroppers@ops.ietf.org In-Reply-To: <200302120035.23161.davidb@verisignlabs.com> References: <200302120428.h1C4Sjd6009438@drugs.dv.isc.org> <200302120035.23161.davidb@verisignlabs.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 12 Feb 2003 01:41:29 -0500 Message-Id: <1045032089.1382.296.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Spam-Status: No, hits=3.2 required=5.0 tests=IN_REP_TO,RCVD_IN_OSIRUSOFT_COM,RCVD_IN_RELAYS_ORDB_ORG, REFERENCES,SPAM_PHRASE_00_01,X_OSIRU_OPEN_RELAY version=2.43 X-Spam-Level: *** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2003-02-12 at 00:35, David Blacka wrote: > But from the zone owner's perspective, his zone will be vulnerable until > either he re-signs the zone or all resolvers are reconfigured to not use the > bad algorithm. I don't see how re-signing the zone helps. If I can forge, say, RSA signatures, then I can forge a signature chain all the way from the client's pre-configured RSA public key to the domain I'm trying to attack, whether or not the real zone data has been re-signed with a DSA key. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 12 03:43:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26202 for ; Wed, 12 Feb 2003 03:43:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18isOm-000GJP-00 for namedroppers-data@psg.com; Wed, 12 Feb 2003 00:37:44 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #1) id 18isOj-000GJD-00 for namedroppers@ops.ietf.org; Wed, 12 Feb 2003 00:37:41 -0800 Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.5/8.11.6) with SMTP id h1C8bVAq001052; Wed, 12 Feb 2003 09:37:31 +0100 Date: Wed, 12 Feb 2003 09:37:31 +0100 From: "Olaf M. Kolkman" To: Mark.Andrews@isc.org Cc: derek@ihtfp.com, Mark_Andrews@isc.org, sra+namedroppers@hactrn.net, namedroppers@ops.ietf.org Subject: Re: Q2: crypto algorithm requirements for DNSSEC Message-Id: <20030212093731.18ff9f7b.olaf@ripe.net> In-Reply-To: <200302120505.h1C55Od6010145@drugs.dv.isc.org> References: <200302120505.h1C55Od6010145@drugs.dv.isc.org> Organization: RIPE NCC X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.5 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_02_03 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > Seriously, you're over-engineering a solution to something I consider > > a non-problem. And honestly I think that Mr. Bellovin or Mr. Schiller > > would agree with me that this is a non-problem. The problem we want > > to solve here is that DNS Resolvers, Caching Services, and Primary > > Servers are slow to deploy/upgrade. Changing the software is HARD. > > > > However, the DATA in the DNS is _EASY_ to change... > > No. It's not easy. It's easier but it's still hard. > > When it happens it is going to be hard enough just to get > the word out to say "don't use this algorithm anymore". > It will be MUCH harder to get the new data deployed if it > is not deployed as part of standard procedures. My over-engineering-flag is raised as well; If RSA get's compromised the DNS is the least of my worries... If RSA get's compromised I can live with an unsecured DNS tree... just as I can live with it today. In other words: "You do not have to outrun the bear as long as you outrun the other guy" and if RSA is compromised there are other guys than DNS that are a much tastier game. --Olaf --------------------------------------------| Olaf M. Kolkman | www.ripe.net/disi -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 12 03:51:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26351 for ; Wed, 12 Feb 2003 03:51:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18isYx-000GeT-00 for namedroppers-data@psg.com; Wed, 12 Feb 2003 00:48:15 -0800 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by psg.com with esmtp (Exim 3.36 #1) id 18isYu-000Gdu-00 for namedroppers@ops.ietf.org; Wed, 12 Feb 2003 00:48:12 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA27659; Wed, 12 Feb 2003 00:48:10 -0800 (PST) Received: from localhost (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h1C8m9P12849; Wed, 12 Feb 2003 09:48:09 +0100 (MET) Date: Tue, 11 Feb 2003 23:38:47 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: DNSEXT WGLC: DNSSEC Opt-in To: Roy Arends Cc: =?iso-8859-1?Q?=D3lafur_Gudmundsson/DNSEXT_co-chair?= , namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=1.1 required=5.0 tests=DATE_IN_PAST_06_12,IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Yes, Verisignlabs and ISC have auth.server implementations, ISC has a > resolver implementation. Does this mean that there is a caching resolver implementation that has been tested? I'm wondering if the caching aspects (which are not opt-in specific) of NXDOMAIN and the corresponding NXT records have been tested. 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. archive: From owner-namedroppers@ops.ietf.org Wed Feb 12 04:12:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26891 for ; Wed, 12 Feb 2003 04:12:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ist4-000HCq-00 for namedroppers-data@psg.com; Wed, 12 Feb 2003 01:09:02 -0800 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 18ist1-000HCd-00 for namedroppers@ops.ietf.org; Wed, 12 Feb 2003 01:09:00 -0800 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.6/8.12.6/Debian-7) with ESMTP id h1C98lVX004435; Wed, 12 Feb 2003 10:08:48 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.6/8.12.6/Debian-7) with ESMTP id h1C98lqT004432; Wed, 12 Feb 2003 10:08:47 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 12 Feb 2003 10:08:47 +0100 (CET) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: Erik Nordmark cc: =?iso-8859-1?Q?=D3lafur_Gudmundsson/DNSEXT_co-chair?= , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: DNSSEC Opt-in In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-2.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT, REFERENCES,SPAM_PHRASE_00_01,USER_AGENT_PINE,X_AUTH_WARNING version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 11 Feb 2003, Erik Nordmark wrote: > > Yes, Verisignlabs and ISC have auth.server implementations, ISC has a > > resolver implementation. > > Does this mean that there is a caching resolver implementation that > has been tested? I'm wondering if the caching aspects (which are not opt-in > specific) of NXDOMAIN and the corresponding NXT records have been tested. I don't have material on how thorough the caching resolver implementation has been tested. Regards, Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 12 04:53:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27689 for ; Wed, 12 Feb 2003 04:53:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18itUi-000IJK-00 for namedroppers-data@psg.com; Wed, 12 Feb 2003 01:47:56 -0800 Received: from [2001:6e0:206:1:250:daff:fe3d:1d6] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 3.36 #1) id 18itUf-000IIx-00; Wed, 12 Feb 2003 01:47:54 -0800 Received: from open.nlnetlabs.nl (localhost [IPv6:::1]) by open.nlnetlabs.nl (8.12.6/8.12.6) with ESMTP id h1C9lep8066750; Wed, 12 Feb 2003 10:47:40 +0100 (CET) (envelope-from alexis@open.nlnetlabs.nl) Received: (from alexis@localhost) by open.nlnetlabs.nl (8.12.6/8.12.6/Submit) id h1C9leRo066749; Wed, 12 Feb 2003 10:47:40 +0100 (CET) Message-Id: <200302120947.h1C9leRo066749@open.nlnetlabs.nl> Subject: Re: draft-ietf-dnsext-unknown-rrs-04.txt In-Reply-To: <200302120248.h1C2mFq19962@guava.araneus.fi> To: Andreas Gustafsson Date: Wed, 12 Feb 2003 10:47:40 +0100 (CET) From: Alexis Yushin CC: Erik Nordmark , Andreas Gustafsson , ogud@ogud.com, randy@psg.com, namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, hits=0.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, UPPERCASE_25_50 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Once Andreas Gustafsson wrote: >There is already such a list: > > "the domain names embedded in RRs of type NS, MD, MF, CNAME, SOA, MB, > MG, MR, PTR, HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, > NAPTR, KX, SRV, DNAME, and A6 are converted to lower case according > to the DNS rules for character comparisons" Side questions, perhaps I missed the answer, but where does this list come from? Alexis -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 12 05:43:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28527 for ; Wed, 12 Feb 2003 05:43:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iuG5-000Jls-00 for namedroppers-data@psg.com; Wed, 12 Feb 2003 02:36:53 -0800 Received: from cyphermail.sandelman.ottawa.on.ca ([192.139.46.78] helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 3.36 #1) id 18iuFu-000Jkt-00 for namedroppers@ops.ietf.org; Wed, 12 Feb 2003 02:36:42 -0800 Received: from sandelman.ottawa.on.ca ([2002:c08b:2e21:2:204:76ff:fe2d:8c]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h180l3L20560 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Fri, 7 Feb 2003 19:47:04 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h180l1FZ012276 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Fri, 7 Feb 2003 19:47:03 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h180kvWw012254 for ; Fri, 7 Feb 2003 19:47:01 -0500 Message-Id: <200302080047.h180kvWw012254@marajade.sandelman.ottawa.on.ca> To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration In-reply-to: Your message of "Thu, 06 Feb 2003 22:14:59 +0900." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 07 Feb 2003 19:46:56 -0500 From: Michael Richardson X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,LINES_OF_YELLING,PGP_SIGNATURE,SPAM_PHRASE_02_03 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "jinmei" == jinmei > writes: >> I see two individual problems: >> 1. The device (according to the draft) has a problem knowing its FQDN. >> DHCP will happily supply that information. jinmei> Okay, then are you also assuming the DHCPv6 server assigns the jinmei> IPv6 address(es) of the client? Or are you thinking of some jinmei> registration mechanism from the client (that configures its jinmei> address(es) in a stateless manner) to the server? I would think that the address of the DHCPv6 servers should simply be returned by one (or all) of the routers in the router advertisements. (As an option) As a fallback, the DHCPv6 server could have a well known link local address. RS/RA gets you on the network. RFC2462 says: stateful autoconfiguration complement each other. For example, a host can use stateless autoconfiguration to configure its own addresses, but use stateful autoconfiguration to obtain other information. Stateful autoconfiguration for IPv6 is the subject of future work [DHCPv6]. The key thing to realize is that DHCP{v4} does not just do address configuration - it establishes some level of trust between the end node and the infrastructure. In particular, a random v6 node is just NOT going to have any trust relationship with the DNS server such that it can update the reverse map. A DHCP server can have that. The DHC WG is working on ways of making that trust stronger. SEND is also doing similar things. This is not a DNSext issue. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPkRTf4qHRg3pndX9AQGwYgP/TdfnlN9lPHjiXqx5RI/DeAPmKEfR4vkW qJh2R/xL5hygEhFly9FUxAkJzkdMcxP8mtU2x2LHdHzQ0ZI26oanMMgjfQ0p6GUJ nK9NrYg4NF2qLAM2L8NuV0C+WwCHVo8lGNV4IL5gMV9KYpbE0hITn/ZCageyxjn6 qgXFxdSkoY8= =0/DK -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 12 05:44:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28544 for ; Wed, 12 Feb 2003 05:44:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iuFz-000Jlf-00 for namedroppers-data@psg.com; Wed, 12 Feb 2003 02:36:47 -0800 Received: from cyphermail.sandelman.ottawa.on.ca ([192.139.46.78] helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 3.36 #1) id 18iuFw-000Jkt-00 for namedroppers@ops.ietf.org; Wed, 12 Feb 2003 02:36:44 -0800 Received: from sandelman.ottawa.on.ca ([2002:c08b:2e21:2:204:76ff:fe2d:8c]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h1812nL20641 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Fri, 7 Feb 2003 20:02:51 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h1812mFZ012776 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Fri, 7 Feb 2003 20:02:49 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h1812mch012773 for ; Fri, 7 Feb 2003 20:02:48 -0500 Message-Id: <200302080102.h1812mch012773@marajade.sandelman.ottawa.on.ca> To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration In-reply-to: Your message of "Thu, 06 Feb 2003 20:22:15 CST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 07 Feb 2003 20:02:47 -0500 From: Michael Richardson X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,LINES_OF_YELLING,PGP_SIGNATURE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Ted" == Ted Lemon writes: >>> Sorry, misuse of terminology. It sends an update to the reverse >>> server signed in the private half of the SIG key from its forward >>> FQDN. The reverse server has to know to do step 6 to validate the >>> update. >> because my laptop has a relationship to the server for psg.com, and >> can put something kinky into the forward name should not mean that the >> owner of the reverse zone should trust the data in the forward zone or >> that the laptop asserts. is the attack not pretty obvious? Ted> It was a rough outline. Obviously the checking the reverse server Ted> has to do to make it work is more than what I said, but it's totally Ted> doable. The validation I described prevents a random host on the Ted> network from trivially stuffing the DNS server with bogus PTR Ted> records. You could do an additional validation where if someone Ted> wants to stuff a new valid into an old PTR record, the DNS server Ted> looks to see if the old FQDN in that PTR record still points back to Ted> the address referred to by the PTR record, and if it does, refuses Ted> the update. This prevents PTR record stealing. Maybe. I'm not convinced that the failure cases are tractable, or can easily be dealt with. Ted> Obviously this assumes that the DNS server for the zone in question Ted> is willing to have arbitrary clients establish PTR records. I can It would a lot easier if a machine on the local LAN can control things to a finer degree. A lot easier to deal with the trust relationships. It provides a clearly local place to put administrative overrides, and to clear up confusion. Such a machine can much more clearly check reachability of the "client". ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPkRXNoqHRg3pndX9AQHUiAQAvpzDUeMsQOLeQgvtFPhaneJ+zBgnlYXS lcmppEfNlbc7G0Igl3AKtaIucYvwixqPH3EcpVYHchc0Jz2scDCOWK4FcVhxB9YD LrZr8HVM3YEZXFfVtNWypgoQ7UFD7s18TCNJzchAEhiEcyRFR7z9P4CB71cA3/qM XfgXmpCGRYg= =Haq4 -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 12 05:45:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28562 for ; Wed, 12 Feb 2003 05:45:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iuFx-000Jla-00 for namedroppers-data@psg.com; Wed, 12 Feb 2003 02:36:45 -0800 Received: from cyphermail.sandelman.ottawa.on.ca ([192.139.46.78] helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 3.36 #1) id 18iuFt-000Jkt-00 for namedroppers@ops.ietf.org; Wed, 12 Feb 2003 02:36:41 -0800 Received: from sandelman.ottawa.on.ca ([2002:c08b:2e21:2:204:76ff:fe2d:8c]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h180n7L20565 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Fri, 7 Feb 2003 19:49:08 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h180n6FZ012344 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Fri, 7 Feb 2003 19:49:07 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h180n5hm012341 for ; Fri, 7 Feb 2003 19:49:05 -0500 Message-Id: <200302080049.h180n5hm012341@marajade.sandelman.ottawa.on.ca> To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration In-reply-to: Your message of "Thu, 06 Feb 2003 22:06:55 +0700." <14446.1044544015@munnari.OZ.AU> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 07 Feb 2003 19:49:05 -0500 From: Michael Richardson X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,LINES_OF_YELLING,PGP_SIGNATURE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Robert" == Robert Elz writes: Robert> For v4 things aren't quite as bad, as DHCP servers update the DNS Robert> only with addresses the DHCP server has assigned, so there is at Robert> least some general reason for believing the DHCP server there. Robert> But for v6, DHCP servers will almost never be actually assigning Robert> addresses, so the server is just believing the client, and then Robert> taking that (unsubstantiated) data and sending it to the DNS Robert> server. That doesn't sound good. No, it does not. But, that's not how I would do it. Robert> The experiment proposed in this draft also has an entity (the Robert> registrar) that can form a trust relationship with the DNS Robert> server, and but it doesn't get its data from what some random Robert> client tells it, but from what another (trusted) agent (the Robert> detector) tells it from what it observes of the network. Robert> Personally I have my doubts that this can really work well - but Robert> what is being proposed is an experiment, discovering whether Robert> things do work or not is what experiments are all about, so I see Robert> no problem with doing it (nor with publishing the doc that tells Robert> people how). The detector sounds like a DHCPv6 server to me. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPkRT/4qHRg3pndX9AQHQ6gP/fYhWNYAlkTA7QH+K9kCgNMywRmEApcD+ GBfgcgdj6RjwP78QNLAcreHO3WPU/rvEjx4yL1EfLg7e8R++vjynyab+IBj2s3yH bWOIslU//aGT3SjRiNJO6uvrkEkC55epLC3SI3qL41n+1Rjkf+cAu84VRsYZ1yCo ca/56stsIHk= =CZ1r -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 12 06:04:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28884 for ; Wed, 12 Feb 2003 06:04:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iudY-000KbO-00 for namedroppers-data@psg.com; Wed, 12 Feb 2003 03:01:08 -0800 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by psg.com with esmtp (Exim 3.36 #1) id 18iudW-000Kb6-00; Wed, 12 Feb 2003 03:01:06 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA08174; Wed, 12 Feb 2003 03:01:02 -0800 (PST) Received: from localhost (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h1CB0uP25514; Wed, 12 Feb 2003 12:00:57 +0100 (MET) Date: Wed, 12 Feb 2003 11:57:16 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: draft-ietf-dnsext-unknown-rrs-04.txt To: Andreas Gustafsson Cc: Erik Nordmark , Andreas Gustafsson , ogud@ogud.com, randy@psg.com, namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" <200302120248.h1C2mFq19962@guava.araneus.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > And I'm concerned about the use of terms like "defined RRs" and > "existing RRs" since their meaning changes over time. The draft > already precisely specifies which RRs use which canonicalization rule; > talking about "defined RRs" would be irrelevant and only confuse the > matter, especially for someone reading the RFC ten years from now. Agreed that "defined RR" and "existing RR" should not be used. And given that section 7 has the list of RRs that use downcasing that part is ok (I didn't re-read the section yesterday so I confused myself - sorry about that.) The only thing that is odd is the "changed" in the text: For all other RR types, the canonical form is hereby changed such that no downcasing of embedded domain names takes place. The owner name is always set to lower case according to the DNS rules for character comparisons, regardless of the RR type. where you've identified that there is no change. To me it makes sense stating instead: This document specifies that for all other RR types, the canonical form is such that no downcasing of embedded domain names takes place. The owner name is always set to lower case according to the DNS rules for character comparisons, regardless of the RR type. and then add a note saying that Note that after RFC 2931 there has been no RR types defined which have an embedded domain name. It is expected that future definitions of RR types will explicitly state that there is no downcasing of embedded domain names as part of DNSSEC canonicalization. Does that make sense? In terms on text suggestions, I don't know if I've seen suggested text that makes it clear that the document changes the compression rule for SIG and NXT. For the benefits of clarity it makes sense having that paragraph point at the paragraphs in 2535 that are changed. 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. archive: From owner-namedroppers@ops.ietf.org Wed Feb 12 06:14:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29049 for ; Wed, 12 Feb 2003 06:14:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iupA-000L3A-00 for namedroppers-data@psg.com; Wed, 12 Feb 2003 03:13:08 -0800 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 18iup6-000L2r-00; Wed, 12 Feb 2003 03:13:04 -0800 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.6/8.12.6/Debian-7) with ESMTP id h1CBCpVX006750; Wed, 12 Feb 2003 12:12:51 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.6/8.12.6/Debian-7) with ESMTP id h1CBCogX006747; Wed, 12 Feb 2003 12:12:50 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 12 Feb 2003 12:12:50 +0100 (CET) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: Alexis Yushin cc: Andreas Gustafsson , Erik Nordmark , Andreas Gustafsson , =?iso-8859-1?Q?=D3lafur_Gudmundsson?= , Randy Bush , namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-unknown-rrs-04.txt In-Reply-To: <200302120947.h1C9leRo066749@open.nlnetlabs.nl> Message-ID: References: <200302120947.h1C9leRo066749@open.nlnetlabs.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-3.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,TO_BE_REMOVED_REPLY,USER_AGENT_PINE, X_AUTH_WARNING version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk section 7 of the draft. Roy On Wed, 12 Feb 2003, Alexis Yushin wrote: > Once Andreas Gustafsson wrote: > >There is already such a list: > > > > "the domain names embedded in RRs of type NS, MD, MF, CNAME, SOA, MB, > > MG, MR, PTR, HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, > > NAPTR, KX, SRV, DNAME, and A6 are converted to lower case according > > to the DNS rules for character comparisons" > > Side questions, perhaps I missed the answer, but where does this list > come from? > > Alexis > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 12 06:27:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29301 for ; Wed, 12 Feb 2003 06:27:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iuv9-000LIP-00 for namedroppers-data@psg.com; Wed, 12 Feb 2003 03:19:19 -0800 Received: from [3ffe:501:100f:0:220:edff:fe2c:2eca] (helo=newshuttle.wide.toshiba.co.jp) by psg.com with esmtp (Exim 3.36 #1) id 18iuv6-000LHl-00 for namedroppers@ops.ietf.org; Wed, 12 Feb 2003 03:19:16 -0800 Received: from localhost (unknown [3ffe:501:4819:2000:200:39ff:fe10:85d7]) by newshuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 2A0FE15220; Wed, 12 Feb 2003 20:19:59 +0900 (JST) Date: Wed, 12 Feb 2003 20:19:17 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Michael Richardson Cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration In-Reply-To: <200302080047.h180kvWw012254@marajade.sandelman.ottawa.on.ca> References: <200302080047.h180kvWw012254@marajade.sandelman.ottawa.on.ca> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 49 X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_03_05,USER_AGENT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> On Fri, 07 Feb 2003 19:46:56 -0500, >>>>> Michael Richardson said: >>> I see two individual problems: >>> 1. The device (according to the draft) has a problem knowing its FQDN. >>> DHCP will happily supply that information. jinmei> Okay, then are you also assuming the DHCPv6 server assigns the jinmei> IPv6 address(es) of the client? Or are you thinking of some jinmei> registration mechanism from the client (that configures its jinmei> address(es) in a stateless manner) to the server? > I would think that the address of the DHCPv6 servers should simply > be returned by one (or all) of the routers in the router advertisements. > (As an option) ... Sorry, but you did not answer my question. I didn't talk about the address of the DHCPv6 server(s) at all. I asked if you cared about a host using stateless autoconfiguration to assign its own addresses in your scenario. BTW: (though this is not related to my question) your thought above is incorrect. > As a fallback, the DHCPv6 server could have a well known link local > address. RS/RA gets you on the network. RFC2462 says: > stateful autoconfiguration complement each other. For example, a host > can use stateless autoconfiguration to configure its own addresses, > but use stateful autoconfiguration to obtain other information. > Stateful autoconfiguration for IPv6 is the subject of future work > [DHCPv6]. > The key thing to realize is that DHCP{v4} does not just do address > configuration - it establishes some level of trust between the end node and > the infrastructure. In particular, a random v6 node is just NOT going to have > any trust relationship with the DNS server such that it can update the > reverse map. A DHCP server can have that. I know that. This is not related to my question. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.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. archive: From owner-namedroppers@ops.ietf.org Wed Feb 12 06:48:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29746 for ; Wed, 12 Feb 2003 06:48:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ivHx-000MAx-00 for namedroppers-data@psg.com; Wed, 12 Feb 2003 03:42:53 -0800 Received: from mail48-s.fg.online.no ([148.122.161.48] helo=mail48.fg.online.no) by psg.com with esmtp (Exim 3.36 #1) id 18ivHv-000MAk-00 for namedroppers@ops.ietf.org; Wed, 12 Feb 2003 03:42:51 -0800 Received: from karepr.Presttun.org (ti200710a080-1213.bb.online.no [80.213.36.189]) by mail48.fg.online.no (8.9.3/8.9.3) with ESMTP id MAA18870; Wed, 12 Feb 2003 12:41:58 +0100 (MET) Message-Id: <5.2.0.9.0.20030212124027.0284c680@localhost> X-Sender: kaaprest@pop.online.no@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 12 Feb 2003 12:42:02 +0100 To: "Olaf M. Kolkman" From: Kare Presttun Subject: Re: Q2: crypto algorithm requirements for DNSSEC Cc: Mark.Andrews@isc.org, derek@ihtfp.com, namedroppers@ops.ietf.org In-Reply-To: <20030212093731.18ff9f7b.olaf@ripe.net> References: <200302120505.h1C55Od6010145@drugs.dv.isc.org> <200302120505.h1C55Od6010145@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-Spam-Status: No, hits=-0.5 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_02_03 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA29746 At 12.02.2003 09:37 +0100, Olaf M. Kolkman wrote: >My over-engineering-flag is raised as well; If RSA get's compromised >the DNS is the least of my worries... If RSA get's compromised I can >live with an unsecured DNS tree... just as I can live with it today. > >In other words: "You do not have to outrun the bear as long as you >outrun the other guy" and if RSA is compromised there are other guys >than DNS that are a much tastier game. > Sooo true!! Med vennlig hilsen | Best regards, Kĺre Presttun Tel.: +47 4100 4908 mailto:Kare@Presttun.org http://www.presttun.org/kare/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 12 09:35:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03867 for ; Wed, 12 Feb 2003 09:35:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ixqy-0001rZ-00 for namedroppers-data@psg.com; Wed, 12 Feb 2003 06:27:12 -0800 Received: from mclmx.mail.saic.com ([149.8.64.10]) by psg.com with esmtp (Exim 3.36 #1) id 18ixqn-0001qt-00 for namedroppers@ops.ietf.org; Wed, 12 Feb 2003 06:27:01 -0800 Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for namedroppers@ops.ietf.org; Wed, 12 Feb 2003 09:25:53 -0500 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.2.17) with SMTP id M2003021209264314283 for ; Wed, 12 Feb 2003 09:26:43 -0500 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2653.19) id <1XS6Q7V3>; Wed, 12 Feb 2003 09:26:25 -0500 Message-Id: <4E25ECBBC03F874CBAD03399254ADFDE104A85@US-Columbia-CIST.mail.saic.com> From: "Loomis, Rip" To: namedroppers@ops.ietf.org Subject: RE: Q2: crypto algorithm requirements for DNSSEC Date: Wed, 12 Feb 2003 09:27:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.2 required=5.0 tests=CANT_LIVE_WITHOUT,EXCHANGE_SERVER,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk (Replying to several e-mails in the thread within one, so bear with me please...) Various smart folks said things along the lines of: > The only argument I've seen (note: I'm repeating it here to answer > your question, not because I necessarily agree with it) is that is > embedded devices (like an IP Phone that does its own DNSSec > verfication) you don't want to have to implement more than you really > need. A "must" algorithm that is never used is just a lot of wasted > bits in a very restricted space. Okay, that's at least a reasonable argument. It doesn't, to me, imply that it's a significant overall advantage to anyone if we now de-specify DSA. > My over-engineering-flag is raised as well; If RSA get's compromised > the DNS is the least of my worries... If RSA get's compromised I can > live with an unsecured DNS tree... just as I can live with it today. If RSA gets compromised, DSA is not affected by the compromise, and DSA is implemented in compiled/embedded software, then the process of shifting everyone over to DSA for DNSSEC might be measured in days or weeks. If RSA is compromised and there is no alternate algorithm implemented in compiled/embedded software, then the process of deploying a new one would be measured in months or years. I agree that we only need to be "faster than the bear" on this and that a lot of other transactions involving cryptography will be more appealing targets if there's a new attack on RSA...but that doesn't mean that it's any real big savings to anyone to de-specify DSA at this point. (Also, if RSA *is* broken suddenly, It Would Be Nice if there were at least one cryptographically-related system that *didn't* need a crisis deployment of new software...) I believe, as others have provided reasonable arguments for, that having DSA implemented in software but recommending the use of RSA as the primary signing algorithm is the best answer. I would ask that we *don't* put DSA into a SHOULD NOT USE category, because there are folks out there who might prefer DSA to RSA for their own reasons. I know that leaving DSA as a "must implement" algorithm smacks of over-engineering to some folks. Can anyone provide a convincing argument of what the DSA-specific code actually "costs" a developer (in terms of size of compiled code or other criteria)? To me it seems minor in the big scheme of things, and I think DSA should be left in the "must implement" category. I can live without it, but I just haven't seen a convincing argument to remove it. Either way, I hope we can come to a resolution quickly. There are a lot of other DNSSEC items that we need to finish fighting through which I believe are more important/useful for us to spend our time on this month... --Rip -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 12 12:05:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08929 for ; Wed, 12 Feb 2003 12:05:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18j052-0007K6-00 for namedroppers-data@psg.com; Wed, 12 Feb 2003 08:49:52 -0800 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 18j04q-0007Jf-00 for namedroppers@ops.ietf.org; Wed, 12 Feb 2003 08:49:41 -0800 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA24987; Wed, 12 Feb 2003 11:49:36 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA05957; Wed, 12 Feb 2003 11:49:35 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id LAA20224; Wed, 12 Feb 2003 11:49:35 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id LAA29633; Wed, 12 Feb 2003 11:49:34 -0500 (EST) To: "Loomis, Rip" Cc: namedroppers@ops.ietf.org From: Derek Atkins Subject: Re: Q2: crypto algorithm requirements for DNSSEC References: <4E25ECBBC03F874CBAD03399254ADFDE104A85@US-Columbia-CIST.mail.saic.com> Date: 12 Feb 2003 11:49:34 -0500 In-Reply-To: <4E25ECBBC03F874CBAD03399254ADFDE104A85@US-Columbia-CIST.mail.saic.com> Message-ID: Lines: 21 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-0.7 required=5.0 tests=CANT_LIVE_WITHOUT,EMAIL_ATTRIBUTION,IN_REP_TO, QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM, RCVD_IN_RELAYS_ORDB_ORG,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_GNUS_UA, X_OSIRU_OPEN_RELAY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Loomis, Rip" writes: > I know that leaving DSA as a "must implement" algorithm smacks of > over-engineering to some folks. Can anyone provide a convincing > argument of what the DSA-specific code actually "costs" a developer > (in terms of size of compiled code or other criteria)? To me it > seems minor in the big scheme of things, and I think DSA should be > left in the "must implement" category. I can live without it, but > I just haven't seen a convincing argument to remove it. I don't think anyone has argued that leaving DSA as a "must implement" is over-engineering. I _believe_ that the arguments have been that specifying that operationally you MUST USE both RSA _AND_ DSA in your zone is over-engineering. -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.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. archive: From owner-namedroppers@ops.ietf.org Wed Feb 12 12:23:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09403 for ; Wed, 12 Feb 2003 12:23:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18j0SQ-00086k-00 for namedroppers-data@psg.com; Wed, 12 Feb 2003 09:14:02 -0800 Received: from mclmx.mail.saic.com ([149.8.64.10]) by psg.com with esmtp (Exim 3.36 #1) id 18j0SI-00086Q-00 for namedroppers@ops.ietf.org; Wed, 12 Feb 2003 09:13:54 -0800 Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for namedroppers@ops.ietf.org; Wed, 12 Feb 2003 12:12:49 -0500 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.2.17) with SMTP id M2003021212133815882 ; Wed, 12 Feb 2003 12:13:38 -0500 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2653.19) id <1XS6RTVP>; Wed, 12 Feb 2003 12:13:21 -0500 Message-Id: <4E25ECBBC03F874CBAD03399254ADFDE104A87@US-Columbia-CIST.mail.saic.com> From: "Loomis, Rip" To: "'Derek Atkins'" Cc: namedroppers@ops.ietf.org Subject: RE: Q2: crypto algorithm requirements for DNSSEC Date: Wed, 12 Feb 2003 12:14:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-0.4 required=5.0 tests=EXCHANGE_SERVER,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hello Derek-- Derek wrote: > I don't think anyone has argued that leaving DSA as a "must implement" > is over-engineering. I _believe_ that the arguments have been that > specifying that operationally you MUST USE both RSA _AND_ DSA in your > zone is over-engineering. Well, okay, but I don't think that was the question Scott originally posed: > There has been previous talk on this list regarding dropping DSA as a > mandatory to implement algorithm. Instead of writing a whole RFC just to > propose making DSA optional and RSA/SHA1 the only required algorithm, it > would be nice to seek consensus here. [Table and other discussion elided] > Q: Is the change of DSA to OPTIONAL acceptable? That will leave only > RSA/SHA1 as the only mandatory to implement algorithm. I agree that any requirement that folks MUST USE both RSA and DSA (must sign each record with both) is over-engineering, and actually provides no added security while having a significant operational cost (sorry, have to disagree with Mark A. on this one). I don't think that's what Scott originally asked, though, which is why I piped up in the first place. Did I miss something? --Rip -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 12 13:46:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11451 for ; Wed, 12 Feb 2003 13:46:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18j1hX-000ArS-00 for namedroppers-data@psg.com; Wed, 12 Feb 2003 10:33:43 -0800 Received: from pushme.nist.gov ([129.6.16.92] helo=postmark.nist.gov) by psg.com with esmtp (Exim 3.36 #1) id 18j1hS-000ArG-00 for namedroppers@ops.ietf.org; Wed, 12 Feb 2003 10:33:38 -0800 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h1CIX5f1010146 for ; Wed, 12 Feb 2003 13:33:06 -0500 (EST) Message-ID: <003201c2d2c5$2f9ddba0$b9370681@barnacle> From: "Scott Rose" To: References: <4E25ECBBC03F874CBAD03399254ADFDE104A87@US-Columbia-CIST.mail.saic.com> Subject: Re: Q2: crypto algorithm requirements for DNSSEC Date: Wed, 12 Feb 2003 13:33:06 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=0.1 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, TO_BE_REMOVED_REPLY,USER_AGENT_OE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Correct. I was taking "implementation" to mean "the resolver should be capable of verifying a SIG using algorithm X" That is slightly different that saying that all zone RR sets must have SIGs using multiple algorithms. Although that point does deserve discussion: If DSA is still "REQUIRED", does that mean each zone should have both a RSA/SHA1 SIG and DSA SIG for each RR set? I'm asking becuase I don't know what the answer should be. I don't know if there is a concensus what entails when there are multiple REQUIRED algorithms. Scott (term nitpick - my use of "resolver" is used to mean "a security aware resolver/verifier" in the above). ----- Original Message ----- From: "Loomis, Rip" > > > There has been previous talk on this list regarding dropping DSA as a > > mandatory to implement algorithm. Instead of writing a whole RFC just to > > propose making DSA optional and RSA/SHA1 the only required algorithm, it > > would be nice to seek consensus here. > [Table and other discussion elided] > > Q: Is the change of DSA to OPTIONAL acceptable? That will leave only > > RSA/SHA1 as the only mandatory to implement algorithm. > > I agree that any requirement that folks MUST USE both RSA and DSA (must > sign each record with both) is over-engineering, and actually provides > no added security while having a significant operational cost (sorry, > have to disagree with Mark A. on this one). > > I don't think that's what Scott originally asked, though, which is why > I piped up in the first place. Did I miss something? > > --Rip > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 12 13:49:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11595 for ; Wed, 12 Feb 2003 13:49:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18j1mD-000B1p-00 for namedroppers-data@psg.com; Wed, 12 Feb 2003 10:38:33 -0800 Received: from [2002:425c:4242:0:250:daff:fe82:1c39] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 18j1m7-000Aza-00 for namedroppers@ops.ietf.org; Wed, 12 Feb 2003 10:38:27 -0800 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 1382A18EC for ; Wed, 12 Feb 2003 13:37:54 -0500 (EST) Date: Wed, 12 Feb 2003 13:37:54 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Q2: crypto algorithm requirements for DNSSEC In-Reply-To: References: <4E25ECBBC03F874CBAD03399254ADFDE104A85@US-Columbia-CIST.mail.saic.com> User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030212183754.1382A18EC@thrintun.hactrn.net> X-Spam-Status: No, hits=-1.5 required=5.0 tests=CANT_LIVE_WITHOUT,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 12 Feb 2003 11:49:34 -0500, Derek Atkins wrote: > > "Loomis, Rip" writes: > > > I know that leaving DSA as a "must implement" algorithm smacks of > > over-engineering to some folks. Can anyone provide a convincing > > argument of what the DSA-specific code actually "costs" a developer > > (in terms of size of compiled code or other criteria)? To me it > > seems minor in the big scheme of things, and I think DSA should be > > left in the "must implement" category. I can live without it, but > > I just haven't seen a convincing argument to remove it. > > I don't think anyone has argued that leaving DSA as a "must implement" > is over-engineering. Sorry, but I have. Rip, I don't have numbers for this specific DSA question, but after a decade in the embedded software market I can tell you that code space -always- costs for low end devices, it's just economics. So I have to turn the question around. Show me that keeping DSA as manadatory to implement is important, and I can live with it. But keeping with no strong reason to believe that it buys us anything is bad, because code that brings no comprehensible benefit to the customer has this nasty tendency to be left out of the final product whether the spec says it's mandatory or not, at which point we have interoperability problems. --Rob -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 12 13:57:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11988 for ; Wed, 12 Feb 2003 13:57:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18j1qB-000BCL-00 for namedroppers-data@psg.com; Wed, 12 Feb 2003 10:42:39 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 18j1q6-000BC9-00 for namedroppers@ops.ietf.org; Wed, 12 Feb 2003 10:42:34 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com) by rip.psg.com with esmtp (Exim 4.12) id 18j1q6-0001Ty-00 for namedroppers@ops.ietf.org; Wed, 12 Feb 2003 10:42:34 -0800 Message-ID: <003a01c2d2c6$3d53e0e0$b9370681@barnacle> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit From: "Scott Rose" To: Subject: Q1 followup - arguements against "MUST NOT" language Date: Wed, 12 Feb 2003 13:40:38 -0500 X-Spam-Status: No, hits=0.6 required=5.0 tests=RESENT_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The general consensus is that name compression in RDATA is A Bad Thing (tm), but there are some differences on the wording for the spec: Sub-Question: What are the arguments against using the terms (1)"MUST NOT use name compression on DNS names in the RDATA on sending over the wire" (paraphrasing here) over (2)"SHOULD NOT use name compression on DNS names in the RDATA..."? Notes: A. (1) is the strength of the wording used in the unknown-rrs draft. There would be consistency. Scott -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 12 14:00:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12109 for ; Wed, 12 Feb 2003 14:00:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18j1yf-000BWr-00 for namedroppers-data@psg.com; Wed, 12 Feb 2003 10:51:25 -0800 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 18j1ya-000BW3-00 for namedroppers@ops.ietf.org; Wed, 12 Feb 2003 10:51:20 -0800 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.6/8.12.6/Debian-7) with ESMTP id h1CIpFVX014456 for ; Wed, 12 Feb 2003 19:51:15 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.6/8.12.6/Debian-7) with ESMTP id h1CIpEIV014453 for ; Wed, 12 Feb 2003 19:51:15 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 12 Feb 2003 19:51:14 +0100 (CET) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: namedroppers@ops.ietf.org Subject: Editors question: Removal of SIG RR Presentation format TTL optimisation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=0.0 required=5.0 tests=SPAM_PHRASE_02_03,USER_AGENT_PINE,X_AUTH_WARNING version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Q: Should the optimization of omitting the original TTL from the master file format representation of the SIG RR be removed from the specification ? Some background: RFC 2535 says: 7.2. Presentation of SIG RRs If the original TTL, which applies to the type signed, is the same as the TTL of the SIG RR itself, it may be omitted. The date field which follows it is larger than the maximum possible TTL so there is no ambiguity. Input for discussion: "Master file format" is a presentation format defined in RFC 1035 section 5, and is part of the base DNS specification. The DNSSEC documents define presentation formats for the DNSSEC RR types, and it seems likely that DNSSEC-aware implementations will include at least one program which will parse this presentation format. The optimization of the original TTL field results in a relatively minor saving in the presentation of what is usually a fairly large RR, and allowing the optimization increases the complexity of any code that must parse this RR format. Should the original TTL field remain optional, or should the revised specs make it mandatory? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 12 14:28:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12837 for ; Wed, 12 Feb 2003 14:28:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18j2QP-000Cm8-00 for namedroppers-data@psg.com; Wed, 12 Feb 2003 11:20:05 -0800 Received: from mclmx.mail.saic.com ([149.8.64.10]) by psg.com with esmtp (Exim 3.36 #1) id 18j2QG-000Clb-00 for namedroppers@ops.ietf.org; Wed, 12 Feb 2003 11:19:56 -0800 Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for namedroppers@ops.ietf.org; Wed, 12 Feb 2003 14:18:49 -0500 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.2.17) with SMTP id M2003021214193930522 for ; Wed, 12 Feb 2003 14:19:39 -0500 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2653.19) id <1XSX7R4J>; Wed, 12 Feb 2003 14:21:36 -0500 Message-Id: <4E25ECBBC03F874CBAD03399254ADFDE104A89@US-Columbia-CIST.mail.saic.com> From: "Loomis, Rip" To: namedroppers@ops.ietf.org Subject: RE: Q2: crypto algorithm requirements for DNSSEC Date: Wed, 12 Feb 2003 14:20:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-0.1 required=5.0 tests=EXCHANGE_SERVER,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Rip, I don't have numbers for this specific DSA question, but after a > decade in the embedded software market I can tell you that code space > -always- costs for low end devices, it's just economics. Yep. I haven't in years, but I used to do stuff in assembler for 68HC11s and such. I guess I was hoping that memory was now "cheap" everywhere--not that that would really be sufficient justification to bloat DNS code with non-useful algorithms. But read on... > So I have to turn the question around. Show me that keeping DSA as > manadatory to implement is important, and I can live with it. But > keeping with no strong reason to believe that it buys us anything is > bad, because code that brings no comprehensible benefit to the > customer has this nasty tendency to be left out of the final product > whether the spec says it's mandatory or not, at which point we have > interoperability problems. OK. I agree with a previous characterization that if RSA gets broken suddenly/cataclysmically, then DNS won't even be *close* to the low-hanging fruit on the vulnerability tree. I can't come up with a convincing enough reason, at that point, why DSA is "useful enough" to keep as a MUST IMPLEMENT--as long as we believe that letting embedded devices drive DNSSEC choices is a Good Idea. Whether letting embedded devices drive DNSSEC choices really *is* a Good Idea I leave to someone with a better big picture of such things. From my perspective, the idea that *any* embedded device is actually expected to implement a security-aware resolver that can do its own signature verification is ludicrous. It seems more likely to me that such a device would implement IPSec to some trusted "mothership" which could provide DNSSEC resolution, or that such a device would blow off DNSSEC entirely, than that such a device would actually make use of SIG and KEY records. So my counter-question, after thinking more about this, is: Does anyone *really* think that embedded devices should drive the choices made in writing DNSSEC specifications? Note that the answer to that question has implications far beyond this single issue. Even if we don't make the choice based solely on embedded devices, the argument that "if we have DSA implemented already then we can recover a signed tree faster" sounds less and less useful to me. As a result I find myself somewhere squarely in the "undecided" category overall--so I'll hush now. --Rip -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 12 14:32:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12938 for ; Wed, 12 Feb 2003 14:32:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18j2VC-000D0G-00 for namedroppers-data@psg.com; Wed, 12 Feb 2003 11:25:02 -0800 Received: from one.elistx.com ([209.116.252.130]) by psg.com with esmtp (Exim 3.36 #1) id 18j2V2-000CzY-00 for namedroppers@ops.ietf.org; Wed, 12 Feb 2003 11:24:52 -0800 Received: from ogud.com (pcp816081pcs.nrockv01.md.comcast.net [68.49.60.118]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HA700MOEN9YS4@eListX.com> for namedroppers@ops.ietf.org; Wed, 12 Feb 2003 14:25:10 -0500 (EST) Received: from ENGILL.ogud.com (ns.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.3/8.12.3) with ESMTP id h1CJN7ts002074 for ; Wed, 12 Feb 2003 14:23:07 -0500 (EST envelope-from ogud@ogud.com) Date: Wed, 12 Feb 2003 14:21:09 -0500 From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Q-03: inclusion of KEY records in additional records section X-Sender: post@localhost To: namedroppers@ops.ietf.org Message-id: <5.1.1.6.2.20030212134348.0254be98@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=us-ascii X-Spam-Status: No, hits=3.1 required=5.0 tests=GAPPY_TEXT,RCVD_IN_RFCI,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: *** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Issue: Is there need to specify that KEY records be placed in additional section on certain queries/responses. Q: Can the DS document outlaw the rules from 2535 that requires inclusion of KEY in additional section ? Background: RFC2535 Section 3.5 says: An explicit request for KEY RRs does not cause any special additional information processing except, of course, for the corresponding SIG RR from a security aware server (see Section 4.2). Security aware DNS servers include KEY RRs as additional information in responses, where a KEY is available, in the following cases: (1) On the retrieval of SOA or NS RRs, the KEY RRset with the same name (perhaps just a zone key) SHOULD be included as additional information if space is available. If not all additional information will fit, type A and AAAA glue RRs have higher priority than KEY RR(s). (2) On retrieval of type A or AAAA RRs, the KEY RRset with the same name (usually just a host RR and NOT the zone key (which usually would have a different name)) SHOULD be included if space is available. On inclusion of A or AAAA RRs as additional information, the KEY RRset with the same name should also be included but with lower priority than the A or AAAA RRs Rule 2 is obviously there for optimization reasons and was put there to push out application (IPSEC) keys. As applications are now directed to get their own key RR type and NOT place any additional section processing requirements on DNS, the value of this rule is operationally minimal. The first rule is more interesting and is focused at the needs of DNS protocol elements. There are two reasons for this rule, 1. Optimization: attempt to distribute KEY RRsets with fewer round trips. 2. NULL KEY push: RFC2535 has NULL-KEY residing in the parent zone for unsecured delegations. The rule above forces the push of this KEY set along with the NS set in referrals. DS document eliminates the NULL-KEY and replaces its role with a rule requiring NXT in authority section of referrals. Some Justifications for eliminating rule 1: a. There is no need to push NULL KEY records anymore b. The rule is complex in implementation as KEY is the lowest priority RRset to be included in additional section. c. The rule does only partially accomplishes its intent (see example below) d. The rule makes negative answers much bigger as the SOA in authority section triggers the rule. e. A security aware resolver should know what information it needs and be able to ask for multiple RRsets in parallel. f. The information is going to be redundant in many cases. Example showing why the optimization does not work in a common case. This is an example in secure universe. Q: a.b.c.d.example. TXT (all zones are one label deep). Server 1: is authoritative for example. Server 2: is authoritative for d.example. Server 3: is authoritative for c.d.example. Server 4: is authoritative for b.c.d.example. Trace (QN: query name, QT: query type, QS: server queried) R: QN: a.b.c.d.example. QT: TXT QS: 1 S1: AU: d.example. NS 2 d.example. DS d.example. SIG(DS) R: QN: a.b.c.d.example. QT: TXT QS: 2 S2: AU: c.d.example. NS 3 c.d.example. DS c.d.example. SIG(DS) R: QN: a.b.c.d.example. QT: TXT QS:3 S3: AU: b.c.d.example. NS 4 b.c.d.example. DS b.c.d.example. SIG(DS) R: QN: a.b.c.d.example. QT: TXT QS:4 S4: AN: a.b.c.d.example. TXT a.b.c.d.example. SIG(TXT) In order to validate the chain the resolver still needs to query for KEY's for example., d.example., c.d.example., b.c.d.example. 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. archive: From owner-namedroppers@ops.ietf.org Wed Feb 12 14:59:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13980 for ; Wed, 12 Feb 2003 14:59:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18j2wC-000EAI-00 for namedroppers-data@psg.com; Wed, 12 Feb 2003 11:52:56 -0800 Received: from [2002:425c:4242:0:250:daff:fe82:1c39] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 18j2w7-000E8C-00 for namedroppers@ops.ietf.org; Wed, 12 Feb 2003 11:52:51 -0800 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 1D1F918EC for ; Wed, 12 Feb 2003 14:52:17 -0500 (EST) Date: Wed, 12 Feb 2003 14:52:17 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Q2: crypto algorithm requirements for DNSSEC In-Reply-To: <4E25ECBBC03F874CBAD03399254ADFDE104A89@US-Columbia-CIST.mail.saic.com> References: <4E25ECBBC03F874CBAD03399254ADFDE104A89@US-Columbia-CIST.mail.saic.com> User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030212195217.1D1F918EC@thrintun.hactrn.net> X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Wed, 12 Feb 2003 14:20:08 -0500, Rip Loomis wrote: > > Yep. I haven't in years, but I used to do stuff in assembler for > 68HC11s and such. I guess I was hoping that memory was now "cheap" > everywhere--not that that would really be sufficient justification to > bloat DNS code with non-useful algorithms. But read on... The way it seems to work out is that, as soon as resources become cheap enough that the current generation of widgets are no longer resource constrained, a new generation of even cheaper widgets redefines the meaning of "low end". As far as I can tell, there will always be people willing to sweat blood to try to make a go of marketing some cool new product with profit margins that can only be detected using an electron microscope. > OK. I agree with a previous characterization that if RSA gets > broken suddenly/cataclysmically, then DNS won't even be *close* to > the low-hanging fruit on the vulnerability tree. I can't come up > with a convincing enough reason, at that point, why DSA is "useful > enough" to keep as a MUST IMPLEMENT--as long as we believe that letting > embedded devices drive DNSSEC choices is a Good Idea. That's fair, but read on :). > Whether letting embedded devices drive DNSSEC choices really *is* a > Good Idea I leave to someone with a better big picture of such things. > From my perspective, the idea that *any* embedded device is actually > expected to implement a security-aware resolver that can do its own > signature verification is ludicrous. It seems more likely to me > that such a device would implement IPSec to some trusted "mothership" > which could provide DNSSEC resolution, or that such a device would > blow off DNSSEC entirely, than that such a device would actually make > use of SIG and KEY records. In the long run, I think it's reasonable to expect that small and highly mobile devices will end up needing to perform their own verification, precisely because they are mobile and may frequently find themselves in environments where they have no usable trust relationship with the local infrastructure. Tunneling across an untrusted infrastructure to get back to a home base is another approach, but it's kinda fragile. > So my counter-question, after thinking more about this, is: > Does anyone *really* think that embedded devices should drive the choices > made in writing DNSSEC specifications? Note that the answer to that > question has implications far beyond this single issue. Drive the choices? No. Be considered along with everything else when making the choices? Yes. As I tried to say earlier, give me a convincing argument that keeping DSA madatory would make the world a better place and I'll shut up about this. But, other things being equal, please don't gratuitously drive up the cost of my toaster :). > Even if we don't make the choice based solely on embedded devices, > the argument that "if we have DSA implemented already then we can > recover a signed tree faster" sounds less and less useful to me. > As a result I find myself somewhere squarely in the "undecided" category > overall--so I'll hush now. Fair enough. I'll shut up now too unless somebody else wants me to blather on about it. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 12 17:42:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18086 for ; Wed, 12 Feb 2003 17:42:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18j5OT-000KFf-00 for namedroppers-data@psg.com; Wed, 12 Feb 2003 14:30:17 -0800 Received: from [2001:470:1f00:ffff::5a1] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 18j5ON-000KDo-00 for namedroppers@ops.ietf.org; Wed, 12 Feb 2003 14:30:11 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h1CMTRd6013793; Thu, 13 Feb 2003 09:29:27 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200302122229.h1CMTRd6013793@drugs.dv.isc.org> To: Roy Arends Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: Editors question: Removal of SIG RR Presentation format TTL optimisation In-reply-to: Your message of "Wed, 12 Feb 2003 19:51:14 BST." Date: Thu, 13 Feb 2003 09:29:27 +1100 X-Spam-Status: No, hits=0.9 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03, TO_BE_REMOVED_REPLY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Q: Should the optimization of omitting the original TTL from the > master file format representation of the SIG RR be removed from the > specification ? It should go. > Some background: > > RFC 2535 says: > > 7.2. Presentation of SIG RRs > > If the original TTL, which applies to the type signed, is the same as > the TTL of the SIG RR itself, it may be omitted. The date field which > follows it is larger than the maximum possible TTL so there is no > ambiguity. > > Input for discussion: > > "Master file format" is a presentation format defined in RFC 1035 section > 5, and is part of the base DNS specification. The DNSSEC documents define > presentation formats for the DNSSEC RR types, and it seems likely that > DNSSEC-aware implementations will include at least one program which > will parse this presentation format. > > The optimization of the original TTL field results in a relatively minor > saving in the presentation of what is usually a fairly large RR, and > allowing the optimization increases the complexity of any code that must > parse this RR format. > > Should the original TTL field remain optional, or should the revised specs > make it mandatory? > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 12 19:52:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20298 for ; Wed, 12 Feb 2003 19:52:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18j7Pw-000PfW-00 for namedroppers-data@psg.com; Wed, 12 Feb 2003 16:39:56 -0800 Received: from thing.verisignlabs.com ([65.201.175.62] helo=cliffie.verisignlabs.com) by psg.com with esmtp (Exim 3.36 #1) id 18j7Ps-000PfK-00 for namedroppers@ops.ietf.org; Wed, 12 Feb 2003 16:39:52 -0800 Received: from pinion.admin.cto.netsol.com (h87.s239.netsol.com [216.168.239.87]) (AUTH: LOGIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by cliffie.verisignlabs.com with esmtp; Wed, 12 Feb 2003 19:39:49 -0500 From: David Blacka Organization: Verisign, Inc. To: "=?iso-8859-1?q?=D3lafur?= =?iso-8859-1?q?=20Gu=F0mundsson?=" , namedroppers@ops.ietf.org Subject: Re: Q-03: inclusion of KEY records in additional records section Date: Wed, 12 Feb 2003 19:39:48 -0500 User-Agent: KMail/1.5 References: <5.1.1.6.2.20030212134348.0254be98@localhost> In-Reply-To: <5.1.1.6.2.20030212134348.0254be98@localhost> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200302121927.47595.davidb@verisignlabs.com> Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA20298 On Wednesday 12 February 2003 02:21 pm, Ólafur Guđmundsson wrote: > > > > Issue: Is there need to specify that KEY records be placed in additional > section on certain queries/responses. > > Q: Can the DS document outlaw the rules from 2535 that requires > inclusion of KEY in additional section ? ... > (1) On the retrieval of SOA or NS RRs, the KEY RRset with the same > name (perhaps just a zone key) SHOULD be included as additional > information if space is available. If not all additional information > will fit, type A and AAAA glue RRs have higher priority than KEY > RR(s). Hmm. I must have initially misread this section. I more or less internalized it as "return the KEYs in the ADDITIONAL section when returning SIGs that need to be verified with those keys." Which, of course, isn't what it says at all. But that is what made sense to me. Then, in a world where there was no truncation, a resolver would get back all of the info it needed to validate the record in a single round trip. This was before DS was introduced, of course. Given this rule, it looks to me that the only case where one would *not* get the zone apex keyset back (barring truncation) is a referral. NXDOMAIN has the zone SOA, postive and NODATA responses have the zone's NS set. Maybe I'm missing something. > DS document eliminates the NULL-KEY and replaces its role with a rule > requiring NXT in authority section of referrals. > > Some Justifications for eliminating rule 1: > a. There is no need to push NULL KEY records anymore > b. The rule is complex in implementation as KEY is the lowest priority > RRset to be included in additional section. > c. The rule does only partially accomplishes its intent (see example below) > d. The rule makes negative answers much bigger as the SOA in authority section > triggers the rule. > e. A security aware resolver should know what information it needs and be able > to ask for multiple RRsets in parallel. > f. The information is going to be redundant in many cases. It seems to me that with DS, this rule should be changed somehow. We can either eliminate it or strengthen it. By "strengthen", I mean make it return the zone KEY rrset in referral cases as well. Eliminating the rule (never returning KEY rrsets in the additional section) optimizes for code complexity and message size at the expense of round trips. Strengthing the rule does the opposite: optimizes for round trips at the expense of code complexity and message size. I'm not sure which is right. At the moment I would probably vote to eliminate the rule. Smaller messages and more predicable client behavior seems better than fewer round trips at the moment. -- David Blacka Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 13 00:08:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24597 for ; Thu, 13 Feb 2003 00:08:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jBID-000BVa-00 for namedroppers-data@psg.com; Wed, 12 Feb 2003 20:48:13 -0800 Received: from one.elistx.com ([209.116.252.130]) by psg.com with esmtp (Exim 3.36 #1) id 18jBIB-000BVO-00 for namedroppers@ops.ietf.org; Wed, 12 Feb 2003 20:48:11 -0800 Received: from ogud.com (pcp816081pcs.nrockv01.md.comcast.net [68.49.60.118]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HA800HJ7DCW7A@eListX.com> for namedroppers@ops.ietf.org; Wed, 12 Feb 2003 23:48:33 -0500 (EST) Received: from ENGILL.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.3/8.12.3) with ESMTP id h1D4kJts003402; Wed, 12 Feb 2003 23:46:19 -0500 (EST envelope-from ogud@ogud.com) Date: Wed, 12 Feb 2003 23:47:06 -0500 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: DNSEXT WGLC Summary: RFC1886bis-01 X-Sender: (Unverified) To: Erik Nordmark Cc: namedroppers@ops.ietf.org Message-id: <5.1.1.6.2.20030212234104.016bdc90@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=us-ascii X-Spam-Status: No, hits=3.1 required=5.0 tests=RCVD_IN_RFCI,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: *** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Erik, The DNSEXT working group has concluded a last call on this document and there is consensus on requesting it be advanced as Draft Standard. >This document replaces RFC1886 with minimal changes incorporated from >interoperabilty testing and RFC3152 (ip6.arpa. delegation) > >This document is on standards track and is to be advanced to Draft >Standard it and supporting interoperabilty test report and is available >via following URLs: >http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc1886bis-01.txt > > >http://www.6wind.com/RFC1886/testRFC1886.html Olafur & 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. archive: From owner-namedroppers@ops.ietf.org Thu Feb 13 04:23:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07780 for ; Thu, 13 Feb 2003 04:23:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jFL9-000Kke-00 for namedroppers-data@psg.com; Thu, 13 Feb 2003 01:07:31 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #1) id 18jFL6-000Kjx-00 for namedroppers@ops.ietf.org; Thu, 13 Feb 2003 01:07:28 -0800 Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.5/8.11.6) with SMTP id h1D97PAq013568; Thu, 13 Feb 2003 10:07:25 +0100 Date: Thu, 13 Feb 2003 10:07:25 +0100 From: "Olaf M. Kolkman" To: Rob Austein Cc: namedroppers@ops.ietf.org Subject: Re: Q2: crypto algorithm requirements for DNSSEC Message-Id: <20030213100725.21a30eef.olaf@ripe.net> In-Reply-To: <20030212183754.1382A18EC@thrintun.hactrn.net> References: <4E25ECBBC03F874CBAD03399254ADFDE104A85@US-Columbia-CIST.mail.saic.com> <20030212183754.1382A18EC@thrintun.hactrn.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.5 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit O > Sorry, but I have. > > Rip, I don't have numbers for this specific DSA question, but after a > decade in the embedded software market I can tell you that code space > -always- costs for low end devices, it's just economics. Curiosity: How many embedded devices run a full blown resolver today? Will embedded devices run their own verification code or will they set up a trust relation with a verifying resolver. --Olaf --------------------------------------------| Olaf M. Kolkman | www.ripe.net/disi -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 13 04:36:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08062 for ; Thu, 13 Feb 2003 04:36:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jFgK-000MBX-00 for namedroppers-data@psg.com; Thu, 13 Feb 2003 01:29:24 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 18jFgI-000MBL-00 for namedroppers@ops.ietf.org; Thu, 13 Feb 2003 01:29:22 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com) by rip.psg.com with esmtp (Exim 4.12) id 18jFgI-000G69-00 for namedroppers@ops.ietf.org; Thu, 13 Feb 2003 01:29:22 -0800 Message-ID: <20030213091929.GB30441@atoom.net> Mail-Followup-To: Scott Rose , namedroppers@ops.ietf.org References: <4E25ECBBC03F874CBAD03399254ADFDE104A87@US-Columbia-CIST.mail.saic.com> <003201c2d2c5$2f9ddba0$b9370681@barnacle> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003201c2d2c5$2f9ddba0$b9370681@barnacle> Date: Thu, 13 Feb 2003 10:19:29 +0100 From: Miek Gieben To: Scott Rose Cc: namedroppers@ops.ietf.org Subject: Re: Q2: crypto algorithm requirements for DNSSEC X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO, SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] [On 12 Feb, @19:33, Scott wrote in "Re: Q2: crypto algorithm requi ..."] > Although that point does deserve discussion: If DSA is still "REQUIRED", > does that mean each zone should have both a RSA/SHA1 SIG and DSA SIG for > each RR set? > > I'm asking becuase I don't know what the answer should be. I don't know if > there is a concensus what entails when there are multiple REQUIRED > algorithms. I'm not sure what the answer should be, but I don't think a TLD will ever want to support two different algorithms in a zone, grtz Miek -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 13 05:32:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08854 for ; Thu, 13 Feb 2003 05:32:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jGYk-000CX6-00 for namedroppers-data@psg.com; Thu, 13 Feb 2003 02:25:38 -0800 Received: from nic.crt.se ([193.12.107.10]) by psg.com with esmtp (Exim 3.36 #1) id 18jGYi-000CWu-00 for namedroppers@ops.ietf.org; Thu, 13 Feb 2003 02:25:36 -0800 Received: from mail.crt.se (postiljon.crt.se [172.16.1.14]) by nic.crt.se (Postfix) with ESMTP id 6B8805283; Thu, 13 Feb 2003 11:25:34 +0100 (MET) Received: from crt.se (fonbella.crt.se [172.16.1.169]) by mail.crt.se (Postfix) with ESMTP id 465CC1D99; Thu, 13 Feb 2003 11:25:34 +0100 (MET) Date: Thu, 13 Feb 2003 11:25:34 +0100 (MET) From: Jakob Schlyter To: Miek Gieben Cc: Scott Rose , namedroppers@ops.ietf.org Subject: Re: Q2: crypto algorithm requirements for DNSSEC In-Reply-To: <20030213091929.GB30441@atoom.net> Message-ID: References: <4E25ECBBC03F874CBAD03399254ADFDE104A87@US-Columbia-CIST.mail.saic.com> <003201c2d2c5$2f9ddba0$b9370681@barnacle> <20030213091929.GB30441@atoom.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 13 Feb 2003, Miek Gieben wrote: > I'm not sure what the answer should be, but I don't think a TLD will > ever want to support two different algorithms in a zone, why? due to zone size constraints? I do not agree. jakob -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 13 05:38:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08916 for ; Thu, 13 Feb 2003 05:38:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jGid-000Cqz-00 for namedroppers-data@psg.com; Thu, 13 Feb 2003 02:35:51 -0800 Received: from [2001:610:ff:1::2] (helo=bartok.sidn.nl) by psg.com with esmtp (Exim 3.36 #1) id 18jGib-000Cqn-00 for namedroppers@ops.ietf.org; Thu, 13 Feb 2003 02:35:49 -0800 Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.12.6/8.12.6) with ESMTP id h1DAZemU049197; Thu, 13 Feb 2003 11:35:40 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200302131035.h1DAZemU049197@bartok.sidn.nl> To: "Olaf M. Kolkman" cc: Rob Austein , namedroppers@ops.ietf.org Subject: Re: Q2: crypto algorithm requirements for DNSSEC In-reply-to: Your message of Thu, 13 Feb 2003 10:07:25 +0100. <20030213100725.21a30eef.olaf@ripe.net> Date: Thu, 13 Feb 2003 11:35:39 +0100 From: Jaap Akkerhuis X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Olaf: Curiosity: How many embedded devices run a full blown resolver today? I don't know about today, but motorola apparently announced that they are going to use Linux in theit mobile phones and other personal electronic devices: http://news.com.com/2100-1001-984424.html?tag=fd_top jaap -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 13 07:07:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10437 for ; Thu, 13 Feb 2003 07:07:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jI53-000Fpf-00 for namedroppers-data@psg.com; Thu, 13 Feb 2003 04:03:05 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 18jI51-000FpS-00 for namedroppers@ops.ietf.org; Thu, 13 Feb 2003 04:03:03 -0800 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 9C499137F05; Thu, 13 Feb 2003 04:03:02 -0800 (PST) To: Jakob Schlyter Cc: Miek Gieben , Scott Rose , namedroppers@ops.ietf.org Subject: Re: Q2: crypto algorithm requirements for DNSSEC In-Reply-To: Message from Jakob Schlyter of "Thu, 13 Feb 2003 11:25:34 +0100." Date: Thu, 13 Feb 2003 04:03:02 -0800 Message-ID: <31581.1045137782@shell.nominum.com> From: Jim Reid X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Jakob" == Jakob Schlyter writes: >> I'm not sure what the answer should be, but I don't think a TLD >> will ever want to support two different algorithms in a zone, Jakob> why? due to zone size constraints? I do not agree. Well zone size is one consideration. Another would be the extra time and resources needed to sign the same data with different algorithms. What would be the justification for all that extra overhead? The case for multiple algorithms is not clear, at least not to me. Having just one algorithm would be a SPoF. OTOH it would keep things simple for signing and verifying => making deployment more straightforward. And ISTR from cryptography 101 class that it's usually not a good idea to encrypt or sign the same stuff with different keys or algorithms. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 13 07:11:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10496 for ; Thu, 13 Feb 2003 07:11:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jIBG-000G6X-00 for namedroppers-data@psg.com; Thu, 13 Feb 2003 04:09:30 -0800 Received: from nic.crt.se ([193.12.107.10]) by psg.com with esmtp (Exim 3.36 #1) id 18jIBF-000G64-00 for namedroppers@ops.ietf.org; Thu, 13 Feb 2003 04:09:29 -0800 Received: from mail.crt.se (postiljon.crt.se [172.16.1.14]) by nic.crt.se (Postfix) with ESMTP id F04325286; Thu, 13 Feb 2003 13:09:25 +0100 (MET) Received: from crt.se (stargate.crt.se [172.16.0.11]) by mail.crt.se (Postfix) with ESMTP id 962CB1D99; Thu, 13 Feb 2003 13:09:25 +0100 (MET) Date: Thu, 13 Feb 2003 13:09:25 +0100 (CET) From: Jakob Schlyter To: Jim Reid Cc: Miek Gieben , Scott Rose , namedroppers@ops.ietf.org Subject: Re: Q2: crypto algorithm requirements for DNSSEC In-Reply-To: <31581.1045137782@shell.nominum.com> Message-ID: References: <31581.1045137782@shell.nominum.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 13 Feb 2003, Jim Reid wrote: > Well zone size is one consideration. maybe for .de and .com, otherwise I doubt that is a real problem. > Another would be the extra time and resources needed to sign the same > data with different algorithms. I wouldn't consider the resources used for signing a problem with modern hardware - people sign .com with their desktop machine within reasonable time. jakob -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 13 08:09:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11416 for ; Thu, 13 Feb 2003 08:09:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jIz4-000Hxd-00 for namedroppers-data@psg.com; Thu, 13 Feb 2003 05:00:58 -0800 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by psg.com with esmtp (Exim 3.36 #1) id 18jIyZ-000HvZ-00 for namedroppers@ops.ietf.org; Thu, 13 Feb 2003 05:00:27 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA01657; Thu, 13 Feb 2003 05:00:25 -0800 (PST) Received: from localhost (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h1DD0OP18356; Thu, 13 Feb 2003 14:00:24 +0100 (MET) Date: Thu, 13 Feb 2003 13:56:44 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: DNSEXT WGLC Summary: RFC1886bis-01 To: =?iso-8859-1?Q?=D3lafur_Gudmundsson/DNSEXT_co-chair?= Cc: Erik Nordmark , namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" <5.1.1.6.2.20030212234104.016bdc90@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > The DNSEXT working group has concluded a last call on this document > and there is consensus on requesting it be advanced as Draft Standard. I've looked it over. The interoperability report identifies some RR types for which AAA additional section processing makes sense that are not explicitly specified in the draft: * CNAME records (not mentioned in RFC1886) * PTR records (mentioned in RFC1886, but not explicitly) * SRV records (not mentioned in RFC1886) * SOA records (not mentioned in RFC1886) Wouldn't it make sense to add explicit mention of those types to section 3 (right now the section says for example NS and MX). > Normative References For this document to become a draft standard all normative references need to be draft standard or higher. > [4] Gilligan, R., and E. Nordmark, "Transition Mechanisms for IPv6 > Hosts and Routers", RFC 2893, FreeGate Corp., Sun Microsystems > Inc., August 2000. > This RFC is being updated. The current draft is > "draft-ietf-ngtrans-mech-v2-00.txt", Gilligan, R., and > E. Nordmark, July 17, 2002 Is this really a normative reference i.e. something that one needs to read and understand in order to implement RFC1886bis? Also, [5] through [8] seems like informative references. (But [3] is normative for the textual representation.) 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. archive: From owner-namedroppers@ops.ietf.org Thu Feb 13 08:27:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11767 for ; Thu, 13 Feb 2003 08:27:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jJKD-000Iju-00 for namedroppers-data@psg.com; Thu, 13 Feb 2003 05:22:49 -0800 Received: from nic.crt.se ([193.12.107.10]) by psg.com with esmtp (Exim 3.36 #1) id 18jJKB-000Iji-00 for namedroppers@ops.ietf.org; Thu, 13 Feb 2003 05:22:47 -0800 Received: from mail.crt.se (postiljon.crt.se [172.16.1.14]) by nic.crt.se (Postfix) with ESMTP id 520BA5283; Thu, 13 Feb 2003 14:22:46 +0100 (MET) Received: from crt.se (stargate.crt.se [172.16.0.11]) by mail.crt.se (Postfix) with ESMTP id 02D351D99; Thu, 13 Feb 2003 14:22:46 +0100 (MET) Date: Thu, 13 Feb 2003 14:22:45 +0100 (CET) From: Jakob Schlyter To: Miek Gieben Cc: Jim Reid , Scott Rose , namedroppers@ops.ietf.org Subject: Re: Q2: crypto algorithm requirements for DNSSEC In-Reply-To: <20030213130103.GF31759@atoom.net> Message-ID: References: <31581.1045137782@shell.nominum.com> <20030213130103.GF31759@atoom.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 13 Feb 2003, Miek Gieben wrote: > > I wouldn't consider the resources used for signing a problem with modern > > hardware - people sign .com with their desktop machine within reasonable > > time. > > so you're asking a TLD to carry twice the load for an event which is unlikely > to happen soon? yes, if we come to the conclusion that we should use two algorithms. > And further more, we (.nl), have to explain to every domain holder in > .nl that signing with 2 algorithms is better than signing with 1. if we cannot explain why to normal people, I'm not sure we should do two algorithms. jakob -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 13 10:12:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15003 for ; Thu, 13 Feb 2003 10:12:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jKnR-000Pwp-00 for namedroppers-data@psg.com; Thu, 13 Feb 2003 06:57:05 -0800 Received: from mclmx.mail.saic.com ([149.8.64.10]) by psg.com with esmtp (Exim 3.36 #1) id 18jKnM-000Pw9-00 for namedroppers@ops.ietf.org; Thu, 13 Feb 2003 06:57:00 -0800 Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for namedroppers@ops.ietf.org; Thu, 13 Feb 2003 09:55:51 -0500 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.2.17) with SMTP id M2003021309564132314 for ; Thu, 13 Feb 2003 09:56:41 -0500 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2653.19) id <1XS641AC>; Thu, 13 Feb 2003 09:56:23 -0500 Message-Id: <4E25ECBBC03F874CBAD03399254ADFDE104A8F@US-Columbia-CIST.mail.saic.com> From: "Loomis, Rip" To: namedroppers@ops.ietf.org Subject: RE: Q2: crypto algorithm requirements for DNSSEC Date: Thu, 13 Feb 2003 09:57:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-0.1 required=5.0 tests=EXCHANGE_SERVER,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >> Curiosity: How many embedded devices run a full blown resolver today? > > I don't know about today, but motorola apparently announced that > they are going to use Linux in theit mobile phones and other personal > electronic devices: I like Linux and use it daily. However, the idea that a mobile device can run even an *embedded* version of Linux but somehow wouldn't have room for DSA in addition to RSA seems (to me) to be ludicrous. So I'm not sure that this latest disclosure helps us much on figuring out whether DSA should remain a "must implement in the software" algorithm. If a mobile phone running Linux has any crypto support at all, I would expect it would have all of the OpenSSL library. --Rip -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 13 10:37:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15932 for ; Thu, 13 Feb 2003 10:37:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jLHP-0002ZU-00 for namedroppers-data@psg.com; Thu, 13 Feb 2003 07:28:03 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 18jLHN-0002ZI-00 for namedroppers@ops.ietf.org; Thu, 13 Feb 2003 07:28:01 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com) by rip.psg.com with esmtp (Exim 4.12) id 18jLHN-000JNs-00 for namedroppers@ops.ietf.org; Thu, 13 Feb 2003 07:28:01 -0800 Message-ID: <20030213130103.GF31759@atoom.net> Mail-Followup-To: Jakob Schlyter , Jim Reid , Scott Rose , namedroppers@ops.ietf.org References: <31581.1045137782@shell.nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Date: Thu, 13 Feb 2003 14:01:03 +0100 From: Miek Gieben To: Jakob Schlyter Cc: Jim Reid , Scott Rose , namedroppers@ops.ietf.org Subject: Re: Q2: crypto algorithm requirements for DNSSEC X-Spam-Status: No, hits=-1.2 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO, SPAM_PHRASE_03_05 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] [On 13 Feb, @13:09, Jakob wrote in "Re: Q2: crypto algorithm requi ..."] > On Thu, 13 Feb 2003, Jim Reid wrote: > > > Well zone size is one consideration. > > maybe for .de and .com, otherwise I doubt that is a real problem. true, the size of .nl would be something of 600 MB (with 768 bits keys). This can be handled. > > Another would be the extra time and resources needed to sign the same > > data with different algorithms. > > I wouldn't consider the resources used for signing a problem with modern > hardware - people sign .com with their desktop machine within reasonable > time. so you're asking a TLD to carry twice the load for an event which is unlikely to happen soon? And further more, we (.nl), have to explain to every domain holder in .nl that signing with 2 algorithms is better than signing with 1. I think that will be very hard to do and enforce. grtz Miek -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 13 11:48:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18261 for ; Thu, 13 Feb 2003 11:48:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jMSB-0009In-00 for namedroppers-data@psg.com; Thu, 13 Feb 2003 08:43:15 -0800 Received: from [2002:425c:4242:0:250:daff:fe82:1c39] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 18jMS8-0009FA-00 for namedroppers@ops.ietf.org; Thu, 13 Feb 2003 08:43:13 -0800 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 9456718ED for ; Thu, 13 Feb 2003 11:42:37 -0500 (EST) Date: Thu, 13 Feb 2003 11:42:37 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Q2: crypto algorithm requirements for DNSSEC In-Reply-To: <20030213100725.21a30eef.olaf@ripe.net> References: <4E25ECBBC03F874CBAD03399254ADFDE104A85@US-Columbia-CIST.mail.saic.com> <20030212183754.1382A18EC@thrintun.hactrn.net> <20030213100725.21a30eef.olaf@ripe.net> User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030213164237.9456718ED@thrintun.hactrn.net> X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Thu, 13 Feb 2003 10:07:25 +0100, Olaf Kolkman wrote: > > Curiosity: How many embedded devices run a full blown resolver today? > Will embedded devices run their own verification code or will they set > up a trust relation with a verifying resolver. I was thinking more along the lines of a recusive-mode-only resolver with verification capabilities. Device lets local infrastructure do the donkey work of iterative resolution, but does its own verifying. As others have noted, an embedded Linux system may have BIND9, OpenSSL, OpenSSH, seven elephants, and the kitchen sink, but such devices tend to have relatively large flash chips (8 or 16 MB). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 13 12:17:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18827 for ; Thu, 13 Feb 2003 12:17:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jMsz-000BuV-00 for namedroppers-data@psg.com; Thu, 13 Feb 2003 09:10:57 -0800 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #1) id 18jMsu-000Btr-00 for namedroppers@ops.ietf.org; Thu, 13 Feb 2003 09:10:52 -0800 Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57] (may be forged)) by peacock.verisign.com (8.12.1/) with ESMTP id h1DH9lCq016123; Thu, 13 Feb 2003 09:09:47 -0800 (PST) Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id <15SGWQ1J>; Thu, 13 Feb 2003 09:10:26 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Roy Arends'" , Erik Nordmark Cc: =?iso-8859-1?Q?=D3lafur_Gudmundsson/DNSEXT_co-chair?= , namedroppers@ops.ietf.org Subject: Summary RE: DNSEXT WGLC: DNSSEC Opt-in Date: Thu, 13 Feb 2003 09:10:16 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_0014_01C2D358.D96A7290"; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=0.9 required=5.0 tests=EMAIL_ATTRIBUTION,EXCHANGE_SERVER,MAY_BE_FORGED, MISSING_OUTLOOK_NAME,OPT_IN,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0014_01C2D358.D96A7290 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable There were 27 messages in this thread from 10 distinct individuals. Olafur posed 3 questions as follows: Q: Is the description in the document of Opt-In complete ? Answers: Kosters - Yes [detailed response] Rose - I believe it is. Loomis - I believe so. Hardie - Raised issue with 3.1.1, possible issue with Section 7 Blacka - Stated that issue raised by Hardie had been tested Could add text to draft, not sure it is necessary Austein - It would be a good idea to mention the issue [3.1.1]=20 explictly, but it's not a showstopper. Arends - Yes Q: Does this document satisfy people as being implement able and testable specification ? Answers: Kosters - Yes [detailed response] Loomis - I believe that the specification can be implemented and tested. Wellington - i believe that the current version of the specification=20 is complete. Q: Are there implementations of opt-in and have there been any tests ? Answers: Kosters - Yes [detailed response] Austein - asked about resolver side implementations Arends - Yes, Verisignlabs and ISC have auth.server implementations,=20 ISC has a resolver implementation. Nordmark - Does this mean that there is a caching resolver=20 implementation that has been tested?=20 Arends - I don't have material on how thorough the caching resolver=20 implementation has been tested. Wellington - yes. Vixie - In message prior to question stated that "OPT-IN softens the=20 privacy-related impact of early dnssec deployment" and "because=20 of some obscure corner cases which have shown up in private=20 workshops that are much easier to isolate and to think about=20 in an opt-in world." In addition there were responses on the question of advancement Hallam-Baker - It should advance Vixie - dunno. but in any case i am strongly in favour of it Conrad - To be perfectly honest, I no longer care=20 Wellington - yes. (notes to be posted here shortly, so they tell me.) Kosters - It should advance Rose - It should advance Loomis - I support the advancement of the current=20 Opt-In draft along the standards track. In addition one poster observed "fun was had in amsterdam, the week before ripe, and opt-in saw some testing." I presume the fun referred to was review of the OPT-IN document. All comments made to the public list concerning the advancement of the draft have been favourable to the advancement of OPT-IN. It has been established that the specifications have been tested in server and resolver configurations. The remaining issue in that respect raised by Eric yesterday was the issue of testing the caching behavior. The posts describing the tests state that caching resolvers were tested. We do not however have a statement that the testing was at the thoroughness usually required when a specification advances to draft standard. There are two possible outstanding editorial issues concerning section 7 and section 3.1.1 but these are not rated as being significant enough to prevent progress of the document. So the question for the chairs is what do we do next? Phill -------------------- Detailed issues raised: On Mon, 3 Feb 2003, Paul Vixie wrote: dunno. but in any case i am strongly in favour of it, both because it softens the privacy-related impact of early dnssec deployment (walking a short nxt chain exposes less information than walking a full nxt chain would) and because of some obscure corner cases which have shown up in private workshops that are much easier to isolate and to think about in an opt-in world. Kosters: > Q: Is the description in the document of Opt-In complete ? Yes. We had one quibble with opt-in using wildcards. The current draft forbids the negative wildcard proof to be returned but the implementation=20 we used did return the negative wildcard proof (that is, an additional NXT=20 record was sent covering the non-existant wildcard). Perhaps the draft needs to be relaxed to allow for the proof to be sent since it seems to do no harm. > Q: Does this document satisfy people as being implement able and testable > specification ? WRT opt-in, we tested with two authoritative servers (ISC and VeriSign) and one opt-in aware recursive server (ISC). A mixture of delegations were tested (fully secure, opt-in, and insecure) and all worked. So, it looks to me like the specifications are clear. > Q: Are there implementations of opt-in and have there been any tests ? Yes. See above. We had a workshop Jan 21-23 @ RIPE and I understand the results are going to be posted soon. Some of the tests run are listed at http://www.verisignlabs.com/workshop/index.html. And, I guess it should be no surprise that I support the advancement of opt-in. Mark Ted Hardie At 01:17 PM 2/4/2003 -0500, =D3lafur Gudmundsson/DNSEXT co-chair wrote: >Q: Is the description in the document of Opt-In complete ? I'm not sure that section 3.1.1 (delegations only) is complete. Section 3.1.1 notes that servers and signers must enforce the restriction that only delegations may exist between the owner and "next" names of an Opt-In tagged NXT record. It was not obvious to me how to handle the error condition. If, for example, a caching resolver receives a request for some record, and gets an answer back that does not conform to 3.1.1, how should it indicate the error to the original requester? Was this one of the conditions tested in the recent set of tests? If so, how was this handled? I'm also not sure that section 7 adequately describes the risks inherent in how Opt-In interacts with NXDOMAIN. Though it makes the point that all unsigned names are at risk for insertion, modification, or deletion, it does not describe either the need for cryptographically assured denial of existence or the affect that Opt-In would have on the ability to provide it. Were others satisfied that this text handled the issue? regards, Ted Hardie Blacka: On Tuesday 04 February 2003 07:06 pm, Ted Hardie wrote: > I'm not sure that section 3.1.1 (delegations only) is complete. Section=20 3.1.1 > notes that servers and signers must enforce the restriction that only > delegations may exist between the owner and "next" names of an Opt-In > tagged NXT record. It was not obvious to me how to handle the error > condition. If, for example, a caching resolver receives a request for some > record, and gets an answer back that does not conform to 3.1.1, how > should it indicate the error to the original requester? Was this one > of the conditions tested in the recent set of tests? If so, how was this > handled? This actually was tested. Violations of any of the requirements of the spec=20 result in a validation error, which is reported as a SERVFAIL. When we=20 tested this against our resolver implementation, we got SERVFAIL. So it worked. At the moment, I can't put my finger on where the protocol behavior of a validation failure is defined, but it probably should not be defined in the=20 opt-in draft. Editorially, I can see adding language that make it clear that violations of 3.1.1 must be handed as a validation error, but I'm not=20 sure that it is necessary. What do others think? --=20 David Blacka =20 Sr. Engineer Verisign Applied Research Austein: Not to be difficult, but the resolver side of opt-in is the hard part. Is there a second iterative resolver implementation, and has it been through any interoperability testing? Not faulting anybody, just digging for whatever data we have. Richardson: I wonder if the final zone files, plus public and private keys from the opt-in workshop could be made available fot FTP somewhere? This would help others to duplicate this test environment in vitro, (via bind9's on multiple aliases, or via User-Mode-Linux, or even by getting X-many machines) to best understand the setup and configuration that was done.=20 ------=_NextPart_000_0014_01C2D358.D96A7290 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1 3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1 81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK +gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/ H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDIxMzE3 MTAwN1owIwYJKoZIhvcNAQkEMRYEFGfymr2axHUBfZfD0nsNvfYcrHj8MFgGCSqGSIb3DQEJDzFL MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO rwvJMA0GCSqGSIb3DQEBAQUABIGASIZOHZmOwj2yJBGVMI1ytMDfwVvVEXzxqOZ+KCCbbU35Snmd 364QkRtzsYOGKIvtSovxmdJaDOSAozgQBovKeHW5yumiuKU0RsZ0fZfDDdWCSesYQMO+VSPbkNP+ DExg0Hh83amaQ/wTY9E3TEPCQnXc0gCdBk78A0Qz6V/eqOAAAAAAAAA= ------=_NextPart_000_0014_01C2D358.D96A7290-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 13 12:59:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20241 for ; Thu, 13 Feb 2003 12:58:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jNaB-000HA5-00 for namedroppers-data@psg.com; Thu, 13 Feb 2003 09:55:35 -0800 Received: from one.elistx.com ([209.116.252.130]) by psg.com with esmtp (Exim 3.36 #1) id 18jNa7-000H9P-00 for namedroppers@ops.ietf.org; Thu, 13 Feb 2003 09:55:31 -0800 Received: from ogud.com (pcp816081pcs.nrockv01.md.comcast.net [68.49.60.118]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HA900IFIDT40V@eListX.com> for namedroppers@ops.ietf.org; Thu, 13 Feb 2003 12:55:52 -0500 (EST) Received: from ENGILL.ogud.com (mail.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.3/8.12.3) with ESMTP id h1DHrgts005585; Thu, 13 Feb 2003 12:53:42 -0500 (EST envelope-from ogud@ogud.com) Date: Thu, 13 Feb 2003 12:54:49 -0500 From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: Summary RE: DNSEXT WGLC: DNSSEC Opt-in In-reply-to: X-Sender: post@localhost To: "Hallam-Baker, Phillip" , Erik Nordmark Cc: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair , namedroppers@ops.ietf.org Message-id: <5.1.1.6.2.20030213125125.024e2e00@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=us-ascii X-Spam-Status: No, hits=4.1 required=5.0 tests=IN_REP_TO,OPT_IN,RCVD_IN_RFCI,SPAM_PHRASE_03_05 version=2.43 X-Spam-Level: **** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 12:10 2003-02-13, Hallam-Baker, Phillip wrote: >There were 27 messages in this thread from 10 distinct individuals. Thank you for your summary, I'm working on my own, but you are absolutely correct there was strong showing of support for technical description of OPT-in. Expect the follow up WGLC to start this week. 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. archive: From owner-namedroppers@ops.ietf.org Thu Feb 13 12:59:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20268 for ; Thu, 13 Feb 2003 12:59:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jNY1-000Gvn-00 for namedroppers-data@psg.com; Thu, 13 Feb 2003 09:53:21 -0800 Received: from numenor.qualcomm.com ([129.46.51.58]) by psg.com with esmtp (Exim 3.36 #1) id 18jNXy-000GvA-00 for namedroppers@ops.ietf.org; Thu, 13 Feb 2003 09:53:18 -0800 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.3/8.12.5/1.0) with ESMTP id h1DHr42d023528 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 13 Feb 2003 09:53:04 -0800 (PST) Received: from CAMITLOAN6.qualcomm.com (camitloan6.qualcomm.com [129.46.74.133]) by sabrina.qualcomm.com (8.12.3/8.12.5/1.0) with ESMTP id h1DHr1Qi000071; Thu, 13 Feb 2003 09:53:01 -0800 (PST) Message-Id: <5.1.0.14.2.20030213092741.00afc518@mage.qualcomm.com> X-Sender: hardie@mage.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 13 Feb 2003 09:45:08 -0800 To: "Hallam-Baker, Phillip" , "'Roy Arends'" , Erik Nordmark From: Ted Hardie Subject: Re: Summary RE: DNSEXT WGLC: DNSSEC Opt-in Cc: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair , namedroppers@ops.ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-Spam-Status: No, hits=0.7 required=5.0 tests=IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA20268 At 09:10 AM 2/13/2003 -0800, Hallam-Baker, Phillip wrote: >There were 27 messages in this thread from 10 distinct individuals. > >Olafur posed 3 questions as follows: > >Q: Is the description in the document of Opt-In complete ? > >Answers: > Kosters - Yes [detailed response] > Rose - I believe it is. > Loomis - I believe so. > Hardie - Raised issue with 3.1.1, possible issue with Section 7 > Blacka - Stated that issue raised by Hardie had been tested > Could add text to draft, not sure it is >necessary > Austein - It would be a good idea to mention the issue [3.1.1] > explictly, but it's not a showstopper. Note that David and Rob's reply dealt with the issues around section 3.1.1. I have seen no replies about the concern raised about section 7 (more explicit text on the interaction of opt-in and NXDOMAIN). I know Roy has done some pretty extensive thinking on it, but that is not yet in the draft. Others may disagree that it is needed, but no one said so explicitly. The workshop reports also indicated that the document didn't agree with implemented behavior in regards to NXT and needed to recommend against dynamic update; here's the text from the report: * specification issues - draft & implementation behavior WRT NXT is different, probably draft needs to change, on inclusion of negative wildcard proof in the answer (draft says MUST NOT, code does it, it's probably harmless, draft should say MAY) - insecure delegation with opt-in NXT is semantically ambiguous, useless, and doesn't work (SERVFAIL) - draft should mention dynamic update behavior. It should caution against dyanmic update with opt-in. There was also the discussion among Rob, Johann, and Michael about the need to rev NXT (and possibly SIG and KEY) to make the current infrastructure distinguishable from the previous infrastructure. I didn't say a resolution to this (though I may have missed it in a thread permutation). >All comments made to the public list concerning the advancement of the >draft have been favourable to the advancement of OPT-IN. There were comments, including in the workshop report, that recommend updates to the specification. There are two possible outstanding editorial issues concerning section 7 >and section 3.1.1 but these are not rated as being significant enough to >prevent progress of the document. Please add the dynamic update and NXT issues to this list. I'm most concerned, obviously, about the mismatch between tested implementations and the spec on the NXT issue. >So the question for the chairs is what do we do next? Speaking personally, I think the authors should rev the docs to fix these spec bugs. regards, Ted > Phill > >-------------------- > >Detailed issues raised: > >On Mon, 3 Feb 2003, Paul Vixie wrote: > > dunno. but in any case i am strongly in favour of it, both because it > softens the privacy-related impact of early dnssec deployment (walking > a short nxt chain exposes less information than walking a full nxt >chain > would) and because of some obscure corner cases which have shown up in > private workshops that are much easier to isolate and to think about in > an opt-in world. > >Kosters: > > > Q: Is the description in the document of Opt-In complete ? > >Yes. We had one quibble with opt-in using wildcards. The current draft >forbids the negative wildcard proof to be returned but the >implementation >we used did return the negative wildcard proof (that is, an additional >NXT >record was sent covering the non-existant wildcard). Perhaps the draft >needs to be relaxed to allow for the proof to be sent since it seems to >do no harm. > > > Q: Does this document satisfy people as being implement able and >testable > > specification ? > >WRT opt-in, we tested with two authoritative servers (ISC and VeriSign) >and >one opt-in aware recursive server (ISC). A mixture of delegations were >tested (fully secure, opt-in, and insecure) and all worked. So, it looks >to me like the specifications are clear. > > > Q: Are there implementations of opt-in and have there been any tests ? > >Yes. See above. We had a workshop Jan 21-23 @ RIPE and I understand the > >results are going to be posted soon. Some of the tests run are listed >at http://www.verisignlabs.com/workshop/index.html. > >And, I guess it should be no surprise that I support the advancement >of opt-in. > >Mark > > >Ted Hardie > >At 01:17 PM 2/4/2003 -0500, Ólafur Gudmundsson/DNSEXT co-chair wrote: > >Q: Is the description in the document of Opt-In complete ? > >I'm not sure that section 3.1.1 (delegations only) is complete. Section >3.1.1 >notes that servers and signers must enforce the restriction that only >delegations may exist between the owner and "next" names of an Opt-In >tagged NXT record. It was not obvious to me how to handle the error >condition. If, for example, a caching resolver receives a request for >some >record, and gets an answer back that does not conform to 3.1.1, how >should it indicate the error to the original requester? Was this one >of the conditions tested in the recent set of tests? If so, how was >this >handled? > >I'm also not sure that section 7 adequately describes the risks inherent >in >how Opt-In interacts with NXDOMAIN. Though it makes the point >that all unsigned names are at risk for insertion, modification, or >deletion, >it does not describe either the need for cryptographically assured >denial >of existence or the affect that Opt-In would have on the ability to >provide >it. Were others satisfied that this text handled the issue? > > regards, > Ted Hardie > >Blacka: > >On Tuesday 04 February 2003 07:06 pm, Ted Hardie wrote: > > > I'm not sure that section 3.1.1 (delegations only) is complete. >Section >3.1.1 > > notes that servers and signers must enforce the restriction that only > > delegations may exist between the owner and "next" names of an Opt-In > > tagged NXT record. It was not obvious to me how to handle the error > > condition. If, for example, a caching resolver receives a request for > >some > > record, and gets an answer back that does not conform to 3.1.1, how > > should it indicate the error to the original requester? Was this one > > of the conditions tested in the recent set of tests? If so, how was >this > > handled? > >This actually was tested. Violations of any of the requirements of the >spec >result in a validation error, which is reported as a SERVFAIL. When we >tested this against our resolver implementation, we got SERVFAIL. So it > >worked. > >At the moment, I can't put my finger on where the protocol behavior of a > >validation failure is defined, but it probably should not be defined in >the >opt-in draft. Editorially, I can see adding language that make it clear > >that violations of 3.1.1 must be handed as a validation error, but I'm >not >sure that it is necessary. What do others think? > >-- >David Blacka >Sr. Engineer Verisign Applied Research > > >Austein: > >Not to be difficult, but the resolver side of opt-in is the hard part. >Is there a second iterative resolver implementation, and has it been >through any interoperability testing? > >Not faulting anybody, just digging for whatever data we have. > > >Richardson: > > >I wonder if the final zone files, plus public and private keys from the >opt-in workshop could be made available fot FTP somewhere? > >This would help others to duplicate this test environment in vitro, >(via bind9's on multiple aliases, or via User-Mode-Linux, or even by >getting >X-many machines) to best understand the setup and configuration that was >done. > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 13 13:33:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21236 for ; Thu, 13 Feb 2003 13:33:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jO8W-000KDI-00 for namedroppers-data@psg.com; Thu, 13 Feb 2003 10:31:04 -0800 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.36 #1) id 18jO8S-000KCe-00 for namedroppers@ops.ietf.org; Thu, 13 Feb 2003 10:31:00 -0800 Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id h1DIUhU08426; Thu, 13 Feb 2003 10:30:43 -0800 (PST) From: Bill Manning Message-Id: <200302131830.h1DIUhU08426@boreas.isi.edu> Subject: Re: Q2: crypto algorithm requirements for DNSSEC In-Reply-To: from Jakob Schlyter at "Feb 13, 3 02:22:45 pm" To: jakob@crt.se (Jakob Schlyter) Date: Thu, 13 Feb 2003 10:30:43 -0800 (PST) Cc: miekg@atoom.net, Jim.Reid@nominum.com, scottr@nist.gov, namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % On Thu, 13 Feb 2003, Miek Gieben wrote: % % > > I wouldn't consider the resources used for signing a problem with modern % > > hardware - people sign .com with their desktop machine within reasonable % > > time. % > % > so you're asking a TLD to carry twice the load for an event which is unlikely % > to happen soon? % % yes, if we come to the conclusion that we should use two algorithms. % % > And further more, we (.nl), have to explain to every domain holder in % > .nl that signing with 2 algorithms is better than signing with 1. % % if we cannot explain why to normal people, I'm not sure we should do two % algorithms. % % % jakob back in the mists of time, we actually tested signed heirarchies with two algorithms. There were interesting results when trying to do validation. as I remember, the results strengthened the argument for a single algorithm. resolver code may have become more robust since then and the point may be moot. --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 13 13:33:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21269 for ; Thu, 13 Feb 2003 13:33:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jO84-000K93-00 for namedroppers-data@psg.com; Thu, 13 Feb 2003 10:30:36 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 18jO81-000K83-00 for namedroppers@ops.ietf.org; Thu, 13 Feb 2003 10:30:33 -0800 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id A4A90137F05; Thu, 13 Feb 2003 10:30:30 -0800 (PST) Date: Thu, 13 Feb 2003 10:30:29 -0800 Subject: Re: Summary RE: DNSEXT WGLC: DNSSEC Opt-in Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "'Roy Arends'" , Erik Nordmark , =?ISO-8859-1?Q?=D3lafur_Gudmundsson/DNSEXT_co-chair?= , namedroppers@ops.ietf.org To: "Hallam-Baker, Phillip" From: David Conrad In-Reply-To: Message-Id: <3A4D137C-3F81-11D7-B108-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-1.1 required=5.0 tests=IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, On Thursday, February 13, 2003, at 09:10 AM, Hallam-Baker, Phillip wrote: > Q: Is the description in the document of Opt-In complete ? It would likely be the first RFC in the history of the IETF if it were... :-) > Q: Are there implementations of opt-in and have there been any tests ? > Nordmark - Does this mean that there is a caching resolver > implementation that has been tested? To be clear: Nominum has a delegation only opt-in validator implementation in our proprietary caching server. The same person who wrote the opt-in validator for our prorietary server (Brian Wellington) also wrote a delegation only opt-in validator for BINDv9, but I'm not sure if that code has been incorporated into BIND. Has anyone else written a validator that supports opt-in? > Conrad - To be perfectly honest, I no longer care Out of context. I do care that a decision is made, I just no longer care what that decision is. Rgds, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 13 14:15:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22528 for ; Thu, 13 Feb 2003 14:15:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jOkN-000NlS-00 for namedroppers-data@psg.com; Thu, 13 Feb 2003 11:10:11 -0800 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 18jOkL-000Nkn-00 for namedroppers@ops.ietf.org; Thu, 13 Feb 2003 11:10:09 -0800 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.6/8.12.6/Debian-7) with ESMTP id h1DJA3Pr008096 for ; Thu, 13 Feb 2003 20:10:04 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.6/8.12.6/Debian-7) with ESMTP id h1DJA3cl008093 for ; Thu, 13 Feb 2003 20:10:03 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Thu, 13 Feb 2003 20:10:03 +0100 (CET) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: namedroppers@ops.ietf.org Subject: Q-5: DNS Security Algorithm Number 252 to reserved ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-0.3 required=5.0 tests=SPAM_PHRASE_01_02,USER_AGENT_PINE,X_AUTH_WARNING version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Q: Can we move KEY Algorithm Number 252 status "reserved for indirect keys" to "reserved" ? Some background: RFC2535 says : 3.2 The KEY Algorithm Number Specification VALUE Algorithm 252 reserved for indirect keys Algorithm number 252 indicates an indirect key format where the actual key material is elsewhere. This format is to be defined in a separate document. Input for discussion: In the years between RFC 2535 and this message, no specification of indirect keys have matured to standards track. The intended usage of indirect keys was for appliction keys. RFC 3445 limited the KEY record to DNSSEC keys only. Should Algorithm number 252 remain "reserved for indirect keys", or should the revised specs move it to "reserved" ? Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 13 14:31:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22987 for ; Thu, 13 Feb 2003 14:31:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jP0t-000PB4-00 for namedroppers-data@psg.com; Thu, 13 Feb 2003 11:27:15 -0800 Received: from thing.verisignlabs.com ([65.201.175.62] helo=cliffie.verisignlabs.com) by psg.com with esmtp (Exim 3.36 #1) id 18jP0q-000PAk-00 for namedroppers@ops.ietf.org; Thu, 13 Feb 2003 11:27:12 -0800 Received: from pinion.admin.cto.netsol.com (h87.s239.netsol.com [216.168.239.87]) (AUTH: LOGIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by cliffie.verisignlabs.com with esmtp; Thu, 13 Feb 2003 14:27:11 -0500 From: David Blacka Organization: Verisign, Inc. To: Ted Hardie , namedroppers@ops.ietf.org Subject: Re: Summary RE: DNSEXT WGLC: DNSSEC Opt-in Date: Thu, 13 Feb 2003 14:27:10 -0500 User-Agent: KMail/1.5 References: <5.1.0.14.2.20030213092741.00afc518@mage.qualcomm.com> In-Reply-To: <5.1.0.14.2.20030213092741.00afc518@mage.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200302131427.10269.davidb@verisignlabs.com> X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC,OPT_IN, QUOTED_EMAIL_TEXT,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thursday 13 February 2003 12:45 pm, Ted Hardie wrote: > Note that David and Rob's reply dealt with the issues around section > 3.1.1. I have seen no replies about the concern raised about > section 7 (more explicit text on the interaction of opt-in and > NXDOMAIN). I know Roy has done some pretty extensive thinking on > it, but that is not yet in the draft. Others may disagree that it > is needed, but no one said so explicitly. I haven't forgotten your concern, Ted. I haven't commented on it yet because I haven't thought about it enough. > The workshop reports also indicated that the document didn't agree > with implemented behavior in regards to NXT and needed to recommend > against dynamic update; Yes, I am aware of these issues as well. I apologize for not having posted an open issues list to namedroppers by now (see the end of this message, however, for one). At this point, however, I do not believe recommending against dynamic update with Opt-In is correct. I don't think there is a real conflict between them. But dynamic update should be mentioned in the draft. > There was also the discussion among Rob, Johann, and Michael about > the need to rev NXT (and possibly SIG and KEY) to make the current > infrastructure distinguishable from the previous infrastructure. I > didn't say a resolution to this (though I may have missed it in a > thread permutation). This issue is totally orthogonal to Opt-In. I think you haven't seen a resolution to this issue because there hasn't been one. > There are two possible outstanding editorial issues concerning > section 7 >and section 3.1.1 but these are not rated as being > significant enough to >prevent progress of the document. Please add > the dynamic update and NXT issues to this list. I'm most concerned, > obviously, about the mismatch between tested implementations and the > spec on the NXT issue. The workshop summary was somewhat unclear on the NXT issue. It is far from a major one. Essentially the draft forbids sending the negative wildcard proof NXT when sending an NXDOMAIN response. We had two server implementations for opt-in: one which sent the negative wildcard proof and one that didn't. Both worked. So the draft is using a MUST when it should be using either SHOULD or MAY. This was actually suggested by Ed Lewis before the publication of the -04 version but got missed somehow. > >So the question for the chairs is what do we do next? > > Speaking personally, I think the authors should rev the docs to fix these > spec bugs. I, as one of the authors, agree. I believe that the other authors (Mark and Roy) also agree. To summarize the "spec bug" issues list that I am aware of: * change the MUST NOT send negative wildcard proof to a SHOULD NOT or MAY NOT (or some other language that means the same thing). * Clarify opt-in behavior wrt dynamic update. (although I'm not sure what the clarification should say). * In section 3.1.1, make it clear that a violation results in a validation error. * Various additional warnings and comments to be placed in the Security Considerations section. This includes: o something about NXDOMAIN (although I'm not sure what needs to be said about this). o some additional description of domain hijacking possibilities (asked by Paul Vixie during the Atlanta dnsext meeting). From the minutes: There was a comment that security section needs stronger language, Clearly list the need for zone transfer protection and risk from zone hijacking of opt-outed delegations. Authors agreed examine if the current text is insufficient . Anything else? I'd like to point out that none of these proposed changes should affect existing implementations in any way. -- David Blacka Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 13 15:12:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25055 for ; Thu, 13 Feb 2003 15:12:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jPau-00023E-00 for namedroppers-data@psg.com; Thu, 13 Feb 2003 12:04:28 -0800 Received: from pigeon.verisign.com ([65.205.251.71]) by psg.com with esmtp (Exim 3.36 #1) id 18jPaq-00022j-00 for namedroppers@ops.ietf.org; Thu, 13 Feb 2003 12:04:24 -0800 Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53] (may be forged)) by pigeon.verisign.com (8.12.1/) with ESMTP id h1DK2Piq022852; Thu, 13 Feb 2003 12:02:25 -0800 (PST) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id <15SCJW80>; Thu, 13 Feb 2003 12:04:23 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'David Blacka'" , Ted Hardie , namedroppers@ops.ietf.org Subject: RE: Summary RE: DNSEXT WGLC: DNSSEC Opt-in Date: Thu, 13 Feb 2003 12:04:22 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_0066_01C2D371.2B0A0F80"; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=2.9 required=5.0 tests=EXCHANGE_SERVER,MAY_BE_FORGED,MISSING_OUTLOOK_NAME,OPT_IN, QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01,TO_BE_REMOVED_REPLY version=2.43 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0066_01C2D371.2B0A0F80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Unfortunately Olafur's process did not set out the procedure for dealing with any changes to the draft. Setting asside step 3 which we can anticipate meeting Hobbes' description of the life of a man in a state of nature, how do we proceed with the document in the meantime? If as appears to be the case these are all editorial issues that can be dealt with in the normal post-last call process, should we wait for an updated draft before going into last call or consider the period prior to Feb 12th as being a preamble to last call and deal with all the issues at once? Since the Feb 12th date was not described as a last call are we now required to repeat the last call and then comment in that period again or do the comments already made count for that purpose? Or considering that no objections were raised in last call and only minor editorial issues with the document were raised in the Feb 12th period do we simply resolve the outstanding issues and go ahead with submission to the IESG? Phill > -----Original Message----- > From: David Blacka [mailto:davidb@verisignlabs.com] > Sent: Thursday, February 13, 2003 2:27 PM > To: Ted Hardie; namedroppers@ops.ietf.org > Subject: Re: Summary RE: DNSEXT WGLC: DNSSEC Opt-in > > > On Thursday 13 February 2003 12:45 pm, Ted Hardie wrote: > > > Note that David and Rob's reply dealt with the issues around section > > 3.1.1. I have seen no replies about the concern raised about > > section 7 (more explicit text on the interaction of opt-in and > > NXDOMAIN). I know Roy has done some pretty extensive thinking on > > it, but that is not yet in the draft. Others may disagree that it > > is needed, but no one said so explicitly. > > I haven't forgotten your concern, Ted. I haven't commented on it yet > because I haven't thought about it enough. > > > The workshop reports also indicated that the document didn't agree > > with implemented behavior in regards to NXT and needed to recommend > > against dynamic update; > > Yes, I am aware of these issues as well. I apologize for not having > posted an open issues list to namedroppers by now (see the end of this > message, however, for one). > > At this point, however, I do not believe recommending against dynamic > update with Opt-In is correct. I don't think there is a real conflict > between them. But dynamic update should be mentioned in the draft. > > > There was also the discussion among Rob, Johann, and Michael about > > the need to rev NXT (and possibly SIG and KEY) to make the current > > infrastructure distinguishable from the previous infrastructure. I > > didn't say a resolution to this (though I may have missed it in a > > thread permutation). > > This issue is totally orthogonal to Opt-In. I think you haven't seen > a resolution to this issue because there hasn't been one. > > > There are two possible outstanding editorial issues concerning > > section 7 >and section 3.1.1 but these are not rated as being > > significant enough to >prevent progress of the document. Please add > > the dynamic update and NXT issues to this list. I'm most concerned, > > obviously, about the mismatch between tested implementations and the > > spec on the NXT issue. > > The workshop summary was somewhat unclear on the NXT issue. It is far > from a major one. Essentially the draft forbids sending the negative > wildcard proof NXT when sending an NXDOMAIN response. We had two > server implementations for opt-in: one which sent the negative > wildcard proof and one that didn't. Both worked. So the draft is > using a MUST when it should be using either SHOULD or MAY. This was > actually suggested by Ed Lewis before the publication of the -04 > version but got missed somehow. > > > >So the question for the chairs is what do we do next? > > > > Speaking personally, I think the authors should rev the > docs to fix these > > spec bugs. > > I, as one of the authors, agree. I believe that the other authors > (Mark and Roy) also agree. > > To summarize the "spec bug" issues list that I am aware of: > > * change the MUST NOT send negative wildcard proof to a SHOULD NOT > or MAY NOT (or some other language that means the same thing). > > * Clarify opt-in behavior wrt dynamic update. (although I'm not > sure what the clarification should say). > > * In section 3.1.1, make it clear that a violation results in a > validation error. > > * Various additional warnings and comments to be placed in the > Security Considerations section. This includes: > > o something about NXDOMAIN (although I'm not sure what needs to be > said about this). > > o some additional description of domain hijacking possibilities > (asked by Paul Vixie during the Atlanta dnsext meeting). From > the minutes: > > There was a comment that security section needs stronger > language, Clearly list the need for zone transfer protection and > risk from zone hijacking of opt-outed delegations. Authors > agreed examine if the current text is insufficient . > > Anything else? > > I'd like to point out that none of these proposed changes should > affect existing implementations in any way. > -- > David Blacka > Sr. Engineer Verisign Applied Research > > > -- > to unsubscribe send a message to > namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > ------=_NextPart_000_0066_01C2D371.2B0A0F80 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1 3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1 81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK +gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/ H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDIxMzIw MDQxMlowIwYJKoZIhvcNAQkEMRYEFNzMwMh/ShXCpp8oYz0blXLv1uu2MFgGCSqGSIb3DQEJDzFL MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO rwvJMA0GCSqGSIb3DQEBAQUABIGARFW7gXYwFQiU5PB4WaijKDbbscxw6x+GObF4LFDg9ERfp3af y5IjfDX8AprBqXodPljyxa0NjTByVDxhdCcc3g9km3X3j+0utIq2hYKGQrlFpIm1YO7uOqtRyctN 7d8SIeghaDvfX/e48xHFeQ23O7Fc09rZVxMiN4WzVvfKcQkAAAAAAAA= ------=_NextPart_000_0066_01C2D371.2B0A0F80-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 13 16:06:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00120 for ; Thu, 13 Feb 2003 16:06:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jQTI-0007Gc-00 for namedroppers-data@psg.com; Thu, 13 Feb 2003 13:00:40 -0800 Received: from [2001:4f8:3:bb:2e0:81ff:fe23:7b5a] (helo=as.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 18jQTG-0007E9-00 for namedroppers@ops.ietf.org; Thu, 13 Feb 2003 13:00:38 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 0BF23379E40 for ; Thu, 13 Feb 2003 21:00:25 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Q2: crypto algorithm requirements for DNSSEC In-Reply-To: Message from Jakob Schlyter of "Thu, 13 Feb 2003 13:09:25 +0100." X-Mailer: MH-E 7.2; nmh 1.0.4; GNU Emacs 21.2.1 Date: Thu, 13 Feb 2003 21:00:25 +0000 Message-Id: <20030213210025.0BF23379E40@as.vix.com> X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I wouldn't consider the resources used for signing a problem with modern > hardware - people sign .com with their desktop machine within reasonable > time. s/desktop/laptop/, but otherwise agreed. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 13 16:40:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06330 for ; Thu, 13 Feb 2003 16:40:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jR1J-000AnW-00 for namedroppers-data@psg.com; Thu, 13 Feb 2003 13:35:49 -0800 Received: from [2001:470:1f00:ffff::5a1] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 18jR1H-000AkV-00 for namedroppers@ops.ietf.org; Thu, 13 Feb 2003 13:35:47 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h1DLYYd6020372; Fri, 14 Feb 2003 08:34:35 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200302132134.h1DLYYd6020372@drugs.dv.isc.org> To: Jim Reid Cc: Jakob Schlyter , Miek Gieben , Scott Rose , namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: Q2: crypto algorithm requirements for DNSSEC In-reply-to: Your message of "Thu, 13 Feb 2003 04:03:02 -0800." <31581.1045137782@shell.nominum.com> Date: Fri, 14 Feb 2003 08:34:34 +1100 X-Spam-Status: No, hits=0.5 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > signing and verifying => making deployment more straightforward. And > ISTR from cryptography 101 class that it's usually not a good idea to > encrypt or sign the same stuff with different keys or algorithms. Encrypting things multiple times is a problem. Signing the same known plain text isn't. -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 13 17:40:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15039 for ; Thu, 13 Feb 2003 17:40:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jRuU-000FWx-00 for namedroppers-data@psg.com; Thu, 13 Feb 2003 14:32:50 -0800 Received: from [2001:470:1f00:ffff::5a1] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 18jRuR-000FSn-00 for namedroppers@ops.ietf.org; Thu, 13 Feb 2003 14:32:48 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h1DMWFd6020543; Fri, 14 Feb 2003 09:32:15 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200302132232.h1DMWFd6020543@drugs.dv.isc.org> To: Erik Nordmark Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: DNSEXT WGLC Summary: RFC1886bis-01 In-reply-to: Your message of "Thu, 13 Feb 2003 13:56:44 BST." Date: Fri, 14 Feb 2003 09:32:15 +1100 X-Spam-Status: No, hits=0.9 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, TO_BE_REMOVED_REPLY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > > The DNSEXT working group has concluded a last call on this document > > and there is consensus on requesting it be advanced as Draft Standard. > > I've looked it over. > > The interoperability report identifies some RR types for which AAA > additional section processing makes sense that are > not explicitly specified in the draft: > * CNAME records (not mentioned in RFC1886) CNAME records do not cause additional section processing. > * PTR records (mentioned in RFC1886, but not explicitly) PTR records do not cause additional section processing. > * SRV records (not mentioned in RFC1886) SRV records do have additional section processing involving address records. > * SOA records (not mentioned in RFC1886) SOA records cause KEY record additional section processing. They do not cause address records to be added despite what Microsoft does. > > Wouldn't it make sense to add explicit mention of those types to section 3 > (right now the section says for example NS and MX). > > > Normative References > > For this document to become a draft standard all normative references need to > be draft standard or higher. > > > [4] Gilligan, R., and E. Nordmark, "Transition Mechanisms for IPv6 > > Hosts and Routers", RFC 2893, FreeGate Corp., Sun Microsystems > > Inc., August 2000. > > This RFC is being updated. The current draft is > > "draft-ietf-ngtrans-mech-v2-00.txt", Gilligan, R., and > > E. Nordmark, July 17, 2002 > > Is this really a normative reference i.e. something that one needs to > read and understand in order to implement RFC1886bis? > > Also, [5] through [8] seems like informative references. > (But [3] is normative for the textual representation.) > > 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. > archive: -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 13 17:56:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16805 for ; Thu, 13 Feb 2003 17:56:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jSA8-000HA8-00 for namedroppers-data@psg.com; Thu, 13 Feb 2003 14:49:00 -0800 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 18jSA5-000H9j-00 for namedroppers@ops.ietf.org; Thu, 13 Feb 2003 14:48:57 -0800 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id RAA02653; Thu, 13 Feb 2003 17:48:40 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA15446; Thu, 13 Feb 2003 17:48:34 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id RAA01723; Thu, 13 Feb 2003 17:48:27 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id RAA06854; Thu, 13 Feb 2003 17:48:27 -0500 (EST) To: Mark.Andrews@isc.org Cc: Jim Reid , Jakob Schlyter , Miek Gieben , Scott Rose , namedroppers@ops.ietf.org From: Derek Atkins Subject: Re: Q2: crypto algorithm requirements for DNSSEC References: <200302132134.h1DLYYd6020372@drugs.dv.isc.org> Date: 13 Feb 2003 17:48:27 -0500 In-Reply-To: <200302132134.h1DLYYd6020372@drugs.dv.isc.org> Message-ID: Lines: 28 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-1.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,RCVD_IN_RELAYS_ORDB_ORG,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_GNUS_UA,X_OSIRU_OPEN_RELAY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mark.Andrews@isc.org writes: > > signing and verifying => making deployment more straightforward. And > > ISTR from cryptography 101 class that it's usually not a good idea to > > encrypt or sign the same stuff with different keys or algorithms. > > Encrypting things multiple times is a problem. > Signing the same known plain text isn't. Sure it is -- how do yo know what to do if: 1) you only have something signed using one algorithm 2) data is signed with multiple algorithms but one sig fails 3) data is signed with multiple algorithms but only one sig succeeds There is a LOT of extra policy decision that needs to happen if you go down this road. A lot of extra implementation, too! > Mark Andrews, Internet Software Consortium > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.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. archive: From owner-namedroppers@ops.ietf.org Thu Feb 13 18:00:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17338 for ; Thu, 13 Feb 2003 18:00:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jSFI-000Hj9-00 for namedroppers-data@psg.com; Thu, 13 Feb 2003 14:54:20 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 18jSFE-000Hiw-00 for namedroppers@ops.ietf.org; Thu, 13 Feb 2003 14:54:16 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com) by rip.psg.com with esmtp (Exim 4.12) id 18jSFD-0006Wz-00; Thu, 13 Feb 2003 14:54:16 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 13 Feb 2003 14:54:15 -0800 To: "Hallam-Baker, Phillip" Cc: namedroppers@ops.ietf.org Subject: RE: Summary RE: DNSEXT WGLC: DNSSEC Opt-in References: Message-Id: X-Spam-Status: No, hits=1.0 required=5.0 tests=OPT_IN,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > If as appears to be the case these are all editorial issues that can > be dealt with in the normal post-last call process, should we wait for > an updated draft before going into last call or consider the period > prior to Feb 12th as being a preamble to last call and deal with all > the issues at once? as usual, we will wait for a draft that is as good as we know 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. archive: From owner-namedroppers@ops.ietf.org Thu Feb 13 18:27:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19713 for ; Thu, 13 Feb 2003 18:27:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jSgj-000KKh-00 for namedroppers-data@psg.com; Thu, 13 Feb 2003 15:22:41 -0800 Received: from [2001:470:1f00:ffff::5a1] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 18jSgg-000KHu-00 for namedroppers@ops.ietf.org; Thu, 13 Feb 2003 15:22:39 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h1DNL7d6021114; Fri, 14 Feb 2003 10:21:07 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200302132321.h1DNL7d6021114@drugs.dv.isc.org> To: Derek Atkins Cc: Mark_Andrews@isc.org, Jim Reid , Jakob Schlyter , Miek Gieben , Scott Rose , namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: Q2: crypto algorithm requirements for DNSSEC In-reply-to: Your message of "13 Feb 2003 17:48:27 CDT." Date: Fri, 14 Feb 2003 10:21:07 +1100 X-Spam-Status: No, hits=0.8 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Mark.Andrews@isc.org writes: > > > > signing and verifying => making deployment more straightforward. And > > > ISTR from cryptography 101 class that it's usually not a good idea to > > > encrypt or sign the same stuff with different keys or algorithms. > > > > Encrypting things multiple times is a problem. > > Signing the same known plain text isn't. > > Sure it is -- how do yo know what to do if: > > 1) you only have something signed using one algorithm > 2) data is signed with multiple algorithms but one sig fails > 3) data is signed with multiple algorithms but only one sig succeeds > > There is a LOT of extra policy decision that needs to happen if you go > down this road. A lot of extra implementation, too! You are missing the whole point. Encrypting the same plain text with multiple algorithms can result in one algorithm canceling out the other algorithm and allowing some/all of the original plain text to be revealed. This is not a issue when signing known plain text. From a cryptographic standpoint there is nothing wrong with signing the same thing with multiple algorithms. You do need a policy (which DNSSEC has) for dealing with the case where not all signatures verify. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 13 18:32:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19785 for ; Thu, 13 Feb 2003 18:32:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jSlu-000KdT-00 for namedroppers-data@psg.com; Thu, 13 Feb 2003 15:28:02 -0800 Received: from thing.verisignlabs.com ([65.201.175.62] helo=cliffie.verisignlabs.com) by psg.com with esmtp (Exim 3.36 #1) id 18jSls-000Kd8-00 for namedroppers@ops.ietf.org; Thu, 13 Feb 2003 15:28:00 -0800 Received: from pinion.admin.cto.netsol.com (h87.s239.netsol.com [216.168.239.87]) (AUTH: LOGIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by cliffie.verisignlabs.com with esmtp; Thu, 13 Feb 2003 18:27:59 -0500 From: David Blacka Organization: Verisign, Inc. To: namedroppers@ops.ietf.org Subject: DNSSEC Opt-In Q: unsigned delegations with opt-in NXTs? Date: Thu, 13 Feb 2003 18:27:58 -0500 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200302131827.58552.davidb@verisignlabs.com> X-Spam-Status: No, hits=1.3 required=5.0 tests=NOSPAM_INC,OPT_IN,SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01, USER_AGENT version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit There was a pretty important clarification that came up during the last workshop that I forgot to put in my list of TODOs for the Opt-In draft, and it leads to a question for the working group. Q: Should an Opt-In tagged NXT record be able to have the same name as an unsigned delegation? That is, can you have a zone fragment that looks like this: a.example IN A 1.1.1.1 IN SIG (A) ... IN NXT b.example A SIG (opt-in) IN SIG (NXT) ... b.example IN NS ns.example IN NXT c.example NS SIG (opt-in) c.example IN NS ns2.example IN DS .... IN SIG (DS) ... IN NXT ... NS DS SIG (opt-in) IN SIG (NXT) ... This case is not addressed at all in the draft, and can lead to interoperability problems. Some reasons why (explictly) allowing this case might be a good thing: * There seems to be no protocol reason why this would not be OK. * Some folks might like to have "proof of existence" available in the opt-in zone without having to secure their zone, for whatever reason. Some reasons why disallowing this might be good: * This state offers no real security benefit: any attack that could be accomplished before against the delegation name are still possible via slightly different attack technique. * This may complicate implementations and analysis, although I think that this is unlikely. At this moment, I personally feel that this case should be allowed, but I don't feel very strongly about it. -- David Blacka Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 13 19:15:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23785 for ; Thu, 13 Feb 2003 19:15:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jTHQ-000MZm-00 for namedroppers-data@psg.com; Thu, 13 Feb 2003 16:00:36 -0800 Received: from [2001:470:1f00:ffff::5a1] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 18jTHN-000MXq-00 for namedroppers@ops.ietf.org; Thu, 13 Feb 2003 16:00:33 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h1E001d6021308; Fri, 14 Feb 2003 11:00:01 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200302140000.h1E001d6021308@drugs.dv.isc.org> To: David Blacka Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: DNSSEC Opt-In Q: unsigned delegations with opt-in NXTs? In-reply-to: Your message of "Thu, 13 Feb 2003 18:27:58 CDT." <200302131827.58552.davidb@verisignlabs.com> Date: Fri, 14 Feb 2003 11:00:01 +1100 X-Spam-Status: No, hits=2.4 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,OPT_IN,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,TO_BE_REMOVED_REPLY version=2.43 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > There was a pretty important clarification that came up during the > last workshop that I forgot to put in my list of TODOs for the Opt-In > draft, and it leads to a question for the working group. > > Q: Should an Opt-In tagged NXT record be able to have the same name as > an unsigned delegation? Yes. Nothing in optin should preclude a standard insecure delegation. > That is, can you have a zone fragment that looks like this: > > a.example IN A 1.1.1.1 > IN SIG (A) ... > IN NXT b.example A SIG (opt-in) > IN SIG (NXT) ... > b.example IN NS ns.example > IN NXT c.example NS SIG (opt-in) > c.example IN NS ns2.example > IN DS .... > IN SIG (DS) ... > IN NXT ... NS DS SIG (opt-in) > IN SIG (NXT) ... > > This case is not addressed at all in the draft, and can lead to > interoperability problems. > > Some reasons why (explictly) allowing this case might be a good thing: > > * There seems to be no protocol reason why this would not be OK. > > * Some folks might like to have "proof of existence" available in the > opt-in zone without having to secure their zone, for whatever > reason. > > Some reasons why disallowing this might be good: > > * This state offers no real security benefit: any attack that could be > accomplished before against the delegation name are still possible > via slightly different attack technique. > > * This may complicate implementations and analysis, although I think > that this is unlikely. > > At this moment, I personally feel that this case should be allowed, > but I don't feel very strongly about it. > > -- > David Blacka > Sr. Engineer Verisign Applied Research > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 13 21:08:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26271 for ; Thu, 13 Feb 2003 21:08:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jV6F-0003de-00 for namedroppers-data@psg.com; Thu, 13 Feb 2003 17:57:11 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 18jV6E-0003dR-00 for namedroppers@ops.ietf.org; Thu, 13 Feb 2003 17:57:10 -0800 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 3B4A8137F05; Thu, 13 Feb 2003 17:57:09 -0800 (PST) Date: Thu, 13 Feb 2003 17:57:08 -0800 Subject: Re: Summary RE: DNSEXT WGLC: DNSSEC Opt-in Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Hallam-Baker, Phillip" , "'Roy Arends'" , Erik Nordmark , =?ISO-8859-1?Q?=D3lafur_Gudmundsson/DNSEXT_co-chair?= , namedroppers@ops.ietf.org To: David Conrad From: David Conrad In-Reply-To: <3A4D137C-3F81-11D7-B108-000393DB42B2@nominum.com> Message-Id: <9FF3CCB2-3FBF-11D7-B108-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=0.1 required=5.0 tests=FROM_AND_TO_SAME_2,IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Sigh. So I said: On Thursday, February 13, 2003, at 10:30 AM, David Conrad wrote: > Nominum has a delegation only opt-in validator implementation in our > proprietary caching server. Turns out, I lied. The only implementation of an opt-in validator I'm aware of is the one Brian did for BINDv9. Oops. However, the question still stands: > Has anyone else written a validator that supports opt-in? Rgds, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 13 22:48:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28743 for ; Thu, 13 Feb 2003 22:48:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jWeN-0008aP-00 for namedroppers-data@psg.com; Thu, 13 Feb 2003 19:36:31 -0800 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 18jWeH-0008ZI-00 for namedroppers@ops.ietf.org; Thu, 13 Feb 2003 19:36:25 -0800 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1E3aHq10848 for ; Fri, 14 Feb 2003 10:36:17 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1E3Zpb09189 for ; Fri, 14 Feb 2003 10:35:56 +0700 (ICT) From: Robert Elz To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC Summary: RFC1886bis-01 In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Feb 2003 10:35:51 +0700 Message-ID: <9187.1045193751@munnari.OZ.AU> X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Thu, 13 Feb 2003 13:56:44 +0100 (CET) From: Erik Nordmark Message-ID: | The interoperability report identifies some RR types for which AAA | additional section processing makes sense that are | not explicitly specified in the draft: The implementation report is nonsense, and really needs to be fixed. | * CNAME records (not mentioned in RFC1886) There is (never) any additional section processing for CNAME records. What the report should be saying, and what I assume was tested, is that when an AAAA lookup is done, and the name looked up turns out to be an alias (own a CNAME RR), then the RDATA of that RR needs to be looked up for the AAAA, and the result returned (in the ANSWER not additional section). | * PTR records (mentioned in RFC1886, but not explicitly) There is no additional section processing for PTR records. The only relevance of PTR at all for 1886 (1886 bis) is for its use in IP6.{ARPA,INT} lookups. | * SRV records (not mentioned in RFC1886) Additional section processing is not required for SRV. It can be done however (it isn't prohibited), testing whether or not it is done for AAAA I suppose makes some sense, but isn't important for the interop report. | * SOA records (not mentioned in RFC1886) There is no additional section processing for SOA records. I can't even imagine why they're mentioned in the interop report. | Wouldn't it make sense to add explicit mention of those types to section 3 | (right now the section says for example NS and MX). No, that would merely add confusion. NS and MX are the only RR types where address record additional section processing is important (though some would say that NS is the only one where it really matters at all). What is needed here (for this part, your point on normative references is good, and that should be fixed in the draft) isn't any changes to the draft, but a rational implementation report, which documents that what was required to be tested was tested, and omits all the extraneous noise. The draft contains just 4 things that I can see AAAA records - they should be tested for lookups (testing lookup indirectly via a CNAME probably makes sense too - but this is testing CNAME is correctly processed, which has nothing much to do with AAAA specfically). AAAA record textual format - the various forms of representing AAAA records should all be tested (with and without ::, with and without the trailing IPv4 format dotted quad at the end, etc) and documented to have been tested, using the same RR's (exactly) in more than one server. PTR lookups in IP6.ARPA Additional section processing of AAAA records for NS MX (and, I suppose, MB, the only other 1035 RR still alive which requires this - though "alive" when talking about MB is stretching credulity a little). The test should be documenting that the 3 cases of interest work correctly - a lookup where there is only an AAAA record for the name in the RDATA, a lookup where there are both A and AAAA (the server is required to return both) and a lookup where there is only an A (the server better not be broken by including AAAA support so that it no longer returns the A record). All that needs documenting. Nothing more than that is required (though extraneoous info in the implementation report shouldn't block progress of the document - even if the extraneous information is bogus - it can claim that all milk extracted from 17 pink cows tested was green if it wants to...) 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. archive: From owner-namedroppers@ops.ietf.org Fri Feb 14 05:41:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15739 for ; Fri, 14 Feb 2003 05:41:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jd8Z-0002e7-00 for namedroppers-data@psg.com; Fri, 14 Feb 2003 02:32:07 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #1) id 18jd8X-0002dv-00 for namedroppers@ops.ietf.org; Fri, 14 Feb 2003 02:32:05 -0800 Received: (qmail 71053 invoked by uid 1016); 14 Feb 2003 10:32:28 -0000 Date: 14 Feb 2003 10:32:28 -0000 Message-ID: <20030214103228.71052.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: axfr-clarify's fraudulent claims of consensus References: <200302101659.LAA15654@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=0.3 required=5.0 tests=REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This ``clarification'' document prohibits several perfectly legitimate, very widely deployed, AXFR implementation techniques. See my web page http://cr.yp.to/djbdns/axfr-clarify.html for details. In particular, this document violates RFC 2119, section 6, in five separate ways. At least seven people have gone on record as objecting to axfr-clarify: Dean Anderson, Len Budney, Felix von Leitner, Kenji Rikitake, Aaron Swartz, Sam Trenholme (MaraDNS implementor), and me (djbdns implementor). Furthermore, the Yokohama minutes report a WG decision that axfr-clarify is ``too bind specific''---too specific to BIND 9, to be precise. Despite this decision and these extensive objections, the WG chairs declared ``consensus'' for axfr-clarify and sent it to the IESG. Those claims of consensus were clearly fraudulent: there was no WG discussion of axfr-clarify in the interim! Subsequent discussions did not resolve any of the objections. A review of all of the axfr-clarify discussions in the WG list archive shows that this document is being pushed primarily by people who have been paid for BIND work: Mark Andrews, Roy Arends, David Conrad, Danny Mayer, Jim Reid, Paul Vixie, Brian Wellington, document author Andreas Gustafsson, and WG chair Gudmundsson. There are non-BIND people who support the document, notably PowerDNS implementor Bert Hubert, but my understanding is that Hubert's support is based entirely on the hope that this document will prevent future interoperability problems, without regard to the huge redeployment costs that this document is imposing on the users of existing implementations. Note that the users attacked by this document include BIND 8 users---who are no longer represented in the WG by implementors, now that the BIND implementors are pushing BIND 9. The document's proponents admit that their ``clarification'' imposes rules disobeyed by BIND 8. My survey http://cr.yp.to/surveys/dns1.html two months ago showed that 45% of all .com names were served by BIND 8, while only 23% were served by BIND 9. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago P.S. You know what really amazes me about this? In another forum, a few people, including a former IESG member, are objecting to an incredibly valuable requirement that software support a universal encoding (UTF-8) of a universal character set (Unicode). Why? Because this requirement would force some existing software to change---and these people claim that the IETF _never_ demands changes from deployed software that complies with the previous standards. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 14 06:42:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16610 for ; Fri, 14 Feb 2003 06:42:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jeB2-0005mB-00 for namedroppers-data@psg.com; Fri, 14 Feb 2003 03:38:44 -0800 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 18jeB0-0005lx-00 for namedroppers@ops.ietf.org; Fri, 14 Feb 2003 03:38:42 -0800 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1EBcVq27692; Fri, 14 Feb 2003 18:38:31 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1EBcMb10699; Fri, 14 Feb 2003 18:38:24 +0700 (ICT) From: Robert Elz To: "D. J. Bernstein" cc: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: axfr-clarify's fraudulent claims of consensus In-Reply-To: <20030214103228.71052.qmail@cr.yp.to> References: <20030214103228.71052.qmail@cr.yp.to> <200302101659.LAA15654@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Feb 2003 18:38:22 +0700 Message-ID: <10697.1045222702@munnari.OZ.AU> X-Spam-Status: No, hits=-0.5 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_02_03 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: 14 Feb 2003 10:32:28 -0000 From: "D. J. Bernstein" Message-ID: <20030214103228.71052.qmail@cr.yp.to> | This ``clarification'' document prohibits several perfectly legitimate, | very widely deployed, AXFR implementation techniques. It prohibits some odd-ball techniques that risk future enhancements (and generally clarifies the almost non-existant specification). | In particular, | this document violates RFC 2119, section 6, in five separate ways. 2119 is a list of words with definitions to save other RFCs from having to define them over and over again. It has some recommendations about where the words should be used - but it is always up to the document in question (the WG for a WG document) to decide which of those words should be used in what circumstances (or to ignore 2119 completely if so inclined). "Violating" 2119 is a nonsense concept. | Furthermore, the Yokohama minutes report a WG decision that axfr-clarify | is ``too bind specific''---too specific to BIND 9, to be precise. That related to some of the language in the draft I believe (I was there, and I think was one of those who supported this position). Some of that I still believe could be cleaned up to be nicer. It doesn't relate to any of the substance though, nor particularly to BIND 9, but rather to use of terms like "slave" and "master" which are (recent) BIND inventions to refer to what the DNS (1034/1035) has always used the words "secondary" and "primary" for. There's a bit more like that I think as well. None of it really matters, though the doc would be better if it was all fixed. | Despite this decision and these extensive objections, the WG chairs | declared ``consensus'' for axfr-clarify and sent it to the IESG. I believe rough consensus exists on this one (it is rough, but there's certainly much more support than opposition). | A review of all of the axfr-clarify discussions in the WG list archive | shows that this document is being pushed primarily by people who have | been paid for BIND work: Even if this were true (and I don't believe it is - I have never been paid for any BIND work) it is irrelevant. It is not at all unusual for a group of related people (sometimes all actually currently employed by one organisation) to push a proposal. | Note that the users attacked by this document include BIND 8 users---who | are no longer represented in the WG by implementors, now that the BIND | implementors are pushing BIND 9. The document's proponents admit that | their ``clarification'' imposes rules disobeyed by BIND 8. My survey | http://cr.yp.to/surveys/dns1.html two months ago showed that 45% of all | .com names were served by BIND 8, while only 23% were served by BIND 9. What has this to do with anything? All that is being done here is to tighten up the specification for how AXFR is supposed to be done. That old BIND code has bugs can hardly be news (even older BIND code had millions of bugs). Nothing proposed is going to cause failures of any existing implementations, nor any current implementations to fail to interoperate with any new implementations that follow this clarification. The scare mongering about "huge redeployment costs" is utter nonsense, no-one is being asked to redeploy anything. All this document seeks to do is to get future AXFR implementations to be a little tighter in what they do, so that some possible (even worse) implementations bugs would have less bad effects than they might otherwise have done. The effect upon your implementation would be, that unless you alter your implementation, you wouldn't be able to claim that it is conformant with this new RFC (once it is issued of course). That's it. As you seem to dislike AXFR as a zone transfer mechanism anyway (which is just fine, it has never been required) I'm not sure why you'd care. 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. archive: From owner-namedroppers@ops.ietf.org Fri Feb 14 09:01:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22924 for ; Fri, 14 Feb 2003 09:01:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jgG4-000CUM-00 for namedroppers-data@psg.com; Fri, 14 Feb 2003 05:52:04 -0800 Received: from outpost.ds9a.nl ([213.244.168.210]) by psg.com with esmtp (Exim 3.36 #1) id 18jgFy-000CTs-00 for namedroppers@ops.ietf.org; Fri, 14 Feb 2003 05:51:58 -0800 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id B3BA44615; Fri, 14 Feb 2003 14:51:55 +0100 (CET) Date: Fri, 14 Feb 2003 14:51:55 +0100 From: bert hubert To: "D. J. Bernstein" Cc: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: axfr-clarify's fraudulent claims of consensus Message-ID: <20030214135155.GA8342@outpost.ds9a.nl> References: <200302101659.LAA15654@ietf.org> <20030214103228.71052.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030214103228.71052.qmail@cr.yp.to> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-4.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_03_05,USER_AGENT, USER_AGENT_MUTT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, Feb 14, 2003 at 10:32:28AM -0000, D. J. Bernstein wrote: > This ``clarification'' document prohibits several perfectly legitimate, > very widely deployed, AXFR implementation techniques. See my web page > http://cr.yp.to/djbdns/axfr-clarify.html for details. In particular, > this document violates RFC 2119, section 6, in five separate ways. See me not care. Almost all RFCs are mutually contradictory. This is not math, and even there we have Goedel. Some observations. Does this clarify things ------------------------ Well, yes. It also specifies new behaviour. The name is therefore wrong. I'd move to just call this RFC the 'New AXFR RFC' and be done with it. It should then also specify that nameservers should have configuration options to deal with older servers. Otherwise, I'd be more than happy with a non-semantics changing version of this draft, one that just documents how to start an AXFR and how to finish it. The Zone -------- Your software does not know about zones, it appears. Much of your criticism boils down to the fact that you do not have a zone concept and do not want to have one, where 1034 and 1035 simply ooze with zone definitions and they are clearly part of the DNS philosophy. Could you perhaps separate your criticism into the parts that are truly stupid and the parts that just don't fit in with your architecture? At a very early point, PowerDNS also did not have zones but it turns out to be hard to do proper interoperation without them. "Therefore, in a zone transfer the master MUST send exactly those records that are associated with the zone, whether or not their owner names would be considered to be "in" the zone for purposes of resolution, and whether or not they would be eligible for use as glue in responses" I don't really get this one on second or third reading. Does this condone weird data in a zone, data that does not end on the zone name? Like the examples you mention? > Dean Anderson, Len Budney, Felix von Leitner, Kenji Rikitake, Aaron > Swartz, Sam Trenholme (MaraDNS implementor), and me (djbdns > implementor). I object to the naming, this goes beyond clarification. Calling BIND9 behaviour 'existing practice' is bad politics. I hate this part: "and slaves MUST ignore any duplicate RRs received.". I know this is about robustness but it makes an incoming AXFR a O(N^2) operation which sucks. Yes, you could build sophisticated hashes & stuff but why not put the burden on the server supplying the zone. It has had to load the zone at least once anyhow. > is based entirely on the hope that this document will prevent future > interoperability problems, without regard to the huge redeployment costs > that this document is imposing on the users of existing implementations. Stuff changes anyhow. Otherwise we'd still be running NCP and HOSTS.TXT. I do like to have the ability to add TSIGs to an AXFR in the additional section, even if that potentially breaks older remotes. Regards, bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing & Traffic Control HOWTO http://netherlabs.nl Consulting -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 14 09:38:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23647 for ; Fri, 14 Feb 2003 09:38:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jgvc-000EO4-00 for namedroppers-data@psg.com; Fri, 14 Feb 2003 06:35:00 -0800 Received: from momotombo.techfak.uni-bielefeld.de ([129.70.136.107]) by psg.com with esmtp (Exim 3.36 #1) id 18jgvZ-000ENk-00 for namedroppers@ops.ietf.org; Fri, 14 Feb 2003 06:34:57 -0800 Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.11.6+Sun/8.11.6/TechFak/pk+ro20010720) with ESMTP id h1EEYtU21207 for ; Fri, 14 Feb 2003 15:34:55 +0100 (MET) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.6+Sun/8.9.1) with SMTP id h1EEYtg02743 for ; Fri, 14 Feb 2003 15:34:55 +0100 (MET) Message-Id: <200302141434.h1EEYtg02743@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org Subject: Re: axfr-clarify's fraudulent claims of consensus In-reply-to: Your message of "Fri, 14 Feb 2003 14:51:55 +0100." <20030214135155.GA8342@outpost.ds9a.nl> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Date: Fri, 14 Feb 2003 15:34:55 +0100 From: Peter Koch X-Spam-Status: No, hits=-2.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02,X_AUTH_WARNING version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk {trimmed To: list} bert hubert wrote: > "and slaves MUST ignore any duplicate RRs received.". I know this is about > robustness but it makes an incoming AXFR a O(N^2) operation which sucks. > Yes, you could build sophisticated hashes & stuff but why not put the burden > on the server supplying the zone. It has had to load the zone at least once > anyhow. Depends on how actively you'd like duplicates to be ignored. I'd read it in a way that prohibits rejecting the incoming zone upon receipt of a duplicate RR but also prohibits handing out these duplicate RRs (which is in RFC 2181, section5, already) in responses. Also, it allows the slave, if also acting as a master (*), to hand out the zone without those duplicates, whereas the general philosophy is that the zone not be touched while being handed through. (*) kre: this is why primary/secondary are not sufficient terms in the context of this document -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. archive: From owner-namedroppers@ops.ietf.org Fri Feb 14 10:17:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24380 for ; Fri, 14 Feb 2003 10:17:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jhVF-000G6h-00 for namedroppers-data@psg.com; Fri, 14 Feb 2003 07:11:49 -0800 Received: from proxy.6wind.com ([194.250.197.211]) by psg.com with esmtp (Exim 3.36 #1) id 18jhVC-000G68-00 for namedroppers@ops.ietf.org; Fri, 14 Feb 2003 07:11:47 -0800 Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id BA90F416; Fri, 14 Feb 2003 16:24:45 +0100 (CET) Received: from 6wind.com (ksinant.6wind.com [10.0.0.101]) by intranet.6wind.com (Postfix) with ESMTP id 886DE57C; Fri, 14 Feb 2003 16:13:13 +0100 (CET) Message-ID: <3E4D0737.B6BCE556@6wind.com> Date: Fri, 14 Feb 2003 16:11:51 +0100 From: Vladimir Ksinant X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark Cc: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair , Erik Nordmark , namedroppers@ops.ietf.org, Mohsen Souissi Subject: Re: DNSEXT WGLC Summary: RFC1886bis-01 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > The interoperability report identifies some RR types for which AAA > additional section processing makes sense that are > not explicitly specified in the draft: > * CNAME records (not mentioned in RFC1886) > * PTR records (mentioned in RFC1886, but not explicitly) > * SRV records (not mentioned in RFC1886) > * SOA records (not mentioned in RFC1886) > > Wouldn't it make sense to add explicit mention of those types to > section 3 (right now the section says for example NS and MX). Our opinion is that the draft should not list all the types that require additional section processing. The reason is that some new types may have to be added in the future and they will not be listed in the document. If the interoperability report creates confusion on this point, we can fix it. > > Normative References > > For this document to become a draft standard all normative references > need to be draft standard or higher. > Point taken. > [4] Gilligan, R., and E. Nordmark, "Transition Mechanisms for IPv6 > Hosts and Routers", RFC 2893, FreeGate Corp., Sun Microsystems > Inc., August 2000. > This RFC is being updated. The current draft is > "draft-ietf-ngtrans-mech-v2-00.txt", Gilligan, R., and > E. Nordmark, July 17, 2002 > > Is this really a normative reference i.e. something that one needs to > read and understand in order to implement RFC1886bis? > Our own opinion is that [4] is rather informative reference. > Also, [5] through [8] seems like informative references. Agreed > (But [3] is normative for the textual representation.) Agreed too. If there is consensus on this, we can modify the references in the draft. Vladimir and mohsen -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 14 11:16:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25891 for ; Fri, 14 Feb 2003 11:16:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jiR8-000Itv-00 for namedroppers-data@psg.com; Fri, 14 Feb 2003 08:11:38 -0800 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 18jiR5-000ItG-00 for namedroppers@ops.ietf.org; Fri, 14 Feb 2003 08:11:35 -0800 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id LAA15208; Fri, 14 Feb 2003 11:11:15 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA18823; Fri, 14 Feb 2003 11:11:01 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id LAA10667; Fri, 14 Feb 2003 11:06:15 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id LAA08665; Fri, 14 Feb 2003 11:06:15 -0500 (EST) To: Mark.Andrews@isc.org Cc: Mark_Andrews@isc.org, Jim Reid , Jakob Schlyter , Miek Gieben , Scott Rose , namedroppers@ops.ietf.org From: Derek Atkins Subject: Re: Q2: crypto algorithm requirements for DNSSEC References: <200302132321.h1DNL7d6021114@drugs.dv.isc.org> Date: 14 Feb 2003 11:06:15 -0500 In-Reply-To: <200302132321.h1DNL7d6021114@drugs.dv.isc.org> Message-ID: Lines: 15 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-1.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,RCVD_IN_RELAYS_ORDB_ORG,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_GNUS_UA,X_OSIRU_OPEN_RELAY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mark.Andrews@isc.org writes: > > There is a LOT of extra policy decision that needs to happen if you go > > down this road. A lot of extra implementation, too! > > You are missing the whole point. No, I'm not. I'm just looking at it from a different angle. -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.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. archive: From owner-namedroppers@ops.ietf.org Fri Feb 14 12:06:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27507 for ; Fri, 14 Feb 2003 12:06:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jjCx-000LQJ-00 for namedroppers-data@psg.com; Fri, 14 Feb 2003 09:01:03 -0800 Received: from thales.memphis.edu ([141.225.37.221]) by psg.com with smtp (Exim 3.36 #1) id 18jjCv-000LQ7-00 for namedroppers@ops.ietf.org; Fri, 14 Feb 2003 09:01:01 -0800 Received: (qmail 14142 invoked by uid 500); 14 Feb 2003 17:00:54 -0000 From: mw-list-namedroppers@csi.hu Date: Fri, 14 Feb 2003 11:00:54 -0600 To: namedroppers@ops.ietf.org Subject: Re: axfr-clarify's fraudulent claims of consensus Message-ID: <20030214170054.GA13587@thales.memphis.edu> References: <200302101659.LAA15654@ietf.org> <20030214103228.71052.qmail@cr.yp.to> <20030214135155.GA8342@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030214135155.GA8342@outpost.ds9a.nl> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-1.4 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_03_05,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, Feb 14, 2003 at 02:51:55PM +0100, bert hubert wrote: > See me not care. Almost all RFCs are mutually contradictory. This is not > math, and even there we have Goedel. You certainly did not mean to refer to Godel in this context. But even if you did not, the above one and and a half lines are for the books: how to lucidly express a healthy ignorance in math and, simultaneously, come out of the closet and expose your opinion that logic has no place in evaluating RFCs. > Your software does not know about zones, it appears. It appears as in "it appears by running, and testing it on my box in the last few months", or as in "it appears in my mind right now so that I can go on with the rant that follows" ? But seriously: are you serious? Could you at least try to be by avoiding soap opera words like "hate" and "stupid" and search for more grown up versions? Thx, --- Mate Wierdl | Dept. of Math. Sciences | University of Memphis -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 14 12:44:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28479 for ; Fri, 14 Feb 2003 12:44:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jjpz-000NY2-00 for namedroppers-data@psg.com; Fri, 14 Feb 2003 09:41:23 -0800 Received: from outpost.ds9a.nl ([213.244.168.210]) by psg.com with esmtp (Exim 3.36 #1) id 18jjpZ-000NVW-00 for namedroppers@ops.ietf.org; Fri, 14 Feb 2003 09:40:57 -0800 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 9F53C46A6; Fri, 14 Feb 2003 18:40:56 +0100 (CET) Date: Fri, 14 Feb 2003 18:40:56 +0100 From: bert hubert To: mw-list-namedroppers@csi.hu Cc: namedroppers@ops.ietf.org Subject: Re: axfr-clarify's fraudulent claims of consensus Message-ID: <20030214174056.GA17682@outpost.ds9a.nl> References: <200302101659.LAA15654@ietf.org> <20030214103228.71052.qmail@cr.yp.to> <20030214135155.GA8342@outpost.ds9a.nl> <20030214170054.GA13587@thales.memphis.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030214170054.GA13587@thales.memphis.edu> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-4.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MUTT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, Feb 14, 2003 at 11:00:54AM -0600, mw-list-namedroppers@csi.hu wrote: > books: how to lucidly express a healthy ignorance in math and, > simultaneously, come out of the closet and expose your opinion that > logic has no place in evaluating RFCs. Complaining that RFCs are internally inconsistent should not stand in the way of progress. Regards, bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing & Traffic Control HOWTO http://netherlabs.nl Consulting -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 14 12:55:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28939 for ; Fri, 14 Feb 2003 12:55:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jjyB-000O3Y-00 for namedroppers-data@psg.com; Fri, 14 Feb 2003 09:49:51 -0800 Received: from one.elistx.com ([209.116.252.130]) by psg.com with esmtp (Exim 3.36 #1) id 18jjy8-000O3C-00 for namedroppers@ops.ietf.org; Fri, 14 Feb 2003 09:49:48 -0800 Received: from ogud.com (pcp816081pcs.nrockv01.md.comcast.net [68.49.60.118]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HAB008KF87NFS@eListX.com> for namedroppers@ops.ietf.org; Fri, 14 Feb 2003 12:50:11 -0500 (EST) Received: from ENGILL.ogud.com (mail.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.3/8.12.3) with ESMTP id h1EHlnts009349; Fri, 14 Feb 2003 12:47:49 -0500 (EST envelope-from ogud@ogud.com) Date: Fri, 14 Feb 2003 12:48:47 -0500 From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: Summary RE: DNSEXT WGLC: DNSSEC Opt-in In-reply-to: <5.1.0.14.2.20030213092741.00afc518@mage.qualcomm.com> X-Sender: post@localhost To: Ted Hardie , "Hallam-Baker, Phillip" , "'Roy Arends'" , Erik Nordmark Cc: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair , namedroppers@ops.ietf.org Message-id: <5.1.1.6.2.20030214103213.02948900@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=us-ascii References: X-Spam-Status: No, hits=2.5 required=5.0 tests=IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI,REFERENCES, SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 12:45 2003-02-13, Ted Hardie wrote: >At 09:10 AM 2/13/2003 -0800, Hallam-Baker, Phillip wrote: >>There were 27 messages in this thread from 10 distinct individuals. >The workshop reports also indicated that the document >didn't agree with implemented behavior in regards to NXT >and needed to recommend against dynamic update; >here's the text from the report: > > * specification issues > - draft & implementation behavior WRT NXT is different, > probably draft needs to change, on inclusion of negative > wildcard proof in the answer (draft says MUST NOT, code does > it, it's probably harmless, draft should say MAY) this is a minor change, and wildcards in DNSSEC are a smaller issue now than 2 months ago see http://www.ietf.org/internet-drafts/draft-lewis-dns-wildcard-clarify-00.txt > - insecure delegation with opt-in NXT is semantically > ambiguous, useless, and doesn't work (SERVFAIL) > - draft should mention dynamic update behavior. It should > caution against dyanmic update with opt-in. There is (IMHO) no need to outlaw dynamic update in opt-in zone, but there are some extra rules that are needed as well as update to RFC2136. This could be accomplished by a separate document while the Opt-in document only says dynamic update of opt-in zones is unspecified. In the following discussion updates to zone APEX are ignored as they do not change at all. Nit: Some of the confusion in the document results from inconsistent terminology. The document seems to use the words "unsigned delegation" and "unsecure delegation" interchangeably. That is not the case, in my mind there is a difference between the two. Unsecure delegation: A delegation without DS record. Unsigned delegation: A delegation without DS but with a signed NXT. If the working group concludes that the second is not allowed it does not change the contents below. In the text below I will only use the terms [un]signed name. More terms: Local NXT == nxt with the same name as the update Previous NXT == NXT at the signed name lexicographically preceding name updated. For completeness all possible operations are included, in a delegation only Opt-in case some operations do may change the signed status as there only one RRset can be unsigned. At unsigned names deleting the only RRset it is equivalent of deleting the name. Only DS RRset can be added to a delegation but that forces signing of the node. Note: NO == Does not change the contents of field YES == Contents of field changes, requires resigning this record. NXT name local previous case:updating signed name Bitmap Name bitmap name Modifying existing RRset NO NO NO NO Adding a RRset YES NO NO no Deleting a RRset YES No no no Deleting a name NO NO no YES Adding a name YES YES NO YES case: updating unsigned name Modifying existing RRset NO NO NO NO Adding a RRset YES YES NO YES Deleting a name/RRset NO NO NO NO Adding unsigned name NO NO NO NO If a delegation can be signed without a DS RRset then the following apply: Changing security status of a delegation via Dynamic update is not obvious and a special rule needs to be made up OR this is done via server policy somehow. This adds two cases to the tables above. case: updating signed name Changing to unsigned DELETE NO YES case: updating unsigned name Changing to signed YES YES NO YES >There was also the discussion among Rob, Johann, and Michael about >the need to rev NXT (and possibly SIG and KEY) to make the current >infrastructure distinguishable from the previous infrastructure. I >didn't say a resolution to this (though I may have missed it in a thread >permutation). > DS + OPT-in is a flag day, and the question is IF/HOW to signal this inside the protocol, the options are do nothing, use a new ENDS0 flag to replace DO, change type code for NXT change type code for NXT SIG and KEY. The reason against doing nothing is that some implementations really do not like the NS + NXT in authority section as specified in DS document. This is a problem resulting from an under-specialization in RFC2535 as to when NXT can appear in authority section. The implementation problem is NXT specific. The advantage changing the NXT type code is then we have a clean break with 2535 resolvers as they will not understand the new type and the special processing that Opt-in and DS require. In my mind there is no need to renumber SIG and KEY. >>So the question for the chairs is what do we do next? > >Speaking personally, I think the authors should rev the docs to fix these >spec bugs. > regards, Speaking as a co-chair of DNSEXT: After reading all the comments received and re-reading the document it is clear to me the document needs updating before the next last call can start. I will be working with my co-chair and the authors on creating a list of changes and clarifications needed. Thus the last call can not start until sometime next week. 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. archive: From owner-namedroppers@ops.ietf.org Fri Feb 14 13:34:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00114 for ; Fri, 14 Feb 2003 13:34:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jkZV-000058-00 for namedroppers-data@psg.com; Fri, 14 Feb 2003 10:28:25 -0800 Received: from gusto.araneus.fi ([204.152.186.164]) by psg.com with esmtp (Exim 3.36 #1) id 18jkZR-00004r-00; Fri, 14 Feb 2003 10:28:21 -0800 Received: from guava.araneus.fi (adsl-63-197-0-204.dsl.snfc21.pacbell.net [63.197.0.204]) by gusto.araneus.fi (8.11.6/8.11.6) with ESMTP id h1EISDZ15810; Fri, 14 Feb 2003 10:28:13 -0800 (PST) Received: (from gson@localhost) by guava.araneus.fi (8.11.6/8.11.6) id h1EISC210840; Fri, 14 Feb 2003 10:28:12 -0800 (PST) Date: Fri, 14 Feb 2003 10:28:12 -0800 (PST) Message-Id: <200302141828.h1EISC210840@guava.araneus.fi> To: Erik Nordmark Cc: Andreas Gustafsson , ogud@ogud.com, randy@psg.com, namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-unknown-rrs-04.txt In-Reply-To: References: <200302120248.h1C2mFq19962@guava.araneus.fi> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=0.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Erik Nordmark writes: > To me it makes sense stating instead: > > This document specifies that for all other RR types, the canonical form > is such that no downcasing of embedded domain names takes place. The owner > name is always set to lower case according to the DNS rules for > character comparisons, regardless of the RR type. OK - I still don't quite see why the word "changed" is so objectionable, but I have no problem with making this change. > and then add a note saying that > > Note that after RFC 2931 there has been no RR types defined which have > an embedded domain name. This is exactly the kind of statement regarding "defined RRs" I have already repeatedly objected to adding. It is true today, but will become false as soon as additional RR types with embedded domain names are defined, and would cause nothing but confusion to an implementor reading it ten years from no. Such a statement does not belong in an archival document. > It is expected that future definitions of > RR types will explicitly state that there is no downcasing of embedded > domain names as part of DNSSEC canonicalization. That is not my expectation. There is a precedent for explicit statements regarding the applicability of *compression*, but that is only because RFC1035 was so ambiguous about where compression was allowed that it had to be specified in the individual RR type definitions (and even then some RR definitions interpreted RFC1035 differently from others). In the case of DNSSEC canonicalization, I hope the specification will be complete and unambiguous so that we don't have to resort to that kind of workaround. > In terms on text suggestions, I don't know if I've seen suggested > text that makes it clear that the document changes the compression > rule for SIG and NXT. For the benefits of clarity it makes sense > having that paragraph point at the paragraphs in 2535 that are > changed. Can do. -- 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. archive: From owner-namedroppers@ops.ietf.org Fri Feb 14 14:03:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01323 for ; Fri, 14 Feb 2003 14:03:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jkxk-0001RE-00 for namedroppers-data@psg.com; Fri, 14 Feb 2003 10:53:28 -0800 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #1) id 18jkxg-0001R0-00 for namedroppers@ops.ietf.org; Fri, 14 Feb 2003 10:53:24 -0800 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id NAA05683; Fri, 14 Feb 2003 13:46:55 -0500 Date: Fri, 14 Feb 2003 13:48:09 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Robert Elz cc: "D. J. Bernstein" , , , Subject: Re: axfr-clarify's fraudulent claims of consensus In-Reply-To: <10697.1045222702@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,SPAM_PHRASE_02_03,USER_AGENT_PINE, X_OSIRU_SPAM_SRC version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 14 Feb 2003, Robert Elz wrote: > Date: 14 Feb 2003 10:32:28 -0000 > From: "D. J. Bernstein" > Message-ID: <20030214103228.71052.qmail@cr.yp.to> > > | This ``clarification'' document prohibits several perfectly legitimate, > | very widely deployed, AXFR implementation techniques. > > It prohibits some odd-ball techniques that risk future enhancements > (and generally clarifies the almost non-existant specification). I don't think they can be dismissed so easilly. Indeed, I think the proposed changes are rather "oddball", and are actually unncessary in order to implement IXFR (which was the original claimed justification). Indeed, the proposed changes are only necessary to justify BINDs' oddball IXFR changes. They are only necessary to make BIND 9 compliant with the RFC's. It seems quite odd that a "clarification" would put 77% of the existing servers out of compliance, and only brings into compliance a currently non-compliant implementation. I think it is unprecedented in the history of any standards organization, not just the IETF. Such a significant change is clearly a completely new version. Thus the widespread complaints about fraudulent labeling and discription of the proposal. ** 45% Bind 8 ** 23% Bind 9 ** 77% are not bind 9, and will not be compliant after this "clarification" This is not the way to run a railroad. (or rather, it is a railroading of the changes through the process...) > | Despite this decision and these extensive objections, the WG chairs > | declared ``consensus'' for axfr-clarify and sent it to the IESG. > > I believe rough consensus exists on this one (it is rough, but there's > certainly much more support than opposition). Consensus on the part of Bind proponents, yes. Consensus when the wider community is counted, no. > | A review of all of the axfr-clarify discussions in the WG list archive > | shows that this document is being pushed primarily by people who have > | been paid for BIND work: > > Even if this were true (and I don't believe it is - I have never been > paid for any BIND work) it is irrelevant. It is not at all unusual > for a group of related people (sometimes all actually currently employed > by one organisation) to push a proposal. Of course not. It happens frequently in consortia. However, a "bloc" behind a single vendor is usually counted as such. Its not unheard of for a vendor to try to create an appearance of widespread support using subcontactors, when in fact there is none. When that happens, people cry "foul". We are crying "foul" now. > | Note that the users attacked by this document include BIND 8 users---who > | are no longer represented in the WG by implementors, now that the BIND > | implementors are pushing BIND 9. The document's proponents admit that > | their ``clarification'' imposes rules disobeyed by BIND 8. My survey > | http://cr.yp.to/surveys/dns1.html two months ago showed that 45% of all > | .com names were served by BIND 8, while only 23% were served by BIND 9. > > What has this to do with anything? All that is being done here is to > tighten up the specification for how AXFR is supposed to be done. That > old BIND code has bugs can hardly be news (even older BIND code had > millions of bugs). Nothing proposed is going to cause failures of > any existing implementations, nor any current implementations to fail to > interoperate with any new implementations that follow this clarification. We have hashed this through many, many times, I fail to see how you can still make this claim with a straight face. It certainly will cause failures: It will cause all non-bind 9implementations to be non-compliant (or 77% of the servers). > The scare mongering about "huge redeployment costs" is utter nonsense, > no-one is being asked to redeploy anything. Asked? No. It is demanded. This is a change to a standard, and to be compliant demands conformance to the standard, and thus change, and redeployment. Perhaps unfortunately, the IETF has no branding program. However, we still have interoperability testing to determine compliance with the standard. > All this document seeks to do is to get future AXFR implementations to > be a little tighter in what they do, so that some possible (even worse) > implementations bugs would have less bad effects than they might otherwise > have done. Clarification is a worthy goal. No one is opposed to clarification. However, the changes proposed go in the wrong direction, and are motivated purely by a crufty IXFR implementation in Bind 9. Many people have indicated that the correct approch to clarification is to look at what Bind8 and _OTHER IMPLEMENTATIONS_ did. Since BIND9 is described in an Oreily book, this could be a difficult for them. However, they should have thought about that before publishing a book describing non-conforming implmentation as though it was standards compliant. They created their own mess, and now want 77% of the world to fix it for them. Talk about the shifting of costs to someone else... The Bind9 people claim the changes are necessary to support IXFR. Of course these changes aren't necessary. IXFR is in principle no different than database transaction log processing. It has no bearing whatsoever on AXFR any more than Oracle incremental replication has bearing on the Oracle query protocol. They made changes to AXFR to make their crufty IXFR implementation work, because they are bad engineers. They exercised even worse judgement by publishing a book on their implementation prior to standardization. Now they want the 77% of the world to jump through hoops to make their oddball, badly engineered work "standard". I'm not buying it. > The effect upon your implementation would be, that unless you alter > your implementation, you wouldn't be able to claim that it is conformant > with this new RFC (once it is issued of course). That's it. As you > seem to dislike AXFR as a zone transfer mechanism anyway (which is just > fine, it has never been required) I'm not sure why you'd care. That's huge. And its not _only_ djbdns. --Dean -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 14 14:45:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02721 for ; Fri, 14 Feb 2003 14:45:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jlfi-0003vD-00 for namedroppers-data@psg.com; Fri, 14 Feb 2003 11:38:54 -0800 Received: from gusto.araneus.fi ([204.152.186.164]) by psg.com with esmtp (Exim 3.36 #1) id 18jlfe-0003v1-00 for namedroppers@ops.ietf.org; Fri, 14 Feb 2003 11:38:50 -0800 Received: from guava.araneus.fi (adsl-63-197-0-204.dsl.snfc21.pacbell.net [63.197.0.204]) by gusto.araneus.fi (8.11.6/8.11.6) with ESMTP id h1EJckZ16109; Fri, 14 Feb 2003 11:38:46 -0800 (PST) Received: (from gson@localhost) by guava.araneus.fi (8.11.6/8.11.6) id h1EJckK10941; Fri, 14 Feb 2003 11:38:46 -0800 (PST) Date: Fri, 14 Feb 2003 11:38:46 -0800 (PST) Message-Id: <200302141938.h1EJckK10941@guava.araneus.fi> To: "D. J. Bernstein" Cc: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: axfr-clarify's fraudulent claims of consensus In-Reply-To: <20030214103228.71052.qmail@cr.yp.to> References: <200302101659.LAA15654@ietf.org> <20030214103228.71052.qmail@cr.yp.to> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=0.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk D. J. Bernstein writes: > This ``clarification'' document prohibits several perfectly legitimate, > very widely deployed, AXFR implementation techniques. See my web page > http://cr.yp.to/djbdns/axfr-clarify.html for details. In particular, > this document violates RFC 2119, section 6, in five separate ways. Your objections are certainly well known by now, and I have repeatedly responded to them. > At least seven people have gone on record as objecting to axfr-clarify: > > Dean Anderson, > Len Budney, > Felix von Leitner, Can you please show us that record? I cannot find any messages from Felix von Leitner in my namedroppers archive. > Kenji Rikitake, Kenji Rikitake withdrew his objection. > Aaron Swartz, Aaron Swartz' objections appear to be based on his belief that BIND 8 and UltraDNS violate section 3 of the draft. I have not seen any further objections from him after I pointed out that they don't. > Sam Trenholme (MaraDNS implementor), and > me (djbdns implementor). > Furthermore, the Yokohama minutes report a WG decision that axfr-clarify > is ``too bind specific''---too specific to BIND 9, to be precise. My impression (based entirely on a private e-mail discussion with Randy Bush, since I was not present at the Yokohama meeting) is that this was not a decision that axfr-clarify is too BIND specific in the view of the WG, but rather a decision to give the draft more time for discussion due to *your* claim that it is too BIND specific. -- 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. archive: From owner-namedroppers@ops.ietf.org Fri Feb 14 15:34:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04131 for ; Fri, 14 Feb 2003 15:34:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jmR1-0006gV-00 for namedroppers-data@psg.com; Fri, 14 Feb 2003 12:27:47 -0800 Received: from gusto.araneus.fi ([204.152.186.164]) by psg.com with esmtp (Exim 3.36 #1) id 18jmQz-0006gA-00 for namedroppers@ops.ietf.org; Fri, 14 Feb 2003 12:27:45 -0800 Received: from guava.araneus.fi (adsl-63-197-0-204.dsl.snfc21.pacbell.net [63.197.0.204]) by gusto.araneus.fi (8.11.6/8.11.6) with ESMTP id h1EKOkZ16221; Fri, 14 Feb 2003 12:24:46 -0800 (PST) Received: (from gson@localhost) by guava.araneus.fi (8.11.6/8.11.6) id h1EKOkS10983; Fri, 14 Feb 2003 12:24:46 -0800 (PST) Date: Fri, 14 Feb 2003 12:24:46 -0800 (PST) Message-Id: <200302142024.h1EKOkS10983@guava.araneus.fi> To: Dean Anderson Cc: Robert Elz , "D. J. Bernstein" , , , Subject: Re: axfr-clarify's fraudulent claims of consensus In-Reply-To: References: <10697.1045222702@munnari.OZ.AU> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=0.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Dean Anderson writes: > I don't think they can be dismissed so easilly. Indeed, I think the > proposed changes are rather "oddball", and are actually unncessary in > order to implement IXFR (which was the original claimed justification). This is not a "change". There are no existing standards which mandate or even explicitly allow mixing of data between zones. On the contrary, RFC1035 specifically suggests using separate data structures that ensure that no such mixing occurs: 6.1.2. Database While name server implementations are free to use any internal data structures they choose, the suggested structure consists of three major parts: - A "catalog" data structure which lists the zones available to this server, and a "pointer" to the zone data structure. The main purpose of this structure is to find the nearest ancestor zone, if any, for arriving standard queries. - Separate data structures for each of the zones held by the name server. - A data structure for cached data. (or perhaps separate caches for different classes) Which one is more "oddball", a server which follows this suggestion or one which does not? > Indeed, the proposed changes are only necessary to justify BINDs' oddball > IXFR changes. They are only necessary to make BIND 9 compliant with the > RFC's. BIND 9 is compliant with the existing AXFR standard even without axfr-clarify. It's not hard to comply since the existing the specification is almost nonexistent. > It seems quite odd that a "clarification" would put 77% of the existing > servers out of compliance, 77% of the existing servers do not reliably interoperate in IXFR (even with one another), and sometimes serve data inconsistent between the authoritative servers of a zone. They *should* be declared out of compliance. > and only brings into compliance a currently > non-compliant implementation. Again, BIND 9 is currently compliant. > Consensus on the part of Bind proponents, yes. Consensus when the wider > community is counted, no. I am not a BIND proponent. Although I wrote the draft while working on BIND 9, I encountered the interoperability problems caused by the current lack of specification and saw the need for clarification years before I received my first BIND-related paycheck. I currently work on products that directly compete with BIND, and I have no financial incentive to see BIND succeed. I have been reluctant to bring up this issue because because it should make no difference whatsoever - the draft should be judged solely on its technical merits, not based on the affiliations of its proponents, but the groundless accusations of misconduct and conspiracy theories by you and Dr. Bernstein have gone too far. -- 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. archive: From owner-namedroppers@ops.ietf.org Fri Feb 14 15:58:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04770 for ; Fri, 14 Feb 2003 15:58:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jmni-00082C-00 for namedroppers-data@psg.com; Fri, 14 Feb 2003 12:51:14 -0800 Received: from [63.149.73.20] (helo=vorpal.notabug.com) by psg.com with smtp (Exim 3.36 #1) id 18jmng-00081z-00 for namedroppers@ops.ietf.org; Fri, 14 Feb 2003 12:51:12 -0800 Received: (qmail 6656 invoked from network); 14 Feb 2003 20:51:09 -0000 Received: from 12-249-96-16.client.attbi.com (HELO aaronsw.com) (12.249.96.16) by 0 with SMTP; 14 Feb 2003 20:51:09 -0000 Date: Fri, 14 Feb 2003 14:51:10 -0600 Subject: Re: objection to axfr-clarify Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Aaron Swartz To: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <0C41331E-405E-11D7-9F22-0003936780B2@aaronsw.com> X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_03_05,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> The vast majority of implementations do not do it this way (notably >> BIND8, >> djbdns and UltraDNS) and I've only heard reports that one does >> (BIND9). >> How can the actions of only one, recent application be the existing >> protocol? > > You are incorrect regarding both BIND 8 and UltraDNS Apologies, my testing code was broken. > [returning an RCODE] is necessary in order to have an interoperable > means of indicating the reason for failure. So? Indicating the reason for failure is not necessary for interoperability. The document already says ``slaves MAY interpret an immediate graceful close of the TCP connection as equivalent to a "Refused" response (RCODE 5).'' Why not require this client strategy and remove the requirement against the server strategy? Clients will likely have to implement this anyway (when it makes a difference); the 1.85 million .com's running djbdns won't go away overnight. >> "the master MUST send exactly those records that are associated with >> the zone" How am I supposed to calculate which are associated? > If you received the zone by AXFR, it's what you received in that AXFR > (as opposed to what you received in AXFRs of other zones). This would appear to prohibit the behavior of djbdns, which makes no distinction between AXFR data for one zone and another. Adding such a distinction is not necessary, and would make the software much more complicated and harder to use. There seems to be an implicit assumption of using AXFR to update slave servers and being able to receive updates from those servers also. But this isn't part of the protocol, nor is it the protocol's only use. If you'd like to recommend this use, feel free, but please keep it separate from protocol requirements. -- Aaron Swartz [http://www.aaronsw.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. archive: From owner-namedroppers@ops.ietf.org Fri Feb 14 16:00:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04905 for ; Fri, 14 Feb 2003 16:00:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jmpO-000848-00 for namedroppers-data@psg.com; Fri, 14 Feb 2003 12:52:58 -0800 Received: from gusto.araneus.fi ([204.152.186.164]) by psg.com with esmtp (Exim 3.36 #1) id 18jmpN-00083v-00 for namedroppers@ops.ietf.org; Fri, 14 Feb 2003 12:52:57 -0800 Received: from guava.araneus.fi (adsl-63-197-0-204.dsl.snfc21.pacbell.net [63.197.0.204]) by gusto.araneus.fi (8.11.6/8.11.6) with ESMTP id h1EKqqZ16316; Fri, 14 Feb 2003 12:52:52 -0800 (PST) Received: (from gson@localhost) by guava.araneus.fi (8.11.6/8.11.6) id h1EKqq011016; Fri, 14 Feb 2003 12:52:52 -0800 (PST) Date: Fri, 14 Feb 2003 12:52:52 -0800 (PST) Message-Id: <200302142052.h1EKqq011016@guava.araneus.fi> To: Robert Elz Cc: "D. J. Bernstein" , ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: axfr-clarify's fraudulent claims of consensus In-Reply-To: <10697.1045222702@munnari.OZ.AU> References: <20030214103228.71052.qmail@cr.yp.to> <200302101659.LAA15654@ietf.org> <10697.1045222702@munnari.OZ.AU> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=0.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Robert Elz writes: > That related to some of the language in the draft I believe (I was there, > and I think was one of those who supported this position). Hmm, this seems a bit different from Randy's recollection. But anyway... > Some of that > I still believe could be cleaned up to be nicer. It doesn't relate to > any of the substance though, nor particularly to BIND 9, but rather to use > of terms like "slave" and "master" which are (recent) BIND inventions to > refer to what the DNS (1034/1035) has always used the words "secondary" > and "primary" for. These terms were defined in RFC1996 and are also used in RFC2136, and they seem clearer than "primary" and "secondary" when describing topologies where a slave server is itself acting as a master for other slaves. If you like, I could add a reference like "This document uses the terms master and slave as defined in RFC1996". > There's a bit more like that I think as well. None > of it really matters, though the doc would be better if it was all fixed. I don't recall seeing any specific suggestions for changes, and I did not attend the Yokohama meeting. Could you please them to me or namedroppers? -- 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. archive: From owner-namedroppers@ops.ietf.org Fri Feb 14 16:53:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06198 for ; Fri, 14 Feb 2003 16:53:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jnhD-000BVa-00 for namedroppers-data@psg.com; Fri, 14 Feb 2003 13:48:35 -0800 Received: from spratly.wl.nominum.com ([128.177.195.135]) by psg.com with esmtp (Exim 3.36 #1) id 18jnhA-000BVO-00 for namedroppers@ops.ietf.org; Fri, 14 Feb 2003 13:48:33 -0800 Received: from spratly.wl.nominum.com (spratly [127.0.0.1]) by spratly.wl.nominum.com (8.12.5/8.12.5) with ESMTP id h1ELmNmK007763; Fri, 14 Feb 2003 13:48:23 -0800 Received: from localhost (bwelling@localhost) by spratly.wl.nominum.com (8.12.5/8.12.5/Submit) with ESMTP id h1ELmLEw007760; Fri, 14 Feb 2003 13:48:22 -0800 X-Authentication-Warning: spratly.wl.nominum.com: bwelling owned process doing -bs Date: Fri, 14 Feb 2003 13:48:21 -0800 (PST) From: Brian Wellington X-X-Sender: bwelling@spratly.wl.nominum.com To: "Hallam-Baker, Phillip" cc: "'Roy Arends'" , Erik Nordmark , =?iso-8859-1?Q?=D3lafur_Gudmundsson/DNSEXT_co-chair?= , "" Subject: Re: Summary RE: DNSEXT WGLC: DNSSEC Opt-in In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT, REFERENCES,SPAM_PHRASE_00_01,USER_AGENT_PINE,X_AUTH_WARNING version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 13 Feb 2003, Hallam-Baker, Phillip wrote: > There were 27 messages in this thread from 10 distinct individuals. I can't speak for anyone else, but I have problems with your analysis. > > Q: Does this document satisfy people as being implement able and > testable > specification ? > > Answers: > Kosters - Yes [detailed response] > Loomis - I believe that the specification can be implemented and > tested. > Wellington - i believe that the current version of the > specification > is complete. I'm pretty sure I never said that. I have implemented opt-in, but am most definitely not sure of its correctness and whether I missed any corner cases. > Q: Are there implementations of opt-in and have there been any tests ? > > Answers: > Kosters - Yes [detailed response] > Austein - asked about resolver side implementations > Arends - Yes, Verisignlabs and ISC have auth.server > implementations, > ISC has a resolver implementation. > Nordmark - Does this mean that there is a caching resolver > implementation that has been tested? > Arends - I don't have material on how thorough the caching > resolver > implementation has been tested. > Wellington - yes. There are two questions here, and 'yes' implies yes to both. Yes, there are implementations. No, I have never tested them and do not know the results of any tests that have been performed. > In addition there were responses on the question of advancement > > Hallam-Baker - It should advance > Vixie - dunno. but in any case i am strongly in favour of it > Conrad - To be perfectly honest, I no longer care > Wellington - yes. (notes to be posted here shortly, so they > tell me.) You've got to be kidding me. I have never supported the advancement of opt-in. I don't know what notes these are, since I haven't publicly said anything about opt-in in the last 6 months. Check your facts before putting words in other people's mouths. 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. archive: From owner-namedroppers@ops.ietf.org Fri Feb 14 17:36:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07865 for ; Fri, 14 Feb 2003 17:36:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18joJX-000Dsf-00 for namedroppers-data@psg.com; Fri, 14 Feb 2003 14:28:11 -0800 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #1) id 18joJV-000DsT-00 for namedroppers@ops.ietf.org; Fri, 14 Feb 2003 14:28:09 -0800 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id RAA29890; Fri, 14 Feb 2003 17:24:26 -0500 Date: Fri, 14 Feb 2003 17:25:40 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Andreas Gustafsson cc: Robert Elz , "D. J. Bernstein" , , , Subject: Re: axfr-clarify's fraudulent claims of consensus In-Reply-To: <200302142024.h1EKOkS10983@guava.araneus.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM, SPAM_PHRASE_00_01,USER_AGENT_PINE,X_OSIRU_SPAM_SRC version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 14 Feb 2003, Andreas Gustafsson wrote: > Dean Anderson writes: > > I don't think they can be dismissed so easilly. Indeed, I think the > > proposed changes are rather "oddball", and are actually unncessary in > > order to implement IXFR (which was the original claimed justification). > > This is not a "change". There are no existing standards which mandate > or even explicitly allow mixing of data between zones. On the > contrary, RFC1035 specifically suggests using separate data structures > that ensure that no such mixing occurs: The key word is "suggests", which has the meaning... > Which one is more "oddball", a server which follows this suggestion or > one which does not? Neither. It doesn't matter what the implementation is. What matters is the protocol. Despite the "suggestion", all implementations prior to Bind 9 made different (but ultimately identical) assumptions. I don't think the section you quote is so compelling. The "oddball" part is requiring a change to a irrelevant part of a protocol. This is nothing less than bad or lazy engineering.** As I mentioned previously, IXFR is in principle no different from an Oracle incremental replication. Clearly, one does not need to alter SQL to have replicated databases. One _could_ alter SQL, but it would be a "bad idea". The concepts of replicated databases, and different kinds of replication is well researched, and well documented. There isn't any rocket science to IXFR, nor are there any theoretical papers to be written on the subject. The AXFR protocol does not _need_ to be changed for IXFR. IXFR can be made to work with AXFR the way it stands. ** a collection of good engineering principles: A "good" engineer avoids making gratiutous changes. A "good" engineer, thinking a significant change to a standard of interoperability needs to be made, will seek consensus from the standards body on the change before distributing it. A "good" engineer, upon finding a language ambiguity or vagueness, would investigate how others analyzed the language, what assumptions they made about the ambiguity and follow accordingly, or discuss and resolve the ambiguity if there are no concrete implementations. A "good" engineer, realizing an incompatible change has to be made to a standard of interoperabilty, would consult the standards body prior to publishing a (non-interoperable) book on the subject. A "good" manager, would ensure that engineers are making "good" engineering decisions. Pretty clearly, the Bind 9 group didn't exercise "good" engineering principles, nor "good" engineering management. Quite obviously, they made a mistake altering and distributing AXFR prior to standardization, or by exploiting the vagueness in the specification. Clearly, they knew about the incompatibility issue. One must wonder if anyone could be so arrogant as to assume that they could push anything they pleased through the standardization process. We probably can't know the answer. I don't know anything about their intentions and can only fairly judge the results of their actions. However, there is much to criticize about the actions. I do not think I am being unfair in that criticism. I also realize that Bind 9 was a group effort, and there is blame to spread among many. However, I do not want to pay for that mistake. Nor do others. > > Indeed, the proposed changes are only necessary to justify BINDs' oddball > > IXFR changes. They are only necessary to make BIND 9 compliant with the > > RFC's. > > BIND 9 is compliant with the existing AXFR standard even without > axfr-clarify. It's not hard to comply since the existing the > specification is almost nonexistent. No. This isn't true either. If we clarify AXFR to standardize the _assumptions_ identically and concretely made by many implementors over a long period of time, then BIND 9 will not be compliant**. Bind 9 is "compliant" only with the vague AXFR spec by invirtue of its vagueness. AXFR should be clarified. I (and others) think it should be clarified to follow the concrete assumptions made by many implementors over many years. This will only make BIND 9 non-compliant. Then 23% of the servers will have to change. 77% will be unaffected. **Actually, it might not even be this bad, as I think there are some "backwards compatibility" functionality that current Bind 9 users can utilize. So perhaps no servers need changing if we standardize AXFR as I propose. Except that Bind 9 will have to withdraw IXFR support until it fixes it to work with AXFR as clarified, or make it synonomous with AXFR. > > It seems quite odd that a "clarification" would put 77% of the existing > > servers out of compliance, > > 77% of the existing servers do not reliably interoperate in IXFR (even > with one another), and sometimes serve data inconsistent between the > authoritative servers of a zone. They *should* be declared out of > compliance. No, because IXFR support is essentially optional. An IXFR server can return the whole zone (AXFR) if it doesn't support IXFR. A server can be compliant with RFC 1995 just by making IXFR a synonym for AXFR. That's probably a one line change for most if not all implementations. Further, most people are not using IXFR. AXFR is not optional. Most people are using AXFR. > > and only brings into compliance a currently > > non-compliant implementation. > > Again, BIND 9 is currently compliant. Bind 9 won't be compliant (modulo its "backward compatibilty") after clarification of AXFR to specify the commonly assumed and commonly implemented behavior for AXFR. > > Consensus on the part of Bind proponents, yes. Consensus when the wider > > community is counted, no. > I have been reluctant to bring up this issue because because it should > make no difference whatsoever - the draft should be judged solely on > its technical merits, not based on the affiliations of its proponents, > but the groundless accusations of misconduct and conspiracy theories > by you and Dr. Bernstein have gone too far. I have made no allegations. My position on the issue of "conspiracy and misconduct" is that allegations made against Dr. Bernstein need to be investigated, and the allegations made by Dr. Bernstein also need to investigated. I think the allegations made by both sides are sufficiently specific that a determination can be made as to their truth. There are many on the djbdiscuss list who seem to think the issue deserves investigation. (I will try to get back to that matter next week, and work with others to come to a conclusion about which accusations were credible and which accusations weren't.) Clearly, some of the allegations made go way too far. --Dean -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 14 18:11:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08891 for ; Fri, 14 Feb 2003 18:11:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jovC-000GC5-00 for namedroppers-data@psg.com; Fri, 14 Feb 2003 15:07:06 -0800 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #1) id 18jov9-000GBW-00 for namedroppers@ops.ietf.org; Fri, 14 Feb 2003 15:07:03 -0800 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id RAA19762; Fri, 14 Feb 2003 17:56:31 -0500 Date: Fri, 14 Feb 2003 17:57:45 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Valdis.Kletnieks@vt.edu cc: ietf@ietf.org, , Subject: Re: axfr-clarify's fraudulent claims of consensus In-Reply-To: <200302142234.h1EMYOwZ011558@turing-police.cc.vt.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,SPAM_PHRASE_00_01,USER_AGENT_PINE, X_OSIRU_SPAM_SRC version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk As you note, they didn't conform to a BCP. There is no requirement (or implication even) that one should conform to a Best Common Practice. These serve to distribute helpful advice to the community and document practices that have worked for others, in situations that may be different. The AXFR issue is compliance with a required standard, and its definition. Much more serious concerns and issues are at stake. --Dean On Fri, 14 Feb 2003 Valdis.Kletnieks@vt.edu wrote: > On Fri, 14 Feb 2003 13:48:09 EST, Dean Anderson said: > > > It seems quite odd that a "clarification" would put 77% of the existing > > servers out of compliance, and only brings into compliance a currently > > non-compliant implementation. I think it is unprecedented in the history > > of any standards organization, not just the IETF. Such a significant > > change is clearly a completely new version. Thus the widespread > > complaints about fraudulent labeling and discription of the proposal. > > Granted, it's only a BCP, but see RFC2505. A large percentage of > implementations were non-conforming to THAT too - but the situation has > improved dramatically since then. And note that there are more servers > for *THAT* protocol, from more vendors, than for DNS. > > > -- > Valdis Kletnieks > Computer Systems Senior Engineer > Virginia Tech > > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 14 18:44:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09624 for ; Fri, 14 Feb 2003 18:44:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jpQr-000ILB-00 for namedroppers-data@psg.com; Fri, 14 Feb 2003 15:39:49 -0800 Received: from fxshpr08.extra.daimlerchrysler.com ([129.9.80.165] helo=fxshpr06.extra.daimlerchrysler.com) by psg.com with esmtp (Exim 3.36 #1) id 18jpQp-000IKn-00 for namedroppers@ops.ietf.org; Fri, 14 Feb 2003 15:39:47 -0800 Received: (from uucp@localhost) by fxshpr06.extra.daimlerchrysler.com (8.11.4/8.9.0) id h1ENcAG06374 for ; Fri, 14 Feb 2003 18:38:10 -0500 (EST) Received: from nodnsquery(129.9.147.104) by fxshpr08.extra.daimlerchrysler.com via csmap (V6.0) id srcAAAsXaOCm; Fri, 14 Feb 03 18:38:10 -0500 Received: from shmrspr2-hme0.shdc.chrysler.com ([129.9.145.240]) by shconpr2-hme0.shdc.chrysler.com (Mail-Gear 2.0.0 bld 58) with SMTP id M2003021418394400456 for ; Fri, 14 Feb 2003 18:39:44 -0500 Received: from daimlerchrysler.com (wokcdts1.is.chrysler.com [53.230.102.164]) by shmrspr2-hme0.shdc.chrysler.com (8.12.7/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id h1ENdjIC023188 for ; Fri, 14 Feb 2003 18:39:45 -0500 (EST) Message-ID: <3E4D7E0B.737F8706@daimlerchrysler.com> Date: Fri, 14 Feb 2003 18:38:51 -0500 From: Kevin Darcy X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: axfr-clarify's fraudulent claims of consensus References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dean Anderson wrote: > On Fri, 14 Feb 2003, Andreas Gustafsson wrote: > > Dean Anderson writes: > > > I don't think they can be dismissed so easilly. Indeed, I think the > > > proposed changes are rather "oddball", and are actually unncessary in > > > order to implement IXFR (which was the original claimed justification). > > > > This is not a "change". There are no existing standards which mandate > > or even explicitly allow mixing of data between zones. On the > > contrary, RFC1035 specifically suggests using separate data structures > > that ensure that no such mixing occurs: > > The key word is "suggests", which has the meaning... > > > Which one is more "oddball", a server which follows this suggestion or > > one which does not? > > Neither. It doesn't matter what the implementation is. What matters is the > protocol. Despite the "suggestion", all implementations prior to Bind 9 > made different (but ultimately identical) assumptions. I don't think the > section you quote is so compelling. > > The "oddball" part is requiring a change to a irrelevant part of a > protocol. This is nothing less than bad or lazy engineering.** As I > mentioned previously, IXFR is in principle no different from an Oracle > incremental replication. Clearly, one does not need to alter SQL to have > replicated databases. One _could_ alter SQL, but it would be a "bad > idea". The concepts of replicated databases, and different kinds of > replication is well researched, and well documented. There isn't any > rocket science to IXFR, nor are there any theoretical papers to be written > on the subject. The AXFR protocol does not _need_ to be changed for IXFR. > IXFR can be made to work with AXFR the way it stands. "Can be made to work"? You mean, through some protocol clarification? If clarifying *either* standard can effect interoperability, why give preference to clarifying IXFR over clarifying AXFR? AXFR/IXFR interoperability issues aside, AXFR was so poorly specified in the first place it seems to me a far better candidate for clarification. > > > Indeed, the proposed changes are only necessary to justify BINDs' oddball > > > IXFR changes. They are only necessary to make BIND 9 compliant with the > > > RFC's. > > > > BIND 9 is compliant with the existing AXFR standard even without > > axfr-clarify. It's not hard to comply since the existing the > > specification is almost nonexistent. > > No. This isn't true either. If we clarify AXFR to standardize the > _assumptions_ identically and concretely made by many implementors over a > long period of time, then BIND 9 will not be compliant Funny, I thought the job of the IETF was to *lead* the development and establishment of Internet standards. You seem to see their job as merely that of a historian/archivist of whatever _de_facto_ standards implementors throw out there, no matter how inefficient/convoluted/non-interoperable those _de_facto_ standards happen to be. > > > It seems quite odd that a "clarification" would put 77% of the existing > > > servers out of compliance, > > > > 77% of the existing servers do not reliably interoperate in IXFR (even > > with one another), and sometimes serve data inconsistent between the > > authoritative servers of a zone. They *should* be declared out of > > compliance. > > No, because IXFR support is essentially optional. An IXFR server can > return the whole zone (AXFR) if it doesn't support IXFR. A server can be > compliant with RFC 1995 just by making IXFR a synonym for AXFR. That's > probably a one line change for most if not all implementations. Further, > most people are not using IXFR. > > AXFR is not optional. Most people are using AXFR. Speaking as the architect of a large DNS infrastructure, AXFR is becoming less and less feasible for us as time goes by, because of scaling issues. We need IXFR ASAP, but we also need good interoperability between AXFR and IXFR because it's not like we can migrate from one to the other overnight. IXFR may technically be "optional" to implement, but in the real world, IXFR or something like it, is quickly becoming a practical necessity. This is because of the increasing size of zones and the frequency with which those zones are being updated. Dean, if you're willing to pony up the thousands of dollars we waste every year because of inefficient zone transfers, then fine, we'll stick with AXFR indefinitely. I can give you the address to which to mail the checks. But I'll be damned if we continue to throw money down the toilet just because you and djb and a handful of others want to maintain compatibility with some nebulous _de_facto_ standard for AXFR. - 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. archive: From owner-namedroppers@ops.ietf.org Fri Feb 14 18:55:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09759 for ; Fri, 14 Feb 2003 18:55:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jpfR-000JPQ-00 for namedroppers-data@psg.com; Fri, 14 Feb 2003 15:54:53 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 18jpfQ-000JPB-00 for namedroppers@ops.ietf.org; Fri, 14 Feb 2003 15:54:52 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com) by rip.psg.com with esmtp (Exim 4.12) id 18jpfQ-000NyF-00 for namedroppers@ops.ietf.org; Fri, 14 Feb 2003 15:54:52 -0800 Message-Id: <200302142234.h1EMYOwZ011558@turing-police.cc.vt.edu> In-Reply-To: Your message of "Fri, 14 Feb 2003 13:48:09 EST." References: Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-1163900064P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit To: Dean Anderson Cc: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: axfr-clarify's fraudulent claims of consensus From: Valdis.Kletnieks@vt.edu Date: Fri, 14 Feb 2003 17:34:24 -0500 X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,REFERENCES, RESENT_TO,SIGNATURE_LONG_SPARSE,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --==_Exmh_-1163900064P Content-Type: text/plain; charset=us-ascii [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] On Fri, 14 Feb 2003 13:48:09 EST, Dean Anderson said: > It seems quite odd that a "clarification" would put 77% of the existing > servers out of compliance, and only brings into compliance a currently > non-compliant implementation. I think it is unprecedented in the history > of any standards organization, not just the IETF. Such a significant > change is clearly a completely new version. Thus the widespread > complaints about fraudulent labeling and discription of the proposal. Granted, it's only a BCP, but see RFC2505. A large percentage of implementations were non-conforming to THAT too - but the situation has improved dramatically since then. And note that there are more servers for *THAT* protocol, from more vendors, than for DNS. -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech --==_Exmh_-1163900064P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQE+TW7wcC3lWbTT17ARAuo3AKDtwRSE4qMVt3OXFiiCrZ64OjB7kACdHLq2 dkIUTf6PLSDDbiorG0+QJxE= =QnwB -----END PGP SIGNATURE----- --==_Exmh_-1163900064P-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 14 19:19:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10313 for ; Fri, 14 Feb 2003 19:19:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jpwF-000KXh-00 for namedroppers-data@psg.com; Fri, 14 Feb 2003 16:12:15 -0800 Received: from [2002:425c:4242:0:250:daff:fe82:1c39] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 18jpwC-000KTu-00 for namedroppers@ops.ietf.org; Fri, 14 Feb 2003 16:12:13 -0800 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id A67CD18EC for ; Fri, 14 Feb 2003 19:11:40 -0500 (EST) Date: Fri, 14 Feb 2003 19:11:40 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: axfr-clarify's fraudulent claims of consensus In-Reply-To: References: <200302142024.h1EKOkS10983@guava.araneus.fi> User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030215001140.A67CD18EC@thrintun.hactrn.net> X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Fri, 14 Feb 2003 17:25:40 -0500 (EST), Dean Anderson wrote: > > Neither. It doesn't matter what the implementation is. What matters is the > protocol. Despite the "suggestion", all implementations prior to Bind 9 > made different (but ultimately identical) assumptions. I don't think the > section you quote is so compelling. Sorry, wrong. Both JEEVES and CHIVES had very strict notions of zone boundaries, and both enforced those boundaries during zone operations. In CHIVES's case the implementation exactly matched the suggestion that Andreas quoted from RFC 1035 6.1.2. I no longer remember the precise implementation details in JEEVES's case, but since JEEVES was written by the author of RFC 1035, I would be rather surprised if the author had not followed his own suggestion. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 14 20:21:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11514 for ; Fri, 14 Feb 2003 20:21:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jqwz-000OAS-00 for namedroppers-data@psg.com; Fri, 14 Feb 2003 17:17:05 -0800 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #1) id 18jqww-000OAF-00 for namedroppers@ops.ietf.org; Fri, 14 Feb 2003 17:17:02 -0800 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id UAA23878; Fri, 14 Feb 2003 20:11:06 -0500 Date: Fri, 14 Feb 2003 20:12:20 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Kevin Darcy cc: namedroppers@ops.ietf.org Subject: Re: axfr-clarify's fraudulent claims of consensus In-Reply-To: <3E4D7E0B.737F8706@daimlerchrysler.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,SPAM_PHRASE_01_02,USER_AGENT_PINE, X_OSIRU_SPAM_SRC version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 14 Feb 2003, Kevin Darcy wrote: > "Can be made to work"? You mean, through some protocol clarification? No, I mean that AXFR can be clarified to reflect current implementations except for Bind 9. The IXFR specification doesn't need to be changed. IXFR implementations can work with the "current" (non-bind9) AXFR. > > No. This isn't true either. If we clarify AXFR to standardize the > > _assumptions_ identically and concretely made by many implementors over a > > long period of time, then BIND 9 will not be compliant > > Funny, I thought the job of the IETF was to *lead* the development and > establishment of Internet standards. You seem to see their job as merely that of > a historian/archivist of whatever _de_facto_ standards implementors throw out > there, no matter how inefficient/convoluted/non-interoperable those _de_facto_ > standards happen to be. Not at all. However, in the present case, we are dealing with a standard that was made many years ago, and there are now multiple, interoperable implementations of it. In this case, the role of the standards body (IETF) is to mediate the dispute on the ambiguous language that was written a long time ago. The "defacto" standards are in fact interoperable. I and others would like to keep it that way. The "convoluted/non-interoperable" part is Bind 9. It is also the role of the standards body to suppress gratuitous changes, which harm stability and interoperability. > Speaking as the architect of a large DNS infrastructure, AXFR is becoming less > and less feasible for us as time goes by, because of scaling issues. We need > IXFR ASAP, but we also need good interoperability between AXFR and IXFR because > it's not like we can migrate from one to the other overnight. IXFR may > technically be "optional" to implement, but in the real world, IXFR or something > like it, is quickly becoming a practical necessity. This is because of the > increasing size of zones and the frequency with which those zones are being > updated. You don't need to change AXFR to implement IXFR any more than it was necessary to change SQL to implement incremental replication in Oracle, or Sybase, or DB2, or even the proprietary wire protocols (all different, but equivalent) used by these engines. Either version of AXFR is equivalent for the purpose of IXFR. In both cases, a server gets the contents of the zone from another server. IXFR just needs to make incremental modifications to the zone database. Oracle does this. It requires no changes--its just PL/SQL scripts--though the script language needs access to its own transaction log, and the ability to make remote updates to the other DB. Did I mention that it didn't need changes to Net 8 or SQL. This isn't rocket science. DNS servers have equivalent capabilities through IXFR. Thus, from a turing machine POV, they can execute the same operations. Q.E.D. > Dean, if you're willing to pony up the thousands of dollars we waste every year > because of inefficient zone transfers, then fine, we'll stick with AXFR > indefinitely. I can give you the address to which to mail the checks. But I'll > be damned if we continue to throw money down the toilet just because you and djb > and a handful of others want to maintain compatibility with some nebulous > _de_facto_ standard for AXFR. You can implement IXFR. No one is stopping you from doing that. You just can't change AXFR. Nor do you need to change AXFR from how is implemented in everything else except Bind 9. If people are so dull that they can't figure how to implement IXFR, well, perhaps they should use Ultradns or some other DNS server with a DB backend and hire an oracle, sybase, or db2, etc consultant as preferred to setup replication and forget about zone transfers altogether. Any commercial Database Engine (and some non-commercial, I think) will happily do incremental update for you, using a plethora of proprietary but equivalent wire protocols. If bandwidth is such a concern (hard to imagine at $50/meg at high levels)... But if you want to pay me, I'll redo the AXFR and IXFR protocols using ASN.1. (I'm close to releasing a free ASN.1 compiler that implements most of the TMF C++ API standard and the ASN1 ITU standards.). Perhaps we can use unaligned PER, which will use a fraction of the bandwidth (practically all bits are used). We'll even compress the PDUs. Everyone has zlib, right? I'd guess we can reduce bandwidth to about 30%. We'll call it AXFR/2 and IXFR/2. Then we could update the resolvers to use aligned PER (not as efficient but easier to encode and decode), we could probably save even more bandwidth worldwide. Not that I'm seriously proposing this--It would save some bandwidth, but the deployment costs would outweigh any savings. ASN1 has advantages and disadvantages, but we are now committed to protocols for DNS specified years ago, and can't run off changing them gratuitously because we have a new widget. Of course, we certainly won't call an ASN1 proposal a "clarification". Maybe "alternate protocol for AXFR and IXFR" --Dean -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 14 20:43:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11831 for ; Fri, 14 Feb 2003 20:43:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jrGK-000PLk-00 for namedroppers-data@psg.com; Fri, 14 Feb 2003 17:37:04 -0800 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #1) id 18jrGI-000PLY-00 for namedroppers@ops.ietf.org; Fri, 14 Feb 2003 17:37:02 -0800 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id UAA22567; Fri, 14 Feb 2003 20:33:08 -0500 Date: Fri, 14 Feb 2003 20:34:22 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Rob Austein cc: namedroppers@ops.ietf.org Subject: Re: axfr-clarify's fraudulent claims of consensus In-Reply-To: <20030215001140.A67CD18EC@thrintun.hactrn.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,SPAM_PHRASE_00_01, TO_BE_REMOVED_REPLY,USER_AGENT_PINE,X_OSIRU_SPAM_SRC version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I think you misunderstood my message. I meant to stress the fact that the implementation details don't matter, but only the protocols matter. I'm talking about modern implementations, such as Bind8, UltraDNS, etc. They worked out interoperable assumptions on the meaning of AXFR that were differnent than Bind 9. --Dean On Fri, 14 Feb 2003, Rob Austein wrote: > At Fri, 14 Feb 2003 17:25:40 -0500 (EST), Dean Anderson wrote: > > > > Neither. It doesn't matter what the implementation is. What matters is the > > protocol. Despite the "suggestion", all implementations prior to Bind 9 > > made different (but ultimately identical) assumptions. I don't think the > > section you quote is so compelling. > > Sorry, wrong. Both JEEVES and CHIVES had very strict notions of zone > boundaries, and both enforced those boundaries during zone operations. > > In CHIVES's case the implementation exactly matched the suggestion > that Andreas quoted from RFC 1035 6.1.2. I no longer remember the > precise implementation details in JEEVES's case, but since JEEVES was > written by the author of RFC 1035, I would be rather surprised if the > author had not followed his own suggestion. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 14 20:51:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11902 for ; Fri, 14 Feb 2003 20:51:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jrRa-000Q0G-00 for namedroppers-data@psg.com; Fri, 14 Feb 2003 17:48:42 -0800 Received: from [2002:425c:4242:0:250:daff:fe82:1c39] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 18jrRY-000PzM-00 for namedroppers@ops.ietf.org; Fri, 14 Feb 2003 17:48:40 -0800 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id C29F218EC for ; Fri, 14 Feb 2003 20:48:07 -0500 (EST) Date: Fri, 14 Feb 2003 20:48:07 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: draft-ietf-dnsext-dnssec-intro-05.txt User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030215014807.C29F218EC@thrintun.hactrn.net> X-Spam-Status: No, hits=0.3 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I just sent draft-ietf-dnsext-dnssec-intro-05.txt off to the Internet-Drafts administrator. In case anyone wants to read this over the weekend, the URL for what I just sent in is: http://www.hactrn.net/ietf/dns/dnssec-editors/draft-ietf-dnsext-dnssec-intro-05.txt Comments actively solicited, the sooner the better. See the WG chairs' periodic posting to this list on "DNSSEC editing process" for details on where to send feedback. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 14 21:02:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12060 for ; Fri, 14 Feb 2003 21:02:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jraK-0000hG-00 for namedroppers-data@psg.com; Fri, 14 Feb 2003 17:57:44 -0800 Received: from gusto.araneus.fi ([204.152.186.164]) by psg.com with esmtp (Exim 3.36 #1) id 18jraH-0000ge-00 for namedroppers@ops.ietf.org; Fri, 14 Feb 2003 17:57:41 -0800 Received: from guava.araneus.fi (adsl-63-197-0-204.dsl.snfc21.pacbell.net [63.197.0.204]) by gusto.araneus.fi (8.11.6/8.11.6) with ESMTP id h1F1vYZ17004; Fri, 14 Feb 2003 17:57:34 -0800 (PST) Received: (from gson@localhost) by guava.araneus.fi (8.11.6/8.11.6) id h1F1vXw11389; Fri, 14 Feb 2003 17:57:33 -0800 (PST) Date: Fri, 14 Feb 2003 17:57:33 -0800 (PST) Message-Id: <200302150157.h1F1vXw11389@guava.araneus.fi> To: Dean Anderson Cc: , Subject: Re: axfr-clarify's fraudulent claims of consensus In-Reply-To: References: <200302142024.h1EKOkS10983@guava.araneus.fi> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=0.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Dean Anderson writes: > Despite the "suggestion", all implementations prior to Bind 9 > made different (but ultimately identical) assumptions. Rob Austein already pointed out JEEVES and CHIVES as counterexamples, and before I worked on BIND, I wrote an authoritative-only server which also used separate data structures for each zone. When I started working on BIND 9, the BIND 9 team had already independently made the same design decision. To both me and the BIND 9 team, it was the obvious design, and the BIND 8 behavior was an obvious implementation bug. > This is nothing less than bad or lazy engineering.** As I > mentioned previously, IXFR is in principle no different from an Oracle > incremental replication. Clearly, one does not need to alter SQL to have > replicated databases. One _could_ alter SQL, but it would be a "bad > idea". If a version of Oracle had a bug that caused tuples to "leak" between tables under certain conditions and the bug was only noticed when it broke incremental replication, would you fix the bug or try to redesign the replication protocol around the bug? Would you do differently if 77% of deployed Oracle servers had the bug? > [more gratuitous insults that I'm not going to respond to] > So perhaps no servers need changing if we standardize AXFR as I > propose. No servers will need changing if we standardize AXFR as I propose, either. There is no AXFR interoperability issue either way. The only difference (other than IXFR working better) is that a different set of servers is declared non-compliant. -- 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. archive: From owner-namedroppers@ops.ietf.org Fri Feb 14 21:12:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12195 for ; Fri, 14 Feb 2003 21:12:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jrjk-0001O7-00 for namedroppers-data@psg.com; Fri, 14 Feb 2003 18:07:28 -0800 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #1) id 18jrjg-0001NZ-00 for namedroppers@ops.ietf.org; Fri, 14 Feb 2003 18:07:24 -0800 Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57] (may be forged)) by peacock.verisign.com (8.12.1/) with ESMTP id h1F26bCq013745; Fri, 14 Feb 2003 18:06:37 -0800 (PST) Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id <15SGYBVA>; Fri, 14 Feb 2003 18:07:17 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Brian Wellington'" , "Hallam-Baker, Phillip" Cc: "'Roy Arends'" , Erik Nordmark , =?iso-8859-1?Q?=D3lafur_Gudmundsson/DNSEXT_co-chair?= , namedroppers@ops.ietf.org Subject: RE: Summary RE: DNSEXT WGLC: DNSSEC Opt-in Date: Fri, 14 Feb 2003 18:07:11 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_0189_01C2D46D.0B80CF30"; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=2.5 required=5.0 tests=EXCHANGE_SERVER,MAY_BE_FORGED,MISSING_OUTLOOK_NAME,OPT_IN, QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.43 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0189_01C2D46D.0B80CF30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Brian, Ooops, Sorry about that, somehow I managed to get your name attached to Paul Vixie's comments one of which is in the wrong column. Probably the DNS Directorate using their confusion ray ... Phill > -----Original Message----- > From: Brian Wellington [mailto:Brian.Wellington@nominum.com] > Sent: Friday, February 14, 2003 4:48 PM > To: Hallam-Baker, Phillip > Cc: 'Roy Arends'; Erik Nordmark; =D3lafur Gudmundsson/DNSEXT co-chair; > namedroppers@ops.ietf.org > Subject: Re: Summary RE: DNSEXT WGLC: DNSSEC Opt-in >=20 >=20 > On Thu, 13 Feb 2003, Hallam-Baker, Phillip wrote: >=20 > > There were 27 messages in this thread from 10 distinct individuals. >=20 > I can't speak for anyone else, but I have problems with your analysis. > >=20 > > Q: Does this document satisfy people as being implement able and > > testable > > specification ? > >=20 > > Answers: > > Kosters - Yes [detailed response] > > Loomis - I believe that the specification can be implemented and > > tested. > > Wellington - i believe that the current version of the > > specification=20 > > is complete. >=20 > I'm pretty sure I never said that. I have implemented=20 > opt-in, but am most=20 > definitely not sure of its correctness and whether I missed=20 > any corner=20 > cases. >=20 > > Q: Are there implementations of opt-in and have there been=20 > any tests ? > >=20 > > Answers: > > Kosters - Yes [detailed response] > > Austein - asked about resolver side implementations > > Arends - Yes, Verisignlabs and ISC have auth.server > > implementations,=20 > > ISC has a resolver implementation. > > Nordmark - Does this mean that there is a caching resolver=20 > > implementation that has been tested?=20 > > Arends - I don't have material on how thorough the caching > > resolver=20 > > implementation has been tested. > > Wellington - yes. >=20 > There are two questions here, and 'yes' implies yes to both. =20 > Yes, there=20 > are implementations. No, I have never tested them and do not=20 > know the=20 > results of any tests that have been performed. >=20 > > In addition there were responses on the question of advancement > >=20 > > Hallam-Baker - It should advance > > Vixie - dunno. but in any case i am strongly in favour of it > > Conrad - To be perfectly honest, I no longer care=20 > > Wellington - yes. (notes to be posted here shortly, so they > > tell me.) >=20 > You've got to be kidding me. I have never supported the=20 > advancement of=20 > opt-in. I don't know what notes these are, since I haven't=20 > publicly said=20 > anything about opt-in in the last 6 months. >=20 > Check your facts before putting words in other people's mouths. >=20 > Brian >=20 ------=_NextPart_000_0189_01C2D46D.0B80CF30 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1 3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1 81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK +gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/ H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDIxNTAy MDcxMlowIwYJKoZIhvcNAQkEMRYEFNdAB1KJF3ttHB1BT36RJZujJxREMFgGCSqGSIb3DQEJDzFL MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO rwvJMA0GCSqGSIb3DQEBAQUABIGAsslqWv08tkdjpkQbCm3aQC2YoUoabQfbQs1YtaZQRocFLGlR 76rlpW7ZVfOxPyAs9bMCrmO3uPeQmVMUob3BDDCh0HIVCbzsUxjUgKjit96Mk3Ka1/aQj3tHbNzO QGeOSW6GajSahCvttluWoBHfYp8LL++8uuGNVURis5n8Il8AAAAAAAA= ------=_NextPart_000_0189_01C2D46D.0B80CF30-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 14 21:27:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12340 for ; Fri, 14 Feb 2003 21:27:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jrzv-0002UM-00 for namedroppers-data@psg.com; Fri, 14 Feb 2003 18:24:11 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 18jrzs-0002U7-00 for namedroppers@ops.ietf.org; Fri, 14 Feb 2003 18:24:08 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com) by rip.psg.com with esmtp (Exim 4.12) id 18jrzs-000Oc9-00; Fri, 14 Feb 2003 18:24:08 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 14 Feb 2003 18:24:08 -0800 To: Rob Austein Cc: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-dnssec-intro-05.txt References: <20030215014807.C29F218EC@thrintun.hactrn.net> Message-Id: X-Spam-Status: No, hits=-0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I just sent draft-ietf-dnsext-dnssec-intro-05.txt off to the > Internet-Drafts administrator. In case anyone wants to read this over > the weekend, the URL for what I just sent in is: > > http://www.hactrn.net/ietf/dns/dnssec-editors/draft-ietf-dnsext-dnssec-intro-05.txt > > Comments actively solicited, the sooner the better. See the WG > chairs' periodic posting to this list on "DNSSEC editing process" for > details on where to send feedback. serious namedroppers PLEASE REVIEW. we're trying to get this stuff out the door, and rob, isc, and others are devoting time and money to the cause. we own them and ourselves serious review. thanks. 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. archive: From owner-namedroppers@ops.ietf.org Fri Feb 14 21:58:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13127 for ; Fri, 14 Feb 2003 21:58:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jsR3-0004K1-00 for namedroppers-data@psg.com; Fri, 14 Feb 2003 18:52:13 -0800 Received: from [2001:4f8:3:bb:2e0:81ff:fe23:7b5a] (helo=as.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 18jsR0-0004H4-00 for namedroppers@ops.ietf.org; Fri, 14 Feb 2003 18:52:10 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id EA0BA379E40; Sat, 15 Feb 2003 02:51:56 +0000 (GMT) From: Paul Vixie To: iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: axfr-clarify's fraudulent claims of consensus In-Reply-To: Message from gson@nominum.com (Andreas Gustafsson) of "Fri, 14 Feb 2003 17:57:33 PST." <200302150157.h1F1vXw11389@guava.araneus.fi> X-Mailer: MH-E 7.2; nmh 1.0.4; GNU Emacs 21.2.1 Date: Sat, 15 Feb 2003 02:51:56 +0000 Message-Id: <20030215025156.EA0BA379E40@as.vix.com> X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ... made the same design decision. To both me and the BIND 9 team, it > was the obvious design, and the BIND 8 behavior was an obvious > implementation bug. i just want to say, bind8's treatment of zone boundaries is terrible, even though it's better in a dozen small ways than bind4's from which it came. my advice is, if you use bind, upgrade to bind9. > No servers will need changing if we standardize AXFR as I propose, > either. There is no AXFR interoperability issue either way. The > only difference (other than IXFR working better) is that a different > set of servers is declared non-compliant. agreed. i am in strong support of the gustafsson axfr-clarify draft. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 14 22:24:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13505 for ; Fri, 14 Feb 2003 22:24:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jsu7-0006HF-00 for namedroppers-data@psg.com; Fri, 14 Feb 2003 19:22:15 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #1) id 18jsu3-0006H2-00 for namedroppers@ops.ietf.org; Fri, 14 Feb 2003 19:22:11 -0800 Received: (qmail 81432 invoked by uid 1016); 15 Feb 2003 03:22:36 -0000 Date: 15 Feb 2003 03:22:36 -0000 Message-ID: <20030215032236.81431.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: axfr-notes.html References: <200302101659.LAA15654@ietf.org> <20030214103228.71052.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=0.3 required=5.0 tests=REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk It has become clear that the BIND company's ``AXFR clarifications'' are never going to turn into an honest description of the AXFR protocol. Consequently, for the sake of interoperability, I sat down after my last message and wrote a web page saying how AXFR actually works: http://cr.yp.to/djbdns/axfr-notes.html Comments are welcome from anyone who wants to help future implementors. Comments are not welcome from people who are demanding (for commercial reasons or for religious reasons) that most of the DNS servers on the Internet be changed to imitate BIND 9. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 14 22:34:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13990 for ; Fri, 14 Feb 2003 22:34:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jt2t-0006wu-00 for namedroppers-data@psg.com; Fri, 14 Feb 2003 19:31:19 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #1) id 18jt2p-0006we-00 for namedroppers@ops.ietf.org; Fri, 14 Feb 2003 19:31:16 -0800 Received: (qmail 82624 invoked by uid 1016); 15 Feb 2003 03:31:41 -0000 Date: 15 Feb 2003 03:31:41 -0000 Message-ID: <20030215033141.82623.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: axfr-clarify's fraudulent claims of consensus References: <20030214103228.71052.qmail@cr.yp.to> <200302101659.LAA15654@ietf.org> <10697.1045222702@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=0.3 required=5.0 tests=REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Robert Elz writes: > It prohibits some odd-ball techniques You are talking about a draft disobeyed by MOST DNS SERVERS ON THE NET. Please drop the loaded terminology. > "Violating" 2119 is a nonsense concept. RFC 2119, section 6: ``Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability.'' Contrary to your claims, these are not mere ``recommendations.'' This draft claims to be following RFC 2119, but blatantly violates RFC 2119, by trying to impose BIND 9's private decisions on everyone else. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 14 22:43:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14367 for ; Fri, 14 Feb 2003 22:43:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jtC6-0007UM-00 for namedroppers-data@psg.com; Fri, 14 Feb 2003 19:40:50 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #1) id 18jtC4-0007Tx-00 for namedroppers@ops.ietf.org; Fri, 14 Feb 2003 19:40:48 -0800 Received: (qmail 84062 invoked by uid 1016); 15 Feb 2003 03:41:14 -0000 Date: 15 Feb 2003 03:41:14 -0000 Message-ID: <20030215034114.84061.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: axfr-clarify's fraudulent claims of consensus References: <200302142024.h1EKOkS10983@guava.araneus.fi> <200302150157.h1F1vXw11389@guava.araneus.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Andreas Gustafsson writes: > To both me and the BIND 9 team, it was the obvious design, and the > BIND 8 behavior was an obvious implementation bug. To me, the djbdns cache structure is the obvious design, and BIND's continuing tree-related cache performance problems---all of which are visible to clients on the wire---are obvious implementation bugs. Do you think I should write drafts specifying my cache structure, falsely label those drafts as ``clarifications,'' and pay a bunch of people to push those drafts through the IETF standardization process? ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 14 23:37:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15123 for ; Fri, 14 Feb 2003 23:36:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jtx3-000Aea-00 for namedroppers-data@psg.com; Fri, 14 Feb 2003 20:29:21 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #1) id 18jtx1-000AeN-00 for namedroppers@ops.ietf.org; Fri, 14 Feb 2003 20:29:19 -0800 Received: (qmail 95102 invoked by uid 1016); 15 Feb 2003 04:29:44 -0000 Date: 15 Feb 2003 04:29:44 -0000 Message-ID: <20030215042944.95101.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: axfr-clarify's fraudulent claims of consensus References: <200302101659.LAA15654@ietf.org> <20030214103228.71052.qmail@cr.yp.to> <20030214135155.GA8342@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_05_08 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk bert hubert writes: > Much of your criticism boils down to the fact that you do not have a > zone concept and do not want to have one, where 1034 and 1035 simply > ooze with zone definitions and they are clearly part of the DNS philosophy. It's amazing how many errors you can pack into one paragraph. Facts: * My software has zones. It simplifies them for the user, by taking advantage of the RFC 1034 database-consistency requirements. * The relevant difference between my software and BIND 9 is that, when my software sees some of the RFC-1034-violating zones allowed by BIND 9, it boils them down to the RFC-1034-compliant parts. * BIND 8 does this to some extent too. It would sound pretty stupid of you to claim that BIND 8 doesn't ``have a zone concept,'' don't you think? * The BIND company's ``AXFR clarifications'' try to eliminate the RFC 1034 database-consistency requirements, allowing data for the same class+name+type to vary across zones, contrary to RFC 1034, sections 4.2.1 and 4.2.2. Furthermore, this zone mismanagement is only one of many problems with axfr-clarify. If you decided to imitate BIND 9's database format in your software, feel free---but stop trying to force me to do the same thing. It isn't what my users want, and it's not necessary for interoperability. [ removing duplicates ] > Yes, you could build sophisticated hashes & stuff Learn to program: ``sort -u''. As for your suggestion to shift this programming burden to the server: You aren't thinking straight. There will be BIND 8 servers for the foreseeable future, so you'll have to continue removing duplicates for the foreseeable future. You'll be imposing a burden on servers without removing it from clients. Silly. > I do like to have the ability to add TSIGs to an AXFR in the additional > section, even if that potentially breaks older remotes. Again, you aren't thinking straight. Servers don't randomly use TSIG; they use it _upon request_. Random use of TSIG has no benefits; it's a pointless incompatibility, and there's no reason to allow it. (Besides, IPSEC does a better job than TSIG.) ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Feb 15 01:16:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16596 for ; Sat, 15 Feb 2003 01:16:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jvY5-000I9k-00 for namedroppers-data@psg.com; Fri, 14 Feb 2003 22:11:41 -0800 Received: from [2001:470:1f00:ffff::5a1] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 18jvY0-000I6K-00 for namedroppers@ops.ietf.org; Fri, 14 Feb 2003 22:11:37 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h1F6Akd6028212; Sat, 15 Feb 2003 17:10:46 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200302150610.h1F6Akd6028212@drugs.dv.isc.org> To: "D. J. Bernstein" Cc: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: axfr-clarify's fraudulent claims of consensus In-reply-to: Your message of "15 Feb 2003 04:29:44 -0000." <20030215042944.95101.qmail@cr.yp.to> Date: Sat, 15 Feb 2003 17:10:46 +1100 X-Spam-Status: No, hits=1.2 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05, TO_BE_REMOVED_REPLY version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > bert hubert writes: > > Much of your criticism boils down to the fact that you do not have a > > zone concept and do not want to have one, where 1034 and 1035 simply > > ooze with zone definitions and they are clearly part of the DNS philosophy. > > It's amazing how many errors you can pack into one paragraph. Facts: > > * My software has zones. It simplifies them for the user, by taking > advantage of the RFC 1034 database-consistency requirements. Your software (and BIND 8) causes operational problems by not preserving zone contents. By incorrectly merging data from child zones you can prevent a master from sending correct data. You can also prevent slaves from sending the correct information. You require administators to worry about silly timing issues. You require administators to detect when the timing was wrong and update the serial numbers on zones just to get it retransfered with the original information because the server couldn't keep the zone contents seperate. Senario 1. Server 1 master for example.com and slave for division.example.com. division.example.com has been updated on it master to have new delegation information, the zone has not yet refreshed on server 1 for some reason. You receive email with the new delegation information. You update example.com adjusting its serial. You reload example.com. You expect the new delegation to be advertised in the outgoing zone transfer. This doesn't happen because the server messed with the zone contents. Senario 2. Server 1 master example.com Server 2 master division.example.com Server 3 slave example.com and division.example.com Server 4 slave example.com using server 3 as a master. Server 2 the delgation infomation for division.example.com is update and the parent zone is informed. Server 1 is updated to contain the new delegation information. Server 3 receives the updated parent zone before the updated child zone and notifies Server 4 which transfers example.com WITH THE OLD DELEGATION INFORMATION. Both masters were updated to have the new delegation information but it doesn't get distributed to all the servers. You want the IETF to believe that this is *correct* AXFR behaviour. This doesn't pass the giggle test. This is a common implemention error caused by trying to stuff all zones into a common database. BIND 4 got it wrong. BIND 8 got it wrong. You want us all to keep repeating this mistake. All that is being asked is that the data in AXFR is preserved so that it can be used as the data source of another AXFR and as a dataset to which IXFR deltas can be applied. If you want to merge the zones for non AXFR requests go ahead. In otherwords what is entered as the zone data is what is transmitted as the zone data. I was very much aware of this issue when I was working as a systems administrator for CSIRO years before I started working for ISC. We had to make regular sweeps of the the CSIRO.AU heirarchy to detect and clean up the errors caused by nameservers incorrectly merging zone contents. I got very tired of having to explain to all of the different system admins what the problem was and how to "fix it" by incrementing the serial number and getting the zone re-transfered. Mark > * The relevant difference between my software and BIND 9 is that, > when my software sees some of the RFC-1034-violating zones allowed > by BIND 9, it boils them down to the RFC-1034-compliant parts. > > * BIND 8 does this to some extent too. It would sound pretty stupid > of you to claim that BIND 8 doesn't ``have a zone concept,'' don't > you think? > > * The BIND company's ``AXFR clarifications'' try to eliminate the > RFC 1034 database-consistency requirements, allowing data for the > same class+name+type to vary across zones, contrary to RFC 1034, > sections 4.2.1 and 4.2.2. > > Furthermore, this zone mismanagement is only one of many problems with > axfr-clarify. > > If you decided to imitate BIND 9's database format in your software, > feel free---but stop trying to force me to do the same thing. It isn't > what my users want, and it's not necessary for interoperability. > > [ removing duplicates ] > > Yes, you could build sophisticated hashes & stuff > > Learn to program: ``sort -u''. > > As for your suggestion to shift this programming burden to the server: > You aren't thinking straight. There will be BIND 8 servers for the > foreseeable future, so you'll have to continue removing duplicates for > the foreseeable future. You'll be imposing a burden on servers without > removing it from clients. Silly. > > > I do like to have the ability to add TSIGs to an AXFR in the additional > > section, even if that potentially breaks older remotes. > > Again, you aren't thinking straight. Servers don't randomly use TSIG; > they use it _upon request_. Random use of TSIG has no benefits; it's a > pointless incompatibility, and there's no reason to allow it. (Besides, > IPSEC does a better job than TSIG.) > > ---D. J. Bernstein, Associate Professor, Department of Mathematics, > Statistics, and Computer Science, University of Illinois at Chicago > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Feb 15 02:35:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27591 for ; Sat, 15 Feb 2003 02:35:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jwoM-000Nqz-00 for namedroppers-data@psg.com; Fri, 14 Feb 2003 23:32:34 -0800 Received: from 12-234-22-23.client.attbi.com ([12.234.22.23]) by psg.com with esmtp (Exim 3.36 #1) id 18jwoJ-000Nqi-00 for namedroppers@ops.ietf.org; Fri, 14 Feb 2003 23:32:32 -0800 Received: from 12-234-22-23.client.attbi.com (6p7sspq1aoisz6hl@localhost [127.0.0.1]) by 12-234-22-23.client.attbi.com (8.12.6/8.12.6) with ESMTP id h1F7WDdw049857; Fri, 14 Feb 2003 23:32:13 -0800 (PST) (envelope-from DougB@DougBarton.net) Received: from localhost (doug@localhost) by 12-234-22-23.client.attbi.com (8.12.6/8.12.6/Submit) with ESMTP id h1F7WCaA049854; Fri, 14 Feb 2003 23:32:12 -0800 (PST) Date: Fri, 14 Feb 2003 23:32:12 -0800 (PST) From: Doug Barton To: bert hubert cc: mw-list-namedroppers@csi.hu, namedroppers@ops.ietf.org Subject: Re: axfr-clarify's fraudulent claims of consensus In-Reply-To: <20030214174056.GA17682@outpost.ds9a.nl> Message-ID: <20030214233143.L49637@12-234-22-23.pyvrag.nggov.pbz> References: <200302101659.LAA15654@ietf.org> <20030214103228.71052.qmail@cr.yp.to> <20030214135155.GA8342@outpost.ds9a.nl> <20030214170054.GA13587@thales.memphis.edu> <20030214174056.GA17682@outpost.ds9a.nl> Organization: Triborough Bridge & Tunnel Authority X-message-flag: Outlook -- Not just for spreading viruses anymore! MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 14 Feb 2003, bert hubert wrote: > Complaining that RFCs are internally inconsistent should not stand in the > way of progress. Isn't that why they need to be clarified? :) -- "The last time France wanted more evidence, it rolled right through Paris with a German flag." - David Letterman -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Feb 15 03:01:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28028 for ; Sat, 15 Feb 2003 03:01:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jxCC-000Pks-00 for namedroppers-data@psg.com; Fri, 14 Feb 2003 23:57:12 -0800 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 18jxBv-000PgV-00 for namedroppers@ops.ietf.org; Fri, 14 Feb 2003 23:57:00 -0800 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1F7uhq17525; Sat, 15 Feb 2003 14:56:44 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1F7tXb14122; Sat, 15 Feb 2003 14:55:34 +0700 (ICT) From: Robert Elz To: Peter Koch , Andreas Gustafsson cc: namedroppers@ops.ietf.org Subject: Re: axfr-clarify's fraudulent claims of consensus In-Reply-To: <200302141434.h1EEYtg02743@grimsvotn.TechFak.Uni-Bielefeld.DE> <200302142052.h1EKqq011016@guava.araneus.fi> References: <200302141434.h1EEYtg02743@grimsvotn.TechFak.Uni-Bielefeld.DE> <200302142052.h1EKqq011016@guava.araneus.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 15 Feb 2003 14:55:33 +0700 Message-ID: <14120.1045295733@munnari.OZ.AU> X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Fri, 14 Feb 2003 15:34:55 +0100 From: Peter Koch Message-ID: <200302141434.h1EEYtg02743@grimsvotn.TechFak.Uni-Bielefeld.DE> | Depends on how actively you'd like duplicates to be ignored. I'd read it | in a way that prohibits rejecting the incoming zone upon receipt of a | duplicate RR but also prohibits handing out these duplicate RRs (which | is in RFC 2181, section5, already) in responses. This is what it has to mean - what matters is the external behaviour of the server, not its internal implementation details. How the server chooses to go about ignoring the duplicates, if it receives any, is entirely up to it - the effect when viewed from outside has to be that the server gives the same responses whether it received an AXFR containing duplicate RRs or whether those had been pruned by the server. | Also, it allows the slave, if also acting as a master (*), | (*) kre: this is why primary/secondary are not sufficient terms in the | context of this document No ... you could write that as Also, it allows the secondary, if also acting as a primary, ... The problem here has always been that people's perception has always been that a server simply *is* a primary or a secondary for a zone (largely related to bind4's use of "primary" or "secondary" in its named.boot file). But that's nonsense - the terms make sense only when applied to a particular AXFR (and now IXFR) transaction, and only ever did. BIND8 (and 9) use the words "master" and "slave" in their named.conf files in exactly the way BIND4 used "primary" and "secondary", so it is likely that people (if not educated otherwise) will start to regard a server as a "master" for a zone, or as a "slave" for a zone, which would also be wrong. The BIND config file would probablyt be better if it were using terms like "load from file" or "load via AXFR" (or "load preferring IXFR") to describe what it has traditionally used the terms primary/master or secondary/slave to accomplish - what it is indicating is how this server should fetch the zone, which relates to its role in at most one AXFR. Unless prohibited by access controls, any server can be a primary for an AXFR request, however it fetched the zone file. Andreas Gustafsson said in <200302142052.h1EKqq011016@guava.araneus.fi>: | Robert Elz writes: | > That related to some of the language in the draft I believe (I | > was there, and I think was one of those who supported this | > position). | Hmm, this seems a bit different from Randy's recollection. But anyway... It is always hard in a brief WG discussion, especially one that takes only minutes (if that), and relates to a comment from the floor, to really be sure what was intended is the way it was interpreted. All I can say for sure is that I thought that the point related to this (essentially bind inspired) use of master/slave (etc) (if you read 1034/5 you won't find the term "slave" anywhere - and "master" is mostly used to refer to the file format, though there are a couple of what I regard as "slips of the pen" ...) It is entirely possible that Randy interpreted the comment differently. | These terms were defined in RFC1996 and are also used in RFC2136 [...] Yes, I know. If you query Paul about this, I'm sure he'll confirm that he and I have been having a running battle about this ever since that time (not frequently -- just whenever the topic arises). When he first proposed this new terminology I hadn't really thought through the arguments, and it sounded like a good idea. That didn't last very long... | I don't recall seeing any specific suggestions for changes, and I did | not attend the Yokohama meeting. Could you please them to me or | namedroppers? There were no specific changes requested. This isn't important enough to bother with. As you point out, this new terminology exists in (a few) other RFCs now, so it is no longer possible to be consistent with everything out there (though I'd much prefer 1034/5 terminology be used than 1996). If there's one thing I'd most like changed in this area, it would be that you expunge all use of the term "primary master" which is utter nonsense. The definition in 1996 is gibberish, it claims "There is by definition only one primary master server per zone", while actually defining it to mean "master server at the root of the zone transfer dependency graph" of which there can easily be many (there can be several independent zone transfer dependency graphs for the same zone - the master file can be created independently at different servers, and transferred from them). Doing things this way makes Dynamic Update difficult (or impossible perhaps) but dynamic update isn't required, it is an option that zones can choose not to use. Nothing in 1996 nor in axfr-clarify depends upon there being one unique magic server for a zone. (The SOA.MNAME field does of course, but aside from the use imposed upon it by dynamic update, that's a useless field, and there doesn't need to be a term (aside from SOA.MNAME) to refer to the domain name it references). But I'm not about to request even a delay in the processing of this doc in order to worry about meaningless differences of opinion about irrelevant terminology. If there were to be a reason for you to send in a new draft for other purposes, then by all means, fix this too if you feel inclined. Otherwise, it really doesn't matter - I'll try again with the next draft that uses this terminology... 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. archive: From owner-namedroppers@ops.ietf.org Sat Feb 15 03:24:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28420 for ; Sat, 15 Feb 2003 03:24:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jxaZ-0001Ij-00 for namedroppers-data@psg.com; Sat, 15 Feb 2003 00:22:23 -0800 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 18jxaX-0001IV-00 for namedroppers@ops.ietf.org; Sat, 15 Feb 2003 00:22:21 -0800 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1F8MHq18608; Sat, 15 Feb 2003 15:22:18 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1F8Kkb14158; Sat, 15 Feb 2003 15:20:48 +0700 (ICT) From: Robert Elz To: Dean Anderson cc: Andreas Gustafsson , "D. J. Bernstein" , ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: axfr-clarify's fraudulent claims of consensus In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 15 Feb 2003 15:20:46 +0700 Message-ID: <14156.1045297246@munnari.OZ.AU> X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Fri, 14 Feb 2003 17:25:40 -0500 (EST) From: Dean Anderson Message-ID: | | On Fri, 14 Feb 2003, Andreas Gustafsson wrote: | > RFC1035 specifically suggests using separate data structures | > that ensure that no such mixing occurs: | | The key word is "suggests", which has the meaning... exactly what you think it does - but note, the suggestion relates to an implementation technique, which certainly isn't going to be required. Implementors are free to implement however they desire, as long as they achieve the objective. Now ask yourself why 1035 would bother even suggesting an implementation technique. Don't you think it entirely possible that it is because the requirement (that which was to be implemented) is so fundamental to the design of the DNS, that some kind of suggestion of how to actually comply with the design was worth making? Implementation methods are often "suggested" in circumstances like that. That is, when it seems plausible that implementors might miss an important point and just do it the "easy way", it is common for the spec to indicate how the implementation can achieve the desired result - this way implementors either just blindly copy the suggestion, or at least should think about why they're doing it a different way, and ask themselves if their results will be the same as the suggested method. | No. This isn't true either. If we clarify AXFR to standardize the | _assumptions_ identically and concretely made by many implementors over a | long period of time, I can absolutely guarantee to you that that will never happen. No-one is going to standardise a protocol that essentially says "send whatever data you feel like sending, and believe whatever the other end sends you without question" which is exactly what the early implementations did. When we standardise something, we want to first be as sure as we can be that the protocol is correct for its purpose. We aren't always very good at that, but that should certainly be a major aim - documenting something that doesn't work is a waste of everyone's time. AXFR as it has been commonly implemented simply doesn't work reliably. 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. archive: From owner-namedroppers@ops.ietf.org Sat Feb 15 03:47:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28935 for ; Sat, 15 Feb 2003 03:47:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jxsG-0002pu-00 for namedroppers-data@psg.com; Sat, 15 Feb 2003 00:40:40 -0800 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 18jxsD-0002pf-00 for namedroppers@ops.ietf.org; Sat, 15 Feb 2003 00:40:37 -0800 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1F8eTq19209; Sat, 15 Feb 2003 15:40:30 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1F8cjb14482; Sat, 15 Feb 2003 15:38:45 +0700 (ICT) From: Robert Elz To: "D. J. Bernstein" cc: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: axfr-clarify's fraudulent claims of consensus In-Reply-To: <20030215042944.95101.qmail@cr.yp.to> References: <20030215042944.95101.qmail@cr.yp.to> <200302101659.LAA15654@ietf.org> <20030214103228.71052.qmail@cr.yp.to> <20030214135155.GA8342@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Sat, 15 Feb 2003 15:38:45 +0700 Message-ID: <14480.1045298325@munnari.OZ.AU> X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA28935 Date: 15 Feb 2003 04:29:44 -0000 From: "D. J. Bernstein" Message-ID: <20030215042944.95101.qmail@cr.yp.to> | * The BIND company's ``AXFR clarifications'' try to eliminate the | RFC 1034 database-consistency requirements, allowing data for the | same class+name+type to vary across zones, contrary to RFC 1034, | sections 4.2.1 and 4.2.2. Most of your arguments aren't worth replying to. This one looks like it has merit on first glance. But when examined closely it doesn't. The database consistency requirements in 1034 *have* to be requirements imposed upon the operators of the DNS, not the software, as there is no mechanism in existence which allows the software to ensure this consistency. The issue here is "glue" records copied into a parent zone from a child. If the parent and child are in the same server, the software is able to ensure that the glue records in the parent are identical to what is in the child zone - that's what early BIND software did, and I am guessing that is what your server does. From a naďve point of view, this looks to be a good thing. On the other hand, if the parent and child are operating in different servers then there's nothing that causes the glue in the parent to be the same as the records in the child - I have long wished that there could be (by having the parent actually go query the child, repeatedly) but for scaling and other reasons, it simply wouldn't work. Now for your average query this turns out to not matter (which is how BIND got away with being broken for so long) - a query to a server that holds both zones will receive its answer using the data that is the child zone (the zone that actually holds the record in question, or the nearest parent of that) and so will (assuming the query requests it, one way or another) get the data (which is glue in the parent) from the child zone. A query addressed to a parent which doesn't also hold the child zone will get the glue as added in the parent zone, unaffected by whatever might be in the child. Well - most of the time. And this is where the problems arise, and why AXFR is relevant to all of this. If the server for only the parent did a zone transfer from the server that is also a server for the child zone, then (using the zone smashing style of earlier BIND) the transfer it gets contains the records from the child zone, instead of what was actually configured into the parent zone. On the other hand, a different server for the parent zone alone, which did its AXFR from a server that was configured with the parent zone data and had never seen the child zone (or is a server configured manually itself, with only the parent zone), would have only the configured glue. Now we have two servers for the parent only, giving out different answers, from the same zone, with the same serial number. That's simply unacceptable, and wrong, and always has been. Early BIND had even worse problems in this area, but they're not relevant here - except that I certainly hope that no-one is going to come out of the woodwork and say that because (10 years ago) 99% of the nameservers were running BIND4 that the DNS specs must be "clarified" to document the way that BIND4 worked ... which is the logical conclusion of some of the arguments that are being made here. Even ignoring any issues with doing incremental zone transfers, it is important that a resolver be able to pick any of several different servers for a zone, with confidence that it will receive the same answer (if it receives an answer at all). If the server selected also happens to be a server for a child zone that would eventually need to be queried anyway, that's fine, just avoids an extra query getting from parent to child. But with incremental zone transfer it is essential that there is a well defined version of what is the content of the zone, so that the clients of those protocols can sanely apply updates - most particularly when the server for the (incremental) transfer isn't one fixed system, but can be any of several others. That is, DNS database consistency is important, but (unless we were to ever create some other method of ensuring it) it is the operators who have to make it happen - DNS software, at least using the DNS protocols as defined, simply cannot, and more, must not, attempt to achieve this on the user's behalf - doing so causes worse problems that not. Tools to ensure that the parent domain has the correct glue, where glue is needed, and to keep that correctly up to date when the child zone makes changes would be a very worthwhile thing to create and make available. But they're not related to AXFR, which transfers one zone from one server to another, and must do that without causing the zone to change (perhaps as it is transferred along a chain of many servers). 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. archive: From owner-namedroppers@ops.ietf.org Sat Feb 15 04:20:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29153 for ; Sat, 15 Feb 2003 04:20:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jyQS-0004fu-00 for namedroppers-data@psg.com; Sat, 15 Feb 2003 01:16:00 -0800 Received: from pianosa.catch22.org ([64.81.48.19]) by psg.com with esmtp (Exim 3.36 #1) id 18jyQQ-0004fZ-00 for namedroppers@ops.ietf.org; Sat, 15 Feb 2003 01:15:58 -0800 Received: by pianosa.catch22.org (Postfix, from userid 1000) id E095D2B; Sat, 15 Feb 2003 09:15:54 +0000 (GMT) Date: Sat, 15 Feb 2003 03:15:54 -0600 From: David Terrell To: Aaron Swartz Cc: namedroppers@ops.ietf.org Subject: Re: objection to axfr-clarify Message-ID: <20030215091554.GA12192@pianosa.catch22.org> Reply-To: David Terrell References: <0C41331E-405E-11D7-9F22-0003936780B2@aaronsw.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0C41331E-405E-11D7-9F22-0003936780B2@aaronsw.com> User-Agent: Mutt/1.4i X-vi: Version 1.79 (10/23/96) The CSRG, University of California, Berkeley. X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 3:12AM up 36 days, 5:35, 23 users, load averages: 0.31, 0.29, 0.27 X-Spam-Status: No, hits=-3.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MUTT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, Feb 14, 2003 at 02:51:10PM -0600, Aaron Swartz wrote: > This would appear to prohibit the behavior of djbdns, which makes no > distinction between AXFR data for one zone and another. Adding such a > distinction is not necessary, and would make the software much more > complicated and harder to use. Server A loads a.b.c.test from disk. Server B loads b.c.test from disk. Server C axfr slaves a.b.c.test and b.c.test from a and b, respectively. Server D axfr slaves b.c.test from C. In your world, server D will have stale versions of *.a.b.c.test data any time a has been updated more recently than b. That's an interoperability failure, or in the words of one local critic, "an AXFR disaster". -- David Terrell | Step 1: "configure one system using your GUI" dbt@meat.net | Step 2: "now configure 1000 more" Nebcorp Prime Minister | - Casper H.S. Dik http://wwn.nebcorp.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. archive: From owner-namedroppers@ops.ietf.org Sat Feb 15 06:15:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00728 for ; Sat, 15 Feb 2003 06:15:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18k0CD-000AYH-00 for namedroppers-data@psg.com; Sat, 15 Feb 2003 03:09:25 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #1) id 18k0CB-000AY5-00 for namedroppers@ops.ietf.org; Sat, 15 Feb 2003 03:09:23 -0800 Received: (qmail 67447 invoked by uid 1016); 15 Feb 2003 11:09:46 -0000 Date: 15 Feb 2003 11:09:46 -0000 Message-ID: <20030215110946.67446.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: axfr-clarify's fraudulent claims of consensus References: <20030215042944.95101.qmail@cr.yp.to> <200302150610.h1F6Akd6028212@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-0.2 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_03_05 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mark.Andrews@isc.org writes: > Server 1 master for example.com and slave for division.example.com. [ and division.example.com decides to change its NS records: ] > You receive email with the new delegation information. You update > example.com Your hypothetical scenario breaks down here, for two reasons: (1) That configuration violates RFC 1034. (2) My software doesn't allow that configuration. Consequently, your claims of failure have no connection to reality. The situation simply doesn't occur. (What actually happens is that the NS record is updated when the child zone is transferred, as it should be.) In more detail: (1) RFC 1034, sections 4.2.1 and 4.2.2, make crystal clear that the NS record for division.example.com is supposed to be exactly the same in the example.com zone and the division.example.com zone. (2) When my software is handling both zones, it enforces the RFC 1034 requirement, by unifying the data for the two zones. There isn't a division.example.com NS record in the example.com zone separate from the same NS record in the division.example.com zone. I realize that, in BIND, there are two independent disk files with the two zones, so it's possible to separately change the NS record in the division.com zone. But that violates RFC 1034, and my software simply doesn't allow it. You're going to have to learn that the protocol is not defined by BIND's implementation decisions. If you persist in viewing everything through the language of BIND's configuration files, you're going to keep making false claims about the behavior of other DNS software. I strongly recommend that you read the specifications of the standard DNS protocol, specifically RFC 1034 and RFC 1035, before you comment further. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Feb 15 07:46:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01858 for ; Sat, 15 Feb 2003 07:46:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18k1bw-000G6f-00 for namedroppers-data@psg.com; Sat, 15 Feb 2003 04:40:04 -0800 Received: from [2001:470:1f00:ffff::5a1] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 18k1bt-000G3W-00 for namedroppers@ops.ietf.org; Sat, 15 Feb 2003 04:40:01 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h1FCdCd6028798; Sat, 15 Feb 2003 23:39:12 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200302151239.h1FCdCd6028798@drugs.dv.isc.org> To: "D. J. Bernstein" Cc: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: axfr-clarify's fraudulent claims of consensus In-reply-to: Your message of "15 Feb 2003 11:09:46 -0000." <20030215110946.67446.qmail@cr.yp.to> Date: Sat, 15 Feb 2003 23:39:12 +1100 X-Spam-Status: No, hits=1.2 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05, TO_BE_REMOVED_REPLY version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Mark.Andrews@isc.org writes: > > Server 1 master for example.com and slave for division.example.com. > [ and division.example.com decides to change its NS records: ] > > You receive email with the new delegation information. You update > > example.com > > Your hypothetical scenario breaks down here, for two reasons: > > (1) That configuration violates RFC 1034. It does not. > (2) My software doesn't allow that configuration. Well as we keep pointing out your software is BROKEN. > Consequently, your claims of failure have no connection to reality. The > situation simply doesn't occur. (What actually happens is that the NS > record is updated when the child zone is transferred, as it should be.) > > In more detail: > > (1) RFC 1034, sections 4.2.1 and 4.2.2, make crystal clear that the > NS record for division.example.com is supposed to be exactly the > same in the example.com zone and the division.example.com zone. But the parent version *IS* a exact copy in both of the senarios given. Just because it is not what is in the *old* copy of the child zone doesn't make it not a exact copy. > (2) When my software is handling both zones, it enforces the RFC 1034 > requirement, by unifying the data for the two zones. There isn't > a division.example.com NS record in the example.com zone separate > from the same NS record in the division.example.com zone. Which is a problem in your software as it is a problem in BIND4 and BIND 8. > I realize that, in BIND, there are two independent disk files with the > two zones, so it's possible to separately change the NS record in the > division.com zone. But that violates RFC 1034, and my software simply > doesn't allow it. > > implementation decisions. If you persist in viewing everything through > the language of BIND's configuration files, you're going to keep making > false claims about the behavior of other DNS software. I strongly > recommend that you read the specifications of the standard DNS protocol, > specifically RFC 1034 and RFC 1035, before you comment further. > > ---D. J. Bernstein, Associate Professor, Department of Mathematics, > Statistics, and Computer Science, University of Illinois at Chicago > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 17 01:11:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05647 for ; Mon, 17 Feb 2003 01:11:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18keGJ-000CEp-00 for namedroppers-data@psg.com; Sun, 16 Feb 2003 21:56:19 -0800 Received: from one.elistx.com ([209.116.252.130]) by psg.com with esmtp (Exim 3.36 #1) id 18keGH-000CEc-00 for namedroppers@ops.ietf.org; Sun, 16 Feb 2003 21:56:17 -0800 Received: from ogud.com (pcp816081pcs.nrockv01.md.comcast.net [68.49.60.118]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HAF00G56V6JWP@eListX.com> for namedroppers@ops.ietf.org; Mon, 17 Feb 2003 00:56:43 -0500 (EST) Received: from ENGILL.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.3/8.12.3) with ESMTP id h1H5s1ts020269 for ; Mon, 17 Feb 2003 00:54:01 -0500 (EST envelope-from ogud@ogud.com) Date: Mon, 17 Feb 2003 00:55:32 -0500 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: IETF-56 agenda X-Sender: (Unverified) To: namedroppers@ops.ietf.org Message-id: <5.1.1.6.2.20030217005401.02394950@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=us-ascii X-Spam-Status: No, hits=3.1 required=5.0 tests=RCVD_IN_RFCI,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: *** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk We (currently) have 2.5 hours Please send in agenda requests. 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. archive: From owner-namedroppers@ops.ietf.org Mon Feb 17 04:05:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18122 for ; Mon, 17 Feb 2003 04:05:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kh0r-000L3A-00 for namedroppers-data@psg.com; Mon, 17 Feb 2003 00:52:33 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #1) id 18kh0n-000L2y-00 for namedroppers@ops.ietf.org; Mon, 17 Feb 2003 00:52:30 -0800 Received: from ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.5/8.11.6) with ESMTP id h1H8qRAq012109; Mon, 17 Feb 2003 09:52:27 +0100 Message-Id: <200302170852.h1H8qRAq012109@birch.ripe.net> To: Rob Austein cc: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-dnssec-intro-05.txt In-Reply-To: Message from Rob Austein of "Fri, 14 Feb 2003 20:48:07 EST." <20030215014807.C29F218EC@thrintun.hactrn.net> Date: Mon, 17 Feb 2003 09:52:27 +0100 From: Olaf Kolkman X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk * http://www.hactrn.net/ietf/dns/dnssec-editors/draft-ietf-dnsext-dnssec-int * ro-05.txt I cannot get it from there.... (source address ik.dacht.net 193.0.3.28 ) --Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 17 09:13:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22637 for ; Mon, 17 Feb 2003 09:13:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kloA-0002Gf-00 for namedroppers-data@psg.com; Mon, 17 Feb 2003 05:59:46 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 18klo8-0002GT-00 for namedroppers@ops.ietf.org; Mon, 17 Feb 2003 05:59:44 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com) by rip.psg.com with esmtp (Exim 4.12) id 18klo8-000AAF-00 for namedroppers@ops.ietf.org; Mon, 17 Feb 2003 05:59:44 -0800 In-Reply-To: <200302151239.h1FCdCd6028798@drugs.dv.isc.org> Message-ID: References: <200302151239.h1FCdCd6028798@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Mon, 17 Feb 2003 13:48:23 +0000 (GMT) From: Lloyd Wood To: Mark.Andrews@isc.org cc: "D. J. Bernstein" , "" , "" , "" Subject: Re: axfr-clarify's fraudulent claims of consensus X-Spam-Status: No, hits=-3.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,RESENT_TO, SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] On Sat, 15 Feb 2003 Mark.Andrews@isc.org wrote: > > (2) My software doesn't allow that configuration. > > Well as we keep pointing out your software is BROKEN. Saying it's broken implies the act of breakage. At what point was the software NOT broken? L. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 17 13:09:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27504 for ; Mon, 17 Feb 2003 13:09:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kpZe-0007jz-00 for namedroppers-data@psg.com; Mon, 17 Feb 2003 10:01:02 -0800 Received: from fxodpr13.extra.daimlerchrysler.com ([129.9.82.74]) by psg.com with esmtp (Exim 3.36 #1) id 18kpZZ-0007jm-00 for namedroppers@ops.ietf.org; Mon, 17 Feb 2003 10:00:57 -0800 Received: (from uucp@localhost) by fxodpr13.extra.daimlerchrysler.com (8.11.4/8.9.0) id h1HI0u923858 for ; Mon, 17 Feb 2003 13:00:56 -0500 (EST) Received: from unknown(53.231.71.237) by fxodpr13.extra.daimlerchrysler.com via csmap (V6.0) id srcAAAjdaiMU; Mon, 17 Feb 03 13:00:56 -0500 Received: from odmrspr2-hme0.oddc.chrysler.com ([53.231.2.113]) by odconpr2-hme0.oddc.chrysler.com (Mail-Gear 2.0.0 bld 58) with SMTP id M2003021713005506642 for ; Mon, 17 Feb 2003 13:00:55 -0500 Received: from daimlerchrysler.com ([53.231.58.84]) by odmrspr2-hme0.oddc.chrysler.com (8.12.7/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id h1HI0op7016723 for ; Mon, 17 Feb 2003 13:00:55 -0500 (EST) Message-ID: <3E51239D.8050002@daimlerchrysler.com> Date: Mon, 17 Feb 2003 13:02:05 -0500 From: Kevin Darcy User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: axfr-clarify's fraudulent claims of consensus References: <200302151239.h1FCdCd6028798@drugs.dv.isc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_01_02,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Lloyd Wood wrote: >[ post by non-subscriber. with the massive amount of spam, it is easy to miss > and therefore delete posts by non-subscribers. if you wish to regularly > post from an address that is not subscribed to this mailing list, send a > message to -owner@ops.ietf.org and ask to have the alternate > address added to the list of addresses from which submissions are > automatically accepted. ] > >On Sat, 15 Feb 2003 Mark.Andrews@isc.org wrote: > > > >>> (2) My software doesn't allow that configuration. >>> >>> >> Well as we keep pointing out your software is BROKEN. >> >> > >Saying it's broken implies the act of breakage. > >At what point was the software NOT broken? > "Broken" is a jargon term. In the context of software design, it denotes failure to conform to the relevant specifications. - 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. archive: From owner-namedroppers@ops.ietf.org Mon Feb 17 15:29:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00660 for ; Mon, 17 Feb 2003 15:29:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kri7-000CJU-00 for namedroppers-data@psg.com; Mon, 17 Feb 2003 12:17:55 -0800 Received: from [2001:470:1f00:ffff::5a1] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 18kri4-000CIO-00 for namedroppers@ops.ietf.org; Mon, 17 Feb 2003 12:17:52 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h1HKG4d6046986; Tue, 18 Feb 2003 07:16:08 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200302172016.h1HKG4d6046986@drugs.dv.isc.org> To: Lloyd Wood Cc: Mark_Andrews@isc.org, "D. J. Bernstein" , "" , "" , "" From: Mark.Andrews@isc.org Subject: Re: axfr-clarify's fraudulent claims of consensus In-reply-to: Your message of "Mon, 17 Feb 2003 13:48:23 -0000." Date: Tue, 18 Feb 2003 07:16:04 +1100 X-Spam-Status: No, hits=0.5 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > On Sat, 15 Feb 2003 Mark.Andrews@isc.org wrote: > > > > (2) My software doesn't allow that configuration. > > > > Well as we keep pointing out your software is BROKEN. > > Saying it's broken implies the act of breakage. > > At what point was the software NOT broken? In the original design specs. RFC 1034 and RFC 1035. If they had been followed then we wouldn't be havin this discussion. Mark > L. > > -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 17 15:36:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00847 for ; Mon, 17 Feb 2003 15:36:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18krsV-000Cio-00 for namedroppers-data@psg.com; Mon, 17 Feb 2003 12:28:39 -0800 Received: from thales.memphis.edu ([141.225.37.221]) by psg.com with smtp (Exim 3.36 #1) id 18krsS-000CiC-00 for namedroppers@ops.ietf.org; Mon, 17 Feb 2003 12:28:36 -0800 Received: (qmail 17372 invoked by uid 500); 17 Feb 2003 20:28:33 -0000 From: mw-list-namedroppers@csi.hu Date: Mon, 17 Feb 2003 14:28:33 -0600 To: Name Droppers Subject: Re: axfr-clarify's fraudulent claims of consensus Message-ID: <20030217202833.GA16887@thales.memphis.edu> References: <20030215042944.95101.qmail@cr.yp.to> <200302150610.h1F6Akd6028212@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200302150610.h1F6Akd6028212@drugs.dv.isc.org> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sat, Feb 15, 2003 at 05:10:46PM +1100, Mark.Andrews@isc.org wrote: > Your software (and BIND 8) causes operational problems by not > preserving zone contents. [...] > Senario 1. In order to understand your claim about the operational problems while using djbdns, could you tell us how Scenario 1 is accomplished with tinydns/axfrdns? Could you give us a URL pointing at a webpage that contains the output of your experiments? > You update example.com adjusting > its serial. In particular, could you tell us what is the relevance of the serial number to tinydns's update procedures? > Senario 2. [...] > This is a common implemention error caused by trying to > stuff all zones into a common database. BIND 4 got it > wrong. BIND 8 got it wrong. > > You want us all to keep repeating this mistake. But I thought djbdns did _not_ get it wrong. Or if you think it did, could you show us the experiment that verifies the claim, that is, it accomplishes Scenario 2 with tinydns/axfrdns servers? Mate Mate Wierdl | Dept. of Math. Sciences | University of Memphis -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 17 15:52:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01180 for ; Mon, 17 Feb 2003 15:52:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ks7I-000DI9-00 for namedroppers-data@psg.com; Mon, 17 Feb 2003 12:43:56 -0800 Received: from thales.memphis.edu ([141.225.37.221]) by psg.com with smtp (Exim 3.36 #1) id 18ks7F-000DH5-00 for namedroppers@ops.ietf.org; Mon, 17 Feb 2003 12:43:53 -0800 Received: (qmail 17465 invoked by uid 500); 17 Feb 2003 20:43:52 -0000 From: mw-list-namedroppers@csi.hu Date: Mon, 17 Feb 2003 14:43:52 -0600 To: Name Droppers Subject: Re: axfr-clarify's fraudulent claims of consensus Message-ID: <20030217204351.GB16887@thales.memphis.edu> References: <20030215110946.67446.qmail@cr.yp.to> <200302151239.h1FCdCd6028798@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200302151239.h1FCdCd6028798@drugs.dv.isc.org> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sat, Feb 15, 2003 at 11:39:12PM +1100, Mark.Andrews@isc.org wrote: > Well as we keep pointing out your software is BROKEN. The problem is that I see this claim over and over, but I have not seen an actual experiment showing the broken behavior. Why is that? > > (2) When my software is handling both zones, it enforces the RFC 1034 > > requirement, by unifying the data for the two zones. There isn't > > a division.example.com NS record in the example.com zone separate > > from the same NS record in the division.example.com zone. > > Which is a problem in your software as it is a problem in BIND4 > and BIND 8. Here is how the above sounds --- Software S enforces a certain rfc 1034 behavior. --- Then the software has a problem. Is this logic intentional? --- Mate Wierdl | Dept. of Math. Sciences | University of Memphis -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 17 16:42:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02110 for ; Mon, 17 Feb 2003 16:42:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ksyj-000FJy-00 for namedroppers-data@psg.com; Mon, 17 Feb 2003 13:39:09 -0800 Received: from fxodpr13.extra.daimlerchrysler.com ([129.9.82.74]) by psg.com with esmtp (Exim 3.36 #1) id 18ksyg-000FJe-00 for namedroppers@ops.ietf.org; Mon, 17 Feb 2003 13:39:06 -0800 Received: (from uucp@localhost) by fxodpr13.extra.daimlerchrysler.com (8.11.4/8.9.0) id h1HLd5B16040 for ; Mon, 17 Feb 2003 16:39:05 -0500 (EST) Received: from unknown(53.231.71.237) by fxodpr13.extra.daimlerchrysler.com via csmap (V6.0) id srcAAAVMa4uF; Mon, 17 Feb 03 16:39:05 -0500 Received: from odmrspr2-hme0.oddc.chrysler.com ([53.231.2.113]) by odconpr2-hme0.oddc.chrysler.com (Mail-Gear 2.0.0 bld 58) with SMTP id M2003021716390422771 for ; Mon, 17 Feb 2003 16:39:04 -0500 Received: from daimlerchrysler.com ([53.231.58.174]) by odmrspr2-hme0.oddc.chrysler.com (8.12.7/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id h1HLd2p7011535 for ; Mon, 17 Feb 2003 16:39:04 -0500 (EST) Message-ID: <3E5156B7.3060508@daimlerchrysler.com> Date: Mon, 17 Feb 2003 16:40:07 -0500 From: Kevin Darcy User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Name Droppers Subject: Re: axfr-clarify's fraudulent claims of consensus References: <20030215110946.67446.qmail@cr.yp.to> <200302151239.h1FCdCd6028798@drugs.dv.isc.org> <20030217204351.GB16887@thales.memphis.edu> In-Reply-To: <20030217204351.GB16887@thales.memphis.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit mw-list-namedroppers@csi.hu wrote: >On Sat, Feb 15, 2003 at 11:39:12PM +1100, Mark.Andrews@isc.org wrote: > > > >>> (2) When my software is handling both zones, it enforces the RFC 1034 >>> requirement, by unifying the data for the two zones. There isn't >>> a division.example.com NS record in the example.com zone separate >>> from the same NS record in the division.example.com zone. >>> >>> >> Which is a problem in your software as it is a problem in BIND4 >> and BIND 8. >> >> > >Here is how the above sounds > >--- Software S enforces a certain rfc 1034 behavior. > >--- Then the software has a problem. > >Is this logic intentional? > False syllogism. RFC 1034 requires matching NS record sets in the parent and the child, but this cannot be *guaranteed* (even if administrators were perfect, there can be propagation delays when the record sets are changed). BIND 9 recognizes the possibility of a mismatch and deals with it reasonably (IMO) by respecting the disparity between the record sets. djbdns's approach, on the other hand, is to shut its eyes, put its fingers in its ears, and scream "la! la! la! this can't be happening! la! la! la!" and generate problematic zone transfers. Behold what happens when protocol implementation is left in the hands of mathematicians... The appropriate pseudo-syllogism, if any, is: Software D assumes that a particular RFC 1034 requirement R is always met R is sometimes not met => Software D's assumption is sometimes false Corollary: as is often the case, when an algorithm makes a false assumption, it generates incorrect results. Such is the case with Software D in those instances when its assumption about requirement R does not hold true. - 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. archive: From owner-namedroppers@ops.ietf.org Mon Feb 17 18:40:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04088 for ; Mon, 17 Feb 2003 18:40:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kukv-000JlU-00 for namedroppers-data@psg.com; Mon, 17 Feb 2003 15:33:01 -0800 Received: from thales.memphis.edu ([141.225.37.221]) by psg.com with smtp (Exim 3.36 #1) id 18kukt-000JlI-00 for namedroppers@ops.ietf.org; Mon, 17 Feb 2003 15:32:59 -0800 Received: (qmail 18956 invoked by uid 500); 17 Feb 2003 23:32:58 -0000 From: mw-list-namedroppers@csi.hu Date: Mon, 17 Feb 2003 17:32:58 -0600 To: Name Droppers Subject: Re: axfr-clarify's fraudulent claims of consensus Message-ID: <20030217233257.GA18427@thales.memphis.edu> References: <20030215110946.67446.qmail@cr.yp.to> <200302151239.h1FCdCd6028798@drugs.dv.isc.org> <20030217204351.GB16887@thales.memphis.edu> <3E5156B7.3060508@daimlerchrysler.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E5156B7.3060508@daimlerchrysler.com> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, Feb 17, 2003 at 04:40:07PM -0500, Kevin Darcy wrote: > mw-list-namedroppers@csi.hu wrote: > > >On Sat, Feb 15, 2003 at 11:39:12PM +1100, Mark.Andrews@isc.org wrote: > > > > > > > >>> (2) When my software is handling both zones, it enforces the RFC 1034 > >>> requirement, by unifying the data for the two zones. There isn't > >>> a division.example.com NS record in the example.com zone separate > >>> from the same NS record in the division.example.com zone. > >>> > >>> > >> Which is a problem in your software as it is a problem in BIND4 > >> and BIND 8. > >> > >> > > > >Here is how the above sounds > > > >--- Software S enforces a certain rfc 1034 behavior. > > > >--- Then the software has a problem. > > > >Is this logic intentional? > > > False syllogism. I do not get it: DJB says, his software meets some RFC 1034 requirement, and MA says then DJB's software has a problem. How can you read the above conversation differently? How can you read more into what Mark is saying, when it is not there? The fundamental problem is that I see all these claims, and no actual verifications. I start to think that none of the people criticizing djbdns ever run its servers and/or used its clients. In case you think this is irrelevant: people keep dismissing proposals and criticisms by saying it is just relevant to the single broken implementation by a mathematician. How can this be acceptable when it comes to creating rfc's? Is this done in the users' future and present best interest? Is this done in the interest of objectivity and coherence? > RFC 1034 requires matching NS record sets in the parent > and the child, but this cannot be *guaranteed* (even if administrators > were perfect, there can be propagation delays when the record sets are > changed). BIND 9 recognizes the possibility of a mismatch and deals with > it reasonably (IMO) by respecting the disparity between the record sets. > djbdns's approach, on the other hand, is to shut its eyes, put its > fingers in its ears, and scream "la! la! la! this can't be happening! > la! la! la!" and generate problematic zone transfers. > Again, could you show me the actual experiment when either of Mark's two Scenarios happen with djbdns? This cannot be too difficult given the enormous brokenness of the software. Mate --- Mate Wierdl | Dept. of Math. Sciences | University of Memphis -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 17 18:42:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04113 for ; Mon, 17 Feb 2003 18:42:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kujn-000Jhi-00 for namedroppers-data@psg.com; Mon, 17 Feb 2003 15:31:51 -0800 Received: from [63.149.73.20] (helo=vorpal.notabug.com) by psg.com with smtp (Exim 3.36 #1) id 18kujk-000JhV-00 for namedroppers@ops.ietf.org; Mon, 17 Feb 2003 15:31:49 -0800 Received: (qmail 16634 invoked from network); 17 Feb 2003 23:31:46 -0000 Received: from 12-249-96-16.client.attbi.com (HELO aaronsw.com) (12.249.96.16) by 0 with SMTP; 17 Feb 2003 23:31:46 -0000 Date: Mon, 17 Feb 2003 17:31:51 -0600 Subject: Re: axfr-clarify's fraudulent claims of consensus Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: namedroppers@ops.ietf.org To: Kevin Darcy From: Aaron Swartz In-Reply-To: <3E4D7E0B.737F8706@daimlerchrysler.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kevin Darcy wrote: > the thousands of dollars we waste every year because of inefficient > zone transfers If you're serious, then you should switch to gzipped rsync immediately. I bet you'll save far more than you will with IXFR. I'm sure you can find someone who will set it up for you in return for thousands of dollars. -- Aaron Swartz [http://www.aaronsw.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. archive: From owner-namedroppers@ops.ietf.org Mon Feb 17 19:07:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04436 for ; Mon, 17 Feb 2003 19:07:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kvDT-000LAa-00 for namedroppers-data@psg.com; Mon, 17 Feb 2003 16:02:31 -0800 Received: from fxodpr13.extra.daimlerchrysler.com ([129.9.82.74]) by psg.com with esmtp (Exim 3.36 #1) id 18kvDR-000LAM-00 for namedroppers@ops.ietf.org; Mon, 17 Feb 2003 16:02:29 -0800 Received: (from uucp@localhost) by fxodpr13.extra.daimlerchrysler.com (8.11.4/8.9.0) id h1I02Sn11508 for ; Mon, 17 Feb 2003 19:02:28 -0500 (EST) Received: from unknown(53.231.71.237) by fxodpr13.extra.daimlerchrysler.com via csmap (V6.0) id srcAAAtaayEw; Mon, 17 Feb 03 19:02:28 -0500 Received: from odmrspr2-hme0.oddc.chrysler.com ([53.231.2.113]) by odconpr2-hme0.oddc.chrysler.com (Mail-Gear 2.0.0 bld 58) with SMTP id M2003021719022824325 for ; Mon, 17 Feb 2003 19:02:28 -0500 Received: from daimlerchrysler.com ([53.231.58.174]) by odmrspr2-hme0.oddc.chrysler.com (8.12.7/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id h1I02Rp7023263 for ; Mon, 17 Feb 2003 19:02:28 -0500 (EST) Message-ID: <3E517853.2060707@daimlerchrysler.com> Date: Mon, 17 Feb 2003 19:03:31 -0500 From: Kevin Darcy User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: axfr-clarify's fraudulent claims of consensus References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Aaron Swartz wrote: > Kevin Darcy wrote: > >> the thousands of dollars we waste every year because of inefficient >> zone transfers > > > If you're serious, then you should switch to gzipped rsync > immediately. I bet you'll save far more than you will with IXFR. I'm > sure you can find someone who will set it up for you in return for > thousands of dollars. If I were the conspiratorial sort, I'd probably start raving at this point about how "the DJB company" was forcing me to use gzip and/or rsync by making AXFR and IXFR incompatible with each other... But, fortunately, I'm _not_ the conspiratorial sort. I just want AXFR and IXFR to be compatible. And I don't think DJB's poor design decisions should stand in the way of that. - 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. archive: From owner-namedroppers@ops.ietf.org Mon Feb 17 19:26:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04691 for ; Mon, 17 Feb 2003 19:26:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kvYV-000M9v-00 for namedroppers-data@psg.com; Mon, 17 Feb 2003 16:24:15 -0800 Received: from fxshpr08.extra.daimlerchrysler.com ([129.9.80.165] helo=fxshpr06.extra.daimlerchrysler.com) by psg.com with esmtp (Exim 3.36 #1) id 18kvYS-000M9i-00 for namedroppers@ops.ietf.org; Mon, 17 Feb 2003 16:24:12 -0800 Received: (from uucp@localhost) by fxshpr06.extra.daimlerchrysler.com (8.11.4/8.9.0) id h1I0MYk13745 for ; Mon, 17 Feb 2003 19:22:34 -0500 (EST) Received: from nodnsquery(129.9.147.104) by fxshpr08.extra.daimlerchrysler.com via csmap (V6.0) id srcAAA9uaa2A; Mon, 17 Feb 03 19:22:34 -0500 Received: from odmrspr2-hme0.oddc.chrysler.com ([53.231.2.113]) by shconpr2-hme0.shdc.chrysler.com (Mail-Gear 2.0.0 bld 58) with SMTP id M2003021719241002282 for ; Mon, 17 Feb 2003 19:24:10 -0500 Received: from daimlerchrysler.com ([53.231.58.174]) by odmrspr2-hme0.oddc.chrysler.com (8.12.7/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id h1I0O9p7029466 for ; Mon, 17 Feb 2003 19:24:10 -0500 (EST) Message-ID: <3E517D6A.10304@daimlerchrysler.com> Date: Mon, 17 Feb 2003 19:25:14 -0500 From: Kevin Darcy User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Name Droppers Subject: Re: axfr-clarify's fraudulent claims of consensus References: <20030215110946.67446.qmail@cr.yp.to> <200302151239.h1FCdCd6028798@drugs.dv.isc.org> <20030217204351.GB16887@thales.memphis.edu> <3E5156B7.3060508@daimlerchrysler.com> <20030217233257.GA18427@thales.memphis.edu> In-Reply-To: <20030217233257.GA18427@thales.memphis.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_01_02,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit mw-list-namedroppers@csi.hu wrote: >On Mon, Feb 17, 2003 at 04:40:07PM -0500, Kevin Darcy wrote: > > >>mw-list-namedroppers@csi.hu wrote: >> >> >> >>>On Sat, Feb 15, 2003 at 11:39:12PM +1100, Mark.Andrews@isc.org wrote: >>> >>> >>> >>> >>> >>>>> (2) When my software is handling both zones, it enforces the RFC 1034 >>>>> requirement, by unifying the data for the two zones. There isn't >>>>> a division.example.com NS record in the example.com zone separate >>>>> from the same NS record in the division.example.com zone. >>>>> >>>>> >>>>> >>>>> >>>> Which is a problem in your software as it is a problem in BIND4 >>>> and BIND 8. >>>> >>>> >>>> >>>> >>>Here is how the above sounds >>> >>>--- Software S enforces a certain rfc 1034 behavior. >>> >>>--- Then the software has a problem. >>> >>>Is this logic intentional? >>> >>> >>> >>False syllogism. >> >> > >I do not get it: DJB says, his software meets some RFC 1034 >requirement, and MA says then DJB's software has a problem. How can >you read the above conversation differently? How can you read more >into what Mark is saying, when it is not there? > There's a big difference between a piece of software meeting a data-structure requirement, and a piece of software assuming that *every* administrator in the world *always* meets a particular *operational* requirement, and that all replication is instantaneous. Remember "liberal in what you accept, conservative in what you generate". It's like the difference between publishing a bus schedule, on the one hand, and, on the other, staking your life on the presence of a bus at a particular bus stop at a particular time. The former might be reasonable (if it's based on real-world data about how buses proceed through the relevant routes); the latter is totally foolish. >The fundamental problem is that I see all these claims, and no actual >verifications. I start to think that none of the people criticizing >djbdns ever run its servers and/or used its clients. > Well, I think that's mainly because the aberrant behavior of djbdns has been hashed out here many times previously, and most folks are sick and tired of hearing djb's convoluted rationalizations for it. >In case you think this is irrelevant: people keep dismissing proposals >and criticisms by saying it is just relevant to the single broken >implementation by a mathematician. How can this be acceptable when it >comes to creating rfc's? > The *proposal* is to clarify AXFR, and it is DJB that is "dismissing" it, mostly on the basis that he doesn't want to have to change his software to conform to the newly-clarified spec. As for my comment about mathematicians, sorry if you were offended, but the incredibly idealistic assumption embedded in djbdns struck me as being singularly representative of the "assume a perfect world" stereotype that mathematicians get plastered with regularly. I'll note that the "E" in IETF stands for "Engineering". Engineers have a slightly better reputation for dealing with real-world challenges. >Is this done in the users' future and >present best interest? > Yes. Thanks for asking. >Is this done in the interest of objectivity >and coherence? > Yes. Thanks for asking. - 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. archive: From owner-namedroppers@ops.ietf.org Mon Feb 17 21:38:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06993 for ; Mon, 17 Feb 2003 21:38:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kxXg-0001vt-00 for namedroppers-data@psg.com; Mon, 17 Feb 2003 18:31:32 -0800 Received: from tyo202.gate.nec.co.jp ([202.32.8.202]) by psg.com with esmtp (Exim 3.36 #1) id 18kxXc-0001uu-00 for namedroppers@ops.ietf.org; Mon, 17 Feb 2003 18:31:29 -0800 Received: from mailgate3.nec.co.jp ([10.7.69.194]) by TYO202.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id h1I2VPU26862; Tue, 18 Feb 2003 11:31:25 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate52.nec.co.jp [10.7.69.191]) by mailgate3.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id h1I2VOG05265; Tue, 18 Feb 2003 11:31:24 +0900 (JST) Received: from dns02.netlab.nec.co.jp (dns02.netlab.nec.co.jp [10.17.225.2]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id h1I2VOH04346; Tue, 18 Feb 2003 11:31:24 +0900 (JST) Received: from dns03.netlab.nec.co.jp (dns03.netlab.nec.co.jp [10.17.225.65]) by dns02.netlab.nec.co.jp (8.11.6/3.7W) with ESMTP id h1I2VNe02204; Tue, 18 Feb 2003 11:31:23 +0900 (JST) Received: from potsdam.lab5.netlab.nec.co.jp (potsdam.lab5.netlab.nec.co.jp [10.17.226.96]) by dns03.netlab.nec.co.jp (8.11.6/3.7W) with ESMTP id h1I2VNv13287; Tue, 18 Feb 2003 11:31:23 +0900 (JST) Received: from localhost (localhost.lab5.netlab.nec.co.jp [127.0.0.1]) by potsdam.lab5.netlab.nec.co.jp (8.9.3/3.7W20020312HK) with ESMTP id LAA24838; Tue, 18 Feb 2003 11:31:22 +0900 (JST) To: rdroms@cisco.com Cc: namedroppers@ops.ietf.org From: kitamura@da.jp.nec.com Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration In-Reply-To: <4.3.2.7.2.20030206113001.00b974e8@funnel.cisco.com> References: <5.1.1.6.2.20030204144231.01e22c70@localhost> <4.3.2.7.2.20030206113001.00b974e8@funnel.cisco.com> X-Mailer: Mew version 1.94.2 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20030218113122U.kitamura@netlab.nec.co.jp> Date: Tue, 18 Feb 2003 11:31:22 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 58 X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Thu, 06 Feb 2003 11:30:51 -0500 Message-ID: <4.3.2.7.2.20030206113001.00b974e8@funnel.cisco.com> > I do not support the publication of this specification on experimental > track, for the following reasons: > > What, exactly, is being standardized as an experimental protocol in > this document; why is the IETF publishing it? The detector function > is a set of heuristics which may be of use in detecting newly > connected nodes, but it's not a protocol. The detector<->registrar ^^^^^^^^^^^^^^ Please read the I-D carefully. Let me quote the beginning of the I-D. This document describes a scheme of "Domain Name Auto-Registration ^^^^^^^^ for Plugged-in IPv6 Nodes" mechanism that makes it possible to register both regular and inverse domain name information of plugged- in IPv6 nodes to DNS servers automatically. The document describes a scheme (not a protocol). Main goals of the document are: - to meet requirements to use logical names that are easy to remember to specify IPv6 nodes (even if they are just plugged-in). - to clarify problems that we meet when we apply the Dynamic Updates in the DNS [DYN-DNS] to automatic domain name information registration mechanisms. - to provide a scheme to solve above problems. - to provide a method to collect IPv6 address information that should be registered to DNS servers. (This will help administrators of DNS servers.) - ... This document is on experimental track (not standard track), and the document describes enough information for it. > communication is only described as an example in Appendix A. The > registrar then uses DDNS to change the information in DNS. The > registrar function is a set of rules for generating names for nodes > and for managing information about nodes. What is the protocol that > must be standardized for interoperability among different > implementations? Regards, Hiroshi -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 17 21:38:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07009 for ; Mon, 17 Feb 2003 21:38:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kxUb-0001kg-00 for namedroppers-data@psg.com; Mon, 17 Feb 2003 18:28:21 -0800 Received: from [2001:470:1f00:ffff::5a1] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 18kxUX-0001jL-00 for namedroppers@ops.ietf.org; Mon, 17 Feb 2003 18:28:18 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h1I2RSd6053173; Tue, 18 Feb 2003 13:27:29 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200302180227.h1I2RSd6053173@drugs.dv.isc.org> To: mw-list-namedroppers@csi.hu Cc: Name Droppers cc: ietf@ietf.org, iesg@ietf.org From: Mark.Andrews@isc.org Subject: Re: axfr-clarify's fraudulent claims of consensus In-reply-to: Your message of "Mon, 17 Feb 2003 14:28:33 MDT." <20030217202833.GA16887@thales.memphis.edu> Date: Tue, 18 Feb 2003 13:27:28 +1100 X-Spam-Status: No, hits=0.6 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02, TO_BE_REMOVED_REPLY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > On Sat, Feb 15, 2003 at 05:10:46PM +1100, Mark.Andrews@isc.org wrote: > > Your software (and BIND 8) causes operational problems by not > > preserving zone contents. > [...] > > Senario 1. > > In order to understand your claim about the operational problems while > using djbdns, could you tell us how Scenario 1 is accomplished with > tinydns/axfrdns? Could you give us a URL pointing at a webpage that > contains the output of your experiments? > > > You update example.com adjusting > > its serial. > > In particular, could you tell us what is the relevance of the serial > number to tinydns's update procedures? > > > > Senario 2. > > [...] > > > This is a common implemention error caused by trying to > > stuff all zones into a common database. BIND 4 got it > > wrong. BIND 8 got it wrong. > > > > You want us all to keep repeating this mistake. > > But I thought djbdns did _not_ get it wrong. Or if you think it did, > could you show us the experiment that verifies the claim, that is, it > accomplishes Scenario 2 with tinydns/axfrdns servers? > > Mate > > Mate Wierdl | Dept. of Math. Sciences | University of Memphis > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: It's easy enough to demonstate. The master server is 10.53.0.2. 10.53.0.1 is dbj's software. I used the FreeBSD port system to install it. djbdns-1.05_2 A collection of secure and reliable DNS tools tcpclient 10.53.0.2 53 axfr-get child.example.net zone.child.example.net zone.child.example.net.tmp tcpclient 10.53.0.2 53 axfr-get example.net zone.example.net zone.example.net.tmp sort -u zone.* > data make You will note that it actually *merges* the records. ns2.child.example.net doesn't exist due to a typo in child.example.net. I was taking Dan's word that it took the child data. Merges are just as bad as taking data just from the child zone. In both cases slaves off 10.53.0.1 will be left with data that was not in the original master files. I presume for a real world server that you would need to call tcpclient periodically and remake data if the zone files have changed. It looks like they axfr-get is designed to be called independently of the database make. I suspect no-one would run tinydns in the senarios described. It's designed for a collection of servers that all serve a identical set of zones from a single master. Trying to use it in any other configuration is just cumbersome. There really is no incoming zone maintanence. You have to roll your own from what I can see. axfr-get will check the serial but that is far short of full zone maintenance. axfr-get get need to be called with the right periodicity. Mark ; <<>> DiG 9.3.0s20021115 <<>> axfr child.example.net @10.53.0.2 ;; global options: printcmd child.example.net. 10 IN SOA . . 1 3600 1200 360000 10 child.example.net. 10 IN NS ns1.child.example.net. child.example.net. 10 IN NS ns2.child.example.net. ns1.child.example.net. 10 IN A 10.53.0.1 ns1.child.example.net. 10 IN A 10.53.0.2 child.example.net. 10 IN SOA . . 1 3600 1200 360000 10 ;; Query time: 43 msec ;; SERVER: 10.53.0.2#53(10.53.0.2) ;; WHEN: Tue Feb 18 11:50:46 2003 ;; XFR size: 7 records (messages 1) ; <<>> DiG 9.3.0s20021115 <<>> axfr child.example.net @10.53.0.1 ;; global options: printcmd child.example.net. 10 IN SOA . . 1 3600 1200 360000 10 child.example.net. 10 IN NS ns1.child.example.net. child.example.net. 10 IN NS ns2.child.example.net. ns1.child.example.net. 10 IN A 10.53.0.1 ns1.child.example.net. 10 IN A 10.53.0.2 ns2.child.example.net. 10 IN A 10.53.0.2 child.example.net. 10 IN SOA . . 1 3600 1200 360000 10 ;; Query time: 5 msec ;; SERVER: 10.53.0.1#53(10.53.0.1) ;; WHEN: Tue Feb 18 11:51:02 2003 ;; XFR size: 8 records (messages 7) ; <<>> DiG 9.3.0s20021115 <<>> axfr example.net @10.53.0.2 ;; global options: printcmd example.net. 10 IN SOA . . 1 3600 1200 360000 10 example.net. 10 IN NS ns1.example.net. example.net. 10 IN NS ns2.example.net. child.example.net. 10 IN NS ns1.child.example.net. child.example.net. 10 IN NS ns2.child.example.net. ns1.child.example.net. 10 IN A 10.53.0.1 ns2.child.example.net. 10 IN A 10.53.0.2 ns1.example.net. 10 IN A 10.53.0.1 ns2.example.net. 10 IN A 10.53.0.2 example.net. 10 IN SOA . . 1 3600 1200 360000 10 ;; Query time: 3 msec ;; SERVER: 10.53.0.2#53(10.53.0.2) ;; WHEN: Tue Feb 18 11:52:04 2003 ;; XFR size: 11 records (messages 1) ; <<>> DiG 9.3.0s20021115 <<>> axfr example.net @10.53.0.1 ;; global options: printcmd example.net. 10 IN SOA . . 1 3600 1200 360000 10 child.example.net. 10 IN NS ns1.child.example.net. child.example.net. 10 IN NS ns2.child.example.net. example.net. 10 IN NS ns1.example.net. example.net. 10 IN NS ns2.example.net. ns1.child.example.net. 10 IN A 10.53.0.1 ns1.child.example.net. 10 IN A 10.53.0.2 ns1.example.net. 10 IN A 10.53.0.1 ns2.child.example.net. 10 IN A 10.53.0.2 ns2.example.net. 10 IN A 10.53.0.2 example.net. 10 IN SOA . . 1 3600 1200 360000 10 ;; Query time: 5 msec ;; SERVER: 10.53.0.1#53(10.53.0.1) ;; WHEN: Tue Feb 18 11:51:30 2003 ;; XFR size: 12 records (messages 11) ; <<>> DiG 9.3.0s20021115 <<>> ns child.example.net @10.53.0.1 ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56624 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3 ;; QUESTION SECTION: ;child.example.net. IN NS ;; ANSWER SECTION: child.example.net. 10 IN NS ns1.child.example.net. child.example.net. 10 IN NS ns2.child.example.net. ;; ADDITIONAL SECTION: ns1.child.example.net. 10 IN A 10.53.0.1 ns1.child.example.net. 10 IN A 10.53.0.2 ns2.child.example.net. 10 IN A 10.53.0.2 ;; Query time: 1 msec ;; SERVER: 10.53.0.1#53(10.53.0.1) ;; WHEN: Tue Feb 18 12:11:45 2003 ;; MSG SIZE rcvd: 119 ; <<>> DiG 9.3.0s20021115 <<>> ns child.example.net @10.53.0.2 ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12751 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2 ;; QUESTION SECTION: ;child.example.net. IN NS ;; ANSWER SECTION: child.example.net. 10 IN NS ns2.child.example.net. child.example.net. 10 IN NS ns1.child.example.net. ;; ADDITIONAL SECTION: ns1.child.example.net. 10 IN A 10.53.0.1 ns1.child.example.net. 10 IN A 10.53.0.2 ;; Query time: 1 msec ;; SERVER: 10.53.0.2#53(10.53.0.2) ;; WHEN: Tue Feb 18 12:12:02 2003 ;; MSG SIZE rcvd: 103 -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 18 04:30:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23271 for ; Tue, 18 Feb 2003 04:30:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18l3uO-000MJq-00 for namedroppers-data@psg.com; Tue, 18 Feb 2003 01:19:24 -0800 Received: from nat.alvestrand.no ([217.13.28.204] helo=eikenes.alvestrand.no) by psg.com with esmtp (Exim 3.36 #1) id 18l3uM-000MJe-00 for namedroppers@ops.ietf.org; Tue, 18 Feb 2003 01:19:22 -0800 Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2E25262581; Tue, 18 Feb 2003 10:19:19 +0100 (CET) Date: Tue, 18 Feb 2003 10:19:19 +0100 From: Harald Tveit Alvestrand To: Dean Anderson , Valdis.Kletnieks@vt.edu Cc: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: A formality.... (Re: axfr-clarify's fraudulent claims of consensus) Message-ID: <332070000.1045559959@askvoll.hjemme.alvestrand.no> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On fredag, februar 14, 2003 17:57:45 -0500 Dean Anderson wrote: > As you note, they didn't conform to a BCP. There is no requirement (or > implication even) that one should conform to a Best Common Practice. > These serve to distribute helpful advice to the community and document > practices that have worked for others, in situations that may be > different. > > The AXFR issue is compliance with a required standard, and its definition. > Much more serious concerns and issues are at stake. Note: The IETF has never made *any* standard that the IETF required people to conform to, unless they wanted to truthfully claim conformance to that standard. At one point in time it made sense to say that "to be an Internet device, you have to conform to this set of standards"; currently, the ways in which IETF standards depend on each other are complex enough that this doesn't make much sense any more. As a result, the distinction between "Elective", "Recommended" and "Required" protocols has largely fallen into disuse; RFC 2400 was the last version of the Official Protocol Standards document that even bothered to list them - the current version is RFC 3300. At the time of RFC 2400, the set of Required standards were: -------- Internet Official Protocol Standards Req 2400 1 -------- Assigned Numbers Req 1700 2 -------- Host Requirements - Communications Req 1122 3 -------- Host Requirements - Applications Req 1123 3 IP Internet Protocol Req 791 5 -------- IP Subnet Extension Req 950 5 -------- IP Broadcast Datagrams Req 919 5 -------- IP Broadcast Datagrams with Subnets Req 922 5 ICMP Internet Control Message Protocol Req 792 5 Here is the status of the DNS standards in that document: DOMAIN Domain Name System Rec 1034,1035 13 DNS-MX Mail Routing and the Domain System Rec 974 14 axfr-clarify will have to enter the process as a Proposed Standard. Both Proposed Standards and BCPs are encouraging people to do things a certain way; if anything, I consider a BCP slightly more forceful. Harald Alvestrand -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 18 04:50:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23638 for ; Tue, 18 Feb 2003 04:50:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18l4Mk-000N44-00 for namedroppers-data@psg.com; Tue, 18 Feb 2003 01:48:42 -0800 Received: from [2001:6e0:206:1:250:daff:fe3d:1d6] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 3.36 #1) id 18l4Mh-000N3q-00 for namedroppers@ops.ietf.org; Tue, 18 Feb 2003 01:48:39 -0800 Received: from open.nlnetlabs.nl (localhost [IPv6:::1]) by open.nlnetlabs.nl (8.12.6/8.12.6) with ESMTP id h1I9map8047798; Tue, 18 Feb 2003 10:48:36 +0100 (CET) (envelope-from alexis@open.nlnetlabs.nl) Received: (from alexis@localhost) by open.nlnetlabs.nl (8.12.6/8.12.6/Submit) id h1I9maGm047797; Tue, 18 Feb 2003 10:48:36 +0100 (CET) Message-Id: <200302180948.h1I9maGm047797@open.nlnetlabs.nl> Subject: Re: axfr-clarify's fraudulent claims of consensus In-Reply-To: <20030217233257.GA18427@thales.memphis.edu> To: mw-list-namedroppers@csi.hu Date: Tue, 18 Feb 2003 10:48:36 +0100 (CET) From: Alexis Yushin CC: Name Droppers X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Once mw-list-namedroppers@csi.hu wrote: >The fundamental problem is that I see all these claims, and no actual >verifications. I start to think that none of the people criticizing >djbdns ever run its servers and/or used its clients. Why would they even try after seeing his posts? I certainly wouldn't as the author comes across as unprofessional, biased and difficult (next to impossible) to deal with. Alexis -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 18 05:21:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24152 for ; Tue, 18 Feb 2003 05:21:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18l4pe-000O3f-00 for namedroppers-data@psg.com; Tue, 18 Feb 2003 02:18:34 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18l4pb-000O23-00 for namedroppers@ops.ietf.org; Tue, 18 Feb 2003 02:18:31 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18l44o-0000DF-00 for namedroppers@ops.ietf.org; Tue, 18 Feb 2003 18:30:11 +0900 In-Reply-To: <200302172016.h1HKG4d6046986@drugs.dv.isc.org> Message-ID: References: <200302172016.h1HKG4d6046986@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Mon, 17 Feb 2003 20:36:29 +0000 (GMT) From: Lloyd Wood To: Mark.Andrews@isc.org cc: Mark_Andrews@isc.org, "D. J. Bernstein" , "" , "" , "" Subject: Re: axfr-clarify's fraudulent claims of consensus X-Spam-Status: No, hits=-2.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,RESENT_TO, SPAM_PHRASE_02_03,USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] On Tue, 18 Feb 2003 Mark.Andrews@isc.org wrote: > > On Sat, 15 Feb 2003 Mark.Andrews@isc.org wrote: > > > > > > (2) My software doesn't allow that configuration. > > > > > > Well as we keep pointing out your software is BROKEN. > > > > Saying it's broken implies the act of breakage. > > > > At what point was the software NOT broken? > > In the original design specs. RFC 1034 and RFC 1035. If > they had been followed then we wouldn't be havin this > discussion. original design specs != "your software". Are you claiming that djb's djbdns software was incorrectly implemented? Please be clear, for Dan "we're all suffering because of a few inconsiderate people" Bernstein's benefit -- and ultimately our benefit, too. L. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 18 05:26:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24229 for ; Tue, 18 Feb 2003 05:26:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18l4wF-000OHn-00 for namedroppers-data@psg.com; Tue, 18 Feb 2003 02:25:23 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 18l4wB-000OHa-00 for namedroppers@ops.ietf.org; Tue, 18 Feb 2003 02:25:19 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h1IAPJqn078086 for ; Tue, 18 Feb 2003 05:25:19 -0500 (EST) Received: from [220.128.48.47] ([192.136.136.113]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id FAA16223; Tue, 18 Feb 2003 05:25:17 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@ops (Unverified) Message-Id: Date: Tue, 18 Feb 2003 11:28:40 +0800 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: empty answers Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=0.9 required=5.0 tests=DATE_IN_PAST_06_12,SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk When was the last time a completely empty answer (w/RCODE=0) was intentionally implemented? E.g., a response to a query (in which the QCLASS and QNAME exist but without a match for the QTYPE) that had neither a SOA RR nor a NXT RR in the authority section? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 18 13:58:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05091 for ; Tue, 18 Feb 2003 13:58:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lCbx-000J2c-00 for namedroppers-data@psg.com; Tue, 18 Feb 2003 10:36:57 -0800 Received: from [2002:421e:68aa:0:250:daff:fe82:1c39] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 18lCbs-000J1m-00 for namedroppers@ops.ietf.org; Tue, 18 Feb 2003 10:36:52 -0800 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 98C8518DF for ; Tue, 18 Feb 2003 13:36:16 -0500 (EST) Date: Tue, 18 Feb 2003 13:36:16 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: empty answers In-Reply-To: References: User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030218183616.98C8518DF@thrintun.hactrn.net> X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03, USER_AGENT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Tue, 18 Feb 2003 11:28:40 +0800, Ed Lewis wrote: > > When was the last time a completely empty answer (w/RCODE=0) was > intentionally implemented? > > E.g., a response to a query (in which the QCLASS and QNAME exist but > without a match for the QTYPE) that had neither a SOA RR nor a NXT RR > in the authority section? I can't answer your question about "when", but for what it's worth: This is a legitimate response for an authoritative-only name server to send when asked about a zone for which it knows absolutely nothing. If I assume that you meant "NS" rather than "NXT", it's still legitimate, but less common, since it would only be given out by the above name server when it had no root hints to hand out. This is a completely legitimate configuration, but not that common, due to implementations that become despondant upon discovering that they have no root hints and chose to reply with RCODE=2. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 18 16:23:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08899 for ; Tue, 18 Feb 2003 16:23:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lF5t-00031s-00 for namedroppers-data@psg.com; Tue, 18 Feb 2003 13:16:01 -0800 Received: from [2001:470:1f00:ffff::5a1] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 18lF5p-0002yW-00 for namedroppers@ops.ietf.org; Tue, 18 Feb 2003 13:15:58 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h1ILFG4U002448; Wed, 19 Feb 2003 08:15:17 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200302182115.h1ILFG4U002448@drugs.dv.isc.org> To: Rob Austein Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: empty answers In-reply-to: Your message of "Tue, 18 Feb 2003 13:36:16 CDT." <20030218183616.98C8518DF@thrintun.hactrn.net> Date: Wed, 19 Feb 2003 08:15:16 +1100 X-Spam-Status: No, hits=0.9 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03, TO_BE_REMOVED_REPLY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > At Tue, 18 Feb 2003 11:28:40 +0800, Ed Lewis wrote: > > > > When was the last time a completely empty answer (w/RCODE=0) was > > intentionally implemented? > > > > E.g., a response to a query (in which the QCLASS and QNAME exist but > > without a match for the QTYPE) that had neither a SOA RR nor a NXT RR > > in the authority section? > > I can't answer your question about "when", but for what it's worth: > > This is a legitimate response for an authoritative-only name server to > send when asked about a zone for which it knows absolutely nothing. > > If I assume that you meant "NS" rather than "NXT", it's still > legitimate, but less common, since it would only be given out by the > above name server when it had no root hints to hand out. This is a > completely legitimate configuration, but not that common, due to > implementations that become despondant upon discovering that they have > no root hints and chose to reply with RCODE=2. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: You missed the point of the question which was. What was the last version of each vendors software to NOT return SOA for a NOERROR NODATA response. BIND 4.9.5 enabled sending of SOA for NOERROR NODATA. It also enabled sending of SOA for cached negative responses. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 18 17:13:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09944 for ; Tue, 18 Feb 2003 17:13:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lFs1-0006Bi-00 for namedroppers-data@psg.com; Tue, 18 Feb 2003 14:05:45 -0800 Received: from [2001:6e0:206:1:250:daff:fe3d:1d6] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 3.36 #1) id 18lFry-0006BP-00 for namedroppers@ops.ietf.org; Tue, 18 Feb 2003 14:05:42 -0800 Received: from open.nlnetlabs.nl (localhost [IPv6:::1]) by open.nlnetlabs.nl (8.12.6/8.12.6) with ESMTP id h1IM5ep8051397 for ; Tue, 18 Feb 2003 23:05:40 +0100 (CET) (envelope-from alexis@open.nlnetlabs.nl) Received: (from alexis@localhost) by open.nlnetlabs.nl (8.12.6/8.12.6/Submit) id h1IM5ejc051396 for namedroppers@ops.ietf.org; Tue, 18 Feb 2003 23:05:40 +0100 (CET) Message-Id: <200302182205.h1IM5ejc051396@open.nlnetlabs.nl> Subject: wildcards draft To: namedroppers@ops.ietf.org Date: Tue, 18 Feb 2003 23:05:40 +0100 (CET) From: Alexis Yushin X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I dont like the wildcard clarification draft, what I'm saying is that I dont like the idea of existance of non-existing or better put non-explicitly-configured domains. It is quite non intuitive. What's the main driver behing this clarification draft? NXT processing? Certain implementation shortcomings? Alexis -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 18 17:27:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10176 for ; Tue, 18 Feb 2003 17:27:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lFu7-0006Mf-00 for namedroppers-data@psg.com; Tue, 18 Feb 2003 14:07:55 -0800 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by psg.com with esmtp (Exim 3.36 #1) id 18lFu4-0006MS-00 for namedroppers@ops.ietf.org; Tue, 18 Feb 2003 14:07:52 -0800 Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1IM7lNh011683; Tue, 18 Feb 2003 17:07:47 -0500 (EST) Received: from cisco.com (dhcp-161-44-149-137.cisco.com [161.44.149.137]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA02285; Tue, 18 Feb 2003 17:07:46 -0500 (EST) Message-ID: <3E52AEB2.2040807@cisco.com> Date: Tue, 18 Feb 2003 17:07:46 -0500 From: Josh Littlefield User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andreas Gustafsson CC: iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: axfr-clarify's fraudulent claims of consensus References: <200302142024.h1EKOkS10983@guava.araneus.fi> <200302150157.h1F1vXw11389@guava.araneus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.3 required=5.0 tests=REFERENCES,SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I'd like to make clear my support for draft-ietf-dnsext-axfr-clarify-05. With the exception of a single subtle enhancement (the specification of returning NOTAUTH to an AXFR request about a zone for which the server is not authoritative), I find that the specification correctly matches my own interpretation of RFC1034 and RFC1035 and first-hand interoperability experience. Regarding zone integrity, I find the specification supports the clear requirements for the independence of zone data described in RFC1034 (sections 4.1 and 4.2), along with the practical need to ensure that all authoritative servers for a zone will have an accurate copy of the data for that zone for a given serial number (RFC1034, Sect. 4.3.5). As for the requirement to carry zone transfer RRs in the answer section, this is a completely obvious application of the rules governing all responses to requests with opcode QUERY (0). RFC1034 clearly states that the answer section "carries RRs which directly answer the query." I don't see how anyone could conclude that AXFR clients should look for zone RRs anywhere else. I implemented AXFR in 1997 on a server architected to clearly differentiate each zone's data, as specified (according to my reading) in RFC1034. The axfr-clarify draft is consistent with that implementation, whose basic architecture has not changed. This made the implementation of RFC1995 relatively trivial, because the consistency of the baseline AXFR allows the unambiguous communication of incremental changes to that baseline, even if the AXFR has been retrieved from one authority, and the IXFR from another, and regardless of what other zones those servers may know about. Regards, Josh Littlefield -- ===================================================================== Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 250 Apollo Drive tel: 978-497-8378 fax: same Chelmsford, MA 01824-3627 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 18 18:19:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11172 for ; Tue, 18 Feb 2003 18:19:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lGuN-000Amm-00 for namedroppers-data@psg.com; Tue, 18 Feb 2003 15:12:15 -0800 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #1) id 18lGuL-000Ama-00 for namedroppers@ops.ietf.org; Tue, 18 Feb 2003 15:12:13 -0800 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id SAA31690; Tue, 18 Feb 2003 18:09:17 -0500 Date: Tue, 18 Feb 2003 18:10:36 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Kevin Darcy cc: namedroppers@ops.ietf.org Subject: Re: axfr-clarify's fraudulent claims of consensus In-Reply-To: <3E517853.2060707@daimlerchrysler.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,SPAM_PHRASE_00_01,USER_AGENT_PINE, X_OSIRU_SPAM_SRC version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 17 Feb 2003, Kevin Darcy wrote: > I just want AXFR and IXFR to be compatible. And I don't think DJB's poor > design decisions should stand in the way of that. DJB's decisions don't stand in the way of that. Just the opposite. Bind 9 broke AXFR, due to bad programming, bad management, and lazy engineering. Now, instead of admitting the mistakes, they want to change AXFR, and are trying (lamely, I might add) to say that AXFR MUST be changed to support IXFR. AXFR has NOTHING WHATSOEVER to do with IXFR. This is a simple proof, the outlines of which I have already given. --Dean -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 18 18:19:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11187 for ; Tue, 18 Feb 2003 18:19:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lGxS-000B0k-00 for namedroppers-data@psg.com; Tue, 18 Feb 2003 15:15:26 -0800 Received: from [2001:470:1f00:ffff::5a1] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 18lGxM-000Az7-00 for namedroppers@ops.ietf.org; Tue, 18 Feb 2003 15:15:23 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h1INEX4U002844; Wed, 19 Feb 2003 10:14:33 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200302182314.h1INEX4U002844@drugs.dv.isc.org> To: Alexis Yushin Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: wildcards draft In-reply-to: Your message of "Tue, 18 Feb 2003 23:05:40 BST." <200302182205.h1IM5ejc051396@open.nlnetlabs.nl> Date: Wed, 19 Feb 2003 10:14:33 +1100 X-Spam-Status: No, hits=2.1 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,SPAM_PHRASE_05_08 version=2.43 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Hi, > > I dont like the wildcard clarification draft, what I'm saying is that I dont > like the idea of existance of non-existing or better put non-explicitly-confi > gured > domains. It is quite non intuitive. > > What's the main driver behing this clarification draft? NXT processing? Certa > in > implementation shortcomings? > > Alexis The main driving force is to demonstate that you only need a maximum of two NXT records to prove the non-existance of the qname. One for the qname and potentially an additional one for the wildcard. People were saying that you need lots of NXT records which was just wrong. Additionally it was counter intuitive returning NXDOMAIN for a name which clearly exist and RFC 1035 says should result in a NOERROR response. It's also counter intuitive for a empty node to be used for wildcard processing but to have it return NXDOMAIN. NXT processing can be done either way. You just have to have agreement upon what is the correct RCODE for a empty node as the validator will reject the wrong RCODE. DS is a major change and the validator needs to be re-written. DNSSEC should not change the basics of DNS. It should be securing the DNS. The wording in RFC 2535 could be interpreted to allow for both NOERROR and NXDOMAIN. Mark P.S. I've always though NXDOMAIN was wrong for the empty node case. -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 18 18:33:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11443 for ; Tue, 18 Feb 2003 18:33:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lHBm-000Bz7-00 for namedroppers-data@psg.com; Tue, 18 Feb 2003 15:30:14 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18lHBk-000Byv-00 for namedroppers@ops.ietf.org; Tue, 18 Feb 2003 15:30:13 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18lHBj-000NxD-00 for namedroppers@ops.ietf.org; Wed, 19 Feb 2003 08:30:11 +0900 Message-Id: <200302181832.h1IIWbhC016614@turing-police.cc.vt.edu> In-Reply-To: Your message of "Mon, 17 Feb 2003 13:48:23 GMT." References: <200302151239.h1FCdCd6028798@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-396084903P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit To: Lloyd Wood Cc: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: axfr-clarify's fraudulent claims of consensus From: Valdis.Kletnieks@vt.edu Date: Tue, 18 Feb 2003 13:32:27 -0500 X-Spam-Status: No, hits=0.3 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,REFERENCES,RESENT_TO, SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --==_Exmh_-396084903P Content-Type: text/plain; charset=us-ascii and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] On Mon, 17 Feb 2003 13:48:23 GMT, Lloyd Wood said: > Saying it's broken implies the act of breakage. > > At what point was the software NOT broken? It's quite conceivable the software was BAD (Broken As Designed). It's pretty clear to me that either djbdns or BIND was BAD. I'm just not sure which.. :) http://www.catb.org/~esr/jargon/html/entry/BAD.html --==_Exmh_-396084903P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQE+Unw7cC3lWbTT17ARAj8mAJ9Sh1pxAnTf6/+Zm6PU6ZZKZ8kHTwCdGUfv BP2xGbkQywKOaPw0rNODwPY= =tDGn -----END PGP SIGNATURE----- --==_Exmh_-396084903P-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 18 18:56:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11962 for ; Tue, 18 Feb 2003 18:56:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lHSh-000DGS-00 for namedroppers-data@psg.com; Tue, 18 Feb 2003 15:47:43 -0800 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #1) id 18lHSe-000DG0-00 for namedroppers@ops.ietf.org; Tue, 18 Feb 2003 15:47:40 -0800 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id SAA23308; Tue, 18 Feb 2003 18:45:00 -0500 Date: Tue, 18 Feb 2003 18:46:19 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Mark.Andrews@isc.org cc: mw-list-namedroppers@csi.hu, Name Droppers , , Subject: Bind 9 AXFR Modification vs AXFR Clarification In-Reply-To: <200302180227.h1I2RSd6053173@drugs.dv.isc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=2.5 required=5.0 tests=IN_REP_TO,RCVD_IN_OSIRUSOFT_COM,SPAM_PHRASE_00_01, USER_AGENT_PINE,X_OSIRU_SPAM_SRC version=2.43 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Good. You found a bug in an implementation. I thought such things were off-topic for this list. This bug doesn't mean that AXFR is broken. Bind 8 did not have this bug, yet it has the common understanding of AXFR. Let me summarize the discussion: Everyone agrees that AXFR specification in RFC 1034 is ambiguous. Some people, many associated with Bind 9 development, assert that it is necessary to change AXFR to support IXFR. This assertion has been refuted on the grounds that incremental database update does not depend on AXFR, since incremental database update does not depend on the underlying wire protocol used to create the remote database which is to be modified by IXFR. Conceivably, it is unnecessary to use AXFR at all, yet one could still use IXFR, so, AXFR is independent of IXFR. Some people, many associated with Bind 9 development, assert that AXFR as commonly implemented by many implementors over many years, is broken, and can't transfer domains correctly. This claim has been refuted by demonstration by interoperability between Bind 8 and other nameserver implementations over the years, and 77% of the internet that currently does not use Bind 9, yet still does AXFR. There being no other arguments raised for the Bind 9 AXFR clarify/modification proposal, it seems that this proposal is gratuitous and unnecessary, and should be rejected. However, we still have the issue of AXFR ambiguity to deal with, and we still need to clarify those ambiguities. I would therefore like to organize a small group of people using implementations other than Bind 9, which we declare to be broken, to document the common implementation assumptions made, and submit that as a clarification to RFC 1034 To prevent confusion between the two proposals, I would like to rename the first proposal "Bind 9 AXFR Modification", and the second proposal "AXFR Clarification". The term "axfr-clarify" will not be used. --Dean -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 18 20:04:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13677 for ; Tue, 18 Feb 2003 20:04:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lIX4-000I6l-00 for namedroppers-data@psg.com; Tue, 18 Feb 2003 16:56:18 -0800 Received: from [2001:470:1f00:ffff::5a1] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 18lIWy-000I3J-00 for namedroppers@ops.ietf.org; Tue, 18 Feb 2003 16:56:13 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h1J0sU4U003065; Wed, 19 Feb 2003 11:54:32 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200302190054.h1J0sU4U003065@drugs.dv.isc.org> To: Dean Anderson Cc: mw-list-namedroppers@csi.hu, Name Droppers , ietf@ietf.org, iesg@ietf.org From: Mark.Andrews@isc.org Subject: Re: Bind 9 AXFR Modification vs AXFR Clarification In-reply-to: Your message of "Tue, 18 Feb 2003 18:46:19 CDT." Date: Wed, 19 Feb 2003 11:54:30 +1100 X-Spam-Status: No, hits=0.5 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Good. You found a bug in an implementation. I thought such things were > off-topic for this list. This bug doesn't mean that AXFR is broken. > Bind 8 did not have this bug, yet it has the common understanding of AXFR. > > Let me summarize the discussion: > > Everyone agrees that AXFR specification in RFC 1034 is ambiguous. > > Some people, many associated with Bind 9 development, assert that it is > necessary to change AXFR to support IXFR. This assertion has been refuted > on the grounds that incremental database update does not depend on AXFR, > since incremental database update does not depend on the underlying wire > protocol used to create the remote database which is to be modified by > IXFR. Conceivably, it is unnecessary to use AXFR at all, yet one could > still use IXFR, so, AXFR is independent of IXFR. Nobody is saying that preserving zone content is a *wire* issue. It is a server behaviour issue. > Some people, many associated with Bind 9 development, assert that AXFR as > commonly implemented by many implementors over many years, is broken, and > can't transfer domains correctly. This claim has been refuted by > demonstration by interoperability between Bind 8 and other nameserver > implementations over the years, and 77% of the internet that currently > does not use Bind 9, yet still does AXFR. All this shows is that these nameservers are not used in situations where the breakage is demonstrated or the administators have learn to work around the breakage or choose to live with it or are unaware of it. > There being no other arguments raised for the Bind 9 AXFR > clarify/modification proposal, it seems that this proposal is gratuitous > and unnecessary, and should be rejected. > > However, we still have the issue of AXFR ambiguity to deal with, and we > still need to clarify those ambiguities. I would therefore like to > organize a small group of people using implementations other than Bind 9, > which we declare to be broken, to document the common implementation > assumptions made, and submit that as a clarification to RFC 1034 > > To prevent confusion between the two proposals, I would like to rename the > first proposal "Bind 9 AXFR Modification", and the second proposal "AXFR > Clarification". The term "axfr-clarify" will not be used. > > --Dean -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 18 21:14:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15073 for ; Tue, 18 Feb 2003 21:14:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lJeV-000NBo-00 for namedroppers-data@psg.com; Tue, 18 Feb 2003 18:08:03 -0800 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #1) id 18lJeQ-000NBc-00 for namedroppers@ops.ietf.org; Tue, 18 Feb 2003 18:07:58 -0800 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id UAA00864; Tue, 18 Feb 2003 20:57:36 -0500 Date: Tue, 18 Feb 2003 20:58:55 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Mark.Andrews@isc.org cc: mw-list-namedroppers@csi.hu, Name Droppers , , Subject: Re: Bind 9 AXFR Modification vs AXFR Clarification In-Reply-To: <200302190054.h1J0sU4U003065@drugs.dv.isc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,SPAM_PHRASE_00_01,USER_AGENT_PINE, X_OSIRU_SPAM_SRC version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 19 Feb 2003 Mark.Andrews@isc.org wrote: > > Good. You found a bug in an implementation. I thought such things were > > off-topic for this list. This bug doesn't mean that AXFR is broken. > > Bind 8 did not have this bug, yet it has the common understanding of AXFR. > > > > Let me summarize the discussion: > > > > Everyone agrees that AXFR specification in RFC 1034 is ambiguous. > > > > Some people, many associated with Bind 9 development, assert that it is > > necessary to change AXFR to support IXFR. This assertion has been refuted > > on the grounds that incremental database update does not depend on AXFR, > > since incremental database update does not depend on the underlying wire > > protocol used to create the remote database which is to be modified by > > IXFR. Conceivably, it is unnecessary to use AXFR at all, yet one could > > still use IXFR, so, AXFR is independent of IXFR. > > Nobody is saying that preserving zone content is a *wire* > issue. It is a server behaviour issue. Zone definition and content is not an AXFR issue. Server administrators provide the definition of zone boundaries. (RFC 1034 Section 2.3 and elsewhere) AXFR merely gives the contents of the zone as has been defined according to the boundaries and content specified by the administrator. The contents could be given to the secondary by FTP or other method. If you mean to change the definition of zone contents, then I would say this proposal is hugely mis-labeled. All the IXFR server needs to do is determine (by some implementation dependent, administrator maintained method) what has changed between one zone version and another. How it does this is nobody's business but the administrator and the implementor. There are infinite possibilities, here. One could, for example, store differences in a series of files. The administrator could even make the differnce files by hand--this is an _implementation detail_. The IXFR server just sends a series or sequences consisting of a list of deleted RRs and a list of added RRs to an IXFR client. There is nothing more to it. (notwithstanding the optional condensation.) The IXFR client must simply make the changes (again, by some implementation dependent, administrator maintained method) to the zone by deleting RRs and adding RR's in each sequence. The original version of the zone might have been obtained by FTP (or quantum interference, or the psychic network) for all we know. This isn't rocket science, and doesn't require any AXFR changes. Nor does it require that the zone boundaries be defined only in some certain way, beyond the definition of zone boundaries given by the system administrator. > > Some people, many associated with Bind 9 development, assert that AXFR as > > commonly implemented by many implementors over many years, is broken, and > > can't transfer domains correctly. This claim has been refuted by > > demonstration by interoperability between Bind 8 and other nameserver > > implementations over the years, and 77% of the internet that currently > > does not use Bind 9, yet still does AXFR. > > All this shows is that these nameservers are not used in > situations where the breakage is demonstrated or the > administators have learn to work around the breakage or > choose to live with it or are unaware of it. "administrators have learn[ed] to work around [it,...] live with it [,] or are unaware of it". Agreed. Having done so, we don't want to stir the pot. Essentially, you are putting more (unnecessary) constraints on implementations, and thus on the administrators, who are supposed to be pretty free to define the zone boundaries. Of course, the specifics of an implementation puts some constraints on the adminstrator, but the administrator can choose a different implementation more to her liking. These unnecessary constraints are a "bad thing". > > To prevent confusion between the two proposals, I would like to rename the > > first proposal "Bind 9 AXFR Modification", and the second proposal "AXFR > > Clarification". The term "axfr-clarify" will not be used. I presume agreement on the name change? --Dean -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 18 21:57:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15975 for ; Tue, 18 Feb 2003 21:57:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lKLA-0000Eh-00 for namedroppers-data@psg.com; Tue, 18 Feb 2003 18:52:08 -0800 Received: from gusto.araneus.fi ([204.152.186.164]) by psg.com with esmtp (Exim 3.36 #1) id 18lKL7-0000EO-00 for namedroppers@ops.ietf.org; Tue, 18 Feb 2003 18:52:05 -0800 Received: from guava.araneus.fi (adsl-63-197-0-204.dsl.snfc21.pacbell.net [63.197.0.204]) by gusto.araneus.fi (8.11.6/8.11.6) with ESMTP id h1J2q0Z00830; Tue, 18 Feb 2003 18:52:00 -0800 (PST) Received: (from gson@localhost) by guava.araneus.fi (8.11.6/8.11.6) id h1J2pwG28755; Tue, 18 Feb 2003 18:51:58 -0800 (PST) Date: Tue, 18 Feb 2003 18:51:58 -0800 (PST) Message-Id: <200302190251.h1J2pwG28755@guava.araneus.fi> To: Dean Anderson Cc: Mark.Andrews@isc.org, Namedroppers , Subject: Re: Bind 9 AXFR Modification vs AXFR Clarification In-Reply-To: References: <200302190054.h1J0sU4U003065@drugs.dv.isc.org> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=0.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Dean Anderson writes: > Zone definition and content is not an AXFR issue. Server administrators > provide the definition of zone boundaries. (RFC 1034 Section 2.3 and > elsewhere) AXFR merely gives the contents of the zone as has been defined > according to the boundaries and content specified by the administrator. This is exactly what the draft says, so what are you disagreeing with? The issue with BIND 8 is that it does *not* give the contents of the zone according to the boundaries and content specified by the zone administrator, but instead a mixture of data from different zones as specified by their different administrators. -- 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. archive: From owner-namedroppers@ops.ietf.org Tue Feb 18 22:49:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17234 for ; Tue, 18 Feb 2003 22:49:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lL9N-0003bS-00 for namedroppers-data@psg.com; Tue, 18 Feb 2003 19:44:01 -0800 Received: from [2001:470:1f00:ffff::5a1] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 18lL9J-0003aX-00 for namedroppers@ops.ietf.org; Tue, 18 Feb 2003 19:43:57 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h1J3gM4U003505; Wed, 19 Feb 2003 14:42:22 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200302190342.h1J3gM4U003505@drugs.dv.isc.org> To: Dean Anderson Cc: mw-list-namedroppers@csi.hu, Name Droppers , ietf@ietf.org, iesg@ietf.org From: Mark.Andrews@isc.org Subject: Re: Bind 9 AXFR Modification vs AXFR Clarification In-reply-to: Your message of "Tue, 18 Feb 2003 20:58:55 CDT." Date: Wed, 19 Feb 2003 14:42:22 +1100 X-Spam-Status: No, hits=0.2 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > On Wed, 19 Feb 2003 Mark.Andrews@isc.org wrote: > > > > Good. You found a bug in an implementation. I thought such things were > > > off-topic for this list. This bug doesn't mean that AXFR is broken. > > > Bind 8 did not have this bug, yet it has the common understanding of AXFR > . > > > > > > Let me summarize the discussion: > > > > > > Everyone agrees that AXFR specification in RFC 1034 is ambiguous. > > > > > > Some people, many associated with Bind 9 development, assert that it is > > > necessary to change AXFR to support IXFR. This assertion has been refute > d > > > on the grounds that incremental database update does not depend on AXFR, > > > since incremental database update does not depend on the underlying wire > > > protocol used to create the remote database which is to be modified by > > > IXFR. Conceivably, it is unnecessary to use AXFR at all, yet one could > > > still use IXFR, so, AXFR is independent of IXFR. > > > > Nobody is saying that preserving zone content is a *wire* > > issue. It is a server behaviour issue. > > Zone definition and content is not an AXFR issue. Server administrators > provide the definition of zone boundaries. (RFC 1034 Section 2.3 and > elsewhere) AXFR merely gives the contents of the zone as has been defined > according to the boundaries and content specified by the administrator. Well BIND 9 does this. CISCO's server does this according to John. BIND 8 doesn't always. BIND 4 doesn't always. DJBDNS doesn't always. This is independent of the method used to transfer the zone to these servers or enter the zone contents on these servers. > The contents could be given to the secondary by FTP or other method. If > you mean to change the definition of zone contents, then I would say this > proposal is hugely mis-labeled. It's not changing the definition. It is preserving the definition. It's not mis-labeled. It is stating the implict assumption that AXFR transfers what is entered as the zones contents. Nothing more, nothing less. > All the IXFR server needs to do is determine (by some implementation > dependent, administrator maintained method) what has changed between one > zone version and another. How it does this is nobody's business but the > administrator and the implementor. There are infinite possibilities, here. > One could, for example, store differences in a series of files. The > administrator could even make the differnce files by hand--this is an > _implementation detail_. The IXFR server just sends a series or sequences > consisting of a list of deleted RRs and a list of added RRs to an IXFR > client. There is nothing more to it. (notwithstanding the optional > condensation.) All of which is irrelevent to this issue. > The IXFR client must simply make the changes (again, by some > implementation dependent, administrator maintained method) to the zone by > deleting RRs and adding RR's in each sequence. The original version of the > zone might have been obtained by FTP (or quantum interference, or the > psychic network) for all we know. Well the problem is that you have to get the *original* version, not a corrupted version. AXFR implementations are not returning the data originally entered. > This isn't rocket science, and doesn't require any AXFR changes. Nor does > it require that the zone boundaries be defined only in some certain way, > beyond the definition of zone boundaries given by the system > administrator. It does however require that for a given serial number that all sources of the zone have supplied identical contents. You should be able to apply a IXFR delta to a copy derived from any source and have it apply without error. > > > Some people, many associated with Bind 9 development, assert that AXFR as > > > commonly implemented by many implementors over many years, is broken, and > > > can't transfer domains correctly. This claim has been refuted by > > > demonstration by interoperability between Bind 8 and other nameserver > > > implementations over the years, and 77% of the internet that currently > > > does not use Bind 9, yet still does AXFR. > > > > All this shows is that these nameservers are not used in > > situations where the breakage is demonstrated or the > > administators have learn to work around the breakage or > > choose to live with it or are unaware of it. > > "administrators have learn[ed] to work around [it,...] live with it [,] or > are unaware of it". Agreed. Having done so, we don't want to stir the > pot. LOL. > Essentially, you are putting more (unnecessary) constraints on > implementations, and thus on the administrators, who are supposed to be > pretty free to define the zone boundaries. Of course, the specifics of an > implementation puts some constraints on the adminstrator, but the > administrator can choose a different implementation more to her liking. The constaint was already there and it is necessary for reliable operation of the DNS. > These unnecessary constraints are a "bad thing". > > > > To prevent confusion between the two proposals, I would like to rename th > e > > > first proposal "Bind 9 AXFR Modification", and the second proposal "AXFR > > > Clarification". The term "axfr-clarify" will not be used. > > I presume agreement on the name change? No. > > --Dean > -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 19 00:52:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19422 for ; Wed, 19 Feb 2003 00:52:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lN1z-000BhK-00 for namedroppers-data@psg.com; Tue, 18 Feb 2003 21:44:31 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #1) id 18lN1x-000Bh8-00 for namedroppers@ops.ietf.org; Tue, 18 Feb 2003 21:44:29 -0800 Received: (qmail 19703 invoked by uid 1016); 19 Feb 2003 05:44:54 -0000 Date: 19 Feb 2003 05:44:54 -0000 Message-ID: <20030219054454.19702.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: axfr-clarify breaking RFC 1034 References: <20030215110946.67446.qmail@cr.yp.to> <200302151239.h1FCdCd6028798@drugs.dv.isc.org> <20030217204351.GB16887@thales.memphis.edu> <3E5156B7.3060508@daimlerchrysler.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=0.3 required=5.0 tests=REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Kevin Darcy writes: > RFC 1034 requires matching NS record sets in the parent > and the child, but this cannot be *guaranteed* In the situation under discussion, one server has both zones, so that server _can_ guarantee RFC 1034 consistency---and my server _does_. (BIND 8 also does, to some extent. BIND 9 doesn't.) Andrews says that this RFC 1034 enforcement causes problems for a system administrator who tries to violate RFC 1034. Well, that's too damn bad! The system administrator shouldn't be trying to violate RFC 1034. If the BIND company wants the RFC 1034 rule changed, they can propose that, and we'll discuss the costs and benefits. Instead they're trying to slip the change past us as a ``clarification.'' You know they're lying; why are you condoning dishonest behavior? ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 19 01:32:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20140 for ; Wed, 19 Feb 2003 01:32:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lNk4-000F6x-00 for namedroppers-data@psg.com; Tue, 18 Feb 2003 22:30:04 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #1) id 18lNk0-000F66-00 for namedroppers@ops.ietf.org; Tue, 18 Feb 2003 22:30:00 -0800 Received: (qmail 39959 invoked by uid 1016); 19 Feb 2003 06:30:22 -0000 Date: 19 Feb 2003 06:30:22 -0000 Message-ID: <20030219063022.39958.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: axfr-clarify breaking RFC 1034, continued References: <20030217202833.GA16887@thales.memphis.edu> <200302180227.h1I2RSd6053173@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-0.2 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_03_05 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mark.Andrews@isc.org writes: > ; <<>> DiG 9.3.0s20021115 <<>> axfr child.example.net @10.53.0.2 [ claims that ns2.child.example.net doesn't exist, as compared to: ] > ; <<>> DiG 9.3.0s20021115 <<>> axfr example.net @10.53.0.2 > ns2.child.example.net. 10 IN A 10.53.0.2 Once again: That configuration violates RFC 1034. Specifically, sections 4.2.1 and 4.2.2 of RFC 1034 make crystal clear that the ns2 glue in the parent zone is supposed to match the data in the child zone. My software enforces the RFC 1034 requirement in this situation. If it had been running on 10.53.0.2 then you wouldn't have been able to screw up the configuration in the first place. What you're complaining about is my software's perfectly straightforward enforcement of the RFC 1034 requirement on the client side after you set up an RFC-1034-violating configuration with your server. Is it really so difficult to understand that it's your fault for violating RFC 1034? [ complaining about zone transfers in tinydns ] > You have to roll your own from what I can see. No, you don't. Have you ever heard of ``third parties''? How about ``interchangeable parts''? Monolithic design is good for a company trying to achieve lock-in, but modular design leads to faster evolution and, in the end, better software for the users. If you're trying to say that I haven't bothered to write up the existing AXFR tools on my web pages, you're right. These tools have an extremely limited audience; I have better things to do. The vast majority of users are much happier with rsync+ssh than they would ever be with anything based on AXFR. See http://cr.yp.to/djbdns/tcp.html#intro-axfr. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 19 02:02:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24122 for ; Wed, 19 Feb 2003 02:02:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lOB4-000HRE-00 for namedroppers-data@psg.com; Tue, 18 Feb 2003 22:57:58 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #1) id 18lOB2-000HR1-00 for namedroppers@ops.ietf.org; Tue, 18 Feb 2003 22:57:56 -0800 Received: (qmail 50064 invoked by uid 1016); 19 Feb 2003 06:58:22 -0000 Date: 19 Feb 2003 06:58:22 -0000 Message-ID: <20030219065822.50063.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: axfr-clarify's fraudulent claims of consensus References: <200302142024.h1EKOkS10983@guava.araneus.fi> <200302150157.h1F1vXw11389@guava.araneus.fi> <3E52AEB2.2040807@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Josh Littlefield writes: > RFC1034 clearly states that the answer section "carries RRs which > directly answer the query." I don't see how anyone could conclude > that AXFR clients should look for zone RRs anywhere else. There is overwhelming consensus that (in the absence of extended behavior requested by the client) the AXFR _server_ must leave the additional section and authority section empty. It must put the data into the answer section. All existing servers work this way---and must do so for interoperability. There are several perfectly valid parsing strategies for the client. In particular, my software uses the simple strategy while there are records left read a record while BIND 9 uses the slightly more complicated strategy while there are records left in the answer section read a record Both strategies work, since servers put all records into the answer section. Neither strategy creates any interoperability problems. There is certainly _not_ consensus on telling the _client_ to use the BIND 9 strategy. Furthermore, any such statement (whether ``MUST'' or ``SHOULD'') would blatantly violate RFC 2119, section 6. This is about the tenth time that I have had to point out the blazingly obvious fact that constraining _server_ behavior is not the same as constraining _client_ behavior. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 19 02:17:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02841 for ; Wed, 19 Feb 2003 02:17:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lOR2-000Is5-00 for namedroppers-data@psg.com; Tue, 18 Feb 2003 23:14:28 -0800 Received: from as7-2-2.bn.g.bonet.se ([217.215.21.151] helo=poledra) by psg.com with esmtp (Exim 3.36 #1) id 18lOR0-000Irq-00 for namedroppers@ops.ietf.org; Tue, 18 Feb 2003 23:14:26 -0800 Received: from amalthea.8in.net ([192.168.242.14] helo=amalthea) by poledra with asmtp (Exim 3.35 #1 (Debian)) id 18lOQx-0005oS-00 for ; Wed, 19 Feb 2003 08:14:23 +0100 Message-ID: <046601c2d7e6$77001820$0ef2a8c0@amalthea> From: =?iso-8859-1?Q?Kandra_Nyg=E5rds?= To: References: <20030217202833.GA16887@thales.memphis.edu> <200302180227.h1I2RSd6053173@drugs.dv.isc.org> <20030219063022.39958.qmail@cr.yp.to> Subject: Re: axfr-clarify breaking RFC 1034, continued Date: Wed, 19 Feb 2003 08:13:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_03_05, USER_AGENT_OE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit From: "D. J. Bernstein" > Once again: That configuration violates RFC 1034. Specifically, sections > 4.2.1 and 4.2.2 of RFC 1034 make crystal clear that the ns2 glue in the > parent zone is supposed to match the data in the child zone. Excellent point. Now for a real-world example: Many ccTLDs (and RIRs, such as RIPE) require automated or manual checks before a delegation [change] is approved by the TLD Registry. Prior to requesting a change of delegation, the zone administrator changes the zone data. This of course violates RFC 1034, specifically sections 4.2.1 and 4.2.2. Please tell me, how is one to accomplish this without breaking RFC1034 sections 4.2.1 and 4.2.2? Or perhaps there are places where some (temporary) RFC1034 breakage is not only warranted but to be expected from time to time? > My software enforces the RFC 1034 requirement in this situation. If it > had been running on 10.53.0.2 then you wouldn't have been able to screw > up the configuration in the first place. If it prevents me from breaking my zones without breaking anything else, that's a good thing. Unfortunately, it also changes the content of the zones, which does break something else. This is an interoperability issue, and a potentially problematic one. > What you're complaining about is my software's perfectly straightforward > enforcement of the RFC 1034 requirement on the client side after you set > up an RFC-1034-violating configuration with your server. Is it really so > difficult to understand that it's your fault for violating RFC 1034? The reason for violating RFC1034 could be as simple as propragation delay. If timing issues interfere with routine zone updates, it's an implementation bug. The reason could also be a temporary intentional change. If your software breaks intentional changes, it's an implementation bug. Face it, you do not live in a perfect world, where you (as a single administrator) can control everything. Delays - human or machine - in propragating information is a reality. If your software can't cope with that, it's an implementation bug. And, it's no good to claim that it wouldn't have broken if everyone had just used YOUR software. If it breaks, it's a bug. > If you're trying to say that I haven't bothered to write up the existing > AXFR tools on my web pages, you're right. These tools have an extremely > limited audience; I have better things to do. The vast majority of users > are much happier with rsync+ssh than they would ever be with anything > based on AXFR. See http://cr.yp.to/djbdns/tcp.html#intro-axfr. ...and, if your software can't interoperate with other software properly, it's an [ insert here ] bug? Best regards, Kandra Nygards -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 19 04:53:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17198 for ; Wed, 19 Feb 2003 04:53:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lQnR-000Paj-00 for namedroppers-data@psg.com; Wed, 19 Feb 2003 01:45:45 -0800 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 18lQnO-000Pa8-00 for namedroppers@ops.ietf.org; Wed, 19 Feb 2003 01:45:42 -0800 Received: from delta.cs.mu.OZ.AU ([172.30.0.189]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1J9jKd28424; Wed, 19 Feb 2003 16:45:21 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1J9gOK05421; Wed, 19 Feb 2003 16:42:25 +0700 (ICT) From: Robert Elz To: "D. J. Bernstein" cc: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: axfr-clarify breaking RFC 1034 In-Reply-To: <20030219054454.19702.qmail@cr.yp.to> References: <20030219054454.19702.qmail@cr.yp.to> <20030215110946.67446.qmail@cr.yp.to> <200302151239.h1FCdCd6028798@drugs.dv.isc.org> <20030217204351.GB16887@thales.memphis.edu> <3E5156B7.3060508@daimlerchrysler.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 19 Feb 2003 16:42:23 +0700 Message-ID: <5419.1045647743@munnari.OZ.AU> X-Spam-Status: No, hits=-0.5 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: 19 Feb 2003 05:44:54 -0000 From: "D. J. Bernstein" Message-ID: <20030219054454.19702.qmail@cr.yp.to> | In the situation under discussion, one server has both zones, so that | server _can_ guarantee RFC 1034 consistency---and my server _does_. | (BIND 8 also does, to some extent. BIND 9 doesn't.) There are two requirements (in this general area) on servers in the DNS. One is that two servers for the same zone give the same answers to the same questions (except in the interval between an update to one server and its being made known to the other, during which time the SOA serial numbers will differ). (AXFR is one such possible question). Second, glue records should be copied from the authoritative zone to the parent, so they are the same in both zones. Again, there is necessarily going to sometimes be a delay between when the child zone is updated and when the parent is updated. Your reading of the requirements means that in order to shorten the delay in the second case, in some circumstances, you're willing to generate cases where the first incompatibility (servers for the same zone returning different answers) will exist, without the serial numbers differing (and with no defined method of reconciling the issue - that is, there is no way of knowing which answer is the "correct" one). In the parent/child case, if there is a difference, the child's answers are correct by definition. In the "different zones after an update" case, the server with the higher serial number is correct, the lower is out of date. In the case we have been discussing, the answers differ, both servers are serving the same zone, the serial numbers are the same, which answer should be used? How can anyone guess? Just about everyone here seems to be convinced that the (negligible) gain to be gained from forcing the parent and child to contain the same records in the cases where that is feasible is not worth the kind of problems this can cause to the first requirement (which in hard cases can actually be difficult to fix without manual intervention - it won't always just "fix itself" though normal correct operation of the servers). The requirements you're insisting upon enforcing in your servers trivially fix themselves when the parent zone is updated (remember you assume that if the human doesn't do that, any problems are of their own making...) If you have a proposal for some method to actually cause the parent/child delegation to *always* be compatible (glue in parent matches records in child, always), then please don't keep it a secret, I'd really like to see it. Until then, assuming that this will always be true, and writing off all other cases as "configuration error, anything is allowed to happen" is inappropriate. 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. archive: From owner-namedroppers@ops.ietf.org Wed Feb 19 05:04:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17596 for ; Wed, 19 Feb 2003 05:04:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lR3e-0000As-00 for namedroppers-data@psg.com; Wed, 19 Feb 2003 02:02:30 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 18lR3b-0000Ac-00 for namedroppers@ops.ietf.org; Wed, 19 Feb 2003 02:02:27 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h1JA2Nqn005217; Wed, 19 Feb 2003 05:02:23 -0500 (EST) Received: from [220.128.48.115] ([192.136.136.99]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id FAA04938; Wed, 19 Feb 2003 05:02:20 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@ops Message-Id: In-Reply-To: <200302182205.h1IM5ejc051396@open.nlnetlabs.nl> References: <200302182205.h1IM5ejc051396@open.nlnetlabs.nl> Date: Wed, 19 Feb 2003 18:01:43 +0800 To: Alexis Yushin From: Edward Lewis Subject: Re: wildcards draft Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-0.4 required=5.0 tests=IN_REP_TO,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,TO_BE_REMOVED_REPLY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 23:05 +0100 2/18/03, Alexis Yushin wrote: >Hi, > >I dont like the wildcard clarification draft, what I'm saying is that I dont >like the idea of existance of non-existing or better put >non-explicitly-configured >domains. It is quite non intuitive. I don't exactly understand the question. It's not what exists or doesn't exist in a protocol, the issue is what response is generated by a query. In RFC 1034 there are three concepts regarding existence. Wild cards are tools for synthesizing answers. Whether you want to say the an answer synthesized from a wild card represents existence or not, the fact remains that an answer is obtained for the query. RFC 1034 does define an authoritative name error for queries whose QNAME is neither a leaf with data nor an interior node. In this case, if the node does not exist, a query against it results in an authoritative name error (NXDOMAIN in BIND lingo). The third incidence of 'existence' is the impact on the algorithm in 4.3.2, section C. Given the defintion in 3.1, it's quite clear that empty non-terminals play a role in the execution of 4.3.2-c, hence they 'exist'. (I exist, ergo I impact a response, or, if a domain name falls in the forest...) >What's the main driver behing this clarification draft? NXT >processing? Certain >implementation shortcomings? Someone asked me to write up text on wild cards. Apparently some feel it is unclear from RFC 1034, I just reiterated what is in that RFC. Perhaps my question is - do you think the wild card draft differs from RFC 1034? I don't intend it to, but if that is the impression it gives, the draft is in error. >Alexis > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 19 05:31:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18141 for ; Wed, 19 Feb 2003 05:31:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lRPc-00011e-00 for namedroppers-data@psg.com; Wed, 19 Feb 2003 02:25:12 -0800 Received: from [2001:6e0:206:1:250:daff:fe3d:1d6] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 3.36 #1) id 18lRPa-00011S-00 for namedroppers@ops.ietf.org; Wed, 19 Feb 2003 02:25:10 -0800 Received: from open.nlnetlabs.nl (localhost [IPv6:::1]) by open.nlnetlabs.nl (8.12.6/8.12.6) with ESMTP id h1JAP7p8054362; Wed, 19 Feb 2003 11:25:07 +0100 (CET) (envelope-from alexis@open.nlnetlabs.nl) Received: (from alexis@localhost) by open.nlnetlabs.nl (8.12.6/8.12.6/Submit) id h1JAP7qQ054361; Wed, 19 Feb 2003 11:25:07 +0100 (CET) Message-Id: <200302191025.h1JAP7qQ054361@open.nlnetlabs.nl> Subject: Re: wildcards draft In-Reply-To: To: Edward Lewis Date: Wed, 19 Feb 2003 11:25:07 +0100 (CET) From: Alexis Yushin CC: Alexis Yushin , namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, hits=0.4 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01,TO_BE_REMOVED_REPLY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward, Intuitively I would expect a NXDOMAIN (in BIND language) for a domain that I did not explicitly configure and that doesnt have any resource data associated with it. *.test. MX 100 mailhost.test. a.b.c.test. MX 100 office.test. As a user, the expected outcome of the above example would be to route all the mail for *.test to mailhost.test with the exception of a.b.c.test that'd go to office.test. Before reading your draft I wouldnt have realized that I need to put *.a.b.c.test, *.b.c.test and *.c.test to achieve my goal. In the above example I would treat a.b.c as a one node, consisting of three labels. I have to read the 1034 once over again and I'll come back on the topic :) Everybody have a nice day! Alexis Once Edward Lewis wrote: >At 23:05 +0100 2/18/03, Alexis Yushin wrote: >>Hi, >> >>I dont like the wildcard clarification draft, what I'm saying is that I dont >>like the idea of existance of non-existing or better put >>non-explicitly-configured >>domains. It is quite non intuitive. > >I don't exactly understand the question. > >It's not what exists or doesn't exist in a protocol, the issue is >what response is generated by a query. > >In RFC 1034 there are three concepts regarding existence. > >Wild cards are tools for synthesizing answers. Whether you want to >say the an answer synthesized from a wild card represents existence >or not, the fact remains that an answer is obtained for the query. > >RFC 1034 does define an authoritative name error for queries whose >QNAME is neither a leaf with data nor an interior node. In this >case, if the node does not exist, a query against it results in an >authoritative name error (NXDOMAIN in BIND lingo). > >The third incidence of 'existence' is the impact on the algorithm in >4.3.2, section C. Given the defintion in 3.1, it's quite clear that >empty non-terminals play a role in the execution of 4.3.2-c, hence >they 'exist'. > >(I exist, ergo I impact a response, or, if a domain name falls in the >forest...) > >>What's the main driver behing this clarification draft? NXT >>processing? Certain >>implementation shortcomings? > >Someone asked me to write up text on wild cards. Apparently some >feel it is unclear from RFC 1034, I just reiterated what is in that >RFC. > >Perhaps my question is - do you think the wild card draft differs >from RFC 1034? I don't intend it to, but if that is the impression >it gives, the draft is in error. > >>Alexis >> >>-- >>to unsubscribe send a message to namedroppers-request@ops.ietf.org with >>the word 'unsubscribe' in a single line as the message text body. >>archive: > >-- >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >Edward Lewis +1-703-227-9854 >ARIN Research Engineer > > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 19 06:26:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19048 for ; Wed, 19 Feb 2003 06:26:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lSKq-0003GQ-00 for namedroppers-data@psg.com; Wed, 19 Feb 2003 03:24:20 -0800 Received: from [2001:470:1f00:ffff::5a1] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 18lSKn-0003Ds-00 for namedroppers@ops.ietf.org; Wed, 19 Feb 2003 03:24:17 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h1JBNW4U004589; Wed, 19 Feb 2003 22:23:32 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200302191123.h1JBNW4U004589@drugs.dv.isc.org> To: Alexis Yushin Cc: Edward Lewis , namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: wildcards draft In-reply-to: Your message of "Wed, 19 Feb 2003 11:25:07 BST." <200302191025.h1JAP7qQ054361@open.nlnetlabs.nl> Date: Wed, 19 Feb 2003 22:23:32 +1100 X-Spam-Status: No, hits=0.6 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02, TO_BE_REMOVED_REPLY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Edward, > > Intuitively I would expect a NXDOMAIN (in BIND language) for a domain > that I did not explicitly configure and that doesnt have any resource > data associated with it. > > *.test. MX 100 mailhost.test. > a.b.c.test. MX 100 office.test. > > As a user, the expected outcome of the above example would be to > route all the mail for *.test to mailhost.test with the exception > of a.b.c.test that'd go to office.test. > > Before reading your draft I wouldnt have realized that I need to > put *.a.b.c.test, *.b.c.test and *.c.test to achieve my goal. > > In the above example I would treat a.b.c as a one node, consisting > of three labels. I have to read the 1034 once over again and I'll > come back on the topic :) > > Everybody have a nice day! > > Alexis Alexis. The DNS is a tree structure. "a.b.c.test. MX 100 office.test" implicitly creates the parent domains (nodes) b.c.test, c.test, test and the root node. (root) | test | c | b | a Once you put the names into a tree structure what is "intuitive" changes. Also I suggest that you read RFC 1033 and RFC 1035. They are designed to be read together with RFC 1034. DNSSEC order is a alternate way to look at the zone contents but it hides the tree structure (and empty nodes) which is fundemental to understanding DNS. Mark > > > Once Edward Lewis wrote: > >At 23:05 +0100 2/18/03, Alexis Yushin wrote: > >>Hi, > >> > >>I dont like the wildcard clarification draft, what I'm saying is that I don > t > >>like the idea of existance of non-existing or better put > >>non-explicitly-configured > >>domains. It is quite non intuitive. > > >I don't exactly understand the question. > > > >It's not what exists or doesn't exist in a protocol, the issue is > >what response is generated by a query. > > > >In RFC 1034 there are three concepts regarding existence. > > > >Wild cards are tools for synthesizing answers. Whether you want to > >say the an answer synthesized from a wild card represents existence > >or not, the fact remains that an answer is obtained for the query. > > > >RFC 1034 does define an authoritative name error for queries whose > >QNAME is neither a leaf with data nor an interior node. In this > >case, if the node does not exist, a query against it results in an > >authoritative name error (NXDOMAIN in BIND lingo). > > > >The third incidence of 'existence' is the impact on the algorithm in > >4.3.2, section C. Given the defintion in 3.1, it's quite clear that > >empty non-terminals play a role in the execution of 4.3.2-c, hence > >they 'exist'. > > > >(I exist, ergo I impact a response, or, if a domain name falls in the > >forest...) > > > >>What's the main driver behing this clarification draft? NXT > >>processing? Certain > >>implementation shortcomings? > > > >Someone asked me to write up text on wild cards. Apparently some > >feel it is unclear from RFC 1034, I just reiterated what is in that > >RFC. > > > >Perhaps my question is - do you think the wild card draft differs > >from RFC 1034? I don't intend it to, but if that is the impression > >it gives, the draft is in error. > > > >>Alexis > >> > >>-- > >>to unsubscribe send a message to namedroppers-request@ops.ietf.org with > >>the word 'unsubscribe' in a single line as the message text body. > >>archive: > > > >-- > >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > >Edward Lewis +1-703-227-9854 > >ARIN Research Engineer > > > > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 19 08:47:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24856 for ; Wed, 19 Feb 2003 08:47:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lURS-00095p-00 for namedroppers-data@psg.com; Wed, 19 Feb 2003 05:39:18 -0800 Received: from [2001:470:1f00:ffff::5a1] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 18lURN-00094p-00 for namedroppers@ops.ietf.org; Wed, 19 Feb 2003 05:39:14 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h1JDcC4U004904; Thu, 20 Feb 2003 00:38:13 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200302191338.h1JDcC4U004904@drugs.dv.isc.org> To: "D. J. Bernstein" Cc: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: axfr-clarify's fraudulent claims of consensus In-reply-to: Your message of "19 Feb 2003 06:58:22 -0000." <20030219065822.50063.qmail@cr.yp.to> Date: Thu, 20 Feb 2003 00:38:12 +1100 X-Spam-Status: No, hits=0.5 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Josh Littlefield writes: > > RFC1034 clearly states that the answer section "carries RRs which > > directly answer the query." I don't see how anyone could conclude > > that AXFR clients should look for zone RRs anywhere else. > > There is overwhelming consensus that (in the absence of extended > behavior requested by the client) the AXFR _server_ must leave the > additional section and authority section empty. It must put the data > into the answer section. All existing servers work this way---and must > do so for interoperability. > > There are several perfectly valid parsing strategies for the client. > In particular, my software uses the simple strategy > > while there are records left > read a record Which can only be found by adding up the three fields in the header (number of answer records (which bind uses), number of records in the authority section and number of records in the additional section). You can't use the DNS message length as too many implementations get it wrong and leave a couple of bytes between the end of the messages as discovered by processing the records and the end of the data that is read. You have discovered this havn't you? > while BIND 9 uses the slightly more complicated strategy BIND has always used the simple strategy of reading the number from the header then processing that number of records after skipping any questions, again read from the header. > while there are records left in the answer section > read a record Let me see if I have your logic right, Simple: Read the number of questions then skip them. Read three numbers, add them up, then read this number of records. Complicated: Read the number of questions then skip them. Read one number then read this number of records. I think you have the labels the wrong way around. > Both strategies work, since servers put all records into the answer > section. Neither strategy creates any interoperability problems. There is different behaviour. That is enough reason in and of itself to clarify the issue. I don't think anyone envisioned someone that would process records outside of the answer section as answers. > There is certainly _not_ consensus on telling the _client_ to use the > BIND 9 strategy. Furthermore, any such statement (whether ``MUST'' or > ``SHOULD'') would blatantly violate RFC 2119, section 6. > > This is about the tenth time that I have had to point out the blazingly > obvious fact that constraining _server_ behavior is not the same as > constraining _client_ behavior. -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 19 13:01:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03318 for ; Wed, 19 Feb 2003 13:01:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lYMJ-000KOR-00 for namedroppers-data@psg.com; Wed, 19 Feb 2003 09:50:15 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #1) id 18lYMG-000KOF-00 for namedroppers@ops.ietf.org; Wed, 19 Feb 2003 09:50:12 -0800 Received: (qmail 55141 invoked by uid 1016); 19 Feb 2003 17:50:37 -0000 Date: 19 Feb 2003 17:50:37 -0000 Message-ID: <20030219175037.55139.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: axfr-clarify's fraudulent claims of consensus References: <20030219065822.50063.qmail@cr.yp.to> <200302191338.h1JDcC4U004904@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-0.8 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mark.Andrews@isc.org writes: > You can't use the DNS message length as too many implementations get > it wrong and leave a couple of bytes between the end of the messages > as discovered by processing the records and the end of the data that > is read. False. The Microsoft AXFR _client_ puts two extra bytes after its AXFR requests to indicate its support for multiple records per DNS packet, but the Microsoft AXFR _server_ does nothing of the sort. My AXFR client can and does use the packet length, in full compliance with RFC 1035. There are no interoperability problems here. (By the way, my DNS software is more widely deployed than Microsoft's, and much more stable, so if there were an interoperability problem then the lowest-cost solution would be to redeploy Microsoft's software. But these problems are a figment of your imagination.) > There is different behaviour. That is enough reason in and > of itself to clarify the issue. False premise, bad logic, false conclusion. These software differences don't affect interoperability, so they are none of the IETF's business. See RFC 2119, section 6. > I don't think anyone envisioned someone that would process > records outside of the answer section as answers. Read the full DNS standards, RFC 1034 and RFC 1035. Example: To save time, the additional section of an MX response usually contains A records that are reported as answers to subsequent queries. This is perfectly standard behavior not only in theory but also in practice. (To the extent that proposed standard RFC 2181 suggests otherwise, RFC 2181 is out of whack with reality, and RFC 2181 will have to be fixed.) You can't seriously promote a ``never treat additional records as answers'' religion when every major DNS cache---including BIND 9--- blatantly violates that religion. If you start adding qualifiers such as ``except in MX queries'' then your religion starts to sound really dumb. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 19 13:03:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03341 for ; Wed, 19 Feb 2003 13:03:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lYS4-000KgQ-00 for namedroppers-data@psg.com; Wed, 19 Feb 2003 09:56:12 -0800 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by psg.com with esmtp (Exim 3.36 #1) id 18lYS0-000KgC-00 for namedroppers@ops.ietf.org; Wed, 19 Feb 2003 09:56:08 -0800 Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1JHtxJR017743; Wed, 19 Feb 2003 12:56:00 -0500 (EST) Received: from cisco.com (dhcp-161-44-149-137.cisco.com [161.44.149.137]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA09274; Wed, 19 Feb 2003 12:55:58 -0500 (EST) Message-ID: <3E53C52D.3020303@cisco.com> Date: Wed, 19 Feb 2003 12:55:57 -0500 From: Josh Littlefield User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Edward Lewis CC: namedroppers@ops.ietf.org Subject: Re: empty answers References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.1 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward Lewis wrote: > When was the last time a completely empty answer (w/RCODE=0) was > intentionally implemented? > > E.g., a response to a query (in which the QCLASS and QNAME exist but > without a match for the QTYPE) that had neither a SOA RR nor a NXT RR in > the authority section? It sounds like you're asking when vendors last shipped a server that produced Type 3 NO DATA responses, as defined in RFC 2308. Cisco's currently shipping server will generate these. Our next release, due shortly, will not. -josh -- ===================================================================== Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 250 Apollo Drive tel: 978-497-8378 fax: same Chelmsford, MA 01824-3627 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 19 13:53:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04848 for ; Wed, 19 Feb 2003 13:53:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lZGB-000NK8-00 for namedroppers-data@psg.com; Wed, 19 Feb 2003 10:47:59 -0800 Received: from nat.alvestrand.no ([217.13.28.204] helo=eikenes.alvestrand.no) by psg.com with esmtp (Exim 3.36 #1) id 18lZG6-000NJl-00 for namedroppers@ops.ietf.org; Wed, 19 Feb 2003 10:47:55 -0800 Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6DD366259E; Wed, 19 Feb 2003 19:47:53 +0100 (CET) Date: Wed, 19 Feb 2003 19:47:53 +0100 From: Harald Tveit Alvestrand To: Tomson_Eric@Yahoo.fr Cc: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: Just three questions Message-ID: <582310000.1045680473@askvoll.hjemme.alvestrand.no> In-Reply-To: <002d01c2d841$726dd670$1100a8c0@tomson.be> References: <002d01c2d841$726dd670$1100a8c0@tomson.be> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On onsdag, februar 19, 2003 19:05:09 +0100 "Tomson Eric (Yahoo.fr)" wrote: > Just three questions : > > 1/does the IETF support or contest the "Inclusive Name Space" (the one > operated by NewRoot instead of the ICANN)? See RFC 2826; the IAB thinks that one root is enough. > 2/is this list reserved for all IETF-supporting people only, or is it > also open to IETF opponents/challengers? You have adressed three lists. ietf@ietf.org exists as an open forum to further the work of the IETF. Its charter can be found on http://www.ietf.org/maillist.html iesg@ietf.org exists to communicate with the Internet Engineering Steering Group (IESG). namedroppers@ops.ietf.org exists as an open forum to further the work of the DNSEXT IETF working group, described in http://www2.ietf.org/html.charters/dnsext-charter.html None of the lists restrict who can post to it (apart from spam control). On both of the open lists, repeated posting of material irrelevant to the purpose of the list can lead to your posting privilleges being restricted. This has nothing to do with what you think, or say, and everything to do with the forum in which you choose to say it. > 3/knowing that the Internet Society is the only official body amongst > all the Internet-related structures (IETF, IAB, IESG, etc.), created to > host all of them, is it decent and acceptable to dispute/oppose/mock it, > here in this list? Since the IETF list (ietf@ietf.org) is intended as a forum to disucss the policies of the IETF (among other things), reasoned opinions about the relationship between the IETF and ISOC is a valid subject for this list, no matter whether the person stating that opinion thinks that the relationship is a good thing or a bad thing. However, it would be inappropriate to the purpose of the namedroppers list. Mockery is not generally considered a reasoned form of opinion. Did this answer your question? Harald Alvestrand -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 19 14:07:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05339 for ; Wed, 19 Feb 2003 14:07:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lZSp-000O5i-00 for namedroppers-data@psg.com; Wed, 19 Feb 2003 11:01:03 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #1) id 18lZSl-000O5T-00 for namedroppers@ops.ietf.org; Wed, 19 Feb 2003 11:00:59 -0800 Received: (qmail 8909 invoked by uid 1016); 19 Feb 2003 19:01:24 -0000 Date: 19 Feb 2003 19:01:24 -0000 Message-ID: <20030219190124.8908.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: axfr-clarify breaking RFC 1034 References: <20030219054454.19702.qmail@cr.yp.to> <20030215110946.67446.qmail@cr.yp.to> <200302151239.h1FCdCd6028798@drugs.dv.isc.org> <20030217204351.GB16887@thales.memphis.edu> <3E5156B7.3060508@daimlerchrysler.com> <5419.1045647743@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Robert Elz writes: > If you have a proposal for some method to actually cause the parent/child > delegation to *always* be compatible (glue in parent matches records in > child, always), then please don't keep it a secret Read about timestamps in http://cr.yp.to/djbdns/tinydns-data.html. It's not my fault that BIND can't handle this trivial synchronization. If you're trying to say that the RFC 1034 requirement should be loosened to allow semi-synchronized changes (parent zone is changed after all the child servers have changed), go ahead and make that proposal in DNSEXT, and we'll discuss it. But don't try to sneak it past us as part of an ``AXFR clarification.'' ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 19 15:20:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07576 for ; Wed, 19 Feb 2003 15:20:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lad5-0001sa-00 for namedroppers-data@psg.com; Wed, 19 Feb 2003 12:15:43 -0800 Received: from as7-2-2.bn.g.bonet.se ([217.215.21.151] helo=poledra) by psg.com with esmtp (Exim 3.36 #1) id 18lad1-0001sO-00 for namedroppers@ops.ietf.org; Wed, 19 Feb 2003 12:15:39 -0800 Received: from amalthea.8in.net ([192.168.242.14] helo=amalthea) by poledra with asmtp (Exim 3.35 #1 (Debian)) id 18lacz-00067N-00 for ; Wed, 19 Feb 2003 21:15:37 +0100 Message-ID: <04a201c2d853$9a4232b0$0ef2a8c0@amalthea> From: =?iso-8859-1?Q?Kandra_Nyg=E5rds?= To: References: <20030219065822.50063.qmail@cr.yp.to> <200302191338.h1JDcC4U004904@drugs.dv.isc.org> <20030219175037.55139.qmail@cr.yp.to> Subject: Re: axfr-clarify's fraudulent claims of consensus Date: Wed, 19 Feb 2003 21:14:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_OE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit From: "D. J. Bernstein" > Read the full DNS standards, RFC 1034 and RFC 1035. Example: To save > time, the additional section of an MX response usually contains A > records that are reported as answers to subsequent queries. This is > perfectly standard behavior not only in theory but also in practice. The query is for MX. The answer section contains MX, which is correct. The response usually contains one or more A records in the additional section, which are NOT part of the answer but served as additional data as a convinience. A query for AXFR would similarily contain the response to the query in the answer section. As a convenience, servers might add additional data in the additional section, but those are NOT part of the answer and should not be treated as such. Easy enough for you to understand? - Kandra -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 19 15:53:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08556 for ; Wed, 19 Feb 2003 15:53:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lb8f-0003en-00 for namedroppers-data@psg.com; Wed, 19 Feb 2003 12:48:21 -0800 Received: from momotombo.techfak.uni-bielefeld.de ([129.70.136.107]) by psg.com with esmtp (Exim 3.36 #1) id 18lb8c-0003eb-00 for namedroppers@ops.ietf.org; Wed, 19 Feb 2003 12:48:19 -0800 Received: from popocatepetl.TechFak.Uni-Bielefeld.DE (popocatepetl.TechFak.Uni-Bielefeld.DE [129.70.136.108]) by momotombo.TechFak.Uni-Bielefeld.DE (8.11.6+Sun/8.11.6/TechFak/pk+ro20010720) with ESMTP id h1JKmHD19264 for ; Wed, 19 Feb 2003 21:48:17 +0100 (MET) Received: from localhost (pk@localhost) by popocatepetl.TechFak.Uni-Bielefeld.DE (8.11.6+Sun/8.9.1) with SMTP id h1JKmGE28523 for ; Wed, 19 Feb 2003 21:48:16 +0100 (MET) Message-Id: <200302192048.h1JKmGE28523@popocatepetl.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: popocatepetl.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: popocatepetl.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org Subject: Re: axfr-clarify's fraudulent claims of consensus In-reply-to: Your message of "Wed, 19 Feb 2003 21:14:49 +0100." <04a201c2d853$9a4232b0$0ef2a8c0@amalthea> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Date: Wed, 19 Feb 2003 21:48:16 +0100 From: Peter Koch X-Spam-Status: No, hits=-1.8 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,SPAM_PHRASE_00_01, X_AUTH_WARNING version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Kandra_Nyg=E5rds wrote: > A query for AXFR would similarily contain the response to the query in the > answer section. As a convenience, servers might add additional data in the > additional section, but those are NOT part of the answer and should not be > treated as such. the draft explicitly forbids this ``might add'' in section 4 and this is OK and consistent with the general idea of producing identical copies of the zone data. Please note that the draft introduces a concept of names being ``associated'' with a zone regardless of their logical relation to the zone's content. I.e. if I add an A RR for this.is.invalid to my zone the draft expects this RR - although operationally useless - to be copied for the sake of consistency. On the other hand the draft wont allow handing out this RR in any case, so there's no operational harm caused by this, but it makes AXFR as reliable (as in: producing predictable results) as ftp, scp or pony express. Since all the data has to be evaluated for eligibility at the slave ("client") side anyway and the master has no choice in sending or not sending additional data, there's no point in sending the AXFR response in anything else but the answer section. -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. archive: From owner-namedroppers@ops.ietf.org Wed Feb 19 16:35:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09505 for ; Wed, 19 Feb 2003 16:35:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lbmX-0005uy-00 for namedroppers-data@psg.com; Wed, 19 Feb 2003 13:29:33 -0800 Received: from [2001:470:1f00:ffff::5a1] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 18lbmS-0005u2-00 for namedroppers@ops.ietf.org; Wed, 19 Feb 2003 13:29:29 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h1JLSc4U005926; Thu, 20 Feb 2003 08:28:38 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200302192128.h1JLSc4U005926@drugs.dv.isc.org> To: "D. J. Bernstein" Cc: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: axfr-clarify's fraudulent claims of consensus In-reply-to: Your message of "19 Feb 2003 17:50:37 -0000." <20030219175037.55139.qmail@cr.yp.to> Date: Thu, 20 Feb 2003 08:28:38 +1100 X-Spam-Status: No, hits=0.9 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, TO_BE_REMOVED_REPLY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Mark.Andrews@isc.org writes: > > You can't use the DNS message length as too many implementations get > > it wrong and leave a couple of bytes between the end of the messages > > as discovered by processing the records and the end of the data that > > is read. > > False. The Microsoft AXFR _client_ puts two extra bytes after its AXFR > requests to indicate its support for multiple records per DNS packet, > but the Microsoft AXFR _server_ does nothing of the sort. My AXFR client > can and does use the packet length, in full compliance with RFC 1035. > There are no interoperability problems here. Well you havn't struck the servers that get this calculation wrong yet. However I don't find that suprising as your server really isn't designed to with AXFR in mind. > (By the way, my DNS software is more widely deployed than Microsoft's, > and much more stable, so if there were an interoperability problem then > the lowest-cost solution would be to redeploy Microsoft's software. But > these problems are a figment of your imagination.) I never said that Microsoft was the responible vendor. I've never bothered to find the name of the vendor. > > There is different behaviour. That is enough reason in and > > of itself to clarify the issue. > > False premise, bad logic, false conclusion. These software differences > don't affect interoperability, so they are none of the IETF's business. > See RFC 2119, section 6. But it does affect interopability with servers that get things slightly wrong. You can't trust the UDP length and you can't trust the TCP message size to find the end of reply received. There are servers that get these calculations wrong. > > I don't think anyone envisioned someone that would process > > records outside of the answer section as answers. > > Read the full DNS standards, RFC 1034 and RFC 1035. Example: To save > time, the additional section of an MX response usually contains A > records that are reported as answers to subsequent queries. This is > perfectly standard behavior not only in theory but also in practice. The additional section does NOT contain the answer. It contains other data that may be related however it is not part of the answer to the question an is not treated as such. > (To the extent that proposed standard RFC 2181 suggests otherwise, RFC > 2181 is out of whack with reality, and RFC 2181 will have to be fixed.) > > You can't seriously promote a ``never treat additional records as > answers'' religion when every major DNS cache---including BIND 9--- > blatantly violates that religion. If you start adding qualifiers such as > ``except in MX queries'' then your religion starts to sound really dumb. We selectively cache the contents of the additional section. We also reject what shouldn't be there or what we don't trust the current server to give us. Mark > ---D. J. Bernstein, Associate Professor, Department of Mathematics, > Statistics, and Computer Science, University of Illinois at Chicago > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 19 16:36:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09575 for ; Wed, 19 Feb 2003 16:36:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lbfa-0005Ws-00 for namedroppers-data@psg.com; Wed, 19 Feb 2003 13:22:22 -0800 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #1) id 18lbfT-0005WZ-00 for namedroppers@ops.ietf.org; Wed, 19 Feb 2003 13:22:15 -0800 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id QAA04672; Wed, 19 Feb 2003 16:18:43 -0500 Date: Wed, 19 Feb 2003 16:20:03 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Andreas Gustafsson cc: Mark.Andrews@isc.org, Namedroppers , Subject: Re: Bind 9 AXFR Modification vs AXFR Clarification In-Reply-To: <200302190251.h1J2pwG28755@guava.araneus.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,SPAM_PHRASE_01_02,USER_AGENT_PINE, X_OSIRU_SPAM_SRC version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 18 Feb 2003, Andreas Gustafsson wrote: > Dean Anderson writes: > > Zone definition and content is not an AXFR issue. Server administrators > > provide the definition of zone boundaries. (RFC 1034 Section 2.3 and > > elsewhere) AXFR merely gives the contents of the zone as has been defined > > according to the boundaries and content specified by the administrator. > > This is exactly what the draft says, so what are you disagreeing with? Uhh, no. Draft 05 says quite a bit more. It subtly changes a number of things that shouldn't be, and don't need to be changed. In fact, looking at my copy, it doesn't say anything like the above at all. (But assuming it did, it would be redundant and could be deleted). Perhaps we don't have the same copy of the file. My copy was printed from www.ietf.org/internet-drafts/draft-ietf-dnsext-axfr-clarify-05.txt. I disagree with everything in the draft that deviates from the common assumptions made by implementations besides Bind 9. Specifically, (and I'll try to be complete, but this is just off the cuff for this message) The second paragraph of Section 2 should be deleted. Specific implementations are not to be mentioned in RFC's. In section 3, where it says "MUST" it should say "MAY", and where it says "MAY", it should say "MUST". Section 3.1 seems like a good idea, however, it is a modification to AXFR, and should have a new request code. I suggest calling it MAXFR and giving it code 253. Support for this request code should be optional, and a server may respond using the original (one record per message) AXFR method. Upon discovering non-implemenation, clients should fall back to AXFR or fail as determined by implementation or configuration. Section 3.3 should be deleted. This is up to the administator and/or the implementation. SIG processing is not addressed, neither by when the server should put them in, nor by what the client should do with them if present. Section 3.4 should be deleted. Section 3.5 and 3.6 should be deleted. Data can come in either authority or additional sections. There are no transaction signatures, except for id, question, and serial number. Section 4 should be deleted. Clearly, glue records need to be merged in. Section 5 paragraph 3 should be deleted except for the first sentence. In the forth paragraph, where it says "MUST", should say "MAY". Clearly, duplicate records may indicate a misconfiguration, and their presence in a zone can indicate a problem. Or not. It is up to the administrators to determine how they configure there servers, and to configure those servers consistently. Section 6 should be deleted. The status of these other RFCs is not to be altered except by appropriate standardization process. This is an inappropriate end-run around that process. Whether zone data is public is an administrative decision not limited by RFC. Administrators are free to place or implement whatever restrictions they wish on domain name records, and such administrative restrictions are not limited to only zone transfer restriction. They can, for example, be limited by node or record type, or any other way that can be invented and found useful. > The issue with BIND 8 is that it does *not* give the contents of the > zone according to the boundaries and content specified by the zone > administrator, but instead a mixture of data from different zones as > specified by their different administrators. Perhaps. Perhaps not. However, that would be an implementation issue, not relevant to AXFR, or to the protocol. Section 4.2 of 1034 says "it would be possible to partition the name space so that each domain name was in a separate zone... In some cases, such divisions are made purely to make database maintenance more convenient." There is a huge amount of latitude on the administration of zone boundaries. Clearly, one has to be able to merge in glue records. These records are specified by the administrator, and so merging is appropriate. If the administrator specifies them inconsistently, they may be inconsistent. No surprise there. That is the ultimately the administrator's fault. It may not be possible for a secondary to detect such misconfiguration in the master. --Dean -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 19 16:41:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09712 for ; Wed, 19 Feb 2003 16:41:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lbud-0006OA-00 for namedroppers-data@psg.com; Wed, 19 Feb 2003 13:37:55 -0800 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #1) id 18lbuZ-0006Mw-00 for namedroppers@ops.ietf.org; Wed, 19 Feb 2003 13:37:51 -0800 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id QAA28236; Wed, 19 Feb 2003 16:30:46 -0500 Date: Wed, 19 Feb 2003 16:32:01 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Mark.Andrews@isc.org cc: mw-list-namedroppers@csi.hu, Name Droppers , , Subject: Re: Bind 9 AXFR Modification vs AXFR Clarification In-Reply-To: <200302190342.h1J3gM4U003505@drugs.dv.isc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,SPAM_PHRASE_01_02,USER_AGENT_PINE, X_OSIRU_SPAM_SRC version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 19 Feb 2003 Mark.Andrews@isc.org wrote: > > All the IXFR server needs to do is determine (by some implementation > > dependent, administrator maintained method) what has changed between one > > zone version and another. How it does this is nobody's business but the > > administrator and the implementor. There are infinite possibilities, here. > > One could, for example, store differences in a series of files. The > > administrator could even make the differnce files by hand--this is an > > _implementation detail_. The IXFR server just sends a series or sequences > > consisting of a list of deleted RRs and a list of added RRs to an IXFR > > client. There is nothing more to it. (notwithstanding the optional > > condensation.) > > All of which is irrelevent to this issue. THAT's what I have been saying. You were the one who said we needed to do this to support IXFR. I've been saying that claim was wrong. Thanks for FINALLY coming round to that. > > The IXFR client must simply make the changes (again, by some > > implementation dependent, administrator maintained method) to the zone by > > deleting RRs and adding RR's in each sequence. The original version of the > > zone might have been obtained by FTP (or quantum interference, or the > > psychic network) for all we know. > > Well the problem is that you have to get the *original* version, > not a corrupted version. AXFR implementations are not returning > the data originally entered. They sure have been. > > This isn't rocket science, and doesn't require any AXFR changes. Nor does > > it require that the zone boundaries be defined only in some certain way, > > beyond the definition of zone boundaries given by the system > > administrator. > > It does however require that for a given serial number that all > sources of the zone have supplied identical contents. You should > be able to apply a IXFR delta to a copy derived from any source > and have it apply without error. None of this is relevant. All that is necessary is to delete the RRs, and insert the RRs in the sequence. If the zones are inconsistent through administrative mistake, then it won't matter what the IXFR does. > > > > Some people, many associated with Bind 9 development, assert that AXFR as > > > > commonly implemented by many implementors over many years, is broken, and > > > > can't transfer domains correctly. This claim has been refuted by > > > > demonstration by interoperability between Bind 8 and other nameserver > > > > implementations over the years, and 77% of the internet that currently > > > > does not use Bind 9, yet still does AXFR. > > > > > > All this shows is that these nameservers are not used in > > > situations where the breakage is demonstrated or the > > > administators have learn to work around the breakage or > > > choose to live with it or are unaware of it. > > > > "administrators have learn[ed] to work around [it,...] live with it [,] or > > are unaware of it". Agreed. Having done so, we don't want to stir the > > pot. > > LOL. Strange, that was my reaction, too. I'm just trying to be polite. 77% work just fine. We don't want to break 77% of the servers out there. > > Essentially, you are putting more (unnecessary) constraints on > > implementations, and thus on the administrators, who are supposed to be > > pretty free to define the zone boundaries. Of course, the specifics of an > > implementation puts some constraints on the adminstrator, but the > > administrator can choose a different implementation more to her liking. > > The constaint was already there and it is necessary for reliable > operation of the DNS. No, you ware not being honest about the contents of the Draft. See my last message to Andreas. > > > > To prevent confusion between the two proposals, I would like to rename th > > e > > > > first proposal "Bind 9 AXFR Modification", and the second proposal "AXFR > > > > Clarification". The term "axfr-clarify" will not be used. > > > > I presume agreement on the name change? > > No. Then the entire draft should be rejected since it is misleading. Please resubmit a proposal that isn't misleading the community about its purpose, impact, and contents. --Dean -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 19 18:31:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12772 for ; Wed, 19 Feb 2003 18:31:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ldXO-000CW4-00 for namedroppers-data@psg.com; Wed, 19 Feb 2003 15:22:02 -0800 Received: from [2001:470:1f00:ffff::5a1] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 18ldXI-000CUi-00 for namedroppers@ops.ietf.org; Wed, 19 Feb 2003 15:21:56 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h1JNL94U006491; Thu, 20 Feb 2003 10:21:10 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200302192321.h1JNL94U006491@drugs.dv.isc.org> To: "D. J. Bernstein" Cc: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: axfr-clarify breaking RFC 1034 In-reply-to: Your message of "19 Feb 2003 19:01:24 -0000." <20030219190124.8908.qmail@cr.yp.to> Date: Thu, 20 Feb 2003 10:21:09 +1100 X-Spam-Status: No, hits=0.5 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Robert Elz writes: > > If you have a proposal for some method to actually cause the parent/child > > delegation to *always* be compatible (glue in parent matches records in > > child, always), then please don't keep it a secret > > Read about timestamps in http://cr.yp.to/djbdns/tinydns-data.html. It's > not my fault that BIND can't handle this trivial synchronization. > > If you're trying to say that the RFC 1034 requirement should be loosened > to allow semi-synchronized changes (parent zone is changed after all the > child servers have changed), go ahead and make that proposal in DNSEXT, > and we'll discuss it. But don't try to sneak it past us as part of an > ``AXFR clarification.'' Semi-synchronized changes have always been part of the DNS. Anyone who believes otherwise is deluding themselves. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 19 18:41:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12913 for ; Wed, 19 Feb 2003 18:41:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ldhy-000DEV-00 for namedroppers-data@psg.com; Wed, 19 Feb 2003 15:32:58 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18ldhu-000DDQ-00 for namedroppers@ops.ietf.org; Wed, 19 Feb 2003 15:32:54 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18ldht-0007b2-00 for namedroppers@ops.ietf.org; Thu, 20 Feb 2003 08:32:53 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Organization: Eric Tomson Message-ID: <002d01c2d841$726dd670$1100a8c0@tomson.be> From: "Tomson Eric \(Yahoo.fr\)" To: "'Harald Tveit Alvestrand'" Cc: , , Subject: Just three questions Date: Wed, 19 Feb 2003 19:05:09 +0100 X-Spam-Status: No, hits=0.4 required=5.0 tests=NOSPAM_INC,RESENT_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Just three questions : 1/does the IETF support or contest the "Inclusive Name Space" (the one operated by NewRoot instead of the ICANN)? 2/is this list reserved for all IETF-supporting people only, or is it also open to IETF opponents/challengers? 3/knowing that the Internet Society is the only official body amongst all the Internet-related structures (IETF, IAB, IESG, etc.), created to host all of them, is it decent and acceptable to dispute/oppose/mock it, here in this list? Just asking... ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en fran=E7ais ! Yahoo! Mail : http://fr.mail.yahoo.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. archive: From owner-namedroppers@ops.ietf.org Wed Feb 19 18:45:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12972 for ; Wed, 19 Feb 2003 18:45:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ldlU-000DTS-00 for namedroppers-data@psg.com; Wed, 19 Feb 2003 15:36:36 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18ldlR-000DTG-00 for namedroppers@ops.ietf.org; Wed, 19 Feb 2003 15:36:34 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18ldlQ-0008Oq-00 for namedroppers@ops.ietf.org; Thu, 20 Feb 2003 08:36:32 +0900 In-Reply-To: <002d01c2d841$726dd670$1100a8c0@tomson.be> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Date: Wed, 19 Feb 2003 01:28:15 -0500 (EST) From: shogunx To: "Tomson Eric (Yahoo.fr)" cc: "'Harald Tveit Alvestrand'" , , , Subject: Re: Just three questions X-Spam-Status: No, hits=-2.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RESENT_TO, SPAM_PHRASE_03_05,USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id SAA12972 [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] On Wed, 19 Feb 2003, Tomson Eric (Yahoo.fr) wrote: > Just three questions : > > 1/does the IETF support or contest the "Inclusive Name Space" (the one > operated by NewRoot instead of the ICANN)? Dont forget the opennic www.opennic.unrated.net the pacificroot pacificroot.org or the open root server consortium www.open-rsc.org when addressing the topic of alternative root servers. Notwithstanding, the IETF is made up of individuals, each with their own perspectives and opinions. > > 2/is this list reserved for all IETF-supporting people only, or is it > also open to IETF opponents/challengers? > Without this list, and the IETF, you would not be able to send the email I am responding to. > 3/knowing that the Internet Society is the only official body amongst > all the Internet-related structures (IETF, IAB, IESG, etc.), created to > host all of them, is it decent and acceptable to dispute/oppose/mock it, > here in this list? > Dispute all you want, if the topic is valid. Oppose whatever you choose. It is never a wise idea, however, to mock on of the most intelligent collections of individuals on the planet. Just a word to the wise. Scott > Just asking... > > ___________________________________________________________ > Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! > Yahoo! Mail : http://fr.mail.yahoo.com > > sleekfreak pirate broadcast world tour 2002-3 live from daytona beach http://sleekfreak.ath.cx -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 19 19:05:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13440 for ; Wed, 19 Feb 2003 19:05:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18le6m-000Elj-00 for namedroppers-data@psg.com; Wed, 19 Feb 2003 15:58:36 -0800 Received: from [2001:470:1f00:ffff::5a1] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 18le6i-000ElQ-00 for namedroppers@ops.ietf.org; Wed, 19 Feb 2003 15:58:33 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h1JNuj4U006653; Thu, 20 Feb 2003 10:56:47 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200302192356.h1JNuj4U006653@drugs.dv.isc.org> To: Dean Anderson Cc: mw-list-namedroppers@csi.hu, Name Droppers , ietf@ietf.org, iesg@ietf.org From: Mark.Andrews@isc.org Subject: Re: Bind 9 AXFR Modification vs AXFR Clarification In-reply-to: Your message of "Wed, 19 Feb 2003 16:32:01 CDT." Date: Thu, 20 Feb 2003 10:56:45 +1100 X-Spam-Status: No, hits=0.2 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > > On Wed, 19 Feb 2003 Mark.Andrews@isc.org wrote: > > > > All the IXFR server needs to do is determine (by some implementation > > > dependent, administrator maintained method) what has changed between one > > > zone version and another. How it does this is nobody's business but the > > > administrator and the implementor. There are infinite possibilities, here > . > > > One could, for example, store differences in a series of files. The > > > administrator could even make the differnce files by hand--this is an > > > _implementation detail_. The IXFR server just sends a series or sequences > > > consisting of a list of deleted RRs and a list of added RRs to an IXFR > > > client. There is nothing more to it. (notwithstanding the optional > > > condensation.) > > > > All of which is irrelevent to this issue. > > THAT's what I have been saying. You were the one who said we needed to do > this to support IXFR. I've been saying that claim was wrong. Thanks for > FINALLY coming round to that. > > > > The IXFR client must simply make the changes (again, by some > > > implementation dependent, administrator maintained method) to the zone by > > > deleting RRs and adding RR's in each sequence. The original version of th > e > > > zone might have been obtained by FTP (or quantum interference, or the > > > psychic network) for all we know. > > > > Well the problem is that you have to get the *original* version, > > not a corrupted version. AXFR implementations are not returning > > the data originally entered. > > They sure have been. Not always. > > > This isn't rocket science, and doesn't require any AXFR changes. Nor does > > > it require that the zone boundaries be defined only in some certain way, > > > beyond the definition of zone boundaries given by the system > > > administrator. > > > > It does however require that for a given serial number that all > > sources of the zone have supplied identical contents. You should > > be able to apply a IXFR delta to a copy derived from any source > > and have it apply without error. > > None of this is relevant. All that is necessary is to delete the RRs, and > insert the RRs in the sequence. > > If the zones are inconsistent through administrative mistake, then it > won't matter what the IXFR does. Who said anything administrative mistakes? The content is being unilaterally changed by the servers. > > > > > Some people, many associated with Bind 9 development, assert that AXF > R as > > > > > commonly implemented by many implementors over many years, is broken, > and > > > > > can't transfer domains correctly. This claim has been refuted by > > > > > demonstration by interoperability between Bind 8 and other nameserver > > > > > implementations over the years, and 77% of the internet that currentl > y > > > > > does not use Bind 9, yet still does AXFR. > > > > > > > > All this shows is that these nameservers are not used in > > > > situations where the breakage is demonstrated or the > > > > administators have learn to work around the breakage or > > > > choose to live with it or are unaware of it. > > > > > > "administrators have learn[ed] to work around [it,...] live with it [,] o > r > > > are unaware of it". Agreed. Having done so, we don't want to stir the > > > pot. > > > > LOL. > > Strange, that was my reaction, too. I'm just trying to be polite. 77% > work just fine. We don't want to break 77% of the servers out there. You really think that it will break those servers? LOL. > > > Essentially, you are putting more (unnecessary) constraints on > > > implementations, and thus on the administrators, who are supposed to be > > > pretty free to define the zone boundaries. Of course, the specifics of a > n > > > implementation puts some constraints on the adminstrator, but the > > > administrator can choose a different implementation more to her liking. > > > > The constaint was already there and it is necessary for reliable > > operation of the DNS. > > No, you ware not being honest about the contents of the Draft. See my last > message to Andreas. The abstract say: This memo clarifies, updates, and adds missing detail to the original AXFR protocol specification in RFC1034. I fail to see how the contents can be deemed misleading when it states up front what it does. Woops we missed warning you up front that it contains a warning. > > > > > To prevent confusion between the two proposals, I would like to renam > e th > > > e > > > > > first proposal "Bind 9 AXFR Modification", and the second proposal "A > XFR > > > > > Clarification". The term "axfr-clarify" will not be used. > > > > > > I presume agreement on the name change? > > > > No. > > Then the entire draft should be rejected since it is misleading. Please > resubmit a proposal that isn't misleading the community about its purpose, > impact, and contents. > > --Dean -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 19 19:11:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13644 for ; Wed, 19 Feb 2003 19:11:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18leFO-000FLN-00 for namedroppers-data@psg.com; Wed, 19 Feb 2003 16:07:30 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #1) id 18leFL-000FL4-00 for namedroppers@ops.ietf.org; Wed, 19 Feb 2003 16:07:27 -0800 Received: (qmail 38145 invoked by uid 1016); 20 Feb 2003 00:07:52 -0000 Date: 20 Feb 2003 00:07:52 -0000 Message-ID: <20030220000752.38144.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: axfr-clarify breaking RFC 1034 References: <20030219190124.8908.qmail@cr.yp.to> <200302192321.h1JNL94U006491@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=0.3 required=5.0 tests=REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mark.Andrews@isc.org writes: > Semi-synchronized changes have always been part of the DNS. If there's an honest proposal to modify the DNS specifications to allow semi-synchronized changes (once again: parent zone being changed after all the child servers have changed), perhaps the discussion will reveal that those changes work with BIND 4, BIND 8, djbdns, etc.; that those changes are useful; and that nobody objects to this modification. On the other hand, if there's an honest proposal to modify the DNS specifications to allow _unsychronized_ changes (such as your asinine configuration examples), the discussion will reveal that those changes do _not_ work with the majority of DNS servers on the Internet, that those changes are _not_ useful, and that the modification is a bad idea. What we have here is much worse: a thoroughly dishonest attempt to slip the latter modification past us as part of an ``AXFR clarification.'' Anyone with a shred of integrity should be opposing this fraud. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 19 21:36:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16323 for ; Wed, 19 Feb 2003 21:36:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lgQ7-000NnR-00 for namedroppers-data@psg.com; Wed, 19 Feb 2003 18:26:43 -0800 Received: from [2001:470:1f00:ffff::5a1] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 18lgQ3-000Nmo-00 for namedroppers@ops.ietf.org; Wed, 19 Feb 2003 18:26:40 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h1K2Pp4U007052; Thu, 20 Feb 2003 13:25:52 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200302200225.h1K2Pp4U007052@drugs.dv.isc.org> To: "D. J. Bernstein" Cc: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: axfr-clarify breaking RFC 1034 In-reply-to: Your message of "20 Feb 2003 00:07:52 -0000." <20030220000752.38144.qmail@cr.yp.to> Date: Thu, 20 Feb 2003 13:25:51 +1100 X-Spam-Status: No, hits=1.3 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_05_08 version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Mark.Andrews@isc.org writes: > > Semi-synchronized changes have always been part of the DNS. > > If there's an honest proposal to modify the DNS specifications to allow > semi-synchronized changes (once again: parent zone being changed after > all the child servers have changed), perhaps the discussion will reveal > that those changes work with BIND 4, BIND 8, djbdns, etc.; that those > changes are useful; and that nobody objects to this modification. > > On the other hand, if there's an honest proposal to modify the DNS > specifications to allow _unsychronized_ changes (such as your asinine > configuration examples), the discussion will reveal that those changes > do _not_ work with the majority of DNS servers on the Internet, that > those changes are _not_ useful, and that the modification is a bad idea. > > What we have here is much worse: a thoroughly dishonest attempt to slip > the latter modification past us as part of an ``AXFR clarification.'' > Anyone with a shred of integrity should be opposing this fraud. If you want synchronized changes in the parent and child zones you need to write up a draft to explain how to do it. The current DNS does not have this capability. I would suggest that you will need to add inception and expiration times as meta data for each RR. I will be happy to review the draft when you make it available. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 19 22:47:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18203 for ; Wed, 19 Feb 2003 22:47:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lhaR-0002Gd-00 for namedroppers-data@psg.com; Wed, 19 Feb 2003 19:41:27 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #1) id 18lhaN-0002GQ-00 for namedroppers@ops.ietf.org; Wed, 19 Feb 2003 19:41:23 -0800 Received: (qmail 14685 invoked by uid 1016); 20 Feb 2003 03:41:48 -0000 Date: 20 Feb 2003 03:41:48 -0000 Message-ID: <20030220034148.14684.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: axfr-clarify breaking RFC 1034 References: <20030220000752.38144.qmail@cr.yp.to> <200302200225.h1K2Pp4U007052@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=0.0 required=5.0 tests=REFERENCES,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Here's a chart summarizing the situation: Timing of |Useful in|RFC 1034 |BIND 8 |BIND 9 |tinydns data change |practice |compliant|support|support|support ------------------+---------+---------+-------+-------+------- Synchronized |Yes |Yes |No |No |Yes Semi-synchronized |Yes |No |Yes |Yes |Yes Unsynchronized |No |No |No |Yes |No The BIND company observes that * synchronized changes are hard to do with BIND, even though they're required by RFC 1034; and * unsynchronized changes can fail miserably with BIND 8 et al., which account for the majority of DNS servers. The obvious solution is semi-synchronized changes, which work with the entire installed base. I wouldn't object to modifying RFC 1034 to allow semi-synchronized changes. (To repeat the relevant definitions: A synchronized change happens at the same time in all the parent servers and all the child servers. A semi-synchronized change happens in the parent zone---specifically, the parent serial is changed---after it happens in all the child servers.) I certainly _do_ object to allowing unsynchronized changes. They don't work correctly with the installed base, and they have no advantages over semi-synchronized changes. It's insane to demand massive redeployment of DNS servers for the sake of a useless protocol modification. Mark.Andrews@isc.org writes: > you need to write up a draft _I_ don't need to write anything. I am not the one trying to change the requirements in RFC 1034. My software follows the spec. _Your_ company is trying to impose requirements that aren't in RFC 1034. You are claiming that most DNS server installations on the Internet have to be changed. You are demanding that we tolerate configurations that violate RFC 1034. Even worse, instead of honestly proposing this protocol change, you are trying to sneak it past us as part of an ``AXFR clarification''; and someone who has been paid for BIND work is abusing his position as WG chair by fraudulently claiming ``consensus.'' This is a sham. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 20 00:52:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20203 for ; Thu, 20 Feb 2003 00:52:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ljUD-0009nZ-00 for namedroppers-data@psg.com; Wed, 19 Feb 2003 21:43:09 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 18ljUB-0009nM-00 for namedroppers@ops.ietf.org; Wed, 19 Feb 2003 21:43:07 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h1K5gnqn034767; Thu, 20 Feb 2003 00:42:49 -0500 (EST) Received: from [220.128.48.115] ([192.136.136.76]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id AAA05391; Thu, 20 Feb 2003 00:42:47 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@ops Message-Id: In-Reply-To: <3E53C52D.3020303@cisco.com> References: <3E53C52D.3020303@cisco.com> Date: Thu, 20 Feb 2003 13:42:01 +0800 To: Josh Littlefield From: Edward Lewis Subject: Re: empty answers Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 12:55 -0500 2/19/03, Josh Littlefield wrote: >Edward Lewis wrote: >> When was the last time a completely empty answer (w/RCODE=0) was >>intentionally implemented? >> E.g., a response to a query (in which the QCLASS and QNAME exist >>but without a match for the QTYPE) that had neither a SOA RR nor a >>NXT RR in the authority section? > >It sounds like you're asking when vendors last shipped a server that >produced Type 3 NO DATA responses, as defined in RFC 2308. Exactly... >Cisco's currently shipping server will generate these. Our next >release, due shortly, will not. Thanks... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 20 01:24:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20932 for ; Thu, 20 Feb 2003 01:24:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lk03-000BnF-00 for namedroppers-data@psg.com; Wed, 19 Feb 2003 22:16:03 -0800 Received: from [2001:470:1f00:ffff::5a1] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 18ljzz-000Blo-00 for namedroppers@ops.ietf.org; Wed, 19 Feb 2003 22:16:00 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h1K6Ev4U007655; Thu, 20 Feb 2003 17:14:57 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200302200614.h1K6Ev4U007655@drugs.dv.isc.org> To: "D. J. Bernstein" Cc: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: axfr-clarify breaking RFC 1034 In-reply-to: Your message of "20 Feb 2003 03:41:48 -0000." <20030220034148.14684.qmail@cr.yp.to> Date: Thu, 20 Feb 2003 17:14:57 +1100 X-Spam-Status: No, hits=0.2 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Here's a chart summarizing the situation: > > Timing of |Useful in|RFC 1034 |BIND 8 |BIND 9 |tinydns > data change |practice |compliant|support|support|support > ------------------+---------+---------+-------+-------+------- > Synchronized |Yes |Yes |No |No |Yes > Semi-synchronized |Yes |No |Yes |Yes |Yes > Unsynchronized |No |No |No |Yes |No This is not a accurate summary. > The BIND company observes that > > * synchronized changes are hard to do with BIND, even though they're > required by RFC 1034; and RFC 1034 requires the *administators* to keep the glue in sync. Section 4.2.2. Administrative considerations As the last installation step, the delegation NS RRs and glue RRs necessary to make the delegation effective should be added to the parent zone. The administrators of both zones should insure that the NS and glue RRs which mark both sides of the cut are consistent and remain so. This is a administrative action. If you can automate administrative actions well and good. Using a single file for all your PRIMARY zones is actually a useful way to partially achieve this. It will keep all PRIMARY zones on the server in sync. If you wish you can copy the contents of a SECONDARY into a PRIMARY provided you also change the SERIAL of the PRIMARY to reflect the change. I wouldn't encorage this as a default action however. However changing the contents of SECONDARY zones is not allowed. That action needs to be performed through the PRIMARY server for the zone. UPDATE could be used to facilitate this. Again I would not encourage this as a default action. A server ceases to be a SECONDARY if it changes the zones contents. > * unsynchronized changes can fail miserably with BIND 8 et al., which > account for the majority of DNS servers. Which is why we fixed our server. > The obvious solution is semi-synchronized changes, which work with the > entire installed base. I wouldn't object to modifying RFC 1034 to allow > semi-synchronized changes. You have to be kidding. Even if we were to go down that path (which I don't believe we should) it still leaves servers with the underlying problem in that they are not serving the zone contents as entered. > (To repeat the relevant definitions: A synchronized change happens at > the same time in all the parent servers and all the child servers. A > semi-synchronized change happens in the parent zone---specifically, the > parent serial is changed---after it happens in all the child servers.) > > I certainly _do_ object to allowing unsynchronized changes. They don't > work correctly with the installed base, and they have no advantages over > semi-synchronized changes. It's insane to demand massive redeployment of > DNS servers for the sake of a useless protocol modification. Nobody is demanding a massive redeployment. None of the changes require a massive redeployment. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 20 04:53:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05754 for ; Thu, 20 Feb 2003 04:53:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lnH5-000L8e-00 for namedroppers-data@psg.com; Thu, 20 Feb 2003 01:45:51 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #1) id 18lnH3-000L8S-00 for namedroppers@ops.ietf.org; Thu, 20 Feb 2003 01:45:49 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA25387; Thu, 20 Feb 2003 02:45:47 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h1K9jkP18199; Thu, 20 Feb 2003 10:45:46 +0100 (MET) Date: Thu, 20 Feb 2003 10:42:02 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: DNSEXT WGLC Summary: RFC1886bis-01 To: Mark.Andrews@isc.org Cc: Erik Nordmark , namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" <200302132232.h1DMWFd6020543@drugs.dv.isc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > * CNAME records (not mentioned in RFC1886) > > CNAME records do not cause additional section processing. > > > * PTR records (mentioned in RFC1886, but not explicitly) > > PTR records do not cause additional section processing. > > > * SRV records (not mentioned in RFC1886) > > SRV records do have additional section processing involving > address records. > > > * SOA records (not mentioned in RFC1886) > > SOA records cause KEY record additional section processing. > They do not cause address records to be added despite what > Microsoft does. It seems like the interoperability report for 1886bis should be clarified based on the above. And that the 1886bis document should mention SRV record additional section processing. 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. archive: From owner-namedroppers@ops.ietf.org Thu Feb 20 05:17:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06352 for ; Thu, 20 Feb 2003 05:17:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lnhS-000M92-00 for namedroppers-data@psg.com; Thu, 20 Feb 2003 02:13:06 -0800 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #1) id 18lnhO-000M8a-00; Thu, 20 Feb 2003 02:13:03 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA27162; Thu, 20 Feb 2003 03:13:00 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h1KACxP20671; Thu, 20 Feb 2003 11:12:59 +0100 (MET) Date: Thu, 20 Feb 2003 11:09:15 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: draft-ietf-dnsext-unknown-rrs-04.txt To: Andreas Gustafsson Cc: Erik Nordmark , Andreas Gustafsson , ogud@ogud.com, randy@psg.com, namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" <200302141828.h1EISC210840@guava.araneus.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > Note that after RFC 2931 there has been no RR types defined which have > > an embedded domain name. > > This is exactly the kind of statement regarding "defined RRs" I have > already repeatedly objected to adding. It is true today, but will > become false as soon as additional RR types with embedded domain names > are defined, and would cause nothing but confusion to an implementor > reading it ten years from no. Such a statement does not belong in an > archival document. Please suggest alternate text that captures the fact that this section doesn't change any RR that is currently issued in an RFC and that the intent is that no future RRs with embedded domain names have this behavior. > > It is expected that future definitions of > > RR types will explicitly state that there is no downcasing of embedded > > domain names as part of DNSSEC canonicalization. > > That is not my expectation. There is a precedent for explicit > statements regarding the applicability of *compression*, but that is > only because RFC1035 was so ambiguous about where compression was > allowed that it had to be specified in the individual RR type > definitions (and even then some RR definitions interpreted RFC1035 > differently from others). In the case of DNSSEC canonicalization, I > hope the specification will be complete and unambiguous so that we > don't have to resort to that kind of workaround. I don't understand. I thought you wanted to specify rules to make unmodified servers/caches be able to handle new RR types. How can you do that if you allow future RR types to specify different DNSSEC canonicalization rules? 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. archive: From owner-namedroppers@ops.ietf.org Thu Feb 20 07:45:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09921 for ; Thu, 20 Feb 2003 07:45:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lpzB-0000j2-00 for namedroppers-data@psg.com; Thu, 20 Feb 2003 04:39:33 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 18lpz8-0000ip-00 for namedroppers@ops.ietf.org; Thu, 20 Feb 2003 04:39:30 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08917; Thu, 20 Feb 2003 07:35:39 -0500 (EST) Message-Id: <200302201235.HAA08917@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-keyrr-key-signing-flag-06.txt Date: Thu, 20 Feb 2003 07:35:39 -0500 X-Spam-Status: No, hits=4.6 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.43 X-Spam-Level: **** 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 : KEY RR Key-Signing Key (KSK) Flag Author(s) : O. Kolkman, J. Schlyter, E. Lewis Filename : draft-ietf-dnsext-keyrr-key-signing-flag-06.txt Pages : 10 Date : 2003-2-19 With the DS resource record the concept of key-signing and zone-signing keys has been introduced. During key-exchanges with the parent there is a need to differentiate between these zone- and key-signing keys. We propose a flag to indicate which key is used as key-signing key. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-keyrr-key-signing-flag-06.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-keyrr-key-signing-flag-06.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: <2003-2-19141847.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-keyrr-key-signing-flag-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-19141847.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. archive: From owner-namedroppers@ops.ietf.org Thu Feb 20 07:47:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10046 for ; Thu, 20 Feb 2003 07:47:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lpz6-0000im-00 for namedroppers-data@psg.com; Thu, 20 Feb 2003 04:39:28 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 18lpz3-0000iZ-00 for namedroppers@ops.ietf.org; Thu, 20 Feb 2003 04:39:26 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08899; Thu, 20 Feb 2003 07:35:34 -0500 (EST) Message-Id: <200302201235.HAA08899@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-intro-05.txt Date: Thu, 20 Feb 2003 07:35:34 -0500 X-Spam-Status: No, hits=4.6 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.43 X-Spam-Level: **** 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 Introduction and Requirements Author(s) : R. Arends, R. Austein, D. Massey, M. Larson, S. Rose Filename : draft-ietf-dnsext-dnssec-intro-05.txt Pages : 23 Date : 2003-2-19 The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions, and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the group of documents that collectively describe DNSSEC. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-intro-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-intro-05.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-intro-05.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: <2003-2-19141836.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-intro-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-intro-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-19141836.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. archive: From owner-namedroppers@ops.ietf.org Thu Feb 20 10:47:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18582 for ; Thu, 20 Feb 2003 10:47:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lsl6-0007lW-00 for namedroppers-data@psg.com; Thu, 20 Feb 2003 07:37:12 -0800 Received: from one.elistx.com ([209.116.252.130]) by psg.com with esmtp (Exim 3.36 #1) id 18lsl0-0007kb-00 for namedroppers@ops.ietf.org; Thu, 20 Feb 2003 07:37:06 -0800 Received: from ogud.com (pcp816081pcs.nrockv01.md.comcast.net [68.49.60.118]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HAM00J6462JRG@eListX.com> for namedroppers@ops.ietf.org; Thu, 20 Feb 2003 10:37:32 -0500 (EST) Received: from ENGILL.ogud.com (mail.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.3/8.12.3) with ESMTP id h1KFYJts035064 for ; Thu, 20 Feb 2003 10:34:19 -0500 (EST envelope-from ogud@ogud.com) Date: Thu, 20 Feb 2003 10:36:15 -0500 From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: Q-03: inclusion of KEY records in additional records section In-reply-to: <5.1.1.6.2.20030212134348.0254be98@localhost> X-Sender: post@localhost To: namedroppers@ops.ietf.org Message-id: <5.1.1.6.2.20030220103345.03440ae8@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=iso-8859-1 X-Spam-Status: No, hits=1.9 required=5.0 tests=GAPPY_TEXT,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, SPAM_PHRASE_00_01,TO_BE_REMOVED_REPLY version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA18582 At 14:21 2003-02-12, Ólafur Guđmundsson wrote: > > > >Issue: Is there need to specify that KEY records be placed in additional >section on certain queries/responses. > >Q: Can the DS document outlaw the rules from 2535 that requires >inclusion of KEY in additional section ? Does anyone care if I specify in the DS document that KEY RR SHOULD NOT be placed in additional section ? This will simplify DNSSEC implementations, reduce packet sizes and avoid repeated redundant information. Olafur >Background: > >RFC2535 Section 3.5 says: > An explicit request for KEY RRs does not cause any special additional > information processing except, of course, for the corresponding SIG > RR from a security aware server (see Section 4.2). > > Security aware DNS servers include KEY RRs as additional information > in responses, where a KEY is available, in the following cases: > > (1) On the retrieval of SOA or NS RRs, the KEY RRset with the same > name (perhaps just a zone key) SHOULD be included as additional > information if space is available. If not all additional information > will fit, type A and AAAA glue RRs have higher priority than KEY > RR(s). > > (2) On retrieval of type A or AAAA RRs, the KEY RRset with the same > name (usually just a host RR and NOT the zone key (which usually > would have a different name)) SHOULD be included if space is > available. On inclusion of A or AAAA RRs as additional information, > the KEY RRset with the same name should also be included but with > lower priority than the A or AAAA RRs > > >Rule 2 is obviously there for optimization reasons and was put there >to push out application (IPSEC) keys. As applications are now directed >to get their own key RR type and NOT place any additional section >processing requirements on DNS, the value of this rule is >operationally minimal. > >The first rule is more interesting and is focused at the needs of >DNS protocol elements. There are two reasons for this rule, >1. Optimization: attempt to distribute KEY RRsets with fewer round trips. >2. NULL KEY push: RFC2535 has NULL-KEY residing in the parent zone for > unsecured delegations. The rule above forces the push of this KEY set > along with the NS set in referrals. > >DS document eliminates the NULL-KEY and replaces its role with a rule >requiring NXT in authority section of referrals. > >Some Justifications for eliminating rule 1: >a. There is no need to push NULL KEY records anymore >b. The rule is complex in implementation as KEY is the lowest priority > RRset to be included in additional section. >c. The rule does only partially accomplishes its intent (see example below) >d. The rule makes negative answers much bigger as the SOA in authority section > triggers the rule. >e. A security aware resolver should know what information it needs and be able > to ask for multiple RRsets in parallel. >f. The information is going to be redundant in many cases. > >Example showing why the optimization does not work in a common case. >This is an example in secure universe. >Q: a.b.c.d.example. TXT (all zones are one label deep). >Server 1: is authoritative for example. >Server 2: is authoritative for d.example. >Server 3: is authoritative for c.d.example. >Server 4: is authoritative for b.c.d.example. > > >Trace (QN: query name, QT: query type, QS: server queried) >R: QN: a.b.c.d.example. QT: TXT QS: 1 >S1: > AU: d.example. NS 2 > d.example. DS > d.example. SIG(DS) > >R: QN: a.b.c.d.example. QT: TXT QS: 2 >S2: > AU: c.d.example. NS 3 > c.d.example. DS > c.d.example. SIG(DS) > >R: QN: a.b.c.d.example. QT: TXT QS:3 >S3: > AU: b.c.d.example. NS 4 > b.c.d.example. DS > b.c.d.example. SIG(DS) > >R: QN: a.b.c.d.example. QT: TXT QS:4 >S4: > AN: a.b.c.d.example. TXT > a.b.c.d.example. SIG(TXT) > >In order to validate the chain the resolver still needs to query for >KEY's for example., d.example., c.d.example., b.c.d.example. > > 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. >archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 20 11:47:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20861 for ; Thu, 20 Feb 2003 11:47:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lti2-000AGW-00 for namedroppers-data@psg.com; Thu, 20 Feb 2003 08:38:06 -0800 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #1) id 18lthx-000AGH-00 for namedroppers@ops.ietf.org; Thu, 20 Feb 2003 08:38:01 -0800 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id LAA27216; Thu, 20 Feb 2003 11:31:27 -0500 Date: Thu, 20 Feb 2003 11:32:38 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Mark.Andrews@isc.org cc: mw-list-namedroppers@csi.hu, Name Droppers , , Subject: Re: Bind 9 AXFR Modification vs AXFR Clarification In-Reply-To: <200302192356.h1JNuj4U006653@drugs.dv.isc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=2.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM, SPAM_PHRASE_03_05,USER_AGENT_PINE,X_OSIRU_SPAM_SRC version=2.43 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > > > The IXFR client must simply make the changes (again, by some > > > > implementation dependent, administrator maintained method) to the zone by > > > > deleting RRs and adding RR's in each sequence. The original version of th > > e > > > > zone might have been obtained by FTP (or quantum interference, or the > > > > psychic network) for all we know. > > > > > > Well the problem is that you have to get the *original* version, > > > not a corrupted version. AXFR implementations are not returning > > > the data originally entered. > > > > They sure have been. > > Not always. You haven't shown any proof of that. The "proof" you showed, was the result of a misconfiguration. > > If the zones are inconsistent through administrative mistake, then it > > won't matter what the IXFR does. > > Who said anything administrative mistakes? The content is being > unilaterally changed by the servers. It is reasonable and necessary to merge in glue. When you misconfigure the glue, strange things may happen. That is all that you have shown. I'm sure that many software programs will exhibit even stranger behavior, and may even fail to operate as a result of misconfiguration. > > Strange, that was my reaction, too. I'm just trying to be polite. 77% > > work just fine. We don't want to break 77% of the servers out there. > > You really think that it will break those servers? LOL. They will not be compliant, and thus will need to be changed. Thus, they would be broken by definition of not being compliant. Your failure to comprehend the consequences of the changes does not lessen the effect. We now agree that these changes aren't necessary to support IXFR. You were part of the bad engineering that led to the unnecessary creation of these changes in Bind 9. You were also part of the bad decision making that led to the distribution of these changes to Bind 9 users prior to standardization, and quite possibly you were part of the bad decision making that resulted in publishing a book on the subject, prior to acceptance of your modifications to standards. In short, you have shown bad judgement. Trying to "belittle" the effects with the "LOL", as opposed to offering anything substantive, simply suggests that you have no appreciation of the seriousness of the changes. Perhaps you should take this more seriously. > > > > Essentially, you are putting more (unnecessary) constraints on > > > > implementations, and thus on the administrators, who are supposed to be > > > > pretty free to define the zone boundaries. Of course, the specifics of a > > n > > > > implementation puts some constraints on the adminstrator, but the > > > > administrator can choose a different implementation more to her liking. > > > > > > The constaint was already there and it is necessary for reliable > > > operation of the DNS. > > > > No, you ware not being honest about the contents of the Draft. See my last > > message to Andreas. > > The abstract say: > > This memo clarifies, updates, and > adds missing detail to the original AXFR protocol specification in > RFC1034. > > I fail to see how the contents can be deemed misleading when > it states up front what it does. Woops we missed warning you > up front that it contains a warning. I've no doubt that you fail to see it. We seem to be focusing a lot on your failures. I have to question whether someone who went to MIT could really fail so often. Perhaps it has changes since I was there. Or perhaps you aren't really taking this very seriously. Let me explain it: 1) It doesn't say that it adds a completely new, incompatible zone transfer protocol. New protocols should be made through a different process, which includes experimentation. I'm not against experimenting with a new protocol. Indeed, I think this idea has some merit. However, it can't be "end-run standardized" by a "clarification". There is a process. 2) It doesn't say that it changes AXFR with respect to SIG 3) It doesn't say that it changes the status of other RFC's (RFC 2845, and possibly others.) without going through the appropriate standards process. 4) It doesn't say that it changes the definition of zone data to be public. Zone data is absolutely not "public by definition". It could very well be useful to tag certain RRs as non-public, and exclude them from zone transfers to public servers. This "clarification" precludes that. This is really 2 changes. 5) It doesn't say that it changes the security constraints on a zone transfer to be limited to deny or accept only. The list is longer, but that should be enough. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 20 13:27:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24353 for ; Thu, 20 Feb 2003 13:27:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lvEq-000EgX-00 for namedroppers-data@psg.com; Thu, 20 Feb 2003 10:16:04 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #1) id 18lvEn-000EgB-00 for namedroppers@ops.ietf.org; Thu, 20 Feb 2003 10:16:01 -0800 Received: (qmail 26323 invoked by uid 1016); 20 Feb 2003 18:16:26 -0000 Date: 20 Feb 2003 18:16:26 -0000 Message-ID: <20030220181626.26322.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: axfr-clarify breaking RFC 1034 References: <20030220034148.14684.qmail@cr.yp.to> <200302200614.h1K6Ev4U007655@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Andrews admits that his configuration violates RFC 1034 section 4.2.2. He also agrees that DNS servers are allowed to discard the inconsistent parts of his configuration. (BIND 9 doesn't; djbdns does; BIND 8 does to some extent.) However, because the _title_ of section 4.2.2 is ``Administrative considerations,'' Andrews concludes that DNS servers aren't allowed to discard the inconsistent parts of his configuration _if_ they obtained data for the parent zone through AXFR rather than directly from an ``administrator.'' It would be easy to shred the details of that argument. I could point out again that the configuration also violates section 4.2.1; the title of section 4.2.1 is ``Technical considerations''; no ``administrators'' here. There are many other obvious mistakes in what Andrews says. But there's a much larger problem here. Look at the overall structure of Andrews's argument: (1) Observation: This configuration, which is prohibited by RFC 1034, doesn't work correctly with 77% of the installed base. (2) Insane conclusion: 77% of the installed base is broken! We have to change all of it to make this configuration work correctly! Let's ignore all the objections, and declare the software used for most of the Internet's DNS servers to be non-compliant! Anyone who cares about interoperability will draw a very different conclusion: (3) Sane conclusion: The configuration is broken. Stop using it. Andrews is trying to shift blame from the broken configuration to the installed base. He's fighting against both RFC 1034 and the real world; that's why he's resorted almost entirely to religious arguments about proper implementation techniques for servers. There is one spot where Andrews returns to reality. He points out that his software (unlike mine) has never supported the synchronization required by RFC 1034. Obeying RFC 1034 would mean, among other things, changing all the BIND installations, which would be very difficult. Does this mean that we need the broken configurations? No! There's a middle ground between the synchronized configurations required by RFC 1034 and the broken configurations: namely, semi-synchronized configurations (parent serial changing after all the child servers have changed), which work with the entire installed base. RFC 1034 can be modified to allow semi-synchronized configurations. Mark.Andrews@isc.org writes: > Even if we were to go down that path (which I don't believe we should) Let me get this straight, Mark. You're screaming that the RFC 1034 requirement is too restrictive---because it requires synchronization that your software can't handle---but you don't believe that it should be changed to allow configurations that work with all existing software? You know, Mark, this discussion would have been a lot easier if your company had started by making an honest proposal to change the protocol, instead of trying to sneak changes past us as ``clarifications.'' ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 20 14:04:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25638 for ; Thu, 20 Feb 2003 14:04:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lvsc-000GaK-00 for namedroppers-data@psg.com; Thu, 20 Feb 2003 10:57:10 -0800 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by psg.com with esmtp (Exim 3.36 #1) id 18lvsY-000GYP-00 for namedroppers@ops.ietf.org; Thu, 20 Feb 2003 10:57:07 -0800 Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1KIv2JR009522; Thu, 20 Feb 2003 13:57:03 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn2-275.cisco.com [10.82.241.19]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA13590; Thu, 20 Feb 2003 13:57:00 -0500 (EST) Message-Id: <4.3.2.7.2.20030220135524.03e6d548@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Feb 2003 13:56:59 -0500 To: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org From: Ralph Droms Subject: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=0.5 required=5.0 tests=SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Reminder and note: there have been a few responses to this WG last call, but no explicit positive recommendations for advancement. Please review draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt and reply with comments. If you recommend the document for advancement without revision, please respond with a quick acknowledgment. No response will be interpreted as a lack of support for advancing the document. ----- This message announces a WG last call on "DNS Configuration options for DHCPv6" . The last call will conclude on Friday, 2/21. Note that this is a parallel WG last call in the dhc, ipv6 and dnsext WGs. draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt describes two options for DHCPv6: the Domain Name Server option and the Domain Search List option. This document is being considered for Proposed Standard as an extension to the base DHCPv6 specification, and is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt - Ralph Droms -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 20 14:47:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27237 for ; Thu, 20 Feb 2003 14:47:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lwYb-000IeC-00 for namedroppers-data@psg.com; Thu, 20 Feb 2003 11:40:33 -0800 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #1) id 18lwYX-000Idz-00 for namedroppers@ops.ietf.org; Thu, 20 Feb 2003 11:40:29 -0800 Received: from esunmail ([129.147.58.120]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA13944 for ; Thu, 20 Feb 2003 12:40:28 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTP id <0HAM00MBHHBF5O@edgemail1.Central.Sun.COM> for namedroppers@ops.ietf.org; Thu, 20 Feb 2003 12:40:28 -0700 (MST) Received: from sun.com ([129.146.10.23]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTPSA id <0HAM007HQHBECA@mail.sun.net> for namedroppers@ops.ietf.org; Thu, 20 Feb 2003 12:40:27 -0700 (MST) Date: Thu, 20 Feb 2003 11:40:26 -0800 From: Alain Durand Subject: Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt To: Ralph Droms Cc: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Message-id: <3E552F2A.2090302@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 References: <4.3.2.7.2.20030220135524.03e6d548@funnel.cisco.com> X-Spam-Status: No, hits=-3.7 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_01_02,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT From a quick look at the draft: 4. Domain Name Server option The Domain Name Server option provides a list of one or more IP addresses of DNS servers to which a client's DNS resolver MAY send DNS queries [2]. The DNS servers are listed in the order of preference for use by the client resolver. The format of the Domain Name Server option is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_DNS_SERVERS | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | DNS-server (IP address) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | DNS-server (IP address) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Are the IP addresses of the DNS servers IPv4 ones or IPv6 ones? How would the DHCP client knows? From the width of the boxes, one could think it it is v4 addresses, but from the height (4 lines!), one could think it is actually v6 addresses. My points are: - the spec is unclear if those addresses are v4 or v6 - it may makes sense to actually mix both type in an announcement, for example say: try this v6 address, if it does not work, try this v4 one. Then each DNS server entry should have both the actual address and its family. - Alain. Ralph Droms wrote: > Reminder and note: there have been a few responses to this WG last > call, but no explicit positive recommendations for advancement. > Please review draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt and reply > with comments. If you recommend the document for advancement without > revision, please respond with a quick acknowledgment. No response > will be interpreted as a lack of support for advancing the document. > > ----- > > This message announces a WG last call on "DNS Configuration options > for DHCPv6" . The last > call will conclude on Friday, 2/21. > > Note that this is a parallel WG last call in the dhc, ipv6 and dnsext > WGs. > > draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt describes two options for > DHCPv6: the Domain Name Server option and the Domain Search List > option. This document is being considered for Proposed Standard as an > extension to the base DHCPv6 specification, and is available as > http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt > > > - Ralph Droms > > -------------------------------------------------------------------- > 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 > -------------------------------------------------------------------- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 20 14:59:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27573 for ; Thu, 20 Feb 2003 14:59:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lwmw-000JkD-00 for namedroppers-data@psg.com; Thu, 20 Feb 2003 11:55:22 -0800 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by psg.com with esmtp (Exim 3.36 #1) id 18lwmt-000Jjt-00 for namedroppers@ops.ietf.org; Thu, 20 Feb 2003 11:55:19 -0800 Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1KJtEJR013584; Thu, 20 Feb 2003 14:55:15 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn2-275.cisco.com [10.82.241.19]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA18996; Thu, 20 Feb 2003 14:55:13 -0500 (EST) Message-Id: <4.3.2.7.2.20030220143854.03e69358@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Feb 2003 14:55:11 -0500 To: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org From: Ralph Droms Subject: Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-Reply-To: <200302101927.h1AJRdu16843@grimsvotn.TechFak.Uni-Bielefeld. DE> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-1.7 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_03_05,TO_BE_REMOVED_REPLY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Thanks for your feedback, Peter; my comments in line... - Ralph At 08:27 PM 2/10/2003 +0100, Peter Koch wrote: > > draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt describes two options for > > DHCPv6: the Domain Name Server option and the Domain Search List > > > This document uses terminology specific to IPv6 and DHCPv6 as defined > > in section "Terminology" of the DHCP specification. > >Might want to add an explicit normative reference here? OK. > > 4. Domain Name Server option > > > > The Domain Name Server option provides a list of one or more IP > > addresses of DNS servers to which a client's DNS resolver MAY send > > >From a purist's point of view I'm tempted to say that you're not really > looking >for a DNS server here but instead for a (list of) recursive resolvers. Should this sentence read (I'm not a DNS purist!): The Domain Name Server option provides a list of one or more IP addresses of DNS recursive resolvers to which a client's DNS resolver MAY send DNS queries [2]. > > DNS-server: IP address of DNS server (change to "DNS recursive resolver"?) >I did not follow the DHCPv6 effort too close, so I must admit not knowing >the usual "culture", but wouldn't it be better to say IPv6 address here? Yes; also see follow up by Alain Durand. > > A server sends a Domain Search List option to the DHCP client to > > specify the domain search list the client is to use when resolving > > hostnames with DNS. This option does not apply to other name > > resolution mechanisms. > >The draft does not say for which kind of domain names the client is expected >to process the list, i.e. one-label names only, n-label names (how to >communicate the 'n', aka 'ndots', then?) or whether this is left to the >application(s). > > > Because the Domain Search List option may be used to spoof DNS name > > resolution in a way that cannot be detected by DNS security > > mechanisms like DNSSEC [5], DHCP clients and servers MUST use > >Apart from the sad fact that DNSSEC isn't yet deployed I don't see why it >wouldn't be able to detect spoofing. If, however, you want to say that >using domain names in the search list you don't control is a dangerous >thing, that could be emphazised by a reference to RFC 1535. The idea here (note that I'm not a DNSSEC expert, either) is that a search list that the host doesn't control might still pass DNSSEC authentication while yielding unexpected results. I would be happy to hear that DNSSEC can prevent the problem and would be willing to follow your suggestion and replace the reference to DNSSEC with a more general reference to untrusted search lists. > > authenticated DHCP when a Domain Search List option is included in a > > DHCP message. > >Why is this a MUST while there's a SHOULD only for the server option? They probably both should have the same level of requirement; I would think SHOULD would be sufficient for both. >-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. >archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 20 15:08:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27841 for ; Thu, 20 Feb 2003 15:08:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lwvF-000KK8-00 for namedroppers-data@psg.com; Thu, 20 Feb 2003 12:03:57 -0800 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by psg.com with esmtp (Exim 3.36 #1) id 18lwvB-000KJt-00 for namedroppers@ops.ietf.org; Thu, 20 Feb 2003 12:03:54 -0800 Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1KK3oJR014151; Thu, 20 Feb 2003 15:03:50 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn2-275.cisco.com [10.82.241.19]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA19859; Thu, 20 Feb 2003 15:03:49 -0500 (EST) Message-Id: <4.3.2.7.2.20030220150155.03e6d448@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Feb 2003 15:03:44 -0500 To: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org From: Ralph Droms Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-Reply-To: <3E552F2A.2090302@sun.com> References: <4.3.2.7.2.20030220135524.03e6d548@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Alain, If it's unclear, then we should edit the document to explicitly identify the addresses as IPv6 addresses. This option is intended to return IPv6 configuration information. IPv4 addresses for DNS resolvers should be provided through DHCPv4... - Ralph At 11:40 AM 2/20/2003 -0800, Alain Durand wrote: > From a quick look at the draft: > >4. Domain Name Server option > > The Domain Name Server option provides a list of one or more IP > addresses of DNS servers to which a client's DNS resolver MAY send > DNS queries [2]. The DNS servers are listed in the order of > preference for use by the client resolver. > > The format of the Domain Name Server option is: > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | OPTION_DNS_SERVERS | option-len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | DNS-server (IP address) | > | | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | DNS-server (IP address) | > | | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > >Are the IP addresses of the DNS servers IPv4 ones or IPv6 ones? >How would the DHCP client knows? > From the width of the boxes, one could think it it is v4 addresses, >but from the height (4 lines!), one could think it is actually v6 addresses. > >My points are: >- the spec is unclear if those addresses are v4 or v6 >- it may makes sense to actually mix both type in an announcement, > for example say: try this v6 address, if it does not work, try this v4 one. > Then each DNS server entry should have both the actual address and its > family. > > - Alain. > > >Ralph Droms wrote: > >>Reminder and note: there have been a few responses to this WG last call, >>but no explicit positive recommendations for advancement. >>Please review draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt and reply with >>comments. If you recommend the document for advancement without >>revision, please respond with a quick acknowledgment. No response will >>be interpreted as a lack of support for advancing the document. >> >>----- >> >>This message announces a WG last call on "DNS Configuration options for >>DHCPv6" . The last call will >>conclude on Friday, 2/21. >> >>Note that this is a parallel WG last call in the dhc, ipv6 and dnsext WGs. >> >>draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt describes two options for >>DHCPv6: the Domain Name Server option and the Domain Search List >>option. This document is being considered for Proposed Standard as an >>extension to the base DHCPv6 specification, and is available as >>http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt >> >>- Ralph Droms >> >>-------------------------------------------------------------------- >>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 >>-------------------------------------------------------------------- > > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 20 15:17:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28168 for ; Thu, 20 Feb 2003 15:17:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lx0P-000Kjd-00 for namedroppers-data@psg.com; Thu, 20 Feb 2003 12:09:17 -0800 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 18lx0L-000KjO-00 for namedroppers@ops.ietf.org; Thu, 20 Feb 2003 12:09:14 -0800 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h1KK7qA11319; Thu, 20 Feb 2003 15:07:53 -0500 (EST) Date: Thu, 20 Feb 2003 15:07:52 -0500 From: Keith Moore To: "D. J. Bernstein" Cc: moore@cs.utk.edu, ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: axfr-clarify's fraudulent claims of consensus Message-Id: <20030220150752.357be0cc.moore@cs.utk.edu> In-Reply-To: <20030215033141.82623.qmail@cr.yp.to> References: <20030214103228.71052.qmail@cr.yp.to> <200302101659.LAA15654@ietf.org> <10697.1045222702@munnari.OZ.AU> <20030215033141.82623.qmail@cr.yp.to> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > RFC 2119, section 6: ``Imperatives of the type defined in this memo > must be used with care and sparingly. In particular, they MUST only > be used where it is actually required for interoperation or to limit > behavior which has potential for causing harm (e.g., limiting > retransmisssions) For example, they must not be used to try to impose > a particular method on implementors where the method is not required > for interoperability.'' fwiw, this only applies to documents that cite RFC 2119 for definitions of those terms. other documents have used other definitions. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 20 15:20:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28260 for ; Thu, 20 Feb 2003 15:20:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lx8V-000LFt-00 for namedroppers-data@psg.com; Thu, 20 Feb 2003 12:17:39 -0800 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 18lx8P-000LFW-00 for namedroppers@ops.ietf.org; Thu, 20 Feb 2003 12:17:33 -0800 Received: from nominum.com (az-ben-pm3-2-15.ppp.theriver.com [206.25.50.15]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1KKEoN12781; Thu, 20 Feb 2003 14:14:50 -0600 (CST) Date: Thu, 20 Feb 2003 13:17:26 -0700 Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org To: Ralph Droms From: Ted Lemon In-Reply-To: <4.3.2.7.2.20030220135524.03e6d548@funnel.cisco.com> Message-Id: <5448A21C-4510-11D7-A12D-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I thought I had said that I thought it should go ahead, but maybe not explicitly. I would like to see this draft advance. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 20 16:13:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29724 for ; Thu, 20 Feb 2003 16:13:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lxtK-000O1E-00 for namedroppers-data@psg.com; Thu, 20 Feb 2003 13:06:02 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #1) id 18lxtG-000O0u-00 for namedroppers@ops.ietf.org; Thu, 20 Feb 2003 13:05:58 -0800 Received: (qmail 40639 invoked by uid 1016); 20 Feb 2003 21:06:23 -0000 Date: 20 Feb 2003 21:06:23 -0000 Message-ID: <20030220210623.40638.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: axfr-clarify's fraudulent claims of consensus References: <20030214103228.71052.qmail@cr.yp.to> <200302101659.LAA15654@ietf.org> <10697.1045222702@munnari.OZ.AU> <20030215033141.82623.qmail@cr.yp.to> <20030220150752.357be0cc.moore@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=0.3 required=5.0 tests=REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Keith Moore writes: [ RFC 2119 section 6 ] > only applies to documents that cite RFC 2119 for definitions of those terms. That's exactly what axfr-clarify does in section 1: ``The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119].'' The author will, presumably, try to weasel out of RFC 2119 section 6 by dropping the reference to RFC 2119. Why is this tolerated? Why would any legitimate standards organization _want_ to violate the basic principles stated in RFC 2119? The IETF shouldn't be sticking its nose into private implementation decisions that don't cause interoperability problems. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 20 17:41:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02444 for ; Thu, 20 Feb 2003 17:41:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lzHb-0003GB-00 for namedroppers-data@psg.com; Thu, 20 Feb 2003 14:35:11 -0800 Received: from [2001:470:1f00:ffff::5a1] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 18lzHW-0003CD-00 for namedroppers@ops.ietf.org; Thu, 20 Feb 2003 14:35:07 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h1KMXO4U009264; Fri, 21 Feb 2003 09:33:26 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200302202233.h1KMXO4U009264@drugs.dv.isc.org> To: Dean Anderson Cc: mw-list-namedroppers@csi.hu, Name Droppers , ietf@ietf.org, iesg@ietf.org From: Mark.Andrews@isc.org Subject: Re: Bind 9 AXFR Modification vs AXFR Clarification In-reply-to: Your message of "Thu, 20 Feb 2003 11:32:38 CDT." Date: Fri, 21 Feb 2003 09:33:24 +1100 X-Spam-Status: No, hits=0.8 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > > > > The IXFR client must simply make the changes (again, by some > > > > > implementation dependent, administrator maintained method) to the zon > e by > > > > > deleting RRs and adding RR's in each sequence. The original version o > f th > > > e > > > > > zone might have been obtained by FTP (or quantum interference, or the > > > > > psychic network) for all we know. > > > > > > > > Well the problem is that you have to get the *original* version > , > > > > not a corrupted version. AXFR implementations are not returnin > g > > > > the data originally entered. > > > > > > They sure have been. > > > > Not always. > > You haven't shown any proof of that. The "proof" you showed, was the > result of a misconfiguration. No. It is the result of operational reality. Whenever you have a parent and child zones under different administrative controls it is impossible to change both zones simultaniously. It is also impossible using AXFR or any other mechanism which transfers *individual* zones to transfer them to a secondary and guarantee that they will arrive simultaniously. Having parent and child zone under different administrative control is the norm not the execption. > > > If the zones are inconsistent through administrative mistake, then it > > > won't matter what the IXFR does. > > > > Who said anything administrative mistakes? The content is being > > unilaterally changed by the servers. > > It is reasonable and necessary to merge in glue. When you misconfigure the > glue, strange things may happen. That is all that you have shown. I'm > sure that many software programs will exhibit even stranger behavior, and > may even fail to operate as a result of misconfiguration. No. It is neither reasonable nor necessary. Any temporary inconsistancies will be corrected when all the zone transfers complete. By changing the zones contents you create situations where these temporary inconsistancies won't be corrected. When handing out non axfr/ixfr responses you use the best source of data you have. Nothing in RFC 1033 / 1034 / 1035 says that a server is permitted to alter the content of a zone. The responability for maintaining consistancy between zones is a administrative function. > > > Strange, that was my reaction, too. I'm just trying to be polite. 77% > > > work just fine. We don't want to break 77% of the servers out there. > > > > You really think that it will break those servers? LOL. > > They will not be compliant, and thus will need to be changed. Thus, they > would be broken by definition of not being compliant. So. Just because they will not be compliant doesn't mean that that they need to be replaced immediately. That non-compliance doesn't hurt most of them. For those where it does have a negative impact it will mean that they should be able to request a fix from their vendor. > Your failure to comprehend the consequences of the changes does not lessen > the effect. We now agree that these changes aren't necessary to support > IXFR. You were part of the bad engineering that led to the unnecessary > creation of these changes in Bind 9. You were also part of the bad > decision making that led to the distribution of these changes to Bind 9 > users prior to standardization, and quite possibly you were part of the > bad decision making that resulted in publishing a book on the subject, > prior to acceptance of your modifications to standards. In short, you have > shown bad judgement. I never said that they we not necessary for IXFR. I said that that your descripition of how to generate the differences was irrelevent to this discussion. It was bad engineering to merge the data sets together in the first place. It was not required by RFC 1033/ 1034 / 1035. It had negative consequences. It was good engineering to correct this. It was also good engineering to report a common error to the community so that other vendors could fix their mistakes. Good engineers learn from their mistakes and try hard not to repeat them. They also learn from the mistakes of others. That's why bridge designs are wind tunnel tested these days. > Trying to "belittle" the effects with the "LOL", as opposed to offering > anything substantive, simply suggests that you have no appreciation of the > seriousness of the changes. Perhaps you should take this more seriously. I'm quite aware of what the change requires. I'm also aware that most of the nameserver are used in situations where the zone contents is already preserved because they are not serving zones with parent / child relationships. Anyone saying that all the nameservers need to be replaced immediately is spreading FUD. LOL the the correct reponse to FUD. Using a server that perserves zone contents under all conditions doesn't break anything. > > > > > Essentially, you are putting more (unnecessary) constraints on > > > > > implementations, and thus on the administrators, who are supposed to > be > > > > > pretty free to define the zone boundaries. Of course, the specifics > of a > > > n > > > > > implementation puts some constraints on the adminstrator, but the > > > > > administrator can choose a different implementation more to her likin > g. > > > > > > > > The constaint was already there and it is necessary for reliabl > e > > > > operation of the DNS. > > > > > > No, you ware not being honest about the contents of the Draft. See my las > t > > > message to Andreas. > > > > The abstract say: > > > > This memo clarifies, updates, and > > adds missing detail to the original AXFR protocol specification in > > RFC1034. > > > > I fail to see how the contents can be deemed misleading when > > it states up front what it does. Woops we missed warning you > > up front that it contains a warning. > > I've no doubt that you fail to see it. We seem to be focusing a lot on > your failures. I have to question whether someone who went to MIT could > really fail so often. Perhaps it has changes since I was there. Or perhaps > you aren't really taking this very seriously. Let me explain it: > > 1) It doesn't say that it adds a completely new, incompatible zone > transfer protocol. New protocols should be made through a different > process, which includes experimentation. I'm not against experimenting > with a new protocol. Indeed, I think this idea has some merit. However, it > can't be "end-run standardized" by a "clarification". There is a process. It isn't new. All it is saying is that the contents tramitted out MUST be that transmitted in. This occurs most of the time already. Note BIND is not the only implementation that does this. We have already had reports of 3 other implementations doing this. Even the implementations that don't guarentee the contents do this most of the time. It has no negative effects. > 2) It doesn't say that it changes AXFR with respect to SIG It doesn't change anything wrt to SIG. Go read RFC 2535 which also says that SIG records in the answer section are part of the zone contents and don't need special processing. > 3) It doesn't say that it changes the status of other RFC's (RFC 2845, and > possibly others.) without going through the appropriate standards process. It doen't change the status of RFC 2845. > 4) It doesn't say that it changes the definition of zone data to be > public. Zone data is absolutely not "public by definition". It could very > well be useful to tag certain RRs as non-public, and exclude them from > zone transfers to public servers. This "clarification" precludes that. > This is really 2 changes. Nowhere in RFC 1033 / 1034 / 1035 does it say that zone transfers are restricted to secondaries. Nowhere in RFC 1033 / 1034 / 1035 does it say that you should restrict zone tranfers. There is a REFUSED rcode so the possibility of refusing a zone transfer is allowed for but the conditions underwhich this will be done are not specified. This draft does not change this. > 5) It doesn't say that it changes the security constraints on a zone > transfer to be limited to deny or accept only. Effective it does. If you transmit the zone then you MUST transmit its full contents unmodified (accept). It also says that you are allowed to refuse zone transfers (deny). > The list is longer, but that should be enough. -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 20 19:06:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04088 for ; Thu, 20 Feb 2003 19:06:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18m0YO-0007yw-00 for namedroppers-data@psg.com; Thu, 20 Feb 2003 15:56:36 -0800 Received: from gusto.araneus.fi ([204.152.186.164]) by psg.com with esmtp (Exim 3.36 #1) id 18m0YE-0007ya-00 for namedroppers@ops.ietf.org; Thu, 20 Feb 2003 15:56:26 -0800 Received: from guava.araneus.fi (adsl-63-197-0-204.dsl.snfc21.pacbell.net [63.197.0.204]) by gusto.araneus.fi (8.11.6/8.11.6) with ESMTP id h1KNuIZ08226; Thu, 20 Feb 2003 15:56:18 -0800 (PST) Received: (from gson@localhost) by guava.araneus.fi (8.11.6/8.11.6) id h1KNuHT16938; Thu, 20 Feb 2003 15:56:17 -0800 (PST) Date: Thu, 20 Feb 2003 15:56:17 -0800 (PST) Message-Id: <200302202356.h1KNuHT16938@guava.araneus.fi> To: Dean Anderson Cc: Mark.Andrews@isc.org, Namedroppers , Subject: Re: Bind 9 AXFR Modification vs AXFR Clarification In-Reply-To: References: <200302190251.h1J2pwG28755@guava.araneus.fi> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=1.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_03_05 version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Dean Anderson writes: > > > Zone definition and content is not an AXFR issue. Server administrators > > > provide the definition of zone boundaries. (RFC 1034 Section 2.3 and > > > elsewhere) AXFR merely gives the contents of the zone as has been defined > > > according to the boundaries and content specified by the administrator. > > > > This is exactly what the draft says, so what are you disagreeing with? > > Uhh, no. Draft 05 says quite a bit more. It subtly changes a number of > things that shouldn't be, and don't need to be changed. In fact, looking > at my copy, it doesn't say anything like the above at all. (But assuming > it did, it would be redundant and could be deleted). The draft says many things, and I understand that you are objecting to several of them, but we were specifically discussing zone boundaries, the subject of section 4. Your statement that "server administrators provide the definition of zone boundaries" is consistent with the draft's existing wording and inconsistent with the BIND 4 / BIND 8 handling of zone boundaries which you previously claimed to support. > Section 4 should be deleted. Clearly, glue records need to be merged in. Are you saying section 4 should be deleted because you disagree with it, or because you find it obviously correct and therefore redundant? Also, which glue records need to be merged into what? -- 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. archive: From owner-namedroppers@ops.ietf.org Thu Feb 20 19:17:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04475 for ; Thu, 20 Feb 2003 19:17:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18m0l8-0008km-00 for namedroppers-data@psg.com; Thu, 20 Feb 2003 16:09:46 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #1) id 18m0l4-0008kW-00 for namedroppers@ops.ietf.org; Thu, 20 Feb 2003 16:09:42 -0800 Received: from esunmail ([129.147.58.120]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA28968 for ; Thu, 20 Feb 2003 17:09:38 -0700 (MST) Received: from xpa-fe1 ([129.147.58.198]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTP id <0HAM00MGVTS15O@edgemail1.Central.Sun.COM> for namedroppers@ops.ietf.org; Thu, 20 Feb 2003 17:09:38 -0700 (MST) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTPSA id <0HAM0062DTS0W0@mail.sun.net> for namedroppers@ops.ietf.org; Thu, 20 Feb 2003 17:09:37 -0700 (MST) Date: Thu, 20 Feb 2003 16:10:44 -0800 From: Alain Durand Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-reply-to: <4.3.2.7.2.20030220150155.03e6d448@funnel.cisco.com> To: Ralph Droms Cc: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.551) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Status: No, hits=-4.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On Thursday, February 20, 2003, at 12:03 PM, Ralph Droms wrote: > Alain, > > If it's unclear, then we should edit the document to explicitly > identify the addresses as IPv6 addresses. > > This option is intended to return IPv6 configuration information. > IPv4 addresses for DNS resolvers should be provided through DHCPv4... ??? Why so? This would be the equivalent to say: "If queried using IPv6, DNS will return AAAA and if queried using IPv4, it will return A". Now, let's say that this is the case for DHCP, what should a node that act both as a DHCPv4 and DHCPv6 client do when it will be returned two lists of recursive DNS serves, one IPv4 via DHCPv4 and one IPv6 via DHCPv6. Which one should take priority? - Alain. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 20 19:20:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04563 for ; Thu, 20 Feb 2003 19:20:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18m0qM-00095l-00 for namedroppers-data@psg.com; Thu, 20 Feb 2003 16:15:10 -0800 Received: from [2001:470:1f00:ffff::5a1] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 18m0qI-00094R-00 for namedroppers@ops.ietf.org; Thu, 20 Feb 2003 16:15:06 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h1L0EH4U009904; Fri, 21 Feb 2003 11:14:18 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200302210014.h1L0EH4U009904@drugs.dv.isc.org> To: "D. J. Bernstein" Cc: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: axfr-clarify breaking RFC 1034 In-reply-to: Your message of "20 Feb 2003 18:16:26 -0000." <20030220181626.26322.qmail@cr.yp.to> Date: Fri, 21 Feb 2003 11:14:17 +1100 X-Spam-Status: No, hits=0.6 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02, TO_BE_REMOVED_REPLY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Andrews admits that his configuration violates RFC 1034 section 4.2.2. It's a necessary and unavoidable reality to temporarily violate it. The only way to meet this all the times and at all levels of the DNS is to have the all the zones administered on a single machine *and* to have a multizone transfer protocol. Lets go back to HOSTS.TXT, that meets this criteria. > He also agrees that DNS servers are allowed to discard the inconsistent > parts of his configuration. (BIND 9 doesn't; djbdns does; BIND 8 does to > some extent.) No. I agree that server can be configured to correct PRIMARY zones if they detect a inconsistancy and if they do so they have to update the serial number. > However, because the _title_ of section 4.2.2 is ``Administrative > considerations,'' Andrews concludes that DNS servers aren't allowed to > discard the inconsistent parts of his configuration _if_ they obtained > data for the parent zone through AXFR rather than directly from an > ``administrator.'' It is not the servers job to correct inconsistancies in SECONDARY zones. RFC 1034 states that a ACURATE copy of the zone is ESSENTIAL. "The stream of messages allows the secondary to construct a copy of the zone. Because accuracy is essential, TCP or some other reliable protocol must be used for AXFR requests." A modified zone is NOT a ACURATE copy. It's not even a copy. It is a derived work. BIND 4 and BIND 8 violate this section of RFC 1034. BIND 9 does not. > It would be easy to shred the details of that argument. I could point > out again that the configuration also violates section 4.2.1; the title > of section 4.2.1 is ``Technical considerations''; no ``administrators'' > here. There are many other obvious mistakes in what Andrews says. > > But there's a much larger problem here. Look at the overall structure of > Andrews's argument: > > (1) Observation: This configuration, which is prohibited by RFC 1034, > doesn't work correctly with 77% of the installed base. > > (2) Insane conclusion: 77% of the installed base is broken! We have > to change all of it to make this configuration work correctly! > Let's ignore all the objections, and declare the software used > for most of the Internet's DNS servers to be non-compliant! The installed base is broken. It doesn't matter if it is 1%, 77% or 100%. > Anyone who cares about interoperability will draw a very different > conclusion: > > (3) Sane conclusion: The configuration is broken. Stop using it. No. The sane conclusion is to deal with physical and administative realities. To stop fighting the speed of light and correct the implementations. > Andrews is trying to shift blame from the broken configuration to the > installed base. He's fighting against both RFC 1034 and the real world; > that's why he's resorted almost entirely to religious arguments about > proper implementation techniques for servers. > > There is one spot where Andrews returns to reality. He points out that > his software (unlike mine) has never supported the synchronization > required by RFC 1034. Obeying RFC 1034 would mean, among other things, > changing all the BIND installations, which would be very difficult. > > Does this mean that we need the broken configurations? No! There's a > middle ground between the synchronized configurations required by RFC > 1034 and the broken configurations: namely, semi-synchronized > configurations (parent serial changing after all the child servers have > changed), which work with the entire installed base. RFC 1034 can be > modified to allow semi-synchronized configurations. It is good to see that you agree that Section 4.2.2 cannot be met all the time. It is good to see that you agree that enforcing agreement between zones causes problem. The logical conclusion is to stop enforcing agreement between zones where it causes problems. > Mark.Andrews@isc.org writes: > > Even if we were to go down that path (which I don't believe we should) > > Let me get this straight, Mark. You're screaming that the RFC 1034 > requirement is too restrictive---because it requires synchronization > that your software can't handle---but you don't believe that it should > be changed to allow configurations that work with all existing software? > > You know, Mark, this discussion would have been a lot easier if your > company had started by making an honest proposal to change the protocol, > instead of trying to sneak changes past us as ``clarifications.'' > > ---D. J. Bernstein, Associate Professor, Department of Mathematics, > Statistics, and Computer Science, University of Illinois at Chicago > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 20 19:47:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05048 for ; Thu, 20 Feb 2003 19:47:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18m1IX-000B2L-00 for namedroppers-data@psg.com; Thu, 20 Feb 2003 16:44:17 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18m1IU-000AyW-00 for namedroppers@ops.ietf.org; Thu, 20 Feb 2003 16:44:14 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18m0bd-0005WS-00 for namedroppers@ops.ietf.org; Fri, 21 Feb 2003 08:59:57 +0900 Message-ID: <3E5551DB.2060808@cisco.com> MIME-Version: 1.0 References: <20030214103228.71052.qmail@cr.yp.to> <200302101659.LAA15654@ietf.org> <10697.1045222702@munnari.OZ.AU> <20030215033141.82623.qmail@cr.yp.to> <20030220150752.357be0cc.moore@cs.utk.edu> <20030220210623.40638.qmail@cr.yp.to> In-Reply-To: <20030220210623.40638.qmail@cr.yp.to> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 20 Feb 2003 14:08:27 -0800 From: Eliot Lear To: "D. J. Bernstein" CC: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: axfr-clarify's fraudulent claims of consensus X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO, SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] D. J. Bernstein wrote: > The IETF shouldn't be sticking its nose into private > implementation decisions that don't cause interoperability problems. But Rob Elz made a clear point in seemingly the only message you *didn't* respond to that your implementation could cause interoperability problems by potentially allowing for different contents of the same zone with the same serial number. I won't regurgitate the rest of his message, but it's in the archives. If he's right (and it seems to me that he is), that's an indication for either a standards clarification or a bug fix to your code, and maybe both (indicated, IMHO). Eliot -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 20 21:23:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06536 for ; Thu, 20 Feb 2003 21:23:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18m2gW-000Gq8-00 for namedroppers-data@psg.com; Thu, 20 Feb 2003 18:13:08 -0800 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #1) id 18m2gS-000Gpm-00 for namedroppers@ops.ietf.org; Thu, 20 Feb 2003 18:13:04 -0800 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id VAA05875; Thu, 20 Feb 2003 21:06:38 -0500 Date: Thu, 20 Feb 2003 21:07:49 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Mark.Andrews@isc.org cc: mw-list-namedroppers@csi.hu, Name Droppers , , Subject: Re: Bind 9 AXFR Modification vs AXFR Clarification In-Reply-To: <200302202233.h1KMXO4U009264@drugs.dv.isc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,SPAM_PHRASE_02_03,USER_AGENT_PINE, X_OSIRU_SPAM_SRC version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 21 Feb 2003 Mark.Andrews@isc.org wrote: > > You haven't shown any proof of that. The "proof" you showed, was the > > result of a misconfiguration. > > No. It is the result of operational reality. Whenever you > have a parent and child zones under different administrative > controls it is impossible to change both zones simultaniously. > It is also impossible using AXFR or any other mechanism > which transfers *individual* zones to transfer them to a > secondary and guarantee that they will arrive simultaniously. > > Having parent and child zone under different administrative control > is the norm not the execption. Actually, a parent always has some control over the child. It exercises this control through the glue records. When the glue records are in the child zone, they need to be merged. If a zone transfer happens while they are inconsistent, it is possible for some strange results to happen. Ordinarilly, zone transfers don't happen when they are inconsistent, since the inconsistency is usually short. Any zone transfers made during the inconsistent window are corrected so long as the child zone is updated with correct information after the parent is updated. Frequently the parent and child zone are under different administrative control, and are frequently on different servers. In such a case, the contents of the parent zone aren't merged with the child in the child's server, and no evidence of the inconsistency is seen through zone transfers. However, the inconsistency still exists and may still be visible by resolvers and nameservers that lookup the glue records. You have obtained no benefits by these constraints. > > > > If the zones are inconsistent through administrative mistake, then it > > > > won't matter what the IXFR does. > > > > > > Who said anything administrative mistakes? The content is being > > > unilaterally changed by the servers. > > > > It is reasonable and necessary to merge in glue. When you misconfigure the > > glue, strange things may happen. That is all that you have shown. I'm > > sure that many software programs will exhibit even stranger behavior, and > > may even fail to operate as a result of misconfiguration. > > No. It is neither reasonable nor necessary. Any temporary > inconsistancies will be corrected when all the zone transfers > complete. By changing the zones contents you create > situations where these temporary inconsistancies won't be > corrected. When handing out non axfr/ixfr responses you > use the best source of data you have. It is necessary, since the parent has glue records in the child zone. The parent therefore has (always) a part of the child zone. If that server also loads the child zone (or perhaps generates part of it dynamically), it quite reasonable to merge the records as though the zone includes multiple files, which in theory, it does. The child zone contents will only be correct when the administrators of both zones agree on the contents of the glue records, and update their parts of the child zone accordingly. It will not be correct until then, regardless of how many zone transfers take place. > Nothing in RFC 1033 / 1034 / 1035 says that a server is permitted > to alter the content of a zone. The responability for maintaining > consistancy between zones is a administrative function. This is a loaded statement. The part of the server NOT involved in responding to queries and zone transfers is part of the administrative function. So, as part of that administrative function, it has to be able to modify the RR and zones accordingly. Your proposed changes exclude a huge part of the potential for intelligence in name servers. And do so with no benefits. > > > > Strange, that was my reaction, too. I'm just trying to be polite. 77% > > > > work just fine. We don't want to break 77% of the servers out there. > > > > > > You really think that it will break those servers? LOL. > > > > They will not be compliant, and thus will need to be changed. Thus, they > > would be broken by definition of not being compliant. > > So. Just because they will not be compliant doesn't mean > that that they need to be replaced immediately. That > non-compliance doesn't hurt most of them. For those where > it does have a negative impact it will mean that they should > be able to request a fix from their vendor. You seem to make a case that in general, non-compliance doesn't hurt anything. This is false, for both technical and commercial reasons. Technically, it hurts interoperability, which has some many obvious harms I won't go into them. Commercially, implementations make and advertise compatibility and standards compliance claims. This retroactively makes those claims false, which harms the business and reputation of those other vendors. 77% will need a fix from the vendor, if we were to accept these changes. The vendor that made false claims of compatibility and standards compliance is Bind 9. It should suffer the commercial damage to its business and reputation, as a result. > > Your failure to comprehend the consequences of the changes does not lessen > > the effect. We now agree that these changes aren't necessary to support > > IXFR. You were part of the bad engineering that led to the unnecessary > > creation of these changes in Bind 9. You were also part of the bad > > decision making that led to the distribution of these changes to Bind 9 > > users prior to standardization, and quite possibly you were part of the > > bad decision making that resulted in publishing a book on the subject, > > prior to acceptance of your modifications to standards. In short, you have > > shown bad judgement. > > I never said that they we not necessary for IXFR. I said that > that your descripition of how to generate the differences was > irrelevent to this discussion. Ok, you are half way there. They are irrelevant because IXFR is irrelevant. These changes are not necessary to IXFR, as I explained that IXFR can work with the current AXFR, or even without AXFR. > It was bad engineering to merge the data sets together in the > first place. It was not required by RFC 1033/ 1034 / 1035. > It had negative consequences. It was good engineering to > correct this. It was also good engineering to report a > common error to the community so that other vendors could > fix their mistakes. Actually, since the parent has the glue in the child zone, it has part of the child zone as well as the master zone. Merging them together is not prohibited, and in the case where child and parent have the same adminstrator, as might be the case where most of the child is simply automatically generated by the nameserver, can make things much easier. Your constraints preclude this unnecessarilly. Since I can think of cases where it is useful to merge records together, it is bad engineering to remove that flexibility and obtain no benefits in return. > > Trying to "belittle" the effects with the "LOL", as opposed to offering > > anything substantive, simply suggests that you have no appreciation of the > > seriousness of the changes. Perhaps you should take this more seriously. > > I'm quite aware of what the change requires. I'm also aware > that most of the nameserver are used in situations where > the zone contents is already preserved because they are not > serving zones with parent / child relationships. Apparently, you aren't even aware that your changes will make all non-bind 9 servers non-compliant. Had you been aware of that, it seems you would have brought this proposal forward something like 3 years ago, before releasing Bind 9, and before publishing a book on the subject. > Anyone saying that all the nameservers need to be replaced > immediately is spreading FUD. LOL the the correct reponse > to FUD. Making 77% of the servers non-compliant is a fact of your proposed changes. It is another fact, as explained, that non-compliant servers will need to be replaced. Will they suddenly stop working? It depends on whether other implementations want to implement a "backwards compatibility" mode. If they don't implement this mode, then the answer is yes, they will stop working as soon as these updates are deployed by other vendors. Of course, this is a bad result. > Using a server that perserves zone contents under all > conditions doesn't break anything. Your constraints break useful services, and offer no value in return. > > 1) It doesn't say that it adds a completely new, incompatible zone > > transfer protocol. New protocols should be made through a different > > process, which includes experimentation. I'm not against experimenting > > with a new protocol. Indeed, I think this idea has some merit. However, it > > can't be "end-run standardized" by a "clarification". There is a process. > > It isn't new. All it is saying is that the contents tramitted > out MUST be that transmitted in. This occurs most of the time > already. Note BIND is not the only implementation that does > this. We have already had reports of 3 other implementations > doing this. Even the implementations that don't guarentee the > contents do this most of the time. It has no negative effects. No, Section 3.1 is a whole new derivative of AXFR. That is new. > > 2) It doesn't say that it changes AXFR with respect to SIG > > It doesn't change anything wrt to SIG. Go read RFC 2535 which > also says that SIG records in the answer section are part of the > zone contents and don't need special processing. Oh. Then section 3.3 can be deleted in entirety without objection. > > 3) It doesn't say that it changes the status of other RFC's (RFC 2845, and > > possibly others.) without going through the appropriate standards process. > > It doen't change the status of RFC 2845. The IEFT index indicates that RFC 2845 is "Proposed Standard", with no applicability statement that I could find. This changes it to "RECOMMENDED" requirement level. I think an applicability statement is premature until RFC 2845 is moved along, and then by the appropriate standards body decision-making process. It is inappropriate to hide something like this deep in an irrelevant "clarification". > > 4) It doesn't say that it changes the definition of zone data to be > > public. Zone data is absolutely not "public by definition". It could very > > well be useful to tag certain RRs as non-public, and exclude them from > > zone transfers to public servers. This "clarification" precludes that. > > This is really 2 changes. > > Nowhere in RFC 1033 / 1034 / 1035 does it say that zone transfers > are restricted to secondaries. Nowhere in RFC 1033 / 1034 / 1035 > does it say that you should restrict zone tranfers. I don't think you understood my statement. I'm talking about the definition of zone data. Nowhere does 1034 etc say that zone data is public. It may well have been thought to be public, originally, but since I can easily see a useful purpose in withholding some private RRs, there isn't any reason to preclude that behavior. Your constraints harm a useful purpose, and provide no benefits. > There is a REFUSED rcode so the possibility of refusing a zone > transfer is allowed for but the conditions underwhich this will > be done are not specified. This draft does not change this. Your modifications put additional and unnecessary restrictions on a zone transfer. Again, these restrictions have no useful purpose. > > 5) It doesn't say that it changes the security constraints on a zone > > transfer to be limited to deny or accept only. > > Effective it does. If you transmit the zone then you MUST > transmit its full contents unmodified (accept). It also > says that you are allowed to refuse zone transfers (deny). This was addressed in the previous comments. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 20 21:24:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06555 for ; Thu, 20 Feb 2003 21:24:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18m2pO-000HNa-00 for namedroppers-data@psg.com; Thu, 20 Feb 2003 18:22:18 -0800 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #1) id 18m2pM-000HNO-00 for namedroppers@ops.ietf.org; Thu, 20 Feb 2003 18:22:16 -0800 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id VAA22041; Thu, 20 Feb 2003 21:18:30 -0500 Date: Thu, 20 Feb 2003 21:19:51 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Andreas Gustafsson cc: Mark.Andrews@isc.org, Namedroppers , Subject: Re: Bind 9 AXFR Modification vs AXFR Clarification In-Reply-To: <200302202356.h1KNuHT16938@guava.araneus.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,SPAM_PHRASE_03_05,USER_AGENT_PINE, X_OSIRU_SPAM_SRC version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 20 Feb 2003, Andreas Gustafsson wrote: > Dean Anderson writes: > > > > Zone definition and content is not an AXFR issue. Server administrators > > > > provide the definition of zone boundaries. (RFC 1034 Section 2.3 and > > > > elsewhere) AXFR merely gives the contents of the zone as has been defined > > > > according to the boundaries and content specified by the administrator. > > > > > > This is exactly what the draft says, so what are you disagreeing with? > > > > Uhh, no. Draft 05 says quite a bit more. It subtly changes a number of > > things that shouldn't be, and don't need to be changed. In fact, looking > > at my copy, it doesn't say anything like the above at all. (But assuming > > it did, it would be redundant and could be deleted). > > The draft says many things, and I understand that you are objecting to > several of them, but we were specifically discussing zone boundaries, > the subject of section 4. Your statement that "server administrators > provide the definition of zone boundaries" is consistent with the > draft's existing wording and inconsistent with the BIND 4 / BIND 8 > handling of zone boundaries which you previously claimed to support. Actually, I am quoting RFC 1034 directly. Section 2.3. I believe you are misquoting the draft, since its section 4 doesn't say anything like this. Bind 8 will merge glue from child and parent zones. This merging is the reason for the warning not to mix slave and master servers, since the order of this merging is undetermined and the slave can overwrite the glue originally supplied from the parent zone file. > > Section 4 should be deleted. Clearly, glue records need to be merged in. > > Are you saying section 4 should be deleted because you disagree with > it, or because you find it obviously correct and therefore redundant? > Also, which glue records need to be merged into what? I disagree with it. I gave several reasons in more detail in my last message to Mark Andrews: 1) It makes it impossible to dynamically generate zones 2) It makes it impossible to give some data to public secondaries and other data to private/trusted secondaries. 3) It offers no benefits. The parent zone has glue records belonging to the child zone. It is quite reasonable (perhaps not absolutely necessary) for those records to be merged in as though the zone were spread across multiple files. This is an administrative function of the server, on behalf of the human adminstrator. --Dean -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 20 21:38:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06986 for ; Thu, 20 Feb 2003 21:38:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18m33G-000IMd-00 for namedroppers-data@psg.com; Thu, 20 Feb 2003 18:36:38 -0800 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 18m33E-000IMP-00 for namedroppers@ops.ietf.org; Thu, 20 Feb 2003 18:36:36 -0800 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id VAA15121 for ; Thu, 20 Feb 2003 21:36:34 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id VAA20843 for ; Thu, 20 Feb 2003 21:36:34 -0500 (EST) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id VAA20694 for ; Thu, 20 Feb 2003 21:36:33 -0500 (EST) Received: (from ghudson@localhost) by error-messages.mit.edu (8.9.3) id VAA07427; Thu, 20 Feb 2003 21:36:32 -0500 Subject: Re: axfr-clarify breaking RFC 1034 From: Greg Hudson To: namedroppers@ops.ietf.org In-Reply-To: <20030220034148.14684.qmail@cr.yp.to> References: <20030220000752.38144.qmail@cr.yp.to> <200302200225.h1K2Pp4U007052@drugs.dv.isc.org> <20030220034148.14684.qmail@cr.yp.to> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 20 Feb 2003 21:36:31 -0500 Message-Id: <1045794991.1213.168.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Spam-Status: No, hits=2.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM, RCVD_IN_RELAYS_ORDB_ORG,REFERENCES,SPAM_PHRASE_00_01, X_OSIRU_OPEN_RELAY version=2.43 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2003-02-19 at 22:41, D. J. Bernstein wrote: > (To repeat the relevant definitions: A synchronized change happens at > the same time in all the parent servers and all the child servers. A > semi-synchronized change happens in the parent zone---specifically, the > parent serial is changed---after it happens in all the child servers.) Does this mean there can't be unrelated changes in the parent zone while the child servers are still being updated? (Or, more realistically, after the child servers have been updated but before the administrators of the parent zone have processed the change request for the glue records.) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 20 22:46:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08456 for ; Thu, 20 Feb 2003 22:46:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18m44b-000Mdc-00 for namedroppers-data@psg.com; Thu, 20 Feb 2003 19:42:05 -0800 Received: from gusto.araneus.fi ([204.152.186.164]) by psg.com with esmtp (Exim 3.36 #1) id 18m44X-000MdL-00; Thu, 20 Feb 2003 19:42:01 -0800 Received: from guava.araneus.fi (adsl-63-197-0-204.dsl.snfc21.pacbell.net [63.197.0.204]) by gusto.araneus.fi (8.11.6/8.11.6) with ESMTP id h1L3fpZ08838; Thu, 20 Feb 2003 19:41:52 -0800 (PST) Received: (from gson@localhost) by guava.araneus.fi (8.11.6/8.11.6) id h1L3fpq17126; Thu, 20 Feb 2003 19:41:51 -0800 (PST) Date: Thu, 20 Feb 2003 19:41:51 -0800 (PST) Message-Id: <200302210341.h1L3fpq17126@guava.araneus.fi> To: Erik Nordmark Cc: Andreas Gustafsson , ogud@ogud.com, randy@psg.com, namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-unknown-rrs-04.txt In-Reply-To: References: <200302141828.h1EISC210840@guava.araneus.fi> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=0.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Erik Nordmark writes: > > > Note that after RFC 2931 there has been no RR types defined which have > > > an embedded domain name. > > > > This is exactly the kind of statement regarding "defined RRs" I have > > already repeatedly objected to adding. It is true today, but will > > become false as soon as additional RR types with embedded domain names > > are defined, and would cause nothing but confusion to an implementor > > reading it ten years from no. Such a statement does not belong in an > > archival document. > > Please suggest alternate text that captures the fact that this section > doesn't change any RR that is currently issued in an RFC I still think adding text to that effect is a bad idea, regardless of wording. If I understand you correctly, the reason you are asking for this text is is to help assess the impact of the unknown-RRs specification on implementations that currently exist, or that may exist at the time of publication of unknown-rrs as an RFC. That is a reasonable concern, but it is a meta-concern; it should be part of the current discussion about the specification, not part of the specification itself. > > That is not my expectation. There is a precedent for explicit > > statements regarding the applicability of *compression*, but that is > > only because RFC1035 was so ambiguous about where compression was > > allowed that it had to be specified in the individual RR type > > definitions (and even then some RR definitions interpreted RFC1035 > > differently from others). In the case of DNSSEC canonicalization, I > > hope the specification will be complete and unambiguous so that we > > don't have to resort to that kind of workaround. > > I don't understand. > I thought you wanted to specify rules to make unmodified servers/caches > be able to handle new RR types. How can you do that if you allow > future RR types to specify different DNSSEC canonicalization rules? Of course I don't allow future RR types to specify different DNSSEC canonicalization rules. All I said was that I do not expect future definitions of RR types to *explicitly state* that they use the unknown-rrs canonicalization algorithm, just like existing definitions of RR types do not explicitly state that they are using the RFC2535 algorithm. In the absence of an explicit statement, the unknown-RRs specification will apply, just like RFC2535 applies today. -- 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. archive: From owner-namedroppers@ops.ietf.org Thu Feb 20 23:03:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08688 for ; Thu, 20 Feb 2003 23:03:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18m4Lh-000NoS-00 for namedroppers-data@psg.com; Thu, 20 Feb 2003 19:59:45 -0800 Received: from [2001:470:1f00:ffff::5a1] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 18m4LZ-000NkP-00 for namedroppers@ops.ietf.org; Thu, 20 Feb 2003 19:59:38 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h1L3vr4U010801; Fri, 21 Feb 2003 14:57:55 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200302210357.h1L3vr4U010801@drugs.dv.isc.org> To: Dean Anderson Cc: mw-list-namedroppers@csi.hu, Name Droppers , ietf@ietf.org, iesg@ietf.org From: Mark.Andrews@isc.org Subject: Re: Bind 9 AXFR Modification vs AXFR Clarification In-reply-to: Your message of "Thu, 20 Feb 2003 21:07:49 CDT." Date: Fri, 21 Feb 2003 14:57:53 +1100 X-Spam-Status: No, hits=0.5 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > On Fri, 21 Feb 2003 Mark.Andrews@isc.org wrote: > > > > You haven't shown any proof of that. The "proof" you showed, was the > > > result of a misconfiguration. > > > > No. It is the result of operational reality. Whenever you > > have a parent and child zones under different administrative > > controls it is impossible to change both zones simultaniously. > > It is also impossible using AXFR or any other mechanism > > which transfers *individual* zones to transfer them to a > > secondary and guarantee that they will arrive simultaniously. > > > > Having parent and child zone under different administrative control > > is the norm not the execption. > > Actually, a parent always has some control over the child. It exercises > this control through the glue records. When the glue records are in the > child zone, they need to be merged. Which is it. Does the parent control the contents of its zone or does the child? > If a zone transfer happens while they > are inconsistent, it is possible for some strange results to happen. > Ordinarilly, zone transfers don't happen when they are inconsistent, since > the inconsistency is usually short. It doesn't matter if they normally happen while they are consistant. You have to get correct behaviour while they are inconsistant. Changing zone content on SECONDARY servers is not correct behaviour. > Any zone transfers made during the inconsistent window are corrected so > long as the child zone is updated with correct information after the > parent is updated. This is a incorrect statement. > Frequently the parent and child zone are under different administrative > control, and are frequently on different servers. In such a case, the > contents of the parent zone aren't merged with the child in the child's > server, and no evidence of the inconsistency is seen through zone > transfers. However, the inconsistency still exists and may still be > visible by resolvers and nameservers that lookup the glue records. Nobody is claiming that inconsistancies don't occur all the time. What we are claiming is that those inconsistancies need to be preserved in SECONDARY servers for the correct operation of the DNS. That they can only be corrected by modifying the PRIMARY source of the zones. > You have obtained no benefits by these constraints. There are clear benefits in preserving zone contents on SECONDARY servers. > > > > > If the zones are inconsistent through administrative mistake, then it > > > > > won't matter what the IXFR does. > > > > > > > > Who said anything administrative mistakes? The content is bein > g > > > > unilaterally changed by the servers. > > > > > > It is reasonable and necessary to merge in glue. When you misconfigure th > e > > > glue, strange things may happen. That is all that you have shown. I'm > > > sure that many software programs will exhibit even stranger behavior, and > > > may even fail to operate as a result of misconfiguration. > > > > No. It is neither reasonable nor necessary. Any temporary > > inconsistancies will be corrected when all the zone transfers > > complete. By changing the zones contents you create > > situations where these temporary inconsistancies won't be > > corrected. When handing out non axfr/ixfr responses you > > use the best source of data you have. > > It is necessary, since the parent has glue records in the child zone. > The parent therefore has (always) a part of the child zone. If that server > also loads the child zone (or perhaps generates part of it dynamically), > it quite reasonable to merge the records as though the zone includes > multiple files, which in theory, it does. No it isn't. Changes need to come from the PRIMARY source not from intermediate sources. > The child zone contents will only be correct when the administrators of > both zones agree on the contents of the glue records, and update their > parts of the child zone accordingly. It will not be correct until then, > regardless of how many zone transfers take place. Which is what I've been saying all along. It doesn't require a server to "correct" the content at a intermediate point. Such "corrections" actually cause problems. > > Nothing in RFC 1033 / 1034 / 1035 says that a server is permitted > > to alter the content of a zone. The responability for maintaining > > consistancy between zones is a administrative function. > > This is a loaded statement. The part of the server NOT involved in > responding to queries and zone transfers is part of the administrative > function. So, as part of that administrative function, it has to be able > to modify the RR and zones accordingly. Your proposed changes exclude a > huge part of the potential for intelligence in name servers. And do so > with no benefits. The benefits are correct operation of the DNS regardless of the propogation timings involved. If servers don't modify slave zone content then which the master servers are brought into sync all the servers will be brought into sync. This is not guarenteed if the zone content is modified by a secondary server. > > > > > Strange, that was my reaction, too. I'm just trying to be polite. 77 > % > > > > > work just fine. We don't want to break 77% of the servers out there. > > > > > > > > You really think that it will break those servers? LOL. > > > > > > They will not be compliant, and thus will need to be changed. Thus, they > > > would be broken by definition of not being compliant. > > > > So. Just because they will not be compliant doesn't mean > > that that they need to be replaced immediately. That > > non-compliance doesn't hurt most of them. For those where > > it does have a negative impact it will mean that they should > > be able to request a fix from their vendor. > > You seem to make a case that in general, non-compliance doesn't hurt > anything. This is false, for both technical and commercial reasons. > Technically, it hurts interoperability, which has some many obvious harms > I won't go into them. Commercially, implementations make and advertise > compatibility and standards compliance claims. This retroactively makes > those claims false, which harms the business and reputation of those other > vendors. They will be harmed much more if they don't correct a common error now that it has been pointed out. The claims were made in good faith and will be accepted as such. > 77% will need a fix from the vendor, if we were to accept these changes. > > The vendor that made false claims of compatibility and standards > compliance is Bind 9. It should suffer the commercial damage to its > business and reputation, as a result. BIND 9 conforms to RFC 1034. Nothing in RFC 1034 says to merge zone content. If fact 1034 says that this a administrative responsability. > > > Your failure to comprehend the consequences of the changes does not lesse > n > > > the effect. We now agree that these changes aren't necessary to support > > > IXFR. You were part of the bad engineering that led to the unnecessary > > > creation of these changes in Bind 9. You were also part of the bad > > > decision making that led to the distribution of these changes to Bind 9 > > > users prior to standardization, and quite possibly you were part of the > > > bad decision making that resulted in publishing a book on the subject, > > > prior to acceptance of your modifications to standards. In short, you hav > e > > > shown bad judgement. > > > > I never said that they we not necessary for IXFR. I said that > > that your descripition of how to generate the differences was > > irrelevent to this discussion. > > Ok, you are half way there. They are irrelevant because IXFR is > irrelevant. These changes are not necessary to IXFR, as I explained that > IXFR can work with the current AXFR, or even without AXFR. IXFR cannot work through SECONDARY servers that change zone content regardless of whether the content was learnt via AXFR or IXFR. > > It was bad engineering to merge the data sets together in the > > first place. It was not required by RFC 1033/ 1034 / 1035. > > It had negative consequences. It was good engineering to > > correct this. It was also good engineering to report a > > common error to the community so that other vendors could > > fix their mistakes. > > Actually, since the parent has the glue in the child zone, it has part of > the child zone as well as the master zone. Merging them together is not > prohibited, and in the case where child and parent have the same > adminstrator, as might be the case where most of the child is simply > automatically generated by the nameserver, can make things much easier. > > Your constraints preclude this unnecessarilly. The constraint in on the SECONDARY server. > Since I can think of cases where it is useful to merge records together, > it is bad engineering to remove that flexibility and obtain no benefits in > return. > > > > Trying to "belittle" the effects with the "LOL", as opposed to offering > > > anything substantive, simply suggests that you have no appreciation of th > e > > > seriousness of the changes. Perhaps you should take this more seriously. > > > > I'm quite aware of what the change requires. I'm also aware > > that most of the nameserver are used in situations where > > the zone contents is already preserved because they are not > > serving zones with parent / child relationships. > > Apparently, you aren't even aware that your changes will make all non-bind > 9 servers non-compliant. Had you been aware of that, it seems you would > have brought this proposal forward something like 3 years ago, before > releasing Bind 9, and before publishing a book on the subject. Well you obviously have not been reading. ISC is not the only vendor to come to the same conclusion about preserving zone content. I suspect that they are just bored with arguing with you and Dan. > > Anyone saying that all the nameservers need to be replaced > > immediately is spreading FUD. LOL the the correct reponse > > to FUD. > > Making 77% of the servers non-compliant is a fact of your proposed > changes. It is another fact, as explained, that non-compliant servers > will need to be replaced. Will they suddenly stop working? It depends on > whether other implementations want to implement a "backwards > compatibility" mode. If they don't implement this mode, then the answer is > yes, they will stop working as soon as these updates are deployed by other > vendors. Of course, this is a bad result. Well they havn't stopped working in the last two years that this code has been out there. Nothing in this drafts stops a server implementing it taking to any other server. There is one backwards compatiblity switch which is only requires if you decide to send multiple records in a single messages. A server is not required to send multiple records in a single message. > > Using a server that perserves zone contents under all > > conditions doesn't break anything. > > Your constraints break useful services, and offer no value in return. What's useful about modifing the contents of a slave zone? All I can see is harm. > > > 1) It doesn't say that it adds a completely new, incompatible zone > > > transfer protocol. New protocols should be made through a different > > > process, which includes experimentation. I'm not against experimenting > > > with a new protocol. Indeed, I think this idea has some merit. However, i > t > > > can't be "end-run standardized" by a "clarification". There is a process. > > > > It isn't new. All it is saying is that the contents tramitted > > out MUST be that transmitted in. This occurs most of the time > > already. Note BIND is not the only implementation that does > > this. We have already had reports of 3 other implementations > > doing this. Even the implementations that don't guarentee the > > contents do this most of the time. It has no negative effects. > > No, Section 3.1 is a whole new derivative of AXFR. That is new. Actually it's always been allowed by RFC 1034. Just because it wasn't implement initially doesn't mean that it was not allowed. > > > 2) It doesn't say that it changes AXFR with respect to SIG > > > > It doesn't change anything wrt to SIG. Go read RFC 2535 which > > also says that SIG records in the answer section are part of the > > zone contents and don't need special processing. > > Oh. Then section 3.3 can be deleted in entirety without objection. > > > > 3) It doesn't say that it changes the status of other RFC's (RFC 2845, an > d > > > possibly others.) without going through the appropriate standards process > . > > > > It doen't change the status of RFC 2845. > > The IEFT index indicates that RFC 2845 is "Proposed Standard", with no > applicability statement that I could find. This changes it to > "RECOMMENDED" requirement level. I think an applicability statement is > premature until RFC 2845 is moved along, and then by the appropriate > standards body decision-making process. It is inappropriate to hide > something like this deep in an irrelevant "clarification". > > > > 4) It doesn't say that it changes the definition of zone data to be > > > public. Zone data is absolutely not "public by definition". It could very > > > well be useful to tag certain RRs as non-public, and exclude them from > > > zone transfers to public servers. This "clarification" precludes that. > > > This is really 2 changes. > > > > Nowhere in RFC 1033 / 1034 / 1035 does it say that zone transfers > > are restricted to secondaries. Nowhere in RFC 1033 / 1034 / 1035 > > does it say that you should restrict zone tranfers. > > I don't think you understood my statement. I'm talking about the > definition of zone data. Nowhere does 1034 etc say that zone data is > public. It may well have been thought to be public, originally, but since > I can easily see a useful purpose in withholding some private RRs, there > isn't any reason to preclude that behavior. Does this address your concerns? "The zone transfer protocol allows read-only access to the complete zone data. When the data being served to the public it is generally acceptable to allow unrestricted access to it via AXFR. Sites that wish to avoid disclosing their full zone data MAY restrict zone transfer access to authorized slaves." If you have part of a zone to which you would normally return REFUSED to I suggest that you also return REFUSED to AXFR. If you want to be able to return partial zones then I suggest that a new TYPE be defined so that receipients can know that the results will be incomplete. > Your constraints harm a useful purpose, and provide no benefits. > > There is a REFUSED rcode so the possibility of refusing a zone > > transfer is allowed for but the conditions underwhich this will > > be done are not specified. This draft does not change this. > > Your modifications put additional and unnecessary restrictions on a zone > transfer. Again, these restrictions have no useful purpose. > > > 5) It doesn't say that it changes the security constraints on a zone > > > transfer to be limited to deny or accept only. > > > > Effective it does. If you transmit the zone then you MUST > > transmit its full contents unmodified (accept). It also > > says that you are allowed to refuse zone transfers (deny). > > This was addressed in the previous comments. > > -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 20 23:06:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08775 for ; Thu, 20 Feb 2003 23:06:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18m4QK-000O9X-00 for namedroppers-data@psg.com; Thu, 20 Feb 2003 20:04:32 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 18m4QI-000O9A-00 for namedroppers@ops.ietf.org; Thu, 20 Feb 2003 20:04:30 -0800 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 81A5C137F02; Thu, 20 Feb 2003 20:04:28 -0800 (PST) Date: Thu, 20 Feb 2003 20:04:32 -0800 Subject: Re: axfr-clarify's fraudulent claims of consensus Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Kevin Darcy , namedroppers@ops.ietf.org To: Dean Anderson From: David Conrad In-Reply-To: Message-Id: <94EB3B78-4551-11D7-A854-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-3.8 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,TO_BE_REMOVED_REPLY,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dean, It would probably be helpful if you desist from ad hominem attacks. Rgds, -drc On Tuesday, February 18, 2003, at 03:10 PM, Dean Anderson wrote: > > > On Mon, 17 Feb 2003, Kevin Darcy wrote: > >> I just want AXFR and IXFR to be compatible. And I don't think DJB's >> poor >> design decisions should stand in the way of that. > > DJB's decisions don't stand in the way of that. Just the opposite. > > Bind 9 broke AXFR, due to bad programming, bad management, and lazy > engineering. Now, instead of admitting the mistakes, they want to > change > AXFR, and are trying (lamely, I might add) to say that AXFR MUST be > changed to support IXFR. > > AXFR has NOTHING WHATSOEVER to do with IXFR. This is a simple proof, > the > outlines of which I have already given. > > > --Dean > > > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 20 23:21:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08999 for ; Thu, 20 Feb 2003 23:21:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18m4gA-000PXs-00 for namedroppers-data@psg.com; Thu, 20 Feb 2003 20:20:54 -0800 Received: from [2001:4f8:3:bb:2e0:81ff:fe23:7b5a] (helo=as.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 18m4g8-000PWq-00 for namedroppers@ops.ietf.org; Thu, 20 Feb 2003 20:20:52 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id F362E379E40; Fri, 21 Feb 2003 04:20:38 +0000 (GMT) From: Paul Vixie To: Greg Hudson Cc: namedroppers@ops.ietf.org Subject: Re: axfr-clarify breaking RFC 1034 In-Reply-To: Message from Greg Hudson of "20 Feb 2003 21:36:31 EST." <1045794991.1213.168.camel@error-messages.mit.edu> X-Mailer: MH-E 7.2; nmh 1.0.4; GNU Emacs 21.2.1 Date: Fri, 21 Feb 2003 04:20:38 +0000 Message-Id: <20030221042038.F362E379E40@as.vix.com> X-Spam-Status: No, hits=-0.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, TO_BE_REMOVED_REPLY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk this is all just fantasy, and not about dns at all (yet). the protocol as specified has zone boundaries and the parent's zone bottom is unauthoritative glue. any implementation which mixes data from the child apex into the parent zone-bottom is incorrect. this discussion is significantly off course. let's talk about clarifying axfr. > X-Original-To: vixie@vix.com > Subject: Re: axfr-clarify breaking RFC 1034 > From: Greg Hudson > To: namedroppers@ops.ietf.org > X-Mailer: Ximian Evolution 1.0.5 > Date: 20 Feb 2003 21:36:31 -0500 > Sender: owner-namedroppers@ops.ietf.org > > On Wed, 2003-02-19 at 22:41, D. J. Bernstein wrote: > > (To repeat the relevant definitions: A synchronized change happens at > > the same time in all the parent servers and all the child servers. A > > semi-synchronized change happens in the parent zone---specifically, the > > parent serial is changed---after it happens in all the child servers.) > > Does this mean there can't be unrelated changes in the parent zone while > the child servers are still being updated? (Or, more realistically, > after the child servers have been updated but before the administrators > of the parent zone have processed the change request for the glue > records.) > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 20 23:39:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09194 for ; Thu, 20 Feb 2003 23:39:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18m4wW-0000oa-00 for namedroppers-data@psg.com; Thu, 20 Feb 2003 20:37:48 -0800 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #1) id 18m4wU-0000oN-00 for namedroppers@ops.ietf.org; Thu, 20 Feb 2003 20:37:46 -0800 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id XAA05353; Thu, 20 Feb 2003 23:31:37 -0500 Date: Thu, 20 Feb 2003 23:32:58 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: David Conrad cc: Kevin Darcy , Subject: Re: axfr-clarify's fraudulent claims of consensus In-Reply-To: <94EB3B78-4551-11D7-A854-000393DB42B2@nominum.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,SPAM_PHRASE_00_01, TO_BE_REMOVED_REPLY,USER_AGENT_PINE,X_OSIRU_SPAM_SRC version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I presume you mean this: > > Bind 9 broke AXFR, due to bad programming, bad management, and lazy > > engineering. Now, instead of admitting the mistakes, they want to > > change AXFR, and are trying (lamely, I might add) to say that AXFR > > MUST be changed to support IXFR. This is a true and fair criticism. If it is embarrasing to someone or to some group of people, that isn't my problem, nor is it an ad hominem, which means an attack on some person's personal traits, like calling someone fat or something. Making a fair criticism isn't an ad hominem. --Dean On Thu, 20 Feb 2003, David Conrad wrote: > Dean, > > It would probably be helpful if you desist from ad hominem attacks. > > Rgds, > -drc > > On Tuesday, February 18, 2003, at 03:10 PM, Dean Anderson wrote: > > > > > > > On Mon, 17 Feb 2003, Kevin Darcy wrote: > > > >> I just want AXFR and IXFR to be compatible. And I don't think DJB's > >> poor > >> design decisions should stand in the way of that. > > > > DJB's decisions don't stand in the way of that. Just the opposite. > > > > Bind 9 broke AXFR, due to bad programming, bad management, and lazy > > engineering. Now, instead of admitting the mistakes, they want to > > change > > AXFR, and are trying (lamely, I might add) to say that AXFR MUST be > > changed to support IXFR. > > > > AXFR has NOTHING WHATSOEVER to do with IXFR. This is a simple proof, > > the > > outlines of which I have already given. > > > > > > --Dean > > > > > > > > > > -- > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > > > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 20 23:56:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09550 for ; Thu, 20 Feb 2003 23:56:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18m59R-0001l7-00 for namedroppers-data@psg.com; Thu, 20 Feb 2003 20:51:09 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 18m59N-0001kn-00 for namedroppers@ops.ietf.org; Thu, 20 Feb 2003 20:51:06 -0800 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 35841137F02; Thu, 20 Feb 2003 20:51:04 -0800 (PST) Date: Thu, 20 Feb 2003 20:51:07 -0800 Subject: Re: axfr-clarify's fraudulent claims of consensus Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Kevin Darcy , To: Dean Anderson From: David Conrad In-Reply-To: Message-Id: <172C76B0-4558-11D7-A854-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I presume you mean this: > >>> Bind 9 broke AXFR, due to bad programming, bad management, and lazy >>> engineering. Now, instead of admitting the mistakes, they want to >>> change AXFR, and are trying (lamely, I might add) to say that AXFR >>> MUST be changed to support IXFR. > This is a true and fair criticism. No. It is a subjective and erroneous evaluation based on incomplete and incorrect information. Instead of expressing specific concerns about the protocol in a constructive way you are attacking the programming, management, and engineering of the people who wrote BINDv9. Rgds, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 21 00:33:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10080 for ; Fri, 21 Feb 2003 00:33:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18m5ib-0004MT-00 for namedroppers-data@psg.com; Thu, 20 Feb 2003 21:27:29 -0800 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #1) id 18m5iW-0004LE-00 for namedroppers@ops.ietf.org; Thu, 20 Feb 2003 21:27:24 -0800 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id AAA14903; Fri, 21 Feb 2003 00:24:34 -0500 Date: Fri, 21 Feb 2003 00:25:56 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Mark.Andrews@isc.org cc: mw-list-namedroppers@csi.hu, Name Droppers , , Subject: Re: Bind 9 AXFR Modification vs AXFR Clarification In-Reply-To: <200302210357.h1L3vr4U010801@drugs.dv.isc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,SPAM_PHRASE_01_02,USER_AGENT_PINE, X_OSIRU_SPAM_SRC version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 21 Feb 2003 Mark.Andrews@isc.org wrote: > > > On Fri, 21 Feb 2003 Mark.Andrews@isc.org wrote: > > > > > > You haven't shown any proof of that. The "proof" you showed, was the > > > > result of a misconfiguration. > > > > > > No. It is the result of operational reality. Whenever you > > > have a parent and child zones under different administrative > > > controls it is impossible to change both zones simultaniously. > > > It is also impossible using AXFR or any other mechanism > > > which transfers *individual* zones to transfer them to a > > > secondary and guarantee that they will arrive simultaniously. > > > > > > Having parent and child zone under different administrative control > > > is the norm not the execption. > > > > Actually, a parent always has some control over the child. It exercises > > this control through the glue records. When the glue records are in the > > child zone, they need to be merged. > > Which is it. Does the parent control the contents of its zone > or does the child? You seem not to understand the subtlety of the issue. The parent (like real parents) ultimately controls the child, but the child (like real children) has limited autonomy. > > If a zone transfer happens while they > > are inconsistent, it is possible for some strange results to happen. > > Ordinarilly, zone transfers don't happen when they are inconsistent, since > > the inconsistency is usually short. > > It doesn't matter if they normally happen while they are > consistant. You have to get correct behaviour while they > are inconsistant. Changing zone content on SECONDARY servers > is not correct behaviour. Sure it is. Unless you can arrange to conduct both updates simultaneosly. While it would be possible to coordinate such changes on the phone, relativity could come into play someday. It has nothing to do with zone transfers. Its part of the state of the system. Zone transfers is only one way to learn about the state of the system. > > Any zone transfers made during the inconsistent window are corrected so > > long as the child zone is updated with correct information after the > > parent is updated. > > This is a incorrect statement. Could you elaborate? > > Frequently the parent and child zone are under different administrative > > control, and are frequently on different servers. In such a case, the > > contents of the parent zone aren't merged with the child in the child's > > server, and no evidence of the inconsistency is seen through zone > > transfers. However, the inconsistency still exists and may still be > > visible by resolvers and nameservers that lookup the glue records. > > Nobody is claiming that inconsistancies don't occur all the > time. What we are claiming is that those inconsistancies > need to be preserved in SECONDARY servers for the correct > operation of the DNS. That they can only be corrected by > modifying the PRIMARY source of the zones. ??? I can't parse this with respect to your previous statements. Could you rephrase it? During the period in which the zone is inconsistent, there is no guarantee the zone will work. Depending on the nature of the change, wrong information may be given in queries as well. Suppose the parent is removing control from the child, and has updated the glue to remove referals to the child nameservers. For some time (the TTL, at least), the original child servers will be queried. On the other hand, the child zone may not even exist yet on the childs nameservers. Referals to the zone fail. To make a concrete example, Osama registers alquaeda.com, and begins coordinating his evil deeds. The registrar delegates the alquaeda.com as a child of .com. Eventually, the government intervenes, and .com replaces Osamas nameserver glue with new glue pointing to government servers. For a time, this zone will be inconsistent. Note that in this case, the zone transfers will not indicate the inconsistency. However, for a short time, Osama will be able to put up a message warning his followers not to go to the government run site. This can't be avoided, no matter what gyrations you put AXFR through. It makes no difference that the inconsistency _could_, _in_some_cases_, be seen at the secondaries. > > You have obtained no benefits by these constraints. > > There are clear benefits in preserving zone contents on > SECONDARY servers. Such as? Your term "preserving zone contents" is misleading. The zone contents are not corrupted. The glue is inconsistent. What is the benefit of preventing any trace of inconsistency in the secondary? It has nothing to do with IXFR. It has nothing to do with anything. > > It is necessary, since the parent has glue records in the child zone. > > The parent therefore has (always) a part of the child zone. If that server > > also loads the child zone (or perhaps generates part of it dynamically), > > it quite reasonable to merge the records as though the zone includes > > multiple files, which in theory, it does. > > No it isn't. Changes need to come from the PRIMARY source not > from intermediate sources. The intermediate sources aren't making changes. They are, at worst, propogating old information mixed with new information. However, this is visible in other ways besides zone transfers. > > The child zone contents will only be correct when the administrators of > > both zones agree on the contents of the glue records, and update their > > parts of the child zone accordingly. It will not be correct until then, > > regardless of how many zone transfers take place. > > Which is what I've been saying all along. It doesn't require > a server to "correct" the content at a intermediate point. Such > "corrections" actually cause problems. Good. Then you agree that Bind 8 behavior is correct. > > > Nothing in RFC 1033 / 1034 / 1035 says that a server is permitted > > > to alter the content of a zone. The responability for maintaining > > > consistancy between zones is a administrative function. > > > > This is a loaded statement. The part of the server NOT involved in > > responding to queries and zone transfers is part of the administrative > > function. So, as part of that administrative function, it has to be able > > to modify the RR and zones accordingly. Your proposed changes exclude a > > huge part of the potential for intelligence in name servers. And do so > > with no benefits. > > The benefits are correct operation of the DNS regardless of the > propogation timings involved. If servers don't modify slave zone > content then which the master servers are brought into sync all > the servers will be brought into sync. We already have correct operation of DNS. The zone contents are inconsistent until both adminstrators come to agreement. The child zone should be updated last. After the child zone is brought into agreement with the parent glue, zone transfers will be made which are correct. Only then will zone transfers will be correct. Zone transfers made while the administrators are not in agreement will not be correct, even if there is no apparent evidence in the zone data from the child (such as a mixture of new and old glue) they are still incorrect. NS Queries against the parent and child servers will return different results. > This is not guarenteed if the zone content is modified by a > secondary server. > > > > > > > Strange, that was my reaction, too. I'm just trying to be polite. 77 > > % > > > > > > work just fine. We don't want to break 77% of the servers out there. > > > > > > > > > > You really think that it will break those servers? LOL. > > > > > > > > They will not be compliant, and thus will need to be changed. Thus, they > > > > would be broken by definition of not being compliant. > > > > > > So. Just because they will not be compliant doesn't mean > > > that that they need to be replaced immediately. That > > > non-compliance doesn't hurt most of them. For those where > > > it does have a negative impact it will mean that they should > > > be able to request a fix from their vendor. > > > > You seem to make a case that in general, non-compliance doesn't hurt > > anything. This is false, for both technical and commercial reasons. > > Technically, it hurts interoperability, which has some many obvious harms > > I won't go into them. Commercially, implementations make and advertise > > compatibility and standards compliance claims. This retroactively makes > > those claims false, which harms the business and reputation of those other > > vendors. > > They will be harmed much more if they don't correct a common > error now that it has been pointed out. Except, there are no errors, beyond a window of inconsistency that cannot be avoided, and in fact, that window isn't fixed. Nor do you fix the "error". They are _still_ inconsistent for a period. And the child will _still_ have to be updated last. > The claims were made in good faith and will be accepted as > such. I'm not convinced. If they were, we would have argued this before Bind 9 was released, and before a book was sent out. Probably about 3 years ago. Someone knew years ago when they wrote the "backward compatibility" mode, that they had a protocol issue that would have to come before namedroppers. That they delayed for so long doesn't indicate good faith to me. > > 77% will need a fix from the vendor, if we were to accept these changes. > > > > The vendor that made false claims of compatibility and standards > > compliance is Bind 9. It should suffer the commercial damage to its > > business and reputation, as a result. > > BIND 9 conforms to RFC 1034. Nothing in RFC 1034 says to > merge zone content. If fact 1034 says that this a administrative > responsability. It does right now, due to a knowingly reckless exploitation of ambiguity in the AXFR. Once AXFR is clarified, Bind 9 will have to use its 'backward compatibility' mode to be compliant. It is "knowingly reckless" because the Bind 9 implementers _KNEW_ they needed to provide a "backward compatibility". That means they knew what they were doing was incompatible with any (all actually) reasonable interpretation (however ambiguous) of 1034. > > > > Your failure to comprehend the consequences of the changes does not lesse > > n > > > > the effect. We now agree that these changes aren't necessary to support > > > > IXFR. You were part of the bad engineering that led to the unnecessary > > > > creation of these changes in Bind 9. You were also part of the bad > > > > decision making that led to the distribution of these changes to Bind 9 > > > > users prior to standardization, and quite possibly you were part of the > > > > bad decision making that resulted in publishing a book on the subject, > > > > prior to acceptance of your modifications to standards. In short, you hav > > e > > > > shown bad judgement. > > > > > > I never said that they we not necessary for IXFR. I said that > > > that your descripition of how to generate the differences was > > > irrelevent to this discussion. > > > > Ok, you are half way there. They are irrelevant because IXFR is > > irrelevant. These changes are not necessary to IXFR, as I explained that > > IXFR can work with the current AXFR, or even without AXFR. > > IXFR cannot work through SECONDARY servers that change zone > content regardless of whether the content was learnt via > AXFR or IXFR. Sure it can. It doesn't need AXFR at all. And the secondary's aren't making arbitrary changes at all. > > > It was bad engineering to merge the data sets together in the > > > first place. It was not required by RFC 1033/ 1034 / 1035. > > > It had negative consequences. It was good engineering to > > > correct this. It was also good engineering to report a > > > common error to the community so that other vendors could > > > fix their mistakes. > > > > Actually, since the parent has the glue in the child zone, it has part of > > the child zone as well as the master zone. Merging them together is not > > prohibited, and in the case where child and parent have the same > > adminstrator, as might be the case where most of the child is simply > > automatically generated by the nameserver, can make things much easier. > > > > Your constraints preclude this unnecessarilly. > > The constraint in on the SECONDARY server. So? It is still unnecesary. > > Since I can think of cases where it is useful to merge records together, > > it is bad engineering to remove that flexibility and obtain no benefits in > > return. > > > > > > Trying to "belittle" the effects with the "LOL", as opposed to offering > > > > anything substantive, simply suggests that you have no appreciation of th > > e > > > > seriousness of the changes. Perhaps you should take this more seriously. > > > > > > I'm quite aware of what the change requires. I'm also aware > > > that most of the nameserver are used in situations where > > > the zone contents is already preserved because they are not > > > serving zones with parent / child relationships. > > > > Apparently, you aren't even aware that your changes will make all non-bind > > 9 servers non-compliant. Had you been aware of that, it seems you would > > have brought this proposal forward something like 3 years ago, before > > releasing Bind 9, and before publishing a book on the subject. > > Well you obviously have not been reading. ISC is not the > only vendor to come to the same conclusion about preserving > zone content. I suspect that they are just bored with > arguing with you and Dan. I think they just haven't really read the proposal's, and have taken some misleading assurances at face value. > > > Anyone saying that all the nameservers need to be replaced > > > immediately is spreading FUD. LOL the the correct reponse > > > to FUD. > > > > Making 77% of the servers non-compliant is a fact of your proposed > > changes. It is another fact, as explained, that non-compliant servers > > will need to be replaced. Will they suddenly stop working? It depends on > > whether other implementations want to implement a "backwards > > compatibility" mode. If they don't implement this mode, then the answer is > > yes, they will stop working as soon as these updates are deployed by other > > vendors. Of course, this is a bad result. > > Well they havn't stopped working in the last two years that > this code has been out there. Nothing in this drafts stops > a server implementing it taking to any other server. Uhh, wrong. The drafts make the current AXFR non-compliant. There is nothing that would require a server to implement the old AXFR and provide a "backwards compatibility" mode such as Bind 9 has. So servers running today, won't be able to talk to strictly compliant servers that don't have a backwards compatibility mode. > There is one backwards compatiblity switch which is only > requires if you decide to send multiple records in a single > messages. A server is not required to send multiple records > in a single message. But is allowed to, and a server that can't receive such messages won't be able to get the zone. > > > > 1) It doesn't say that it adds a completely new, incompatible zone > > > > transfer protocol. New protocols should be made through a different > > > > process, which includes experimentation. I'm not against experimenting > > > > with a new protocol. Indeed, I think this idea has some merit. However, i > > t > > > > can't be "end-run standardized" by a "clarification". There is a process. > > > > > > It isn't new. All it is saying is that the contents tramitted > > > out MUST be that transmitted in. This occurs most of the time > > > already. Note BIND is not the only implementation that does > > > this. We have already had reports of 3 other implementations > > > doing this. Even the implementations that don't guarentee the > > > contents do this most of the time. It has no negative effects. > > > > No, Section 3.1 is a whole new derivative of AXFR. That is new. > > Actually it's always been allowed by RFC 1034. Just because > it wasn't implement initially doesn't mean that it was not > allowed. Uhh, wrong, except in an unreasonably broad technical exception due to the vagueness of 1034. > > > > 4) It doesn't say that it changes the definition of zone data to be > > > > public. Zone data is absolutely not "public by definition". It could very > > > > well be useful to tag certain RRs as non-public, and exclude them from > > > > zone transfers to public servers. This "clarification" precludes that. > > > > This is really 2 changes. > > > > > > Nowhere in RFC 1033 / 1034 / 1035 does it say that zone transfers > > > are restricted to secondaries. Nowhere in RFC 1033 / 1034 / 1035 > > > does it say that you should restrict zone tranfers. > > > > I don't think you understood my statement. I'm talking about the > > definition of zone data. Nowhere does 1034 etc say that zone data is > > public. It may well have been thought to be public, originally, but since > > I can easily see a useful purpose in withholding some private RRs, there > > isn't any reason to preclude that behavior. > > Does this address your concerns? No. Because it might be reasonable not to give complete zone data. > "The zone transfer protocol allows read-only access to the complete > zone data. When the data being served to the public it is > generally acceptable to allow unrestricted access to it via AXFR. > Sites that wish to avoid disclosing their full zone data MAY > restrict zone transfer access to authorized slaves." > > If you have part of a zone to which you would normally > return REFUSED to I suggest that you also return REFUSED > to AXFR. > > If you want to be able to return partial zones then I suggest > that a new TYPE be defined so that receipients can know > that the results will be incomplete. So far as the secondary is concerned, the zone is complete. If you do this, you don't want to tell people that you have some data that isn't public. Nor would you ever need to. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 21 00:47:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10262 for ; Fri, 21 Feb 2003 00:47:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18m5xW-0005Vb-00 for namedroppers-data@psg.com; Thu, 20 Feb 2003 21:42:54 -0800 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #1) id 18m5xT-0005V2-00 for namedroppers@ops.ietf.org; Thu, 20 Feb 2003 21:42:51 -0800 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id AAA06560; Fri, 21 Feb 2003 00:39:57 -0500 Date: Fri, 21 Feb 2003 00:41:19 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: David Conrad cc: Kevin Darcy , Subject: Re: axfr-clarify's fraudulent claims of consensus In-Reply-To: <172C76B0-4558-11D7-A854-000393DB42B2@nominum.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,SPAM_PHRASE_00_01,USER_AGENT_PINE, X_OSIRU_SPAM_SRC version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I'm not attacking them. I'm criticizing them, fairly, I might add. As I wrote in another mail, when they put in a "backward compatibility" mode, they knew (years ago) that they had a protocol issue that would have to come before namedroppers and the ietf. They delayed. Instead, they released code to users, and wrote a book. Those were clearly a bad decisions. (note the plural) They justly deserve criticism for that. Further, they wrongly concluded that these changes were necessary to implement IXFR. Even if we assume that was an honest mistake, then it was still a _MISTAKE_, for which they justly deserve criticism. On Thu, 20 Feb 2003, David Conrad wrote: > > I presume you mean this: > > > >>> Bind 9 broke AXFR, due to bad programming, bad management, and lazy > >>> engineering. Now, instead of admitting the mistakes, they want to > >>> change AXFR, and are trying (lamely, I might add) to say that AXFR > >>> MUST be changed to support IXFR. > > This is a true and fair criticism. > > No. It is a subjective and erroneous evaluation based on incomplete > and incorrect information. Instead of expressing specific concerns > about the protocol in a constructive way you are attacking the > programming, management, and engineering of the people who wrote BINDv9. > > Rgds, > -drc > > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 21 01:31:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10667 for ; Fri, 21 Feb 2003 01:31:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18m6ef-0004SJ-00 for namedroppers-data@psg.com; Thu, 20 Feb 2003 22:27:29 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #1) id 18m6ed-0004S7-00 for namedroppers@ops.ietf.org; Thu, 20 Feb 2003 22:27:27 -0800 Received: (qmail 32231 invoked by uid 1016); 21 Feb 2003 06:27:51 -0000 Date: 21 Feb 2003 06:27:51 -0000 Message-ID: <20030221062751.32230.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: axfr-clarify breaking RFC 1034 References: <20030220000752.38144.qmail@cr.yp.to> <200302200225.h1K2Pp4U007052@drugs.dv.isc.org> <20030220034148.14684.qmail@cr.yp.to> <1045794991.1213.168.camel@error-messages.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Greg Hudson writes: > Does this mean there can't be unrelated changes in the parent zone while > the child servers are still being updated? No. You can make as many other changes, and corresponding serial-number updates, as you want. Semi-synchronization refers to the timing of the parent serial-number update corresponding to a child-zone change. Presumably you're accustomed to the following zone update procedure for glue data: (1) Change the data in the child zone on the child master. (2) Change the child serial number. This must be done after #1. (I mean >=, not >, when I say ``after''; you probably do #1 and #2 at the same time.) (3) Copy the new data to all the child slaves. (4) Change the data in the parent zone on the parent master. (5) Change the parent serial number. This must be done after #4. (6) Copy the new data to all the parent slaves. The definition of a semi-synchronized change is simply that #5 is done after #3; you don't finish the parent update until all the child servers have been updated. (The definition of a synchronized change is that #1, #2, #3, #4, #5, #6 happen at the same time.) Mark's problems can't occur unless he changes the parent serial number too early. It's fine for other updates to be happening at the same time. In fact, Mark's problems can't occur for active zones, even if he does screw up the timing of #5 for one update; the next update wipes out all of the inconsistencies that he created by screwing up the configuration. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 21 01:32:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10704 for ; Fri, 21 Feb 2003 01:32:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18m6iC-0004iq-00 for namedroppers-data@psg.com; Thu, 20 Feb 2003 22:31:08 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18m6iA-0004id-00 for namedroppers@ops.ietf.org; Thu, 20 Feb 2003 22:31:07 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18m6i9-000II6-00 for namedroppers@ops.ietf.org; Fri, 21 Feb 2003 15:31:06 +0900 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Fri, 21 Feb 2003 08:25:57 +0200 (EET) From: Pekka Savola To: Alain Durand cc: Ralph Droms , , , Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt X-Spam-Status: No, hits=-1.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RESENT_TO, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_02_03,USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] On Thu, 20 Feb 2003, Alain Durand wrote: > On Thursday, February 20, 2003, at 12:03 PM, Ralph Droms wrote: > > If it's unclear, then we should edit the document to explicitly > > identify the addresses as IPv6 addresses. > > > > This option is intended to return IPv6 configuration information. > > IPv4 addresses for DNS resolvers should be provided through DHCPv4... I symphatize with this -- there are some uses to have DHCPv6 return IPv4 addresses too -- but the result would just make the dnsconfig option more complex for little benefit. Let's face it: if you deploy DHCPv6, you really should have long since deployed IPv6-enabled nameservers too. So, I think clarifying the scope to do only IPv6 seems like the best option by far. > Now, let's say that this is the case for DHCP, what should a node that > act both as a DHCPv4 and DHCPv6 client do when it will be returned two > lists of recursive DNS serves, one IPv4 via DHCPv4 and one IPv6 via > DHCPv6. Which one should take priority? Implementation decision, but I guess typically the results of the latest query take precedence. I don't see a problem here, myself. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 21 01:37:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10817 for ; Fri, 21 Feb 2003 01:37:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18m6nv-0005DB-00 for namedroppers-data@psg.com; Thu, 20 Feb 2003 22:37:03 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #1) id 18m6ns-0005Cz-00 for namedroppers@ops.ietf.org; Thu, 20 Feb 2003 22:37:00 -0800 Received: (qmail 35915 invoked by uid 1016); 21 Feb 2003 06:37:25 -0000 Date: 21 Feb 2003 06:37:25 -0000 Message-ID: <20030221063725.35914.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: Bind 9 AXFR Modification vs AXFR Clarification References: <200302202233.h1KMXO4U009264@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mark.Andrews@isc.org writes: > Whenever you have a parent and child zones under different administrative > controls it is impossible to change both zones simultaniously. False. Set the clocks correctly, and schedule the change on all the servers for a particular time, using (for example) the tinydns timestamp feature described in http://cr.yp.to/djbdns/tinydns-data.html. When that time rolls around, all the servers will change their data simultaneously, as RFC 1034 requires. Yes, this is difficult to achieve with BIND, AXFR, etc. But it's easy to achieve with better software, better replication protocols, etc. You're making a fool of yourself when you call it ``impossible.'' ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 21 01:41:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10867 for ; Fri, 21 Feb 2003 01:41:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18m6qO-0005SE-00 for namedroppers-data@psg.com; Thu, 20 Feb 2003 22:39:36 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #1) id 18m6qL-0005S1-00 for namedroppers@ops.ietf.org; Thu, 20 Feb 2003 22:39:33 -0800 Received: from esunmail ([129.147.58.120]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA27868 for ; Thu, 20 Feb 2003 23:39:32 -0700 (MST) Received: from xpa-fe1 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTP id <0HAN005KRBS00E@edgemail1.Central.Sun.COM> for namedroppers@ops.ietf.org; Thu, 20 Feb 2003 23:38:24 -0700 (MST) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTPSA id <0HAN006WTBRYVU@mail.sun.net> for namedroppers@ops.ietf.org; Thu, 20 Feb 2003 23:38:24 -0700 (MST) Date: Thu, 20 Feb 2003 22:39:29 -0800 From: Alain Durand Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-reply-to: To: Pekka Savola Cc: Ralph Droms , dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Message-id: <3A56AD0A-4567-11D7-A383-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.551) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Status: No, hits=-4.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On Thursday, February 20, 2003, at 10:25 PM, Pekka Savola wrote: > On Thu, 20 Feb 2003, Alain Durand wrote: >> On Thursday, February 20, 2003, at 12:03 PM, Ralph Droms wrote: >>> If it's unclear, then we should edit the document to explicitly >>> identify the addresses as IPv6 addresses. >>> >>> This option is intended to return IPv6 configuration information. >>> IPv4 addresses for DNS resolvers should be provided through DHCPv4... > > I symphatize with this -- there are some uses to have DHCPv6 return > IPv4 > addresses too -- but the result would just make the dnsconfig option > more > complex for little benefit. Let's face it: if you deploy DHCPv6, you > really should have long since deployed IPv6-enabled nameservers too. > > So, I think clarifying the scope to do only IPv6 seems like the best > option by far. Some may scream at this idea, but couldn't we pass an IPv4-mapped address in there? The DHCPv6 client could recognize this special format to mean this is actually a v4 address? > >> Now, let's say that this is the case for DHCP, what should a node that >> act both as a DHCPv4 and DHCPv6 client do when it will be returned two >> lists of recursive DNS serves, one IPv4 via DHCPv4 and one IPv6 via >> DHCPv6. Which one should take priority? > > Implementation decision, but I guess typically the results of the > latest query take precedence. I don't see a problem here, myself. Unpredictable behavior. Difficult to debug. - Alain. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 21 01:58:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11187 for ; Fri, 21 Feb 2003 01:58:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18m77F-0006wL-00 for namedroppers-data@psg.com; Thu, 20 Feb 2003 22:57:01 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18m77D-0006w9-00 for namedroppers@ops.ietf.org; Thu, 20 Feb 2003 22:56:59 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18m77C-0004v3-00 for namedroppers@ops.ietf.org; Fri, 21 Feb 2003 15:56:58 +0900 In-Reply-To: <3A56AD0A-4567-11D7-A383-00039376A6AA@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Fri, 21 Feb 2003 08:55:13 +0200 (EET) From: Pekka Savola To: Alain Durand cc: Ralph Droms , , , Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt X-Spam-Status: No, hits=-2.2 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RESENT_TO, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] On Thu, 20 Feb 2003, Alain Durand wrote: > On Thursday, February 20, 2003, at 10:25 PM, Pekka Savola wrote: > > > On Thu, 20 Feb 2003, Alain Durand wrote: > >> On Thursday, February 20, 2003, at 12:03 PM, Ralph Droms wrote: > >>> If it's unclear, then we should edit the document to explicitly > >>> identify the addresses as IPv6 addresses. > >>> > >>> This option is intended to return IPv6 configuration information. > >>> IPv4 addresses for DNS resolvers should be provided through DHCPv4... > > > > I symphatize with this -- there are some uses to have DHCPv6 return > > IPv4 > > addresses too -- but the result would just make the dnsconfig option > > more > > complex for little benefit. Let's face it: if you deploy DHCPv6, you > > really should have long since deployed IPv6-enabled nameservers too. > > > > So, I think clarifying the scope to do only IPv6 seems like the best > > option by far. > > Some may scream at this idea, but couldn't we pass an IPv4-mapped address > in there? The DHCPv6 client could recognize this special format > to mean this is actually a v4 address? That is certainly an idea, but I don't like passing around mapped addresses if it can be avoided. Anything which requires special code in DHCPv6 seems like a bad idea. Of course, if the mapped address is pushed in your /etc/resolv.conf and your resolver understands that.... -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 21 02:05:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17936 for ; Fri, 21 Feb 2003 02:05:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18m7Cv-0007PQ-00 for namedroppers-data@psg.com; Thu, 20 Feb 2003 23:02:53 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #1) id 18m7Ct-0007PD-00 for namedroppers@ops.ietf.org; Thu, 20 Feb 2003 23:02:51 -0800 Received: (qmail 41428 invoked by uid 1016); 21 Feb 2003 07:03:17 -0000 Date: 21 Feb 2003 07:03:17 -0000 Message-ID: <20030221070317.41427.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: axfr-clarify breaking RFC 1034 References: <20030220181626.26322.qmail@cr.yp.to> <200302210014.h1L0EH4U009904@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=0.6 required=5.0 tests=REFERENCES,SPAM_PHRASE_03_05 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mark.Andrews@isc.org writes: [ about RFC 1034's database-consistency requirement ] > The only way to meet this all the times and at all levels > of the DNS is to have the all the zones administered on a > single machine *and* to have a multizone transfer protocol. False; and, more importantly, irrelevant. RFC 1034 clearly prohibits your broken configurations. You admit this. It's now obvious to everybody that you're talking about real protocol changes, not ``clarifications.'' You want to change the protocol. Okay. Make an honest proposal in the DNSEXT WG, and we'll discuss it. Don't try to slip it past us as part of an ``AXFR clarification.'' ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 21 02:31:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21979 for ; Fri, 21 Feb 2003 02:31:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18m7Zh-0009Lp-00 for namedroppers-data@psg.com; Thu, 20 Feb 2003 23:26:25 -0800 Received: from [2001:470:1f00:ffff::5a1] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 18m7ZX-0009HV-00 for namedroppers@ops.ietf.org; Thu, 20 Feb 2003 23:26:15 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h1L7Nr4U011442; Fri, 21 Feb 2003 18:23:55 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200302210723.h1L7Nr4U011442@drugs.dv.isc.org> To: Dean Anderson Cc: Mark_Andrews@isc.org, mw-list-namedroppers@csi.hu, Name Droppers , ietf@ietf.org, iesg@ietf.org From: Mark.Andrews@isc.org Subject: Re: Bind 9 AXFR Modification vs AXFR Clarification In-reply-to: Your message of "Fri, 21 Feb 2003 00:25:56 CDT." Date: Fri, 21 Feb 2003 18:23:53 +1100 X-Spam-Status: No, hits=-0.5 required=5.0 tests=BALANCE_FOR_LONG_20K,IN_REP_TO,NO_REAL_NAME, QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > On Fri, 21 Feb 2003 Mark.Andrews@isc.org wrote: > > > > > > On Fri, 21 Feb 2003 Mark.Andrews@isc.org wrote: > > > > > > > > You haven't shown any proof of that. The "proof" you showed, was the > > > > > result of a misconfiguration. > > > > > > > > No. It is the result of operational reality. Whenever you > > > > have a parent and child zones under different administrative > > > > controls it is impossible to change both zones simultaniously. > > > > It is also impossible using AXFR or any other mechanism > > > > which transfers *individual* zones to transfer them to a > > > > secondary and guarantee that they will arrive simultaniously. > > > > > > > > Having parent and child zone under different administrative con > trol > > > > is the norm not the execption. > > > > > > Actually, a parent always has some control over the child. It exercises > > > this control through the glue records. When the glue records are in the > > > child zone, they need to be merged. > > > > Which is it. Does the parent control the contents of its zone > > or does the child? > > You seem not to understand the subtlety of the issue. The parent (like > real parents) ultimately controls the child, but the child (like real > children) has limited autonomy. It is a subtle issue. You can only apply changes to the PRIMARY source of the data. Applying changes at any other point has the potential to cause servers to serve incorrect content. > > > If a zone transfer happens while they > > > are inconsistent, it is possible for some strange results to happen. > > > Ordinarilly, zone transfers don't happen when they are inconsistent, sinc > e > > > the inconsistency is usually short. > > > > It doesn't matter if they normally happen while they are > > consistant. You have to get correct behaviour while they > > are inconsistant. Changing zone content on SECONDARY servers > > is not correct behaviour. > > Sure it is. Unless you can arrange to conduct both updates simultaneosly. > While it would be possible to coordinate such changes on the phone, > relativity could come into play someday. It has nothing to do with zone > transfers. Its part of the state of the system. Zone transfers is only one > way to learn about the state of the system. Changing the content of zones in SECONDARY servers prevents other SECONARY servers using the first SECONDARY server learning the correct state of the system. > > > Any zone transfers made during the inconsistent window are corrected so > > > long as the child zone is updated with correct information after the > > > parent is updated. > > > > This is a incorrect statement. > > Could you elaborate? Server A master to parent. Server B master to child. Server C slave to parent and child. Server D slave to parent using C as master. All servers with NS RRset N of child zone. Server B updates NS RRset to N'. Server A updates NS RRset to N'. Server C transfers parent from A. Server D transfers parent zone from C. Server C transfers child zone from B. End state with modification (BIND 8/tinydns). Server A N', Server B N', Server C N', Server D N. End state without modificatin (BIND 9). Server A N', Server B N', Server C N', Server D N'. You will notice that the last transfer above was the transfer of the child zone. Now lets update the child last. Server A updates NS RRset to N'. Server B updates NS RRset to N'. Server C transfers parent from A. Server D transfers parent zone from C. Server C transfers child zone from B. End state with modification (BIND 8/tinydns). Server A N', Server B N', Server C N', Server D N. End state without modificatin (BIND 9). Server A N', Server B N', Server C N', Server D N'. You will notice that the last transfer above was the transfer of the child zone. Lets wait for the parent zone to propogate to all servers before updating the child zone. Server A updates NS RRset to N'. Server C transfers parent from A. Server D transfers parent zone from C. Server B updates NS RRset to N'. Server C transfers child zone from B. End state with modification (BIND 8/tinydns). Server A N', Server B N', Server C N', Server D N. End state without modificatin (BIND 9). Server A N', Server B N', Server C N', Server D N'. Now if you force everyone to wait until the child zone has progated. Server B updates NS RRset to N'. Server C transfers child zone from B. Server A updates NS RRset to N'. Server C transfers parent from A. Server D transfers parent zone from C. End state with modification (BIND 8/tinydns). Server A N', Server B N', Server C N', Server D N'. End state without modificatin (BIND 9). Server A N', Server B N', Server C N', Server D N'. You will notice that in all examples BIND 9 ends in the correct state. The same cannot be said for BIND 8 or tinydns. Modification of SECONDARY zone content is NOT required or desirable for the correct operation of the DNS. > > > Frequently the parent and child zone are under different administrative > > > control, and are frequently on different servers. In such a case, the > > > contents of the parent zone aren't merged with the child in the child's > > > server, and no evidence of the inconsistency is seen through zone > > > transfers. However, the inconsistency still exists and may still be > > > visible by resolvers and nameservers that lookup the glue records. > > > > Nobody is claiming that inconsistancies don't occur all the > > time. What we are claiming is that those inconsistancies > > need to be preserved in SECONDARY servers for the correct > > operation of the DNS. That they can only be corrected by > > modifying the PRIMARY source of the zones. > > ??? I can't parse this with respect to your previous statements. Could > you rephrase it? You make changes at the PRIMARY server for the zone. You do not make changes to zones anywhere else. > During the period in which the zone is inconsistent, there is no guarantee > the zone will work. Depending on the nature of the change, wrong > information may be given in queries as well. Suppose the parent is > removing control from the child, and has updated the glue to remove > referals to the child nameservers. For some time (the TTL, at least), the > original child servers will be queried. What does this have to do with this draft? > On the other hand, the child zone may not even exist yet on the childs > nameservers. Referals to the zone fail. What does that have to do with this draft? > To make a concrete example, Osama registers alquaeda.com, and begins > coordinating his evil deeds. The registrar delegates the alquaeda.com as a > child of .com. Eventually, the government intervenes, and .com replaces > Osamas nameserver glue with new glue pointing to government servers. For a > time, this zone will be inconsistent. Note that in this case, the zone > transfers will not indicate the inconsistency. However, for a short time, > Osama will be able to put up a message warning his followers not to go to > the government run site. This can't be avoided, no matter what gyrations > you put AXFR through. What has this got to do with this draft? > It makes no difference that the inconsistency _could_, _in_some_cases_, be > seen at the secondaries. It does make a difference as demonstated above. > > > You have obtained no benefits by these constraints. > > > > There are clear benefits in preserving zone contents on > > SECONDARY servers. > > Such as? > > Your term "preserving zone contents" is misleading. The zone contents are > not corrupted. The glue is inconsistent. What is the benefit of > preventing any trace of inconsistency in the secondary? It may be inconsistant but which version is correct? The copy in the child may be out of date. > It has nothing to do with IXFR. It has nothing to do with anything. IXFR still requires the content to only be changed in response to IXFR deltas. > > > It is necessary, since the parent has glue records in the child zone. > > > The parent therefore has (always) a part of the child zone. If that serve > r > > > also loads the child zone (or perhaps generates part of it dynamically), > > > it quite reasonable to merge the records as though the zone includes > > > multiple files, which in theory, it does. > > > > No it isn't. Changes need to come from the PRIMARY source not > > from intermediate sources. > > The intermediate sources aren't making changes. They are, at worst, > propogating old information mixed with new information. However, this is > visible in other ways besides zone transfers. You are changing the contents if you mix data from different zones. > > > The child zone contents will only be correct when the administrators of > > > both zones agree on the contents of the glue records, and update their > > > parts of the child zone accordingly. It will not be correct until then, > > > regardless of how many zone transfers take place. > > > > Which is what I've been saying all along. It doesn't require > > a server to "correct" the content at a intermediate point. Such > > "corrections" actually cause problems. > > Good. Then you agree that Bind 8 behavior is correct. BIND 8 "corrects" data at intermediate points. BIND 9 doesn't. BIND 8's behaviour is wrong. > > > > Nothing in RFC 1033 / 1034 / 1035 says that a server is permitt > ed > > > > to alter the content of a zone. The responability for maintain > ing > > > > consistancy between zones is a administrative function. > > > > > > This is a loaded statement. The part of the server NOT involved in > > > responding to queries and zone transfers is part of the administrative > > > function. So, as part of that administrative function, it has to be able > > > to modify the RR and zones accordingly. Your proposed changes exclude a > > > huge part of the potential for intelligence in name servers. And do so > > > with no benefits. > > > > The benefits are correct operation of the DNS regardless of the > > propogation timings involved. If servers don't modify slave zone > > content then which the master servers are brought into sync all > > the servers will be brought into sync. > > We already have correct operation of DNS. The zone contents are > inconsistent until both adminstrators come to agreement. The child zone > should be updated last. After the child zone is brought into agreement > with the parent glue, zone transfers will be made which are correct. Only > then will zone transfers will be correct. Zone transfers made while the > administrators are not in agreement will not be correct, even if there is > no apparent evidence in the zone data from the child (such as a mixture of > new and old glue) they are still incorrect. NS Queries against the parent > and child servers will return different results. What have you been smoking? > > This is not guarenteed if the zone content is modified by a > > secondary server. > > > > > > > > > Strange, that was my reaction, too. I'm just trying to be polite. > 77 > > > % > > > > > > > work just fine. We don't want to break 77% of the servers out the > re. > > > > > > > > > > > > You really think that it will break those servers? LOL. > > > > > > > > > > They will not be compliant, and thus will need to be changed. Thus, t > hey > > > > > would be broken by definition of not being compliant. > > > > > > > > So. Just because they will not be compliant doesn't mean > > > > that that they need to be replaced immediately. That > > > > non-compliance doesn't hurt most of them. For those where > > > > it does have a negative impact it will mean that they should > > > > be able to request a fix from their vendor. > > > > > > You seem to make a case that in general, non-compliance doesn't hurt > > > anything. This is false, for both technical and commercial reasons. > > > Technically, it hurts interoperability, which has some many obvious harms > > > I won't go into them. Commercially, implementations make and advertise > > > compatibility and standards compliance claims. This retroactively makes > > > those claims false, which harms the business and reputation of those othe > r > > > vendors. > > > > They will be harmed much more if they don't correct a common > > error now that it has been pointed out. > > Except, there are no errors, beyond a window of inconsistency that cannot > be avoided, and in fact, that window isn't fixed. Nor do you fix the > "error". They are _still_ inconsistent for a period. And the child will > _still_ have to be updated last. You obviously don't understand the problem > > The claims were made in good faith and will be accepted as > > such. > > I'm not convinced. If they were, we would have argued this before Bind 9 > was released, and before a book was sent out. Probably about 3 years ago. > Someone knew years ago when they wrote the "backward compatibility" mode, > that they had a protocol issue that would have to come before > namedroppers. That they delayed for so long doesn't indicate good faith > to me. We having been saying for years before BIND 9 was released that that BIND 8 had this wrong. BIND 9 conforms to RFC 1034. Axfr-clarify arose because it was pointed out that IXFR depended upon the definition of AXFR and that AXFR was not well specified. > > > 77% will need a fix from the vendor, if we were to accept these changes. > > > > > > The vendor that made false claims of compatibility and standards > > > compliance is Bind 9. It should suffer the commercial damage to its > > > business and reputation, as a result. > > > > BIND 9 conforms to RFC 1034. Nothing in RFC 1034 says to > > merge zone content. If fact 1034 says that this a administrative > > responsability. > > It does right now, due to a knowingly reckless exploitation of ambiguity > in the AXFR. Once AXFR is clarified, Bind 9 will have to use its 'backward > compatibility' mode to be compliant. What "reckless" exploitation? > It is "knowingly reckless" because the Bind 9 implementers _KNEW_ they > needed to provide a "backward compatibility". That means they knew what > they were doing was incompatible with any (all actually) reasonable > interpretation (however ambiguous) of 1034. The only thing that requires a backward compatability switch is sending multiple records in a message. BIND 4 accepted these back in 1996. Other vendors started accepting these back in 1996. BIND 8 has always accepted them and could be configured to send them. BIND 9 defaults to sending them and can be configured not to. At the same time as this was happening other vendors also started sending them. We all knew that there was interoprability issues that were a result of oversites in the implementation. One vendor even made use of the fact that named (and I presume other servers) didn't barf on a oversized query to signal to it servers that they could send a multi-record respones. > > > > > Your failure to comprehend the consequences of the changes does not l > esse > > > n > > > > > the effect. We now agree that these changes aren't necessary to supp > ort > > > > > IXFR. You were part of the bad engineering that led to the unnecessar > y > > > > > creation of these changes in Bind 9. You were also part of the bad > > > > > decision making that led to the distribution of these changes to Bind > 9 > > > > > users prior to standardization, and quite possibly you were part of t > he > > > > > bad decision making that resulted in publishing a book on the subject > , > > > > > prior to acceptance of your modifications to standards. In short, you > hav > > > e > > > > > shown bad judgement. > > > > > > > > I never said that they we not necessary for IXFR. I said that > > > > that your descripition of how to generate the differences was > > > > irrelevent to this discussion. > > > > > > Ok, you are half way there. They are irrelevant because IXFR is > > > irrelevant. These changes are not necessary to IXFR, as I explained that > > > IXFR can work with the current AXFR, or even without AXFR. > > > > IXFR cannot work through SECONDARY servers that change zone > > content regardless of whether the content was learnt via > > AXFR or IXFR. > > Sure it can. It doesn't need AXFR at all. And the secondary's aren't > making arbitrary changes at all. If servers wern't making arbitary changes we would not be having this discussion. > > > > It was bad engineering to merge the data sets together in the > > > > first place. It was not required by RFC 1033/ 1034 / 1035. > > > > It had negative consequences. It was good engineering to > > > > correct this. It was also good engineering to report a > > > > common error to the community so that other vendors could > > > > fix their mistakes. > > > > > > Actually, since the parent has the glue in the child zone, it has part of > > > the child zone as well as the master zone. Merging them together is not > > > prohibited, and in the case where child and parent have the same > > > adminstrator, as might be the case where most of the child is simply > > > automatically generated by the nameserver, can make things much easier. > > > > > > Your constraints preclude this unnecessarilly. > > > > The constraint in on the SECONDARY server. > > So? It is still unnecesary. Next you will tell me that the grass is blue and the sky is green. If you can't see the need for the constraint stop blocking those that do. > > > Since I can think of cases where it is useful to merge records together, > > > it is bad engineering to remove that flexibility and obtain no benefits i > n > > > return. > > > > > > > > Trying to "belittle" the effects with the "LOL", as opposed to offeri > ng > > > > > anything substantive, simply suggests that you have no appreciation o > f th > > > e > > > > > seriousness of the changes. Perhaps you should take this more seriou > sly. > > > > > > > > I'm quite aware of what the change requires. I'm also aware > > > > that most of the nameserver are used in situations where > > > > the zone contents is already preserved because they are not > > > > serving zones with parent / child relationships. > > > > > > Apparently, you aren't even aware that your changes will make all non-bin > d > > > 9 servers non-compliant. Had you been aware of that, it seems you would > > > have brought this proposal forward something like 3 years ago, before > > > releasing Bind 9, and before publishing a book on the subject. > > > > Well you obviously have not been reading. ISC is not the > > only vendor to come to the same conclusion about preserving > > zone content. I suspect that they are just bored with > > arguing with you and Dan. > > I think they just haven't really read the proposal's, and have taken some > misleading assurances at face value. > > > > > Anyone saying that all the nameservers need to be replaced > > > > immediately is spreading FUD. LOL the the correct reponse > > > > to FUD. > > > > > > Making 77% of the servers non-compliant is a fact of your proposed > > > changes. It is another fact, as explained, that non-compliant servers > > > will need to be replaced. Will they suddenly stop working? It depends on > > > whether other implementations want to implement a "backwards > > > compatibility" mode. If they don't implement this mode, then the answer i > s > > > yes, they will stop working as soon as these updates are deployed by othe > r > > > vendors. Of course, this is a bad result. > > > > Well they havn't stopped working in the last two years that > > this code has been out there. Nothing in this drafts stops > > a server implementing it taking to any other server. > > Uhh, wrong. The drafts make the current AXFR non-compliant. There is > nothing that would require a server to implement the old AXFR and provide > a "backwards compatibility" mode such as Bind 9 has. So you want "Slaves MUST accept messages containing any number of answer RRs. For compatibility with old slaves, masters that support sending multiple answers per message SHOULD be configurable to revert to the historical mode of one answer per message, and the configuration SHOULD be settable on a per-slave basis." replaced with "Slaves MUST accept messages containing any number of answer RRs. For compatibility with old slaves, masters that support sending multiple answers per message MUST be configurable to revert to the historical mode of one answer per message, and the configuration SHOULD be settable on a per-slave basis." > So servers running today, won't be able to talk to strictly compliant > servers that don't have a backwards compatibility mode. > > There is one backwards compatiblity switch which is only > > requires if you decide to send multiple records in a single > > messages. A server is not required to send multiple records > > in a single message. > > But is allowed to, and a server that can't receive such messages won't be > able to get the zone. > > > > > > 1) It doesn't say that it adds a completely new, incompatible zone > > > > > transfer protocol. New protocols should be made through a different > > > > > process, which includes experimentation. I'm not against experimentin > g > > > > > with a new protocol. Indeed, I think this idea has some merit. Howeve > r, i > > > t > > > > > can't be "end-run standardized" by a "clarification". There is a proc > ess. > > > > > > > > It isn't new. All it is saying is that the contents tramitted > > > > out MUST be that transmitted in. This occurs most of the time > > > > already. Note BIND is not the only implementation that does > > > > this. We have already had reports of 3 other implementations > > > > doing this. Even the implementations that don't guarentee the > > > > contents do this most of the time. It has no negative effects. > > > > > > No, Section 3.1 is a whole new derivative of AXFR. That is new. > > > > Actually it's always been allowed by RFC 1034. Just because > > it wasn't implement initially doesn't mean that it was not > > allowed. > > Uhh, wrong, except in an unreasonably broad technical exception due to the > vagueness of 1034. Multiple records in the answer section have always been part of the standard. > > > > > 4) It doesn't say that it changes the definition of zone data to be > > > > > public. Zone data is absolutely not "public by definition". It could > very > > > > > well be useful to tag certain RRs as non-public, and exclude them fro > m > > > > > zone transfers to public servers. This "clarification" precludes that > . > > > > > This is really 2 changes. > > > > > > > > Nowhere in RFC 1033 / 1034 / 1035 does it say that zone transfe > rs > > > > are restricted to secondaries. Nowhere in RFC 1033 / 1034 / 10 > 35 > > > > does it say that you should restrict zone tranfers. > > > > > > I don't think you understood my statement. I'm talking about the > > > definition of zone data. Nowhere does 1034 etc say that zone data is > > > public. It may well have been thought to be public, originally, but sinc > e > > > I can easily see a useful purpose in withholding some private RRs, there > > > isn't any reason to preclude that behavior. > > > > Does this address your concerns? > > No. Because it might be reasonable not to give complete zone data. > > > "The zone transfer protocol allows read-only access to the complete > > zone data. When the data being served to the public it is > > generally acceptable to allow unrestricted access to it via AXFR. > > Sites that wish to avoid disclosing their full zone data MAY > > restrict zone transfer access to authorized slaves." > > > > If you have part of a zone to which you would normally > > return REFUSED to I suggest that you also return REFUSED > > to AXFR. > > > > If you want to be able to return partial zones then I suggest > > that a new TYPE be defined so that receipients can know > > that the results will be incomplete. > > So far as the secondary is concerned, the zone is complete. If you do > this, you don't want to tell people that you have some data that isn't > public. Nor would you ever need to. Well if you don't want to tell them that you have private part then you won't be answering with REFUSED. You effectively have two zones that just have a lot in common. Treat them as such. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 21 02:32:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22001 for ; Fri, 21 Feb 2003 02:32:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18m7dg-0009cg-00 for namedroppers-data@psg.com; Thu, 20 Feb 2003 23:30:32 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #1) id 18m7dd-0009cS-00 for namedroppers@ops.ietf.org; Thu, 20 Feb 2003 23:30:29 -0800 Received: (qmail 48795 invoked by uid 1016); 21 Feb 2003 07:30:55 -0000 Date: 21 Feb 2003 07:30:55 -0000 Message-ID: <20030221073055.48794.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: axfr-clarify's fraudulent claims of consensus References: <20030214103228.71052.qmail@cr.yp.to> <200302101659.LAA15654@ietf.org> <10697.1045222702@munnari.OZ.AU> <20030215033141.82623.qmail@cr.yp.to> <20030220150752.357be0cc.moore@cs.utk.edu> <20030220210623.40638.qmail@cr.yp.to> <3E5551DB.2060808@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-0.8 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Eliot Lear writes: > your implementation And others, notably BIND 8. We're talking about MOST of the Internet's DNS servers here. (See http://cr.yp.to/surveys/dns1.html; I'm assuming that *.com is representative.) This is not a small issue. > could cause interoperability problems by potentially allowing for > different contents of the same zone with the same serial number. No. The _administrator_ can create problems by violating RFC 1034. (Andrews has admitted that his broken configurations violate RFC 1034.) If the administrator follows RFC 1034's consistency requirements, no problems occur. In fact, if the administrator violates RFC 1034 but still follows the easy semi-synchronization rule, no problems occur. Andrews is finally coming out of the closet and arguing that the RFC 1034 rule should be changed (because, with his software, the rule is hard for administrators to follow). But he can't reasonably argue against the semi-synchronization rule. People normally follow that rule anyway; there's no reason to break it; and it guarantees that problems don't occur. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 21 03:32:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22872 for ; Fri, 21 Feb 2003 03:32:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18m8Yp-000CtL-00 for namedroppers-data@psg.com; Fri, 21 Feb 2003 00:29:35 -0800 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by psg.com with esmtp (Exim 3.36 #1) id 18m8Ym-000Ct7-00 for namedroppers@ops.ietf.org; Fri, 21 Feb 2003 00:29:33 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA00422; Fri, 21 Feb 2003 00:29:28 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h1L8TMP07931; Fri, 21 Feb 2003 09:29:23 +0100 (MET) Date: Fri, 21 Feb 2003 09:25:36 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Bind 9 AXFR Modification vs AXFR Clarification To: Dean Anderson Cc: Mark.Andrews@isc.org, mw-list-namedroppers@csi.hu, Name Droppers , ietf@ietf.org, iesg@ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Apparently, you aren't even aware that your changes will make all non-bind > 9 servers non-compliant. Had you been aware of that, it seems you would > have brought this proposal forward something like 3 years ago, before > releasing Bind 9, and before publishing a book on the subject. A data point. http://www.ietf.org/proceedings/00jul/I-D/dnsext-axfr-clarify-00.txt INTERNET-DRAFT Andreas Gustafsson draft-ietf-dnsext-axfr-clarify-00.txt Nominum Inc. March 2000 Seems to be 3 years ago. 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. archive: From owner-namedroppers@ops.ietf.org Fri Feb 21 03:32:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22890 for ; Fri, 21 Feb 2003 03:32:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18m8YH-000CsN-00 for namedroppers-data@psg.com; Fri, 21 Feb 2003 00:29:01 -0800 Received: from [2001:470:1f00:ffff::5a1] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 18m8YE-000Cro-00 for namedroppers@ops.ietf.org; Fri, 21 Feb 2003 00:28:58 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h1L8S64U011586; Fri, 21 Feb 2003 19:28:06 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200302210828.h1L8S64U011586@drugs.dv.isc.org> To: "D. J. Bernstein" Cc: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: Bind 9 AXFR Modification vs AXFR Clarification In-reply-to: Your message of "21 Feb 2003 06:37:25 -0000." <20030221063725.35914.qmail@cr.yp.to> Date: Fri, 21 Feb 2003 19:28:06 +1100 X-Spam-Status: No, hits=0.8 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Mark.Andrews@isc.org writes: > > Whenever you have a parent and child zones under different administrative > > controls it is impossible to change both zones simultaniously. > > False. > > Set the clocks correctly, and schedule the change on all the servers for > a particular time, using (for example) the tinydns timestamp feature > described in http://cr.yp.to/djbdns/tinydns-data.html. When that time > rolls around, all the servers will change their data simultaneously, as > RFC 1034 requires. So now you want to extend the protocol so that each record has an inception time and a expiration time. We could create a new transfer protocol to do this and treat this data as meta data. However you would still have the problem of the meta data being inconsitant. You would still need to ensure that it is transmitted in the right order or that servers didn't modify it while it was being transmitted or that you ban any server but the master server sending copies of the zone. The problems are inherent with having different source maintaining copies of the same data. Mark > Yes, this is difficult to achieve with BIND, AXFR, etc. But it's easy to > achieve with better software, better replication protocols, etc. You're > making a fool of yourself when you call it ``impossible.'' -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 21 03:47:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23333 for ; Fri, 21 Feb 2003 03:47:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18m8mH-000DHB-00 for namedroppers-data@psg.com; Fri, 21 Feb 2003 00:43:29 -0800 Received: from [2001:470:1f00:ffff::5a1] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 18m8mC-000DFq-00 for namedroppers@ops.ietf.org; Fri, 21 Feb 2003 00:43:25 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h1L8gX4U011674; Fri, 21 Feb 2003 19:42:34 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200302210842.h1L8gX4U011674@drugs.dv.isc.org> To: "D. J. Bernstein" Cc: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: axfr-clarify's fraudulent claims of consensus In-reply-to: Your message of "21 Feb 2003 07:30:55 -0000." <20030221073055.48794.qmail@cr.yp.to> Date: Fri, 21 Feb 2003 19:42:33 +1100 X-Spam-Status: No, hits=0.8 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Eliot Lear writes: > > your implementation > > And others, notably BIND 8. We're talking about MOST of the Internet's > DNS servers here. (See http://cr.yp.to/surveys/dns1.html; I'm assuming > that *.com is representative.) This is not a small issue. > > > could cause interoperability problems by potentially allowing for > > different contents of the same zone with the same serial number. > > No. The _administrator_ can create problems by violating RFC 1034. > (Andrews has admitted that his broken configurations violate RFC 1034.) The administrator cannot avoid breaking the rule. All they can do is ensure that the time the rule is broken is minimised. > If the administrator follows RFC 1034's consistency requirements, no > problems occur. In fact, if the administrator violates RFC 1034 but > still follows the easy semi-synchronization rule, no problems occur. You don't live in the real world if you think there won't be errors. The job of computers is to make life easier not more complicated. Having a protocol/implementation that doesn't deal with timing mistakes is a bad. > Andrews is finally coming out of the closet and arguing that the RFC > 1034 rule should be changed (because, with his software, the rule is > hard for administrators to follow). But he can't reasonably argue > against the semi-synchronization rule. People normally follow that rule > anyway; there's no reason to break it; and it guarantees that problems > don't occur. Dan if you want everyone to follow this rule then are you going to modify your software to enforce it. You software doesn't currently comply with this rule. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 21 04:32:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24251 for ; Fri, 21 Feb 2003 04:32:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18m9UH-000ETC-00 for namedroppers-data@psg.com; Fri, 21 Feb 2003 01:28:57 -0800 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #1) id 18m9UF-000ESz-00; Fri, 21 Feb 2003 01:28:55 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA26083; Fri, 21 Feb 2003 02:28:52 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h1L9SjP13266; Fri, 21 Feb 2003 10:28:46 +0100 (MET) Date: Fri, 21 Feb 2003 10:24:55 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: draft-ietf-dnsext-unknown-rrs-04.txt To: Andreas Gustafsson Cc: Erik Nordmark , Andreas Gustafsson , ogud@ogud.com, randy@psg.com, namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" <200302210341.h1L3fpq17126@guava.araneus.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > If I understand you correctly, the reason you are asking for this text > is is to help assess the impact of the unknown-RRs specification on > implementations that currently exist, or that may exist at the time of > publication of unknown-rrs as an RFC. That is a reasonable concern, > but it is a meta-concern; it should be part of the current discussion > about the specification, not part of the specification itself. You at least understand my concern. I don't understand why you don't agree with it. The IETF produces documentation that try to be clear enough so that folks can (with reasonable probability) produce interoperable implementations from the specification. If a specification changes some other specification it makes a lot of sense to make the change clear enough so that an implementor can understand the change. But when I asked you about the change you reviewed the specifications and said that there is no change to existing RRs. I then suggested that the reason you said "change" was because you wanted to change the practise used for defining future RRs. You balked at that proposal - but perhaps it was just a wording detail ... > Of course I don't allow future RR types to specify different DNSSEC > canonicalization rules. All I said was that I do not expect future > definitions of RR types to *explicitly state* that they use the > unknown-rrs canonicalization algorithm, just like existing definitions > of RR types do not explicitly state that they are using the RFC2535 > algorithm. In the absence of an explicit statement, the unknown-RRs > specification will apply, just like RFC2535 applies today. So the 3rd paragraph in section 7 changes the practise for future definitions of RRs? They can not have downcasing of embedded domain names. Then it makes sense to say that and not say "For all other RR types ...". And it is useful to implementors to point out that no RRs that have been defined after RFC 2931 and this RFC contain embedded domain names". (There aren't any RR definitions in the IETF last call, IESG, RFC-editor pipeline right now and if any appear I'll make sure they get this right.) 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. archive: From owner-namedroppers@ops.ietf.org Fri Feb 21 07:36:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27767 for ; Fri, 21 Feb 2003 07:36:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mC8j-000JYA-00 for namedroppers-data@psg.com; Fri, 21 Feb 2003 04:18:53 -0800 Received: from [3ffe:501:100f:0:220:edff:fe2c:2eca] (helo=shuttle.wide.toshiba.co.jp) by psg.com with esmtp (Exim 3.36 #1) id 18mC8h-000JXx-00 for namedroppers@ops.ietf.org; Fri, 21 Feb 2003 04:18:51 -0800 Received: from localhost (unknown [3ffe:501:100f:1048:39e3:8874:aae1:94ec]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 7D6C715210; Fri, 21 Feb 2003 21:18:51 +0900 (JST) Date: Fri, 21 Feb 2003 21:19:00 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Cc: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-Reply-To: <4.3.2.7.2.20030220135524.03e6d548@funnel.cisco.com> References: <4.3.2.7.2.20030220135524.03e6d548@funnel.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 20 X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> On Thu, 20 Feb 2003 13:56:59 -0500, >>>>> Ralph Droms said: > Reminder and note: there have been a few responses to this WG last call, > but no explicit positive recommendations for advancement. Please review > draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt and reply with comments. If you > recommend the document for advancement without revision, please respond > with a quick acknowledgment. No response will be interpreted as a lack of > support for advancing the document. Just as a note: I believe I presented a positive recommendation for advancement. (But it would better to revise the document once to address issues raised during the last call period.) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.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. archive: From owner-namedroppers@ops.ietf.org Fri Feb 21 07:48:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28061 for ; Fri, 21 Feb 2003 07:48:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mCOH-000K6o-00 for namedroppers-data@psg.com; Fri, 21 Feb 2003 04:34:57 -0800 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 18mCOA-000K3b-00 for namedroppers@ops.ietf.org; Fri, 21 Feb 2003 04:34:50 -0800 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1LCY6d12175; Fri, 21 Feb 2003 19:34:08 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1LCY2o23087; Fri, 21 Feb 2003 19:34:02 +0700 (ICT) From: Robert Elz To: "D. J. Bernstein" cc: namedroppers@ops.ietf.org Subject: Re: axfr-clarify breaking RFC 1034 In-Reply-To: <20030221062751.32230.qmail@cr.yp.to> References: <20030221062751.32230.qmail@cr.yp.to> <20030220000752.38144.qmail@cr.yp.to> <200302200225.h1K2Pp4U007052@drugs.dv.isc.org> <20030220034148.14684.qmail@cr.yp.to> <1045794991.1213.168.camel@error-messages.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Feb 2003 19:34:02 +0700 Message-ID: <23085.1045830842@munnari.OZ.AU> X-Spam-Status: No, hits=-0.5 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_02_03 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: 21 Feb 2003 06:27:51 -0000 From: "D. J. Bernstein" Message-ID: <20030221062751.32230.qmail@cr.yp.to> | Presumably you're accustomed to the following zone update procedure for | glue data: | | (1) Change the data in the child zone on the child master. | (2) Change the child serial number. This must be done after #1. | (I mean >=, not >, when I say ``after''; you probably do #1 and | #2 at the same time.) To be correct, it should not be "probably" (as viewed from the outside world anyway). When the data in the zone changes, the serial number must also change (simultaneously). This, of course, doesn't impact upon your argument at all (I am just pointing it out so anyone who reads this doesn't get the impression that they're allowed to make changes to a zone, and then sometime later, update the serial number). | (3) Copy the new data to all the child slaves. | (4) Change the data in the parent zone on the parent master. | (5) Change the parent serial number. This must be done after #4. | (6) Copy the new data to all the parent slaves. | | The definition of a semi-synchronized change is simply that #5 is done | after #3; you don't finish the parent update until all the child servers | have been updated. That's fine, that's how things should work in most cases. | (The definition of a synchronized change is that #1, | #2, #3, #4, #5, #6 happen at the same time.) That's essentially impossible to do in general, though obviously can be done in some special cases. Inventing a new protocol to make it happen could be done - but there is no such thing in the DNS, and the DNS is what we're concerned with here. | Mark's problems can't occur | unless he changes the parent serial number too early. I didn't bother to read Mark's description of the problem, as I know what the problem is, and didn't need to be educated about it. So, it is possible that he didn't describe the issue, or that you didn't understand it - in any case I'm not in a position to say whether or not Mark's particular problems can or can't occur. But problems certainly occur following your "semi-synchronized" model, having the parent update later doesn't help - which should be obvious, as the only fix for the problem that is consistent with your view are your synchronized updates, which require the parent to update sooner (ie: with a delay of 0 after the first possible instant when it can properly update). Any delay larger than 0 opens a window during which problems can occur. Since in the practical universe, rather than some imaginary one, the delay is very often going to be (much) longer than 0 (dealing with ccTLDs it can be months...) we need to find what method causes least problems to deal with the unavoidable discrepancies that do occur. Note that the DNS design assumes that there will be differences - it has timers that limit how out of date data are allowed to become. The RR TTL controls caches, the SOA timers control secondary servers. There's no protocol control over parent zone updates, just the administrative ones. All this is expected (and the users of the DNS are expected to plan their changes to allow for this). The timers can all be adjusted as needed to assist limit the period during which these occur. When operating the way it was designed, the DNS will always fix itself (and yes, the way it was designed includes the parent updating glue to match what is in the child zones). The way that you want the DNS to operate however, it can get into a state where it will not self-heal, it can stay inconsistent forever. That's not how it was designed to work. That it is possible to reach this state under your reading of how things are supposed to work should be regarded as pretty good evidence that your reading is incorrect. Of course, that you're able to read it this way, and other are able to read it differently, is conclusive evidence that clarification is needed. And, of course, when we do that, some readers of the original spec are bound to conclude that what has happened in the "clarification" isn't clarification at all, but change. Others see it as "well, that's what it always said, why do we need this at all?" Both of those groups are mistaken. When we have something that is sometimes read one way, and sometimes read a different way, we don't decide which is correct by counting the number of readers who formed one interpretation, and counting the number who formed a different one - much less do we do so by counting the number of deployed copies of implementations based upon each reading. What we do is look at what the spec should say, to work correctly. | It's fine for other updates to be happening at the same time. In fact, | Mark's problems can't occur for active zones, even if he does screw up | the timing of #5 for one update; the next update wipes out all of the | inconsistencies that he created by screwing up the configuration. Yes, this is correct - assuming that the same problem doesn't occur again. But that's a big assumption, given that the problem is caused by the normal operation of the servers, there's no reason to expect that anything different will happen from one update to the next. If the servers smash zones together on the first update, they're going to do it on every subsequent update. Which actual data is inconsistent may vary from one update to another, but having some inconsistent data, continually, is quite likely. And, of course, you're also assuming that there is a "next update" within some practical time frame. Some zones are updated relatively frequently (daily, or more often), others can go for years without any changes at all. The DNS should correct its inconsistencies without requiring updates that aren't otherwise required. Operating as designed, it does. Operating as you would define it, it doesn't. 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. archive: From owner-namedroppers@ops.ietf.org Fri Feb 21 08:04:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28450 for ; Fri, 21 Feb 2003 08:04:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mCj7-000L14-00 for namedroppers-data@psg.com; Fri, 21 Feb 2003 04:56:29 -0800 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by psg.com with esmtp (Exim 3.36 #1) id 18mCj4-000L0P-00 for namedroppers@ops.ietf.org; Fri, 21 Feb 2003 04:56:26 -0800 Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1LCuKNh003586; Fri, 21 Feb 2003 07:56:21 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-251.cisco.com [161.44.149.251]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA13252; Fri, 21 Feb 2003 07:56:20 -0500 (EST) Message-Id: <4.3.2.7.2.20030221074927.03e89ed8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Feb 2003 07:56:20 -0500 To: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org From: Ralph Droms Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-Reply-To: <3A56AD0A-4567-11D7-A383-00039376A6AA@sun.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-1.7 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01, TO_BE_REMOVED_REPLY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Regarding unpredictable, difficult to debug behavior (see end of quoted text)... Shouldn't the host receive the same answer to a DNS query, regardless of the resolver to which the query is sent? If so, the order in which resolvers are used by the host shouldn't matter. What is done today in the deployed IPv6 world in a host that has both an IPv6 stack and an IPv4 stack, and a manually configured list of DNS resolvers? Is it allowed to mix together IPv6 and IPv4 addresses for resolvers? Is that configuration actually used? Does the host have two lists: one for IPv6 and one for IPv4? Suppose the host only has an IPv6 stack but both IPv6 and IPv4 addresses in its list of DNS resolvers? I'm hoping we can get some real-world deployment experience injected into the conversation... - Ralph At 10:39 PM 2/20/2003 -0800, Alain Durand wrote: >On Thursday, February 20, 2003, at 10:25 PM, Pekka Savola wrote: > >>On Thu, 20 Feb 2003, Alain Durand wrote: >>>On Thursday, February 20, 2003, at 12:03 PM, Ralph Droms wrote: >>>>If it's unclear, then we should edit the document to explicitly >>>>identify the addresses as IPv6 addresses. >>>> >>>>This option is intended to return IPv6 configuration information. >>>>IPv4 addresses for DNS resolvers should be provided through DHCPv4... >> >>I symphatize with this -- there are some uses to have DHCPv6 return IPv4 >>addresses too -- but the result would just make the dnsconfig option more >>complex for little benefit. Let's face it: if you deploy DHCPv6, you >>really should have long since deployed IPv6-enabled nameservers too. >> >>So, I think clarifying the scope to do only IPv6 seems like the best >>option by far. > > >Some may scream at this idea, but couldn't we pass an IPv4-mapped address >in there? The DHCPv6 client could recognize this special format >to mean this is actually a v4 address? > > >> >>>Now, let's say that this is the case for DHCP, what should a node that >>>act both as a DHCPv4 and DHCPv6 client do when it will be returned two >>>lists of recursive DNS serves, one IPv4 via DHCPv4 and one IPv6 via >>>DHCPv6. Which one should take priority? >> >>Implementation decision, but I guess typically the results of the >>latest query take precedence. I don't see a problem here, myself. > >Unpredictable behavior. Difficult to debug. > > - Alain. > > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 21 09:04:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00118 for ; Fri, 21 Feb 2003 09:04:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mDfI-000NKx-00 for namedroppers-data@psg.com; Fri, 21 Feb 2003 05:56:36 -0800 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 18mDfF-000NKk-00 for namedroppers@ops.ietf.org; Fri, 21 Feb 2003 05:56:33 -0800 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1LDuSd14961; Fri, 21 Feb 2003 20:56:28 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1LDuCo24076; Fri, 21 Feb 2003 20:56:12 +0700 (ICT) From: Robert Elz To: Ralph Droms cc: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-Reply-To: <4.3.2.7.2.20030221074927.03e89ed8@funnel.cisco.com> References: <4.3.2.7.2.20030221074927.03e89ed8@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Feb 2003 20:56:12 +0700 Message-ID: <24074.1045835772@munnari.OZ.AU> X-Spam-Status: No, hits=-0.5 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Fri, 21 Feb 2003 07:56:20 -0500 From: Ralph Droms Message-ID: <4.3.2.7.2.20030221074927.03e89ed8@funnel.cisco.com> | Shouldn't the host receive the same answer to a DNS query, regardless of | the resolver to which the query is sent? If so, the order in which | resolvers are used by the host shouldn't matter. It shouldn't matter to the answer (but those who insist on shoving 2faced DNS implementations down everyone's throats can cause problems). It can matter to the workability - often the first resolver listed is the one that should be used, the others are there for backup purposes only, and won't necessarily respond as quickly (they may have smaller cache capacity, slower net links, slower CPU, ...). All this is fine as a backup when the primary resolver happens to be broken, but you wouldn't want to be using it just because you happened to pick the wrong address from a list. | What is done today in the deployed IPv6 world in a host that has both an | IPv6 stack and an IPv4 stack, and a manually configured list of DNS | resolvers? Just about everyone uses IPv4 alone for their resolvers. | Is it allowed to mix together IPv6 and IPv4 addresses for resolvers? Allowed, yes, of course, nothing disallows it. | Is that configuration actually used? Probably not at the minute. | Does the host have two lists: one for IPv6 and one for IPv4? This would make no sense. The host (or application in most cases) has one resolver (stub). When called, all that exists is a domain name, there's no particular v4 or v6 preference. The resolver stub needs to contact its back end resolver to resolve the address, whether v4 or v6 is used for this will depend entirely upon what addresses have been configured for the back end resolver (cache). It certainly isn't influenced by the nature of the query, or by what use is intended for the results of the query. | Suppose the host only has an IPv6 stack but both IPv6 and IPv4 addresses in | its list of DNS resolvers? The v4 address would be useless, just like any other (patently) bogus address that is configured. Ignoring that one would be easy. | I'm hoping we can get some real-world deployment experience injected into | the conversation... Since just about no-one is using v6 in their stub resolvers (just a few who will no doubt now speak up...) this might be difficult. On the issue - I think having just v6 addresses in the DHCPv6 option is fine. How the host actually mixes addresses it gets from DHCPv6 and DHCPv4, and other mechanisms is an interesting problem to which we don't yet have any real answers. This is an area where we probably should just say nothing, and wait to see how implementations actually react. But rather than mixing v6 & v4 addresses in one response (as you imply, v6 addresses are no use to a node with only v4, and v4 addresses no use to a node with only v6) it might be better to explicitly add a "priority of this DNS cache" field along with each address. This allows the implicit "this one is better than that one" based upon ordering to be done away with. What's more, if we were to pick a middling well known priority that would implicitly be applied to addresses in a v4 response it also allows v6 to be placed before, or after, v4 addresses in nodes that support both (or even some before, and some after). It doesn't allow v4 addresses to be ranked other than by their implicit ordering, nor for v6 addresses to be inserted in the middle of the v4 list, but we can't have everything (and I doubt anyone wants to go changing the v4 DNS cache list option now). 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. archive: From owner-namedroppers@ops.ietf.org Fri Feb 21 09:48:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01744 for ; Fri, 21 Feb 2003 09:48:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mEIy-000PFu-00 for namedroppers-data@psg.com; Fri, 21 Feb 2003 06:37:36 -0800 Received: from as7-2-2.bn.g.bonet.se ([217.215.21.151] helo=poledra) by psg.com with esmtp (Exim 3.36 #1) id 18mEIu-000PFe-00 for namedroppers@ops.ietf.org; Fri, 21 Feb 2003 06:37:32 -0800 Received: from amalthea.8in.net ([192.168.242.14] helo=amalthea) by poledra with asmtp (Exim 3.35 #1 (Debian)) id 18mEIr-0000vb-00 for ; Fri, 21 Feb 2003 15:37:29 +0100 Message-ID: <057201c2d9b6$b2154990$0ef2a8c0@amalthea> From: =?iso-8859-1?Q?Kandra_Nyg=E5rds?= To: References: <200302202233.h1KMXO4U009264@drugs.dv.isc.org> <20030221063725.35914.qmail@cr.yp.to> Subject: Re: Bind 9 AXFR Modification vs AXFR Clarification Date: Fri, 21 Feb 2003 15:36:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_OE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit From: "D. J. Bernstein" > > Whenever you have a parent and child zones under different administrative > > controls it is impossible to change both zones simultaniously. > > False. > > Set the clocks correctly, and schedule the change on all the servers for > a particular time, using (for example) the tinydns timestamp feature > described in http://cr.yp.to/djbdns/tinydns-data.html. When that time > rolls around, all the servers will change their data simultaneously, as > RFC 1034 requires. Excellent idea. Unfortunately, this doesn't address the problem with several TLD registries requiring a correctly configured zone prior to making a delegation. In many cases, there are automated checks that prevent you from even requesting a change of delegation unless you have updated your zone. Example: Server A and B are authorative for zone C. Zone C is a child of zone TLD. The administrator for zone C wants to add Server D. The registrar for TLD requires that Zone C is configured according to the new data before approving a change. Alternative A: The administrator for zone C won't violate RFC1034 and is therefore unable to change his zone data unless TLD is also updated at the same time, which the TLD doesn't allow. Alternative B: The administrator for zone C changes the data in zone C, thereby temporarily violating RFC1034. The delegation robot for TLD verifies the data and accepts the delegation, therefore ensuring that RFC1034 consistency is maintained. I'm sure that most administrators would pick alternative B in this case. If you're still maintaining that RFC1034 violations are unacceptable, you might want to update the following pages: http://cr.yp.to/djbdns/dot-fr.html http://cr.yp.to/djbdns/dot-it.html http://cr.yp.to/djbdns/dot-nl.html http://cr.yp.to/djbdns/dot-no.html http://cr.yp.to/djbdns/dot-ru.html http://cr.yp.to/djbdns/dot-arpa.html All of these registries require that administrators knowingly change the data in their child zones before the parent zone is updated, in fact they all use automated checks to ensure that the data is in fact correct. This short-term intentional violation of RFC1034 is to ensure that parent and child gluedata is consistent in the long run. As I said, we don't live in a perfect world. If your software can't cope with that, there's an implementation bug. Best regards, Kandra Nygards -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 21 10:04:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02511 for ; Fri, 21 Feb 2003 10:04:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mEdO-0000E4-00 for namedroppers-data@psg.com; Fri, 21 Feb 2003 06:58:42 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 18mEdM-0000Ds-00 for namedroppers@ops.ietf.org; Fri, 21 Feb 2003 06:58:40 -0800 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id AE375137F06; Fri, 21 Feb 2003 06:58:38 -0800 (PST) Date: Fri, 21 Feb 2003 06:58:42 -0800 Subject: Re: Bind 9 AXFR Modification vs AXFR Clarification Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Dean Anderson , Mark_Andrews@isc.org, mw-list-namedroppers@csi.hu, Name Droppers , ietf@ietf.org, iesg@ietf.org To: Erik Nordmark From: David Conrad In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-4.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I remember when people thought OSI protocols took too long to standardize... :-) Rgds, -drc On Friday, February 21, 2003, at 12:25 AM, Erik Nordmark wrote: >> Apparently, you aren't even aware that your changes will make all >> non-bind >> 9 servers non-compliant. Had you been aware of that, it seems you >> would >> have brought this proposal forward something like 3 years ago, before >> releasing Bind 9, and before publishing a book on the subject. > > A data point. > > http://www.ietf.org/proceedings/00jul/I-D/dnsext-axfr-clarify-00.txt > INTERNET-DRAFT Andreas Gustafsson > draft-ietf-dnsext-axfr-clarify-00.txt Nominum Inc. > March 2000 > Seems to be 3 years ago. > > Erik > > > _______________________________________________ > This message was passed through ietf_censored@carmen.ipv6.cselt.it, > which is a sublist of ietf@ietf.org. Not all messages are passed. > Decisions on what to pass are made solely by Raffaele D'Albenzio. > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 21 12:39:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08256 for ; Fri, 21 Feb 2003 12:39:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mH1I-0008EJ-00 for namedroppers-data@psg.com; Fri, 21 Feb 2003 09:31:32 -0800 Received: from gold.nb.net ([209.161.64.73] helo=mx2.nb.net) by psg.com with smtp (Exim 3.36 #1) id 18mH1D-0008Dz-00 for namedroppers@ops.ietf.org; Fri, 21 Feb 2003 09:31:27 -0800 Received: (qmail 24022 invoked from network); 21 Feb 2003 17:31:25 -0000 Received: from titanium.nb.net (209.161.64.27) by gold.nb.net with SMTP; 21 Feb 2003 17:31:25 -0000 Date: Fri, 21 Feb 2003 12:31:25 -0500 (EST) From: Len Budney X-Sender: lbudney@titanium.nb.net To: namedroppers@ops.ietf.org Subject: Re: axfr-clarify's fraudulent claims of consensus In-Reply-To: <200302210842.h1L8gX4U011674@drugs.dv.isc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03, USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 21 Feb 2003 Mark.Andrews@isc.org wrote: > Dan Bernstein wrote: >> >> If the administrator follows RFC 1034's consistency requirements, no >> problems occur... > > You don't live in the real world if you think there won't be errors. > The job of computers is to make life easier not more complicated. Agreed! The way to make life easier is to make the software enforce the rules, so that the admins don't have to worry about it. Granted, the rules themselves can be wrong--but in that case, you change the rules and then start enforcing them. >> Andrews...can't reasonably argue against the semi-synchronization >> rule. People normally follow that rule anyway; there's no reason to >> break it; and it guarantees that problems don't occur. > > Dan if you want everyone to follow this rule then are you going to > modify your software to enforce it. You software doesn't currently > comply with this rule. You might want to read more carefully: Dan's definition of "semi-synchronization" was (purposely) designed to include synchronization as a special case. --Len. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 21 12:58:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09161 for ; Fri, 21 Feb 2003 12:58:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mHIh-0009Je-00 for namedroppers-data@psg.com; Fri, 21 Feb 2003 09:49:31 -0800 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 18mHIY-0009HM-00 for namedroppers@ops.ietf.org; Fri, 21 Feb 2003 09:49:22 -0800 Received: from nominum.com (a21.pm3-67.theriver.com [206.25.48.213]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1LHk3N26412; Fri, 21 Feb 2003 11:46:03 -0600 (CST) Date: Fri, 21 Feb 2003 10:48:44 -0700 Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Ralph Droms , dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org To: Robert Elz From: Ted Lemon In-Reply-To: <24074.1045835772@munnari.OZ.AU> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I'm not sure why you would have a deployed DHCPv6 server and not deploy a DNS resolver that listens to requests on an IPv6 socket. Can anybody give a rationale for this? Has anybody done this? Was it a problem? In principle, there is nothing that would prevent you from configuring your DHCPv6 server to return an encapsulated IPv4 address, but as various people have said, this might produce a not-useful result. I think that the idea of having a DNS resolver priority list is a reasonable answer to the problem of "what do we do if we have both IPv4 and IPv6 addresses for resolvers," but I also think that it's a complicated answer, and I do not believe that the problem it solves is a compelling one. It adds significant special-case code to the DHCP client, and I don't think it produces a useful benefit. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 21 14:07:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11445 for ; Fri, 21 Feb 2003 14:07:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mIO3-000Djv-00 for namedroppers-data@psg.com; Fri, 21 Feb 2003 10:59:07 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #1) id 18mINx-000DjZ-00 for namedroppers@ops.ietf.org; Fri, 21 Feb 2003 10:59:01 -0800 Received: (qmail 89050 invoked by uid 1016); 21 Feb 2003 18:59:25 -0000 Date: 21 Feb 2003 18:59:25 -0000 Message-ID: <20030221185925.89049.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: axfr-clarify breaking RFC 1034 References: <20030221062751.32230.qmail@cr.yp.to> <20030220000752.38144.qmail@cr.yp.to> <200302200225.h1K2Pp4U007052@drugs.dv.isc.org> <20030220034148.14684.qmail@cr.yp.to> <1045794991.1213.168.camel@error-messages.mit.edu> <23085.1045830842@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-0.2 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_03_05 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Robert Elz writes: > the serial number must also change (simultaneously) That's certainly part of the RFC 1034 requirement. But Andrews is complaining that the RFC 1034 requirement is too hard to follow. (For example, you're violating this part if you change your data but forget to update the serial number until later.) I'm pointing out the minimum set of timing constraints that guarantee consistent data at the end. From this perspective, it's fine for the serial number to be updated as a separate step. > The way that you want the DNS to operate however, it can get into a > state where it will not self-heal, it can stay inconsistent forever. False. After step #6 of a semi-synchronized update, all the servers have the updated data---whether the servers are running BIND 4, BIND 8, BIND 9, or djbdns. All of Andrews's problems occur because he's updating the parent serial number too early. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 21 14:20:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11878 for ; Fri, 21 Feb 2003 14:20:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mIbd-000EWr-00 for namedroppers-data@psg.com; Fri, 21 Feb 2003 11:13:09 -0800 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #1) id 18mIbY-000EWf-00 for namedroppers@ops.ietf.org; Fri, 21 Feb 2003 11:13:05 -0800 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id OAA29747; Fri, 21 Feb 2003 14:05:28 -0500 Date: Fri, 21 Feb 2003 14:06:41 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: "D. J. Bernstein" cc: ietf@ietf.org, , Subject: Re: Bind 9 AXFR Modification vs AXFR Clarification In-Reply-To: <20030221063725.35914.qmail@cr.yp.to> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,SPAM_PHRASE_00_01,USER_AGENT_PINE, X_OSIRU_SPAM_SRC version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On 21 Feb 2003, D. J. Bernstein wrote: > Mark.Andrews@isc.org writes: > > Whenever you have a parent and child zones under different administrative > > controls it is impossible to change both zones simultaniously. > > False. > > Set the clocks correctly, and schedule the change on all the servers for > a particular time, using (for example) the tinydns timestamp feature > described in http://cr.yp.to/djbdns/tinydns-data.html. When that time > rolls around, all the servers will change their data simultaneously, as > RFC 1034 requires. Clever. > Yes, this is difficult to achieve with BIND, AXFR, etc. But it's easy to > achieve with better software, better replication protocols, etc. You're > making a fool of yourself when you call it ``impossible.'' This could be done with a slight change to AXFR. Lets include it in the MAXFR proposal (the axfr mods, taken out of the "clarification". -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 21 14:22:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11946 for ; Fri, 21 Feb 2003 14:22:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mIcb-000Eb4-00 for namedroppers-data@psg.com; Fri, 21 Feb 2003 11:14:09 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #1) id 18mIcX-000Eah-00 for namedroppers@ops.ietf.org; Fri, 21 Feb 2003 11:14:05 -0800 Received: (qmail 97799 invoked by uid 1016); 21 Feb 2003 19:14:30 -0000 Date: 21 Feb 2003 19:14:30 -0000 Message-ID: <20030221191430.97798.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: Bind 9 AXFR Modification vs AXFR Clarification References: <200302202233.h1KMXO4U009264@drugs.dv.isc.org> <20030221063725.35914.qmail@cr.yp.to> <057201c2d9b6$b2154990$0ef2a8c0@amalthea> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > As I said, we don't live in a perfect world. If your software can't cope > with that, there's an implementation bug. Where do you get the idea that my software (or most deployed versions of BIND) has any trouble here? Andrews is creating problems for himself by updating the parent serial number too _early_. You're talking about parents that insist on making the parent changes _late_. Early and late both violate RFC 1034, but late doesn't cause problems. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 21 14:33:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12361 for ; Fri, 21 Feb 2003 14:33:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mIlS-000FGp-00 for namedroppers-data@psg.com; Fri, 21 Feb 2003 11:23:18 -0800 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #1) id 18mIlL-000FGb-00 for namedroppers@ops.ietf.org; Fri, 21 Feb 2003 11:23:11 -0800 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id OAA17122; Fri, 21 Feb 2003 14:19:35 -0500 Date: Fri, 21 Feb 2003 14:20:57 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Erik Nordmark cc: Mark.Andrews@isc.org, , Name Droppers , , Subject: Re: Bind 9 AXFR Modification vs AXFR Clarification In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,SPAM_PHRASE_00_01,USER_AGENT_PINE, X_OSIRU_SPAM_SRC version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Interesting. So, they knew that standardization was necessary, the proposed a standard, the standard wasn't accepted, so they distributed code to users anyway, and wrote a book anyway. I find that even more worthy of criticism. Did they think they would force this through later? Never mind, it doesn't matter what they thought. As this "clarify" seems to have been dead for years, we should get on with the business of clarifying AXFR as it was commonly interpreted. And lets get on with the MAXFR proposal. --Dean On Fri, 21 Feb 2003, Erik Nordmark wrote: > > Apparently, you aren't even aware that your changes will make all non-bind > > 9 servers non-compliant. Had you been aware of that, it seems you would > > have brought this proposal forward something like 3 years ago, before > > releasing Bind 9, and before publishing a book on the subject. > > A data point. > > http://www.ietf.org/proceedings/00jul/I-D/dnsext-axfr-clarify-00.txt > INTERNET-DRAFT Andreas Gustafsson > draft-ietf-dnsext-axfr-clarify-00.txt Nominum Inc. > March 2000 > Seems to be 3 years ago. > > 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. archive: From owner-namedroppers@ops.ietf.org Fri Feb 21 15:16:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13371 for ; Fri, 21 Feb 2003 15:16:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mJWd-000Igm-00 for namedroppers-data@psg.com; Fri, 21 Feb 2003 12:12:03 -0800 Received: from as7-2-2.bn.g.bonet.se ([217.215.21.151] helo=poledra) by psg.com with esmtp (Exim 3.36 #1) id 18mJWa-000IgW-00 for namedroppers@ops.ietf.org; Fri, 21 Feb 2003 12:12:00 -0800 Received: from amalthea.8in.net ([192.168.242.14] helo=amalthea) by poledra with asmtp (Exim 3.35 #1 (Debian)) id 18mJWY-0004UI-00 for ; Fri, 21 Feb 2003 21:11:58 +0100 Message-ID: <060001c2d9e5$6be0fbc0$0ef2a8c0@amalthea> From: =?iso-8859-1?Q?Kandra_Nyg=E5rds?= To: References: <200302202233.h1KMXO4U009264@drugs.dv.isc.org> <20030221063725.35914.qmail@cr.yp.to> <057201c2d9b6$b2154990$0ef2a8c0@amalthea> <20030221191430.97798.qmail@cr.yp.to> Subject: Re: Bind 9 AXFR Modification vs AXFR Clarification Date: Fri, 21 Feb 2003 21:11:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=-0.6 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02, USER_AGENT_OE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit From: "D. J. Bernstein" > > As I said, we don't live in a perfect world. If your software can't cope > > with that, there's an implementation bug. > > Where do you get the idea that my software (or most deployed versions of > BIND) has any trouble here? You have been consistently claiming that your software enforces strict RFC1034 compliance and therefore compromizes data integrity. > Andrews is creating problems for himself by updating the parent serial > number too _early_. You're talking about parents that insist on making > the parent changes _late_. Early and late both violate RFC 1034, but > late doesn't cause problems. Both "early" and "late" exist in the real world. Regardless of if it's an administrative error or an intentional change, there's no excuse for any software to allow timing issues to affect data integrity. - Kandra -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 21 15:18:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13452 for ; Fri, 21 Feb 2003 15:18:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mJZA-000InA-00 for namedroppers-data@psg.com; Fri, 21 Feb 2003 12:14:40 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #1) id 18mJZ7-000Imt-00 for namedroppers@ops.ietf.org; Fri, 21 Feb 2003 12:14:37 -0800 Received: from esunmail ([129.147.58.120]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17831 for ; Fri, 21 Feb 2003 13:14:34 -0700 (MST) Received: from xpa-fe2 ([129.147.58.198]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTP id <0HAO005BRDK9EK@edgemail1.Central.Sun.COM> for namedroppers@ops.ietf.org; Fri, 21 Feb 2003 13:14:34 -0700 (MST) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTPSA id <0HAO00K1ADK8UH@mail.sun.net> for namedroppers@ops.ietf.org; Fri, 21 Feb 2003 13:14:33 -0700 (MST) Date: Fri, 21 Feb 2003 12:15:41 -0800 From: Alain Durand Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-reply-to: <4.3.2.7.2.20030221074927.03e89ed8@funnel.cisco.com> To: Ralph Droms Cc: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Message-id: <3FCBEDD2-45D9-11D7-9278-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.551) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Status: No, hits=-4.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On Friday, February 21, 2003, at 04:56 AM, Ralph Droms wrote: > Regarding unpredictable, difficult to debug behavior (see end of > quoted text)... > > Shouldn't the host receive the same answer to a DNS query, regardless > of the resolver to which the query is sent? If so, the order in which > resolvers are used by the host shouldn't matter. There might be performance/security issues. > > What is done today in the deployed IPv6 world in a host that has both > an IPv6 stack and an IPv4 stack, and a manually configured list of DNS > resolvers? Is it allowed to mix together IPv6 and IPv4 addresses for > resolvers? Yes, in /etc/resolv.conf > Is that configuration actually used? Yes > Does the host have two lists: one for IPv6 and one for IPv4? No, one list which include either v4 or v6 addreses > > Suppose the host only has an IPv6 stack but both IPv6 and IPv4 > addresses in its list of DNS resolvers? then obviously it should ignore the v4 one, the same way a v4-only host should ignore AAAA records. > I'm hoping we can get some real-world deployment experience injected > into the conversation... > > - Ralph -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 21 15:59:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14687 for ; Fri, 21 Feb 2003 15:59:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mK9f-000LXO-00 for namedroppers-data@psg.com; Fri, 21 Feb 2003 12:52:23 -0800 Received: from gold.nb.net ([209.161.64.73] helo=mx2.nb.net) by psg.com with smtp (Exim 3.36 #1) id 18mK9b-000LWt-00 for namedroppers@ops.ietf.org; Fri, 21 Feb 2003 12:52:19 -0800 Received: (qmail 19144 invoked from network); 21 Feb 2003 20:52:18 -0000 Received: from titanium.nb.net (209.161.64.27) by gold.nb.net with SMTP; 21 Feb 2003 20:52:18 -0000 Date: Fri, 21 Feb 2003 15:52:18 -0500 (EST) From: Len Budney X-Sender: lbudney@titanium.nb.net To: namedroppers@ops.ietf.org Subject: Re: Bind 9 AXFR Modification vs AXFR Clarification In-Reply-To: <060001c2d9e5$6be0fbc0$0ef2a8c0@amalthea> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN X-Spam-Status: No, hits=-1.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id PAA14687 On Fri, 21 Feb 2003, [iso-8859-1] Kandra Nygĺrds wrote: > > Both "early" and "late" exist in the real world. Regardless of if it's > an administrative error or an intentional change, there's no excuse > for any software to allow timing issues to affect data integrity. Yes--early and late both exist. But errors are not symmetrical! If the task is to "open the door and walk through", then opening the door "early" doesn't hurt, but opening the door "late" really hurts a lot. Dan has proposed allowing "late" but not "early". That's easy to do: just do one thing before attempting to do the other. Your implied claim that it's impossible to guarantee a time ordering is ridiculous. --Len. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 21 16:36:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15699 for ; Fri, 21 Feb 2003 16:36:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mKmZ-000OV7-00 for namedroppers-data@psg.com; Fri, 21 Feb 2003 13:32:35 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #1) id 18mKmW-000OUv-00 for namedroppers@ops.ietf.org; Fri, 21 Feb 2003 13:32:32 -0800 Received: (qmail 61543 invoked by uid 1016); 21 Feb 2003 21:32:57 -0000 Date: 21 Feb 2003 21:32:57 -0000 Message-ID: <20030221213257.61542.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: update timing References: <200302202233.h1KMXO4U009264@drugs.dv.isc.org> <20030221063725.35914.qmail@cr.yp.to> <057201c2d9b6$b2154990$0ef2a8c0@amalthea> <20030221191430.97798.qmail@cr.yp.to> <060001c2d9e5$6be0fbc0$0ef2a8c0@amalthea> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Regardless of if it's an administrative error or an intentional > change, there's no excuse for any software to allow timing issues to > affect data integrity. Suppose the administrator changes the serial number and _then_ changes the other data. This timing screwup destroys data integrity with BIND 9. According to your mindless rhetoric, this is an inexcusable BIND 9 flaw. Can we please drop the religious nonsense now? In the real world, when the administrator screws up the timing, we blame the administrator. Good software can prevent many problems---as tinydns does with automatic serial numbers, for example---but all remaining problems are the direct result of an administrator's misconfiguration. Andrews says that the RFC 1034 rules are too hard for administrators to follow. He wants to loosen them. I'm pointing out exactly which timing rules are necessary to guarantee a successful update. You are claiming that we don't need _any_ rules; that's ludicrous. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 21 17:45:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17591 for ; Fri, 21 Feb 2003 17:45:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mLnP-00037y-00 for namedroppers-data@psg.com; Fri, 21 Feb 2003 14:37:31 -0800 Received: from gusto.araneus.fi ([204.152.186.164]) by psg.com with esmtp (Exim 3.36 #1) id 18mLmt-000357-00; Fri, 21 Feb 2003 14:36:59 -0800 Received: from guava.araneus.fi (adsl-63-197-0-204.dsl.snfc21.pacbell.net [63.197.0.204]) by gusto.araneus.fi (8.11.6/8.11.6) with ESMTP id h1LMZZZ11888; Fri, 21 Feb 2003 14:35:35 -0800 (PST) Received: (from gson@localhost) by guava.araneus.fi (8.11.6/8.11.6) id h1LMZXi18563; Fri, 21 Feb 2003 14:35:33 -0800 (PST) Date: Fri, 21 Feb 2003 14:35:33 -0800 (PST) Message-Id: <200302212235.h1LMZXi18563@guava.araneus.fi> To: Erik Nordmark Cc: Andreas Gustafsson , ogud@ogud.com, randy@psg.com, namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-unknown-rrs-04.txt In-Reply-To: References: <200302210341.h1L3fpq17126@guava.araneus.fi> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=0.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Erik Nordmark writes: > > If I understand you correctly, the reason you are asking for this text > > is is to help assess the impact of the unknown-RRs specification on > > implementations that currently exist, or that may exist at the time of > > publication of unknown-rrs as an RFC. That is a reasonable concern, > > but it is a meta-concern; it should be part of the current discussion > > about the specification, not part of the specification itself. > > You at least understand my concern. > > I don't understand why you don't agree with it. > The IETF produces documentation that try to be clear enough so that folks > can (with reasonable probability) produce interoperable implementations > from the specification. > If a specification changes some other specification it makes a lot of > sense to make the change clear enough so that an implementor can > understand the change. Of course, but I think the changes you suggested would make the specification less clear, not clearer. > But when I asked you about the change you reviewed the specifications > and said that there is no change to existing RRs. > I then suggested that the reason you said "change" was because you wanted > to change the practise used for defining future RRs. > You balked at that proposal - but perhaps it was just a wording detail ... The intent of the draft is that the new canonicalization algorithm will apply to all future RR types. I don't think there is any disagreement about that. The disagreement seems to be about two other issues: 1. The use of temporal terms such as "current", "future", or "existing" in the text of the specification. That would only cause confusion since an RR type which we today consider a "future" type is likely to be an "existing" type when an implementor reads the RFC some time in the future. An explicit listing of the RRs that use the old algorithm and a statement that all others use the new algorithm is unambiguous, whereas a reference to "future types" is not. 2. When you say the draft wants to "change the practice used for defining future RRs", you seem to be assuming that the DNSSEC canonicalization algorithm to be used for any given RR type is part of the RR type definition itself. That has not traditionally been the case - no existing RR type definition contains any mention of downcasing or other aspects DNSSEC canonicalization, and there is no reason for future ones to contain such specific mention, either. The erefore, section 7 does not change the "practice of defining new RRs"; it only changes a part of the DNSSEC specification. Furthermore, saying that the draft "changes the practice used for defining future RRs" could be incorrectly interpreted as meaning the new canonicalization algorithm only begins to apply to a new RR type once it gets defined, when in fact it will apply even *before* it is defined, when it is still only an unallocated RR type number being treated transparently by implementations. Keep in mind that the reason why this change is being made in the first place is to ensure that new RR types are canonicalized identically by all implementations even if they are treated as known types by some implementations and as unknown types by others. > And it is useful to implementors to point out that no RRs that have > been defined after RFC 2931 and this RFC contain embedded domain names". > (There aren't any RR definitions in the IETF last call, IESG, RFC-editor > pipeline right now and if any appear I'll make sure they get this right.) Did you mean "after RFC2931 but before this RFC"? If you can guarantee that no new RR types with embedded domain names are published as RFCs before the publication of unknown-RRs as an RFC, then I have no problem with including a statement to that effect. Regarding the possibility of publishing new RR types with embedded domain names before unknown-RRs and making sure they "get it right", that's much more problematic. It would mean that these new RR type definitions would not only have to explicitly mention DNSSEC canonicalization (unlike previous RR type definitions), but they would also have to contain a copy of the text from section 7 defining the new canonicalization algorithm, and they would have to update RFC2535. Also, I'm not sure what the text you want added to the unknown-RRs RFC would say in that case - clearly it could not say "no RR types defined at the time of the publication of this RFC use the new canonicalization rules" nor "no RR types defined between RFC2931 and this RFC have embedded domain names", since neither statement would be true. -- 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. archive: From owner-namedroppers@ops.ietf.org Fri Feb 21 18:22:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18072 for ; Fri, 21 Feb 2003 18:22:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mMPu-0005Ng-00 for namedroppers-data@psg.com; Fri, 21 Feb 2003 15:17:18 -0800 Received: from thales.memphis.edu ([141.225.37.221]) by psg.com with smtp (Exim 3.36 #1) id 18mMPO-0005NI-00 for namedroppers@ops.ietf.org; Fri, 21 Feb 2003 15:16:46 -0800 Received: (qmail 26912 invoked by uid 500); 21 Feb 2003 23:16:38 -0000 From: mw-list-namedroppers@csi.hu Date: Fri, 21 Feb 2003 17:16:38 -0600 To: Name Droppers Subject: Re: axfr-clarify breaking RFC 1034 Message-ID: <20030221231638.GA26168@thales.memphis.edu> References: <20030221062751.32230.qmail@cr.yp.to> <20030220000752.38144.qmail@cr.yp.to> <200302200225.h1K2Pp4U007052@drugs.dv.isc.org> <20030220034148.14684.qmail@cr.yp.to> <1045794991.1213.168.camel@error-messages.mit.edu> <23085.1045830842@munnari.OZ.AU> <20030221185925.89049.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030221185925.89049.qmail@cr.yp.to> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-0.9 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, Feb 21, 2003 at 06:59:25PM -0000, D. J. Bernstein wrote: > All of Andrews's problems occur because he's updating > the parent serial number too early. > This is hard to watch: people cannot believe it is possible to have perfect synchronization, you keep asserting it is possible. I think if you tell tell them how djbdns does it, the pingpong will be over. Some might even install djbdns just to see for themselves. Mate -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 21 18:41:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18488 for ; Fri, 21 Feb 2003 18:41:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mMkS-0006F7-00 for namedroppers-data@psg.com; Fri, 21 Feb 2003 15:38:32 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18mMkA-0006Dv-00 for namedroppers@ops.ietf.org; Fri, 21 Feb 2003 15:38:14 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18mMV1-0009mJ-00 for namedroppers@ops.ietf.org; Sat, 22 Feb 2003 08:22:36 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: Subject: RE: [dhcwg] Re: WG last call ondraft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Date: Fri, 21 Feb 2003 14:20:45 +0100 From: "BELOEIL Luc FTRD/DMI/CAE" To: "Pekka Savola" Cc: "Alain Durand" , "Ralph Droms" , , , X-Spam-Status: No, hits=-0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,RESENT_TO,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] > De : Pekka Savola [mailto:pekkas@netcore.fi] >=20 >=20 > On Fri, 21 Feb 2003, BELOEIL Luc FTRD/DMI/CAE wrote: > > > > Implementation decision, but I guess typically the=20 > results of the > > > > latest query take precedence. I don't see a problem=20 > here, myself. > > >=20 > > > Unpredictable behavior. Difficult to debug. > > >=20 > > > - Alain. > >=20 > > Good remark! I understand the point/issue if IPv6 provider=20 > is not the > > same as IPv4 one. By that way the node may not have the same global > > vision of the Domain Name System!=20 >=20 > I'm having a difficulty seeing the point. A similar=20 > situation happens if=20 > the user has manually configured a few nameservers in=20 > /etc/resolv.conf and=20 > then runs either DHCPv4 / DHCPv6. >=20 Yes > Is it IETF's business to specify whether or not (and if so, how) the > entries should be overwritten, prepended/appended, etc. ?=20 I'm really not sure.=20 > Is this done > now with DHCPv4? >=20 No idea. > I'm not so sure, but something like "DNS servers configured=20 > through this > option should take precedence if some existed beforehand" would be > acceptable to me Note *no* RFC2119 upper-case keywords. >=20 IMO, the "split vision of DNS" remark is useful for service architectures but may not be taken into account in some protocol specifications. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 21 18:59:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18979 for ; Fri, 21 Feb 2003 18:59:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mMzd-000752-00 for namedroppers-data@psg.com; Fri, 21 Feb 2003 15:54:13 -0800 Received: from [2001:4f8:3:bb:2e0:81ff:fe23:7b5a] (helo=as.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 18mMzb-00074e-00 for namedroppers@ops.ietf.org; Fri, 21 Feb 2003 15:54:11 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 59230379FBB for ; Fri, 21 Feb 2003 23:53:58 +0000 (GMT) From: Paul Vixie To: Name Droppers Subject: Re: axfr-clarify breaking RFC 1034 In-Reply-To: Message from mw-list-namedroppers@csi.hu of "Fri, 21 Feb 2003 17:16:38 CST." <20030221231638.GA26168@thales.memphis.edu> X-Mailer: MH-E 7.2; nmh 1.0.4; GNU Emacs 21.2.1 Date: Fri, 21 Feb 2003 23:53:58 +0000 Message-Id: <20030221235358.59230379FBB@as.vix.com> X-Spam-Status: No, hits=-0.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, TO_BE_REMOVED_REPLY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk why would that matter? the dns protocol does not have perfect synchronization. microsoft goes out of band ("active directory") to try to create the illusion of "multiple masters" which is their marketing equivilent of perfect synchronization. dbjdns appears to go out of band ("rsync") for the same reason and with similar results. instead of talking about out of band methods used by implementations, let's talk about the dns protocol (this being "namedroppers"). like for example, let's clarify exactly what a zone is and how the dns protocol goes about transfering it ("axfr"). re: > X-Original-To: vixie@vix.com > From: mw-list-namedroppers@csi.hu > Date: Fri, 21 Feb 2003 17:16:38 -0600 > To: Name Droppers > Subject: Re: axfr-clarify breaking RFC 1034 > Sender: owner-namedroppers@ops.ietf.org > > On Fri, Feb 21, 2003 at 06:59:25PM -0000, D. J. Bernstein wrote: > > All of Andrews's problems occur because he's updating > > the parent serial number too early. > > > > This is hard to watch: people cannot believe it is possible to have > perfect synchronization, you keep asserting it is possible. I think if > you tell tell them how djbdns does it, the pingpong will be over. > Some might even install djbdns just to see for themselves. > > Mate > > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 21 19:03:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19052 for ; Fri, 21 Feb 2003 19:03:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mN4Z-0007JV-00 for namedroppers-data@psg.com; Fri, 21 Feb 2003 15:59:19 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18mN4W-0007JH-00 for namedroppers@ops.ietf.org; Fri, 21 Feb 2003 15:59:17 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18mN4V-000Flt-00 for namedroppers@ops.ietf.org; Sat, 22 Feb 2003 08:59:16 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-reply-to: "21 Feb 2003 06:37:25 GMT." <20030221063725.35914.qmail@cr.yp.to> Message-id: <200302211731.h1LHVmG29919@gungnir.fnal.gov> Date: Fri, 21 Feb 2003 11:31:48 -0600 From: Matt Crawford Subject: Re: Bind 9 AXFR Modification vs AXFR Clarification To: "D. J. Bernstein" Cc: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org X-Spam-Status: No, hits=-1.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RESENT_TO,SPAM_PHRASE_02_03 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] > Set the clocks correctly, and schedule the change on all the servers for > a particular time, using (for example) the tinydns timestamp feature > described in http://cr.yp.to/djbdns/tinydns-data.html. When that time > rolls around, all the servers will change their data simultaneously, My friend Dr. Einstein would like a word with you about your casual misuse of the word "simultaneously." __________________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 21 19:07:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19113 for ; Fri, 21 Feb 2003 19:07:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mN6s-0007SF-00 for namedroppers-data@psg.com; Fri, 21 Feb 2003 16:01:42 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18mN6q-0007S3-00 for namedroppers@ops.ietf.org; Fri, 21 Feb 2003 16:01:40 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18mN6p-000Fmj-00 for namedroppers@ops.ietf.org; Sat, 22 Feb 2003 09:01:39 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-reply-to: "21 Feb 2003 06:58:42 PST." Message-id: <200302211809.h1LI98G03298@gungnir.fnal.gov> Date: Fri, 21 Feb 2003 12:09:08 -0600 From: Matt Crawford Subject: Re: Bind 9 AXFR Modification vs AXFR Clarification To: David Conrad Cc: Erik Nordmark , Name Droppers , ietf@ietf.org, iesg@ietf.org X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RESENT_TO,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] > > draft-ietf-dnsext-axfr-clarify-00.txt Nominum Inc. > > March 2000 > > Seems to be 3 years ago. > I remember when people thought OSI protocols took too long to > standardize... :-) "$X is a slow-moving parody of itself." -- Peter Honeyman In the original, $X was bound to "USENET", not "IETF". -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 21 19:39:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19780 for ; Fri, 21 Feb 2003 19:39:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mNfR-0009MG-00 for namedroppers-data@psg.com; Fri, 21 Feb 2003 16:37:25 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18mNfO-0009M3-00 for namedroppers@ops.ietf.org; Fri, 21 Feb 2003 16:37:22 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18mNfN-0007aP-00 for namedroppers@ops.ietf.org; Sat, 22 Feb 2003 09:37:21 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: Subject: RE: [dhcwg] Re: WG last call ondraft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Date: Fri, 21 Feb 2003 10:07:13 +0100 From: "BELOEIL Luc FTRD/DMI/CAE" To: "Alain Durand" , "Pekka Savola" Cc: "Ralph Droms" , , , X-Spam-Status: No, hits=-0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,RESENT_TO,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Hi all,=20 > De : Alain Durand [mailto:Alain.Durand@Sun.COM] > > On Thursday, February 20, 2003, at 10:25 PM, Pekka Savola wrote: >=20 > > On Thu, 20 Feb 2003, Alain Durand wrote: > >> On Thursday, February 20, 2003, at 12:03 PM, Ralph Droms wrote: > >>> If it's unclear, then we should edit the document to explicitly > >>> identify the addresses as IPv6 addresses. > >>> > >>> This option is intended to return IPv6 configuration information. > >>> IPv4 addresses for DNS resolvers should be provided=20 > through DHCPv4... > > > > I symphatize with this -- there are some uses to have DHCPv6 return=20 > > IPv4 > > addresses too -- but the result would just make the=20 > dnsconfig option=20 > > more > > complex for little benefit. Let's face it: if you deploy=20 > DHCPv6, you > > really should have long since deployed IPv6-enabled nameservers too. > > > > So, I think clarifying the scope to do only IPv6 seems like the best > > option by far. >=20 >=20 > Some may scream at this idea, but couldn't we pass an IPv4-mapped=20 > address > in there? The DHCPv6 client could recognize this special format > to mean this is actually a v4 address? >=20 I feel ill at ease with such a solution. How your DHCPv6 client, running a node, is aware that there is an IPv4 stack enable on that same node ? If it is not, v4-mapped addresses could be harmfull, couldn't they ? >=20 > > > >> Now, let's say that this is the case for DHCP, what should=20 > a node that > >> act both as a DHCPv4 and DHCPv6 client do when it will be=20 > returned two > >> lists of recursive DNS serves, one IPv4 via DHCPv4 and one IPv6 via > >> DHCPv6. Which one should take priority? > > > > Implementation decision, but I guess typically the results of the > > latest query take precedence. I don't see a problem here, myself. >=20 > Unpredictable behavior. Difficult to debug. >=20 > - Alain. >=20 Good remark! I understand the point/issue if IPv6 provider is not the same as IPv4 one. By that way the node may not have the same global vision of the Domain Name System!=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. archive: From owner-namedroppers@ops.ietf.org Fri Feb 21 20:49:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21014 for ; Fri, 21 Feb 2003 20:49:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mOiV-000DBY-00 for namedroppers-data@psg.com; Fri, 21 Feb 2003 17:44:39 -0800 Received: from [2002:425c:4242:0:250:daff:fe82:1c39] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 18mOiQ-000Cvb-00 for namedroppers@ops.ietf.org; Fri, 21 Feb 2003 17:44:37 -0800 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 1D82D18EC; Fri, 21 Feb 2003 20:39:30 -0500 (EST) Date: Fri, 21 Feb 2003 20:39:30 -0500 From: Rob Austein To: Ralph Droms Cc: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-Reply-To: <4.3.2.7.2.20030220143854.03e69358@funnel.cisco.com> User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030222013930.1D82D18EC@thrintun.hactrn.net> X-Spam-Status: No, hits=-0.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_05_08,USER_AGENT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In response to the main question: I've read the draft, the option looks looks reasonable to me (subject to the discussion that has already taken place during this last call, I'm not disagreeing with any of that), and I think it'd be useful for this draft to advance. The rest of this message is on one specific point: At Thu, 20 Feb 2003 14:55:11 -0500, Ralph Droms wrote: > At 08:27 PM 2/10/2003 +0100, Peter Koch wrote: > > >Apart from the sad fact that DNSSEC isn't yet deployed I don't see why it > >wouldn't be able to detect spoofing. If, however, you want to say that > >using domain names in the search list you don't control is a dangerous > >thing, that could be emphazised by a reference to RFC 1535. > > The idea here (note that I'm not a DNSSEC expert, either) is that > a search list that the host doesn't control might still pass DNSSEC > authentication while yielding unexpected results. > > I would be happy to hear that DNSSEC can prevent the problem and would > be willing to follow your suggestion and replace the reference to > DNSSEC with a more general reference to untrusted search lists. DNSSEC could let you figure out whether the data you got back was signed by an entity which you trust. The difficulty with search paths, is that you're also trusting the search path to tell you what question you should be asking. So DNSSEC could let you figure out whether the random question that your search path just told you to ask was answered with data signed by an entity which you trust, but it's not going to help you figure out whether that was the right question. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 21 22:39:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23011 for ; Fri, 21 Feb 2003 22:39:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mQR2-000JO4-00 for namedroppers-data@psg.com; Fri, 21 Feb 2003 19:34:44 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 18mQQW-000JMe-00 for namedroppers@ops.ietf.org; Fri, 21 Feb 2003 19:34:12 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h1M3Y8qn094575; Fri, 21 Feb 2003 22:34:09 -0500 (EST) Received: from [220.128.48.115] ([192.136.136.114]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id WAA14435; Fri, 21 Feb 2003 22:34:07 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@ops Message-Id: In-Reply-To: <20030218183616.98C8518DF@thrintun.hactrn.net> References: <20030218183616.98C8518DF@thrintun.hactrn.net> Date: Sat, 22 Feb 2003 11:24:05 +0800 To: Rob Austein From: Edward Lewis Subject: Re: empty answers Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-1.2 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_02_03,TO_BE_REMOVED_REPLY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Oh, a response with 0 RR's is legal, I've seen it in the past. I was just wondering if it was still done. I suppose the latter question is bogus, any specification would have to address empty answers (as they are are legal and, besides, there exists at least one process somewhere still capable of issuing them ;) ). At 13:36 -0500 2/18/03, Rob Austein wrote: >At Tue, 18 Feb 2003 11:28:40 +0800, Ed Lewis wrote: >> >> When was the last time a completely empty answer (w/RCODE=0) was >> intentionally implemented? >> >> E.g., a response to a query (in which the QCLASS and QNAME exist but >> without a match for the QTYPE) that had neither a SOA RR nor a NXT RR >> in the authority section? > >I can't answer your question about "when", but for what it's worth: > >This is a legitimate response for an authoritative-only name server to >send when asked about a zone for which it knows absolutely nothing. > >If I assume that you meant "NS" rather than "NXT", it's still >legitimate, but less common, since it would only be given out by the >above name server when it had no root hints to hand out. This is a >completely legitimate configuration, but not that common, due to >implementations that become despondant upon discovering that they have >no root hints and chose to reply with RCODE=2. > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Feb 22 06:01:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08731 for ; Sat, 22 Feb 2003 06:01:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mXDF-000HzD-00 for namedroppers-data@psg.com; Sat, 22 Feb 2003 02:48:57 -0800 Received: from cs78149057.pp.htv.fi ([62.78.149.57] helo=devil.pp.htv.fi) by psg.com with esmtp (Exim 3.36 #1) id 18mXCj-000Hwk-00 for namedroppers@ops.ietf.org; Sat, 22 Feb 2003 02:48:25 -0800 Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1MAmXaj027089; Sat, 22 Feb 2003 12:48:34 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1MAmSxt027087; Sat, 22 Feb 2003 12:48:28 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt From: Mika Liljeberg To: Pekka Savola Cc: Alain Durand , Ralph Droms , dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045910906.26677.29.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Feb 2003 12:48:27 +0200 X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02, X_AUTH_WARNING version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 2003-02-21 at 08:25, Pekka Savola wrote: > On Thu, 20 Feb 2003, Alain Durand wrote: > > On Thursday, February 20, 2003, at 12:03 PM, Ralph Droms wrote: > > > If it's unclear, then we should edit the document to explicitly > > > identify the addresses as IPv6 addresses. > > > > > > This option is intended to return IPv6 configuration information. > > > IPv4 addresses for DNS resolvers should be provided through DHCPv4... > > I symphatize with this -- there are some uses to have DHCPv6 return IPv4 > addresses too -- but the result would just make the dnsconfig option more > complex for little benefit. Let's face it: if you deploy DHCPv6, you > really should have long since deployed IPv6-enabled nameservers too. > > So, I think clarifying the scope to do only IPv6 seems like the best > option by far. Is that necessary? IPv4 addresses can be returned in IPv4 Mapped format if necessary. Just add some text explaining this. With our hybrid IPv4/IPv6 stack implementation this would work out of the box. MikaL -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Feb 22 06:14:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08891 for ; Sat, 22 Feb 2003 06:14:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mXR7-000IeB-00 for namedroppers-data@psg.com; Sat, 22 Feb 2003 03:03:17 -0800 Received: from cs78149057.pp.htv.fi ([62.78.149.57] helo=devil.pp.htv.fi) by psg.com with esmtp (Exim 3.36 #1) id 18mXQb-000IdY-00 for namedroppers@ops.ietf.org; Sat, 22 Feb 2003 03:02:45 -0800 Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1MB31aj027243; Sat, 22 Feb 2003 13:03:01 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1MB30t3027242; Sat, 22 Feb 2003 13:03:00 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: RE: [dhcwg] Re: WG last call ondraft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt From: Mika Liljeberg To: BELOEIL Luc FTRD/DMI/CAE Cc: Alain Durand , Pekka Savola , Ralph Droms , dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045911780.27180.5.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Feb 2003 13:03:00 +0200 X-Spam-Status: No, hits=-1.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, X_AUTH_WARNING version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 2003-02-21 at 11:07, BELOEIL Luc FTRD/DMI/CAE wrote: > > Some may scream at this idea, but couldn't we pass an IPv4-mapped > > address > > in there? The DHCPv6 client could recognize this special format > > to mean this is actually a v4 address? I think this is a good idea. > I feel ill at ease with such a solution. How your DHCPv6 client, running > a node, is aware that there is an IPv4 stack enable on that same node ? > If it is not, v4-mapped addresses could be harmfull, couldn't they ? Not really. Why would a network administrator advertise IPv4 DNS servers on a network with IPv6 only nodes? Even if there are some IPv6 only nodes on the network, the host resolver on those nodes will simply try to use the IPv4-mapped address and fail, and move on the the next one as it would do with any malfunctioning DNS server. I don't think the DHCP client has to care whether IPv4 is enabled on the node (although it could attempt to check that). All it has to do is configure the DNS addresses and let the host resolver take it from there. MikaL -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Feb 22 06:22:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08984 for ; Sat, 22 Feb 2003 06:22:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mXf3-000JMH-00 for namedroppers-data@psg.com; Sat, 22 Feb 2003 03:17:41 -0800 Received: from [3ffe:b80:2:a90::2] (helo=devil.pp.htv.fi) by psg.com with esmtp (Exim 3.36 #1) id 18mXez-000JL5-00 for namedroppers@ops.ietf.org; Sat, 22 Feb 2003 03:17:38 -0800 Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1MBHlaj027296; Sat, 22 Feb 2003 13:17:48 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1MBHiY2027295; Sat, 22 Feb 2003 13:17:44 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt From: Mika Liljeberg To: Pekka Savola Cc: Alain Durand , Ralph Droms , dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045912663.27180.12.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Feb 2003 13:17:44 +0200 X-Spam-Status: No, hits=-1.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, X_AUTH_WARNING version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sat, 2003-02-22 at 13:13, Pekka Savola wrote: > IMO, we should just say "IPv6 addresses" (the critical thing here is the > size of the address -- no checks are done to validate them!), and nothing > about mapped addresses. > > If some want to push mapped addresses in there, that's fine by me -- if > your DNS resolver supports mapped addresses in /etc/resolv.conf (or > equivalent). > > No special code/text, is my opinion! That's good. I agree. MikaL -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Feb 22 06:31:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09153 for ; Sat, 22 Feb 2003 06:31:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mXk0-000Jcj-00 for namedroppers-data@psg.com; Sat, 22 Feb 2003 03:22:48 -0800 Received: from [3ffe:b80:2:a90::2] (helo=devil.pp.htv.fi) by psg.com with esmtp (Exim 3.36 #1) id 18mXjw-000JcV-00 for namedroppers@ops.ietf.org; Sat, 22 Feb 2003 03:22:45 -0800 Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1MBNEaj027331; Sat, 22 Feb 2003 13:23:14 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1MBNDPc027330; Sat, 22 Feb 2003 13:23:13 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt From: Mika Liljeberg To: Ralph Droms Cc: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org In-Reply-To: <4.3.2.7.2.20030220135524.03e6d548@funnel.cisco.com> References: <4.3.2.7.2.20030220135524.03e6d548@funnel.cisco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045912992.27180.14.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Feb 2003 13:23:12 +0200 X-Spam-Status: No, hits=-1.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, X_AUTH_WARNING version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 2003-02-20 at 20:56, Ralph Droms wrote: > Reminder and note: there have been a few responses to this WG last call, > but no explicit positive recommendations for advancement. Please review > draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt and reply with comments. If you > recommend the document for advancement without revision, please respond > with a quick acknowledgment. No response will be interpreted as a lack of > support for advancing the document. I would like to see this specification move forward. MikaL -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Feb 22 07:16:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09590 for ; Sat, 22 Feb 2003 07:16:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mYSu-000M1W-00 for namedroppers-data@psg.com; Sat, 22 Feb 2003 04:09:12 -0800 Received: from [2001:470:1f00:ffff::5a1] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 18mYSr-000M0c-00 for namedroppers@ops.ietf.org; Sat, 22 Feb 2003 04:09:09 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h1MC8M4U017007; Sat, 22 Feb 2003 23:08:23 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200302221208.h1MC8M4U017007@drugs.dv.isc.org> To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: update timing In-reply-to: Your message of "21 Feb 2003 21:32:57 -0000." <20030221213257.61542.qmail@cr.yp.to> Date: Sat, 22 Feb 2003 23:08:22 +1100 X-Spam-Status: No, hits=0.9 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, TO_BE_REMOVED_REPLY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > Regardless of if it's an administrative error or an intentional > > change, there's no excuse for any software to allow timing issues to > > affect data integrity. > > Suppose the administrator changes the serial number and _then_ changes > the other data. This timing screwup destroys data integrity with BIND 9. > According to your mindless rhetoric, this is an inexcusable BIND 9 flaw. > > Can we please drop the religious nonsense now? > > In the real world, when the administrator screws up the timing, we blame > the administrator. Good software can prevent many problems---as tinydns > does with automatic serial numbers, for example---but all remaining > problems are the direct result of an administrator's misconfiguration. > > Andrews says that the RFC 1034 rules are too hard for administrators to > follow. He wants to loosen them. I'm pointing out exactly which timing > rules are necessary to guarantee a successful update. You are claiming > that we don't need _any_ rules; that's ludicrous. Server A (tinydns) primary parent and child. Server B (bind 8) secondary parent and child off A Server C secondary parent off B Initial state NS RRset for child zone N on all servers Server A updates NS RRset to N' Server B transfers parent Server C transfers parent Server B transfers child Final state Server A N', Server B N', Server C N Your fix. Delay the update of the parent. Tinydns is incapable of doing this. > ---D. J. Bernstein, Associate Professor, Department of Mathematics, > Statistics, and Computer Science, University of Illinois at Chicago > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Feb 22 08:05:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10395 for ; Sat, 22 Feb 2003 08:05:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mZB8-000OFl-00 for namedroppers-data@psg.com; Sat, 22 Feb 2003 04:54:54 -0800 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.36 #1) id 18mZAd-000ODK-00 for namedroppers@ops.ietf.org; Sat, 22 Feb 2003 04:54:23 -0800 Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id h1MCs1I04267; Sat, 22 Feb 2003 04:54:01 -0800 (PST) From: Bill Manning Message-Id: <200302221254.h1MCs1I04267@boreas.isi.edu> Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-Reply-To: <1045912663.27180.12.camel@devil> from Mika Liljeberg at "Feb 22, 3 01:17:44 pm" To: mika.liljeberg@welho.com (Mika Liljeberg) Date: Sat, 22 Feb 2003 04:54:00 -0800 (PST) Cc: pekkas@netcore.fi, Alain.Durand@Sun.COM, rdroms@cisco.com, dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit regarding the use of mapped addresses: draft-cmetz-v6ops-v4mapped-api-harmful-00.txt might be a useful ID to review before committing this draft to the stds process. --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Feb 22 08:29:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10586 for ; Sat, 22 Feb 2003 08:28:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mZeX-000Pq8-00 for namedroppers-data@psg.com; Sat, 22 Feb 2003 05:25:17 -0800 Received: from [3ffe:b80:2:a90::2] (helo=devil.pp.htv.fi) by psg.com with esmtp (Exim 3.36 #1) id 18mZeT-000Ppu-00 for namedroppers@ops.ietf.org; Sat, 22 Feb 2003 05:25:14 -0800 Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1MDPXaj027791; Sat, 22 Feb 2003 15:25:34 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1MDPVQX027788; Sat, 22 Feb 2003 15:25:31 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: IPv4-mapped API [Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt] From: Mika Liljeberg To: Bill Manning Cc: pekkas@netcore.fi, Alain.Durand@Sun.COM, rdroms@cisco.com, dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org In-Reply-To: <200302221254.h1MCs1I04267@boreas.isi.edu> References: <200302221254.h1MCs1I04267@boreas.isi.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045920330.27180.45.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Feb 2003 15:25:31 +0200 X-Spam-Status: No, hits=-1.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, X_AUTH_WARNING version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Topic changed. If you respond to this, please drop unrelated mailing lists.] On Sat, 2003-02-22 at 14:54, Bill Manning wrote: > regarding the use of mapped addresses: > > draft-cmetz-v6ops-v4mapped-api-harmful-00.txt > > might be a useful ID to review before committing this draft to the > stds process. These issues are completely unrelated. The API issues are real but they are not something that can or should be considered in a protocol specification. [Sorry for the off-topicness of the following] I'm not too happy about RFC2553 myself in this respect, and I strongly support the "Alternative solution" (fully specify IPv4-mapped behaviour) in the above mentioned draft. I can attest from implementation experience that it is possible to create a hybrid IPv4/IPv6 stack implementation that uses around 80-90% shared code between IPv4 and IPv6. All IPv4 addresses are handled in IPv4-mapped format internally inside the stack. Our sockets API is (mostly) version agnostic. Most applications are not even aware which IP version they are using. The OS is not a unix derivative and did not have the legacy baggage of the BSD style sockets API. The API that was already defined for IPv4 yielded very easily to support IPv6. MikaL -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Feb 22 10:19:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11981 for ; Sat, 22 Feb 2003 10:19:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mbLW-0005Y2-00 for namedroppers-data@psg.com; Sat, 22 Feb 2003 07:13:46 -0800 Received: from as7-2-2.bn.g.bonet.se ([217.215.21.151] helo=poledra) by psg.com with esmtp (Exim 3.36 #1) id 18mbL0-0005TG-00 for namedroppers@ops.ietf.org; Sat, 22 Feb 2003 07:13:14 -0800 Received: from amalthea.8in.net ([192.168.242.14] helo=amalthea) by poledra with asmtp (Exim 3.35 #1 (Debian)) id 18mbKy-0008K8-00 for ; Sat, 22 Feb 2003 16:13:12 +0100 Message-ID: <068501c2da84$d876ae70$0ef2a8c0@amalthea> From: =?iso-8859-1?Q?Kandra_Nyg=E5rds?= To: References: <200302202233.h1KMXO4U009264@drugs.dv.isc.org> <20030221063725.35914.qmail@cr.yp.to> <057201c2d9b6$b2154990$0ef2a8c0@amalthea> <20030221191430.97798.qmail@cr.yp.to> <060001c2d9e5$6be0fbc0$0ef2a8c0@amalthea> <20030221213257.61542.qmail@cr.yp.to> Subject: Re: update timing Date: Sat, 22 Feb 2003 16:12:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03, USER_AGENT_OE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit From: "D. J. Bernstein" > > Regardless of if it's an administrative error or an intentional > > change, there's no excuse for any software to allow timing issues to > > affect data integrity. > > Suppose the administrator changes the serial number and _then_ changes > the other data. This timing screwup destroys data integrity with BIND 9. BIND9 transfers the zone as presented by the master server at the time of the transfer. BIND9 does not destroy or change any data received through that transfer. A change in the master zone without the corresponding change of serial is an administrative error, true, and will result in inconsistent views in master and slave servers. However, the draft in question is specific to the concept of AXFR. In this scenario, an AXFR would never take place. > Can we please drop the religious nonsense now? I apologize. I strayed off topic. > In the real world, when the administrator screws up the timing, we blame > the administrator. Good software can prevent many problems---as tinydns > does with automatic serial numbers, for example---but all remaining > problems are the direct result of an administrator's misconfiguration. I fully agree with you, with the exception that there is a defined problem here. Under certain circumstances, some software might not preserve data integrity. Your software might be one of them, as has been claimed by a number of people. I agree that good software can prevent many problems, in particular administrative errors. However, those errors must be corrected at the source or not at all. Attempting to correct administrative errors at a slave server will cause data inconsistency in certain circumstances. > Andrews says that the RFC 1034 rules are too hard for administrators to > follow. He wants to loosen them. I'm pointing out exactly which timing > rules are necessary to guarantee a successful update. You are claiming > that we don't need _any_ rules; that's ludicrous. On the contrary, I'm trying to encourage a draft that specifies rules to protect data integrity. - Kandra -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Feb 22 11:10:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12541 for ; Sat, 22 Feb 2003 11:10:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mc9N-0008Pz-00 for namedroppers-data@psg.com; Sat, 22 Feb 2003 08:05:17 -0800 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by psg.com with esmtp (Exim 3.36 #1) id 18mc8L-0008K9-00 for namedroppers@ops.ietf.org; Sat, 22 Feb 2003 08:04:13 -0800 Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1MG4AJR004751 for ; Sat, 22 Feb 2003 11:04:11 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn2-488.cisco.com [10.82.241.232]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA06737 for ; Sat, 22 Feb 2003 11:04:10 -0500 (EST) Message-Id: <4.3.2.7.2.20030222105644.00b87580@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 22 Feb 2003 11:04:06 -0500 To: namedroppers@ops.ietf.org From: Ralph Droms Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration In-Reply-To: <20030218113122U.kitamura@netlab.nec.co.jp> References: <4.3.2.7.2.20030206113001.00b974e8@funnel.cisco.com> <5.1.1.6.2.20030204144231.01e22c70@localhost> <4.3.2.7.2.20030206113001.00b974e8@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-2.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Thanks for the clarification about the purpose of the document. However, I still don't agree that the IETF should consider publishing this document. There are no parts of the scheme described in the document that address or solve interoperability issues. - Ralph At 11:31 AM 2/18/2003 +0900, kitamura@da.jp.nec.com wrote: >Date: Thu, 06 Feb 2003 11:30:51 -0500 >Message-ID: <4.3.2.7.2.20030206113001.00b974e8@funnel.cisco.com> > > > I do not support the publication of this specification on experimental > > track, for the following reasons: > > > > What, exactly, is being standardized as an experimental protocol in > > this document; why is the IETF publishing it? The detector function > > is a set of heuristics which may be of use in detecting newly > > connected nodes, but it's not a protocol. The detector<->registrar > ^^^^^^^^^^^^^^ > >Please read the I-D carefully. > >Let me quote the beginning of the I-D. > > This document describes a scheme of "Domain Name Auto-Registration > ^^^^^^^^ > for Plugged-in IPv6 Nodes" mechanism that makes it possible to > register both regular and inverse domain name information of plugged- > in IPv6 nodes to DNS servers automatically. > > >The document describes a scheme (not a protocol). > >Main goals of the document are: > > - to meet requirements to use logical names that are easy to remember > to specify IPv6 nodes (even if they are just plugged-in). > > - to clarify problems that we meet when we apply the Dynamic Updates > in the DNS [DYN-DNS] to automatic domain name information > registration mechanisms. > > - to provide a scheme to solve above problems. > > - to provide a method to collect IPv6 address information that > should be registered to DNS servers. > (This will help administrators of DNS servers.) > > - ... > > >This document is on experimental track (not standard track), and >the document describes enough information for it. > > > > communication is only described as an example in Appendix A. The > > registrar then uses DDNS to change the information in DNS. The > > registrar function is a set of rules for generating names for nodes > > and for managing information about nodes. What is the protocol that > > must be standardized for interoperability among different > > implementations? > > >Regards, >Hiroshi -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Feb 22 12:30:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13474 for ; Sat, 22 Feb 2003 12:30:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mdNu-000Cxi-00 for namedroppers-data@psg.com; Sat, 22 Feb 2003 09:24:22 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #1) id 18mdNE-000CvK-00 for namedroppers@ops.ietf.org; Sat, 22 Feb 2003 09:23:40 -0800 Received: (qmail 34649 invoked by uid 1016); 22 Feb 2003 17:24:05 -0000 Date: 22 Feb 2003 17:24:05 -0000 Message-ID: <20030222172405.34648.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: update timing References: <20030221213257.61542.qmail@cr.yp.to> <200302221208.h1MC8M4U017007@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=3.4 required=5.0 tests=NO_MX_FOR_FROM,REFERENCES,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: *** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Andrews gives yet another example of a configuration that (1) violates the semi-synchronization rule and (2) causes problems. The solution, of course, is to follow the semi-synchronization rule: update the parent serial number after the child servers have changed. Mark.Andrews@isc.org writes: > Tinydns is incapable of doing this. Where do you get these ridiculous ideas? With tinydns, you can use manual serial numbers and update them exactly as you would with BIND. You can also use automatic serial numbers and update them by simply touching the data file. Both ways work. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Feb 22 12:46:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13714 for ; Sat, 22 Feb 2003 12:46:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mdfg-000E4A-00 for namedroppers-data@psg.com; Sat, 22 Feb 2003 09:42:44 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #1) id 18mdfd-000E32-00 for namedroppers@ops.ietf.org; Sat, 22 Feb 2003 09:42:41 -0800 Received: (qmail 40360 invoked by uid 1016); 22 Feb 2003 17:43:07 -0000 Date: 22 Feb 2003 17:43:07 -0000 Message-ID: <20030222174307.40359.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: update timing References: <200302202233.h1KMXO4U009264@drugs.dv.isc.org> <20030221063725.35914.qmail@cr.yp.to> <057201c2d9b6$b2154990$0ef2a8c0@amalthea> <20030221191430.97798.qmail@cr.yp.to> <060001c2d9e5$6be0fbc0$0ef2a8c0@amalthea> <20030221213257.61542.qmail@cr.yp.to> <068501c2da84$d876ae70$0ef2a8c0@amalthea> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ BIND 9 allowing a badly timed serial-number update to destroy data ] > In this scenario, an AXFR would never take place. BIND 9 does an AXFR, but does it too early, because the administrator updated the parent serial number too early. BIND 9 never realizes that it has to do another AXFR. This is also what's going wrong in Andrews's tinydns/BIND 8 scenarios. Andrews updates the parent serial number too early, so the parent slave doesn't realize that it have to transfer the parent zone. The necessary final AXFR never takes place. > Attempting to correct administrative errors at a slave server > will cause data inconsistency in certain circumstances. No. It will simply copy inconsistencies created by the administrator. If the administrator changes serial numbers properly, the only effect of these inconsistencies is that, _during_ the update, clients might receive old data, and clients might receive new data. If the administrator screws up the timing of changing serial numbers, the old data can persist _beyond_ the update. You claimed that this was ``inexcusable'' but have now admitted that it's true for BIND 9 too. The solution is for the administrator to change serial numbers properly. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Feb 22 18:14:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17111 for ; Sat, 22 Feb 2003 18:14:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18migI-0006pj-00 for namedroppers-data@psg.com; Sat, 22 Feb 2003 15:03:42 -0800 Received: from [2001:470:1f00:ffff::5a1] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 18migE-0006oP-00 for namedroppers@ops.ietf.org; Sat, 22 Feb 2003 15:03:39 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h1MMn04U018543; Sun, 23 Feb 2003 09:49:00 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200302222249.h1MMn04U018543@drugs.dv.isc.org> To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: update timing In-reply-to: Your message of "22 Feb 2003 17:24:05 -0000." <20030222172405.34648.qmail@cr.yp.to> Date: Sun, 23 Feb 2003 09:49:00 +1100 X-Spam-Status: No, hits=1.2 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05, TO_BE_REMOVED_REPLY version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Andrews gives yet another example of a configuration that (1) violates > the semi-synchronization rule and (2) causes problems. > > The solution, of course, is to follow the semi-synchronization rule: > update the parent serial number after the child servers have changed. > > Mark.Andrews@isc.org writes: > > Tinydns is incapable of doing this. > > Where do you get these ridiculous ideas? > > With tinydns, you can use manual serial numbers and update them exactly > as you would with BIND. You can also use automatic serial numbers and > update them by simply touching the data file. Both ways work. So now you want to update the contents of the parent zone without a changing the serial. You want the administators to intentionally introduce inconsistanties within the servers of a zone to deal with your misguided attempts to remove inconsistanties between zones that will be corrected if you left them alone. Mark > ---D. J. Bernstein, Associate Professor, Department of Mathematics, > Statistics, and Computer Science, University of Illinois at Chicago > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Feb 22 18:43:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17475 for ; Sat, 22 Feb 2003 18:43:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mjCr-0008n0-00 for namedroppers-data@psg.com; Sat, 22 Feb 2003 15:37:21 -0800 Received: from [2001:470:1f00:ffff::5a1] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 18mjCo-0008lZ-00 for namedroppers@ops.ietf.org; Sat, 22 Feb 2003 15:37:19 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h1MNae4U018852; Sun, 23 Feb 2003 10:36:40 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200302222336.h1MNae4U018852@drugs.dv.isc.org> To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: update timing In-reply-to: Your message of "22 Feb 2003 17:43:07 -0000." <20030222174307.40359.qmail@cr.yp.to> Date: Sun, 23 Feb 2003 10:36:40 +1100 X-Spam-Status: No, hits=0.5 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > [ BIND 9 allowing a badly timed serial-number update to destroy data ] Dan, is your intention to intentionally mislead the list? The example was for BIND 8. Saying it was for BIND 9 was a lie. Server A (tinydns) primary parent and child. Server B (bind 8) secondary parent and child off A Server C secondary parent off B Initial state NS RRset for child zone N on all servers Server A updates NS RRset to N' Server B transfers parent Server C transfers parent Server B transfers child Final state Server A N', Server B N', Server C N Your fix. Delay the update of the parent. Tinydns is incapable of doing this. > > In this scenario, an AXFR would never take place. > > BIND 9 does an AXFR, but does it too early, because the administrator > updated the parent serial number too early. BIND 9 never realizes that > it has to do another AXFR. Well it was BIND 8 doing the AXFR. > This is also what's going wrong in Andrews's tinydns/BIND 8 scenarios. > Andrews updates the parent serial number too early, so the parent slave > doesn't realize that it have to transfer the parent zone. The necessary > final AXFR never takes place. There is not such thing are a "necessary final AXFR". > > Attempting to correct administrative errors at a slave server > > will cause data inconsistency in certain circumstances. > > No. It will simply copy inconsistencies created by the administrator. What? > If the administrator changes serial numbers properly, the only effect > of these inconsistencies is that, _during_ the update, clients might > receive old data, and clients might receive new data. > > If the administrator screws up the timing of changing serial numbers, > the old data can persist _beyond_ the update. You claimed that this was > ``inexcusable'' but have now admitted that it's true for BIND 9 too. The > solution is for the administrator to change serial numbers properly. Well I didn't claim this. If the nameserver screws up the copy of the zone the old data can persist _beyond_ the update. The simple solution to this is to stop the nameservers screwing with the copy the zone. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Feb 22 19:11:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17949 for ; Sat, 22 Feb 2003 19:11:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mjgT-000AW4-00 for namedroppers-data@psg.com; Sat, 22 Feb 2003 16:07:57 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #1) id 18mjgQ-000AVi-00 for namedroppers@ops.ietf.org; Sat, 22 Feb 2003 16:07:55 -0800 Received: (qmail 38779 invoked by uid 1016); 23 Feb 2003 00:08:19 -0000 Date: 23 Feb 2003 00:08:19 -0000 Message-ID: <20030223000819.38778.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: update timing References: <20030222172405.34648.qmail@cr.yp.to> <200302222249.h1MMn04U018543@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=1.1 required=5.0 tests=REFERENCES,SPAM_PHRASE_05_08 version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mark.Andrews@isc.org writes: > So now you want to update the contents of the parent zone > without a changing the serial. I said nothing of the sort. The entire theme of this discussion is that _you_ are causing problems by leaving a serial number alone when you should be updating it. Because of your configuration error, a slave fails to realize that it needs to do an AXFR. _I_ am saying that those serial numbers have to be changed at certain times. My position is supported by both RFC 1034 (which imposes even more stringent constraints---so stringent that you're trying to change them) and the reality of what actually works with the installed base. (The ``I'll update serial numbers too early if I feel like it, and it's inexcusable for software to fail to correct my mistake'' religion made a brief appearance in this discussion, and was quickly shredded. It's obvious that some constraints are required.) It is, of course, acceptable for serial numbers to be changed at other times too. Extra AXFRs will not cause the world to collapse. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Feb 22 19:21:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18077 for ; Sat, 22 Feb 2003 19:21:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mjr4-000BDi-00 for namedroppers-data@psg.com; Sat, 22 Feb 2003 16:18:54 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #1) id 18mjr1-000BDV-00 for namedroppers@ops.ietf.org; Sat, 22 Feb 2003 16:18:51 -0800 Received: (qmail 45121 invoked by uid 1016); 23 Feb 2003 00:19:14 -0000 Date: 23 Feb 2003 00:19:14 -0000 Message-ID: <20030223001914.45120.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: update timing References: <20030222174307.40359.qmail@cr.yp.to> <200302222336.h1MNae4U018852@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mark.Andrews@isc.org writes: > Dan, is your intention to intentionally mislead the list? > The example was for BIND 8. Saying it was for BIND 9 was a lie. You are, as usual, completely wrong. I gave a crystal-clear example of BIND 9 allowing a badly timed serial-number update to destroy data. I was responding to the ridiculous claim that ``there's no excuse for any software to allow timing issues to affect data integrity.'' > Tinydns is incapable [ of changing serial numbers upon demand ] Wrong again. You're making a fool of yourself. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Feb 22 20:06:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18570 for ; Sat, 22 Feb 2003 20:06:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mkW6-000Djx-00 for namedroppers-data@psg.com; Sat, 22 Feb 2003 17:01:18 -0800 Received: from [2001:470:1f00:ffff::5a1] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 18mkW3-000Djd-00 for namedroppers@ops.ietf.org; Sat, 22 Feb 2003 17:01:15 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h1N10P4U019135; Sun, 23 Feb 2003 12:00:25 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200302230100.h1N10P4U019135@drugs.dv.isc.org> To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: update timing In-reply-to: Your message of "23 Feb 2003 00:08:19 -0000." <20030223000819.38778.qmail@cr.yp.to> Date: Sun, 23 Feb 2003 12:00:25 +1100 X-Spam-Status: No, hits=1.7 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_05_08, TO_BE_REMOVED_REPLY version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Mark.Andrews@isc.org writes: > > So now you want to update the contents of the parent zone > > without a changing the serial. > > I said nothing of the sort. > > The entire theme of this discussion is that _you_ are causing problems > by leaving a serial number alone when you should be updating it. Because > of your configuration error, a slave fails to realize that it needs to > do an AXFR. In every case I've presented the PRIMARY changed the serial when the parent zone was updated. This is correct adminstrative procedure. > _I_ am saying that those serial numbers have to be changed at certain > times. My position is supported by both RFC 1034 (which imposes even > more stringent constraints---so stringent that you're trying to change > them) and the reality of what actually works with the installed base. There is no requirement to change the contents of a secondary zone in RFC 1034. It's all in your imagination. > (The ``I'll update serial numbers too early if I feel like it, and it's > inexcusable for software to fail to correct my mistake'' religion made > a brief appearance in this discussion, and was quickly shredded. It's > obvious that some constraints are required.) It's your I'll change the contents of a secondary zone that is causing all the problems. > It is, of course, acceptable for serial numbers to be changed at other > times too. Extra AXFRs will not cause the world to collapse. > > ---D. J. Bernstein, Associate Professor, Department of Mathematics, > Statistics, and Computer Science, University of Illinois at Chicago > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Feb 22 21:32:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19478 for ; Sat, 22 Feb 2003 21:32:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mltF-000Ipt-00 for namedroppers-data@psg.com; Sat, 22 Feb 2003 18:29:17 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #1) id 18mlt5-000Ipc-00 for namedroppers@ops.ietf.org; Sat, 22 Feb 2003 18:29:07 -0800 Received: (qmail 83481 invoked by uid 1016); 23 Feb 2003 02:29:32 -0000 Date: 23 Feb 2003 02:29:32 -0000 Message-ID: <20030223022932.83480.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: update timing References: <20030223000819.38778.qmail@cr.yp.to> <200302230100.h1N10P4U019135@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-0.2 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_03_05 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mark.Andrews@isc.org writes: > In every case I've presented the PRIMARY changed the serial when > the parent zone was updated. This is correct adminstrative procedure. No. Your procedure is insufficient, incomplete, and incorrect. You're arguing that, because you did _something_ right, your entire procedure is correct. The premise is okay, but the logic is idiotic. Here's an extreme example to demonstrate the flaw in the logic. Suppose you _never_ update the data in the child servers. Then the old data will persist, producing a long-lasting inconsistency, quite similar to the inconsistencies in your BIND 8 examples and in my BIND 9 example. You can scream ``I updated the parent data and serial number'' all you want. But the problem isn't what you _did_; the problem is what you _failed_ to do. Now do you understand the flaw in your argument? Anyway, you've admitted that your procedure (1) violates RFC 1034 and (2) gives wrong answers with most of the installed base. So you don't have a leg to stand on when you call it ``correct.'' ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Feb 22 23:32:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21278 for ; Sat, 22 Feb 2003 23:32:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mniT-000O8x-00 for namedroppers-data@psg.com; Sat, 22 Feb 2003 20:26:17 -0800 Received: from [2001:6e0:206:1:250:daff:fe3d:1d6] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 3.36 #1) id 18mniR-000O8i-00 for namedroppers@ops.ietf.org; Sat, 22 Feb 2003 20:26:15 -0800 Received: from open.nlnetlabs.nl (localhost [IPv6:::1]) by open.nlnetlabs.nl (8.12.6/8.12.6) with ESMTP id h1N4QAp8090888; Sun, 23 Feb 2003 05:26:10 +0100 (CET) (envelope-from alexis@open.nlnetlabs.nl) Received: (from alexis@localhost) by open.nlnetlabs.nl (8.12.6/8.12.6/Submit) id h1N4QABX090887; Sun, 23 Feb 2003 05:26:10 +0100 (CET) Message-Id: <200302230426.h1N4QABX090887@open.nlnetlabs.nl> Subject: Re: update timing In-Reply-To: <20030223001914.45120.qmail@cr.yp.to> To: "D. J. Bernstein" Date: Sun, 23 Feb 2003 05:26:10 +0100 (CET) From: Alexis Yushin CC: namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, hits=-1.1 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Once D. J. Bernstein wrote: >Mark.Andrews@isc.org writes: >> Dan, is your intention to intentionally mislead the list? >> The example was for BIND 8. Saying it was for BIND 9 was a lie. > >You are, as usual, completely wrong. I gave a crystal-clear example of >BIND 9 allowing a badly timed serial-number update to destroy data. I >was responding to the ridiculous claim that ``there's no excuse for any >software to allow timing issues to affect data integrity.'' > >> Tinydns is incapable > [ of changing serial numbers upon demand ] > >Wrong again. You're making a fool of yourself. Are you guys married? Alexis -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Feb 23 00:13:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21738 for ; Sun, 23 Feb 2003 00:13:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18moNi-0000V2-00 for namedroppers-data@psg.com; Sat, 22 Feb 2003 21:08:54 -0800 Received: from [2001:470:1f00:ffff::5a1] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 18moNf-0000Q6-00 for namedroppers@ops.ietf.org; Sat, 22 Feb 2003 21:08:51 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h1N57m4U019531; Sun, 23 Feb 2003 16:07:48 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200302230507.h1N57m4U019531@drugs.dv.isc.org> To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: update timing In-reply-to: Your message of "23 Feb 2003 02:29:32 -0000." <20030223022932.83480.qmail@cr.yp.to> Date: Sun, 23 Feb 2003 16:07:48 +1100 X-Spam-Status: No, hits=1.0 required=5.0 tests=IN_REP_TO,LINES_OF_YELLING,NO_REAL_NAME,QUOTED_EMAIL_TEXT, SPAM_PHRASE_03_05 version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Mark.Andrews@isc.org writes: > > In every case I've presented the PRIMARY changed the serial when > > the parent zone was updated. This is correct adminstrative procedure. > > No. Your procedure is insufficient, incomplete, and incorrect. Changing the serial number when they data in a zone changes is correct procedure. THAT IS ALL THAT IS REQUIRED WITH NON BROKEN SERVERS. THAT IS ALL THAT IS REQUIRED BY RFC 1034. Waiting for data to propogate is a WORKAROUND. > You're arguing that, because you did _something_ right, your entire > procedure is correct. The premise is okay, but the logic is idiotic. > > Here's an extreme example to demonstrate the flaw in the logic. Suppose > you _never_ update the data in the child servers. Then the old data will > persist, producing a long-lasting inconsistency, quite similar to the > inconsistencies in your BIND 8 examples and in my BIND 9 example. If you never update the child then it is an *administrative* error. > You can scream ``I updated the parent data and serial number'' all you > want. But the problem isn't what you _did_; the problem is what you > _failed_ to do. Now do you understand the flaw in your argument? The size of the installed base has absolutely nothing to do which what is right or wrong. If 90% of installed bridges had construction/design flaws what would you do. A. Continue to used that the existing construction/design method. B. Stop using the existing construction/design method. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Feb 23 00:36:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21946 for ; Sun, 23 Feb 2003 00:36:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mom2-0002R2-00 for namedroppers-data@psg.com; Sat, 22 Feb 2003 21:34:02 -0800 Received: from gold.nb.net ([209.161.64.73] helo=mx2.nb.net) by psg.com with smtp (Exim 3.36 #1) id 18molz-0002PW-00 for namedroppers@ops.ietf.org; Sat, 22 Feb 2003 21:33:59 -0800 Received: (qmail 27480 invoked from network); 23 Feb 2003 05:33:58 -0000 Received: from titanium.nb.net (209.161.64.27) by gold.nb.net with SMTP; 23 Feb 2003 05:33:58 -0000 Date: Sun, 23 Feb 2003 00:33:58 -0500 (EST) From: Len Budney X-Sender: lbudney@titanium.nb.net To: namedroppers@ops.ietf.org Subject: Re: update timing In-Reply-To: <200302230507.h1N57m4U019531@drugs.dv.isc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sun, 23 Feb 2003 Mark.Andrews@isc.org wrote: > > The size of the installed base has absolutely nothing to do > which what is right or wrong. > > If 90% of installed bridges had construction/design flaws what > would you do. Redesign and rebuild the bridges, of course. But I wouldn't claim it was "routine maintenance" and "design clarification", for starters. I'd call it what it was. --Len. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Feb 23 01:36:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22524 for ; Sun, 23 Feb 2003 01:36:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mpXq-0005wS-00 for namedroppers-data@psg.com; Sat, 22 Feb 2003 22:23:26 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 18mpXn-0005wG-00 for namedroppers@ops.ietf.org; Sat, 22 Feb 2003 22:23:24 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h1N6NKqn009399; Sun, 23 Feb 2003 01:23:20 -0500 (EST) Received: from [220.128.48.115] ([192.136.136.76]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id BAA01306; Sun, 23 Feb 2003 01:23:18 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@ops Message-Id: In-Reply-To: <4.3.2.7.2.20030222105644.00b87580@funnel.cisco.com> References: <4.3.2.7.2.20030206113001.00b974e8@funnel.cisco.com> <5.1.1.6.2.20030204144231.01e22c70@localhost> <4.3.2.7.2.20030206113001.00b974e8@funnel.cisco.com> <4.3.2.7.2.20030222105644.00b87580@funnel.cisco.com> Date: Sun, 23 Feb 2003 14:23:11 +0800 To: Ralph Droms From: Edward Lewis Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:04 -0500 2/22/03, Ralph Droms wrote: >However, I still don't agree that the IETF should consider publishing >this document. There are no parts of the scheme described in >the document that address or solve interoperability issues. FWIW - I had the same comment in : http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01152.html (Not meaning to say "I said it first," but to say, "I agree.") My other problem with the document is in: http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01152.html and this hasn't been addressed (i.e., no update to the WG charter to allow this). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Feb 23 04:21:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04681 for ; Sun, 23 Feb 2003 04:21:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18msDj-000GLF-00 for namedroppers-data@psg.com; Sun, 23 Feb 2003 01:14:51 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #1) id 18msDh-000GKw-00 for namedroppers@ops.ietf.org; Sun, 23 Feb 2003 01:14:49 -0800 Received: (qmail 85300 invoked by uid 1016); 23 Feb 2003 09:15:13 -0000 Date: 23 Feb 2003 09:15:13 -0000 Message-ID: <20030223091513.85299.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: update timing errors References: <20030223022932.83480.qmail@cr.yp.to> <200302230507.h1N57m4U019531@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-0.8 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mark.Andrews@isc.org writes: > If you never update the child then it is an *administrative* error. Changing the serial number too early is also an administrative error. Here's a summary of our three examples of administrative errors: 1. Failing to update the parent serial number after updating the glue in all the child servers. As you keep pointing out, this error can cause problems with BIND 8: the data will be inconsistent until the serial number is updated. 2. Failing to update the parent serial number after updating the glue in the parent master. This error can cause problems with BIND 9 (and BIND 8, of course): the data will be inconsistent until the serial number is updated. 3. Failing to update the data in the child master. This error can cause problems with BIND 9 (and BIND 8, of course): the data will be inconsistent until the child data is updated (and the serial numbers handled properly). In every case, the administrator is violating RFC 1034 (as you have admitted), and is creating a configuration that does not work properly with most DNS software deployed in the real world. You persist in drawing a completely unjustified line between the first error and the other two errors. You claim that allowable administrative action is defined by BIND 9---never mind what RFC 1034 says, and never mind the rest of the installed base. You cycle endlessly between ``BIND 9 is doing the Right Thing'' and ``BIND 9 handles that situation'' and ``that situation is not actually an error,'' attempting to defend each part of the BIND 9 religion by showing how it fits with the other parts. The circularity is pathetic. In situations where there's a difference between the software and the spec---for example, actions that are prohibited by RFC 1034 even though they work in the real world, or vice versa---one can reasonably discuss whether the actions should be considered errors. But the above actions do _not_ work and are _not_ allowed by the spec. If you want to support them in BIND 9, fine, but you have no basis for demanding that the rest of us support them too. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Feb 23 05:05:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05139 for ; Sun, 23 Feb 2003 05:05:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18msvx-000I0b-00 for namedroppers-data@psg.com; Sun, 23 Feb 2003 02:00:33 -0800 Received: from as7-2-2.bn.g.bonet.se ([217.215.21.151] helo=poledra) by psg.com with esmtp (Exim 3.36 #1) id 18msvt-000I0N-00 for namedroppers@ops.ietf.org; Sun, 23 Feb 2003 02:00:29 -0800 Received: from amalthea.8in.net ([192.168.242.14] helo=amalthea) by poledra with asmtp (Exim 3.35 #1 (Debian)) id 18msvp-00048s-00 for ; Sun, 23 Feb 2003 11:00:25 +0100 Message-ID: <06e201c2db22$51164460$0ef2a8c0@amalthea> From: =?iso-8859-1?Q?Kandra_Nyg=E5rds?= To: References: <200302202233.h1KMXO4U009264@drugs.dv.isc.org> <20030221063725.35914.qmail@cr.yp.to> <057201c2d9b6$b2154990$0ef2a8c0@amalthea> <20030221191430.97798.qmail@cr.yp.to> <060001c2d9e5$6be0fbc0$0ef2a8c0@amalthea> <20030221213257.61542.qmail@cr.yp.to> <068501c2da84$d876ae70$0ef2a8c0@amalthea> <20030222174307.40359.qmail@cr.yp.to> Subject: Re: update timing Date: Sun, 23 Feb 2003 10:59:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_OE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit From: "D. J. Bernstein" > If the administrator screws up the timing of changing serial numbers, > the old data can persist _beyond_ the update. You claimed that this was > ``inexcusable'' but have now admitted that it's true for BIND 9 too. The > solution is for the administrator to change serial numbers properly. Whoa, back up a moment. First, I'd like to apologize for not making my argument crystal clear. For some reason, a few people seem to be under several misconceptions regarding my intentions. Let's step back and define a few base parameters: I'm claiming that some software - now existing or future - might experience problems due to implementation errors. These problems may be caused by minor administrative errors, or may be caused by normal everyday routine operations. These problems are caused by the following: Server A updates parent and/or child zones. Server B reaches its refresh threshold for parent zone, checks for an updated SOA serial and transfers the zone via AXFR Server C reaches its refresh threshold for parent zone, checks for an updated SOA serial and transfers the zone via AXFR Server B reaches its refresh threshold for child zone, checks for an updated SOA serial and transfers the zone via AXFR In the above scenario, all updates are performed according to established routines: * Any update of the data in a zone is accompanied by the required update of the SOA serial. * The AXFRs are all initiated by a SOA serial query indicating an updated zone. * The frequency and timing of the queries are controlled by the SOA refresh value. This scenario is for a perfectly ordinary routine operation for real-world configurations - I've personally witnessed configurations where several masters (see Server B) receive their data from a hidden master (Server A) and in turn allow slaves (Server C) to update from them. Now, the problems mentioned above can of course also be caused by administrative errors, but that's beside the point. What I'm trying to point out here is the need to maintain zone integrity for the purposes of AXFR in order to ensure that the zones stay consistent between the servers during normal updates. - Kandra -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Feb 23 16:52:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13478 for ; Sun, 23 Feb 2003 16:52:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18n3gM-000P9P-00 for namedroppers-data@psg.com; Sun, 23 Feb 2003 13:29:10 -0800 Received: from [2001:470:1f00:ffff::5a1] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 18n3gI-000P67-00 for namedroppers@ops.ietf.org; Sun, 23 Feb 2003 13:29:06 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h1NLS74U020848; Mon, 24 Feb 2003 08:28:09 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200302232128.h1NLS74U020848@drugs.dv.isc.org> To: "D. J. Bernstein" Cc: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: update timing errors In-reply-to: Your message of "23 Feb 2003 09:15:13 -0000." <20030223091513.85299.qmail@cr.yp.to> Date: Mon, 24 Feb 2003 08:28:07 +1100 X-Spam-Status: No, hits=0.2 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Mark.Andrews@isc.org writes: > > If you never update the child then it is an *administrative* error. > > Changing the serial number too early is also an administrative error. > Here's a summary of our three examples of administrative errors: > > 1. Failing to update the parent serial number after updating the glue > in all the child servers. As you keep pointing out, this error can > cause problems with BIND 8: the data will be inconsistent until > the serial number is updated. > > 2. Failing to update the parent serial number after updating the glue > in the parent master. This error can cause problems with BIND 9 > (and BIND 8, of course): the data will be inconsistent until the > serial number is updated. > > 3. Failing to update the data in the child master. This error can > cause problems with BIND 9 (and BIND 8, of course): the data will > be inconsistent until the child data is updated (and the serial > numbers handled properly). > > In every case, the administrator is violating RFC 1034 (as you have > admitted), and is creating a configuration that does not work properly > with most DNS software deployed in the real world. > > You persist in drawing a completely unjustified line between the first > error and the other two errors. You claim that allowable administrative > action is defined by BIND 9---never mind what RFC 1034 says, and never > mind the rest of the installed base. You cycle endlessly between ``BIND > 9 is doing the Right Thing'' and ``BIND 9 handles that situation'' and > ``that situation is not actually an error,'' attempting to defend each > part of the BIND 9 religion by showing how it fits with the other parts. > The circularity is pathetic. > > In situations where there's a difference between the software and the > spec---for example, actions that are prohibited by RFC 1034 even though > they work in the real world, or vice versa---one can reasonably discuss > whether the actions should be considered errors. But the above actions > do _not_ work and are _not_ allowed by the spec. If you want to support > them in BIND 9, fine, but you have no basis for demanding that the rest > of us support them too. Changing the content of SECONDARY zones is outside of the actions specified by RFC 1034. In fact RFC 1034 demands a "accurate" copy. You can't have a "accurate" copy if it has been changed. There are no timing issues if you have a "accurate" copy. There is no such thing as changing the serial "too early". It is the errors in BIND 4, BIND 8 and tinydns that introduce timing constraints that are not part of RFC 1034 and only affect servers that are serving both parent and child zones. We have heard from at least three other independent developers that they preserve / preserved the copy of the child zone based on RFC 1034 requirement. Maintaining consistancy between parent and child zones is a administrative responsability. Even with automated assistance the changes are required to be applied to the PRIMARY not to the SECONDARY. BIND 4, BIND 8 and tinydns violate the maintance model as a result of applying changes in the incorrect place directly leading to the situation where all the PRIMARY copies of the zones have the correct information but some of the SECONDARY "copies" don't. There is no technical reason not to preserve the contents of the SECONDARY copies of the zone unaltered. There are no negative effects from doing this. There definitely are negative effects caused by changing the contents of SECONDARY copies. All your complaints are based on your interpretation of RFC 1034. Your interpretation introduces timing issues which even your own software cannot meet without violating the requirement to change the serial number when you change the zone contents. In addition to the pure AXFR issues. IXFR depends upon the contents of the zone not being changed unilaterally on the SECONDARY. Failure to preserve the contents will result in deltas not applying that should. This should result in fallback to AXFR to get a upto date copy of the zone. This will result in a AXFR style IXFR to done stream servers. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Feb 23 18:09:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14735 for ; Sun, 23 Feb 2003 18:09:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18n58L-0004WO-00 for namedroppers-data@psg.com; Sun, 23 Feb 2003 15:02:09 -0800 Received: from [2001:4f8:3:bb:2e0:81ff:fe23:7b5a] (helo=as.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 18n58I-0004T1-00 for namedroppers@ops.ietf.org; Sun, 23 Feb 2003 15:02:06 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 6AA2D379EF8; Sun, 23 Feb 2003 23:01:53 +0000 (GMT) From: Paul Vixie To: Mark.Andrews@isc.org Cc: "D. J. Bernstein" , ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: update timing errors In-Reply-To: Message from Mark.Andrews@isc.org of "Mon, 24 Feb 2003 08:28:07 +1100." <200302232128.h1NLS74U020848@drugs.dv.isc.org> X-Mailer: MH-E 7.2; nmh 1.0.4; GNU Emacs 21.2.1 Date: Sun, 23 Feb 2003 23:01:53 +0000 Message-Id: <20030223230153.6AA2D379EF8@as.vix.com> X-Spam-Status: No, hits=-0.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02, TO_BE_REMOVED_REPLY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk ok mark, that's it. no more replies are warranted. if mr. bernstein still misunderstands zone coherency, then someone who doesn't work for ISC will have to take a turn trying to educate him. we're done. --paul ps. great answer btw. re: > X-Original-To: vixie@vix.com > To: "D. J. Bernstein" > Cc: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org > From: Mark.Andrews@isc.org > Subject: Re: update timing errors > Date: Mon, 24 Feb 2003 08:28:07 +1100 > Sender: owner-namedroppers@ops.ietf.org > > > > Mark.Andrews@isc.org writes: > > > If you never update the child then it is an *administrative* error. > > > > Changing the serial number too early is also an administrative error. > > Here's a summary of our three examples of administrative errors: > > > > 1. Failing to update the parent serial number after updating the glue > > in all the child servers. As you keep pointing out, this error can > > cause problems with BIND 8: the data will be inconsistent until > > the serial number is updated. > > > > 2. Failing to update the parent serial number after updating the glue > > in the parent master. This error can cause problems with BIND 9 > > (and BIND 8, of course): the data will be inconsistent until the > > serial number is updated. > > > > 3. Failing to update the data in the child master. This error can > > cause problems with BIND 9 (and BIND 8, of course): the data will > > be inconsistent until the child data is updated (and the serial > > numbers handled properly). > > > > In every case, the administrator is violating RFC 1034 (as you have > > admitted), and is creating a configuration that does not work properly > > with most DNS software deployed in the real world. > > > > You persist in drawing a completely unjustified line between the first > > error and the other two errors. You claim that allowable administrative > > action is defined by BIND 9---never mind what RFC 1034 says, and never > > mind the rest of the installed base. You cycle endlessly between ``BIND > > 9 is doing the Right Thing'' and ``BIND 9 handles that situation'' and > > ``that situation is not actually an error,'' attempting to defend each > > part of the BIND 9 religion by showing how it fits with the other parts. > > The circularity is pathetic. > > > > In situations where there's a difference between the software and the > > spec---for example, actions that are prohibited by RFC 1034 even though > > they work in the real world, or vice versa---one can reasonably discuss > > whether the actions should be considered errors. But the above actions > > do _not_ work and are _not_ allowed by the spec. If you want to support > > them in BIND 9, fine, but you have no basis for demanding that the rest > > of us support them too. > > Changing the content of SECONDARY zones is outside of the > actions specified by RFC 1034. In fact RFC 1034 demands a > "accurate" copy. You can't have a "accurate" copy if it > has been changed. > > There are no timing issues if you have a "accurate" copy. > > There is no such thing as changing the serial "too early". > > It is the errors in BIND 4, BIND 8 and tinydns that introduce > timing constraints that are not part of RFC 1034 and only > affect servers that are serving both parent and child zones. > > We have heard from at least three other independent developers > that they preserve / preserved the copy of the child zone > based on RFC 1034 requirement. > > Maintaining consistancy between parent and child zones is > a administrative responsability. Even with automated > assistance the changes are required to be applied to the > PRIMARY not to the SECONDARY. BIND 4, BIND 8 and tinydns > violate the maintance model as a result of applying changes > in the incorrect place directly leading to the situation where > all the PRIMARY copies of the zones have the correct information > but some of the SECONDARY "copies" don't. > > There is no technical reason not to preserve the contents of > the SECONDARY copies of the zone unaltered. There are no > negative effects from doing this. There definitely are negative > effects caused by changing the contents of SECONDARY copies. > > All your complaints are based on your interpretation of RFC > 1034. Your interpretation introduces timing issues which > even your own software cannot meet without violating the > requirement to change the serial number when you change the > zone contents. > > In addition to the pure AXFR issues. IXFR depends upon the > contents of the zone not being changed unilaterally on the > SECONDARY. Failure to preserve the contents will result > in deltas not applying that should. This should result in > fallback to AXFR to get a upto date copy of the zone. This > will result in a AXFR style IXFR to done stream servers. > > Mark > > -- > Mark Andrews, Internet Software Consortium > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Feb 23 18:24:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14976 for ; Sun, 23 Feb 2003 18:24:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18n5Ou-0005ZD-00 for namedroppers-data@psg.com; Sun, 23 Feb 2003 15:19:16 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18n5Os-0005Ys-00 for namedroppers@ops.ietf.org; Sun, 23 Feb 2003 15:19:14 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18n5Os-000Bda-00 for namedroppers@ops.ietf.org; Mon, 24 Feb 2003 08:19:14 +0900 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F0193C272@esebe005.ntc.nokia.com> Thread-Topic: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Thread-Index: AcLaZZynvrulm453S7+HDXpNQWfSyQA66Q7Q Subject: RE: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Date: Sun, 23 Feb 2003 18:09:37 +0200 From: To: Cc: , , X-Spam-Status: No, hits=1.6 required=5.0 tests=NO_REAL_NAME,RESENT_TO,SPAM_PHRASE_01_02 version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA14976 [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Hi all! Even though I find standardizing "stateless DNS discovery" in the IPv6 wg very important, I find this DHCPv6 option useful. So I also support moving it forward. Juha Wiljakka -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Feb 23 19:22:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15738 for ; Sun, 23 Feb 2003 19:22:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18n6JY-0009Aw-00 for namedroppers-data@psg.com; Sun, 23 Feb 2003 16:17:48 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #1) id 18n6JU-0009Ak-00 for namedroppers@ops.ietf.org; Sun, 23 Feb 2003 16:17:44 -0800 Received: (qmail 72006 invoked by uid 1016); 24 Feb 2003 00:18:09 -0000 Date: 24 Feb 2003 00:18:09 -0000 Message-ID: <20030224001809.72005.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: update timing errors References: <20030223091513.85299.qmail@cr.yp.to> <200302232128.h1NLS74U020848@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mark.Andrews@isc.org writes: > Changing the content of SECONDARY zones is outside of the > actions specified by RFC 1034. Fact: Slaves _must_ discard records in some situations. A detailed example appears in http://cr.yp.to/djbdns/axfr-notes.html#poison. (There are many other counterexamples to your ``no reason'' claim.) Fact: Slaves _do_ discard records in many situations. You claim that this is ``wrong'' solely because it can break certain configurations. You have admitted that RFC 1034 clearly prohibits those configurations. > It is the errors in BIND 4, BIND 8 and tinydns that introduce > timing constraints that are not part of RFC 1034 Fact: As you have already admitted, RFC 1034 _does_ impose these timing constraints. As you have already admitted, RFC 1034 prohibits even the slightest configuration inconsistency. In previous messages, you were complaining about how severe the RFC 1034 consistency requirement is! Fact: As above, your sole basis for calling the widespread BIND-8-etc. behavior an ``error'' is that it doesn't work with your broken configurations. Your sole basis for claiming that the configurations aren't broken is _some_ DNS servers support them. Fact: These broken configurations are going to continue to fail for the foreseeable future. (As http://cr.yp.to/surveys/dns1.html shows, BIND 8 is more widely used than BIND 9.) It is essential for interoperability that these broken configurations continue to be prohibited. Demanding support for them would impose costs on at least two independent implementations, without providing any benefits for the users. Fact: Making the configurations work is a simple matter of updating the parent---most importantly, the parent serial number---after (or at the same time as) all the child servers are updated. This rule is easy for administrators to follow. > All your complaints are based on your interpretation of RFC 1034. Fact: There are no relevant disputes about the interpretation of RFC 1034. When I pointed to the sections of RFC 1034 that you are violating, you admitted your violations. > change the serial number when you change the zone contents Fact: That's part of what RFC 1034 requires. However, that's not even close to a complete description of an RFC-1034-compliant glue-update procedure. More importantly, it's not a complete description of a glue-update procedure that works in practice. > IXFR depends upon Fact: IXFR is an optional protocol extension. It is entirely IXFR's responsibility to maintain compatibility with the preexisting, unextended, protocol. It is not the responsibility of the installed base to change for the sake of new protocol options. Fact: When a protocol extension causes failures with most of the software deployed on the Internet, you can't safely use the extension without waiting for a massive upgrade. Users are much happier with an extension that, at comparable cost, avoids the failures and provides the same benefits immediately. I have explained to you how to do this in the case of IXFR. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Feb 23 19:31:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15879 for ; Sun, 23 Feb 2003 19:31:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18n6TR-0009qB-00 for namedroppers-data@psg.com; Sun, 23 Feb 2003 16:28:01 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #1) id 18n6TO-0009p4-00 for namedroppers@ops.ietf.org; Sun, 23 Feb 2003 16:27:58 -0800 Received: (qmail 74465 invoked by uid 1016); 24 Feb 2003 00:28:24 -0000 Date: 24 Feb 2003 00:28:24 -0000 Message-ID: <20030224002824.74464.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: update timing References: <200302202233.h1KMXO4U009264@drugs.dv.isc.org> <20030221063725.35914.qmail@cr.yp.to> <057201c2d9b6$b2154990$0ef2a8c0@amalthea> <20030221191430.97798.qmail@cr.yp.to> <060001c2d9e5$6be0fbc0$0ef2a8c0@amalthea> <20030221213257.61542.qmail@cr.yp.to> <068501c2da84$d876ae70$0ef2a8c0@amalthea> <20030222174307.40359.qmail@cr.yp.to> <06e201c2db22$51164460$0ef2a8c0@amalthea> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Any update of the data in a zone is accompanied by the required > update of the SOA serial. That sentence is, obviously, not a complete statement of a glue-update procedure. See my 21 Feb 2003 06:27:51 -0000 message for a complete list of the things you have to do. Do you have some questions about that procedure? ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Feb 23 20:40:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17186 for ; Sun, 23 Feb 2003 20:40:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18n7Xp-000E7L-00 for namedroppers-data@psg.com; Sun, 23 Feb 2003 17:36:37 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18n7Xn-000E79-00 for namedroppers@ops.ietf.org; Sun, 23 Feb 2003 17:36:36 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18n7Xm-000B8w-00 for namedroppers@ops.ietf.org; Mon, 24 Feb 2003 10:36:34 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200302240130.UAA39348@ccr.org> To: djb@cr.yp.to Cc: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: your ongoing diatribe Date: Sun, 23 Feb 2003 20:30:19 -0500 From: "Mike O'Dell" X-Spam-Status: No, hits=0.6 required=5.0 tests=RESENT_TO,SPAM_PHRASE_02_03 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Excuse me, sir, but I've enjoyed quite enough of your behavior Your lack of genuine operating experience is transparent. don't quote adoption numbers for your software - i'm talking about *you* having direct experience running very large name server systems with many tens of thousands of zones, both primary and secondary, or equivalently, working hand-in-glove with those who have Your failure (nee unwillingness) to appreciate the large-scale consequences of your mathematical fantasy land is simply stunning The fact the Real World doesn't care about the constraints you've constructed to make your world view viable doesn't seem to faze you In particular, you don't appreciate the necessity of reasonable operational behavior in the presence of multiple administrative domains which cannot perform with perfect coordination Then you have the audacity to describe those with a deep understanding of what it takes to make the Big-I Internet work at very large scale as "pathetic". Frankly, sir, sit down. You have embarrassed yourself in this forum quite enough and have impeded the efforts of those working mightily to move things along in a constructive manner. You seem to imagine this is some kind of debating society where you gain points by taking yet another turn at the microphone when your opponents have been worn down by arguing with a refractory surface. It isn't a debating society, "rough consensus" goes not require unanimity and there is serious work to get done, so I ask again, Sir, please sit down. I now return you to the previous screed, -mo -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Feb 23 21:49:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18900 for ; Sun, 23 Feb 2003 21:49:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18n8WX-000GJW-00 for namedroppers-data@psg.com; Sun, 23 Feb 2003 18:39:21 -0800 Received: from gusto.araneus.fi ([204.152.186.164]) by psg.com with esmtp (Exim 3.36 #1) id 18n8WT-000GJH-00 for namedroppers@ops.ietf.org; Sun, 23 Feb 2003 18:39:17 -0800 Received: from guava.araneus.fi (adsl-63-197-0-204.dsl.snfc21.pacbell.net [63.197.0.204]) by gusto.araneus.fi (8.11.6/8.11.6) with ESMTP id h1O2dCZ18356; Sun, 23 Feb 2003 18:39:13 -0800 (PST) Received: (from gson@localhost) by guava.araneus.fi (8.11.6/8.11.6) id h1O2dAh00524; Sun, 23 Feb 2003 18:39:10 -0800 (PST) Date: Sun, 23 Feb 2003 18:39:10 -0800 (PST) Message-Id: <200302240239.h1O2dAh00524@guava.araneus.fi> To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org, iesg@ietf.org Subject: Poison in a zone In-Reply-To: <20030224001809.72005.qmail@cr.yp.to> References: <20030223091513.85299.qmail@cr.yp.to> <200302232128.h1NLS74U020848@drugs.dv.isc.org> <20030224001809.72005.qmail@cr.yp.to> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=0.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_02_03 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk D. J. Bernstein writes: > Fact: Slaves _must_ discard records in some situations. This claim has no basis in the standards. > A detailed example appears in http://cr.yp.to/djbdns/axfr-notes.html#poison. This is an interesting example and worth discussing in its own right; I have changed the subject line in the hope that this discussion can be kept somewhat separate from the usual flamage. Quoting your example: > Suppose that an ISP is simultaneously a third-party DNS server for > .edu and a third-party DNS server for princeton.edu. > > Suppose the ISP pulls the princeton.edu zone from a Princeton AXFR > server, and receives the data > > haven.princeton.edu NS serv1.net.yale.edu > serv1.net.yale.edu A 128.112.128.15 > > from the AXFR server. The point of the following analysis is that the > ISP must discard the yale.edu information. > > An innocent user's cache has the legitimate record > > yale.edu NS serv1.net.yale.edu > > saved. The user asks for the address of www.haven.princeton.edu. The > cache contacts the root server, learns that the ISP is a .edu server, > contacts the ISP, and receives the same information > > haven.princeton.edu NS serv1.net.yale.edu > serv1.net.yale.edu A 128.112.128.15 > > that the ISP obtained from the Princeton server. Because the ISP is a > .edu server, the cache trusts and saves the serv1.net.yale.edu > information. The user now asks for the address of www.yale.edu. The > cache knows yale.edu NS serv1.net.yale.edu and serv1.net.yale.edu A > 128.112.128.15, so it contacts 128.112.128.15 to obtain the address of > www.yale.edu. In short, Princeton has been given control over the Yale > web server. I agree that this is a real problem that ought to be solved. However, there are several ways of solving it, and I do not think your solution (making slaves discard certain records in zone transfers) is the best solution. For one thing, it does not solve the case where the ISP is the *master* for the domains in case. It is an unfortunate fact that the existing DNS standards do not adequately address the issue of cache poisoning. They do not even address the simpler cases that can arise even when all domains are hosted on distinct servers, much less the more subtle case you describe above. They do not even recommend, much less mandate, the simple but effective resolver-side anti-spoofing measures that BIND 8, BIND 9, and dnscache all currently employ and that you are taking for granted in your example above when you say "because the ISP is a .edu server, the cache trusts and saves the serv1.net.yale.edu information. My own preference would be for solving this problem on the resolver side, by using more discriminate anti-spoofing rules than the ones BIND 8/9 and djbdns currently use. Another possibility is to make the servers refrain from giving out the glue in responses in situations like the above even though it is stored and preserved for purposes of outgoing zone transfers. In any case, none of the possible solutions are standardized at this time, and until they are, no one is required to use any particular solution, and that includes your solution of "discarding records". > When I first mentioned this type of attack, the BIND 9 implementors > claimed that it was safe for the ISP to provide the serv1.net.yale.edu > information as glue for haven.princeton.edu. There was a discussion where I said it was safe to provide cross-zone glue, but in that discussion no mention was made of the server also being authoritative for "edu", which makes a subtle but important difference. -- 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. archive: From owner-namedroppers@ops.ietf.org Sun Feb 23 22:27:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19450 for ; Sun, 23 Feb 2003 22:27:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18n9BC-000Hs3-00 for namedroppers-data@psg.com; Sun, 23 Feb 2003 19:21:22 -0800 Received: from pigeon.verisign.com ([65.205.251.71]) by psg.com with esmtp (Exim 3.36 #1) id 18n9B9-000Hrr-00 for namedroppers@ops.ietf.org; Sun, 23 Feb 2003 19:21:19 -0800 Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53] (may be forged)) by pigeon.verisign.com (8.12.1/) with ESMTP id h1O3J6iq002773; Sun, 23 Feb 2003 19:19:06 -0800 (PST) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id ; Sun, 23 Feb 2003 19:21:13 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Mike O'Dell'" Cc: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: RE: your ongoing diatribe Date: Sun, 23 Feb 2003 19:21:08 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_0017_01C2DB89.DD032AD0"; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=1.8 required=5.0 tests=EXCHANGE_SERVER,MAY_BE_FORGED,MISSING_OUTLOOK_NAME, SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0017_01C2DB89.DD032AD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I think that the underlying problem here is lack of respect. Frankly I don't much care about the technical issues someone is putting forward when they are behaving like a shouting head from a sunday talk show. While Prof Bernsteins posts and general behaviour shows a total lack of respect for others I don't think the problem is unique to members of the crazy gang. One of the issues I have with the IETF generally is that the feedback I frequently get back on ideas is 'if you understood the problem you would know why your proposal is stupid', followed by a blank refusal to cite specifics. This is an argument strategy that will be familliar to the readers of Joseph Heller. I am not talking about random bar room conversations here, I am talking about longstanding IESG and IAB members. If I get treated that way after ten years of involvement with network protocols, how does the graduate student who comes to her first IETF get treated? The point is that this type of behaviour is comming from the top down. Phill ------=_NextPart_000_0017_01C2DB89.DD032AD0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1 3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1 81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK +gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/ H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDIyNDAz MjEwOFowIwYJKoZIhvcNAQkEMRYEFEZzUgSyUW3l24/56cNkpwdOmR0EMFgGCSqGSIb3DQEJDzFL MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO rwvJMA0GCSqGSIb3DQEBAQUABIGAZCjUZMteMtGRwAhgErYlODCmnXIo6tJ0VrqyHnZaKwN5b1ju Po2wFmMMjAWcWqbmdDGWzQWX3NtAkl8jAVwnMC56ZCuXkomrni32CvkfCt3HciMP9LhQIXdqkGnN xSt2PZj+kS9srQdKD4rnBeNMlVh2JnWSZVtUU+dQ9dwOizsAAAAAAAA= ------=_NextPart_000_0017_01C2DB89.DD032AD0-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Feb 23 23:03:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20300 for ; Sun, 23 Feb 2003 23:03:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18n9mZ-000JFK-00 for namedroppers-data@psg.com; Sun, 23 Feb 2003 19:59:59 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #1) id 18n9mV-000JEj-00 for namedroppers@ops.ietf.org; Sun, 23 Feb 2003 19:59:55 -0800 Received: (qmail 47336 invoked by uid 1016); 24 Feb 2003 04:00:21 -0000 Date: 24 Feb 2003 04:00:21 -0000 Message-ID: <20030224040021.47335.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: Poison in a zone References: <20030223091513.85299.qmail@cr.yp.to> <200302232128.h1NLS74U020848@drugs.dv.isc.org> <20030224001809.72005.qmail@cr.yp.to> <200302240239.h1O2dAh00524@guava.araneus.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=0.0 required=5.0 tests=REFERENCES,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Andreas Gustafsson writes: > D. J. Bernstein writes: > > Fact: Slaves _must_ discard records in some situations. > This claim has no basis in the standards. Anti-poisoning rules are required for security. I'm not going to bother addressing the irrelevant question of whether the de-facto standards in DNS security can be deduced from the de-jure standards. You have some anti-poisoning rules in BIND 9 (and BIND 8). We all know that they're necessary: some records have to be discarded. Consequently, any claim such as ``all records must be preserved'' is obviously wrong. When religious rhetoric crashes into security, we all know who wins. Yes or no: Does the specific attack described on my web page work against BIND 9? I'll give you three days to issue a security release before I send a message to bugtraq. Or are you using the defense stated on my web page, discarding records on the client side of an AXFR? > where the ISP is the *master* for the domains Different situation, but same solution: discard all records outside the source's bailiwick. End of problem. > more discriminate anti-spoofing rules Namely? Exactly what would you suggest in place of the de-facto-standard bailiwick rule? (You realize, of course, that deploying a new rule would take time.) ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 24 11:10:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17747 for ; Mon, 24 Feb 2003 11:10:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18nKw7-000Kmg-00 for namedroppers-data@psg.com; Mon, 24 Feb 2003 07:54:35 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #1) id 18nKw1-000KmQ-00; Mon, 24 Feb 2003 07:54:29 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA12515; Mon, 24 Feb 2003 08:54:27 -0700 (MST) Received: from localhost (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h1OFsQP25055; Mon, 24 Feb 2003 16:54:26 +0100 (MET) Date: Mon, 24 Feb 2003 16:50:39 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: draft-ietf-dnsext-unknown-rrs-04.txt To: Andreas Gustafsson Cc: Erik Nordmark , Andreas Gustafsson , ogud@ogud.com, randy@psg.com, namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" <200302212235.h1LMZXi18563@guava.araneus.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > And it is useful to implementors to point out that no RRs that have > > been defined after RFC 2931 and this RFC contain embedded domain names". > > (There aren't any RR definitions in the IETF last call, IESG, RFC-editor > > pipeline right now and if any appear I'll make sure they get this right.) > > Did you mean "after RFC2931 but before this RFC"? Yes. Upleveling. Since you seem to understand my concern but disagree with every textual proposal I suggest to try to make things more clear, why don't you suggest some clarifications to the text that make things more clear? 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. archive: From owner-namedroppers@ops.ietf.org Mon Feb 24 12:56:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20659 for ; Mon, 24 Feb 2003 12:56:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18nMdI-0000XQ-00 for namedroppers-data@psg.com; Mon, 24 Feb 2003 09:43:16 -0800 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by psg.com with esmtp (Exim 3.36 #1) id 18nMdF-0000XE-00 for namedroppers@ops.ietf.org; Mon, 24 Feb 2003 09:43:13 -0800 Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1OHh8Nh024277; Mon, 24 Feb 2003 12:43:09 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-251.cisco.com [161.44.149.251]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA23894; Mon, 24 Feb 2003 12:43:08 -0500 (EST) Message-Id: <4.3.2.7.2.20030224123058.03f484a8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Feb 2003 12:43:06 -0500 To: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org From: Ralph Droms Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt In-Reply-To: <1045912992.27180.14.camel@devil> References: <4.3.2.7.2.20030220135524.03e6d548@funnel.cisco.com> <4.3.2.7.2.20030220135524.03e6d548@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-0.5 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Summary of discussion during WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Pekka Savola, Tony Lindstrom, Bernie Volz and Peter Koch all responded with editorial suggestions. These suggestions have been incorporated into the draft and will appear in next published rev. Peter Koch and Rob Austein commented on the "Security Considerations"; specifically, whether DNSSEC can prevent problems caused by a search list supplied as part of an attack by a DHCP server. Based on Rob's argument (and assuming I understood Rob correctly) that DNSSEC can guarantee that a host can trust the replies it receives, but DNSSEC can't guarantee that the host has asked the right question based on its search list, I'm inclined to leave the text in question unchanged. Alain Durand raised the issue of supplying both IPv4 and IPv6 addresses for DNS resolvers in the DNS server option. I judged the rough consensus in the responses to be that restricting the DNS server option to return only IPv6 addresses is acceptable. - Ralph -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 24 14:10:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23023 for ; Mon, 24 Feb 2003 14:10:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18nNtC-00059V-00 for namedroppers-data@psg.com; Mon, 24 Feb 2003 11:03:46 -0800 Received: from nat.alvestrand.no ([217.13.28.204] helo=eikenes.alvestrand.no) by psg.com with esmtp (Exim 3.36 #1) id 18nNt4-00059G-00 for namedroppers@ops.ietf.org; Mon, 24 Feb 2003 11:03:38 -0800 Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5B346622BB; Mon, 24 Feb 2003 20:03:35 +0100 (CET) Date: Mon, 24 Feb 2003 20:03:35 +0100 From: Harald Tveit Alvestrand To: "Hallam-Baker, Phillip" Cc: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: Respect for others (RE: your ongoing diatribe) Message-ID: <2151130000.1046113415@askvoll.hjemme.alvestrand.no> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline X-Spam-Status: No, hits=-1.0 required=5.0 tests=IN_REP_TO,MIME_LONG_LINE_QP,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA23023 Since Phil claims that this behaviour comes "from the top down", and it's hard to find anyone who can be "the top" above me.... I find the behaviour Phil Hallam-Baker describes below unacceptable. At times, a quickly-tossed-off "I know this is false, but I don't have the time to show you the proof" is acceptable as a placeholder until time can be made; at times, an "I have explained this problem to you twentyseven times, and you still don't agree with me" is nothing more than the simple truth, and we have to recognize the underlying disagreement. But in general, asking the IETF to accept consensus on an unsubstantiated objection is no more acceptable than asking the IETF to accept consensus on an undocumented proposal. Harald --On sřndag, februar 23, 2003 19:21:08 -0800 "Hallam-Baker, Phillip" wrote: > I think that the underlying problem here is lack of respect. Frankly I > don't much care about the technical issues someone is putting forward > when they are behaving like a shouting head from a sunday talk show. > > While Prof Bernsteins posts and general behaviour shows a total lack of > respect for others I don't think the problem is unique to members of the > crazy gang. > > One of the issues I have with the IETF generally is that the feedback I > frequently get back on ideas is 'if you understood the problem you would > know why your proposal is stupid', followed by a blank refusal to cite > specifics. This is an argument strategy that will be familliar to the > readers of Joseph Heller. > > I am not talking about random bar room conversations here, I am talking > about longstanding IESG and IAB members. If I get treated that way after > ten years of involvement with network protocols, how does the graduate > student who comes to her first IETF get treated? > > The point is that this type of behaviour is comming from the top down. > > > Phill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 24 14:40:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23995 for ; Mon, 24 Feb 2003 14:40:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18nONh-0006s4-00 for namedroppers-data@psg.com; Mon, 24 Feb 2003 11:35:17 -0800 Received: from imr1.ericy.com ([208.237.135.240]) by psg.com with esmtp (Exim 3.36 #1) id 18nONa-0006ro-00 for namedroppers@ops.ietf.org; Mon, 24 Feb 2003 11:35:10 -0800 Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id h1OJZ7d15014; Mon, 24 Feb 2003 13:35:08 -0600 (CST) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id h1OJZ7Z11540; Mon, 24 Feb 2003 13:35:08 -0600 (CST) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Mon, 24 Feb 2003 13:35:07 -0600 Message-ID: From: "Bernie Volz (EUD)" To: "'Ralph Droms'" , dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: RE: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconf ig-02.txt Date: Mon, 24 Feb 2003 13:33:27 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2DC3B.9AC3CE60" X-Spam-Status: No, hits=0.6 required=5.0 tests=ASCII_FORM_ENTRY,EXCHANGE_SERVER,MAILTO_LINK, MIME_NULL_BLOCK,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2DC3B.9AC3CE60 Content-Type: text/plain; charset="iso-8859-1" Isn't it possible for the DHCPv6 server to return IPv4 addresses as per RFC 2373, section 2.5.4 (IPv6 Addresses with Embedded IPv4 Addresses), in particular: A second type of IPv6 address which holds an embedded IPv4 address is also defined. This address is used to represent the addresses of IPv4-only nodes (those that *do not* support IPv6) as IPv6 addresses. This type of address is termed an "IPv4-mapped IPv6 address" and has the format: | 80 bits | 16 | 32 bits | +--------------------------------------+--------------------------+ |0000..............................0000|FFFF| IPv4 address | +--------------------------------------+----+---------------------+ - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Monday, February 24, 2003 12:43 PM To: dhcwg@ietf.org; ipng@sunroof.eng.sun.com; namedroppers@ops.ietf.org Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Summary of discussion during WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Pekka Savola, Tony Lindstrom, Bernie Volz and Peter Koch all responded with editorial suggestions. These suggestions have been incorporated into the draft and will appear in next published rev. Peter Koch and Rob Austein commented on the "Security Considerations"; specifically, whether DNSSEC can prevent problems caused by a search list supplied as part of an attack by a DHCP server. Based on Rob's argument (and assuming I understood Rob correctly) that DNSSEC can guarantee that a host can trust the replies it receives, but DNSSEC can't guarantee that the host has asked the right question based on its search list, I'm inclined to leave the text in question unchanged. Alain Durand raised the issue of supplying both IPv4 and IPv6 addresses for DNS resolvers in the DNS server option. I judged the rough consensus in the responses to be that restricting the DNS server option to return only IPv6 addresses is acceptable. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C2DC3B.9AC3CE60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Re: WG last call on = draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt

Isn't it possible for the DHCPv6 server to return = IPv4 addresses as per
RFC 2373, section 2.5.4 (IPv6 Addresses with = Embedded IPv4 Addresses),
in particular:

   A second type of IPv6 address which = holds an embedded IPv4 address is
   also defined.  This address is = used to represent the addresses of
   IPv4-only nodes (those that *do not* = support IPv6) as IPv6 addresses.
   This type of address is termed an = "IPv4-mapped IPv6 address" and has
   the format:

   = |            = ;    80 = bits           &n= bsp;   | 16 |      32 = bits        |
   = +--------------------------------------+--------------------------+
   = |0000..............................0000|FFFF|    IPv4 = address     |
   = +--------------------------------------+----+---------------------+

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Monday, February 24, 2003 12:43 PM
To: dhcwg@ietf.org; ipng@sunroof.eng.sun.com; = namedroppers@ops.ietf.org
Subject: Re: [dhcwg] Re: WG last call on
draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt


Summary of discussion during WG last call on
draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt

Pekka Savola, Tony Lindstrom, Bernie Volz and Peter = Koch all responded with
editorial suggestions.  These suggestions have = been incorporated into the
draft and will appear in next published rev.

Peter Koch and Rob Austein commented on the = "Security Considerations";
specifically, whether DNSSEC can prevent problems = caused by a search list
supplied as part of an attack by a DHCP = server.  Based on Rob's argument
(and assuming I understood Rob correctly) that = DNSSEC can guarantee that a
host can trust the replies it receives, but DNSSEC = can't guarantee that the
host has asked the right question based on its = search list, I'm inclined to
leave the text in question unchanged.

Alain Durand raised the issue of supplying both IPv4 = and IPv6 addresses for
DNS resolvers in the DNS server option.  I = judged the rough consensus in
the responses to be that restricting the DNS server = option to return only
IPv6 addresses is acceptable.

- Ralph


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C2DC3B.9AC3CE60-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 24 17:39:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29052 for ; Mon, 24 Feb 2003 17:39:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18nQvb-000HAd-00 for namedroppers-data@psg.com; Mon, 24 Feb 2003 14:18:27 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #1) id 18nQv4-000H9J-00 for namedroppers@ops.ietf.org; Mon, 24 Feb 2003 14:17:55 -0800 Received: (qmail 93063 invoked by uid 1016); 24 Feb 2003 22:18:18 -0000 Date: 24 Feb 2003 22:18:18 -0000 Message-ID: <20030224221818.93062.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: your ongoing diatribe References: <200302240130.UAA39348@ccr.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=0.0 required=5.0 tests=REFERENCES,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mike O'Dell writes: > cannot perform with perfect coordination RFC 1034 requires perfect coordination. However, I've been pointing out that a much looser glue-update procedure works just fine: (1) Change the data in the child zone on the child master. (2) Once #1 is done: Change the child serial number. (3) Once #2 is done: Copy the new data to all the child slaves, for example by waiting for the slaves to pull the data through AXFR. (4) Change the data in the parent zone on the parent master. (5) Once #3 and #4 are done: Change the parent serial number. (6) Once #5 is done: Copy the new data to all the parent slaves, for example by waiting for the slaves to pull the data through AXFR. This guarantees a successful update with all of today's DNS software. For example, the update will succeed if the child administrator does #1, #2, #3 and then tells the parent administrator to do #4, #5, #6. Easy! If you violate the timing constraints---for example, if you change the parent serial number too early---then the update may fail. For example, breaking the #3<=#5 rule can cause failures with BIND 8, and breaking the #4<=#5 rule can cause failures with BIND 8 or BIND 9. Solution: Don't break the rules! The BIND company has been drawing a completely unjustified line between the #3<=#5 rule and the other rules. They're demanding that we go to a lot of effort to allow #5<#3 because BIND 9 does. How is this supposed to benefit the administrators? Even if we started on this massive upgrade, #5<#3 would remain unsafe for the foreseeable future. Not only is there a huge BIND 8 installed base, but many OS distributors are deliberately avoiding BIND 9. So administrators would have to continue following the #3<=#5 rule for the foreseeable future. The BIND company is simply trying to make extra work for competing DNS implementations. There's a long history of the BIND company introducing interoperability problems: their multiple-answers AXFR format, for example, and their failure to handle NODATA responses to IXFR. They try to blame the other side for these failures, even when BIND is clearly violating RFC 1034 (as in the IXFR case) and could easily have avoided the failures (as in the multiple-answers and IXFR cases). They use these failures to market the latest version of BIND: if you change to BIND on the other side, everything will work again! This is reprehensible. > don't quote adoption numbers for your software Why not? You talk about ``very large name server systems'' and ``large-scale consequences'' and ``the Real World'' and ``the Big-I Internet,'' and you expect me not to mention that tinydns is being used by seven of the largest .com hosting companies on the Internet? ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 24 18:48:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00619 for ; Mon, 24 Feb 2003 18:48:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18nSE0-000MVE-00 for namedroppers-data@psg.com; Mon, 24 Feb 2003 15:41:32 -0800 Received: from gusto.araneus.fi ([204.152.186.164]) by psg.com with esmtp (Exim 3.36 #1) id 18nSDU-000MRN-00 for namedroppers@ops.ietf.org; Mon, 24 Feb 2003 15:41:00 -0800 Received: from guava.araneus.fi (adsl-63-197-0-204.dsl.snfc21.pacbell.net [63.197.0.204]) by gusto.araneus.fi (8.11.6/8.11.6) with ESMTP id h1ONeuZ21831; Mon, 24 Feb 2003 15:40:56 -0800 (PST) Received: (from gson@localhost) by guava.araneus.fi (8.11.6/8.11.6) id h1ONeur00731; Mon, 24 Feb 2003 15:40:56 -0800 (PST) Date: Mon, 24 Feb 2003 15:40:56 -0800 (PST) Message-Id: <200302242340.h1ONeur00731@guava.araneus.fi> To: "D. J. Bernstein" Cc: iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: Poison in a zone In-Reply-To: <20030224040021.47335.qmail@cr.yp.to> References: <20030223091513.85299.qmail@cr.yp.to> <200302232128.h1NLS74U020848@drugs.dv.isc.org> <20030224001809.72005.qmail@cr.yp.to> <200302240239.h1O2dAh00524@guava.araneus.fi> <20030224040021.47335.qmail@cr.yp.to> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=0.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk D. J. Bernstein writes: > Yes or no: Does the specific attack described on my web page work > against BIND 9? It does not. BIND 9 is currently incapable of storing out-of-domain glue records (i.e., records whose owner name is not a subdomain of the zone apex), whether it is acting as a primary or a secondary. Therefore, it will discard such records whether they are loaded from a master file or received as part of a zone transfer. This might be considered either a security feature or a bug depending on your point of view. > > where the ISP is the *master* for the domains > > Different situation, but same solution: discard all records outside the > source's bailiwick. End of problem. Yes, requiring all authoritative servers (masters and slaves) to discard out-of-domain glue would solve the problem you described. If we do this, slaves to conformant masters will never actually discard any records because anything that the slave would discard has already been discarded by the master, and the integrity of the zone will be preserved as required in axfr-clarify section 4. > > more discriminate anti-spoofing rules > > Namely? Exactly what would you suggest in place of the de-facto-standard > bailiwick rule? What Masataka Ohta suggested in August 2001: Ohta> I have been suggesting that these records be put in a referral-local Ohta> cache content of which is not used for usual A query nor glue A of Ohta> other referral points. -- 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. archive: From owner-namedroppers@ops.ietf.org Mon Feb 24 19:51:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01772 for ; Mon, 24 Feb 2003 19:51:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18nTFF-0000gk-00 for namedroppers-data@psg.com; Mon, 24 Feb 2003 16:46:53 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18nTFD-0000gX-00 for namedroppers@ops.ietf.org; Mon, 24 Feb 2003 16:46:51 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18nTFC-000FFG-00 for namedroppers@ops.ietf.org; Tue, 25 Feb 2003 09:46:50 +0900 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Mon, 24 Feb 2003 14:46:58 -0500 (EST) From: Edward Warnicke To: namedroppers@ops.ietf.org Subject: Request for review of DNS related draft X-Spam-Status: No, hits=0.8 required=5.0 tests=RESENT_TO,SPAM_PHRASE_05_08,USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] I have published a draft defining a method for using DNS given an IP address to resolve the subnet that contains that IP address, the netmask of that network, and the gateway(s) on that network. It is very similar in purpose the RFC 1101, but allows for variable length subnets, and the delegation of zones on non-octet boundaries. The draft is available here: http://www.ietf.org/internet-drafts/draft-warnicke-network-dns-resolution-00.txt My intention is to pursue having this published as an informational RFC. I would very much appreciate any comments or criticism of the draft. Thank you for your time, Ed Warnicke -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 24 19:52:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01796 for ; Mon, 24 Feb 2003 19:52:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18nTHG-0000mX-00 for namedroppers-data@psg.com; Mon, 24 Feb 2003 16:48:58 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18nTHE-0000mK-00 for namedroppers@ops.ietf.org; Mon, 24 Feb 2003 16:48:56 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18nTHD-000FH0-00 for namedroppers@ops.ietf.org; Tue, 25 Feb 2003 09:48:55 +0900 In-Reply-To: <2151130000.1046113415@askvoll.hjemme.alvestrand.no> Message-ID: References: <2151130000.1046113415@askvoll.hjemme.alvestrand.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Mon, 24 Feb 2003 20:28:32 +0000 (GMT) From: Lloyd Wood To: Harald Tveit Alvestrand cc: "Hallam-Baker, Phillip" , "" , "" , "" Subject: Re: Respect for others (RE: your ongoing diatribe) X-Spam-Status: No, hits=-3.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,RESENT_TO, SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] On Mon, 24 Feb 2003, Harald Tveit Alvestrand wrote: > Since Phil claims that this behaviour comes "from the top down", and it's > hard to find anyone who can be "the top" above me.... you're admin of namedroppers now? L. and the longest-serving member of the IESG is...? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 24 19:55:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01821 for ; Mon, 24 Feb 2003 19:55:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18nTJ3-0000vN-00 for namedroppers-data@psg.com; Mon, 24 Feb 2003 16:50:49 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #1) id 18nTIX-0000uo-00 for namedroppers@ops.ietf.org; Mon, 24 Feb 2003 16:50:17 -0800 Received: (qmail 72048 invoked by uid 1016); 25 Feb 2003 00:50:42 -0000 Date: 25 Feb 2003 00:50:42 -0000 Message-ID: <20030225005042.72047.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: ietf@ietf.org, iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: Poison in a zone References: <20030223091513.85299.qmail@cr.yp.to> <200302232128.h1NLS74U020848@drugs.dv.isc.org> <20030224001809.72005.qmail@cr.yp.to> <200302240239.h1O2dAh00524@guava.araneus.fi> <20030224040021.47335.qmail@cr.yp.to> <200302242340.h1ONeur00731@guava.araneus.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=0.3 required=5.0 tests=REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk A moment ago we were being told how vitally important it was for AXFR clients to preserve all records received under all circumstances: * ``An ACURATE [sic] copy of the zone is ESSENTIAL''; * ``A modified zone is NOT a [sic] ACURATE [sic] copy. It's not even a copy. It is a derived work''; * ``IXFR depends upon the contents of the zone not being changed unilaterally on the SECONDARY''; * ``Bernstein still misunderstands zone coherency''; etc. This rhetoric is supposed to convince you that the majority of AXFR clients (BIND 8 et al.) are doing something wrong by discarding parent glue records when they have the authoritative child records. But now Gustafsson admits that the BIND 9 AXFR client doesn't follow the ``zone coherency'' religion. It deliberately discards some kinds of records! It isn't making a perfect copy of the zone! It's breaking IXFR! Here's the quote: ``BIND 9 ... will discard [these] records whether they are loaded from a master file or received as part of a zone transfer.'' To summarize: Not only is the BIND company (1) fraudulently labelling its religion as a ``clarification'' and (2) fraudulently claiming ``consensus'' on the religion over the objections of several people, but it is also (3) deliberately disobeying its own commandments. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 24 23:57:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06238 for ; Mon, 24 Feb 2003 23:57:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18nX3P-000HKu-00 for namedroppers-data@psg.com; Mon, 24 Feb 2003 20:50:55 -0800 Received: from gusto.araneus.fi ([204.152.186.164]) by psg.com with esmtp (Exim 3.36 #1) id 18nX2t-000HHI-00 for namedroppers@ops.ietf.org; Mon, 24 Feb 2003 20:50:23 -0800 Received: from guava.araneus.fi (adsl-63-197-0-204.dsl.snfc21.pacbell.net [63.197.0.204]) by gusto.araneus.fi (8.11.6/8.11.6) with ESMTP id h1P4oIZ22790; Mon, 24 Feb 2003 20:50:18 -0800 (PST) Received: (from gson@localhost) by guava.araneus.fi (8.11.6/8.11.6) id h1P4oIW00975; Mon, 24 Feb 2003 20:50:18 -0800 (PST) Date: Mon, 24 Feb 2003 20:50:18 -0800 (PST) Message-Id: <200302250450.h1P4oIW00975@guava.araneus.fi> To: "D. J. Bernstein" Cc: iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: Poison in a zone In-Reply-To: <20030225005042.72047.qmail@cr.yp.to> References: <20030223091513.85299.qmail@cr.yp.to> <200302232128.h1NLS74U020848@drugs.dv.isc.org> <20030224001809.72005.qmail@cr.yp.to> <200302240239.h1O2dAh00524@guava.araneus.fi> <20030224040021.47335.qmail@cr.yp.to> <200302242340.h1ONeur00731@guava.araneus.fi> <20030225005042.72047.qmail@cr.yp.to> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=0.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk D. J. Bernstein writes: > But now Gustafsson admits that the BIND 9 AXFR client doesn't follow > the ``zone coherency'' religion. It deliberately discards some kinds of > records! It isn't making a perfect copy of the zone! It's breaking IXFR! BIND 9 is doing what you yourself said it "must" do. This does not by itself break IXFR. In theory, IXFR can break when the zone transfer graph contains both servers that fully support out-of-zone glue and servers that do not, but in practice no servers support out-of-zone glue and the problem does not occur. This is of course another argument for completely outlawing out-of-zone glue in both masters and slaves as you already suggested doing for security reasons. Mandating support for out-of-zone glue everywhere would also work, but outlawing it does seem like the more realistic approach. In practice, IXFR failures are likely to be caused by inconsistencies in-domain glue, not out-of-domain glue, and the in-domain case is what section 4 is primarily trying to address. -- 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. archive: From owner-namedroppers@ops.ietf.org Tue Feb 25 03:42:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20617 for ; Tue, 25 Feb 2003 03:42:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18naWk-0005jI-00 for namedroppers-data@psg.com; Tue, 25 Feb 2003 00:33:26 -0800 Received: from gold.nb.net ([209.161.64.73] helo=mx2.nb.net) by psg.com with smtp (Exim 3.36 #1) id 18naWE-0005iq-00 for namedroppers@ops.ietf.org; Tue, 25 Feb 2003 00:32:54 -0800 Received: (qmail 18412 invoked from network); 25 Feb 2003 08:32:52 -0000 Received: from titanium.nb.net (209.161.64.27) by gold.nb.net with SMTP; 25 Feb 2003 08:32:52 -0000 Date: Tue, 25 Feb 2003 03:32:52 -0500 (EST) From: Len Budney X-Sender: lbudney@titanium.nb.net To: iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: Poison in a zone In-Reply-To: <200302250450.h1P4oIW00975@guava.araneus.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 24 Feb 2003, (Andreas Gustafsson) wrote: > D. J. Bernstein writes: >> >> But now Gustafsson admits that the BIND 9 AXFR client doesn't follow >> the ``zone coherency'' religion. It deliberately discards some kinds >> of records! It isn't making a perfect copy of the zone! It's breaking >> IXFR! > > BIND 9 is doing what you yourself said it "must" do. True--but it is NOT doing what Mark claimed tinydns and other BIND 9 competitors "must" do. --Len. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 25 06:28:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23777 for ; Tue, 25 Feb 2003 06:28:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18nd1b-000AdX-00 for namedroppers-data@psg.com; Tue, 25 Feb 2003 03:13:27 -0800 Received: from as7-2-2.bn.g.bonet.se ([217.215.21.151] helo=poledra) by psg.com with esmtp (Exim 3.36 #1) id 18nd1Y-000AdL-00 for namedroppers@ops.ietf.org; Tue, 25 Feb 2003 03:13:24 -0800 Received: from localhost ([127.0.0.1] helo=feline.pp.se ident=www-data) by poledra with smtp (Exim 3.35 #1 (Debian)) id 18nd1U-0002Xh-00 for ; Tue, 25 Feb 2003 12:13:20 +0100 Received: from ol7-84.fibertel.com.ar ([213.15.68.55]) (SquirrelMail authenticated user feline) by www.feline.pp.se with HTTP; Tue, 25 Feb 2003 12:13:20 +0100 (CET) Message-ID: <55397.213.15.68.55.1046171600.squirrel@www.feline.pp.se> Date: Tue, 25 Feb 2003 12:13:20 +0100 (CET) Subject: Re: Poison in a zone From: "Kandra Nygards" To: In-Reply-To: <20030225005042.72047.qmail@cr.yp.to> References: <20030223091513.85299.qmail@cr.yp.to> <200302232128.h1NLS74U020848@drugs.dv.isc.org> <20030224001809.72005.qmail@cr.yp.to> <200302240239.h1O2dAh00524@guava.araneus.fi> <20030224040021.47335.qmail@cr.yp.to> <200302242340.h1ONeur00731@guava.araneus.fi> <20030225005042.72047.qmail@cr.yp.to> X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.6) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=1.2 required=5.0 tests=IN_REP_TO,MISSING_MIMEOLE,MISSING_OUTLOOK_NAME, MSG_ID_ADDED_BY_MTA_3,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_02_03 version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit > But now Gustafsson admits that the BIND 9 AXFR client doesn't follow > the ``zone coherency'' religion. It deliberately discards some kinds of > records! It isn't making a perfect copy of the zone! It's breaking > IXFR! Here's the quote: ``BIND 9 ... will discard [these] records > whether they are loaded from a master file or received as part of a > zone transfer.'' Excellent point. You're perfectly right, of course. According to my understanding of this argument, BIND9 (and tinydns etc) must preserve any out-of-zone records it receives in an AXFR, for the purposes of transfering a non-modified zone to other servers via AXFR. It MAY, of course, discard such records when it loads its data from a master file or outer source of master configuration, as well as discard such records for non-AXFR responses to queries. May I assume that you're supporting the AXFR-clarify draft as long as the above clarification is made? Best regards Kandra Nygards -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 25 12:46:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08211 for ; Tue, 25 Feb 2003 12:46:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18nip5-000PtC-00 for namedroppers-data@psg.com; Tue, 25 Feb 2003 09:24:55 -0800 Received: from [2002:425c:4242:0:250:daff:fe82:1c39] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 18nioi-000Pq4-00 for namedroppers@ops.ietf.org; Tue, 25 Feb 2003 09:24:33 -0800 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id A8BD518EC for ; Tue, 25 Feb 2003 12:24:00 -0500 (EST) Date: Tue, 25 Feb 2003 12:24:00 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: draft-ietf-dnsext-dnssec-records-03.txt References: <20030215014807.C29F218EC@thrintun.hactrn.net> User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030225172400.A8BD518EC@thrintun.hactrn.net> X-Spam-Status: No, hits=-0.2 required=5.0 tests=REFERENCES,SPAM_PHRASE_00_01,USER_AGENT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I just sent draft-ietf-dnsext-dnssec-records-03.txt off to the Internet-Drafts administrator on behalf of the DNSSEC document editing team. Since this is a busy time for the I-D admin, it may take a while for this draft to get to the head of the queue. In the meantime, here's the URL for what I just sent in: http://www.hactrn.net/ietf/dns/dnssec-editors/draft-ietf-dnsext-dnssec-records-03.txt Comments actively solicited, the sooner the better. See the WG chairs' periodic posting to this list on "DNSSEC editing process" for details on where to send feedback. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 25 13:02:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08753 for ; Tue, 25 Feb 2003 13:02:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18njG7-0001LS-00 for namedroppers-data@psg.com; Tue, 25 Feb 2003 09:52:51 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #1) id 18njG1-0001LB-00 for namedroppers@ops.ietf.org; Tue, 25 Feb 2003 09:52:46 -0800 Received: from x22.ripe.net (x22.ripe.net [193.0.1.22]) by birch.ripe.net (8.12.5/8.11.6) with ESMTP id h1PHqi6n024486 for ; Tue, 25 Feb 2003 18:52:44 +0100 Date: Tue, 25 Feb 2003 18:52:43 +0100 (CET) From: Bruce Campbell X-X-Sender: bc@x22.ripe.net To: namedroppers@ops.ietf.org Subject: Re: Poison in a zone In-Reply-To: <55397.213.15.68.55.1046171600.squirrel@www.feline.pp.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.7 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_03_05,USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 25 Feb 2003, Kandra Nygards wrote: > According to my understanding of this argument, BIND9 (and tinydns etc) > must preserve any out-of-zone records it receives in an AXFR, for the > purposes of transfering a non-modified zone to other servers via AXFR. Yes, specifically (section 4, paragraph 4 of axfr-clarify-05): The slave MUST associate the RRs received in a zone transfer with the specific zone being transferred, and maintain that association for purposes of acting as a master in outgoing transfers. > It MAY, of course, discard such records when it loads its data from a > master file or outer source of master configuration, as well as discard > such records for non-AXFR responses to queries. Yes, specifically section 4, paragraph 3: Therefore, in a zone transfer the master MUST send exactly those records that are associated with the zone, whether or not their owner names would be considered to be "in" the zone for purposes of resolution, and whether or not they would be eligible for use as glue in responses. 'Exactly' in this instance should imply that case is preserved, as per 1035 2.3.3 , although you'd only get into trouble with not doing this when tossing IDN zones around. > May I assume that you're supporting the AXFR-clarify draft as long as the > above clarification is made? You seem to be 35 days early. --==-- Bruce. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 25 13:44:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10133 for ; Tue, 25 Feb 2003 13:44:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18njzE-0003lw-00 for namedroppers-data@psg.com; Tue, 25 Feb 2003 10:39:28 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #1) id 18njz7-0003kO-00 for namedroppers@ops.ietf.org; Tue, 25 Feb 2003 10:39:22 -0800 Received: (qmail 82658 invoked by uid 1016); 25 Feb 2003 18:39:45 -0000 Date: 25 Feb 2003 18:39:45 -0000 Message-ID: <20030225183945.82657.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: Poison in a zone References: <20030223091513.85299.qmail@cr.yp.to> <200302232128.h1NLS74U020848@drugs.dv.isc.org> <20030224001809.72005.qmail@cr.yp.to> <200302240239.h1O2dAh00524@guava.araneus.fi> <20030224040021.47335.qmail@cr.yp.to> <200302242340.h1ONeur00731@guava.araneus.fi> <20030225005042.72047.qmail@cr.yp.to> <55397.213.15.68.55.1046171600.squirrel@www.feline.pp.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Kandra Nygards writes: > May I assume that you're supporting the AXFR-clarify draft as long as > the above clarification is made? Of course not. The existing draft is inconsistent with RFC 1034, inconsistent with most of the installed base, and---as Gustafsson now admits---inconsistent with BIND 9. Your additional ``clarification'' doesn't change this; it simply highlights BIND 9's failure to follow the rules. Furthermore, even if the wacko zone-coherency requirements are dropped, axfr-clarify will still need to be fixed in several other ways. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 25 13:56:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10599 for ; Tue, 25 Feb 2003 13:56:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18nkAp-0004QB-00 for namedroppers-data@psg.com; Tue, 25 Feb 2003 10:51:27 -0800 Received: from one.elistx.com ([209.116.252.130]) by psg.com with esmtp (Exim 3.36 #1) id 18nkAg-0004Oz-00 for namedroppers@ops.ietf.org; Tue, 25 Feb 2003 10:51:18 -0800 Received: from ogud.com (pcp816081pcs.nrockv01.md.comcast.net [68.49.60.118]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HAV008NGOEA0R@eListX.com> for namedroppers@ops.ietf.org; Tue, 25 Feb 2003 13:51:47 -0500 (EST) Received: from ENGILL.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.3/8.12.3) with ESMTP id h1PIpsXs003401; Tue, 25 Feb 2003 13:51:54 -0500 (EST envelope-from ogud@ogud.com) Date: Tue, 25 Feb 2003 13:48:37 -0500 From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: comments on DS-12, section 2.2.1.2 In-reply-to: X-Sender: post@localhost To: Edward Lewis , namedroppers@ops.ietf.org Cc: edlewis@arin.net Message-id: <5.1.1.6.2.20030225132755.01626348@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=us-ascii X-Spam-Status: No, hits=1.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:52 2003-01-02, Edward Lewis wrote: >To the group - please scrutinize...In the spirit of "sending text": thanks for the text. >#2.2.1.2 Special processing when child and an ancestor share server ># ># When a child zone and a ancestor other than parent share an ># authorative server, a DS aware server MUST answer with information ># from child zone, as specified in section 2.2.1.1. This is to prevent ># the server to be marked as lame for child. > >Special rules are needed to permit DS RR aware servers to gracefully >interact with older caches which otherwise might falsely label a server as >lame because of the new placement of the DS RR set. > >Such a situation might arise when a server is authoritative for both a >zone and it's grandparent, but not the parent. This sounds like an >obscure example, but it is very real. The root zone is currently served >on 13 machines, and "root-servers.net." is served on 4 of the same 13, but >"net." is served elsewhere. > >When a server receives a query for (, DS, IN), the response MUST be >determined from reading these rules in order: > >1) If the server is authoritative for the zone that holds the DS RR set >(i.e., the zone that delegates away, aka the "parent" zone), the >response contains the DS RR set as an authoritative answer. > >2) If the server is offering recursive service, the server performs the query s/,/and the RD bit is set in the QUERY,/ > itself (according to the rules for resolvers described below) and > returns it's findings. > >3) If the server is authoritative for the zone that holds the 's >SOA RR set, the response is an authoritative negative answer as described >in 2.2.1.1. > >4) If the server is authoritative for a zone above the QNAME, a referral to a s/zone/zone(s)/ > more enclosing zone's servers is made. > >5) If the server is not authoritative for any part of the QNAME, a >response indicating a lame server for QNAME is given. > >[Editorial comment: notice the lack of RFC 2119 terms below this line. I >am not sure what to require, most of what I have written might be >considered recommendations for finding the data.] > >Using these rules will require some special processing on the part of a DS >RR aware resolver. To illustrate this, an example is used. > >Assuming a server is authoritative for roots.example.net. and for the root >zone but not the intervening two zones (or the intervening two label deep >zone). Assume that QNAME=roots.example.net., QTYPE=DS, and QCLASS=IN. > >The resolver will issue this request (assuming no cached data) expecting a >referral to a net. server. Instead, rule number 3 above applies and a >negative answer is returned by the server. The reaction by the resolver >is not to accept this answer as final as it can determine from the SOA RR >in the negative answer the context within which the server has answered. > >A solution to this is to instruct the resolver to hunt for the >authoritative zone of the data in a brute force manner. > >This can be accomplished by taking the owner name of the returned SOA RR >and strip off enough left-hand labels until a successful NS response is >obtained. A successful response here means that the answer has NS records >in it. (Entertaining the possibility that a cut point may be two labels >down in a zone.) > >Returning to the example, the response will include a negative answer with >either the SOA RR for "roots.example.net." or "example.net." depending on >whether roots.example.net is a delegated domain. In either case, removing >the least significant label of the SOA owner name will lead to the >location of the desired data. Much better than my text, I have included this with the edits shown above. 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. archive: From owner-namedroppers@ops.ietf.org Tue Feb 25 14:37:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12002 for ; Tue, 25 Feb 2003 14:37:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18nkol-0006nP-00 for namedroppers-data@psg.com; Tue, 25 Feb 2003 11:32:43 -0800 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #1) id 18nkof-0006lI-00 for namedroppers@ops.ietf.org; Tue, 25 Feb 2003 11:32:38 -0800 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id OAA29764; Tue, 25 Feb 2003 14:28:14 -0500 Date: Tue, 25 Feb 2003 14:29:41 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Andreas Gustafsson cc: "D. J. Bernstein" , , Subject: Re: Poison in a zone In-Reply-To: <200302250450.h1P4oIW00975@guava.araneus.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,SPAM_PHRASE_00_01,USER_AGENT_PINE, X_OSIRU_SPAM_SRC version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 24 Feb 2003, Andreas Gustafsson wrote: > D. J. Bernstein writes: > > But now Gustafsson admits that the BIND 9 AXFR client doesn't follow > > the ``zone coherency'' religion. It deliberately discards some kinds of > > records! It isn't making a perfect copy of the zone! It's breaking IXFR! > > BIND 9 is doing what you yourself said it "must" do. Yes. You present this as though it refutes his argument. It does not. Bind 9 does something that contradicts your claims. (you might say, "we thought so". > This does not by itself break IXFR. Of course it doesn't. As we've been saying, IXFR has no relationship to AXFR at all. IXFR can work _without_ AXFR. --Dean -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 25 14:58:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12901 for ; Tue, 25 Feb 2003 14:58:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18nl88-0007ud-00 for namedroppers-data@psg.com; Tue, 25 Feb 2003 11:52:44 -0800 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #1) id 18nl82-0007uQ-00 for namedroppers@ops.ietf.org; Tue, 25 Feb 2003 11:52:38 -0800 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id OAA29376; Tue, 25 Feb 2003 14:47:39 -0500 Date: Tue, 25 Feb 2003 14:49:06 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: "D. J. Bernstein" cc: namedroppers@ops.ietf.org Subject: Re: Poison in a zone In-Reply-To: <20030225183945.82657.qmail@cr.yp.to> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,SPAM_PHRASE_01_02, TO_BE_REMOVED_REPLY,USER_AGENT_PINE,X_OSIRU_SPAM_SRC version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Dan, Kanda: Do you support the clarification with these changes: I'll write up the draft with these changes, if you agree. ++++++++++ repost from last week The second paragraph of Section 2 should be deleted. Specific implementations are not to be mentioned in RFC's. In section 3, where it says "MUST" it should say "MAY", and where it says "MAY", it should say "MUST". Section 3.1 seems like a good idea, however, it is a modification to AXFR, and should have a new request code. I suggest calling it MAXFR and giving it code 253. Support for this request code should be optional, and a server may respond using the original (one record per message) AXFR method. Upon discovering non-implemenation, clients should fall back to AXFR or fail as determined by implementation or configuration. Section 3.3 should be deleted. This is up to the administator and/or the implementation. SIG processing is not addressed, neither by when the server should put them in, nor by what the client should do with them if present. Section 3.4 should be deleted. Section 3.5 and 3.6 should be deleted. Data can come in either authority or additional sections. There are no transaction signatures, except for id, question, and serial number. Section 4 should be deleted. Clearly, glue records need to be merged in. Section 5 paragraph 3 should be deleted except for the first sentence. In the forth paragraph, where it says "MUST", should say "MAY". Clearly, duplicate records may indicate a misconfiguration, and their presence in a zone can indicate a problem. Or not. It is up to the administrators to determine how they configure there servers, and to configure those servers consistently. Section 6 should be deleted. The status of these other RFCs is not to be altered except by appropriate standardization process. This is an inappropriate end-run around that process. Whether zone data is public is an administrative decision not limited by RFC. Administrators are free to place or implement whatever restrictions they wish on domain name records, and such administrative restrictions are not limited to only zone transfer restriction. They can, for example, be limited by node or record type, or any other way that can be invented and found useful. ++++++++++++++++++++++++++++++++++ --Dean On 25 Feb 2003, D. J. Bernstein wrote: > Kandra Nygards writes: > > May I assume that you're supporting the AXFR-clarify draft as long as > > the above clarification is made? > > Of course not. > > The existing draft is inconsistent with RFC 1034, inconsistent with most > of the installed base, and---as Gustafsson now admits---inconsistent > with BIND 9. Your additional ``clarification'' doesn't change this; it > simply highlights BIND 9's failure to follow the rules. > > Furthermore, even if the wacko zone-coherency requirements are dropped, > axfr-clarify will still need to be fixed in several other ways. > > ---D. J. Bernstein, Associate Professor, Department of Mathematics, > Statistics, and Computer Science, University of Illinois at Chicago > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 25 17:56:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20657 for ; Tue, 25 Feb 2003 17:56:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18nnmf-000HNp-00 for namedroppers-data@psg.com; Tue, 25 Feb 2003 14:42:45 -0800 Received: from pianosa.catch22.org ([66.93.182.229]) by psg.com with esmtp (Exim 3.36 #1) id 18nnmA-000HJ0-00 for namedroppers@ops.ietf.org; Tue, 25 Feb 2003 14:42:14 -0800 Received: by pianosa.catch22.org (Postfix, from userid 1000) id 8225660; Tue, 25 Feb 2003 14:42:13 -0800 (PST) Date: Tue, 25 Feb 2003 16:42:13 -0600 From: David Terrell To: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Message-ID: <20030225224213.GA19540@pianosa.catch22.org> Reply-To: David Terrell References: <1045910906.26677.29.camel@devil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1045910906.26677.29.camel@devil> User-Agent: Mutt/1.4i X-vi: Version 1.79 (10/23/96) The CSRG, University of California, Berkeley. X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 4:40PM up 9 days, 20:07, 42 users, load averages: 0.90, 0.72, 0.72 X-Spam-Status: No, hits=-3.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MUTT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sat, Feb 22, 2003 at 12:48:27PM +0200, Mika Liljeberg wrote: > Is that necessary? IPv4 addresses can be returned in IPv4 Mapped format > if necessary. Just add some text explaining this. With our hybrid > IPv4/IPv6 stack implementation this would work out of the box. Did I miss some announcement that mapped addresses were suddenly allowed to be present on the wire? They were supposed to be only used in the socket API. Camels... tents.... -- David Terrell | "War is peace, Prime Minister, Nebcorp | freedom is slavery, dbt@meat.net | ignorance is strength http://wwn.nebcorp.com/ | Dishes are clean." - Chris Fester -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 25 20:45:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24733 for ; Tue, 25 Feb 2003 20:45:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18nqVW-0001cW-00 for namedroppers-data@psg.com; Tue, 25 Feb 2003 17:37:14 -0800 Received: from gusto.araneus.fi ([204.152.186.164]) by psg.com with esmtp (Exim 3.36 #1) id 18nqVR-0001cH-00; Tue, 25 Feb 2003 17:37:09 -0800 Received: from guava.araneus.fi (adsl-63-197-0-204.dsl.snfc21.pacbell.net [63.197.0.204]) by gusto.araneus.fi (8.11.6/8.11.6) with ESMTP id h1Q1b2B01830; Tue, 25 Feb 2003 17:37:02 -0800 (PST) Received: (from gson@localhost) by guava.araneus.fi (8.11.6/8.11.6) id h1Q1b0i00665; Tue, 25 Feb 2003 17:37:00 -0800 (PST) Date: Tue, 25 Feb 2003 17:37:00 -0800 (PST) Message-Id: <200302260137.h1Q1b0i00665@guava.araneus.fi> To: Erik Nordmark Cc: Andreas Gustafsson , ogud@ogud.com, randy@psg.com, namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-unknown-rrs-04.txt In-Reply-To: References: <200302212235.h1LMZXi18563@guava.araneus.fi> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=0.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Erik Nordmark writes: > Since you seem to understand my concern but disagree with every textual > proposal I suggest to try to make things more clear, why > don't you suggest some clarifications to the text that make things > more clear? Since this perceived lack of clarity seems to be related to the use of the time of publication of RFC2931 as a flag day, would you find it clearer if the time of publication of unknown-RRs itself as an RFC were used instead? Here is an updated and expanded section 7 with this change as well as some added rationale and other clarifications. Using this text will of course require that no new RR types with embedded domain names are defined before this is published as an RFC. Also, the RFC editor needs to replace "TBD" with the actual RFC number of the unknown-rrs RFC itself. 7. DNSSEC Canonical Form and Ordering DNSSEC defines a canonical form and ordering for RRs [RFC2535, section 8.1]. In that canonical form, domain names embedded in the RDATA are converted to lower case. The downcasing is necessary to ensure the correctness of DNSSEC signatures when case distinctions in domain names are lost due to compression, but since it requires knowledge of the presence and position of embedded domain names, it cannot be applied to unknown types. To ensure continued consistency of the canonical form of RR types where compression is allowed, and for continued interoperability with existing implementations that already implement the RFC2535 canonical form and apply it to their known RR types, the canonical form remains unchanged for all RR types whose whose initial publication as an RFC was prior to the initial publication of this specification as an RFC (RFC TBD). As a courtesy to implementors, it is hereby noted that the complete set of such previously published RR types that contain embedded domain names, and whose DNSSEC canonical form therefore involves downcasing according to the DNS rules for character comparisons, consists of the RR types NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV, DNAME, and A6. This document specifies that for all other RR types (whether treated as unknown types or treated as known types according to an RR type definition RFC more recent than than RFC TBD), the canonical form is such that no downcasing of embedded domain names takes place, and otherwise identical to the canonical form specified in RFC2535 section 8.1. Note that the owner name is always set to lower case according to the DNS rules for character comparisons, regardless of the RR type. The DNSSEC canonical RR ordering is as specified in RFC2535 section 8.3, where the octet sequence is the canonical form as revised by this specification. Would this text be acceptable? -- 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. archive: From owner-namedroppers@ops.ietf.org Tue Feb 25 21:21:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25474 for ; Tue, 25 Feb 2003 21:21:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18nr8t-00041R-00 for namedroppers-data@psg.com; Tue, 25 Feb 2003 18:17:55 -0800 Received: from gusto.araneus.fi ([204.152.186.164]) by psg.com with esmtp (Exim 3.36 #1) id 18nr8q-00041F-00 for namedroppers@ops.ietf.org; Tue, 25 Feb 2003 18:17:52 -0800 Received: from guava.araneus.fi (adsl-63-197-0-204.dsl.snfc21.pacbell.net [63.197.0.204]) by gusto.araneus.fi (8.11.6/8.11.6) with ESMTP id h1Q2HoB01991; Tue, 25 Feb 2003 18:17:50 -0800 (PST) Received: (from gson@localhost) by guava.araneus.fi (8.11.6/8.11.6) id h1Q2Hot00705; Tue, 25 Feb 2003 18:17:50 -0800 (PST) Date: Tue, 25 Feb 2003 18:17:50 -0800 (PST) Message-Id: <200302260217.h1Q2Hot00705@guava.araneus.fi> To: Bruce Campbell Cc: namedroppers@ops.ietf.org Subject: Preservation of character case in zone transfers In-Reply-To: References: <55397.213.15.68.55.1046171600.squirrel@www.feline.pp.se> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=0.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Bruce Campbell wrote: > Therefore, in a zone transfer the master MUST send exactly those > records that are associated with the zone, whether or not their owner > names would be considered to be "in" the zone for purposes of > resolution, and whether or not they would be eligible for use as glue > in responses. > > 'Exactly' in this instance should imply that case is preserved, as per > 1035 2.3.3 , although you'd only get into trouble with not doing this when > tossing IDN zones around. RFC1035 section 2.3.3 says case should be preserved "when possible", but also notes that there are cases where it is not possible. It is not always possible to preserve case in zone transfers because of domain name compression in the transfer messages, and I did not mean to imply that case would be preserved. IDN must deal with case not being preserved, and as far as I know it does. So does IXFR. -- 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. archive: From owner-namedroppers@ops.ietf.org Wed Feb 26 18:06:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01395 for ; Wed, 26 Feb 2003 18:06:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18oAHK-000E8W-00 for namedroppers-data@psg.com; Wed, 26 Feb 2003 14:43:54 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #1) id 18oAHH-000E8J-00 for namedroppers@ops.ietf.org; Wed, 26 Feb 2003 14:43:51 -0800 Received: (qmail 19547 invoked by uid 1016); 26 Feb 2003 22:44:16 -0000 Date: 26 Feb 2003 22:44:16 -0000 Message-ID: <20030226224416.19546.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: Poison in a zone References: <20030225183945.82657.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=0.3 required=5.0 tests=REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Dean Anderson writes: > I'll write up the draft with these changes, if you agree. The existing draft was shoved into Last Call with huge problems. I'm still waiting for it to be withdrawn (or rejected). There are obviously bigger problems here than clarification of the AXFR protocol. The discussion has revealed a huge gap between * RFC 1034, which simplifies software but demands that administrators maintain exact glue consistency, and * the ``zone coherency'' cult, which removes some administrative requirements (but not all) while demanding that AXFR clients (but not other clients) maintain exact copies of zones no matter how inconsistent those zones are---a rule that even BIND 9 violates. The real world is somewhere between these extremes. Perhaps we can have a rational cost-benefit discussion, now that BIND 9's disobedience of the cult has been exposed. Meanwhile, http://cr.yp.to/djbdns/axfr-notes.html covers several issues that aren't covered in axfr-clarify. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 26 18:41:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02875 for ; Wed, 26 Feb 2003 18:41:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18oB6J-000HRc-00 for namedroppers-data@psg.com; Wed, 26 Feb 2003 15:36:35 -0800 Received: from pigeon.verisign.com ([65.205.251.71]) by psg.com with esmtp (Exim 3.36 #1) id 18oB6E-000HRJ-00 for namedroppers@ops.ietf.org; Wed, 26 Feb 2003 15:36:30 -0800 Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53] (may be forged)) by pigeon.verisign.com (8.12.1/) with ESMTP id h1QNYHDm000077; Wed, 26 Feb 2003 15:34:17 -0800 (PST) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Feb 2003 15:36:22 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'namedroppers@ops.ietf.org'" Cc: "'Erik Nordmark'" , =?iso-8859-1?Q?=27=D3lafur?= =?iso-8859-1?Q?_Gudmundsson/DNSEXT_co-chair=27?= , "'Harald Tveit Alvestrand'" Subject: DNSEXT WGLC: DNSSEC Opt-in Process Date: Wed, 26 Feb 2003 15:36:22 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_004B_01C2DDC5.F6139710" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=3.3 required=5.0 tests=ACT_NOW,EXCHANGE_SERVER,MAY_BE_FORGED,MISSING_OUTLOOK_NAME, OPT_IN,SPAM_PHRASE_01_02 version=2.43 X-Spam-Level: *** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_004B_01C2DDC5.F6139710 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit OK we have now had the technical review phase. When do we start the next stage of this process, the re-opening of the necessity of opt-in debate? I suggest that this should start now and finish the day before the start of the San Francisco IETF. That is March 16th. There has been plenty of time for this debate over the past three years and there has been consensus on numerous occasions. For the record... NOTING that DNSSEC is not commercially viable in the .com and .net zones unless a mechanism that addresses the cost of signing large numbers of insecure delegations is adopted. NOTING that the DNSSEC protocols have been in development for more than a decade without significant deployment. OBSERVING that the DNSEXT group has had three years in which to debate the merits of the OPT-IN proposal and no alternative method of overcomming the disproportionate deployment costs has been proposed. OBSERVING that implementations of the OPT-IN proposal have been tested and found to be viable. ACTING to try to get this farce to terminate with a porposal for a deployable protocol IT IS ASSERTED that OPT-IN should be immediately sent to the IESG for consideration once the minor editorial corrections suggested during last call are completed. Phill ------=_NextPart_000_004B_01C2DDC5.F6139710 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1 3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1 81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK +gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/ H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDIyNjIz MzYyMlowIwYJKoZIhvcNAQkEMRYEFEL72qLaPPXedK5STr9oSER4o3RVMFgGCSqGSIb3DQEJDzFL MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO rwvJMA0GCSqGSIb3DQEBAQUABIGARECNYoG5iyOO4mzN6T96aPq6aJI2EJ5ayMXIXXosvl1ALw91 gj3dMI57GeRq1oIYw5e7OagaY2QqccunXWb53ku4eLPp2cZcMEchck+vK1GZE2Txf1dcCwysxmSS My4MhkhdJwNOC+2FGSXekggO78b4thibKy6Ye8UefKuGhbsAAAAAAAA= ------=_NextPart_000_004B_01C2DDC5.F6139710-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 27 12:28:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12989 for ; Thu, 27 Feb 2003 12:28:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18oRab-000FPz-00 for namedroppers-data@psg.com; Thu, 27 Feb 2003 09:12:57 -0800 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #1) id 18oRaS-000FNW-00 for namedroppers@ops.ietf.org; Thu, 27 Feb 2003 09:12:48 -0800 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id MAA26737; Thu, 27 Feb 2003 12:07:37 -0500 Date: Thu, 27 Feb 2003 12:09:06 -0500 (EST) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: "D. J. Bernstein" cc: iesg@ietf.org, Subject: Re: Poison in a zone In-Reply-To: <20030226224416.19546.qmail@cr.yp.to> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,SPAM_PHRASE_00_01, TO_BE_REMOVED_REPLY,USER_AGENT_PINE,X_OSIRU_SPAM_SRC version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On 26 Feb 2003, D. J. Bernstein wrote: > Dean Anderson writes: > > I'll write up the draft with these changes, if you agree. > > The existing draft was shoved into Last Call with huge problems. I'm > still waiting for it to be withdrawn (or rejected). I agree that the curent version is unacceptable, though, we also (I think) agree that AXFR does need to be clarified. We could reject the current document and resubmit a new one, or we could extensively modify the current one. Is there any benefit to doing this one way over the other way? > There are obviously bigger problems here than clarification of the AXFR > protocol. The discussion has revealed a huge gap between We should add: ==== It is the responsibility of extended AXFR clients to preserve compatibility with un-extended AXFR servers. ==== I think the issue with AXFR responses was addressed consistently with the comments on your page. Your comment about atomic retrieval of Zone Contents is supported by RFC 1035 Section 6.3 Second Paragraph. This doesn't seem ambiguous to me. I had proposed deleting section 3.4 of the clarify draft. However, it seems that to support concurrent UDP zone tranfers, either the question section must be used, or the ID must be supplied by the AXFR server. I also just noticed that I don't see anywhere that TCP is required for AXFR. If UDP is to be used (why?), then one needs the ID in all UDP packets. Over TCP, unless non-AXFR data is to be intermixed in the TCP connection, neither the ID nore the question matters. Including the ID in all packets would permit multiplexing over TCP. I'm for this, in general, but it wasn't done previously. It could be the topic of a modified AXFR proposal. So, the clarification should also say that TCP is required for AXFR. The question and ID sections are not required. Presence of the ID and question sections in the responses should be accepted and ignored by all AXFR clients. Neither client nor server is not allowed to interleave questions or responses over the same TCP connection during an AXFR. Regarding Poison, I think that such records could be discarded, but I wonder whether it is necessary to require such records be removed. It seems to me to be enough to allow administrators and implementations to remove such records, by removing the proposed requirement that no data ever be deleted. So I think that no further clarification is required. This also addresses the database indexing issue. Regarding the parent/child descrepancies, I think we have now demonstrated that IXFR has no bearing on AXFR, and similar to the previous paragraph, the implementation is free to discard such records. However, I would like to move on the clarification, to clarify what the existing AXFR definitely is and definitely is not, the way it was pre-bind 9. > The real world is somewhere between these extremes. Perhaps we can have > a rational cost-benefit discussion, now that BIND 9's disobedience of > the cult has been exposed. > > Meanwhile, http://cr.yp.to/djbdns/axfr-notes.html covers several issues > that aren't covered in axfr-clarify. > > ---D. J. Bernstein, Associate Professor, Department of Mathematics, > Statistics, and Computer Science, University of Illinois at Chicago > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 28 05:49:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19964 for ; Fri, 28 Feb 2003 05:49:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ohrb-0001FU-00 for namedroppers-data@psg.com; Fri, 28 Feb 2003 02:35:35 -0800 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 18ohr7-0001D3-00 for namedroppers@ops.ietf.org; Fri, 28 Feb 2003 02:35:05 -0800 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.6/8.12.6/Debian-7) with ESMTP id h1SAYmcK015495 for ; Fri, 28 Feb 2003 11:34:49 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.6/8.12.6/Debian-7) with ESMTP id h1SAYmlh015492 for ; Fri, 28 Feb 2003 11:34:48 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Fri, 28 Feb 2003 11:34:48 +0100 (CET) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: namedroppers@ops.ietf.org Subject: draft-ietf-dnsext-dnssec-opt-in-05.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=1.5 required=5.0 tests=OPT_IN,SPAM_PHRASE_00_01,USER_AGENT_PINE,X_AUTH_WARNING version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk We've sent draft-ietf-dnsext-dnssec-opt-in-05.txt off to the Internet-Drafts administrator. This the URL for what we've sent in: http://www.logmess.com/~roy/draft-ietf-dnsext-dnssec-opt-in-05.txt The following are changes suggested by WG as per version 04: Added definitions for "signed name" and "unsigned name". Added text to make it clear that insecure delegations may have Opt-In NXT records of the same name. Updated the example to have one of these. Changed Server-side requirements from MUST NOT to SHOULD NOT and added some basic description of what action to take in the face of violating the delegation-only restriction. Relaxed requirement that servers drop negative wildcard proof from MUST to MAY, reiterated the client requirement. Added section on Dynamic Update declaring it to be undefined wrt Opt-In. Essentially rewrote the "Security Considerations" section. It does not actually say anything different, but hopefully it says it in a clearer fashion. Split references into Normative and Informative. Fixed the example zone and responses to match Delegation Signer. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 28 06:10:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20271 for ; Fri, 28 Feb 2003 06:10:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18oiJV-0002Ih-00 for namedroppers-data@psg.com; Fri, 28 Feb 2003 03:04:25 -0800 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 18oiJT-0002IU-00 for namedroppers@ops.ietf.org; Fri, 28 Feb 2003 03:04:23 -0800 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.6/8.12.6/Debian-7) with ESMTP id h1SB4AcK022106; Fri, 28 Feb 2003 12:04:10 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.6/8.12.6/Debian-7) with ESMTP id h1SB48cC022103; Fri, 28 Feb 2003 12:04:09 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Fri, 28 Feb 2003 12:04:08 +0100 (CET) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: "Hallam-Baker, Phillip" cc: "'namedroppers@ops.ietf.org'" , "'Erik Nordmark'" , =?iso-8859-1?Q?=27=D3lafur?= =?iso-8859-1?Q?_Gudmundsson/DNSEXT_co-chair=27?= , "'Harald Tveit Alvestrand'" Subject: Re: DNSEXT WGLC: DNSSEC Opt-in Process In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-2.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT, REFERENCES,SPAM_PHRASE_00_01,USER_AGENT_PINE,X_AUTH_WARNING version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 26 Feb 2003, Hallam-Baker, Phillip wrote: > IT IS ASSERTED that OPT-IN should be immediately sent to the IESG for > consideration once the minor editorial corrections suggested during last > call are completed. We're convinced we've updated the draft to reflect the minor editorial corrections suggested during last call, so we've sent draft-ietf-dnsext-dnssec-opt-in-05.txt off to the Internet-Drafts administrator. This the URL for what we've sent in: http://www.logmess.com/~roy/draft-ietf-dnsext-dnssec-opt-in-05.txt The following are changes suggested by WG as per version 04: Added definitions for "signed name" and "unsigned name". Added text to make it clear that insecure delegations may have Opt-In NXT records of the same name. Updated the example to have one of these. Changed Server-side requirements from MUST NOT to SHOULD NOT and added some basic description of what action to take in the face of violating the delegation-only restriction. Relaxed requirement that servers drop negative wildcard proof from MUST to MAY, reiterated the client requirement. Added section on Dynamic Update declaring it to be undefined wrt Opt-In. Essentially rewrote the "Security Considerations" section. It does not actually say anything different, but hopefully it says it in a clearer fashion. Split references into Normative and Informative. Fixed the example zone and responses to match Delegation Signer. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 28 06:33:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20874 for ; Fri, 28 Feb 2003 06:33:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18oicp-0002x3-00 for namedroppers-data@psg.com; Fri, 28 Feb 2003 03:24:23 -0800 Received: from [217.144.230.27] (helo=lexx.infeline.org) by psg.com with smtp (Exim 3.36 #1) id 18oicl-0002wp-00 for namedroppers@ops.ietf.org; Fri, 28 Feb 2003 03:24:19 -0800 Received: (qmail 32358 invoked by alias); 28 Feb 2003 11:24:11 -0000 Received: from unknown (HELO ?217.144.230.27?) (ketil@217.144.230.27) by lexx.infeline.org with SMTP; 28 Feb 2003 11:24:11 -0000 Date: Fri, 28 Feb 2003 12:24:05 +0100 (CET) From: Ketil Froyn X-X-Sender: ketil@lexx.infeline.org To: namedroppers@ops.ietf.org Subject: clarity on wildcards Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.2 required=5.0 tests=GAPPY_TEXT,SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hi. I recently found out that there are some discrepancies in how different implementations handle wildcards. Let's say the DNS server authoritative for the zone "c." contains these records: *.c. A 192.168.1.1 a.b.c. A 192.168.1.2 BIND8.3.4 gives these results: z.a.b.c. NXDOMAIN b.c. NODATA b.b.c. NXDOMAIN d.c. A 192.168.1.1 BIND9.2.2rc1 gives these results: z.a.b.c. NXDOMAIN b.c. A 192.168.1.1 b.b.c A 192.168.1.1 d.c. A 192.168.1.1 tinydns gives these results: z.a.b.c. A 192.168.1.1 b.c. A 192.168.1.1 b.b.c. A 192.168.1.1 d.c. A 192.168.1.1 Mark Andrews has said[1] that BIND9.3 does this: b.c. NODATA or NXDOMAIN (does not match *.c) which implies b.b.c. NXDOMAIN Edward Lewis has said[2] (as I understood it, please correct me if I am wrong, this discussion includes elements I am not familiar with) that this is the correct response: b.b.c. 192.168.1.1 (matches *.c) which implies b.c 192.168.1.1 (matches *.c) By my own understanding of RFC1034, BIND9.2.2rc1 is the only one listed that gets all cases right. In my opinion, b.c should match the wildcard, because RFC1034 says: --- Wildcard RRs do not apply: - When the query is in another zone. That is, delegation cancels the wildcard defaults. --- which implies that other RRs do not cancel the wildcard. I say this because, if a zone includes this delegation: d.e.c. NS some.name.server. or in fact any label attached to d.e.c., then by BIND8/BIND9.3 logic, anything on the form *.e.c is already cancelled, and only specifying that *.d.e.c is cancelled is pointless, especially when it additionally limits this to delegations. Also, the reverse case is detailed, where a subdomain of the query name exists between the query name and the wildcard: --- Wildcard RRs do not apply: [snip] - When the query name or a name between the wildcard domain and the query name is know to exist. For example, if a wildcard RR has an owner name of "*.X", and the zone also contains RRs attached to B.X, the wildcards would apply to queries for name Z.X (presuming there is no explicit information for Z.X), but not to B.X, A.B.X, or X. --- but if a.b.c were to cancel b.c from matching *.c, that would surely be worthy of mention? In addition, this definition implies that existence of a name is existence of an RR attached to that name, not the existence of an RR where the label has the name at the end. So, which one _is_ right? Please support your arguments thoroughly, I am clearly not the only one who needs to be convinced. [1] http://marc.theaimsgroup.com/?l=bind-users&m=104634519523021&w=2 [2] http://marc.theaimsgroup.com/?l=namedroppers&m=103549359131894&w=2 Ketil Froyn ketil@froyn.name http://ketil.froyn.name/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 28 07:19:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22047 for ; Fri, 28 Feb 2003 07:19:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ojRT-0004of-00 for namedroppers-data@psg.com; Fri, 28 Feb 2003 04:16:43 -0800 Received: from [2001:470:1f00:ffff::5a1] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 18ojRM-0004mH-00 for namedroppers@ops.ietf.org; Fri, 28 Feb 2003 04:16:38 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h1SCFC4U077653; Fri, 28 Feb 2003 23:15:12 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200302281215.h1SCFC4U077653@drugs.dv.isc.org> To: Ketil Froyn Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: clarity on wildcards In-reply-to: Your message of "Fri, 28 Feb 2003 12:24:05 BST." Date: Fri, 28 Feb 2003 23:15:12 +1100 X-Spam-Status: No, hits=0.9 required=5.0 tests=GAPPY_TEXT,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,TO_BE_REMOVED_REPLY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Hi. > > I recently found out that there are some discrepancies in how different > implementations handle wildcards. Let's say the DNS server authoritative > for the zone "c." contains these records: > *.c. A 192.168.1.1 > a.b.c. A 192.168.1.2 > > BIND8.3.4 gives these results: > z.a.b.c. NXDOMAIN > b.c. NODATA > b.b.c. NXDOMAIN > d.c. A 192.168.1.1 > > BIND9.2.2rc1 gives these results: > z.a.b.c. NXDOMAIN > b.c. A 192.168.1.1 > b.b.c A 192.168.1.1 > d.c. A 192.168.1.1 9.2.2rc1 is wrong. Fixed in 9.3. > tinydns gives these results: > z.a.b.c. A 192.168.1.1 > b.c. A 192.168.1.1 > b.b.c. A 192.168.1.1 > d.c. A 192.168.1.1 this is wrong > Mark Andrews has said[1] that BIND9.3 does this: > b.c. NODATA or NXDOMAIN (does not match *.c) > which implies > b.b.c. NXDOMAIN > > Edward Lewis has said[2] (as I understood it, please correct me if I > am wrong, this discussion includes elements I am not familiar with) that > this is the correct response: > b.b.c. 192.168.1.1 (matches *.c) > which implies > b.c 192.168.1.1 (matches *.c) Ed is wrong. > By my own understanding of RFC1034, BIND9.2.2rc1 is the only one listed > that gets all cases right. In my opinion, b.c should match the wildcard, > because RFC1034 says: > --- > Wildcard RRs do not apply: > > - When the query is in another zone. That is, delegation cancels > the wildcard defaults. > --- > which implies that other RRs do not cancel the wildcard. I say this > because, if a zone includes this delegation: > d.e.c. NS some.name.server. > or in fact any label attached to d.e.c., then by BIND8/BIND9.3 logic, > anything on the form *.e.c is already cancelled, and only specifying that > *.d.e.c is cancelled is pointless, especially when it additionally limits > this to delegations. > > Also, the reverse case is detailed, where a subdomain of the query name > exists between the query name and the wildcard: > --- > Wildcard RRs do not apply: > [snip] > - When the query name or a name between the wildcard domain and > the query name is know to exist. For example, if a wildcard > RR has an owner name of "*.X", and the zone also contains RRs > attached to B.X, the wildcards would apply to queries for name > Z.X (presuming there is no explicit information for Z.X), but > not to B.X, A.B.X, or X. > --- > but if a.b.c were to cancel b.c from matching *.c, that would surely be > worthy of mention? In addition, this definition implies that existence of > a name is existence of an RR attached to that name, not the existence of > an RR where the label has the name at the end. Nodes are allowed to be empty. > So, which one _is_ right? Please support your arguments thoroughly, I am > clearly not the only one who needs to be convinced. Label matching is done a label at the time from the root. Only if a label doesn't match do you look for a wildcard at the same level as the non-matching wildcard. For d.b.c, c matches, b matches, d doesn't match so you look for a wild card at this level (*.b.c). This doesn't exist Read section "4.3.2. Algorithm" again. Pay close attention to the references to the "*" label in step 3. > [1] http://marc.theaimsgroup.com/?l=bind-users&m=104634519523021&w=2 > [2] http://marc.theaimsgroup.com/?l=namedroppers&m=103549359131894&w=2 > > Ketil Froyn > ketil@froyn.name > http://ketil.froyn.name/ > > > > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 28 07:29:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23070 for ; Fri, 28 Feb 2003 07:29:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ojZv-000586-00 for namedroppers-data@psg.com; Fri, 28 Feb 2003 04:25:27 -0800 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 18ojZs-00057u-00 for namedroppers@ops.ietf.org; Fri, 28 Feb 2003 04:25:24 -0800 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1SCPJO08013; Fri, 28 Feb 2003 19:25:20 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1SCOxo03951; Fri, 28 Feb 2003 19:25:01 +0700 (ICT) From: Robert Elz To: Ketil Froyn cc: namedroppers@ops.ietf.org Subject: Re: clarity on wildcards In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 Feb 2003 19:24:59 +0700 Message-ID: <3949.1046435099@munnari.OZ.AU> X-Spam-Status: No, hits=-0.5 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_02_03 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Fri, 28 Feb 2003 12:24:05 +0100 (CET) From: Ketil Froyn Message-ID: | BIND8.3.4 gives these results: This one is correct. All the others shown are wrong. | Wildcard RRs do not apply: | | - When the query is in another zone. That is, delegation cancels | the wildcard defaults. | --- | which implies that other RRs do not cancel the wildcard. No it doesn't. You can't make inferences like that, they make no logical sense. | I say this | because, if a zone includes this delegation: | d.e.c. NS some.name.server. | or in fact any label attached to d.e.c., then by BIND8/BIND9.3 logic, | anything on the form *.e.c is already cancelled, and only specifying that | *.d.e.c is cancelled is pointless, Yes, I agree, and have wondered why that particular limitation needed to be there - perhaps it is just to make it clear that a wildcard can never result in a referral. | Also, the reverse case is detailed, where a subdomain of the query name | exists between the query name and the wildcard: | --- | Wildcard RRs do not apply: | [snip] | - When the query name or a name between the wildcard domain and | the query name is know to exist. This is the one that makes it clear. If b.b.c exists, then necessarily b.c exists as well (note, you need to go back and investigate the definition of a "domain" to see why this is so, and note that domains are not required to own any RR's). So *.c cannot apply to a.b.c as a name between the wildcard domain and the query domain is known to exist (that is, b.c). | So, which one _is_ right? Please support your arguments thoroughly, I am | clearly not the only one who needs to be convinced. This discussion has been had many times - just go back and check the namedroppers archives, you'll find it, more than once. There really is no need to do it all again. 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. archive: From owner-namedroppers@ops.ietf.org Fri Feb 28 08:05:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25684 for ; Fri, 28 Feb 2003 08:05:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ok9o-0006bB-00 for namedroppers-data@psg.com; Fri, 28 Feb 2003 05:02:32 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 18ok9m-0006az-00 for namedroppers@ops.ietf.org; Fri, 28 Feb 2003 05:02:30 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h1SD2Mqn054557; Fri, 28 Feb 2003 08:02:22 -0500 (EST) Received: from [192.149.252.108] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id IAA16604; Fri, 28 Feb 2003 08:02:21 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Fri, 28 Feb 2003 08:01:58 -0500 To: Ketil Froyn From: Edward Lewis Subject: Re: clarity on wildcards Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-1.6 required=5.0 tests=GAPPY_TEXT,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 12:24 +0100 2/28/03, Ketil Froyn wrote: >Edward Lewis has said[2] (as I understood it, please correct me if I What I wrote in message [2] is wrong (it predates the wild card clarification document). What is in the wild card clarifications draft says that b.c. is the "closest enclosing" domain of b.b.c, hence the only potential wild card to synthesize an answer would be at *.b.c. In your example, there isn't one, hence an authoritative name error is the correct response. From the list included, only the Bind 8.3.4 gives the right responses in all cases. >By my own understanding of RFC1034, BIND9.2.2rc1 is the only one listed >that gets all cases right. In my opinion, b.c should match the wildcard, >because RFC1034 says: >--- >Wildcard RRs do not apply: > > - When the query is in another zone. That is, delegation cancels > the wildcard defaults. Unless b.c has an NS set itself, it belongs to the same zone as *.c. So this isn't the reason the wild card is "blocked." >Wildcard RRs do not apply: >[snip] > - When the query name or a name between the wildcard domain and > the query name is know to exist. For example, if a wildcard > RR has an owner name of "*.X", and the zone also contains RRs > attached to B.X, the wildcards would apply to queries for name > Z.X (presuming there is no explicit information for Z.X), but > not to B.X, A.B.X, or X. >--- >but if a.b.c were to cancel b.c from matching *.c, that would surely be >worthy of mention? In addition, this definition implies that existence of >a name is existence of an RR attached to that name, not the existence of >an RR where the label has the name at the end. Read section 3.1 of 1034 and 4.3.2 Step 3 part c. I tried to summarize it in the wild card clarify draft - let me know if the text there fails. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 28 08:53:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28431 for ; Fri, 28 Feb 2003 08:53:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18okrn-0008Zp-00 for namedroppers-data@psg.com; Fri, 28 Feb 2003 05:47:59 -0800 Received: from one.elistx.com ([209.116.252.130]) by psg.com with esmtp (Exim 3.36 #1) id 18okrl-0008ZT-00 for namedroppers@ops.ietf.org; Fri, 28 Feb 2003 05:47:57 -0800 Received: from ogud.com (pcp816081pcs.nrockv01.md.comcast.net [68.49.60.118]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HB000A78UAXSX@eListX.com> for namedroppers@ops.ietf.org; Fri, 28 Feb 2003 08:47:22 -0500 (EST) Received: from ENGILL.ogud.com (ns.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.3/8.12.3) with ESMTP id h1SDl5Xs014720; Fri, 28 Feb 2003 08:47:06 -0500 (EST envelope-from ogud@ogud.com) Date: Fri, 28 Feb 2003 08:45:45 -0500 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: Breaking GSS-API deadlock X-Sender: (Unverified) To: namedroppers@ops.ietf.org Cc: Levon Esibov Message-id: <5.1.1.6.2.20030220095515.01b89348@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=us-ascii X-Spam-Status: No, hits=3.1 required=5.0 tests=RCVD_IN_RFCI,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: *** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk After consulting the working group, the consensus is strongly for updating the GSS-API document to update RFC2845. Authors are requested to issue a new version of the gss-api draft with following changes based on the version draft that got posted to the working group. Abstract: State this document updates RFC2845 Add new section 2.2 that specifies the change to 2845, by allowing the TSIG to be introduced in a explicitly specified place in multi message exchange between two DNS entities. Something along the lines: >update Section 4.2 of RFC 2845 >(TSIG): >Replace: >"The server MUST not generate a signed response to an unsigned request." > >With: >"The server MUST not generate a signed response to an unsigned request, >except in case of response to client's unsigned TKEY query if secret key >is established on server side after server processed client's query. >Signing responses to unsigned TKEY queries MUST be explicitly specified >in the description of an individual secret key establishment algorithm." Add a new subsection (not sure where): That specifies explicitly that in a [successful] GSS-API TKEY exchange the LAST message from the server to client MAY/MUST be signed. Highlight that this depends on the change to RFC2845 specified in section 2.2. 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. archive: From owner-namedroppers@ops.ietf.org Fri Feb 28 09:16:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29372 for ; Fri, 28 Feb 2003 09:16:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18olFi-0009kO-00 for namedroppers-data@psg.com; Fri, 28 Feb 2003 06:12:42 -0800 Received: from one.elistx.com ([209.116.252.130]) by psg.com with esmtp (Exim 3.36 #1) id 18olFe-0009kB-00 for namedroppers@ops.ietf.org; Fri, 28 Feb 2003 06:12:39 -0800 Received: from ogud.com (pcp816081pcs.nrockv01.md.comcast.net [68.49.60.118]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HB000AC5VI1SY@eListX.com> for namedroppers@ops.ietf.org; Fri, 28 Feb 2003 09:13:13 -0500 (EST) Received: from ENGILL.ogud.com (mail.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.3/8.12.3) with ESMTP id h1SECwXs014815 for ; Fri, 28 Feb 2003 09:12:58 -0500 (EST envelope-from ogud@ogud.com) Date: Fri, 28 Feb 2003 09:10:14 -0500 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: DNSEXT WGLC summary: OPT-in X-Sender: (Unverified) To: namedroppers@ops.ietf.org Message-id: <5.1.1.6.2.20030228085954.027f6530@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=us-ascii X-Spam-Status: No, hits=4.9 required=5.0 tests=OPT_IN,RCVD_IN_RFCI,SPAM_PHRASE_03_05 version=2.43 X-Spam-Level: **** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This last call has completed. The result of the last call was that there is consensus the technical specification was almost ready. Authors have worked with this chair to create a new version of the document that addresses the issues raised in the last call and have submitted a new version. The message below contains the list of changes to the document: http://psg.com/lists/namedroppers/namedroppers.2003/msg00489.html Due to the expected delay in posting the new version as a ID here is a pointer to the new version: http://www.logmess.com/~roy/draft-ietf-dnsext-dnssec-opt-in-05.txt The chair would like to thank the working group members that responded to the message below and engaged in one of the better technical debates the mailing list has seen. Olafur >This working group last call concluded in December with NO comments, >there have been some comments in the last 24 hours. >The chairs would like a more affirmative statements from the working group >about this document. > >Default action: if there is NO response to these questions Opt-in document >will be removed from the working group. > >Note: We are only asking the technical questions about Opt-in, the political >question if we want to standardize this will be addressed if the >technical questions are affirmative. > >Q: Is the description in the document of Opt-In complete ? > >Q: Does this document satisfy people as being implement able and testable >specification ? > >Q: Are there implementations of opt-in and have there been any tests ? > >The chairs will consider any response received on the mailing list or >sent privately to BOTH chairs, by February 12'th. > > 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. archive: From owner-namedroppers@ops.ietf.org Fri Feb 28 13:06:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07629 for ; Fri, 28 Feb 2003 13:06:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ooe4-000JIh-00 for namedroppers-data@psg.com; Fri, 28 Feb 2003 09:50:04 -0800 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by psg.com with esmtp (Exim 3.36 #1) id 18oody-000JGq-00 for namedroppers@ops.ietf.org; Fri, 28 Feb 2003 09:49:58 -0800 Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1SHnrNh014087; Fri, 28 Feb 2003 12:49:54 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-251.cisco.com [161.44.149.251]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA20367; Fri, 28 Feb 2003 12:49:53 -0500 (EST) Message-Id: <4.3.2.7.2.20030228124404.0378ceb0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 28 Feb 2003 12:49:52 -0500 To: dhcwg@ietf.org, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org From: Ralph Droms Subject: Revision of DHCPv6 DNS configuration options Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I've revised "DNS Configuration options for DHCPv6" based on input received during the WG last call. Here is the summary of changes to the document: Changes from draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt This document includes the following changes in response to comments made during the dhc/dnsext WG last call: o Combined RFC2119 reference and reference to DHCPv6 specification into one "Terminology" section; added explicit normative reference to DHCPv6 specification. o Changed name of "Domain Name Server" option to "DNS Resolver" option. o Clarified and corrected filed names and descriptions of fields in the option format diagrams. o Reworded "Appearance of these options" for clarity; removed Confirm from list of messages in which the options can appear. o Clarified the type of attack that can be mounted through the Domain Search List option by copying text from RFC3997 As these changes are editorial or clarifying, draft-ietf-dhc-dhcpv6 opt-dnsconfig-03.txt is ready for IESG review as a Proposed Standard. - Ralph -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 28 15:26:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12367 for ; Fri, 28 Feb 2003 15:26:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18oqvx-0000Ip-00 for namedroppers-data@psg.com; Fri, 28 Feb 2003 12:16:41 -0800 Received: from [2002:425c:4242:0:250:daff:fe82:1c39] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 18oqvv-0000Hl-00 for namedroppers@ops.ietf.org; Fri, 28 Feb 2003 12:16:39 -0800 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id BCF9018EC for ; Fri, 28 Feb 2003 15:16:06 -0500 (EST) Date: Fri, 28 Feb 2003 15:16:06 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Q-6: May security-aware resolvers cache "Bad" data? User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030228201606.BCF9018EC@thrintun.hactrn.net> X-Spam-Status: No, hits=-0.2 required=5.0 tests=SPAM_PHRASE_00_01,SUBJECT_MONTH,USER_AGENT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Q: Is a security-aware resolver allowed to cache RRsets for which one or more SIG RRs exist but none of them validate? Discussion: Excerpt from RFC 2535, section 6: Data stored at a security aware server needs to be internally categorized as Authenticated, Pending, or Insecure. There is also a fourth transient state of Bad which indicates that all SIG checks have explicitly failed on the data. Such Bad data is not retained at a security aware server. This appears to rule out any form of caching for RRsets with signatures which do not validate, including any form of negative caching. Given the demonstrated need for negative response caching in insecure DNS, this prohibition seems ill-advised. Please also note that this appears to be dictating implementation details than just describing externally visible behavior, and that the RFC 2535 rule may require a security-aware recursive name server to leave itself open to denial of CPU-time attacks by requiring the server to repeat the same signature checks over and over again. Should we remove this prohibition? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 28 18:35:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17225 for ; Fri, 28 Feb 2003 18:35:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18otqC-0008lZ-00 for namedroppers-data@psg.com; Fri, 28 Feb 2003 15:22:56 -0800 Received: from spratly.wl.nominum.com ([128.177.195.135]) by psg.com with esmtp (Exim 3.36 #1) id 18otq9-0008lN-00 for namedroppers@ops.ietf.org; Fri, 28 Feb 2003 15:22:53 -0800 Received: from spratly.wl.nominum.com (spratly [127.0.0.1]) by spratly.wl.nominum.com (8.12.5/8.12.5) with ESMTP id h1SNMtun015012; Fri, 28 Feb 2003 15:22:55 -0800 Received: from localhost (bwelling@localhost) by spratly.wl.nominum.com (8.12.5/8.12.5/Submit) with ESMTP id h1SNMsck015009; Fri, 28 Feb 2003 15:22:55 -0800 X-Authentication-Warning: spratly.wl.nominum.com: bwelling owned process doing -bs Date: Fri, 28 Feb 2003 15:22:54 -0800 (PST) From: Brian Wellington X-X-Sender: bwelling@spratly.wl.nominum.com To: Rob Austein cc: namedroppers@ops.ietf.org Subject: Re: Q-6: May security-aware resolvers cache "Bad" data? In-Reply-To: <20030228201606.BCF9018EC@thrintun.hactrn.net> Message-ID: References: <20030228201606.BCF9018EC@thrintun.hactrn.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,SUBJECT_MONTH,USER_AGENT_PINE, X_AUTH_WARNING version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 28 Feb 2003, Rob Austein wrote: > Q: Is a security-aware resolver allowed to cache RRsets for which one > or more SIG RRs exist but none of them validate? > > Discussion: > > Excerpt from RFC 2535, section 6: > > Data stored at a security aware server needs to be internally > categorized as Authenticated, Pending, or Insecure. There is also a > fourth transient state of Bad which indicates that all SIG checks > have explicitly failed on the data. Such Bad data is not retained at > a security aware server. > > This appears to rule out any form of caching for RRsets with > signatures which do not validate, including any form of negative > caching. Given the demonstrated need for negative response caching in > insecure DNS, this prohibition seems ill-advised. I'm not sure where negative caching fits into this. The RRsets returned as part of a valid negative response should all be verified; there's nothing in the negative reponse which would be classified as anything other than Authenticated. > Please also note that this appears to be dictating implementation > details than just describing externally visible behavior, and that the > RFC 2535 rule may require a security-aware recursive name server to > leave itself open to denial of CPU-time attacks by requiring the > server to repeat the same signature checks over and over again. > > Should we remove this prohibition? As the prohibition is dictating implementation details, it probably should be removed. It's reasonable to suggest this behavior, but the only thing that should be enforced is that clients don't see bad data (clients should possibly get bad data if they issue a query with CD, but I don't care too much either way). 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. archive: From owner-namedroppers@ops.ietf.org Fri Feb 28 19:15:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17886 for ; Fri, 28 Feb 2003 19:15:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ouWa-000AaU-00 for namedroppers-data@psg.com; Fri, 28 Feb 2003 16:06:44 -0800 Received: from gusto.araneus.fi ([204.152.186.164]) by psg.com with esmtp (Exim 3.36 #1) id 18ouWX-000AaH-00 for namedroppers@ops.ietf.org; Fri, 28 Feb 2003 16:06:41 -0800 Received: from guava.araneus.fi (adsl-63-197-0-204.dsl.snfc21.pacbell.net [63.197.0.204]) by gusto.araneus.fi (8.11.6/8.11.6) with ESMTP id h2106aB14149; Fri, 28 Feb 2003 16:06:36 -0800 (PST) Received: (from gson@localhost) by guava.araneus.fi (8.11.6/8.11.6) id h2106Zm21440; Fri, 28 Feb 2003 16:06:35 -0800 (PST) Date: Fri, 28 Feb 2003 16:06:35 -0800 (PST) Message-Id: <200303010006.h2106Zm21440@guava.araneus.fi> To: claus@faerber.muc.de (=?ISO-8859-1?Q?Claus_F=E4rber?=) CC: namedroppers@ops.ietf.org Cc: ietf@ietf.org Subject: Re: Poison in a zone In-Reply-To: <8giJ0Pz3cDD@3247.org> References: <20030225005042.72047.qmail@cr.yp.to> <8giJ0Pz3cDD@3247.org> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=0.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On the IETF list, Claus Färber wrote: > I think the only requirement that's really essential is that the serial > number changes whenever the data that would be returned by a zone > transfer changes (even if that breaks database consistency for the SOA > record's serial number). It is also essential that two different authoritative servers that show the same serial number actually serve the same data. > One strategy to implement this would be to keep an exact copy of a zone > obtained from other servers for outgoing transfers (so you'll always use > the original serial number), which is the BIND 9 strategy. > > Another strategy would be to just increment the serial number of a zone > when it is actually changed by importing glue records from another zone. > This would solve the synchronisation problem, too: If the parent zone is > updated too early, the server might throw away the glue record. But it > will update the parent zone and increase its the serial number when it > gets an up-to-date copy of the child zone. In principle, this approach could work on the primary master server (at least assuming the zone serial number is being maintained by the server rather than the administrator), but it won't work on a slave. If a slave "imports" glue into a zone, it can't update the serial number, and even if it could, that wouldn't make the zone contents consistent with the master. Followups to namedroppers, please. -- 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. archive: From owner-namedroppers@ops.ietf.org Fri Feb 28 19:34:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18362 for ; Fri, 28 Feb 2003 19:34:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ousQ-000BIr-00 for namedroppers-data@psg.com; Fri, 28 Feb 2003 16:29:18 -0800 Received: from [2002:425c:4242:0:250:daff:fe82:1c39] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 18ousN-000BIG-00 for namedroppers@ops.ietf.org; Fri, 28 Feb 2003 16:29:16 -0800 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id A696E18EC for ; Fri, 28 Feb 2003 19:28:42 -0500 (EST) Date: Fri, 28 Feb 2003 19:28:42 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Q-6: May security-aware resolvers cache "Bad" data? In-Reply-To: References: <20030228201606.BCF9018EC@thrintun.hactrn.net> User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030301002842.A696E18EC@thrintun.hactrn.net> X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, SUBJECT_MONTH,USER_AGENT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Fri, 28 Feb 2003 15:22:54 -0800 (PST), Brian Wellington wrote: > > I'm not sure where negative caching fits into this. The RRsets returned > as part of a valid negative response should all be verified; there's > nothing in the negative reponse which would be classified as anything > other than Authenticated. You're thinking of conventional negative response caching, for which you are of course correct. The reference here was to kind of negative caching for which we don't have a name yet, dealing with RRsets whose signatures are demonstrably bad, so that the resolver can avoid performing the same (failing) query and verification operations over and over again within a short period of time. RFC 2535 appears to forbid this form of negative caching and doesn't discuss the (potentially serious) implications of doing so, hence the question. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 28 19:48:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18735 for ; Fri, 28 Feb 2003 19:48:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ov5c-000BYo-00 for namedroppers-data@psg.com; Fri, 28 Feb 2003 16:42:56 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #1) id 18ov5Z-000BYO-00 for namedroppers@ops.ietf.org; Fri, 28 Feb 2003 16:42:53 -0800 Received: (qmail 37444 invoked by uid 1016); 1 Mar 2003 00:43:19 -0000 Date: 1 Mar 2003 00:43:19 -0000 Message-ID: <20030301004319.37443.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org, ietf@ietf.org Subject: Re: Poison in a zone References: <20030225005042.72047.qmail@cr.yp.to> <8giJ0Pz3cDD@3247.org> <200303010006.h2106Zm21440@guava.araneus.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Andreas Gustafsson writes: > It is also essential that two different authoritative servers that > show the same serial number actually serve the same data. That's a wild exaggeration. For example, a pure slave can do anything it wants with its serial numbers. In fact, unless one slave pulls the zone from two different masters, serial-number coherency is irrelevant. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 28 21:31:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20546 for ; Fri, 28 Feb 2003 21:31:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18owf9-000Dt8-00 for namedroppers-data@psg.com; Fri, 28 Feb 2003 18:23:43 -0800 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 18owf6-000Dsr-00 for namedroppers@ops.ietf.org; Fri, 28 Feb 2003 18:23:40 -0800 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id VAA22361; Fri, 28 Feb 2003 21:23:34 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id VAA26068; Fri, 28 Feb 2003 21:23:34 -0500 (EST) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id VAA25759; Fri, 28 Feb 2003 21:23:31 -0500 (EST) Received: (from ghudson@localhost) by error-messages.mit.edu (8.9.3) id VAA11616; Fri, 28 Feb 2003 21:23:31 -0500 Subject: Re: Q-6: May security-aware resolvers cache "Bad" data? From: Greg Hudson To: Rob Austein Cc: namedroppers@ops.ietf.org In-Reply-To: <20030301002842.A696E18EC@thrintun.hactrn.net> References: <20030228201606.BCF9018EC@thrintun.hactrn.net> <20030301002842.A696E18EC@thrintun.hactrn.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 28 Feb 2003 21:23:30 -0500 Message-Id: <1046485410.10318.55.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Spam-Status: No, hits=1.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM, RCVD_IN_RELAYS_ORDB_ORG,REFERENCES,SPAM_PHRASE_01_02, SUBJECT_MONTH,X_OSIRU_OPEN_RELAY version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 2003-02-28 at 19:28, Rob Austein wrote: > The reference here was to kind of negative caching for which we don't > have a name yet, dealing with RRsets whose signatures are demonstrably > bad, so that the resolver can avoid performing the same (failing) > query and verification operations over and over again within a short > period of time. RFC 2535 appears to forbid this form of negative > caching and doesn't discuss the (potentially serious) implications of > doing so, hence the question. Well, to the extent that the cache's behavior is visible to the querying client, it's not an implementation detail. It sounds like the text is trying to prevent a security-aware caching server from providing bad responses to a stub resolver, and that's important for people who want to use security aware local caching recursive resolvers in concert with old native stub resolvers. If the caching resolver wants to cache the bad response (or a hash of it) in order to avoid redoing expensive cryptography operations, that's obviously an implementation detail and is fine. Thunking is always okay when timing attacks aren't an issue. If the caching resolver wants to cache the fact that it got a bad response last time so it doesn't have to bother again, that has a couple of problems: we don't know how long to cache for (any information in the bad response has to be discarded as potentially malicious, and there's no SOA record there anyway), and it could make DOS attacks easier. There may be some scaling issues associated with doing no caching of this sort, but I don't think they're the kind of issues that can be solved during an editing pass. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 28 22:00:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21055 for ; Fri, 28 Feb 2003 22:00:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18oxAf-000Eke-00 for namedroppers-data@psg.com; Fri, 28 Feb 2003 18:56:17 -0800 Received: from spratly.wl.nominum.com ([128.177.195.135]) by psg.com with esmtp (Exim 3.36 #1) id 18oxAd-000EkK-00 for namedroppers@ops.ietf.org; Fri, 28 Feb 2003 18:56:15 -0800 Received: from spratly.wl.nominum.com (spratly [127.0.0.1]) by spratly.wl.nominum.com (8.12.5/8.12.5) with ESMTP id h212uIun019478; Fri, 28 Feb 2003 18:56:18 -0800 Received: from localhost (bwelling@localhost) by spratly.wl.nominum.com (8.12.5/8.12.5/Submit) with ESMTP id h212uHSU019475; Fri, 28 Feb 2003 18:56:18 -0800 X-Authentication-Warning: spratly.wl.nominum.com: bwelling owned process doing -bs Date: Fri, 28 Feb 2003 18:56:17 -0800 (PST) From: Brian Wellington X-X-Sender: bwelling@spratly.wl.nominum.com To: Rob Austein cc: namedroppers@ops.ietf.org Subject: Re: Q-6: May security-aware resolvers cache "Bad" data? In-Reply-To: <20030301002842.A696E18EC@thrintun.hactrn.net> Message-ID: References: <20030228201606.BCF9018EC@thrintun.hactrn.net> <20030301002842.A696E18EC@thrintun.hactrn.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,SUBJECT_MONTH,USER_AGENT_PINE, X_AUTH_WARNING version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 28 Feb 2003, Rob Austein wrote: > At Fri, 28 Feb 2003 15:22:54 -0800 (PST), Brian Wellington wrote: > > > > I'm not sure where negative caching fits into this. The RRsets returned > > as part of a valid negative response should all be verified; there's > > nothing in the negative reponse which would be classified as anything > > other than Authenticated. > > You're thinking of conventional negative response caching, for which > you are of course correct. > > The reference here was to kind of negative caching for which we don't > have a name yet, dealing with RRsets whose signatures are demonstrably > bad, so that the resolver can avoid performing the same (failing) > query and verification operations over and over again within a short > period of time. RFC 2535 appears to forbid this form of negative > caching and doesn't discuss the (potentially serious) implications of > doing so, hence the question. If that's what you mean, I'd suggest not using the term "negative caching", which is well defined (the caching of a negative response, where negative means either the host or type doesn't exist). I'd use a new term, like "failure caching". While forbidding failure caching might be going a bit far, caching failures is really not a good idea. It means that if a server receives a spoofed response, it will cache the data, and use the cached failure as an indication to not try again. This leads to obvious DoS attacks. Not caching failures has other problems (bandwidth amplification attacks), but the ability to spoof a server into caching failure is much worse. 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. archive: From owner-namedroppers@ops.ietf.org Fri Feb 28 23:29:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21996 for ; Fri, 28 Feb 2003 23:29:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18oyXP-000GpR-00 for namedroppers-data@psg.com; Fri, 28 Feb 2003 20:23:51 -0800 Received: from [2002:425c:4242:0:250:daff:fe82:1c39] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 18oyXJ-000GoS-00 for namedroppers@ops.ietf.org; Fri, 28 Feb 2003 20:23:48 -0800 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id C28E018EC for ; Fri, 28 Feb 2003 23:23:12 -0500 (EST) Date: Fri, 28 Feb 2003 23:23:12 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Q-6: May security-aware resolvers cache "Bad" data? In-Reply-To: <1046485410.10318.55.camel@error-messages.mit.edu> References: <20030228201606.BCF9018EC@thrintun.hactrn.net> <20030301002842.A696E18EC@thrintun.hactrn.net> <1046485410.10318.55.camel@error-messages.mit.edu> User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030301042312.C28E018EC@thrintun.hactrn.net> X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, SUBJECT_MONTH,USER_AGENT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I'm not really trying to have a debate here, the point was to ask the WG a question. However, since Greg's comments suggest that the context of the question may have been unclear, one clarification: At 28 Feb 2003 21:23:30 -0500, Greg Hudson wrote: > ... > It sounds like the text is trying to prevent a security-aware > caching server from providing bad responses to a stub resolver, and > that's important for people who want to use security aware local > caching recursive resolvers in concert with old native stub > resolvers. The text I'm asking about forbids the security-aware resolver itself from caching "Bad" data, regardless of what it's going to do with that data or whether it's ever going to send that data anywhere. What data a security-aware recursive name server is allowed to send to to a resolver is a separate matter, addressed elsewhere. As far as I know, nobody's suggesting that a security-aware recursive name server should send "Bad" data a response except perhaps when responding to a query with the CD bit turned on. Different issue. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: