From owner-namedroppers@ops.ietf.org Sun Jul 1 23:42:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA18212 for ; Sun, 1 Jul 2001 23:42:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15Gu9q-000683-00 for namedroppers-data@psg.com; Sun, 01 Jul 2001 20:13:54 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15Gu9p-00067x-00 for namedroppers@ops.ietf.org; Sun, 01 Jul 2001 20:13:53 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15Gu9p-000CCI-00 for namedroppers@ops.ietf.org; Sun, 01 Jul 2001 20:13:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Olafur Gudmundsson To: namedroppers@ops.ietf.org Subject: DNSEXT WGLC Obsoleting IQUERY Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sun, 01 Jul 2001 20:13:54 -0700 Content-Transfer-Encoding: 7bit This document obsoletes a section in RFC1035 that was optional. Operational experience has shown that IQUERY is not only bad it is real bad, thus the working group should make a statement on the issue by obsoleting this before anyone else implements it. No current implementations of DNS servers, resolvers are affected by this change. The last call will end on July 14'th. Olafur Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 2 10:32:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24526 for ; Mon, 2 Jul 2001 10:32:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15H4Vb-000Pa4-00 for namedroppers-data@psg.com; Mon, 02 Jul 2001 07:17:03 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15H4Va-000PZo-00 for namedroppers@ops.ietf.org; Mon, 02 Jul 2001 07:17:02 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15H4Va-000IJG-00 for namedroppers@ops.ietf.org; Mon, 02 Jul 2001 07:17:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roy Arends To: Miek Gieben Cc: Roy Arends , Jakob Schlyter , DNSEXT Subject: Re: draft-ietf-dnsext-delegation-signer-00 In-Reply-To: <20010628132630.A14552@atoom.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 02 Jul 2001 07:17:03 -0700 Content-Transfer-Encoding: 7bit On Thu, 28 Jun 2001, Miek Gieben wrote: > [On 27 Jun, 2001, Roy Arends wrote in " Re: draft-ietf-dnsext-delegation-signer-00 "] > > I would like to see some discussion on the idea of having a > > key-authentication-key (a master-key signs several production keys), this > > in light of "DS points to key that signs the keyset" vs "DS points to key > > that signs the child zone". > > > > In general there are 3 proposals now. DS, SIG@parent and the current > > SIG@child. As I see it, DS is an alternative to SIG@parent, with less of > as the author of sig@parent i must say, i like the idea of DS (let's > stick with that name) > > > the operational problems SIG@parent has. Next to that, the proposed > > master/production key scheme is interesting. > > agreed interesting, but it adds another level of complexity, do we > want that? It's a trade-off. A longer verification chain VS more frequent rollover. I favor a "less frequent rollover" and deal with the longer verification chain. I'm not sure though how more complex the resolver algorithm would be. Regards Roy Arends Nominum. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 2 10:32:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24525 for ; Mon, 2 Jul 2001 10:32:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15H4NE-000PJQ-00 for namedroppers-data@psg.com; Mon, 02 Jul 2001 07:08:24 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15H4NC-000PJK-00 for namedroppers@ops.ietf.org; Mon, 02 Jul 2001 07:08:22 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15H4NC-000I4c-00 for namedroppers@ops.ietf.org; Mon, 02 Jul 2001 07:08:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roy Arends To: Mark Kosters Cc: namedroppers@ops.ietf.org, dnssec@cafax.se Subject: Re: I-D ACTION:draft-ietf-dnsext-dnssec-opt-in-00.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 02 Jul 2001 07:08:24 -0700 Content-Transfer-Encoding: 7bit On Fri, 29 Jun 2001, Roy Arends wrote: > 2) To indicate opt-in, a bit is set in the flag-field of the zone KEY. > When I decide to sign the zone with an "opt-in" zone KEY and I sign the > zone with a vanilla zone KEY (I can sign the zone with more than 1 KEY), > there is no way of indicating how to create NXT RR. Would there be two NXT > RR, one for opt-in view, one for rfc2535-style ? This is in my opinion > very difficult to realise and probably breaks the scheme. Temporarily > signing with both keys might be necessary when I'm moving from a > rfc2535-style to opt-in-style or vice versa. The following scheme proposes a slightly different solution that does not require an allocation of a key's flag field bit, but uses bit zero of the NXT's type bit map to indicate wether the zone is signed in rfc2535-style or opt-in style. This solution allows a zone to have all 3 views, ie unsecure, rfc-2535 secured and opt-in secured. To the reader it might seem ambigu to have both styles of secured styles in a zone, though this is required during a key-rollover when an administrator decides to switch views. (it is not explicitly forbidden to have a NXT RRset with more then 1 NXT RR). In my opinion, it should be the NXT record itself rather than the KEY record to indicate how it should be interpreted. About the zero bit: rfc2535, section 5.2 mentions the zero bit. The first bit represents RR type zero (an illegal type which can not be present) and so will be zero in this format. This format is not used if there exists an RR with a type number greater than 127. If the zero bit of the type bit map is a one, it indicates that a different format is being used which will always be the case if a type number greater than 127 is present. As stated, if the type bit zero is a one, it indicates a different format. The different format in this case is the opt-in format. The null bit should be indicated with a value that is distinct from the RR types. The following example shows the rfc2535-style NXT: (zone: example.com.) alpha.example.com. NXT gamma.example.com. NS NXT DS It indicates that there exists nothing between alpha & gamma. The existing types for alpha are NS, NXT and DS. The following example shows the opt-in-style NXT: (zone: example.com.) alpha.example.com. NXT sigma.example.com. OO NXT DS It indicates that there exists nothing that was signed between alpha & sigma. The signed types for alpha are NXT and DS. Note that NS is never signed as delegation. The opt-in is indicated with OO. This flag always apears first as it is the null bit. Regards, Roy Arends Nominum to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 2 10:40:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29213 for ; Mon, 2 Jul 2001 10:40:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15H4eP-000Pss-00 for namedroppers-data@psg.com; Mon, 02 Jul 2001 07:26:09 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15H4eN-000Psl-00 for namedroppers@ops.ietf.org; Mon, 02 Jul 2001 07:26:07 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15H4eN-000IlY-00 for namedroppers@ops.ietf.org; Mon, 02 Jul 2001 07:26:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roy Arends To: Mats Dufberg Cc: Roy Arends , Mark Kosters , namedroppers@ops.ietf.org, dnssec@cafax.se Subject: Re: I-D ACTION:draft-ietf-dnsext-dnssec-opt-in-00.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 02 Jul 2001 07:26:09 -0700 Content-Transfer-Encoding: 7bit On Fri, 29 Jun 2001, Mats Dufberg wrote: > On Fri, 29 Jun 2001, Roy Arends wrote: > > > 4) If opt-in is generally conceived as a good idea, should backwards > > compatibility be enforced by also permitting rfc2535-style zones ? We are > > already searching for an alternative to sig@child, which is not backward > > compatible (though of a different level) with rfc2535, next to that, > > rfc2535 style zone's are not widely deployed. To my knowledge there are > > some testbeds (cairn, tislabs, sigz, nl.nl, etc) though I've not seen a > > full deployment of DNSSEC. > > I find the opt-in alternative a goot suggestion, which will ease the > deployment of DNSsec. But it would be a bad idea not to have the full NXT > (as defined in RFC 2535). > > During the transition period we will have zone with mixed data (both > signed and unsigned), but eventually there will be fully signed (secured) > subtrees. > > If you have a fully signed tree there is not much (if any) gained from > the opt-in alternative, but you will not have the fully authenticated > denial of existence, which means that a fake non-secured subdomain can be > spoofed. Note that a malicious user has little if not nothing to gain by faking a delegation (as in creating a domain that until now did not exist). In general, a malicious user would want to spoof an existing domain. A secured existing domain can not be spoofed (regardless if the zone was opt-in or rfc2535 signed). An unsecured existing domain can always be spoofed (regardless if the zone was opt-in or rfc2535 signed), because glue will never be signed. > Opt-in is good only if full NXT is kept. Backwards compatibility is no problem, as long as the ambiguity in the NXT record has to be solved (and I think then using a bit in the KEY does not solve that). Regards Roy Arends Nominum to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 2 11:16:17 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26065 for ; Mon, 2 Jul 2001 11:16:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15H5Bf-00017M-00 for namedroppers-data@psg.com; Mon, 02 Jul 2001 08:00:31 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15H5Be-00017G-00 for namedroppers@ops.ietf.org; Mon, 02 Jul 2001 08:00:30 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15H5Be-000KTN-00 for namedroppers@ops.ietf.org; Mon, 02 Jul 2001 08:00:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Matt Crawford To: Olafur Gudmundsson Cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC Obsoleting IQUERY In-reply-to: "01 Jul 2001 20:13:54 PDT." Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 02 Jul 2001 08:00:31 -0700 Content-Transfer-Encoding: 7bit (The file name, by the way, is draft-ietf-dnsext-obsolete-iquery-01.txt.) I support what this document tries to accomplish, but on reflection, its statement that RFC 1035 sections 4.1.1 and 6.4 are changed. and subsequent claims that 1035 itself is altered are incompatible with the fact that an RFC itself is never changed. Small tweaks would make process-purists happier, I think: *** draft-ietf-dnsext-obsolete-iquery-01.txt Mon Jul 2 08:55:25 2001 --- /tmp/suggest-02.txt Mon Jul 2 09:09:59 2001 *************** *** 108,114 **** 1.2 - Updated documents and sections ! RFC 1035 sections 4.1.1 and 6.4 are changed. 2 - New text for RFC 1035. --- 108,115 ---- 1.2 - Updated documents and sections ! RFC 1035, section 4.1.1 is superseded in part and section 6.4 is ! entirely superseded. 2 - New text for RFC 1035. *************** *** 116,127 **** "1 an inverse query (IQUERY)" ! Is is amended to read: "1 an inverse query (IQUERY) (obsolete)" Section 6.4, including all subsections, of RFC 1035 should be ! considered obsolete and not to be implemented. It is changed to read as follows: "Inverse queries using the IQUERY opcode were originally described --- 117,128 ---- "1 an inverse query (IQUERY)" ! It is amended to read: "1 an inverse query (IQUERY) (obsolete)" Section 6.4, including all subsections, of RFC 1035 should be ! considered obsolete and not implemented. It is now considered to read as follows: "Inverse queries using the IQUERY opcode were originally described to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 2 14:57:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21150 for ; Mon, 2 Jul 2001 14:57:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15H8e8-0007ZI-00 for namedroppers-data@psg.com; Mon, 02 Jul 2001 11:42:08 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15H8e7-0007ZC-00 for namedroppers@ops.ietf.org; Mon, 02 Jul 2001 11:42:07 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15H8e7-0005I4-00 for namedroppers@ops.ietf.org; Mon, 02 Jul 2001 11:42:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: gson@nominum.com (Andreas Gustafsson) To: namedroppers@ops.ietf.org CC: "D. J. Bernstein" Subject: Re: DNSEXT WGLC AXFR-02 SHORT last call In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 02 Jul 2001 11:42:08 -0700 Content-Transfer-Encoding: 7bit D. J. Bernstein writes: > I have glanced at the summary of changes provided in the last call. It > seems that several of my objections have been ignored. They were not ignored. They were considered and rejected. -- Andreas Gustafsson, gson@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 2 16:35:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22993 for ; Mon, 2 Jul 2001 16:35:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15HA66-000Am6-00 for namedroppers-data@psg.com; Mon, 02 Jul 2001 13:15:06 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15HA64-000Alz-00 for namedroppers@ops.ietf.org; Mon, 02 Jul 2001 13:15:05 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15HA64-0009s5-00 for namedroppers@ops.ietf.org; Mon, 02 Jul 2001 13:15:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Olafur Gudmundsson/DNSEXT co-chair To: "D. J. Bernstein" , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC AXFR-02 SHORT last call In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 02 Jul 2001 13:15:06 -0700 Content-Transfer-Encoding: 7bit At 10:17 PM 6/30/2001, D. J. Bernstein wrote: >Where did the WG chairs get this ``SHORT last call'' idea from? > >This draft was announced on 22 June. The WG chairs, without giving us >any extra time to review the draft, announced a ``SHORT last call'' >ending on 30 June. > >I've just returned from vacation. I haven't seen the draft yet. I object >to this absurd last-call schedule. so you want more time, you got through the 6'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. From owner-namedroppers@ops.ietf.org Tue Jul 3 07:30:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA14843 for ; Tue, 3 Jul 2001 07:30:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15HNz6-0008PR-00 for namedroppers-data@psg.com; Tue, 03 Jul 2001 04:04:48 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15HNz5-0008PB-00 for namedroppers@ops.ietf.org; Tue, 03 Jul 2001 04:04:47 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15HNz5-0000YN-00 for namedroppers@ops.ietf.org; Tue, 03 Jul 2001 04:04:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Miek Gieben To: Roy Arends Cc: Miek Gieben , Jakob Schlyter , DNSEXT Subject: Re: draft-ietf-dnsext-delegation-signer-00 In-Reply-To: ; from Roy.Arends@nominum.com on Mon, Jul 02, 2001 at 07:17:03AM -0700 References: <20010628132630.A14552@atoom.net> X-Home: www.miek.nl Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 03 Jul 2001 04:04:48 -0700 Content-Transfer-Encoding: 7bit [On 02 Jul, 2001, Roy Arends wrote in " Re: draft-ietf-dnsext-delegation-signer-00 "] > > > the operational problems SIG@parent has. Next to that, the proposed > > > master/production key scheme is interesting. > > > > agreed interesting, but it adds another level of complexity, do we > > want that? > > It's a trade-off. A longer verification chain VS more frequent rollover. I > favor a "less frequent rollover" and deal with the longer verification > chain. I'm not sure though how more complex the resolver algorithm would > be. i'm not only talking about the resolver complexity, we can deal with that. The thing i'm a little bit worried about is how do we explain this all to the common man...you have production keys, zone keys, host keys. Aren't we making it a bit too difficult? grtz Miek NLnet Labs to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 3 11:30:03 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08912 for ; Tue, 3 Jul 2001 11:30:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15HRn4-000Fv3-00 for namedroppers-data@psg.com; Tue, 03 Jul 2001 08:08:38 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15HRn2-000Fux-00 for namedroppers@ops.ietf.org; Tue, 03 Jul 2001 08:08:36 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15HRn2-000CKN-00 for namedroppers@ops.ietf.org; Tue, 03 Jul 2001 08:08:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "Scott Rose" To: "Miek Gieben" , "Roy Arends" Cc: "Jakob Schlyter" , "DNSEXT" Subject: Re: draft-ietf-dnsext-delegation-signer-00 References: <20010628132630.A14552@atoom.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 03 Jul 2001 08:08:38 -0700 Content-Transfer-Encoding: 7bit > [On 02 Jul, 2001, Roy Arends wrote in " Re: draft-ietf-dnsext-delegation-signer-00 "] > > > > the operational problems SIG@parent has. Next to that, the proposed > > > > master/production key scheme is interesting. > > > > > > agreed interesting, but it adds another level of complexity, do we > > > want that? > > > > It's a trade-off. A longer verification chain VS more frequent rollover. I > > favor a "less frequent rollover" and deal with the longer verification > > chain. I'm not sure though how more complex the resolver algorithm would > > be. > i'm not only talking about the resolver complexity, we can deal with > that. The thing i'm a little bit worried about is how do we explain > this all to the common man...you have production keys, zone keys, > host keys. Aren't we making it a bit too difficult? > There is a learning curve on something that was more simple, but it is not too difficult (the fact that things had worked at the workshops point to that). Most DNS admins will be able to manage zone and host keys, but I doubt most small operators will even bother with production keys. I doubt most part-time admins will even bother rolling keys over on a set schedule, unless easy to use tools are made available. my $.02 ($.012 after taxes) 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. From owner-namedroppers@ops.ietf.org Tue Jul 3 15:43:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17324 for ; Tue, 3 Jul 2001 15:43:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15HViO-000NcO-00 for namedroppers-data@psg.com; Tue, 03 Jul 2001 12:20:04 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15HViN-000NcE-00 for namedroppers@ops.ietf.org; Tue, 03 Jul 2001 12:20:03 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15HViN-000OIT-00 for namedroppers@ops.ietf.org; Tue, 03 Jul 2001 12:20:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roy Arends To: Mark Kosters Cc: Roy Arends , , Subject: Re: I-D ACTION:draft-ietf-dnsext-dnssec-opt-in-00.txt In-Reply-To: <20010703143138.A779@netsol.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 03 Jul 2001 12:20:04 -0700 Content-Transfer-Encoding: 7bit On Tue, 3 Jul 2001, Mark Kosters wrote: > On Fri, Jun 29, 2001 at 07:30:48AM +0200, Roy Arends wrote: > > 1) wrt opt-in, a NXT record indicates that a delegation is not secured by > > specifying the signed owner name before and after the unsecured owner > > name. Thus it indicates "authenticated denial of security" instead of > > "authenticated denial of existence". Should the type bit map interpreted > > as "type does not exist" or "type is not signed" ? > > The type bits in the NXT are as stated in rfc2535 showing that there is > existence of RR's in the opt-in view (just like rfc2535). I'm not really > sure if this should be changed. Can you think of a reason that we should > change the semantics of the type bits for opt-in? If the semantics for type bit map are not changed, when using the opt-in view the type bit map could state there is an existing RR record, which is not signed, so it does NOT exist in the opt-in view. The semantics is with regards to the NXT type, in rfc-2535 it is defined for non-existance of names and types. Your draft mentions the change for labels, but not for types. In rfc 2535 there is only one semantic wrt NXT and I see the Labels and Types as attributes. I assumed, when the draft stated "Since the opt-in model changes the semantics of the NXT RR", this was for the 2535-semantics, not specifically for labels only. I think the draft should be more specific on NXT in full, not only about labels. > > 2) To indicate opt-in, a bit is set in the flag-field of the zone KEY. > > When I decide to sign the zone with an "opt-in" zone KEY and I sign the > > zone with a vanilla zone KEY (I can sign the zone with more than 1 KEY), > > there is no way of indicating how to create NXT RR. Would there be two NXT > > RR, one for opt-in view, one for rfc2535-style ? This is in my opinion > > very difficult to realise and probably breaks the scheme. Temporarily > > signing with both keys might be necessary when I'm moving from a > > rfc2535-style to opt-in-style or vice versa. > > We didn't envision having an intermediate state between rfc2535 and opt-in. > One can follow the usual approach to change from type to type by cranking down > the ttls to make this change on the affected RR's and resign the zones > including all the unsigned RR's rfc2535-style. > > The opt-in view by itself looks like a perfectly valid rfc2535 zone, only > it does not contain any unsecured delegations. It is only when the > authoritative opt-in resolver combines the opt-in view with the non-dnssec > view in its response does the meaning of the NXT record change. The type > bits do not have to be changed. When talking about opt-in views/non-dnssec view, it seems that there are actually two zone's, one containing secured RRsets (opt-in), the other all (non-dnssec). It is more conceivable to state that there is only one zone. A nameserver serves the DNSSEC RRsets (KEY/SIG/NXT/DS) only when DO is set in the query. Nothing has to be written about combining views. When the zone is partially signed, call it opt-in, when it is fully signed, call it rfc2535-style. This is not just semantics. With two views I've to xfer zones twice, one with and one without the DO option. I rather do one xfer with DO set, and get one zone. > > 3) Should we extend "authenticated denial of security" for unsecure > > delegations (as specified in the draft) to any RRset ? > > I'm sure one can do this if they wish. Perfect, but then we should change the type-bit-map semantics as well. > > 4) If opt-in is generally conceived as a good idea, should backwards > > compatibility be enforced by also permitting rfc2535-style zones ? We are > > already searching for an alternative to sig@child, which is not backward > > compatible (though of a different level) with rfc2535, next to that, > > rfc2535 style zone's are not widely deployed. To my knowledge there are > > some testbeds (cairn, tislabs, sigz, nl.nl, etc) though I've not seen a > > full deployment of DNSSEC. > > I think that having to maintain backward capability defeats the purpose of > opt-in. Your right in that we have not had full deployment yet so I guess > I see backwards compatility as a very small issue. I see it as follows: rfc2535-style: zone is fully signed. opt-in-style : zone is partly signed. wrt to NXT: rfc-2535-style: NXT indicates non-existence. opt-in-style : NXT indicates not-signed. I would go for: One zone, DO bit to indicate a resolver can handle DNSSEC (aka DNSSEC view). 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. From owner-namedroppers@ops.ietf.org Tue Jul 3 16:15:48 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18438 for ; Tue, 3 Jul 2001 16:15:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15HWEq-000OwC-00 for namedroppers-data@psg.com; Tue, 03 Jul 2001 12:53:36 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15HWEo-000Ow6-00 for namedroppers@ops.ietf.org; Tue, 03 Jul 2001 12:53:34 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15HWEo-000PxM-00 for namedroppers@ops.ietf.org; Tue, 03 Jul 2001 12:53:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Olafur Gudmundsson To: Roy Arends , Mark Kosters Cc: namedroppers@ops.ietf.org, dnssec@cafax.se Subject: Re: I-D ACTION:draft-ietf-dnsext-dnssec-opt-in-00.txt In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 03 Jul 2001 12:53:36 -0700 Content-Transfer-Encoding: 7bit At 10:08 AM 7/2/2001, Roy Arends wrote: >On Fri, 29 Jun 2001, Roy Arends wrote: > >In my opinion, it should be the NXT record itself rather than the KEY >record to indicate how it should be interpreted. > >About the zero bit: > >rfc2535, section 5.2 mentions the zero bit. > > The first bit represents RR type zero (an illegal type which > can not be present) and so will be zero in this format. This format > is not used if there exists an RR with a type number greater than > 127. If the zero bit of the type bit map is a one, it indicates that > a different format is being used which will always be the case if a > type number greater than 127 is present. > >As stated, if the type bit zero is a one, it indicates a different format. >The different format in this case is the opt-in format. This bit is off limits to any use but to extend NXT to types with code > 127. If you want to use a bit in NXT to define Opt-in there are few type codes that I can pull out of the hat to do that from the low number bits (SINK, MB, etc.) or we just reserve a new type code for this. Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 3 16:21:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18631 for ; Tue, 3 Jul 2001 16:21:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15HWO3-000PFT-00 for namedroppers-data@psg.com; Tue, 03 Jul 2001 13:03:07 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15HWO1-000PFN-00 for namedroppers@ops.ietf.org; Tue, 03 Jul 2001 13:03:05 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15HWO1-0000RC-00 for namedroppers@ops.ietf.org; Tue, 03 Jul 2001 13:03:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roy Arends To: Mark Kosters Cc: Jakob Schlyter , DNSEXT , Subject: Re: I-D ACTION:draft-ietf-dnsext-dnssec-opt-in-00.txt In-Reply-To: <20010703143902.C779@netsol.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 03 Jul 2001 13:03:07 -0700 Content-Transfer-Encoding: 7bit On Tue, 3 Jul 2001, Mark Kosters wrote: > On Fri, Jun 29, 2001 at 06:39:23PM +0200, Jakob Schlyter wrote: > > I think the opt-in flag should be moved to a separate RR, a modified > > version of Ed Lewis SEC RR would probably we a good choice (although I > > would perhaps like to call it ZSS for Zone Security Status instead). > > I agree with having some sort of way of indicating the type of dnssec > that is offered by that particular zone. This would also help with the > NXT/NO problem as well. We used an unused bit in the KEY RR for opt-in > given there was no other alternative. One could allocate a type-bit > 127 to be put in NXT (with RR-type bit zero set to 1) to indicate different format. There is no NXT/NO problem that has to be solved by SEC. Both RR types can be in a zone, the server serves it, the resolver interprets it. I don't see why a SEC record should indicate that there are NO records in a zone or NXT records in zone. The response clearly has either NXT or NO in its response. (The only reason for a SEC record I can think of is to indicate that there are neither NO nor NXT records. That would obsolete opt-in all together) Note that this is not a "what to expect" thing. If the parent states that a child is signed, the resolver expects either NXT or NO. (NO RR is still draft ofcourse). It is a chicken or egg thing. If there exists no SEC RR for the child, it gets either NXT or NO. > > the opt-in flag is a per zone flag. as there could be multiple zone keys > > and if KEY would include this flag, all zone keys has to have the same > > flag (for that bit). also, as the zone key are signed by the parent, the > > child can not change from/to opt-in without having the parent sign the > > child's key. > > That brings up a question. Is it better or worse for this to be stored in the > parent so the resolver knows what type of zone it is dealing with before it > queries the child? When there is no indication in the NXT record if it is opt-in or rfc-2535 style, one has the KEY (bit 4 in flag field) to indicate it with. IE One already knows, _before_ quering a child what to expect. Again, no uses for SEC here. I would opt :-) for an opt-in indication in NXT by using a type-bit > 127. Regards, Roy Arends Nominum to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 3 16:31:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18876 for ; Tue, 3 Jul 2001 16:31:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15HWZM-000Pfz-00 for namedroppers-data@psg.com; Tue, 03 Jul 2001 13:14:48 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15HWZK-000Pft-00 for namedroppers@ops.ietf.org; Tue, 03 Jul 2001 13:14:46 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15HWZJ-00010I-00 for namedroppers@ops.ietf.org; Tue, 03 Jul 2001 13:14:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roy Arends To: Olafur Gudmundsson Cc: Roy Arends , Mark Kosters , , Subject: Re: I-D ACTION:draft-ietf-dnsext-dnssec-opt-in-00.txt In-Reply-To: <5.1.0.14.2.20010703154610.02589720@localhost> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 03 Jul 2001 13:14:48 -0700 Content-Transfer-Encoding: 7bit On Tue, 3 Jul 2001, Olafur Gudmundsson wrote: > At 10:08 AM 7/2/2001, Roy Arends wrote: > >On Fri, 29 Jun 2001, Roy Arends wrote: > > > >In my opinion, it should be the NXT record itself rather than the KEY > >record to indicate how it should be interpreted. > > > >About the zero bit: > > > >rfc2535, section 5.2 mentions the zero bit. > > > > The first bit represents RR type zero (an illegal type which > > can not be present) and so will be zero in this format. This format > > is not used if there exists an RR with a type number greater than > > 127. If the zero bit of the type bit map is a one, it indicates that > > a different format is being used which will always be the case if a > > type number greater than 127 is present. > > > >As stated, if the type bit zero is a one, it indicates a different format. > >The different format in this case is the opt-in format. > > This bit is off limits to any use but to extend NXT to types with code > 127. > If you want to use a bit in NXT to define Opt-in there are few type codes > that I can pull out of the hat to do that from the low number bits (SINK, > MB, etc.) or we just reserve a new type code for this. Perfect. We could even use a bit >127 then. Regards, Roy Arends Nominum to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 3 16:43:12 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19172 for ; Tue, 3 Jul 2001 16:43:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15HWnu-0000Hs-00 for namedroppers-data@psg.com; Tue, 03 Jul 2001 13:29:50 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15HWnt-0000Hl-00 for namedroppers@ops.ietf.org; Tue, 03 Jul 2001 13:29:49 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15HWnt-0001kg-00 for namedroppers@ops.ietf.org; Tue, 03 Jul 2001 13:29:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "Scott Rose" To: , "DNSEXT WG Mailing list" Subject: I-D ACTION:draft-ietf-dnsext-dnssec-opt-in-00.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 03 Jul 2001 13:29:50 -0700 Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Scott Rose" To: "Roy Arends" Sent: Tuesday, July 03, 2001 4:23 PM Subject: Re: I-D ACTION:draft-ietf-dnsext-dnssec-opt-in-00.txt > > On Tue, 3 Jul 2001, Olafur Gudmundsson wrote: > > > > > At 10:08 AM 7/2/2001, Roy Arends wrote: > > > >On Fri, 29 Jun 2001, Roy Arends wrote: > > > > > > > >In my opinion, it should be the NXT record itself rather than the KEY > > > >record to indicate how it should be interpreted. > > > > > > > >About the zero bit: > > > > > > > >rfc2535, section 5.2 mentions the zero bit. > > > > > > > > The first bit represents RR type zero (an illegal type which > > > > can not be present) and so will be zero in this format. This > format > > > > is not used if there exists an RR with a type number greater > than > > > > 127. If the zero bit of the type bit map is a one, it > indicates that > > > > a different format is being used which will always be the case > if a > > > > type number greater than 127 is present. > > > > > > > >As stated, if the type bit zero is a one, it indicates a different > format. > > > >The different format in this case is the opt-in format. > > > > > > This bit is off limits to any use but to extend NXT to types with code > > 127. > > > If you want to use a bit in NXT to define Opt-in there are few type > codes > > > that I can pull out of the hat to do that from the low number bits > (SINK, > > > MB, etc.) or we just reserve a new type code for this. > > > > Perfect. We could even use a bit >127 then. > > If the group decides to use a bit to determine the opt-in status (I haven't decided if I like the idea or not - right now I'm leaning towards "not" but don't have a better solution yet) - let's pick an unused number to avoid any potential messy bugs with oddball zonefiles that may use exotic RR types (like LOC, RP, etc). Just to be safe, and there are numbers to spare. 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. From owner-namedroppers@ops.ietf.org Tue Jul 3 18:10:55 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03088 for ; Tue, 3 Jul 2001 18:10:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15HYBy-0002nG-00 for namedroppers-data@psg.com; Tue, 03 Jul 2001 14:58:46 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15HYBw-0002n8-00 for namedroppers@ops.ietf.org; Tue, 03 Jul 2001 14:58:44 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15HYBw-000649-00 for namedroppers@ops.ietf.org; Tue, 03 Jul 2001 14:58:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Bill Manning To: sra@hactrn.net (Rob Austein) Cc: namedroppers@ops.ietf.org Subject: Re: RFC 2782: SRV naming convention In-Reply-To: <20010629145246Z23616-9152+45@thrintun.hactrn.net> from "Rob Austein" at Jun 29, 2001 10:52:38 AM Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 03 Jul 2001 14:58:46 -0700 Content-Transfer-Encoding: 7bit % DNS itself makes no promises at all about ordering of RRs within an % RRset, so a name server can present the RRs in any order it likes. Don't current DNSSEC implementations and specifications change this "promise"? % Hope this clarifies things a bit. % % --Rob --bill ps: this e-mail is not in accordance with the all requirements of section 10 of RFC2026 ... in particular, I haven't given due credit to those who taught me to read and write (frankly, I don't remember who they were), and vast numbers of other people, all of whom contributed to my getting to where I am today... However, I make no copyright claims to it, use it how you will. I also have no patents, pending or issued, on any of the technology (or ever ideas) discussed herein. "IETF" might be a trade mark, so might "RFC", but they don't belong 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. From owner-namedroppers@ops.ietf.org Tue Jul 3 20:38:48 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00794 for ; Tue, 3 Jul 2001 20:38:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15HaP3-0007fe-00 for namedroppers-data@psg.com; Tue, 03 Jul 2001 17:20:25 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15HaP1-0007fX-00 for namedroppers@ops.ietf.org; Tue, 03 Jul 2001 17:20:23 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15HaP1-000CvD-00 for namedroppers@ops.ietf.org; Tue, 03 Jul 2001 17:20:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Stuart Cheshire To: , "DHCPv4 discussion list" Subject: Re: I-D ACTION:draft-guttman-dhc-mdns-enable-00.txt Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 03 Jul 2001 17:20:25 -0700 Content-Transfer-Encoding: 7bit >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > Title : DHCP mDNS Enable Option > Author(s) : E. Guttman > Filename : draft-guttman-dhc-mdns-enable-00.txt > Pages : > Date : 27-Jun-01 I'm generally uneasy about the apparently unending process our community has, of repeatedly stuffing "just one more" configuration option into DHCP packets, with no end in sight. However, with that caveat stated, two comments: 1. I think we all agree now that it is not a good idea to use the search list to control anything other than strings to be appended to unqualified names. Any implicit semantics associated with whether a particular string is in the search list or not is confusing. I think the sections of this draft dealing with why overloading the search list is a bad idea, can be safely deleted. 2. Instead of an 'order' byte and a 'scopes' bitfield, how about this: The option consists of a sequence of zero or more bytes, indicating the allowable scopes and the order in which they are to be tried. A byte with value zero means unicast. A byte with value one means link-local multicast. A byte with value two means site-local multicast, etc. That way, if we want, any number of scopes can be specified in any arbitrary order. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.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. From owner-namedroppers@ops.ietf.org Tue Jul 3 20:38:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00918 for ; Tue, 3 Jul 2001 20:38:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15HaQE-0007jM-00 for namedroppers-data@psg.com; Tue, 03 Jul 2001 17:21:38 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15HaQC-0007j0-00 for namedroppers@ops.ietf.org; Tue, 03 Jul 2001 17:21:36 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15HaQC-000Cyn-00 for namedroppers@ops.ietf.org; Tue, 03 Jul 2001 17:21:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Bernard Aboba To: namedroppers@ops.ietf.org cc: aboba@internaut.com, erik.guttman@sun.com, cheshire@apple.com, levone@microsoft.com, dthaler@microsoft.com, bernarda@microsoft.com Subject: Resolution of proposed changes to mDNS-00 draft Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 03 Jul 2001 17:21:38 -0700 Content-Transfer-Encoding: 7bit Based on the vigorous discussion we've had over the last month or so, we've gone back and tried to summarize many of the recommended changes to the mDNS-00 draft, and the proposed resolutions. Find enclosed a list of proposed changes and recommended resolutions. In this list we've included changes for which we had specific editing instructions and substitute text so that we could understand exactly what text to modify if the change was accepted. If an item is not on the list, it's probably because it is controversial or a large item that is not easily encapsulated in a few paragraphs of recommended edits. An example is mDNS configuration. For this one, we felt that the best approach was for someone to come up with an alternate proposal in order to help facilitate the discussion. Erik Guttman has graciously volunteered to act as lightening rod. Thanks, Erik! In the list "Accept" recommendations are made for changes that we believed had consensus. "Discuss" recommendations are for changes that may need more discussion before coming up with a resolution and/or final text. ======================================================================== Recommended resolution of proposed changes to draft-ietf-dnsext-mdns-00.txt ------------------------------------------------------------------------ Section 1 Submitted by: Erik Guttman, Dave Thaler Justification: existing language does not specify possible limitations of the current approach. Change: " This extension to the DNS protocol consists of a single change to the method of use, and no change to the current format of DNS packets. Namely, this extension allows multicast DNS queries to be sent to and received on port 53 using the LINKLOCAL addresses [2] for IPv4 and IPv6 (below referred as the LINKLOCAL address), which are yet to be assigned by IANA. LINKLOCAL addresses are used to prevent propagation of multicast DNS traffic across routers, potentially flooding the network. Propagation of multicast DNS packets within the local subnet is considered sufficient to enable DNS name resolution, since the expectation is that if a network has a router, then this router can function as a DNS proxy, possibly implementing dynamic DNS. Thus there is not expected to be a need for multicast DNS in networks with multiple subnets." to: " This extension to the DNS protocol consists of a single change to the method of use, and no change to the current format of DNS packets. Namely, this extension allows multicast DNS queries to be sent to and received on port 53. The messages are sent using the LINKLOCAL addresses [2] for IPv4 and IPv6 (below referred as the LINKLOCAL address), which are yet to be assigned by IANA. LINKLOCAL addresses are used to prevent propagation of multicast DNS traffic across routers, potentially flooding the network. Propagation of multicast DNS packets within the local subnet is considered sufficient to enable DNS name resolution in small adhoc networks. The assumption is that if a network has a router, then the network either has a DNS server or the router can function as a DNS proxy, possibly implementing dynamic DNS. In the future, mDNS may be defined to support greater than LINKLOCAL multicast scope. This would occur if LINKLOCAL mDNS deployment is successful, the assumption that mDNS is not needed in multiple subnets proves incorrect, and multicast routing becomes ubiquitous. For example, it is not clear that this assumption will be valid in large adhoc networking scenarios. Once we have experience in mDNS deployment in terms of administrative issues, usability and impact on the network it will be possible reevaluate which multicast scopes are appropriate for use with mDNS." Proposed Resolution: Accept -------------------------------------------------------------------- Section 2: Submitted by: Brian Zill Justification: Use of the solicited node multicast addresses for mDNS would reduce the multicast traffic handled by any particular node. Change: "Namely, this extension allows multicast DNS queries to be sent to and received on port 53 using the LINKLOCAL addresses [2] for IPv4 and IPv6 (below referred as the LINKLOCAL address), which are yet to be assigned by IANA." To: "This extension allows multicast DNS queries to be sent to and received on port 53 using a LINKLOCAL address [2] for IPv4 and the "solicited node" LINKLOCAL multicast addresses for IPv6." Proposed Resolution: Discuss ---------------------------------------------------------------- Submitted by: Erik Guttman, Dave Thaler Justification: Current language does not fully specify retransmission behavior. "If the multicast query is not positively resolved ("positively resolved" refers in this document to a response with the RCODE set to 0) during a limited amount of time, then a sender MAY repeat the transmission of a query in order to assure themselves that the query has been received by a host capable of responding to the query. Repetition MUST NOT be attempted more than 5 times, and the repetition SHOULD NOT be repeated more often than once per 0.1 seconds to reduce unnecessary network traffic. Retry intervals SHOULD be exponentially increased." Change to: "If the multicast query is not positively resolved ("positively resolved" refers in this document to a response with the RCODE set to 0) during a limited amount of time, then a sender MAY repeat the transmission of a query in order to assure themselves that the query has been received by a host capable of responding to the query. Repetition MUST NOT be attempted more than 3 times and SHOULD NOT be repeated more often than once per second to reduce unnecessary network taffic. Retry intervals SHOULD be exponentially increased, starting from a value of 1 second." Proposed resolution: Accept ---------------------------------------------------------------- Section 2.1 Submitted by: Erik Guttman, Levon Esibov Justification: Error reply implosion possible with current text. To the following paragraph: "A response to a multicast query is composed in exactly the same manner as a response to the unicast DNS query as specified in [4]. Responders MUST never respond using cached data, and the AA (Authoritative Answer) bit MUST be set. The response is sent to the sender via unicast." add: "A response to an mDNS query MUST have RCODE set to zero, since mDNS responders MUST NOT send error replies in response to multicast requests." Proposed resolution: Accept ------------------------------------------------------------------------ Submitted by: Dave Thaler Justification: Current text does not address the API issues involved with setting and checking of TTL. "The responder MUST set the Hop Limit field in the IPv6 header and the TTL field in IPv4 header of all multicast DNS query responses to 255. The sender MUST verify that the Hop Limit field in the IPv6 header and the TTL field in the IPv4 header of each response to the multicast DNS query is set to 255. If it is not, then the sender MUST ignore such a response." Change to: "For IPv4 LINKLOCAL addressing, section 2.4 of [6] lays out the rules with respect to source address selection, TTL settings, and acceptable source/destination address combinations. IPv6 LINKLOCAL addressing is described in [9]. mDNS queries and responses MUST obey the rules laid out in these documents. In composing an mDNS response, the responder MUST set the Hop Limit field in the IPv6 header and the TTL field in IPv4 header of the multicast DNS response to 255. The sender MUST verify that the Hop Limit field in IPv6 header and TTL field in IPv4 header of each response to the multicast DNS query is set to 255. If it is not, then sender MUST ignore the response. Implementation note: In the sockets API for IPv4, the IP_TTL and IP_MULTICAST_TTL socket options are used to specify the TTL of outgoing unicast and multicast packets. The IP_RECVTTL socket option is available on some platforms to receive the IPv4 TTL of received packets with recvmsg(). RFC 2292 specifies similar options for specifying and receiving the IPv6 Hop Limit. " Proposed Resolution: Accept Note from Dave: BTW, the IP_RECVTTL option seems to exist currently in Linux but not in BSD. Don't know about any other OSes. There's nothing referencable that I can find, but anyone who does a search on the web for it can easily find the Linux man page that covers it. ------------------------------------------------------------------------ Submitted by: Erik Guttman Justification: Specification of the cache period is unnecessary. Change: "If no positive response is received, a resolver treats it as a response that no records of the specified type and class for the specified name exist (NXRRSET), which SHOULD be cached for a period that SHOULD NOT exceed 5 seconds." To: "If no positive response is received, a resolver treats it as a response that no records of the specified type and class for the specified name exist (NXRRSET)." Proposed resolution: Accept ------------------------------------------------------------------------- Section 3 Submitted by: Bernard Aboba Justification: current text is confusing and contradictory In the paragraph: "If a DNS server is running on a host, the host MUST NOT listen for multicast DNS queries, to prevent the host from listening on port 53 and intercepting DNS queries directed to a DNS server. A DNS server MAY listen and respond to multicast queries. By default, a DNS server MUST NOT listen to multicast DNS queries. For a DNS server, the presence of ".local.arpa." in the domain search list MUST NOT enable multicast DNS." Remove the sentence: "A DNS server MAY listen and respond to multicast queries." Proposed resolution: Accept -------------------------------------------------------------------- Section 4 Submitted by: Bernard Aboba Justification: Current text does not cover addressing limitations. "3. Upon the reception of the response, the sender verifies that the Hop Limit field in IPv6 header or TTL field in IPv4 header (depending on the protocol used) of the response is set to 255. Change to: 3. Upon the reception of the response, the sender verifies that the Hop Limit field in IPv6 header or TTL field in IPv4 header (depending on the protocol used) of the response is set to 255. If the destination address is a LINKLOCAL address, then the sender verifies use of a LINKLOCAL source address. If these conditions are met, then the sender uses and caches the returned response. If not, then the sender ignores the response and continues waiting for the response. Proposed resolution: Accept ------------------------------------------------------------------- Section 5 Submitted by : Levon Esibov Justification: Use of dynamic update for conflict detection is a cleaner approach. Change: "The uniqueness of the host DNS name MUST be verified when a host boots, when its name is changed, or when it is configured to use multicast DNS (such as when the domain search option is changed to include ".local.arpa."). A gratuitous name resolution query SHOULD be done to check for a name conflict. This is done by having the resolver send a multicast query of type SOA for its own name (i.e. for the name it is authoritative for). If the query is not positively resolved then the host assumes authority for the name. If the query is positively resolved, then the host should verify that the name specified in the RDATA of the SOA record in the answer section of the response is its own host name. If the host verifies this, then it assumes authority for its name. If the returned name does not match its host name, then a conflict has been detected. In order to resolve the name conflict, the host will change its name. A host that has detected a name conflict MUST NOT use the name. This means that the host MUST NOT respond to multicast queries for that name and MUST NOT respond to other multicast queries with resource records within the RDATA field that contain the conflicted name (for example, the PTR record). Note that this name conflict detection mechanism doesn't prevent name conflicts when previously partitioned segments are connected by a bridge. In such a situation, name conflicts are detected when a sender receives more than one response to its multicast DNS query. In this case, the sender sends the first response that it received to all responders that responded to this query except the first one, using unicast. A host that receives a response to a query for its own name, even if it didn't send such a query, sends a multicast query for the SOA record of the name that it is authoritative for. Based on the response, the host detects the name conflict and acts according to the description above." To: "There are some scenarios when multiple responders MAY respond to the same query. There are other scenarios when only one responder may respond to a query. Resource records for which the latter queries are submitted are referred to as UNIQUE throughout this document. The uniqueness of a resource record depends on a nature of the name in the query and type of the query. For example it is expected that - multiple hosts may respond to a query for a SRV type record - multiple hosts may respond to a query for an A type record for a cluster name (assigned to multiple hosts in the cluster) - only a single host may respond to a query for an A type record for a hostname. Every responder that responds to a multicast DNS query and/or dynamic update request AND includes a UNIQUE record in the response MUST: 1. Verify that there is no other host within the scope of the multicast DNS query propagation that can return a DNS record for the same name, type and class. 2. Responders MUST NOT include a UNIQUE resource record in the response without having verified its uniqueness. Where a host is configured to respond to multicast DNS queries on more than one interface, the host MUST verify resource record uniqueness on each interface for each UNIQUE resource record that could be used on that interface. To accomplish this, the host MUST multicast a dynamic DNS update request as specified in RFC 2136 [RFC 2136] for each new UNIQUE resource record. Uniqueness verification is carried out when the host: - host starts up or - is configured to respond to the multicast DNS queries on some interface or - is configured to respond to the multicast DNS queries using additional UNIQUE DNS records. Below we describe the data to be specified in the dynamic update request sections. Header section: contains values according to [RFC 2136]. Zone Section The zone name in the zone section MUST be set to the name of the UNIQUE record. The zone type in the zone section MUST be set to SOA. The zone class in the zone section MUST be set to the class of the UNIQUE record. Prerequisite Section This section MUST contain a record set whose semantics are described in RFC 2136, Section 2.4.3 =93RRset Does Not Exist=94 of [RFC 2136] requesting that no RRs with a NAME and TYPE of the UNIQUE record can exist. Update Section This section MUST be left empty. Additional Section This section is set according to RFC 2136. When a host that owns a UNIQUE record receives a dynamic update request that requests that the UNIQUE resource record set does not exist, the host MUST respond via unicast with the YXRRSET error, according to the rules described in Section 3 of RFC 2136 [RFC 2136]. After client receives an YXRRSET response to its dynamic update request that a UNIQUE resource record does not exist, the host MUST not use the UNIQUE resource record in responses to multicast queries and dynamic update requests. Note that this name conflict detection mechanism doesn't prevent name conflicts when previously partitioned segments are connected by a bridge. In such a situation, name conflicts are detected when a sender receives more than one response to its multicast DNS query. In this case, the sender sends the first response that it received to all responders that responded to this query except the first one, using unicast. A host that receives a query response containing a UNIQUE resource record that it owns, even if it didn't send such a query, MUST verify that no other host within the multicast DNS scope is authoritative for the same name, using the dynamic DNS update request mechanism described above. Based on the result, the host detects whether there is a name conflict and acts as described above." Proposed resolution: Discuss --------------------------------------------------------------------- Section 5.1 Submitted by: Bernard Aboba Justification: Need additional text addressing name conflict scenarios in multihomed hosts Add the following section: "5.1. Considerations for Multiple Interfaces A multi-homed host may elect to configure multicast DNS on only one of its active interfaces. In many situations this will be adequate. However, should a host wish to configure multicast DNS on more than one of its active interfaces, there are some additional precautions it MUST take. Implementers who are not planning to support multicast DNS on multiple interfaces simultaneously may skip this section. A multi-homed host checks the uniqueness of UNIQUE records as described in Section 5. The situation is illustrated in figure 1 below: ---------- ---------- | | | | [A] [myhost] [myhost] Figure 1. Linklocal name conflict In this situation, the multi-homed myhost will probe for, and defend, its host name on both interfaces. A conflict will be detected on one interface, but not the other, and as a result, the multi-homed myhost will not be able to respond with a host RR for "myhost". Since names are only unique per-link, hosts on different links could be using the same name. The situation is illustrated in figure 2 below. ---------- ---------- | | | | [A] [myhost] [A] Figure 2. Off-segment name conflict If host myhost is configured to use mDNS on both interfaces, it will send mDNS queries on both interfaces. When host myhost sends a query for the host RR for name "A" it will receive a response from hosts on both interfaces. Host myhost will then forward a response from the first responder to the second responder, who will attempt to verify the uniqueness of host RR for its name, but will not discover a conflict, since the conflicting host resides on a different subnet. Therefore it will continue using its name. This illustrates that the proposed name conflict resolution mechanism does not support resolution of conflicts between hosts on different subnets. This problem can also occur with unicast DNS when a multi-homed host is connected to two different networks with separated name spaces. It is not the intent of this document to address the issue of uniqueness of names within DNS." Proposed resolution: Accept --------------------------------------------------------------------------- Section 5.2 Submitted by: Erik Guttman Add the following section: "5.2 Alternatives for solving the multihomed name ambiguity problem Unfortunately, simple solutions to this problem do not exist. Existing APIs for name resolution and communicating between hosts via the socket interface do not expose which interface information pertains to. [S] Following the example in Figure 2, if an application on 'myhost' issues the request gethostbyname("A"). mDNS requests will be sent from both interfaces and the resolver library will return a struct hostent data structure: struct hostent { char *h_name; /* canonical name of host */ char **h_aliases; /* alias list */ int h_addrtype; /* host address type */ int h_length; /* length of address */ char **h_addr_list; /* list of addresses */ }; This will include the addresses for both hosts responding to the name 'A'. There is no way to determine or influence which interface was used to retrieve which address, given the above interface. There are some non-solutions to the ambiguous name problem: - disallowing multihomed hosts to use mDNS on more than one interface - suggesting multihomed hosts to elect to act as IP bridges - suggesting multihomed hosts behave as routers to pass mDNS While a multihomed host could function as a bridge or router, this should be a configured behavior and has profound implications on network topology. Forwarding packets should not be done simply to address a link-local protocol limitation. Avoiding the use of mDNS on more than one interface of multihomed devices does, however, dissolve the problem: One cure for double vision is removing the second eye. There are three possible solutions to the ambigious name problem: Approach Solution Assessment Do not consider Applications could This 'breaks' DNS. ambiguity a problem. come to expect that It removes the names may be ambiguous. proper correspondence They would have to of a domain name establish application with a RR set from layer naming mechanisms. an application's perspective. Resolve the problem. Enhance mDNS to include This would require additional messages so mDNS to deviate from multihomed hosts can DNS. This entails hosts of conflicting further standards names. development. The mDNS protocol specification already allows for 'gratuitous reply messages' (see Section 5). It is not that much further to go to specify behavior by which a multihomed host could send gratuitous reply messages on behalf of mDNS servers on distinct links to which the host is attached. This would entail changing the conflict resolution algorithm and has profound security implications. Cope with the problem. This can only be done by This fails to creating new APIs and support existing new application software apps and requires to make use of them. a substantial API standardization effort. New APIs for name resolution would return the interface associated with the each item in the result. Applications would have to use socket (XTI, etc.) interfaces to explicitly select which interfaces to use for communication. From the perspective of a multihomed host neither names nor addresses are guaranteed to be unique, though the tuple {interface,name} and {interface,address} will be unique." Proposed Resolution: Discuss. Note: Text relating to APIs is at variance with a previously accepted change. -------------------------------------------------------------------- Section 7 Submitted by: Bernard Aboba Justification: Addressing limitations should be discussed. Change: "In all received packets, the Hop Limit field in IPv6 and the TTL field in IPv4 is verified to contain 255, the maximum legal value." To: "In all received responses, the Hop Limit field in IPv6 and the TTL field in IPv4 are verified to contain 255, the maximum legal value. Since routers decrement the Hop Limit on all packets they forward, received packets containing a Hop Limit of 255 must have originated from a neighbor. Packets destined for a LINKLOCAL address are verified to have been sent from a LINKLOCAL source address." Proposed resolution: Accept --------------------------------------------------------------------- References Submitted by: Erik Gutttman Justification: Current spec does not cite these documents, which are relevant. Add: [A] Huston, G., "Management Guidelines & Operational Requirements for the Internet Infrastructure Domain ("ARPA")", draft-iab-arpa-02.txt, May 2001, A work in progress. [S] Stevens, W. R., "Unix Network Programming, Networking APIs: Sockets and XTI", Prentice Hall, Upper Saddle River, NJ, USA, 1998. Proposed resolution: accept ---------------------------------------------------------------------- Operational recommendations Submitted by: Erik Guttman, Levon Esibov Justification: Need section (or separate BCP document) on operational recommendations. Add the following section (or include this in a separate draft): X.0 Operational Recommendations X.1 Recommendations to IANA concerning the operation of the ARPA subdomain: ARPA domain servers MUST NOT reply to requests for subdomains of '.local.arpa'. X.2 Recommendations concerning the operation of the protocol object regis= try There are no protocol object registry requirements implied by the 'local.arpa' namespace. This 'arpa' sub-domain exists to support locally administered resources. These resources are not protocol objects per se, unlike for example, PTR RRs in 'in-addr.arpa'. The resources constitute arbitrary DNS RRs served by mDNS servers themselves. Proposed resolution: Accept (within a separate BCP document) ------------------------------------------------------------------------ Section 6 Submitted by: Erik Guttman Justification: ARPA guidelines section is required. Add the following text: " This document specifies the use of a new sub-domain of the "ARPA" domain. According to Section 2.1 of the ARPA Guidelines [A], this specification requires description and justification. The 'local.arpa' domain is used to distinguish a local namespace. This namespace differs from others in the following respects: - Name servers responding to requests for names in this domain have different rules concerning authority. As explained in Section 2.1, mDNS servers have limited scope of authority, not extending to sub-domains of domain they are authoritative for. - Hosts may derive their own names in this namespace, independent of centralized authorization and registration (as defined in section 3 and section 5). - There is no delegation or administrative structure to sub-domains of '.local.arpa'. How protocol objects are mapped into lookup keys: Names are associated with resources which can be requested according to the DNS protocol. However, recursive lookup is impossible. Further, mDNS specifies only the use of multicast to transmit these requests. Proposed Resolution: Accept ---------------------------------------------------------------------- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 3 22:00:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA21776 for ; Tue, 3 Jul 2001 22:00:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Hbje-000Axc-00 for namedroppers-data@psg.com; Tue, 03 Jul 2001 18:45:46 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15Hbjc-000AxW-00 for namedroppers@ops.ietf.org; Tue, 03 Jul 2001 18:45:44 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15Hbjc-000H1d-00 for namedroppers@ops.ietf.org; Tue, 03 Jul 2001 18:45:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Olafur Gudmundsson To: Bill Manning cc: Rob Austein , namedroppers@ops.ietf.org Subject: Re: RFC 2782: SRV naming convention In-Reply-To: X-Sender: ogud@hlid.dc.ogud.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 03 Jul 2001 18:45:46 -0700 Content-Transfer-Encoding: 7bit On Tue, 3 Jul 2001, Bill Manning wrote: > % DNS itself makes no promises at all about ordering of RRs within an > % RRset, so a name server can present the RRs in any order it likes. > > Don't current DNSSEC implementations and specifications change > this "promise"? No Bill, DNSSEC specifies an order among the records for signing and verification purposes not on what order records are presented. Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 3 22:03:14 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA23213 for ; Tue, 3 Jul 2001 22:03:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15HbiD-000AtB-00 for namedroppers-data@psg.com; Tue, 03 Jul 2001 18:44:17 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15HbiA-000At4-00 for namedroppers@ops.ietf.org; Tue, 03 Jul 2001 18:44:14 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15HbiA-000GwU-00 for namedroppers@ops.ietf.org; Tue, 03 Jul 2001 18:44:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Mark.Andrews@nominum.com To: Bill Manning Cc: sra@hactrn.net (Rob Austein), namedroppers@ops.ietf.org Subject: Re: RFC 2782: SRV naming convention In-reply-to: Your message of "Tue, 03 Jul 2001 14:58:46 MST." Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 03 Jul 2001 18:44:17 -0700 Content-Transfer-Encoding: 7bit > % DNS itself makes no promises at all about ordering of RRs within an > % RRset, so a name server can present the RRs in any order it likes. > > Don't current DNSSEC implementations and specifications change > this "promise"? No. The server is still free to return the records in any order it feels like. The only thing DNSSEC does is define the order the records are feed crypto support to compute / verify a signature. Mark > > % Hope this clarifies things a bit. > % > % --Rob > > --bill > ps: this e-mail is not in accordance with the all requirements of section 10 > of RFC2026 ... in particular, I haven't given due credit to those who taught > me to read and write (frankly, I don't remember who they were), and vast > numbers of other people, all of whom contributed to my getting to where I > am today... However, I make no copyright claims to it, use it how you will. > I also have no patents, pending or issued, on any of the technology (or ever > ideas) discussed herein. "IETF" might be a trade mark, so might "RFC", but > they don't belong 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. -- Mark Andrews, Nominum Inc. 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 4 00:58:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA14863 for ; Wed, 4 Jul 2001 00:58:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15HeUE-000GQB-00 for namedroppers-data@psg.com; Tue, 03 Jul 2001 21:42:02 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15HeUC-000GQ5-00 for namedroppers@ops.ietf.org; Tue, 03 Jul 2001 21:42:01 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15HeUC-000PPN-00 for namedroppers@ops.ietf.org; Tue, 03 Jul 2001 21:42:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roy Arends To: Mark Kosters , , Cc: Roy Arends Subject: Ideas on opt-in, was Re: I-D ACTION:draft-ietf-dnsext-dnssec-opt-in-00.txt Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 03 Jul 2001 21:42:02 -0700 Content-Transfer-Encoding: 7bit All, You might have seen a few a messages on the list from my hand, which might seem hard to interpret. The ideas mentioned in the second part of this mail is what I wanted to make share. All ideas are a result of numerous discussions with Jakob Schlyter, Mats Dufberg, Scott Rose, Dan Massey and a visit at Verising-GRS Applied Research in Dulles, VA (Mark Kosters and David Macka). The following does however not reflect their opinion. Some may [not] agree with [some] ideas, some may not even agree with this statement :-) This is how I understand the opt-in draft: Take the following zone. $ORIGIN test. @ SOA rdata ; the apex is signed @ SIG (SOA) ; @ NXT a SOA ; @ SIG (NXT) ; a NS ns.a ; this delegation RRset is signed a SIG (NS) ; a DS rdata ; DS or KEY a SIG (DS) ; a NXT d SIG NXT DS ; DS or KEY a SIG (NXT) ; b NS ns.b ; this delegation RRset is not signed d MX rdata ; this RRset is signed. d SIG (MX) ; d NXT @ MX SIG NXT ; d SIG (NXT) ; e MX rdata ; this RRset is not signed. Possible answers: 1) query for a.test. A response from test. nameserver: (referral) RCODE : NOERROR ANSWER : ------- AUTHORITY: a.test. NS ns.a.test. a.test. DS rdata a.test. SIG (DS) 2) query for a.test. NS response from test. nameserver: (referral) RCODE : NOERROR ANSWER : a.test. NS ns.a.test. AUTHORITY: a.test. DS rdata a.test. SIG (DS) 3) query for b.test. NS response from test. nameserver: (referral) RCODE : NOERROR ANSWER : b.test. NS ns.b.test. AUTHORITY: a.test. NXT d.test. SIG NXT DS a.test. SIG (NXT) 4) query for c.test. NS response from test. nameserver: RCODE : NXDOMAIN ANSWER : -------- AUTHORITY: b.test. NXT e.test. SIG NXT DS b.test. SIG (NXT) test. SOA rdata test. SIG (SOA) 5) query for d.test. MX response from test. nameserver: (authoritative) RCODE : NOERROR ANSWER : d.test. MX rdata d.test. SIG (MX) AUTHORITY: --------- 6) query for d.test. A response from test. nameserver: RCODE : NOERROR ANSWER : ------- AUTHORITY: d.test. NXT test. MX SIG NXT d.test. SIG (NXT) 7) query for e.test. MX response from test. nameserver: (authoritative) RCODE : NOERROR ANSWER : e.test. MX rdata AUTHORITY: d.test. NXT test. MX SIG NXT d.test. SIG (NXT) In all queries DO bit is set. The additional section is not specified here. 1 and 2 indicate signed delegations. 3 indicates an unsigned delegation. 4 is of "NXDOMAIN". neither label nor type does exist in this zone. 5 is an authoritative response with a signed RRset in ANSWER. 6 is of "NO DATA". Label exists, but type does not exist in this zone. 7 is an authoritative response with an unsigned RRset in ANSWER. A caching resolver does not give response 1,2 and 3, and has no AA bit set on response 5 and 7. Though query responses might be spoofed: All RRsets with accompanied SIG are verifiably secure. All RCODEs, unsigned RRsets and header bits (aa,tc,rd,ra,cd,ad) are not signed and can be spoofed (use tsig/sig(0) to circumvent this). Conclusion: ----------- If the receiving secure resolver does not know whether the zone was partially signed or fully signed, while a zone was fully signed (aka rfc2535-style), responses like 3 and 7 are spoofed. It is necessary for the resolver to know how to interpret the NXT record. Please correct me if any of the above is wrong. ============================================================================ Now for the ideas: ------------------ As said it is necessary for a secure resolver to know how to interpret the NXT record: This can be done on a per record basis if this is signalled with the NXT record, say by setting some new defined RR-type bit, a response can never be spoofed. (In what follows I refer to the OPTIN RR-bit as "OPT") The NXT records in the zone above would be: $ORIGIN test. @ NXT a SOA ; between @ and a are no records. a NXT d SIG NXT DS OPT ; between a and d are no records signed. d NXT @ MX SIG NXT OPT ; between d and @ are no records signed. (note, setting OPT on the first NXT is optional. There is no RRset between @ and a, so there is also no signed RRset between @ and a) query-responses 3 and 7 must have the OPT indication. If not, they are spoofed. Indication on a per record basis can not be done with either a bit in the key, nor in a special SEC record. In general: ----------- One of the 2 below is mandatory in a signed zone: A NXT+OPT is created for a label when there is some signed RRset by that label. It points to the next signed label. A NXT w/o OPT is created whenever there is some RRset for that label. It points to the next label. The APEX is allways signed in a secure zone, thus the APEX has always a NXT. Why and Who: ------------ The really strict zone administrator signs the whole zone and uses NXT w/o OPT (fully rfc2535-style). The very large (.com) zone administrator might want to sign just the apex, and some delegations, sets the OPT on every NXT. (fully optin-style) For the fine-grained security-savvy administrator, that does not need to sign delegations, its TXT,LOC,HINFO records, but wants to sign some A records, and be sure that nothing is spoofed between the signed A record www.test and zzz.test, creates NXT w/o OPT over "www.test. NXT zzz.test.", and uses NXT+OPT at other signed labels. How: ---- (partially signed zone) Take a zone-file, flush the records you want to sign in a temp file, sort and sign the temp file with NXT+OPT and concatenate it with the zone-file again. (fully signed zone) Sort and sign the zone file with NXT w/o OPT. (partially signed zone + denial of existence between some RRsets) Take partially signed zone, add (or replace) a NXT w/o OPT + SIG(NXT) for the part you want to deny existence for. I hope this computes. Regards, Roy Arends Nominum to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 4 01:54:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA18296 for ; Wed, 4 Jul 2001 01:54:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15HfRH-000IqJ-00 for namedroppers-data@psg.com; Tue, 03 Jul 2001 22:43:03 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15HfRG-000IqD-00 for namedroppers@ops.ietf.org; Tue, 03 Jul 2001 22:43:02 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15HfRG-0002No-00 for namedroppers@ops.ietf.org; Tue, 03 Jul 2001 22:43:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC AXFR-02 SHORT last call References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 03 Jul 2001 22:43:03 -0700 Content-Transfer-Encoding: 7bit Olafur Gudmundsson/DNSEXT co-chair writes: > so you want more time, you got through the 6'th. I have set up a web page, http://cr.yp.to/djbdns/axfr-clarify.html, stating my objections. I'd like to emphasize that the axfr-clarify draft repeatedly violates RFC 2119, section 6, by trying to ``impose a particular method on implementors where the method is not required for interoperability.'' ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 4 07:25:00 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA04498 for ; Wed, 4 Jul 2001 07:24:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15HkNm-00056t-00 for namedroppers-data@psg.com; Wed, 04 Jul 2001 03:59:46 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15HkNj-00056I-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 03:59:43 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15HkNi-000Hs9-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 03:59:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Bernard Aboba cc: namedroppers@ops.ietf.org Subject: Re: Resolution of proposed changes to mDNS-00 draft In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 04 Jul 2001 03:59:46 -0700 Content-Transfer-Encoding: 7bit Date: Tue, 03 Jul 2001 17:21:38 -0700 From: Bernard Aboba Message-ID: | Submitted by: Erik Guttman, Dave Thaler | Justification: Current language does not fully specify retransmission | behavior. | Repetition MUST NOT be attempted more than 3 times and SHOULD NOT | be repeated more often than once per second to reduce unnecessary | network taffic. Retry intervals SHOULD be exponentially increased, | starting from a value of 1 second." | | Proposed resolution: Accept I don't mind that, but specifying "exponentially increased" for something that can't be attempted more than 3 times doesn't achieve very much at all ... in particular, delays of 1 second then 1.01 seconds, then 1.02 seconds is exponentially increasing (just way down at the very flat part of the curve...) Even flatter numbers could be chosen. With so few attempts, just specifying "increased" is really enough. For someone who uses bigger increases, is it really important to anything that they choose 1, 2 and 3.00001 second delays, rather than 1, 2, and 3 second delays? The latter is a linear increase, so clearly isn't exponential, whereas 1, 2, and 3.00001 is (or can be justified as being so). | Submitted by: Dave Thaler | Justification: Current text does not address the API issues involved | with setting and checking of TTL. | Implementation note: | In the sockets API for IPv4, the IP_TTL and IP_MULTICAST_TTL | socket options are used to specify the TTL of outgoing unicast | and multicast packets. The IP_RECVTTL socket option is available | on some platforms to receive the IPv4 TTL of received packets with | recvmsg(). RFC 2292 specifies similar options for specifying and | receiving the IPv6 Hop Limit. | " Personally, I think that is way too much detail, even for an implementation note. | ------------------------------------------------------------------- | Section 5 | | Submitted by : Levon Esibov | Justification: Use of dynamic update for conflict detection is a | cleaner approach. | Proposed resolution: Discuss Yes, do that. | --------------------------------------------------------------------- | Section 5.1 | Submitted by: Bernard Aboba | Justification: Need additional text addressing name conflict scenarios | in multihomed hosts | | Add the following section: | | ---------- ---------- | | | | | | [A] [myhost] [A] | | | Figure 2. Off-segment name conflict | | If host myhost is configured to use mDNS on both interfaces, | it will send mDNS queries on both interfaces. | When host myhost sends a query for the host RR for name "A" | it will receive a response from hosts on both interfaces. | Host myhost will then forward a response from the first responder | to the second responder, What? Since when did anyone ever forward mDNS responses anywhere, under any circumstances? What is this supposed to be achieving? Surely when myhost gets the two response over 2 different interfaces what it does is implementation defined (pick the first, pick the last, return both, return an error, all are possible). Unless and until we get some experience with this, that shows that one approach works best, leaving it implementation defined is best. | --------------------------------------------------------------------------- | Section 5.2 | Submitted by: Erik Guttman | | Add the following section: | | "5.2 Alternatives for solving the multihomed name ambiguity problem | | While a multihomed host could function as a bridge or router, this It could be configured as a router. A host with multiple interfaces that is configured as a bridge is (at least if all its interfaces are involved in bridging) only singly homed. The bridge operates at the link level, "homing" for what it matters here applies at the network level - there should be only one network layer interface to a bridged network (whether the bridging happens in the same hardware, or different hardware). That there are some badly broken bridge implementations around is irrelevant to this. | There are three possible solutions to the ambigious name problem: | | Approach Solution Assessment | | Do not consider Applications could This 'breaks' DNS. | ambiguity a problem. come to expect that It removes the | names may be ambiguous. proper correspondence | They would have to of a domain name | establish application with a RR set from | layer naming mechanisms. an application's | perspective. | | Resolve the problem. Enhance mDNS to include This would require | additional messages so mDNS to deviate from | multihomed hosts can DNS. This entails | hosts of conflicting further standards | names. development. | Cope with the problem. This can only be done by This fails to | creating new APIs and support existing | new application software apps and requires | to make use of them. a substantial API | standardization | effort. There's another, simply acknowledge the problem ... if the name is ambiguous, treat it just the same as if it didn't exist at all. That is, we can't decide where to go, so we go nowhere. I'd prefer omitting all of this, and just specifying it as being implementation defined for now. Let's not try solving all the world's problems in one go. | ---------------------------------------------------------------------- | Operational recommendations | | Submitted by: Erik Guttman, Levon Esibov | Justification: Need section (or separate BCP document) on operational | X.0 Operational Recommendations | | X.1 Recommendations to IANA concerning the operation of the ARPA | subdomain: | | ARPA domain servers MUST NOT reply to requests for | subdomains of '.local.arpa'. This is the last thing that we want. All that can possibly achieve is to have the hosts that are sending the queries, sending more of them, on the assumption that the query might have been lost. There MUST be a reply (just like any other DNS query) - which at the very least will cause the current query to be terminated, and if we're lucky, might even be cached for a while, and prevent some future queries being sent to the ARPA servers. Further, it would be making a truly silly special case in the server implementations for that domain. | Section 6 | Submitted by: Erik Guttman | Justification: ARPA guidelines section is required. | | Add the following text: There needs to be something in here to prevent hosts sending queries for this domain to the ARPA servers (that's where it needs to be stopped not at the ARPA servers). That could be by specifying that the domain is only to be uses for mDNS servers, and much never be used by the conventional DNS protocols. That I think is going a bit too far - I can see uses for purely local names using the regular DNS, as long as the servers involved are configured to serve the domain, so they don't forward queries. But I guess we could just have both local.arpa and private.arpa (or any other name dreamed up) in the search list with the first one being used in mDNS queries, and then the second being used via regular DNS. But if I'm doing that, I might as well just use private.ARPA for the mDNS lookup as well... I'm actually starting to believe that the issue of names for entities not using the global DNS for resolution, and the issue of resolution methods for nodes that have no access to (or don't want to use) the global DNS are 100% independent, and should be treated separately. That is, I think I'd be removing all references to local.arpa from this doc, and defining that in a doc of its own - just so the two things don't get confused. That both mechanisms will often be wanted by the same nodes is a coincidence, and not one that warrants the two specs being merged. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 4 08:15:02 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05240 for ; Wed, 4 Jul 2001 08:15:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15HlKs-0007eA-00 for namedroppers-data@psg.com; Wed, 04 Jul 2001 05:00:50 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15HlKq-0007dt-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 05:00:48 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15HlKq-000Kj5-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 05:00:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Paul Vixie cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC AXFR-02 SHORT last call In-Reply-To: References: <200106290607.XAA89376@redpaul.mfnx.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 04 Jul 2001 05:00:50 -0700 Content-Transfer-Encoding: 7bit Date: Sat, 30 Jun 2001 10:07:14 -0700 From: Paul Vixie Message-ID: | Robert, you were involved in the RFC 1996 discussions, both in the meetings | and here on the mailing list. Yes. | You ought to remember that what was determined | (proposed by me and consensed by others) is that there is no such thing as a | "primary" vs "secondary" server. Yes, but it isn't the words that matter, there is no such thing as a master vs slave server either. It is attempting to categorise the server that is broken, not the words used to do it. At some time or other I recall hearing words along the lines of "the use of primary and secondary was based upon a misunderstanding of 1034/5" - at the time I didn't recall what was in those docs accurately enough to dispute that (that is, I knew the content, but the terminology used to describe it could have been almost anything - though I certainly remembered at least "master" being used there) so I couldn't dispute that at the time. Later when I actually went and checked to see just where this misunderstanding had come from, I found nothing to indicate any kind of misunderstanding at all. "Primary" and "secondary" was always right. That is, using them the way they were used derived from 1034/5 was correct -- 1034/5 themselves could have used master/slave for the distinction, or other completely different terms from any we're using today (in OSI speak they'd probably have been zone transfer initiators and zone transfer responders or something, and we'd talk of ZTIs and ZTRs...) but they didn't, the terms picked initially were primary and secondary, and we create less confusion if we simply stick to them. | The shorthand of "primary" used to mean "loads the zone content from outside | the DNS" but that's a meaningless distinction if DNS isn't used to copy zones | between the various authoritative servers for the zone. All of them would be | primary in that case. Yes, they would. So? Using your terminology, all of them are master. The only difference between what you're saying and what I'm saying is the word that is used. But "primary" and "secondary" are used throughout 1034/5 for this purpose. "master"/"slave" are not. Hence they're new invented terms that aren't required for anything, we already had perfectly good terminology... | That and only that is why late model BIND calls zones "master" and "slave". | "Master" means load from disk. "Slave" means load via AXFR/IXFR (and disk). In earlier bind, "primary" meant "loads from disc" and "secondary" meant "load via AXFR" (IXFR didn't exist then). There never was a need for a change (those labels always applied to a particular zone in the bind config, not to the server as a whole). All that was changed was a label, confusing people, and adding nothing at all. | I now wish I'd just called them "authority" zones and let the presence or | absence of a "masters { };" clause determine the masterness/slaveness type. For bind yes, that would have been fine. The redundancy helps detect broken configurations though (better human interface). For other specs we (sometimes) need a way to categorise the status of a server for the zone however, so we do need terms. | "Master" and "slave" survived the terminology evaluation because they refer | to a useful distinction -- "which role do you take in AXFR/IXFR?" Whereas | "Primary" and "secondary" did not survive because they refer to no useful | distinction. Nonsense - master==primary and slave==secondary - all that altered was the word being used. There's no other distinction at all. And none of this explains how we need the redundant combination "primary master". | (You are, by the way, the last person in the IETF whom I would have expected | an argument ad hominem from. Apologies if it seemed to be that way - that wasn't what I intended. All I intended was to point out that the advocate for using these terms has been you, all of this time. It has not come from anywhere else. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 4 08:28:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05476 for ; Wed, 4 Jul 2001 08:28:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15HlZH-0008IO-00 for namedroppers-data@psg.com; Wed, 04 Jul 2001 05:15:43 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15HlZG-0008IE-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 05:15:42 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15HlZG-000LQk-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 05:15:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Miek Gieben To: Scott Rose Cc: dnssec@cafax.se, DNSEXT WG Mailing list Subject: Re: I-D ACTION:draft-ietf-dnsext-dnssec-opt-in-00.txt In-Reply-To: <00ee01c103fe$1dc34ec0$b9370681@antd.nist.gov>; from scottr@antd.nist.gov on Tue, Jul 03, 2001 at 04:24:09PM -0400 References: <00ee01c103fe$1dc34ec0$b9370681@antd.nist.gov> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 04 Jul 2001 05:15:43 -0700 Content-Transfer-Encoding: 7bit [On 03 Jul, 2001, Scott Rose wrote in " I-D ACTION:draft-ietf-dnsext-dnssec-opt-in-00.txt "] > > If the group decides to use a bit to determine the opt-in status (I haven't > decided if I like the idea or not - right now I'm leaning towards "not" but > don't have a better solution yet) - let's pick an unused number to avoid any which zones are going to use opt-in? .com and .net? Can't we just say that we will never do DNSSEC on .com/.net and friends. If you want to be secure get your secure domainname under .secure? grtz Miek NLnet Labs to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 4 08:29:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05510 for ; Wed, 4 Jul 2001 08:29:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15HlYf-0008Hc-00 for namedroppers-data@psg.com; Wed, 04 Jul 2001 05:15:05 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15HlYe-0008HU-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 05:15:04 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15HlYe-000LOv-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 05:15:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: erik guttman Reply-To: erik.guttman@Sun.COM To: Robert Elz CC: namedroppers@ops.ietf.org Subject: mdns retransmit behavior discussion Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 04 Jul 2001 05:15:05 -0700 Content-Transfer-Encoding: 7bit Robert Elz wrote: > | Justification: Current language does not fully specify retransmission > | behavior. > > | Repetition MUST NOT be attempted more than 3 times and SHOULD NOT > | be repeated more often than once per second to reduce unnecessary > | network taffic. Retry intervals SHOULD be exponentially increased, > | starting from a value of 1 second." > | > | Proposed resolution: Accept > > I don't mind that, but specifying "exponentially increased" for > something that can't be attempted more than 3 times doesn't achieve > very much at all. How about: Retry intervals SHOULD be exponentially increased. The delay between retries is calculated using a random value selected using a uniform distribution between n/2 and (3*n)/2 seconds. Successive retries double n doubles each time. Erik to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 4 08:30:03 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05527 for ; Wed, 4 Jul 2001 08:30:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15HlZv-0008Ko-00 for namedroppers-data@psg.com; Wed, 04 Jul 2001 05:16:23 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15HlZu-0008Ki-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 05:16:22 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15HlZt-000LSm-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 05:16:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: erik guttman Reply-To: erik.guttman@Sun.COM To: Robert Elz CC: namedroppers@ops.ietf.org Subject: mdns off-segment name conflict Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 04 Jul 2001 05:16:23 -0700 Content-Transfer-Encoding: 7bit > | Justification: Need additional text addressing name conflict scenarios > | in multihomed hosts > > | ---------- ---------- > | | | | | > | [A] [myhost] [A] > | > | > | Figure 2. Off-segment name conflict > | > | If host myhost is configured to use mDNS on both interfaces, > | it will send mDNS queries on both interfaces. > | When host myhost sends a query for the host RR for name "A" > | it will receive a response from hosts on both interfaces. > | Host myhost will then forward a response from the first responder > | to the second responder, > > What? [] > Unless and until we get some experience with this, that shows that one > approach works best, leaving it implementation defined is best. I agree with kre. If myhost uses mdns on multiple interfaces, it should be prepared to cope with possible name resolution ambiguity in an implementation specific manner. To go further than this would require that mDNS do more than use multicast to transport DNS request/reply messages, which I believe would be a mistake. Erik to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 4 13:34:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09685 for ; Wed, 4 Jul 2001 13:34:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15HqCS-000LCh-00 for namedroppers-data@psg.com; Wed, 04 Jul 2001 10:12:28 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15HqCQ-000LCb-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 10:12:26 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15HqCQ-0009fd-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 10:12:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Edward Lewis To: Miek Gieben Cc: Scott Rose , dnssec@cafax.se, DNSEXT WG Mailing list Subject: Re: I-D ACTION:draft-ietf-dnsext-dnssec-opt-in-00.txt In-Reply-To: <20010704140646.B37537@atoom.net> References: <00ee01c103fe$1dc34ec0$b9370681@antd.nist.gov>; from scottr@antd.nist.gov on Tue, Jul 03, 2001 at 04:24:09PM -0400 <00ee01c103fe$1dc34ec0$b9370681@antd.nist.gov> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 04 Jul 2001 10:12:28 -0700 Content-Transfer-Encoding: 7bit At 8:06 AM -0400 7/4/01, Miek Gieben wrote: >which zones are going to use opt-in? .com and .net? Can't we just say >that we will never do DNSSEC on .com/.net and friends. If you want to >be secure get your secure domainname under .secure? .com not use DNSSEC? Perish the thought! I think we can hammer opt-in into the default dnssec mode of operation (protocol and procedure) so that .com and other big zones are NOT special cases. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com You fly too often when ... the airport taxi is on speed-dial. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 4 13:34:55 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09696 for ; Wed, 4 Jul 2001 13:34:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Hq9r-000L3n-00 for namedroppers-data@psg.com; Wed, 04 Jul 2001 10:09:47 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15Hq9p-000L3W-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 10:09:45 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15Hq9p-0009XT-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 10:09:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: erik guttman Reply-To: erik.guttman@Sun.COM To: Robert Elz CC: Bernard Aboba , namedroppers@ops.ietf.org Subject: mdns 'local.arpa' guidelines References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 04 Jul 2001 10:09:47 -0700 Content-Transfer-Encoding: 7bit Robert Elz wrote: > | Section 6 > | Submitted by: Erik Guttman > | Justification: ARPA guidelines section is required. > | > | Add the following text: > > There needs to be something in here to prevent hosts sending queries > for this domain to the ARPA servers (that's where it needs to be stopped > not at the ARPA servers). mdns uses 'local.arpa.' because it needs a namespace so - names can be generated/determined by hosts automatically - resolvers can recognize to use mdns, not use DNS to issue unicast requests with 'recursion desired.' It was believed that assigning 'local.arpa' for this purpose was easier than requesting a new TLD. Is this true?! The purpose of the IANA guidelines section is to emphasize that the server authoritative for 'local.arpa' will not be delegate authority for any of its subdomains. Recursive lookups through the ARPA domain server should fail, for that reason. I agree that they should not fail silently. Correctly implemented mDNS resolvers will not issue recursive (or iterative) DNS lookups on names ending with '.local.arpa.' But it will happen. > That could be by specifying that the domain is only to be uses for mDNS > servers, and much never be used by the conventional DNS protocols. > That I think is going a bit too far - I can see uses for purely local > names using the regular DNS, as long as the servers involved are > configured to serve the domain, so they don't forward queries. Without allowing (unicast) DNS requests for 'local.arpa.' qualified names, existing DNS resolvers would be unable to look up these names. Local DNS servers could receive updates from local mDNS stub servers. In this case, you would get the same results unicasting or multicasting a request. Not a bad thing :-) Erik to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 4 13:35:01 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09715 for ; Wed, 4 Jul 2001 13:35:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15HqAu-000L8B-00 for namedroppers-data@psg.com; Wed, 04 Jul 2001 10:10:52 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15HqAu-000L81-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 10:10:52 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15HqAu-0009am-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 10:10:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: erik guttman Reply-To: erik.guttman@Sun.COM To: Bernard Aboba CC: namedroppers@ops.ietf.org, cheshire@apple.com, levone@microsoft.com, dthaler@microsoft.com, bernarda@microsoft.com Subject: Re: Resolution of proposed changes to mDNS-00 draft References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 04 Jul 2001 10:10:52 -0700 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > > Based on the vigorous discussion we've had over the last month or so, Bernard Aboba wrote: > If an item is not on the list, it's probably because it is controversial > or a large item that is not easily encapsulated in a few paragraphs of > recommended edits. An example is mDNS configuration. For this one, we felt > that the best approach was for someone to come up with an alternate > proposal in order to help facilitate the discussion. Erik Guttman has > graciously volunteered to act as lightening rod. Thanks, Erik! Please see draft-guttman-dhc-mdns-enable-00.txt This document specifies a replacement for using the domain search list to configure mdns behavior. Although draft-ietf-dnsext-mdns-00.txt specifies the use of the domain search list, no one seems to prefer this approach to the DHCP 'mDNS enable' option alternative. If you do, please speak up and explain why. Regards, Erik to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 4 13:35:03 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09726 for ; Wed, 4 Jul 2001 13:35:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Hq8O-000L2R-00 for namedroppers-data@psg.com; Wed, 04 Jul 2001 10:08:16 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15Hq8N-000L2L-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 10:08:15 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15Hq8M-0009Sv-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 10:08:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roy Arends To: Miek Gieben Cc: Scott Rose , , DNSEXT WG Mailing list Subject: Re: I-D ACTION:draft-ietf-dnsext-dnssec-opt-in-00.txt In-Reply-To: <20010704140646.B37537@atoom.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 04 Jul 2001 10:08:16 -0700 Content-Transfer-Encoding: 7bit On Wed, 4 Jul 2001, Miek Gieben wrote: > [On 03 Jul, 2001, Scott Rose wrote in " I-D ACTION:draft-ietf-dnsext-dnssec-opt-in-00.txt "] > > > > If the group decides to use a bit to determine the opt-in status (I haven't > > decided if I like the idea or not - right now I'm leaning towards "not" but > > don't have a better solution yet) - let's pick an unused number to avoid any > > which zones are going to use opt-in? .com and .net? Can't we just say > that we will never do DNSSEC on .com/.net and friends. If you want to > be secure get your secure domainname under .secure? 1) There is the RFC-1035 style zone (unsigned) 2) There is the RFC-2535 style zone (fully signed) 3) There is the opt-in style zone (partially signed) 1) is used now. 2) is DNSSEC. 3) is what this discussion is about. Combining 1+2. The opt-in draft describes the opt-in style as a combined view of 1+2. Other arguments merely are about combining the two styles in one zone. Not through server configuration (ie having to combine 2 zones/views). It is absolutely of NO IMPORTANCE if .com/.net and friends go for 3. It would still be DNSSEC for their signed delegations. The effort that Verisign is making (opt-in draft) shows that they want DNSSEC. Which is a big step forward. In general, using optin relieves large TLD's for signing each and every individual Resource Record and creating (null/real)keys + sig + nxt + sig over unsigned delegations. Going through the ICANN process and obtaining the .secure TLD seems very heavy. And next to that, the .secure TLD registry probably wants opt-in too. Roy Arends Nominum to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 4 13:35:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09738 for ; Wed, 4 Jul 2001 13:35:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15HqA2-000L62-00 for namedroppers-data@psg.com; Wed, 04 Jul 2001 10:09:58 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15HqA0-000L5l-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 10:09:56 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15HqA0-0009Y3-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 10:09:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Miek Gieben To: Roy Arends Cc: Miek Gieben , Scott Rose , dnssec@cafax.se, DNSEXT WG Mailing list Subject: Re: I-D ACTION:draft-ietf-dnsext-dnssec-opt-in-00.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 04 Jul 2001 10:09:58 -0700 Content-Transfer-Encoding: 7bit [On 04 Jul, 2001, Roy Arends wrote in " Re: I-D ACTION:draft-ietf-dnsext-dnssec-opt-in-00.txt "] > > which zones are going to use opt-in? .com and .net? Can't we just say > > that we will never do DNSSEC on .com/.net and friends. If you want to > > be secure get your secure domainname under .secure? > In general, using optin relieves large TLD's for signing each and every > individual Resource Record and creating (null/real)keys + sig + nxt + sig > over unsigned delegations. > > Going through the ICANN process and obtaining the .secure TLD seems very > heavy. And next to that, the .secure TLD registry probably wants opt-in > too. why should a small TLD like .secure (going through ICANN is another story) would use opt-in? They can use dnssec right as it stands now. The .secure will grow in time but I don't think it will ever reach the size of .com. I know what opt-in is trying to do, but i'm wondering if it isn't an overkill for zones that are already too large for normal DNS grtz Miek NLet Labs to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 4 13:36:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09751 for ; Wed, 4 Jul 2001 13:36:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15HqD5-000LFP-00 for namedroppers-data@psg.com; Wed, 04 Jul 2001 10:13:07 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15HqD4-000LFJ-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 10:13:06 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15HqD3-0009hg-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 10:13:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Miek Gieben To: Edward Lewis Cc: Miek Gieben , Scott Rose , dnssec@cafax.se, DNSEXT WG Mailing list Subject: Re: I-D ACTION:draft-ietf-dnsext-dnssec-opt-in-00.txt In-Reply-To: ; from lewis@tislabs.com on Wed, Jul 04, 2001 at 09:01:10AM -0400 References: <00ee01c103fe$1dc34ec0$b9370681@antd.nist.gov>; <00ee01c103fe$1dc34ec0$b9370681@antd.nist.gov> <20010704140646.B37537@atoom.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 04 Jul 2001 10:13:07 -0700 Content-Transfer-Encoding: 7bit [On 04 Jul, 2001, Edward Lewis wrote in " Re: I-D ACTION:draft-ietf-dnsext-dnssec-opt-in-00.txt "] > At 8:06 AM -0400 7/4/01, Miek Gieben wrote: > >which zones are going to use opt-in? .com and .net? Can't we just say > >that we will never do DNSSEC on .com/.net and friends. If you want to > >be secure get your secure domainname under .secure? > > .com not use DNSSEC? Perish the thought! > > I think we can hammer opt-in into the default dnssec mode of operation > (protocol and procedure) so that .com and other big zones are NOT special > cases. That's one step further. I'm not against opt-in, but it would be nice to have just one standard, either opt-in or plain dnssec. 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. From owner-namedroppers@ops.ietf.org Wed Jul 4 13:39:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09706 for ; Wed, 4 Jul 2001 13:34:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15HqB7-000L9Y-00 for namedroppers-data@psg.com; Wed, 04 Jul 2001 10:11:05 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15HqB6-000L9S-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 10:11:04 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15HqB6-0009bY-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 10:11:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Edward Lewis To: Roy Arends Cc: Mark Kosters , , , Roy Arends Subject: Re: Ideas on opt-in, was Re: I-D ACTION:draft-ietf-dnsext-dnssec-opt-in-00.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 04 Jul 2001 10:11:05 -0700 Content-Transfer-Encoding: 7bit At 10:46 PM -0400 7/3/01, Roy Arends wrote: > > 1 and 2 indicate signed delegations. > 3 indicates an unsigned delegation. > 4 is of "NXDOMAIN". neither label nor type does exist in this zone. > 5 is an authoritative response with a signed RRset in ANSWER. > 6 is of "NO DATA". Label exists, but type does not exist in this zone. > 7 is an authoritative response with an unsigned RRset in ANSWER. >Conclusion: >----------- > If the receiving secure resolver does not know whether the zone was > partially signed or fully signed, while a zone was fully signed (aka > rfc2535-style), responses like 3 and 7 are spoofed. It is necessary for > the resolver to know how to interpret the NXT record. Responses 3 and 7 are open to spoofing. But this isn't any worse than not using DNSSEC at all. In the case for #3, if the parent is unsigned (as it is today), then the zone is spoofed. When the parent is signed and indicates that the delegation exists, albeit unsecured, spoofing this is hard (/impossible). However, the contents of the zone are spoofable, as well as the NS set given as hints. (Without TSIG, the NS set could simply be modified to pollute caches.) The only loss in this twist is that it is harder to prove a delegation should exist. But with or without the twist, you aren't guaranteed any data returned. In the case for #7, the comparison is much simpler. With opt-in and exclusion from the NXT chain, the parent is considered unsecured for this record set. When included, the zone is secured as far as the record set is concerned. Whether this will confuse the resolver, I think that's a yes. But then again, the resolver (in 9.1.3.rc2) didn't seem to understand sig@parent (unless we screwed up some other part of the workshop set up). -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com You fly too often when ... the airport taxi is on speed-dial. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 4 13:43:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09805 for ; Wed, 4 Jul 2001 13:43:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15HqJa-000Lbw-00 for namedroppers-data@psg.com; Wed, 04 Jul 2001 10:19:50 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15HqJZ-000LbW-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 10:19:49 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15HqJZ-000A1h-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 10:19:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Edward Lewis To: Roy Arends Cc: Miek Gieben , Roy Arends , Jakob Schlyter , DNSEXT Subject: Re: draft-ietf-dnsext-delegation-signer-00 In-Reply-To: References: <20010628132630.A14552@atoom.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 04 Jul 2001 10:19:50 -0700 Content-Transfer-Encoding: 7bit At 10:17 AM -0400 7/2/01, Roy Arends wrote: >It's a trade-off. A longer verification chain VS more frequent rollover. I >favor a "less frequent rollover" and deal with the longer verification >chain. I'm not sure though how more complex the resolver algorithm would >be. Is a longer verification acceptable to folks? Remember that there are a lot of resolutions versus zone changes today. The RSA-MD5 algorithm is prefered because it is cheaper to verify than sign - based on the assumption that resolution happens more often. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com You fly too often when ... the airport taxi is on speed-dial. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 4 14:07:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10087 for ; Wed, 4 Jul 2001 14:07:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15HqmJ-000NFc-00 for namedroppers-data@psg.com; Wed, 04 Jul 2001 10:49:31 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15HqmH-000NFW-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 10:49:29 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15HqmH-000BUE-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 10:49:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Olafur Gudmundsson/DNSEXT co-chair To: "D. J. Bernstein" , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC AXFR-02 SHORT last call In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 04 Jul 2001 10:49:31 -0700 Content-Transfer-Encoding: 7bit At 01:43 AM 7/4/2001, D. J. Bernstein wrote: >Olafur Gudmundsson/DNSEXT co-chair writes: > > so you want more time, you got through the 6'th. > >I have set up a web page, http://cr.yp.to/djbdns/axfr-clarify.html, >stating my objections. Unless it is posted on the mailing list, or sent to chairs&author(s) working group can not consider this material as part of it. Web pages are not acceptable input. >I'd like to emphasize that the axfr-clarify draft repeatedly violates >RFC 2119, section 6, by trying to ``impose a particular method on >implementors where the method is not required for interoperability.'' you are really twisting RFC2119 section 6, by selective quoting. The section is a warning about the over use of the word MUST not a restriction on what can be specified. The document in question here is specifying "If an implementation does optional protocol element AXFR then do it like this". If your implementation is not compliant then you have three choices, 1. Convince the working group to change the specification 2. Update your incorrect implementation 3. Discontinue distribution of non compliant software. We will have an interoperabilty test for AXFR at some time in the not to distant future and you are strongly encouraged to participate. Q: did you write your implementation of AXFR before or after version 00 of the draft was published in March last year. Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 4 14:18:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10158 for ; Wed, 4 Jul 2001 14:18:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Hr65-000OKy-00 for namedroppers-data@psg.com; Wed, 04 Jul 2001 11:09:57 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15Hr64-000OKj-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 11:09:56 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15Hr64-000CVk-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 11:09:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roy Arends To: Edward Lewis Cc: Roy Arends , Mark Kosters , , Subject: Re: Ideas on opt-in, was Re: I-D ACTION:draft-ietf-dnsext-dnssec-opt-in-00.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 04 Jul 2001 11:09:57 -0700 Content-Transfer-Encoding: 7bit On Wed, 4 Jul 2001, Edward Lewis wrote: > At 10:46 PM -0400 7/3/01, Roy Arends wrote: > > > > 1 and 2 indicate signed delegations. > > 3 indicates an unsigned delegation. > > 4 is of "NXDOMAIN". neither label nor type does exist in this zone. > > 5 is an authoritative response with a signed RRset in ANSWER. > > 6 is of "NO DATA". Label exists, but type does not exist in this zone. > > 7 is an authoritative response with an unsigned RRset in ANSWER. > > >Conclusion: > >----------- > > If the receiving secure resolver does not know whether the zone was > > partially signed or fully signed, while a zone was fully signed (aka > > rfc2535-style), responses like 3 and 7 are spoofed. It is necessary for > > the resolver to know how to interpret the NXT record. > > Responses 3 and 7 are open to spoofing. But this isn't any worse than not > using DNSSEC at all. Absolutely, but that is not the point. It's less secure then fullblown 2535. That's why there should be an indication on how to interpret NXT. > In the case for #3, if the parent is unsigned (as it is today), then the > zone is spoofed. When the parent is signed and indicates that the > delegation exists, albeit unsecured, spoofing this is hard (/impossible). > However, the contents of the zone are spoofable, as well as the NS set > given as hints. (Without TSIG, the NS set could simply be modified to > pollute caches.) Absolutely. > The only loss in this twist is that it is harder to prove a delegation > should exist. But with or without the twist, you aren't guaranteed any > data returned. Yes. > In the case for #7, the comparison is much simpler. With opt-in and > exclusion from the NXT chain, the parent is considered unsecured for this > record set. When included, the zone is secured as far as the record set is > concerned. Yes. > Whether this will confuse the resolver, I think that's a yes. But then > again, the resolver (in 9.1.3.rc2) didn't seem to understand sig@parent > (unless we screwed up some other part of the workshop set up). The problem is that an administrator can secure a zone as thick as he wants, a resolver can be tricked into accepting an unsecured record (that in fact does not exist in the zone) because there is no indication how a NXT should be interpreted. In this case, the resolver could interpret the NXT as "nothing is signed between the NXT's label and the next domain name" while the domain holder meant it as "nothing exists between the NXT's label and the next domain name". That is a loss (though a minor one, I agree) on security. That is why there should be an indication how to interpret the NXT record. There is and was no discussion on that. In the draft the indication is done by setting bit 4 in the KEY flag field. This however imposes either "full secured" (bit=0) or "partially secured" (bit=1) on the whole zone. When the latter is imposed it means there is absolutely no way of saying "authenticated denial of existence" for some record. When setting a bit in the NXT record, and not in KEY, there is still the distinction between "full secured (denial of existence)" and "partially secured (denial of signatures)", though not on a zone basis, but on an record basis. I think that is a plus. Regards, Roy Arends Nominum to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 4 14:20:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10189 for ; Wed, 4 Jul 2001 14:20:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Hr5n-000OJC-00 for namedroppers-data@psg.com; Wed, 04 Jul 2001 11:09:39 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15Hr5l-000OJ6-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 11:09:37 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15Hr5l-000CUl-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 11:09:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC AXFR-02 SHORT last call References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 04 Jul 2001 11:09:39 -0700 Content-Transfer-Encoding: 7bit Apparently the DNSEXT chair doesn't have web access, so here's the output of lynx -dump http://cr.yp.to/djbdns/axfr-clarify.html. ---Dan [1]D. J. Bernstein [2]Internet publication [3]djbdns The BIND company's ``AXFR clarifications'' * means BIND company employee or owner. Timeline 2000-03-03: Andreas Gustafsson* released axfr-clarify-00, a ``DNS Zone Transfer Protocol Clarifications'' document. 2000-07-18: Gustafsson* released a new draft, axfr-clarify-01. There was some discussion on the [4]censored DNSEXT mailing list: 2 messages from DNSEXT censor Randy Bush, 4 from Gustafsson*, 3 from Eric Hall, 2 from Peter Koch, 4 from Josh Littlefield, and 1 from Paul Vixie*. ``The purpose of this draft is not to change the protocol but to document it in its existing form,'' Gustafsson* said. 2001-03-13: Olafur Gudmundsson issued a DNSEXT last call to put axfr-clarify-01 on the standards track. ``The document formalizes the zone transfer protocol in accordance with the fielded DNS server software,'' he said. I raised several serious objections, and explained them in detail, in a series of 9 messages. One of my messages was [5]discarded by the DNSEXT censor. The discussion included 2 messages from Mark Andrews*, 2 from Kevin Darcy, 1 from Aaron Durchgaloch, 3 from Gustafsson*, 1 from Koch, 3 from Masataka Ohta, and 2 from Brian Wellington*. 2001-04-04: Several messages from me, a few from Gudmundsson, 4 from Andrews*, 1 from Roy Arends*, 4 from Darcy, 1 from Robert Elz, 1 from Gustafsson*, 2 from Greg Hudson, 1 from Bill Sommerfeld, 4 from independent DNS implementor Sam Trenholme, and 1 from Wellington*. The discussion began when Olafur Gudmundsson claimed that ``the working group consensus is to advance the document'' once certain minor issues had been addressed. Gudmundsson never provided any justification for this claim. Trenholme blasted Gudmundsson on another mailing list: The process for making DNS-related RFCs is open only in name. In reality, the people in the process of making DNS-releated RFCs are not listening to a number of important objections. For example, there was a recently proposed RFC which adds a bunch of arbitrary and, quite frankly, useless, rules to the AXFR (zone transfer) process. Dan, rightly so, brought up a number of objections with this internet draft. These objections were completely ignored. 2001-06-22: Gustafsson* released a new draft, axfr-clarify-02, with several ``major changes.'' Gudmundsson immediately issued a ``SHORT last call,'' with a deadline of 2001-06-30. Discussion over the next week included 3 messages from Darcy, 5 from Elz, 7 from Gustafsson*, 1 from Gudmundsson, 1 from Hall, 1 from Koch, 2 from Littlefield, and 4 from Vixie*. 2001-06-30: I returned from vacation. I immediately objected to Gudmundsson's absurd last-call schedule; Gudmundsson extended the deadline to 2001-07-06. I again pointed out that several of my objections had been ignored. ``They were not ignored,'' Gustafsson* said. ``They were considered and rejected.'' I began working on this web page. AXFR client security issues Suppose I'm an AXFR client transferring the princeton.edu zone. I will discard aol.com information from the princeton.edu servers. This is required for security: the princeton.edu servers aren't authorized to provide aol.com information. Gustafsson* claims that aol.com glue from the princeton.edu AXFR servers may safely be used in referrals below princeton.edu. This claim is false. Suppose, for example, I also happen to be a .com server, and I receive the records blah.princeton.edu NS dns-01.ns.aol.com dns-01.ns.aol.com A 128.112.136.10 from the princeton.edu AXFR servers. It is essential for me to discard the glue A record; otherwise I will poison caches, because caches trust dns-01.ns.aol.com information from .com servers. Parent-child discrepancies Suppose I'm an AXFR client transferring both princeton.edu and cs.princeton.edu. I will discard all princeton.edu AXFR results below cs.princeton.edu, in favor of the cs.princeton.edu results. To the extent that there's a difference, the princeton.edu servers are wrong. For example, the princeton.edu servers say cs.princeton.edu NS cs.princeton.edu cs.princeton.edu NS engram.cs.princeton.edu while the cs.princeton.edu servers say cs.princeton.edu NS dns1.cs.princeton.edu cs.princeton.edu NS dns2.cs.princeton.edu If someone asks me for the cs.princeton.edu NS records, I'm going to report dns1 and dns2, not engram. Note that, when I transfer princeton.edu, I have not yet decided to discard the cs.princeton.edu records from the princeton.edu servers; I don't know at that point whether I'm also transferring cs.princeton.edu. Records are discarded when the transfers are combined. Gustafsson* and Ohta claim that records are zone-specific: in particular, that the cs.princeton.edu NS engram.cs.princeton.edu record is a valid part of the princeton.edu zone. This is not consistent with the DNS specifications. Here's what RFC 1034 actually says: * DNS is divided into zones. Names are partitioned among zones. Each zone is authoritative for all records under its names. See RFC 1034, section 4.1. * Zones may, and sometimes must, contain records for which they aren't authoritative, i.e., records from other zones. These records are supposed to be exact copies of the authoritative records. See RFC 1034, section 4.2.1, last paragraph on page 20. When an administrator fails to correctly copy records, such as the cs.princeton.edu NS records, he is violating the protocol. He has no right to expect clients to preserve both sets of records. Clients can and do assume the accuracy of any record set received from any server authorized to provide that set. axfr-clarify-02 says that an AXFR client ``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.'' I object to this requirement, because (1) it is not necessary for interoperability and (2) it prohibits the behavior of my AXFR client, which discards records as described above when it is scripted in the usual way. This requirement violates RFC 2119, section 6. The IETF-50 DNSEXT meeting minutes said that there was ``more support'' for BIND 9's ``preservation of zone content'' than for the BIND 8 AXFR behavior. The minutes didn't say exactly how much support there was, or how many people attended, or how packed the room was with people having financial interests in BIND. Gustafsson* says that the IXFR protocol breaks if AXFR clients discard bad records. Well, that's too bad for the IXFR protocol. IXFR has an official status of Elective, and my users have a better protocol (rsync), so I am not going to support IXFR, and I object to the notion of IXFR-induced complications in the AXFR protocol. What is allowed in a zone? My DNS server reads all records from a single file; the system administrator doesn't have to worry about zones. My AXFR server defines the princeton.edu zone as the SOA record at princeton.edu and all available non-SOA records within princeton.edu. In particular, if the file includes an address for www.cs.princeton.edu, my AXFR server includes that address in the princeton.edu zone. This works just fine with my AXFR client and with the BIND 8 AXFR client. The client discards undesired records, as explained above; so the server doesn't have to. Unfortunately, the BIND 9 AXFR client rejects the entire zone transfer if it doesn't see www.cs.princeton.edu in an authoritative NS record inside the princeton.edu zone. This is a current interoperability problem. RFC 1034 and RFC 1035 don't prohibit zones of this type. The obvious fix for the interoperability problem is for BIND 9 to stop going out of its way to check the NS records. I could change my AXFR server to work around this BIND 9 bug. However, that would not be sensible engineering: it would take extra code, extra CPU time, and extra disk I/O. axfr-clarify-01 prohibits records ``from the authoritative data of zones other than the one being transferred.'' This is nonsense: every record is part of the authoritative data of some zone. See RFC 1034, section 4.2. axfr-clarify-02 prohibits records ``associated with zones other than the one being transferred.'' A record ``is associated with a zone by being loaded from the master file of that zone at the primary master server, or by some other, equivalent method for configuring zone data.'' This is horribly unclear. Is Gustafsson trying to prohibit the whole concept of a single DNS configuration file? I object to the use of BIND-specific notions here; all requirements should be defined in terms of on-the-wire behavior. Records outside the answer section axfr-clarify-02 says ``Slaves MUST ignore any authority section contents [and] any unexpected RRs in the additional section.'' I object to this requirement, because (1) it is not necessary for interoperability and (2) it prohibits the behavior of my AXFR client, which takes records from all sections. This requirement violates RFC 2119, section 6. Everyone agrees that records must never appear outside the answer section. If the server puts records outside the answer section, the server is violating the protocol. (There was consensus on this in a face-to-face meeting, and there has been no dispute on the mailing list.) This does not mean that the client is violating the protocol. Unauthorized clients axfr-clarify-02 says ``If the master server is unable or unwilling to provide a zone transfer, it MUST respond with a single DNS message containing an appropriate RCODE other than NOERROR.'' I object to this requirement, because (1) it is not necessary for interoperability and (2) it prohibits the behavior of my AXFR server, which simply closes the connection. This requirement violates RFC 2119, section 6. AXFR is a local matter between a master and its authorized slaves. Clients without authorization have no business asking for AXFR. Andrews* claims that clients cannot pipeline AXFRs on a single connection if servers are allowed to close connections. This claim is false. It is easy to construct a pipelining client that will handle errors properly. (In the real world, client implementors open separate TCP connections for separate transfers.) Clients checking RCODE axfr-clarify-02 says that an AXFR client ``MUST check the RCODE in each message and abort the transfer if it is not NOERROR.'' I object to this requirement, because (1) it is not necessary for interoperability and (2) it prohibits the behavior of my AXFR client, which uses a different method to check for errors. This requirement violates RFC 2119, section 6. Clients checking IDs axfr-clarify-02 says that an AXFR client ``SHOULD check the ID of the first message received and abort the transfer if it does not match the ID of the request.'' I object to this recommendation, because (1) it is not necessary for interoperability and (2) it discourages the behavior of my AXFR client, which doesn't bother checking the IDs. This recommendation violates RFC 2119, section 6. ``Failing to check the ID opens a server to spoofing,'' Wellington* claims. That's not true. TCP connections already have sequence numbers, and anyone who wants serious security for AXFR can run AXFR over IPSEC or ssh. IPSEC-protected AXFR shouldn't bother with TSIG, so why should it bother checking IDs? Andrews* points out that AXFR requests can, in theory, be multiplexed over a single TCP connection. I agree that a hypothetical multiplexing AXFR client would have to check IDs. But this has no relevance to the behavior of my AXFR client. Servers repeating questions axfr-clarify-02 says that ``The initial message of a zone transfer response SHOULD have a question section identical to that in the request.'' I object to this recommendation, because (1) it is not necessary for interoperability and (2) it discourages the behavior of my AXFR server, which doesn't bother repeating the question. Wellington* claims that this recommendation is ``an arbitrary decision based on existing practice.'' In fact, it is a pointless recommendation that does not take full account of existing practice. TSIG axfr-clarify-01 says that TSIG is ``RECOMMENDED.'' I objected to this recommendation. People protecting their communications with IPSEC, for example, should not be encouraged to use TSIG. This problem was fixed in axfr-clarify-02, which recommends ``a cryptographic mechanism for ensuring authenticity and integrity,'' such as TSIG or IPSEC or TLS. Servers setting RD axfr-clarify-01 says that RD in a zone-transfer response is copied from the request. I objected to this requirement, because (1) it is not necessary for interoperability and (2) it prohibits the behavior of my AXFR server, which always sets RD to 0. This requirement violates RFC 2119, section 6. This problem was fixed in axfr-clarify-02. I also proposed that RD be prohibited in AXFR requests. RD makes no sense for AXFR and is not used by existing AXFR clients. This proposal was ignored. Servers repeating records axfr-clarify-02 says that, aside from the repeated SOA, each record ``MUST be transmitted exactly once.'' This is how my AXFR server works, and it is how BIND 9 works. It is, however, completely out of whack with how most versions of BIND work. I object to this document being fraudulently characterized as a ``clarification,'' a codification of ``existing practice,'' and a description of ``the fielded DNS server software''; it should be labelled and reviewed as a revision of the protocol. References 1. http://cr.yp.to/djb.html 2. http://cr.yp.to/web.html 3. http://cr.yp.to/djbdns.html 4. http://cr.yp.to/djbdns/namedroppers.html 5. http://cr.yp.to/djbdns/namedroppers.html#2001-03-17 to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 4 14:27:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10230 for ; Wed, 4 Jul 2001 14:27:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15HrEF-000Om8-00 for namedroppers-data@psg.com; Wed, 04 Jul 2001 11:18:23 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15HrED-000Om1-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 11:18:21 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15HrED-000Cvc-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 11:18:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: tale@nominum.com (David C Lawrence) To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC Obsoleting IQUERY In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 04 Jul 2001 11:18:23 -0700 Content-Transfer-Encoding: 7bit Matt Crawford writes: > I support what this document tries to accomplish, but on reflection, > its statement that > > RFC 1035 sections 4.1.1 and 6.4 are changed. > > and subsequent claims that 1035 itself is altered are incompatible > with the fact that an RFC itself is never changed. Small tweaks > would make process-purists happier, I think. I've been reading too many government documents, I guess. I am completely fine with the changes you have proposed. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 4 15:12:07 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10556 for ; Wed, 4 Jul 2001 15:12:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15HrsB-0000nU-00 for namedroppers-data@psg.com; Wed, 04 Jul 2001 11:59:39 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15Hrs9-0000nG-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 11:59:37 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15Hrs9-000ExU-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 11:59:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: erik guttman Cc: Bernard Aboba , namedroppers@ops.ietf.org, cheshire@apple.com, levone@microsoft.com, dthaler@microsoft.com, bernarda@microsoft.com Subject: Re: Resolution of proposed changes to mDNS-00 draft References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 04 Jul 2001 11:59:39 -0700 Content-Transfer-Encoding: 7bit since you asked, i still prefer to continue using a single mechanism, dhcp in this case, as opposed to inventing new overlapping kludges. but you knew that already. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 4 15:12:11 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10567 for ; Wed, 4 Jul 2001 15:12:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Hrrn-0000n2-00 for namedroppers-data@psg.com; Wed, 04 Jul 2001 11:59:15 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15Hrrm-0000mv-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 11:59:14 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15Hrrm-000EwE-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 11:59:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Paul A Vixie To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC AXFR-02 SHORT last call In-Reply-To: Message from Olafur Gudmundsson/DNSEXT co-chair of "Wed, 04 Jul 2001 10:49:31 PDT." Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 04 Jul 2001 11:59:15 -0700 Content-Transfer-Encoding: 7bit > If your implementation is not compliant then you have three choices, > 1. Convince the working group to change the specification > 2. Update your incorrect implementation > 3. Discontinue distribution of non compliant software. You forgot one: 4. Continue distribution of noncompliant software (this shall be henceforth be known as the Scorched Earth approach.) to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 4 15:44:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10747 for ; Wed, 4 Jul 2001 15:44:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15HsP0-0002VS-00 for namedroppers-data@psg.com; Wed, 04 Jul 2001 12:33:34 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15HsP0-0002VM-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 12:33:34 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15HsP0-000Gcg-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 12:33:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Paul A Vixie Cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC AXFR-02 SHORT last call References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 04 Jul 2001 12:33:34 -0700 Content-Transfer-Encoding: 7bit >> If your implementation is not compliant then you have three choices, >> 1. Convince the working group to change the specification >> 2. Update your incorrect implementation >> 3. Discontinue distribution of non compliant software. > You forgot one: > 4. Continue distribution of noncompliant software and the 5th, changing the definition of compliance mid-stream this shall henceforth be known as ... [ i will resist ] randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 4 15:45:00 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10759 for ; Wed, 4 Jul 2001 15:44:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15HsNP-0002QA-00 for namedroppers-data@psg.com; Wed, 04 Jul 2001 12:31:55 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15HsNO-0002Q3-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 12:31:54 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15HsNO-000GXN-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 12:31:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Edward Lewis To: Roy Arends Cc: Edward Lewis , Roy Arends , Mark Kosters , , Subject: Re: Ideas on opt-in, was Re: I-D ACTION:draft-ietf-dnsext-dnssec-opt-in-00.txt In-Reply-To: References: X-Sender: lewis@pop.tislabs.com (Unverified) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 04 Jul 2001 12:31:55 -0700 Content-Transfer-Encoding: 7bit At 2:09 PM -0400 7/4/01, Roy Arends wrote: >The problem is that an administrator can secure a zone as thick as he >wants, a resolver can be tricked into accepting an unsecured record (that >in fact does not exist in the zone) because there is no indication how a Oh. Umm, yeah. I wasn't thinking of data insertion, just data deletion. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com You fly too often when ... the airport taxi is on speed-dial. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 4 15:45:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10770 for ; Wed, 4 Jul 2001 15:45:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15HsNZ-0002Ru-00 for namedroppers-data@psg.com; Wed, 04 Jul 2001 12:32:05 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15HsNY-0002Rm-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 12:32:04 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15HsNY-000GXt-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 12:32:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: RFC 2119 section 6 References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 04 Jul 2001 12:32:05 -0700 Content-Transfer-Encoding: 7bit Olafur Gudmundsson/DNSEXT co-chair writes: > you are really twisting RFC2119 section 6, by selective quoting. Here's 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. axfr-clarify repeatedly violates these requirements. For example, it says that implementors MUST use a particular method of extracting records from an AXFR response packet, even though that method is not required for interoperability. > The section is a warning about the over use of the word MUST not a > restriction on what can be specified. False. The section is a blanket prohibition on certain types of requirements and recommendations. It isn't limited to the word MUST; it applies to all ``imperatives of the type defined in this memo.'' Why are you trying to weasel out of this? Why are you trying to force me to change djbdns in ways that aren't required for interoperability? ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 4 16:28:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11256 for ; Wed, 4 Jul 2001 16:28:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Ht0T-0004bQ-00 for namedroppers-data@psg.com; Wed, 04 Jul 2001 13:12:17 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15Ht0S-0004bJ-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 13:12:16 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15Ht0S-000IXV-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 13:12:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC AXFR-02 SHORT last call References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 04 Jul 2001 13:12:17 -0700 Content-Transfer-Encoding: 7bit [ ok, boys and girls. can we get to technical substance please. this is the last i want to approve of the pissing contest until after the technical discussion on the last call completes. if it ever starts -- rb] Olafur Gudmundsson/DNSEXT co-chair writes: > Q: did you write your implementation of AXFR before or after version 00 > of the draft was published in March last year. I published my AXFR client and AXFR server in January 2000. > If your implementation is not compliant then you have three choices, > 1. Convince the working group to change the specification > 2. Update your incorrect implementation > 3. Discontinue distribution of non compliant software. Is your rhetoric supposed to have some relevance to the facts? My implementation works just fine. If _you_ want to change the IETF DNS specifications then _you_ have to convince the working group. You've been issuing absurd last calls, making unjustified claims of consensus, and otherwise abusing your power to push this biased vendor document out the door. I don't know what connection you have to the BIND company, but I'm willing to bet that your actions as DNSEXT chair have been influenced by communications that the rest of us haven't seen; I demand that you disclose the contents of those communications. > Unless it is posted on the mailing list, or sent to chairs&author(s) > working group can not consider this material as part of it. > Web pages are not acceptable input. Wow. Where do you get these ideas from? Are you trying to make sure that everyone has access to the input? If so, why is it enough to send input ``to chairs&author(s)''? Why don't the rest of us get to see the input? And why are DNSEXT activities being carried out on a censored mailing list where some input never appears? Or are you saying that all input should be permanently available in the mailing-list archives? If so, how do you explain I-Ds? I-Ds rarely appear in the archives; we download them from temporary IETF web pages. Perhaps more importantly, where do you get the idea that it's up to you, rather than the working group, to decide what input is acceptable? ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 4 16:28:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11267 for ; Wed, 4 Jul 2001 16:28:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Hsup-0004DN-00 for namedroppers-data@psg.com; Wed, 04 Jul 2001 13:06:27 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15Hsun-0004DG-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 13:06:25 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15Hsun-000IFX-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 13:06:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Paul A Vixie To: Robert Elz cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC AXFR-02 SHORT last call In-Reply-To: Message from Robert Elz of "Wed, 04 Jul 2001 14:00:20 +0700." <2188.994230020@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 04 Jul 2001 13:06:27 -0700 Content-Transfer-Encoding: 7bit > ... Using your terminology, all of them are master. No, using my terminology, all of them are authoritative. > For bind yes, that would have been fine. The redundancy helps detect > broken configurations though (better human interface). That was my view at the time I did it, but I'm less certain now. > For other specs we (sometimes) need a way to categorise the status of a > server for the zone however, so we do need terms. A server does not have a type, other than "authoritative for zero zones" vs. "authoritative for at least one zone". A server's relationship to a zone does not have a type, it has attributes: either authoritative for a zone, or not if authoritative: gets its zone data through the DNS (AXFR/IXFR), or not allows other servers to get copies of the zone data through DNS (AXFR/IXFR), or not > Nonsense - master==primary and slave==secondary - all that altered was > the word being used. There's no other distinction at all. That was not my intent. Referring to RFC 1996, some masters are also slaves, because in RFC 1996 what's being described are roles taken during AXFR/IXFR, which NOTIFY needed to stratify and declare. Primary/Secondary was absolutely wrong. Master/Slave is almost as wrong. > And none of this explains how we need the redundant combination > "primary master". It's a master that is never a slave. When DNS is being used (AXFR/IXFR) to propagate zone data, you need a name for the server:zone relationship that fetches the zone from outside the DNS, as for example a disk file or database. When DNS is not being used (AXFR/IXFR) to propagate zone data, then all you know about a server is that it is authoritative, since it is neither primary, nor secondary, nor master, nor slave. We all mistakenly call these "masters" because we've fallen into the trap of using types to define relationships between servers and zones, when we need to be using attributes. > Apologies if it seemed to be that way - that wasn't what I intended. Apology accepted, of course. > All I intended was to point out that the advocate for using these terms > has been you, all of this time. It has not come from anywhere else. Nevertheless I believed, until this week, that I had explained the issues clearly and won general acceptance for "attributes rather than types" back when RFC 1996 was being debated and prepared. Servers, btw, don't have types either. A server with zero authority zones could be either recursive or not, and caching or not. So could a server with one or more authority zones. We have got to stop thinking about servers having types, or a server's relationships to its zones (if any) having types, and start back in with attributes. The only use of the type distinction { master, slave } is to talk about what happens over an AXFR/IXFR transaction. Whereas the type distinction between { primary, secondary } has broader meaning, both in RFC1034/5, and in the field. I'm ready to admit that both are confusing, that RFC 1996 should have used terms like "transfer initiator" and "transfer responder", and that the term "primary master" should have been written "non-DNS zone data origin". But that's a far cry from "let's go back to primary/secondary", because those terms are meaningless to the protocol, however useful you may find them over in the dnsops wg or how useful we may find them in the field. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 4 18:53:02 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12297 for ; Wed, 4 Jul 2001 18:53:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15HvCN-000BGP-00 for namedroppers-data@psg.com; Wed, 04 Jul 2001 15:32:43 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15HvCL-000BGJ-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 15:32:41 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15HvCL-000PPl-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 15:32:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Masataka Ohta To: Robert Elz CC: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC AXFR-02 SHORT last call In-Reply-To: from Robert Elz at "Jul 4, 2001 05:00:50 am" X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 04 Jul 2001 15:32:43 -0700 Content-Transfer-Encoding: 7bit kre; > | Robert, you were involved in the RFC 1996 discussions, both in the meetings > | and here on the mailing list. > | The shorthand of "primary" used to mean "loads the zone content from outside > | the DNS" but that's a meaningless distinction if DNS isn't used to copy zones > | between the various authoritative servers for the zone. All of them would be > | primary in that case. The above statements by Paul should be interpreted that when DNS isn't used to copy zones, NOTIFY, RFC1996 and DYNUPD are meaningless. > Nonsense - master==primary and slave==secondary - all that altered was > the word being used. There's no other distinction at all. Wrong. There seems to be a lot of confusion. What Paul ignored is that there may be zone transfer between secondaries, even though he was warned so when he was writing RFC1996. A secondary name server may behave both as "master" and "slave" (a better terminology is "server" and "client" of RFC1995). > And none of this explains how we need the redundant combination > "primary master". We don't need it. Paul just put it in RFC1996 without answering the counter arguments. As a secondary name server may behave both as "master" and "slave", a combination of "master slave server" would make more sense (than negative infinity). Masataka Ohta to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 4 20:03:44 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13152 for ; Wed, 4 Jul 2001 20:03:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15HwP1-000EeP-00 for namedroppers-data@psg.com; Wed, 04 Jul 2001 16:49:51 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15HwP0-000EeF-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 16:49:50 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15HwP0-0003A0-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 16:49:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Mats Dufberg To: Roy Arends cc: DNSEXT , Subject: Re: I-D ACTION:draft-ietf-dnsext-dnssec-opt-in-00.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 04 Jul 2001 16:49:51 -0700 Content-Transfer-Encoding: 7bit On Tue, 3 Jul 2001, Roy Arends wrote: > There is no NXT/NO problem that has to be solved by SEC. Both RR types can > be in a zone, the server serves it, the resolver interprets it. I don't > see why a SEC record should indicate that there are NO records in a zone > or NXT records in zone. The response clearly has either NXT or NO in its > response. > > (The only reason for a SEC record I can think of is to indicate that there > are neither NO nor NXT records. That would obsolete opt-in all together) > > Note that this is not a "what to expect" thing. If the parent states that > a child is signed, the resolver expects either NXT or NO. (NO RR is still > draft ofcourse). > > It is a chicken or egg thing. If there exists no SEC RR for the child, > it gets either NXT or NO. If a signed zone without neither NXT nor NO is to be permitted, then that could be signaled by one NXT record, at the apex, with an RDATA not possible in the normal use of NXT. Mats ----------------------------------------------------------------- Mats Dufberg +46-8-545 857 06 dufberg@nic-se.se fax: +46-8-545 857 29 to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 4 21:01:02 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA13959 for ; Wed, 4 Jul 2001 21:01:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15HxG4-000HMW-00 for namedroppers-data@psg.com; Wed, 04 Jul 2001 17:44:40 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15HxG3-000HMQ-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 17:44:39 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15HxG3-0005qn-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 17:44:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roy Arends To: Cc: Subject: Re: Ideas on opt-in, was Re: I-D ACTION:draft-ietf-dnsext-dnssec-opt-in-00.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 04 Jul 2001 17:44:40 -0700 Content-Transfer-Encoding: 7bit > (In what follows I refer to the OPTIN RR-bit as "OPT") As there is already an OPT RRtype (#41, rfc2671), this should have an other name. My apologies if this might have confused some. Roy Arends Nominum to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jul 5 02:39:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA01928 for ; Thu, 5 Jul 2001 02:39:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15I2SD-0002QM-00 for namedroppers-data@psg.com; Wed, 04 Jul 2001 23:17:33 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15I2SD-0002QG-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 23:17:33 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15I2SD-000M0u-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 23:17:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Erik Guttman Reply-To: Erik Guttman To: Randy Bush Cc: erik guttman , Bernard Aboba , namedroppers@ops.ietf.org, cheshire@apple.com, levone@microsoft.com, dthaler@microsoft.com Subject: Re: Resolution of proposed changes to mDNS-00 draft In-Reply-To: "Your message with ID" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 04 Jul 2001 23:17:33 -0700 Content-Transfer-Encoding: 7bit > since you asked, i still prefer to continue using a single mechanism, dhcp > in this case, as opposed to inventing new overlapping kludges. but you knew > that already. Randy, So you favor the 'mDNS enable' approach over the 'domain search list' approach? Or are you suggesting something else? Erik to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jul 5 03:04:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03688 for ; Thu, 5 Jul 2001 03:04:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15I2wB-00036u-00 for namedroppers-data@psg.com; Wed, 04 Jul 2001 23:48:31 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15I2wB-00036o-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 23:48:31 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15I2wB-000NWR-00 for namedroppers@ops.ietf.org; Wed, 04 Jul 2001 23:48:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Bernard Aboba To: Robert Elz cc: namedroppers@ops.ietf.org Subject: Re: Resolution of proposed changes to mDNS-00 draft In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 04 Jul 2001 23:48:31 -0700 Content-Transfer-Encoding: 7bit On Wed, 4 Jul 2001, Robert Elz wrote: > Date: Tue, 03 Jul 2001 17:21:38 -0700 > From: Bernard Aboba > Message-ID: > > > | Submitted by: Erik Guttman, Dave Thaler > | Justification: Current language does not fully specify retransmission > | behavior. > > > | Repetition MUST NOT be attempted more than 3 times and SHOULD NOT > | be repeated more often than once per second to reduce unnecessary > | network taffic. Retry intervals SHOULD be exponentially increased, > | starting from a value of 1 second." > | > | Proposed resolution: Accept > > I don't mind that, but specifying "exponentially increased" for > something that can't be attempted more than 3 times doesn't achieve > very much at all ... in particular, delays of 1 second then 1.01 seconds, > then 1.02 seconds is exponentially increasing (just way down at the very > flat part of the curve...) Even flatter numbers could be chosen. > With so few attempts, just specifying "increased" is really enough. > For someone who uses bigger increases, is it really important to anything > that they choose 1, 2 and 3.00001 second delays, rather than 1, 2, > and 3 second delays? The latter is a linear increase, so clearly isn't > exponential, whereas 1, 2, and 3.00001 is (or can be justified as being so). Do you have a proposal for better text? Or do we just clarify, by saying "1, 2, 4 seconds"? > > > What? Since when did anyone ever forward mDNS responses anywhere, > under any circumstances? What is this supposed to be achieving? > I'll let Levon respond to this one. But I think the purpose was to alert one node that there was a conflict. However, as noted later on, all that will result is that the node will probe and not find a conflict (since the conflict is off link). So it doesn't fix the problem. > Surely when myhost gets the two response over 2 different interfaces > what it does is implementation defined (pick the first, pick the > last, return both, return an error, all are possible). > > Unless and until we get some experience with this, that shows that one > approach works best, leaving it implementation defined is best. Yes. There's no obvious answer. Do you have proposed modified text? > > I'd prefer omitting all of this, and just specifying it as being > implementation defined for now. Let's not try solving all the > world's problems in one go. > I agree with this, especially since it seems largely intractable ;) > | ARPA domain servers MUST NOT reply to requests for > | subdomains of '.local.arpa'. > > This is the last thing that we want. All that can possibly achieve is > to have the hosts that are sending the queries, sending more of them, > on the assumption that the query might have been lost. There MUST be > a reply (just like any other DNS query) - which at the very least will > cause the current query to be terminated, and if we're lucky, might even > be cached for a while, and prevent some future queries being sent to the > ARPA servers. Further, it would be making a truly silly special case > in the server implementations for that domain. Do you have a proposal for modified text? > There needs to be something in here to prevent hosts sending queries > for this domain to the ARPA servers (that's where it needs to be stopped > not at the ARPA servers). Do you have a suggestion for the "something"? to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jul 5 06:51:13 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06271 for ; Thu, 5 Jul 2001 06:51:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15I6RE-0008P8-00 for namedroppers-data@psg.com; Thu, 05 Jul 2001 03:32:48 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15I6RE-0008P2-00 for namedroppers@ops.ietf.org; Thu, 05 Jul 2001 03:32:48 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15I6RE-0008ai-00 for namedroppers@ops.ietf.org; Thu, 05 Jul 2001 03:32:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Alan Barrett To: Subject: Re: RFC 2119 section 6 In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Thu, 05 Jul 2001 03:32:48 -0700 Content-Transfer-Encoding: 7bit On Wed, 4 Jul 2001, D. J. Bernstein wrote: > Why are you trying to weasel out of this? Why are you trying > to force me to change djbdns in ways that aren't required for > interoperability? I would say that ignoring non-answer fields in AXFR, as described in axfr-clarify, is required for interoperability with potential future extensions to the protocol. Thinking about extensibility is an important part of protocol design. IETF protocols include many examples of such forethought, often in the form of fields reserved for future use with language like "MUST be zero when transmitted, MUST be ignored when received". Interoperability with future extensions is harmed when the sender fails to zero such fields, and is also harmed when the receiver fails to ignore such fields. It's perfectly appropriate to use "MUST" or "MUST NOT" when specifying behaviour that is expected to enable or interfere with future extensibility. --apb (Alan Barrett) to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jul 5 07:03:17 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07063 for ; Thu, 5 Jul 2001 07:03:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15I6n9-0008xN-00 for namedroppers-data@psg.com; Thu, 05 Jul 2001 03:55:27 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15I6n8-0008xH-00 for namedroppers@ops.ietf.org; Thu, 05 Jul 2001 03:55:26 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15I6n8-0009hf-00 for namedroppers@ops.ietf.org; Thu, 05 Jul 2001 03:55:26 -0700 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-roadmap-04.txt Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Thu, 05 Jul 2001 03:55:27 -0700 --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-04.txt Pages : 12 Date : 03-Jul-01 DNS Security (DNSSEC)technology is composed of extensions to the Domain Name System (DNS) protocol that provide data integrity and authentication to security aware resolvers and applications through the use of cryptographic digital signatures. Several documents exist to describe these extensions and the implementation-specific details regarding specific digital signing schemes. The interrelationship between these different documents is discussed here. A brief overview of what to find in which document and author guidelines for what to include in new DNS Security documents, or revisions to existing documents, is described. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-roadmap-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-roadmap-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-roadmap-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: <20010703124439.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-roadmap-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-roadmap-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010703124439.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jul 5 07:03:48 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07080 for ; Thu, 5 Jul 2001 07:03:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15I6n1-0008xB-00 for namedroppers-data@psg.com; Thu, 05 Jul 2001 03:55:19 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15I6n1-0008x5-00 for namedroppers@ops.ietf.org; Thu, 05 Jul 2001 03:55:19 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15I6n1-0009hF-00 for namedroppers@ops.ietf.org; Thu, 05 Jul 2001 03:55:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-roadmap-04.txt Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Thu, 05 Jul 2001 03:55:19 -0700 Content-Transfer-Encoding: 7bit --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-04.txt Pages : 12 Date : 03-Jul-01 DNS Security (DNSSEC)technology is composed of extensions to the Domain Name System (DNS) protocol that provide data integrity and authentication to security aware resolvers and applications through the use of cryptographic digital signatures. Several documents exist to describe these extensions and the implementation-specific details regarding specific digital signing schemes. The interrelationship between these different documents is discussed here. A brief overview of what to find in which document and author guidelines for what to include in new DNS Security documents, or revisions to existing documents, is described. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-roadmap-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-roadmap-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-roadmap-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: <20010703124439.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-roadmap-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-roadmap-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010703124439.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jul 5 09:00:02 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10761 for ; Thu, 5 Jul 2001 09:00:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15I8Jn-000BMn-00 for namedroppers-data@psg.com; Thu, 05 Jul 2001 05:33:15 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15I8Jn-000BMh-00 for namedroppers@ops.ietf.org; Thu, 05 Jul 2001 05:33:15 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15I8Jn-000ETh-00 for namedroppers@ops.ietf.org; Thu, 05 Jul 2001 05:33:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Paul A Vixie cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC AXFR-02 SHORT last call In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Thu, 05 Jul 2001 05:33:15 -0700 Content-Transfer-Encoding: 7bit Date: Wed, 04 Jul 2001 13:06:27 -0700 From: Paul A Vixie Message-ID: | A server's relationship to a zone does not have a type, it has attributes: The type is just an attribute. In this case it is the attribute that tells the server how it loads the zone. We call it "primary" for the zone if it loads the data from a file. We call it "secondary" if it loads the data via AXFR (or IXFR). That's how it has been since forever. | That was not my intent. Referring to RFC 1996, some masters are also slaves, | because in RFC 1996 what's being described are roles taken during AXFR/IXFR, | which NOTIFY needed to stratify and declare. As Otha-san said in his reply to me, client/server is the standard terminology to describe those roles. We didn't need to invent new terminology for this. | It's a master that is never a slave. That may have been useful in 1996 (though I'd have to think about it a bit more to see if it really makes sense even there), but here in the description of AXFR, it makes no sense at all - all that matters to this doc are the two end points of one AXFR transaction. | When DNS is not being used (AXFR/IXFR) to propagate zone data, then all you | know about a server is that it is authoritative, Yes - there's way to much demand for primary/secondary info which makes no sense (including when domains are registered - all that the parent needs to know is a list of servers, asking which server is primary is none of its business). | since it is neither primary, nor secondary, nor master, nor slave. But that's not right - it is primary or secondary - it fetched the data from somewhere after all. What isn't available is any way for any outsider to discover that information. | Nevertheless I believed, until this week, that I had explained the issues | clearly and won general acceptance for "attributes rather than types" back | when RFC 1996 was being debated and prepared. That battle would have made no sense, because the type just is one of the attributes - that is, you're arguing for fruit rather than apples... If the point had been that there are other attributes than the type, then yes, that's correct, but that never seemed to really be it. At the time (as best I remember it, which might not be all that good) the point seemed to be that to call a server "primary" was wrong, what it is is primary for some particular zone. | The only use of the type distinction { master, slave } is to talk about what | happens over an AXFR/IXFR transaction. No it isn't. That is one use - and for that one, client/server would be better terms. But there are also a whole bunch of operational issues where the source of the data is important. If I see two servers with different SOA.serial values for a zone, I want to know the relationship between the servers. If the one with the larger serial is primary for the zone, and the one with the smaller serial is secondary, then I go back to sleep for a while, as this is a normal situation. If they're both secondary, then I see if I can find the primary, and repeat the test using it, with each of the secondaries. In other cases, there's a problem that needs to be fixed. | But that's a far cry from "let's go back to primary/secondary", | because those terms are meaningless to the protocol, Any term is meaningless to the protocol, which is just shovelling bits from place to place. For the spec of the protocol, any term would do to describe anything that we want it to describe - we just define it. But when doing that, it makes sense to use terms which have as many of the following attributes as we can find (presented in no particular order, which is more important will vary from case to case). First, it helps if they're easy to read, understand and remember. Second it helps if they naturally suggest the meaning defined for them. Third it helps if they're terms used for much the same function other places in the same protocol set. Fourth it helps if they're the same terms used for similar operations in other protocols. We could use primary/secondary, we could use client/server - each of those meets some of the requirements. Master/slave meets fewer - it is new terminology to the DNS (it was anyway), it isn't used in other protocols, and it would normally suggest that the master is in control, and the slave is doing what it is told, whereas the way it is being used for AXFR, it is the slave that initiates everything, the master just responds with the data it has been told to send... So, while we're not going to rewrite 1996 just now, to rid us of the terms that should never have been used, there's no point continuing with their usage in new docs. Just use client/server to describe the roles played in an AXFR transfer, it is much simpler. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jul 5 13:15:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20329 for ; Thu, 5 Jul 2001 13:15:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15ICRC-000Hq1-00 for namedroppers-data@psg.com; Thu, 05 Jul 2001 09:57:10 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15ICRC-000Hpt-00 for namedroppers@ops.ietf.org; Thu, 05 Jul 2001 09:57:10 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15ICRC-0001Mb-00 for namedroppers@ops.ietf.org; Thu, 05 Jul 2001 09:57:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Bernard Aboba cc: namedroppers@ops.ietf.org Subject: Re: Resolution of proposed changes to mDNS-00 draft In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Thu, 05 Jul 2001 09:57:10 -0700 Content-Transfer-Encoding: 7bit Date: Wed, 4 Jul 2001 23:33:35 -0700 (PDT) From: Bernard Aboba Message-ID: | > | Submitted by: Erik Guttman, Dave Thaler | > | Justification: Current language does not fully specify retransmission | > | behavior. | Do you have a proposal for better text? Or do we just clarify, by saying | "1, 2, 4 seconds"? I would just say ... Repetition MUST NOT be attempted more than 3 times and SHOULD NOT be repeated more often than once per second to reduce unnecessary network traffic. [aside, my spell checker noticed a typo in the original when I pasted it, traffic was missing the 'r' - I didn't spot that one myself] That's sufficient. That is, just drop the second proposed sentence which says about exponential increases. I don't like a 1 2 4 second requirement, in most LANs that's overkill. That is, it generates exactly the same amount of traffic, but causes the client to have to wait longer ... In practice, if the node that could answer is ever going to answer, it will do so on the first or second transmission anyway, the extras will rarely help. It might be worth adding The delay between attempts should be randomised so as to avoid synchronisation effects. perhaps. I doubt any more than that is really required. | > Unless and until we get some experience with this, that shows that one | > approach works best, leaving it implementation defined is best. | | Yes. There's no obvious answer. Do you have proposed modified text Just say: If an mDNS client sends requests over multiple interfaces, and receives replies from more than one, the result returned to the client is implementation defined. If you want, leave in some of the explanations of what is happening. My guess is that most clients will be gone immediately after the first reply is received anyway "I want an answer, someone sent me the answer, I'm done" - they won't be hanging around waiting just in case another answer happens to come from someplace else (how long would they wait? 99% of the time there never will be any more). So the usual result is going to be "first answer received wins" I suspect. But none of that should be mentioned. Note that the obvious case where this is likely to happen, is where not only is the source of the mDNS query multi-homed on two (or more) interfaces, but so is the destination - so the destination node (which is target.local.arpa or whatever) will see the mDNS request on both of its interfaces, and reply on both, so there will be two replies. While it some circumstances the replies might be identical (containing both addresses) I can also see mDNS server implementations returning only the address of the interface over which they received the query (avoid problems of nodes attempting to access some "foreign" net - there might be no router). In the case where only link local addresses are in use (on both interfaces) that behaviour is mandatory of course (you can't return a link local address for one interface to nodes on a different one). So, in that case, there will be two different replies (even if the numeric value of the address is the same, it is a different address) that have originated at the same node (an undetectable difference from a name duplication). | > | ARPA domain servers MUST NOT reply to requests for | > | subdomains of '.local.arpa'. | Do you have a proposal for modified text? For this part, no, no text is needed. Just delete the offending sentence entirely. We don't need to give any instructions at all to the ARPA domain servers - they just need to do what they always do. | > There needs to be something in here to prevent hosts sending queries | > for this domain to the ARPA servers (that's where it needs to be stopped | > not at the ARPA servers). | | Do you have a suggestion for the "something"? This one is hard, and I'm not sure what is best. Perhaps something like ... DNS servers SHOULD NOT forward queries for domain names in the local.arpa domain - if the server cannot answer the query from its own database, it should reply with a non-authoritative NXDOMAIN. But that is perhaps too strict, in some cases it is OK to forward queries from a local back end resolver to a local server ... But how to describe this in any kind of words that makes sense is beyond me at the minute. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jul 5 14:10:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22094 for ; Thu, 5 Jul 2001 14:10:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15IDD0-000J0d-00 for namedroppers-data@psg.com; Thu, 05 Jul 2001 10:46:34 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15IDD0-000J0X-00 for namedroppers@ops.ietf.org; Thu, 05 Jul 2001 10:46:34 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15IDCz-0003nM-00 for namedroppers@ops.ietf.org; Thu, 05 Jul 2001 10:46:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: RFC 2119 section 6 References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Thu, 05 Jul 2001 10:46:34 -0700 Content-Transfer-Encoding: 7bit Alan Barrett writes: > extensibility We aren't talking about a new protocol. We're talking about a protocol that is already widely deployed. Section-based extensibility is not part of the existing protocol. I have updated my web page, http://cr.yp.to/djbdns/axfr-clarify.html, to cover this topic: Records outside the answer section axfr-clarify-02 says ``Slaves MUST ignore any authority section contents [and] any unexpected RRs in the additional section.'' I object to this requirement, because (1) it is not necessary for interoperability and (2) it prohibits the behavior of my AXFR client, which takes records from all sections. This requirement violates RFC 2119, section 6. RFC 1034 does not say ``clients read only the answer section.'' It also does not say ``clients read the entire packet.'' Both methods work correctly. Everyone agrees that records must never appear outside the answer section. If the server puts records outside the answer section, the server is violating the protocol. (There was consensus on this in a face-to-face meeting, and there has been no dispute on the mailing list.) This does not mean that the client is violating the protocol. Andrews* says that he might want to extend the zone-transfer protocol by putting new information into the authority section and the answer section. He admits that this extension would be incompatible with my AXFR client, which is deployed at thousands of sites. Does he draw the obvious conclusion that the incompatible protocol should be deployed on a different TCP port? No! He demands that my users and I go to extra effort so that he can run an incompatible protocol on the same port. Yes, extensibility is often a helpful protocol feature, but it is fifteen years too late to start adding new forms of extensibility to the AXFR protocol. We have an installed base now, and the BIND company does not have the right to break compatibility with the installed base, even if it drops the pretense that it is merely ``clarifying'' the existing protocol. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jul 5 14:18:08 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22327 for ; Thu, 5 Jul 2001 14:18:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15IDDP-000J1F-00 for namedroppers-data@psg.com; Thu, 05 Jul 2001 10:46:59 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15IDDP-000J19-00 for namedroppers@ops.ietf.org; Thu, 05 Jul 2001 10:46:59 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15IDDP-0003od-00 for namedroppers@ops.ietf.org; Thu, 05 Jul 2001 10:46:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Kevin Darcy To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC AXFR-02 SHORT last call References: X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.8 sun4u) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Thu, 05 Jul 2001 10:46:59 -0700 Content-Transfer-Encoding: 7bit I think the terminology suffers from trying to straddle two different scopes at once. When the scope is *transactional*, what matters is which node is the initiator of the transaction, and which node is the responder. At a transactional scope, I agree with Robert and Ohta-san that "client/server" is perfectly good terminology; it's well understood and consistent with the terminology used in other protocols. But DNS zone-data replication is more than just an episodic series of unrelated transactions. When the scope of the terminology is to describe the role of a particular nameserver in an *infrastructure*, something more descriptive than "client" or "server" is called for. This is because the infrastructure may have a multiple-level dependency graph, where a given node might be a "client" for the transfer of a particular zone at one moment, and then the next moment turn around and be the "server" for the transfer of that zone. And let's not foreclose the possibility that a future extension of the protocol may allow a "master" server (to use the BIND terminology) to *push* a zone transfer to a "slave" server. This possibility makes the "client/server" terminology even less useful/desirable as a way to label nodes in a DNS infrastructure. >From an infrastructure or data-flow perspective, what is important is not which node initiates any given transfer transaction, but where the data enters the system, and where/how it gets replicated from there. Perhaps the optimal terms to use at this scope are "origin" and "replica". In the case of a multiple-level dependency graph, the replicas can be differentiated as "tier 1 replicas", "tier 2 replicas" and so forth. The "primary/secondary" terminology has proven to be confusing to novices. It seems to imply a sequential ordering, and many novices take that to mean that, in the context of NS selection, nameservers will attempt to contact the "primary" NS and only if that fails, resort to contacting the "secondary" NS. Obviously, that's not how it works in practice, but the terminology misleads some people into thinking that. Moreover, sometimes "primary" and "secondary" are used to refer to the first- and second-listed nameservers in a stub resolver configuration, thus muddying the waters even more. I agree that "master" and "slave" are also slightly misleading, because they imply that one node -- the master -- exercises some form of direct control over another node -- the slave -- with respect to replication, when in actual fact the "slave" operates somewhat autonomously. It can ignore a NOTIFY if it wants to, or defer a refresh if it happens to be overloaded. The coupling between authoritative servers of a zone using AXFR/IXFR for replication, is perhaps too loose for the "master/slave" terminology to be appropriate -- it perhaps implies a degree of control that simply doesn't exist. So, to summarize, while I'm not completely comfortable with the "master/slave" terminology, I consider it preferable to "client/server" in general (perhaps because I am an administrator I care more about describing DNS infrastructure than I do about the minutiae of particular zone-transfer transactions), and far preferable to "primary/secondary", which is just downright confusing and/or misleads many folks. - Kevin Robert Elz wrote: > Date: Wed, 04 Jul 2001 13:06:27 -0700 > From: Paul A Vixie > Message-ID: > > | A server's relationship to a zone does not have a type, it has attributes: > > The type is just an attribute. In this case it is the attribute that > tells the server how it loads the zone. We call it "primary" for the > zone if it loads the data from a file. We call it "secondary" if it > loads the data via AXFR (or IXFR). > > That's how it has been since forever. > > | That was not my intent. Referring to RFC 1996, some masters are also slaves, > | because in RFC 1996 what's being described are roles taken during AXFR/IXFR, > | which NOTIFY needed to stratify and declare. > > As Otha-san said in his reply to me, client/server is the standard > terminology to describe those roles. > > We didn't need to invent new terminology for this. > > | It's a master that is never a slave. > > That may have been useful in 1996 (though I'd have to think about it > a bit more to see if it really makes sense even there), but here in the > description of AXFR, it makes no sense at all - all that matters to this > doc are the two end points of one AXFR transaction. > > | When DNS is not being used (AXFR/IXFR) to propagate zone data, then all you > | know about a server is that it is authoritative, > > Yes - there's way to much demand for primary/secondary info which makes > no sense (including when domains are registered - all that the parent needs > to know is a list of servers, asking which server is primary is none of its > business). > > | since it is neither primary, nor secondary, nor master, nor slave. > > But that's not right - it is primary or secondary - it fetched the data > from somewhere after all. What isn't available is any way for any > outsider to discover that information. > > | Nevertheless I believed, until this week, that I had explained the issues > | clearly and won general acceptance for "attributes rather than types" back > | when RFC 1996 was being debated and prepared. > > That battle would have made no sense, because the type just is one of > the attributes - that is, you're arguing for fruit rather than apples... > > If the point had been that there are other attributes than the type, > then yes, that's correct, but that never seemed to really be it. > > At the time (as best I remember it, which might not be all that good) > the point seemed to be that to call a server "primary" was wrong, what > it is is primary for some particular zone. > > | The only use of the type distinction { master, slave } is to talk about what > | happens over an AXFR/IXFR transaction. > > No it isn't. That is one use - and for that one, client/server would > be better terms. But there are also a whole bunch of operational issues > where the source of the data is important. If I see two servers with > different SOA.serial values for a zone, I want to know the relationship > between the servers. If the one with the larger serial is primary for the > zone, and the one with the smaller serial is secondary, then I go back to > sleep for a while, as this is a normal situation. If they're both secondary, > then I see if I can find the primary, and repeat the test using it, with > each of the secondaries. In other cases, there's a problem that needs to > be fixed. > > | But that's a far cry from "let's go back to primary/secondary", > | because those terms are meaningless to the protocol, > > Any term is meaningless to the protocol, which is just shovelling bits > from place to place. For the spec of the protocol, any term would do > to describe anything that we want it to describe - we just define it. > But when doing that, it makes sense to use terms which have as many of > the following attributes as we can find (presented in no particular order, > which is more important will vary from case to case). First, it helps > if they're easy to read, understand and remember. Second it helps if > they naturally suggest the meaning defined for them. Third it helps if > they're terms used for much the same function other places in the same > protocol set. Fourth it helps if they're the same terms used for similar > operations in other protocols. > > We could use primary/secondary, we could use client/server - each of those > meets some of the requirements. Master/slave meets fewer - it is new > terminology to the DNS (it was anyway), it isn't used in other protocols, > and it would normally suggest that the master is in control, and the slave > is doing what it is told, whereas the way it is being used for AXFR, it is > the slave that initiates everything, the master just responds with the data > it has been told to send... > > So, while we're not going to rewrite 1996 just now, to rid us of the > terms that should never have been used, there's no point continuing with > their usage in new docs. Just use client/server to describe the roles > played in an AXFR transfer, it is much simpler. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jul 5 15:27:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24542 for ; Thu, 5 Jul 2001 15:27:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15IEZl-000LJv-00 for namedroppers-data@psg.com; Thu, 05 Jul 2001 12:14:09 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15IEZl-000LJm-00 for namedroppers@ops.ietf.org; Thu, 05 Jul 2001 12:14:09 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15IEZl-0008BA-00 for namedroppers@ops.ietf.org; Thu, 05 Jul 2001 12:14:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Kevin Darcy To: namedroppers@ops.ietf.org Subject: Re: RFC 2119 section 6 References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Thu, 05 Jul 2001 12:14:09 -0700 Content-Transfer-Encoding: 7bit D. J. Bernstein wrote: > We aren't talking about a new protocol. We're talking about a protocol > that is already widely deployed. Section-based extensibility is not part > of the existing protocol. Section-based extensibility *is* part of the protocol, based on the evidence of things like TSIG, SIG(0) and EDNS0, any of which could be used in an AXFR response. Where have you been the last few years? If your client croaks on unexpected RR's in Authority or Additional of an AXFR response, it's broken. The clarify-draft just makes it official. - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jul 6 00:09:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA06191 for ; Fri, 6 Jul 2001 00:09:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15IMbv-0009b3-00 for namedroppers-data@psg.com; Thu, 05 Jul 2001 20:48:55 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15IMbu-0009ax-00 for namedroppers@ops.ietf.org; Thu, 05 Jul 2001 20:48:54 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15IMbu-000752-00 for namedroppers@ops.ietf.org; Thu, 05 Jul 2001 20:48:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: gson@nominum.com (Andreas Gustafsson) To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC AXFR-02 SHORT last call In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Thu, 05 Jul 2001 20:48:55 -0700 Content-Transfer-Encoding: 7bit D. J. Bernstein writes: > AXFR client security issues > > Suppose I'm an AXFR client transferring the princeton.edu zone. I will > discard aol.com information from the princeton.edu servers. This is > required for security: the princeton.edu servers aren't authorized to > provide aol.com information. > > Gustafsson* claims that aol.com glue from the princeton.edu AXFR > servers may safely be used in referrals below princeton.edu. This > claim is false. Suppose, for example, I also happen to be a .com > server, and I receive the records > blah.princeton.edu NS dns-01.ns.aol.com > dns-01.ns.aol.com A 128.112.136.10 > > from the princeton.edu AXFR servers. It is essential for me to discard > the glue A record; otherwise I will poison caches, because caches > trust dns-01.ns.aol.com information from .com servers. No. What is essential is that the server does not send the dns-01.ns.aol.com glue as part of referrals out of any zone other than princeton.edu. > Parent-child discrepancies > > Suppose I'm an AXFR client transferring both princeton.edu and > cs.princeton.edu. I will discard all princeton.edu AXFR results below > cs.princeton.edu, in favor of the cs.princeton.edu results. > > To the extent that there's a difference, the princeton.edu servers are > wrong. For example, the princeton.edu servers say > cs.princeton.edu NS cs.princeton.edu > cs.princeton.edu NS engram.cs.princeton.edu > > while the cs.princeton.edu servers say > cs.princeton.edu NS dns1.cs.princeton.edu > cs.princeton.edu NS dns2.cs.princeton.edu > > If someone asks me for the cs.princeton.edu NS records, I'm going to > report dns1 and dns2, not engram. > > Note that, when I transfer princeton.edu, I have not yet decided to > discard the cs.princeton.edu records from the princeton.edu servers; I > don't know at that point whether I'm also transferring > cs.princeton.edu. Records are discarded when the transfers are > combined. > > Gustafsson* and Ohta claim that records are zone-specific: in > particular, that the cs.princeton.edu NS engram.cs.princeton.edu > record is a valid part of the princeton.edu zone. This is not > consistent with the DNS specifications. Here's what RFC 1034 actually > says: > * DNS is divided into zones. Names are partitioned among zones. Each > zone is authoritative for all records under its names. See RFC > 1034, section 4.1. > * Zones may, and sometimes must, contain records for which they > aren't authoritative, i.e., records from other zones. These > records are supposed to be exact copies of the authoritative > records. See RFC 1034, section 4.2.1, last paragraph on page 20. > > When an administrator fails to correctly copy records, such as the > cs.princeton.edu NS records, he is violating the protocol. He has no > right to expect clients to preserve both sets of records. Clients can > and do assume the accuracy of any record set received from any server > authorized to provide that set. RFC1034 says the records in the parent "should" (not "must") be exactly the same as those in the child. This is an operational recommendation, not a protocol requirement, and in practice, discrepancies are extremely common and must be dealt with by the protocol. > axfr-clarify-02 says that an AXFR client ``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.'' I object to this requirement, because (1) it is > not necessary for interoperability and (2) it prohibits the behavior > of my AXFR client, which discards records as described above when it > is scripted in the usual way. This requirement violates RFC 2119, > section 6. The requirement is necessary for interoperability of downstream IXFR servers. > The IETF-50 DNSEXT meeting minutes said that there was ``more > support'' for BIND 9's ``preservation of zone content'' than for the > BIND 8 AXFR behavior. The minutes didn't say exactly how much support > there was, or how many people attended, or how packed the room was > with people having financial interests in BIND. > > Gustafsson* says that the IXFR protocol breaks if AXFR clients discard > bad records. Well, that's too bad for the IXFR protocol. IXFR has an > official status of Elective, and my users have a better protocol > (rsync), so I am not going to support IXFR, and I object to the notion > of IXFR-induced complications in the AXFR protocol. > > What is allowed in a zone? > > My DNS server reads all records from a single file; the system > administrator doesn't have to worry about zones. My AXFR server > defines the princeton.edu zone as the SOA record at princeton.edu and > all available non-SOA records within princeton.edu. > > In particular, if the file includes an address for > www.cs.princeton.edu, my AXFR server includes that address in the > princeton.edu zone. If your server is the primary master for princeton.edu, it can of course define the princeton.edu zone any way it likes, including the way you described. However, if it is a slave, it should respect the intent of the master administrator and not insert records that were not present on the primary master. > This works just fine with my AXFR client and with the BIND 8 AXFR > client. The client discards undesired records, as explained above; so > the server doesn't have to. > > Unfortunately, the BIND 9 AXFR client rejects the entire zone transfer > if it doesn't see www.cs.princeton.edu in an authoritative NS record > inside the princeton.edu zone. This is a current interoperability > problem. I have no idea what you are talking about here. The draft does not specify that such a transfer should be rejected, and as far as I know, BIND 9 will accept it with no problem. If you have evidence to the contrary, please submit it in a bug report to bind9-bugs@isc.org. > axfr-clarify-01 prohibits records ``from the authoritative data of > zones other than the one being transferred.'' This is nonsense: every > record is part of the authoritative data of some zone. See RFC 1034, > section 4.2. > > axfr-clarify-02 prohibits records ``associated with zones other than > the one being transferred.'' A record ``is associated with a zone by > being loaded from the master file of that zone at the primary master > server, or by some other, equivalent method for configuring zone > data.'' > > This is horribly unclear. Is Gustafsson trying to prohibit the whole > concept of a single DNS configuration file? Of course not - that's why it says "or by some other, equivalent method for configuring zone data". Any configuration method that unambiguously maps a zone name into a collection of RRs is acceptable. All that section is saying is that once this collection of RRs has been defined, transporting it by means of zone transfers must not cause it to be altered. > I object to the use of > BIND-specific notions here; all requirements should be defined in > terms of on-the-wire behavior. The use of master files to define zone data is not a BIND-specific notion, it is an RFC1035 notion, and as I said, the draft specifically allows alternative configuration mechanisms. > Records outside the answer section > > axfr-clarify-02 says ``Slaves MUST ignore any authority section > contents [and] any unexpected RRs in the additional section.'' > > I object to this requirement, because (1) it is not necessary for > interoperability and (2) it prohibits the behavior of my AXFR client, > which takes records from all sections. This requirement violates RFC > 2119, section 6. Alan Barrett already responded to this, and I concur with his response. > Unauthorized clients > > axfr-clarify-02 says ``If the master server is unable or unwilling to > provide a zone transfer, it MUST respond with a single DNS message > containing an appropriate RCODE other than NOERROR.'' > > I object to this requirement, because (1) it is not necessary for > interoperability and (2) it prohibits the behavior of my AXFR server, > which simply closes the connection. This requirement violates RFC > 2119, section 6. The requirement to send a response is already implicit in the nature of the DNS protocol as a query-response protocol. The fact that the quoted paragraph reiterates this requirement is incidental; its main point is to specify the format of the response, which is not clear in RFC1034. In my opinion, a server which closes the connection is not violating the AXFR protocol, it is refusing to speak it and therefore outside the scope of the draft. > AXFR is a local matter between a master and its authorized slaves. > > Clients without authorization have no business asking for AXFR. > > Andrews* claims that clients cannot pipeline AXFRs on a single > connection if servers are allowed to close connections. This claim is > false. It is easy to construct a pipelining client that will handle > errors properly. (In the real world, client implementors open separate > TCP connections for separate transfers.) > > Clients checking RCODE > > axfr-clarify-02 says that an AXFR client ``MUST check the RCODE in > each message and abort the transfer if it is not NOERROR.'' > > I object to this requirement, because (1) it is not necessary for > interoperability and (2) it prohibits the behavior of my AXFR client, > which uses a different method to check for errors. This requirement > violates RFC 2119, section 6. > > Clients checking IDs > > axfr-clarify-02 says that an AXFR client ``SHOULD check the ID of the > first message received and abort the transfer if it does not match the > ID of the request.'' > > I object to this recommendation, because (1) it is not necessary for > interoperability and (2) it discourages the behavior of my AXFR > client, which doesn't bother checking the IDs. This recommendation > violates RFC 2119, section 6. IDs and RCODEs are checked in all other contexts of the DNS protocol, and I don't think it was the intent of RFC1034/1035 to make AXFR an exception. The draft is attempting to capture this presumed intent to the extent possible, making specific exceptions only where required for interoperability with existing implementations. > ``Failing to check the ID opens a server to spoofing,'' Wellington* > claims. That's not true. TCP connections already have sequence > numbers, and anyone who wants serious security for AXFR can run AXFR > over IPSEC or ssh. IPSEC-protected AXFR shouldn't bother with TSIG, so > why should it bother checking IDs? > > Andrews* points out that AXFR requests can, in theory, be multiplexed > over a single TCP connection. I agree that a hypothetical multiplexing > AXFR client would have to check IDs. But this has no relevance to the > behavior of my AXFR client. I agree that the issues of spoofing and multiplexing are irrelevant. They were not the reasons for the current wording of the draft. > Servers repeating questions > > axfr-clarify-02 says that ``The initial message of a zone transfer > response SHOULD have a question section identical to that in the > request.'' > > I object to this recommendation, because (1) it is not necessary for > interoperability and (2) it discourages the behavior of my AXFR > server, which doesn't bother repeating the question. > > Wellington* claims that this recommendation is ``an arbitrary decision > based on existing practice.'' In fact, it is a pointless > recommendation that does not take full account of existing practice. Responses to other forms of DNS queries contain a copy of the question, and again I don't see any indication in RFC1034/1035 that AXFR was intended to be an exception. > I also proposed that RD be prohibited in AXFR requests. RD makes no > sense for AXFR and is not used by existing AXFR clients. This proposal > was ignored. I have no problem with adding such a requirement, but wouldn't that violate RFC 2119, section 6? > Servers repeating records > > axfr-clarify-02 says that, aside from the repeated SOA, each record > ``MUST be transmitted exactly once.'' > > This is how my AXFR server works, and it is how BIND 9 works. It is, > however, completely out of whack with how most versions of BIND work. I have already agreed to change this into a SHOULD. > I object to this document being fraudulently characterized as a > ``clarification,'' a codification of ``existing practice,'' and a > description of ``the fielded DNS server software''; it should be > labelled and reviewed as a revision of the protocol. The draft *is* a revision of the protocol as it replaces "The first and last messages must contain the data for the top authoritative node of the zone" with "The first and last RR transmitted must be the SOA record of the zone". Whether any other aspects of the draft should also be characterized as changes to the protocol will depend on your particular interpretation of RFC103[45]. In any case, I fully expect the draft to be reviewed as a revision of the protocol. As for using the word "clarifications" in the title, that follows the example of RFC2181, which also updated RFC1034. -- Andreas Gustafsson, gson@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jul 6 00:24:50 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA06916 for ; Fri, 6 Jul 2001 00:24:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15IMxJ-000ACJ-00 for namedroppers-data@psg.com; Thu, 05 Jul 2001 21:11:01 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15IMxJ-000ACC-00 for namedroppers@ops.ietf.org; Thu, 05 Jul 2001 21:11:01 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15IMxJ-000892-00 for namedroppers@ops.ietf.org; Thu, 05 Jul 2001 21:11:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: RFC 2119 section 6 References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Thu, 05 Jul 2001 21:11:01 -0700 Content-Transfer-Encoding: 7bit Kevin Darcy writes: > Section-based extensibility *is* part of the protocol Section-based extensibility is _not_ part of the existing AXFR protocol. In particular, the requirement that clients ignore AU records and AR records is _not_ part of the existing AXFR protocol. It is new in the axfr-clarify document. It is not compatible with the installed base. > If your client croaks on unexpected RR's in Authority or Additional of > an AXFR response, it's broken. My AXFR client doesn't look for sections. It treats all records as part of the zone. It works just fine. It is in full compliance with the required DNS standards. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jul 6 07:22:02 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27025 for ; Fri, 6 Jul 2001 07:22:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15ITM2-000LiJ-00 for namedroppers-data@psg.com; Fri, 06 Jul 2001 04:00:58 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15ITM1-000LiD-00 for namedroppers@ops.ietf.org; Fri, 06 Jul 2001 04:00:57 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15ITM1-00029Z-00 for namedroppers@ops.ietf.org; Fri, 06 Jul 2001 04:00:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC AXFR-02 SHORT last call References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Fri, 06 Jul 2001 04:00:58 -0700 Content-Transfer-Encoding: 7bit Andreas Gustafsson writes: > IDs and RCODEs are checked in all other contexts of the DNS protocol, > and I don't think it was the intent of RFC1034/1035 to make AXFR an > exception. I think it would help if you read the DNS specifications. ID checking and RCODE checking are explicitly given as part of the recommended resolution algorithm in RFC 1034 section 5.3.3. They are not part of the zone-transfer protocol in section 4.3.5. Zone-transfer clients are not resolvers. The principle that they should follow resolver rules is a figment of your imagination. > RFC1034 says the records in the parent "should" (not "must") be > exactly the same as those in the child. RFC 1034 also says that a node with a CNAME record ``should'' have no other data, and that in the last step of delegation one ``should'' add NS records to the parent zone, and that lame delegations ``should'' be ignored, and that it is essential that temporary errors ``should not'' be signalled as permanent errors. > I have no idea what you are talking about here. I've been told, by a source I believe, that some recent versions of BIND reject zones of the type I described as containing ``non-glue records.'' Please investigate, and then explain the facts to us. > The requirement to send a response is already implicit in the nature > of the DNS protocol as a query-response protocol. Nonsense. Unauthorized clients do not have any right to a response. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jul 6 07:22:03 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27024 for ; Fri, 6 Jul 2001 07:22:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15ITLj-000Li5-00 for namedroppers-data@psg.com; Fri, 06 Jul 2001 04:00:39 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15ITLi-000Lhy-00 for namedroppers@ops.ietf.org; Fri, 06 Jul 2001 04:00:38 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15ITLi-00028Z-00 for namedroppers@ops.ietf.org; Fri, 06 Jul 2001 04:00:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: AXFR security issues, again References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Fri, 06 Jul 2001 04:00:39 -0700 Content-Transfer-Encoding: 7bit Andreas Gustafsson writes: > No. What is essential is that the server does not send the > dns-01.ns.aol.com glue as part of referrals out of any zone other > than princeton.edu. No, that's not enough. It would help if you read the examples of poison in http://cr.yp.to/djbdns/notes.html. Let's say I'm a .com server, and I receive the records money.microsoft.com NS dns-01.ns.aol.com money.microsoft.com NS dns-02.ns.aol.com dns-01.ns.aol.com A 207.46.230.218 dns-02.ns.aol.com A 207.46.230.218 from a microsoft.com AXFR server. Suppose I follow your bogus model and keep these records in the microsoft.com zone for referrals out of the microsoft.com zone. A cache asks me about www.aol.com, and I provide the records aol.com NS dns-01.ns.aol.com aol.com NS dns-02.ns.aol.com dns-01.ns.aol.com A 152.163.159.232 dns-02.ns.aol.com A 205.188.157.232 from the .com zone. The cache saves these records, because it trusts .com servers to provide *.com information. The cache then asks the AOL servers about www.aol.com, but those servers happen to be down. Later the cache asks me about foobar.money.microsoft.com, and I provide the records money.microsoft.com NS dns-01.ns.aol.com money.microsoft.com NS dns-02.ns.aol.com dns-01.ns.aol.com A 207.46.230.218 dns-02.ns.aol.com A 207.46.230.218 following your bogus model. The cache saves these records, overwriting the previous dns-01.ns.aol.com and dns-02.ns.aol.com information. Later the cache asks 207.46.230.218 for information about www.aol.com. It is, as I said, essential for the .com server to discard the aol.com information from the microsoft.com AXFR servers. ---Dan P.S. Is BIND 9 vulnerable to this attack? Or does it discard the aol.com information, destroying the ``identity'' of the zone? to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jul 6 08:08:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA28443 for ; Fri, 6 Jul 2001 08:08:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15IUCX-000NWH-00 for namedroppers-data@psg.com; Fri, 06 Jul 2001 04:55:13 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15IUCW-000NWB-00 for namedroppers@ops.ietf.org; Fri, 06 Jul 2001 04:55:12 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15IUCW-0004k0-00 for namedroppers@ops.ietf.org; Fri, 06 Jul 2001 04:55:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: gson@nominum.com (Andreas Gustafsson) cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC AXFR-02 SHORT last call In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Fri, 06 Jul 2001 04:55:13 -0700 Content-Transfer-Encoding: 7bit Date: Thu, 05 Jul 2001 20:48:55 -0700 From: gson@nominum.com (Andreas Gustafsson) Message-ID: | RFC1034 says the records in the parent "should" (not "must") be | exactly the same as those in the child. First - be very careful in interpreting the wording of any RFC more than a few years old (say anything much older than 2119). 1034 even predates 1122/1123 which were where the MUST/SHOULD stuff was introduced - though it was being developed at the same approximate time as host requirements was. But back then, the MUST stuff in docs was quite new, and was being kept for the docs that really need it (which is, ones that actually set out to specify protocol conformance, rather than just specify protocols). That an old doc doesn't use the word "must" doesn't necessarily mean anything at all about what is actually required. You have to actually read what is saying, and understand why to be able to deduce that in most cases. | This is an operational recommendation, not a protocol requirement, It is actually a DNS database requirement - there is supposed to be a single set of data, and clients should always get the same answers, no matter who they ask. Because of the lack of protocol support (probably for good reason) enforcing this turns into an operational matter - but it isn't just for operational convenience that the data is supposed to be the same. | and in practice, discrepancies are extremely common and must be dealt | with by the protocol. Yes, the DNS does plan for outdated data, and this one in particular is one of the worst examples of that, as it generally requires some form of human intervention to cause the servers to become reconciled (someone has to ask the parent to update its delegation). The protocol does need to deal with that, and generally it does. I certainly agree that when a zone transfer is attempted, it should not matter what other zones the server of the AXFR happens to be authoritative for (much less what other RRs it might happen to have in its cache). That BIND managed to ignore this requirement for almost ever (until BIND9) has been a long standing acknowledged bug in BIND. But if it hadn't been for that bug, I doubt that anyone would seriously be suggesting otherwise. This is just another example of returning the same answers, any two servers for the same zone, holding the same copy of the that zone (equal serial numbers) should return the same answers when data is extracted from that zone to be used in a reply - whether that's a reply to a query for an A, or a reply to an AXFR request. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jul 6 18:44:55 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22525 for ; Fri, 6 Jul 2001 18:44:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Ie0n-000H8P-00 for namedroppers-data@psg.com; Fri, 06 Jul 2001 15:23:45 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15Ie0m-000H8J-00 for namedroppers@ops.ietf.org; Fri, 06 Jul 2001 15:23:44 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15Ie0m-0002GN-00 for namedroppers@ops.ietf.org; Fri, 06 Jul 2001 15:23:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Kevin Darcy To: namedroppers@ops.ietf.org Subject: Re: RFC 2119 section 6 References: X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.8 sun4u) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Fri, 06 Jul 2001 15:23:45 -0700 Content-Transfer-Encoding: 7bit D. J. Bernstein wrote: > Kevin Darcy writes: > > Section-based extensibility *is* part of the protocol > > Section-based extensibility is _not_ part of the existing AXFR protocol. Why are you referring to AXFR as a separate protocol? By your own logic, if it were a separate protocol, it would run on a separate port number. It doesn't, ergo it's not a separate protocol. It's *part* of the overall DNS protocol, and thus inherits the rules and the assumptions of DNS generally, except where explicitly overridden. > In particular, the requirement that clients ignore AU records and AR > records is _not_ part of the existing AXFR protocol. It is new in the > axfr-clarify document. It is not compatible with the installed base. RFC 1034 just said that the messages of a zone transfer "carry all of the [...] RRs from the zone". Now, where does a DNS client (let's not split hairs again over whether an AXFR client is a DNS client or not) normally look for answers to its question, assuming that the question *was* in fact answered, as opposed to referred, refused or whatever? In the Answer Section of course! So it's a perfectly reasonable assumption -- and a perfectly reasonable interpretation of the original, unclear specification of AXFR -- that the RR's of the zone will be in the Answer Section, and as far as I know all implementations except yours are based on this assumption. This clarify draft simply does what it is supposed to in this instance -- it _clarifies_ the original specification/interpretation. Now, logically, if all of the RR's of the zone being transferred belong in the Answer Section, then it makes no sense for them to appear in other sections, since the other sections serve purposes besides simply answering a client's question. Assuming that all RR's in an AXFR response are data for the zone, regardless of section, would be like assuming that *everything* you get from a grocery store is edible or drinkable (including the glass and/or plastic packaging and/or containers)or that every part on a DaimlerChrysler automobile had been safety-tested and was designed to last more than a few months (just kidding about that second simile :-). Function often depends on context, and DNS section distinctions are contextual. An RR in the Answer Section answers the question asked. A RR in some other section serves some other purpose, so in an AXFR transaction, where the question was, basically,"what are the contents of the zone?" it shouldn't be considered part of the zone data. So any RR's appearing in other sections should be ignored by an AXFR client, unless that client happens to know about specific extensions which use those particular RR's in Authority or Additional, e.g. TSIG or EDNS0. The language "ignore any unexpected RR's" captures this concept quite succinctly I think. This facilitates the development of future extensions, which a given client may "expect" or not, depending on its age and/or level of standards-conformance, and shouldn't be inhibited by your wish/desire to be completely "section-agnostic" in your AXFR client. To take another tack: Dan, how do you propose that extensions to AXFR -- including generic extensions to DNS that might coincidentally be applied to AXFR responses -- be reliably implemented *without* making AXFR into a totally separate protocol, running on a different port and *without* a guarantee that clients will ignore unexpected RR's in sections other than the Answer Section? If I propose a FOOBAR extension tomorrow, which puts a new type of RR in the Additional Sections of, among other responses, AXFR responses, is your client going to foolishly think that new record is part of the zone? For that matter, does your client today think that TSIG or OPT records are part of the zone being transferred? If you treat all of the sections of an AXFR response, collectively, as a data container, you leave almost *no* room for incremental extensibility of the DNS protocol as it may apply to AXFR responses (do you perchance think all of those potential extensions can fit in the unused bits of the header?). Given your overall views on the usefulness of AXFR (or perceived lack of it), I'm not surprised that you would try to stifle its (co-)evolution, but surely you can't expect the rest of the DNS community to acquiesce to such Luddism. - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jul 7 01:48:10 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA02629 for ; Sat, 7 Jul 2001 01:48:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Ikad-0003j0-00 for namedroppers-data@psg.com; Fri, 06 Jul 2001 22:25:11 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15Ikac-0003iu-00 for namedroppers@ops.ietf.org; Fri, 06 Jul 2001 22:25:10 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15Ikac-000MRi-00 for namedroppers@ops.ietf.org; Fri, 06 Jul 2001 22:25:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: RFC 2119 section 6 References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Fri, 06 Jul 2001 22:25:11 -0700 Content-Transfer-Encoding: 7bit Kevin Darcy writes: > it's a perfectly reasonable assumption -- and a perfectly reasonable > interpretation of the original, unclear specification of AXFR -- that > the RR's of the zone will be in the Answer Section I agree. There's no dispute about this. AXFR _servers_ have to put all the records into the answer section. Any server that violates this rule will have interoperability problems with some AXFR clients. Now, given a stream of DNS messages, with empty authority and additional sections, how does the AXFR _client_ extract all the records? There are several methods that work. I'm using one. BIND uses another. The choice of method has no effect on interoperability. axfr-clarify is violating RFC 2119 section 6 by requiring a particular parsing method. > If I propose a FOOBAR extension tomorrow, which puts a new type of RR > in the Additional Sections of, among other responses, AXFR responses, Then you are an idiot. You are pointlessly breaking compatibility with working AXFR clients deployed at thousands of sites. Put your protocol on a new port, and stop demanding that I pay attention to it. > (let's not split hairs again over > whether an AXFR client is a DNS client or not) Zone transfers are requested by name servers. The zone-transfer protocol is described in RFC 1034 section 4: ``NAME SERVERS.'' Resolution is requested by caches (``resolvers''). The resolution protocol is described in RFC 1034 section 5: ``RESOLVERS.'' See RFC 1035, page 6, for a data-flow diagram showing the different roles of caches and name servers. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 9 03:19:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA06876 for ; Mon, 9 Jul 2001 03:19:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15JUoX-000KXK-00 for namedroppers-data@psg.com; Sun, 08 Jul 2001 23:46:37 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15JUoW-000KXA-00 for namedroppers@ops.ietf.org; Sun, 08 Jul 2001 23:46:36 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15JUoW-0009Uw-00 for namedroppers@ops.ietf.org; Sun, 08 Jul 2001 23:46:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: namedroppers@ops.ietf.org Subject: list policy Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sun, 08 Jul 2001 23:46:37 -0700 Content-Transfer-Encoding: 7bit namedroppers@ops.ietf.org is the mailing list for the ietf dnsext wg. see for the wg charter. messages should be on topics appropriate to the dnsext wg, which are various discussion of the dns protocols or administrivia of the wg itself. the list is moderated. calls for papers, announcements of events not directly relevant to the dns protocols, etc. are not appropriate. discussion of problems with particular implementations, announcements of releases, sites' misconfigurations, etc. should be done on mailing lists for the particular implementations. there is a wg for dns operational practice, dnsop, whose charter can be found at . there is a mailing list for discussion of whose implementation is better, and why someone else's is broken. it is weenie-war@ops.ietf.org. all discussions of such nature should occur there or on /dev/null. unlike the namedroppers list, weenie-war@ops.ietf.org is not archived. discussion of this policy is a topic for the poisson wg. poisson's charter can be found at . --- 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. From owner-namedroppers@ops.ietf.org Mon Jul 9 12:06:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19811 for ; Mon, 9 Jul 2001 12:06:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15JdBZ-000AUl-00 for namedroppers-data@psg.com; Mon, 09 Jul 2001 08:42:57 -0700 Received: from [147.28.4.2] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15JdBW-000AUe-00 for namedroppers@ops.ietf.org; Mon, 09 Jul 2001 08:42:55 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15JdBU-000G7R-00 for namedroppers@ops.ietf.org; Mon, 09 Jul 2001 08:42:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "Eric A. Hall" To: Christian Huitema , namedroppers@ops.ietf.org Subject: Re: RFC 2782: SRV naming convention References: X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 09 Jul 2001 08:42:57 -0700 Content-Transfer-Encoding: 7bit Christian Huitema wrote: > > > How about "_smtp._http.example.com"? (Mail tunnelled over http) > Another extension that has been suggested is to take account some form > of locality, as in "I am in subnet number X, in domain example.com, and > I want to find an LDAP server; which is the most appropriate one?" Couple of ways to do this that I can see. The most obvious is to use subdomains within the org, so that users in the ny.corp.example.com zone always get the right SRV RR. A more-dynamic but also more-difficult method would be to tie SRV RRs to IN-ADDR.ARPA zones, such that _smtp._tcp.0.1.192.168.in-addr.arpa. has different data than the _smtp._tcp.0.2.192.168.in-addr.arpa. zone. This would require that [a] clients know their subnet mask, [b] that the resolver is able to find the container in-addr.arpa. zone for their subnet (using classless delegation lookups, and then sticking the SRV query labels onto that), and [c] that the applications were configured to perform adddress-based lookups. But it is doable in a highly-managed environment. > -- Christian Huitema=20 -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 9 16:10:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA27613 for ; Mon, 9 Jul 2001 16:10:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15JgzQ-000GxJ-00 for namedroppers-data@psg.com; Mon, 09 Jul 2001 12:46:40 -0700 Received: from mpfg.attlabs.net ([12.106.35.2] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15JgzO-000Gx6-00 for namedroppers@ops.ietf.org; Mon, 09 Jul 2001 12:46:38 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Jgyj-000GB2-00 for namedroppers@ops.ietf.org; Mon, 09 Jul 2001 12:45:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "Eric A. Hall" To: Christian Huitema CC: namedroppers@ops.ietf.org Subject: Re: RFC 2782: SRV naming convention References: X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 09 Jul 2001 12:46:40 -0700 Content-Transfer-Encoding: 7bit Christian Huitema wrote: > Something like that might limitations of the SRV format perceived by > several WG -- notably SIP and IMPP. The problem occurs when a service > can run on several protocols. For example, SIP can run over UDP, TCP > and possibly SCTP or TLS; IMPP services can be provided through SIMPLE, > APEX, PRIM and possibly others. How can we discover not just a server > name and a port, but also a transport protocol and possibly an > application protocol? PTR records? Q: _sip.example.com. A: PTR _sip._tcp.example.com. A: PTR _sip._udp.example.com. > If a given client only supports some of the options, how do we > restrict the discovery to the server that support common options? Given that this is application-specific functionality, it would seem to be outside the scope of the DNS locator service. You'd have to use SrvLoc I would think. But, one possible solution would be to have the client walk through the weighted list of responses until it finds one that it is willing to work with. Or you could combine the above technique with other techniques (like in-addr.arpa. matching) to hone in on the right server for the specific client. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 10 10:02:08 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29629 for ; Tue, 10 Jul 2001 10:02:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15JxhS-000Kro-00 for namedroppers-data@psg.com; Tue, 10 Jul 2001 06:37:14 -0700 Received: from mpfg.attlabs.net ([12.106.35.2] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15JxhR-000Kq3-00 for namedroppers@ops.ietf.org; Tue, 10 Jul 2001 06:37:13 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Jxgz-000Gkk-00 for namedroppers@ops.ietf.org; Tue, 10 Jul 2001 06:36:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Kevin Darcy To: namedroppers@ops.ietf.org Subject: Re: RFC 2119 section 6 References: X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.8 sun4u) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 10 Jul 2001 06:37:14 -0700 Content-Transfer-Encoding: 7bit Look, Dan, if AXFR clients are going to be a special case to the general rule that DNS clients only look for direct answers to their question, when definitively answered, in the Answer Section, then surely it makes more sense to declare AXFR a separate protocol, with a separate port assignment, than to declare every incremental extension to DNS, present and future, which might happen to put RR's in the non-Answer sections of AXFR responses, a separate protocol requiring a separate port assignment. Why should the many suffer for the sake of the one? Yet I don't see you pushing for AXFR to use a different port number. TSIG and EDNS0 are already with us, and as far as I know it is legal for either or both to be transmitted in an AXFR response; are you seriously suggesting that we already need 2 new port assignments, with more to be obtained as new extensions are adopted? That's madness. It's obviously not scalable for all nameservers to have to listen on a new port every time another protocol extension comes down the pike. And do you really want to make a living hell for firewall administrators who have to change the rulesets on all of their boxes every time a new port is defined for general use? The "ignore unexpected RR's" language of the clarify draft allows these incremental extensions to reliably co-exist with AXFR without drastic measures like forking off new port assignments. The only thing that is lost is the opportunity for an AXFR client to be "section-agnostic", but you have IMO fallen far short of demonstrating that "section-agnosticism" has any practical value, let alone that its preservation is worth stunting the evolution of extensions to the DNS protocol if and whereever those extensions may coincidentally apply to AXFR responses. Between the two types of interoperability under inspection here -- interoperability between AXFR and protocol extensions, on the one hand, and interoperability between non-standards-conforming servers and "section-agnostic"-wannabe clients, on the other -- the type of interoperability which facilitates long-term growth and evolution should be preferred. - Kevin D. J. Bernstein wrote: > Kevin Darcy writes: > > it's a perfectly reasonable assumption -- and a perfectly reasonable > > interpretation of the original, unclear specification of AXFR -- that > > the RR's of the zone will be in the Answer Section > > I agree. There's no dispute about this. AXFR _servers_ have to put all > the records into the answer section. Any server that violates this rule > will have interoperability problems with some AXFR clients. > > Now, given a stream of DNS messages, with empty authority and additional > sections, how does the AXFR _client_ extract all the records? > > There are several methods that work. I'm using one. BIND uses another. > The choice of method has no effect on interoperability. axfr-clarify is > violating RFC 2119 section 6 by requiring a particular parsing method. > > > If I propose a FOOBAR extension tomorrow, which puts a new type of RR > > in the Additional Sections of, among other responses, AXFR responses, > > Then you are an idiot. You are pointlessly breaking compatibility with > working AXFR clients deployed at thousands of sites. Put your protocol > on a new port, and stop demanding that I pay attention to it. > > > (let's not split hairs again over > > whether an AXFR client is a DNS client or not) > > Zone transfers are requested by name servers. The zone-transfer protocol > is described in RFC 1034 section 4: ``NAME SERVERS.'' > > Resolution is requested by caches (``resolvers''). The resolution > protocol is described in RFC 1034 section 5: ``RESOLVERS.'' > > See RFC 1035, page 6, for a data-flow diagram showing the different > roles of caches and name servers. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 10 10:54:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02098 for ; Tue, 10 Jul 2001 10:54:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Jyd4-000Mou-00 for namedroppers-data@psg.com; Tue, 10 Jul 2001 07:36:46 -0700 Received: from mpfg.attlabs.net ([12.106.35.2] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15Jyd3-000Moc-00 for namedroppers@ops.ietf.org; Tue, 10 Jul 2001 07:36:45 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15JycU-000GnP-00 for namedroppers@ops.ietf.org; Tue, 10 Jul 2001 07:36:10 -0700 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org Subject: I-D ACTION:draft-ietf-dnsext-mdns-01.txt Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 10 Jul 2001 07:36:46 -0700 --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 : Multicast DNS Author(s) : L. Esibov, B. Aboba, D. Thaler Filename : draft-ietf-dnsext-mdns-01.txt Pages : 15 Date : 09-Jul-01 Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a DNS server. In order to allow DNS name resolution in such environments, the use of a multicast DNS is proposed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-mdns-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-mdns-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: <20010709103356.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010709103356.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 10 11:24:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03551 for ; Tue, 10 Jul 2001 11:24:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15JzCA-000ONy-00 for namedroppers-data@psg.com; Tue, 10 Jul 2001 08:13:02 -0700 Received: from mpfg.attlabs.net ([12.106.35.2] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15JzC9-000OM5-00 for namedroppers@ops.ietf.org; Tue, 10 Jul 2001 08:13:01 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15JzBZ-000Gop-00 for namedroppers@ops.ietf.org; Tue, 10 Jul 2001 08:12:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "Eric A. Hall" CC: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-mdns-01.txt References: <200107101424.KAA00219@ietf.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 10 Jul 2001 08:13:02 -0700 Content-Transfer-Encoding: 7bit > Title : Multicast DNS > Today, with the rise of home networking, there are an increasing > number of ad-hoc networks operating without a DNS server. In order > to allow DNS name resolution in such environments, the use of a > multicast DNS is proposed. Since this protocol is for local-only environments rather than being a generic "multicast DNS" which can be used in any environment, and since there is the potential at some point for the latter to be developed and deployed, I would like to request that the document and protocol labels be changed to something that more accurately reflects their scope and usage models. This may seem like a minor nit but this exact same issue has come up before with other "multicast" protocols which weren't, and it causes a great deal of confusion that is easily avoided. Thanks -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 10 17:28:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25401 for ; Tue, 10 Jul 2001 17:28:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15K4mK-000AbD-00 for namedroppers-data@psg.com; Tue, 10 Jul 2001 14:10:44 -0700 Received: from mpfg.attlabs.net ([12.106.35.2] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15K4mI-000Aa4-00 for namedroppers@ops.ietf.org; Tue, 10 Jul 2001 14:10:42 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15K4ln-000H1d-00 for namedroppers@ops.ietf.org; Tue, 10 Jul 2001 14:10:11 -0700 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org To: IETF-Announce: ; CC: namedroppers@ops.ietf.org Subject: I-D ACTION:draft-kamite-dnsext-tkey-secret-renewal-00.txt Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 10 Jul 2001 14:10:44 -0700 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : TKEY Secret Key Renewal Mode Author(s) : Y. Kamite, M. Nakayama Filename : draft-kamite-dnsext-tkey-secret-renewal-00.txt Pages : 12 Date : 09-Jul-01 TKEY [RFC2930] provides methods of setting up shared secret keys for TSIG [RFC2845] other than manual exchange. But TKEY itself cannot control timing of key renewal very well though it can add or delete shared keys. Since continuing to sign messages with old keys permanently is not safe, hosts which make use of TSIG should pay attention to the time limit of secret usage. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kamite-dnsext-tkey-secret-renewal-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-kamite-dnsext-tkey-secret-renewal-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-kamite-dnsext-tkey-secret-renewal-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: <20010709113708.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kamite-dnsext-tkey-secret-renewal-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-kamite-dnsext-tkey-secret-renewal-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010709113708.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 10 21:28:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA02718 for ; Tue, 10 Jul 2001 21:28:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15K8Yt-000IXm-00 for namedroppers-data@psg.com; Tue, 10 Jul 2001 18:13:07 -0700 Received: from mpfg.attlabs.net ([12.106.35.2] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15K8Ys-000IWP-00 for namedroppers@ops.ietf.org; Tue, 10 Jul 2001 18:13:06 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15K8YT-000H9q-00 for namedroppers@ops.ietf.org; Tue, 10 Jul 2001 18:12:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: RFC 2119 section 6 References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 10 Jul 2001 18:13:07 -0700 Content-Transfer-Encoding: 7bit Kevin Darcy writes: > TSIG and EDNS0 are already with us, and as far as I know it is legal > for either or both to be transmitted in an AXFR response Only by bilateral agreement. > are you seriously suggesting that we already need 2 new port > assignments, with more to be obtained as new extensions are adopted? Of course not. You could easily squeeze the entire OSI protocol suite into a protocol running on a single TCP port. You have to be careful, however, if you want to use port 25, or port 80, or port 53. You have to maintain compatibility with the installed base. That's why protocol designers often use new ports. Terrified of new ports? Fine. Use a new EXFR query type. This is not rocket science. > you have IMO fallen far short of demonstrating that > "section-agnosticism" has any practical value I have thousands of sites whose adminitsrators don't want to be forced to upgrade their working DNS software. If you don't think compatibility has ``practical value,'' you're an idiot. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 11 03:40:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA27282 for ; Wed, 11 Jul 2001 03:40:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15KEI2-0003Cy-00 for namedroppers-data@psg.com; Wed, 11 Jul 2001 00:20:06 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15KEI1-0003Cq-00 for namedroppers@ops.ietf.org; Wed, 11 Jul 2001 00:20:05 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15KEI1-000Ifz-00 for namedroppers@ops.ietf.org; Wed, 11 Jul 2001 00:20:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: "D. J. Bernstein" cc: namedroppers@ops.ietf.org Subject: Re: RFC 2119 section 6 In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 11 Jul 2001 00:20:06 -0700 Content-Transfer-Encoding: 7bit Date: Tue, 10 Jul 2001 18:13:07 -0700 From: "D. J. Bernstein" Message-ID: | I have thousands of sites whose adminitsrators don't want to be forced | to upgrade their working DNS software. This is a nonsense argument - before anyone would possibly be required to upgrade their working software because of changes to AXFR that put something different in the auth/additional sections than what is in the answer section, all those administrators are going to have upgraded their software for other reasons anyway (and not necessarily all for the same one). What's more, even if a few haven't, it would only matter if their peer axfr servers actually use whatever new might eventually get defined. All that is needed now, or anytime in the forseeable future, is that you add the one line of code it takes to stop processing at the end of the answer section, instead of at the end of the packet, and include that in the distribution. You don't have to suggest to anyone that they upgrade, just make a version that works this way available. Then, long before it is ever going to matter, the thousands of sites are going to be 10's of sites, at most. And most of then may never notice. And this is all *if* anything is ever defined to use the other sections. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 11 03:42:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA27315 for ; Wed, 11 Jul 2001 03:42:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15KEIu-0003DN-00 for namedroppers-data@psg.com; Wed, 11 Jul 2001 00:21:00 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15KEIt-0003DH-00 for namedroppers@ops.ietf.org; Wed, 11 Jul 2001 00:20:59 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15KEIt-000Ihf-00 for namedroppers@ops.ietf.org; Wed, 11 Jul 2001 00:20:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Kevin Darcy To: namedroppers@ops.ietf.org Subject: Re: RFC 2119 section 6 References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 11 Jul 2001 00:21:00 -0700 Content-Transfer-Encoding: 7bit D. J. Bernstein wrote: > Kevin Darcy writes: > > TSIG and EDNS0 are already with us, and as far as I know it is legal > > for either or both to be transmitted in an AXFR response > > Only by bilateral agreement. We've already stipulated that AXFR servers shouldn't be sending zone data outside of the Answer Section, so this whole issue is moot if every server could be trusted to do The Right Thing all of the time. But if we want AXFR clients to be robust and deal reasonably with a server that does The Wrong Thing, however, then we have to deal with unagreed-upon OPT or TSIG records as well as non-Answer-Section zone data. The clarify draft says "ignore the RRs". You seem to be challenging that and saying instead "no, treat them as zone data". Which means if you get a wayward OPT or TSIG record, your client presumably will mistake that for zone data, whereas most other clients will just ignore them if they don't recognize them or there is no bilateral agreement to use them. This is an interoperability problem. The same records are being treated differently depending on the idiosyncrasy of the implementor. This is _exactly_ the kind of thing that a clarify draft is meant to clear up. And when a protocol is clarified, it's certainly not unusual for software which made the "wrong" assumption (even if it didn't seem "wrong" at the time, because the specification was unclear) to have to change to conform to the clarified standard. > > are you seriously suggesting that we already need 2 new port > > assignments, with more to be obtained as new extensions are adopted? > > Of course not. You could easily squeeze the entire OSI protocol suite > into a protocol running on a single TCP port. > > You have to be careful, however, if you want to use port 25, or port 80, > or port 53. You have to maintain compatibility with the installed base. > That's why protocol designers often use new ports. Or they use otherwise-unused sections of a response... > Terrified of new ports? Fine. Use a new EXFR query type. This is not > rocket science. Oh, great. So now we're defining new query types for every extension, whether it functionally needs it or not. Or, should I say, every *combination* of extensions (one for TSIG only, one for EDNS0 only, one for EDNS0+TSIG, etc.)? We'll chew up the QTYPE range pretty quickly that way... > > you have IMO fallen far short of demonstrating that > > "section-agnosticism" has any practical value > > I have thousands of sites whose adminitsrators don't want to be forced > to upgrade their working DNS software. If you don't think compatibility > has ``practical value,'' you're an idiot. And if you think protocol-implementing software can be immutable, even in the face of protocol clarifications and extensions, then you're... well... I've sworn off name-calling so I'll abstain. Suffice it to say, speaking as an administrator, I view claims about "software that will never need to be upgraded" with about as much skepticism as claims about perpetual-motion machines. - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 11 03:46:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA27431 for ; Wed, 11 Jul 2001 03:46:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15KEJy-0003Ep-00 for namedroppers-data@psg.com; Wed, 11 Jul 2001 00:22:06 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15KEJx-0003Ed-00 for namedroppers@ops.ietf.org; Wed, 11 Jul 2001 00:22:05 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15KEJx-000IjX-00 for namedroppers@ops.ietf.org; Wed, 11 Jul 2001 00:22:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Brian Wellington To: "D. J. Bernstein" Cc: Subject: Re: RFC 2119 section 6 In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 11 Jul 2001 00:22:06 -0700 Content-Transfer-Encoding: 7bit On Tue, 10 Jul 2001, D. J. Bernstein wrote: > Kevin Darcy writes: > > TSIG and EDNS0 are already with us, and as far as I know it is legal > > for either or both to be transmitted in an AXFR response > > Only by bilateral agreement. A TKEY can spontaneously be added to a response. See RFC 2930, section 5. I don't think this is a good idea, but it is a spec. It says This SHOULD only be done if the server knows the querier understands TKEY and has this option implemented but that doesn't prevent a server from doing it in other cases. It would be completely legal for a server to implement this, and it would cause your AXFR client to import a TKEY record into the zone. > Terrified of new ports? Fine. Use a new EXFR query type. This is not > rocket science. Which, for every DNS implementation except yours, would be identical to AXFR. > > you have IMO fallen far short of demonstrating that > > "section-agnosticism" has any practical value > > I have thousands of sites whose adminitsrators don't want to be forced > to upgrade their working DNS software. If you don't think compatibility > has ``practical value,'' you're an idiot. No one's forcing users to do anything. This is a fairly minor point, and even if your client is non-compliant, it has virtually no interoperability issues. I wouldn't go out of my way to update sites that I administered just because of this. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 11 11:48:07 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08557 for ; Wed, 11 Jul 2001 11:48:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15KLoi-0008wA-00 for namedroppers-data@psg.com; Wed, 11 Jul 2001 08:22:20 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15KLof-0008w4-00 for namedroppers@ops.ietf.org; Wed, 11 Jul 2001 08:22:17 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15KLof-0005IS-00 for namedroppers@ops.ietf.org; Wed, 11 Jul 2001 08:22:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Andreas Borchert To: namedroppers@ops.ietf.org Subject: Re: RFC 2119 section 6 In-Reply-To: ; from kre@munnari.OZ.AU on Wed, Jul 11, 2001 at 12:20:06AM -0700 References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 11 Jul 2001 08:22:20 -0700 Content-Transfer-Encoding: 7bit On Wed, Jul 11, 2001 at 12:20:06AM -0700, Robert Elz wrote: > Date: Tue, 10 Jul 2001 18:13:07 -0700 > From: "D. J. Bernstein" > Message-ID: > > | I have thousands of sites whose adminitsrators don't want to be forced > | to upgrade their working DNS software. > > This is a nonsense argument - before anyone would possibly be required > to upgrade their working software because of changes to AXFR that put > something different in the auth/additional sections than what is in > the answer section, all those administrators are going to have upgraded > their software for other reasons anyway (and not necessarily all for the > same one). This argument is not nonsense for administrators using djbdns and other software packages from the same author. Dan designes his software packages to be minimal, fast, and secure which allows him to keep them stable for a long time. Qmail, for example, did not change for multiple years. For this reason, many users of Dan's packages prefer them because they remain secure and stable for a long time. Running Qmail and djbdns means that you do not have to look for new security holes and you can keep them running unchanged for many years. This advantage is destroyed once protocols are changed in an incompatible way. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 11 11:57:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08913 for ; Wed, 11 Jul 2001 11:57:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15KM60-0009Fd-00 for namedroppers-data@psg.com; Wed, 11 Jul 2001 08:40:12 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15KM60-0009FT-00 for namedroppers@ops.ietf.org; Wed, 11 Jul 2001 08:40:12 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15KM60-0005n4-00 for namedroppers@ops.ietf.org; Wed, 11 Jul 2001 08:40:12 -0700 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org Subject: I-D ACTION:draft-ietf-dnsext-rfc2536bis-dsa-00.txt Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 11 Jul 2001 08:40:12 -0700 --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 : DSA KEYs and SIGs in the Domain Name System (DNS) Author(s) : D. Eastlake Filename : draft-ietf-dnsext-rfc2536bis-dsa-00.txt Pages : 7 Date : 10-Jul-01 A standard method for storing US Government Digital Signature Algorithm keys and signatures in the Domain Name System is described which utilizes DNS KEY and SIG resource records. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2536bis-dsa-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-rfc2536bis-dsa-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-rfc2536bis-dsa-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: <20010710153818.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-rfc2536bis-dsa-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-rfc2536bis-dsa-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010710153818.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 11 11:59:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08993 for ; Wed, 11 Jul 2001 11:59:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15KM66-0009Fu-00 for namedroppers-data@psg.com; Wed, 11 Jul 2001 08:40:18 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15KM66-0009Fo-00 for namedroppers@ops.ietf.org; Wed, 11 Jul 2001 08:40:18 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15KM66-0005nN-00 for namedroppers@ops.ietf.org; Wed, 11 Jul 2001 08:40:18 -0700 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, dnsop@cafax.se Subject: I-D ACTION:draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 11 Jul 2001 08:40:18 -0700 --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 : Tradeoffs in DNS support for IPv6 Author(s) : R. Austein Filename : draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt Pages : 10 Date : 10-Jul-01 The IETF has two different proposals on the table for how to do DNS support for IPv6, and has thus far failed to reach a clear consensus on which approach is better. This note attempts to examine the pros and cons of each approach, in the hope of clarifying the debate so that we can reach closure and move on. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-ipv6-dns-tradeoffs-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: <20010710153838.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010710153838.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 11 12:00:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09062 for ; Wed, 11 Jul 2001 12:00:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15KM63-0009Fm-00 for namedroppers-data@psg.com; Wed, 11 Jul 2001 08:40:15 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15KM63-0009Fg-00 for namedroppers@ops.ietf.org; Wed, 11 Jul 2001 08:40:15 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15KM63-0005nF-00 for namedroppers@ops.ietf.org; Wed, 11 Jul 2001 08:40:15 -0700 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org Subject: I-D ACTION:draft-ietf-dnsext-rfc2539bis-dhk-00.txt Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 11 Jul 2001 08:40:15 -0700 --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 : Storage of Diffie-Hellman Keys in the Domain Name System (DNS) Author(s) : D. Eastlake Filename : draft-ietf-dnsext-rfc2539bis-dhk-00.txt Pages : 9 Date : 10-Jul-01 A standard method for storing Diffie-Hellman keys in the Domain Name System is described which utilizes DNS KEY resource records. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2539bis-dhk-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-rfc2539bis-dhk-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-rfc2539bis-dhk-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: <20010710153829.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-rfc2539bis-dhk-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-rfc2539bis-dhk-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010710153829.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 11 17:40:07 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21404 for ; Wed, 11 Jul 2001 17:40:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15KRIb-000B7T-00 for namedroppers-data@psg.com; Wed, 11 Jul 2001 14:13:33 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15KRIZ-000B72-00 for namedroppers@ops.ietf.org; Wed, 11 Jul 2001 14:13:31 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15KRIZ-000O7T-00 for namedroppers@ops.ietf.org; Wed, 11 Jul 2001 14:13:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Edward Lewis To: namedroppers@ops.ietf.org Cc: lewis@tislabs.com Subject: comment from "Tradeoffs" applied to "Delegation Signer" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 11 Jul 2001 14:13:33 -0700 Content-Transfer-Encoding: 7bit These two documents are independent, but I'd like to use words from one to comment on the other. In Olafur's Delegation Signer: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-delegation-signer-00.txt >1.1 - Delegation Signer Record model >... > The main disadvantage of this approach is to double the number of > signatures that need to be verified for the each KEY set. The > advantage on the other hand is that child only needs to update data in > parent when it changes DNS signing key. And from Rob's Tradeoffs: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt >Potential problems with A6 > > ..., but in general, we expect the DNS data to be read > more frequently than it is written, so we need to evaluate this > particular tradeoff very carefully. My main concern regarding the delegation signer is that it is "optimizing for write" in a system when where reading is much more common. BTW, I like the Tradeoffs draft - good synopsis of that debate to date. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com You fly too often when ... the airport taxi is on speed-dial. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jul 12 00:43:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA05192 for ; Thu, 12 Jul 2001 00:43:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15KY3J-0006OT-00 for namedroppers-data@psg.com; Wed, 11 Jul 2001 21:26:13 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15KY3I-0006ON-00 for namedroppers@ops.ietf.org; Wed, 11 Jul 2001 21:26:12 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15KY3I-000C5L-00 for namedroppers@ops.ietf.org; Wed, 11 Jul 2001 21:26:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Kevin Darcy To: namedroppers@ops.ietf.org Subject: Re: RFC 2119 section 6 References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 11 Jul 2001 21:26:13 -0700 Content-Transfer-Encoding: 7bit Andreas Borchert wrote: > On Wed, Jul 11, 2001 at 12:20:06AM -0700, Robert Elz wrote: > > Date: Tue, 10 Jul 2001 18:13:07 -0700 > > From: "D. J. Bernstein" > > Message-ID: > > > > | I have thousands of sites whose adminitsrators don't want to be forced > > | to upgrade their working DNS software. > > > > This is a nonsense argument - before anyone would possibly be required > > to upgrade their working software because of changes to AXFR that put > > something different in the auth/additional sections than what is in > > the answer section, all those administrators are going to have upgraded > > their software for other reasons anyway (and not necessarily all for the > > same one). > > This argument is not nonsense for administrators using djbdns and > other software packages from the same author. Dan designes his software > packages to be minimal, fast, and secure which allows him to keep them > stable for a long time. What's "minimal" about looking for zone data in sections where it doesn't belong? Section-agnosticism is not necessary for minimalism, security or performance, it's just a "feature" Dan made up to justify a fairly mundane design decision he made in his AXFR client which in hindsight probably should have been done a different way. - Kevin P.S. ($500 to the first person who proves that the following compromises security or substantially impacts performance. As is usual with such guarantees, my judgment is final as to whether a security-compromise or substantial-performance-impact in fact exists.) *** axfr-get.c.old Sun Jan 21 21:51:44 2001 --- axfr-get.c Wed Jul 11 21:03:38 2001 *************** *** 352,357 **** --- 352,358 ---- pos = x_copy(packet.s,packet.len,0,out,12); uint16_unpack_big(out + 4,&numqueries); + uint16_unpack_big(out + 6,&numanswers); while (numqueries) { --numqueries; *************** *** 358,366 **** pos = x_skipname(packet.s,packet.len,pos); pos += 4; } ! while (pos < packet.len) { pos = doit(packet.s,packet.len,pos); ! if (!pos) die_parse(); } } --- 359,368 ---- pos = x_skipname(packet.s,packet.len,pos); pos += 4; } ! while (numanswers) { ! --numanswers; pos = doit(packet.s,packet.len,pos); ! if (!pos || (pos > packet.len)) die_parse(); } } to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jul 12 01:02:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA07171 for ; Thu, 12 Jul 2001 01:02:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15KXvI-0006Gg-00 for namedroppers-data@psg.com; Wed, 11 Jul 2001 21:17:56 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15KXvI-0006Ga-00 for namedroppers@ops.ietf.org; Wed, 11 Jul 2001 21:17:56 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15KXvI-000Br7-00 for namedroppers@ops.ietf.org; Wed, 11 Jul 2001 21:17:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Stuart Cheshire To: "Andrew Brown" cc: Subject: Re: RFC 2782: SRV weight evaluation Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 11 Jul 2001 21:17:56 -0700 Content-Transfer-Encoding: 7bit >>If weights are to have a sensible intuitive meaning, then >>(in the presence of records containing weights greater than 0) >>records with weight 0 should *never* be selected. > >as a guess, i'd say that "records with a weight of zero in a record >set with some non-zero weights will end up being selected last in no >particular order". that is to say, all non-zero weighted records will >be picked first, and then the zero weight ones will be picked. Yes, you are right. That was what I meant. My unstated assumption was that after trying to contact a server and failing, that record is removed from the list and the process is repeated. After all the non-zero weight records have been tried and failed and removed, the zero-weight records are no longer "in the presence of records containing weights greater than 0", so they are now eligible for selection. Perhaps this wording is better: --- In the presence of records containing weights greater than zero, records with weight zero should *never* be selected. When there are no more records remaining present in the list with weights greater than zero (because all servers with non-zero weights, if any, have been tried already, and failed, and therefore removed from the list) any records still remaining (i.e. those with weight zero) should then be tried in random order. --- Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.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. From owner-namedroppers@ops.ietf.org Thu Jul 12 02:30:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02349 for ; Thu, 12 Jul 2001 02:30:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15KZQK-0000DD-00 for namedroppers-data@psg.com; Wed, 11 Jul 2001 22:54:04 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15KZQK-0000D7-00 for namedroppers@ops.ietf.org; Wed, 11 Jul 2001 22:54:04 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15KZPb-000L8v-00 for namedroppers@ops.ietf.org; Wed, 11 Jul 2001 22:53:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "Brian Zill" To: Subject: Proposed optimization to multicast DNS Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 11 Jul 2001 22:54:04 -0700 Content-Transfer-Encoding: 7bit I'd like to propose the following optimization to the multicast DNS draft. It is only applicable to IPv6, since it takes advantage of the larger multicast address space available in IPv6. The current version of the draft (draft-ietf-dnsext-mdns-01.txt) uses a single well-known link-local multicast address for all queries. This causes all responders to perform some packet processing on each query, even though in most cases this processing is merely to determine that the packet should be dropped (i.e. the query isn't for a record belonging to that responder). This is an analogous situation to IP address resolution, where queries are sent to discover a node's link-layer address. In IPv4 over Ethernet, the ARP protocol uses broadcast packets (which is equivalent to using a single multicast address that everyone listens to). In IPv6, however, Neighbor Discovery uses a more efficient scheme where nodes listen on a multicast address that is derived from their IP address -- this is the "solicited node multicast address". By basing the address to query on the very thing that is being queried, only those nodes that can actually respond to that query are likely to ever receive the packet. I propose something similar for multicast DNS. All IPv6 responders should listen to multicast queries on a "solicited name multicast address" instead of a single well-known multicast address. They derive their solicited name multicast address(es) by combining a 104-bit well-known link-local multicast prefix with the 24-bit result of a hash over the first portion of the name of the record(s) for which they are authoritative. Senders wishing to issue a query for a given record would first generate the solicited name multicast address corresponding to the record they wish to lookup. Then they would send the query to that address. Only those nodes listening to that particular multicast address would receive the packet, thus reducing significantly the amount of packet processing required by nodes participating in multicast DNS. Open issues: Size of multicast prefix and hash result. I chose 104 and 24, respectively, simply because those are the lengths used for solicited node multicast addresses. A smaller hash result would increase the likelihood of collisions, but the smaller address range might be more palatable to IANA. The choice of hash function might also figure in here. What hash function to use? Any half-way reasonable hash function would do, so it might be wise to use a hash function that all IPv6 implementations are required to have anyway. But MD5 and SHA-1 both seem a little overkill for this purpose. The internet checksum isn't great, and only yields 16 bits, but the code is present everywhere. There are plenty of other possibilities. Comments? --Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jul 12 09:21:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18812 for ; Thu, 12 Jul 2001 09:21:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15KfKp-0008Et-00 for namedroppers-data@psg.com; Thu, 12 Jul 2001 05:12:47 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15KfKo-0008En-00 for namedroppers@ops.ietf.org; Thu, 12 Jul 2001 05:12:46 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15KfKo-0006Hc-00 for namedroppers@ops.ietf.org; Thu, 12 Jul 2001 05:12:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Jun-ichiro itojun Hagino To: "Brian Zill" Cc: namedroppers@ops.ietf.org Subject: Re: Proposed optimization to multicast DNS In-reply-to: bzill's message of Wed, 11 Jul 2001 22:54:04 MST. Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Thu, 12 Jul 2001 05:12:47 -0700 Content-Transfer-Encoding: 7bit >I propose something similar for multicast DNS. All IPv6 responders >should listen to multicast queries on a "solicited name multicast >address" instead of a single well-known multicast address. They derive >their solicited name multicast address(es) by combining a 104-bit >well-known link-local multicast prefix with the 24-bit result of a hash >over the first portion of the name of the record(s) for which they are >authoritative. Senders wishing to issue a query for a given record >would first generate the solicited name multicast address corresponding >to the record they wish to lookup. Then they would send the query to >that address. Only those nodes listening to that particular multicast >address would receive the packet, thus reducing significantly the amount >of packet processing required by nodes participating in multicast DNS. I guess we'd better reuse NI group address defined in draft-ietf-ipngwg-icmp-name-lookups-07.txt, page 4. it is formatted as 96bit wellknown + 32bit hash, and will be like ff02::2:xxxx:yyyy (it is not officially assigned yet on IANA table). itojun to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jul 12 11:40:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07926 for ; Thu, 12 Jul 2001 11:40:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15KhcJ-000AFi-00 for namedroppers-data@psg.com; Thu, 12 Jul 2001 07:38:59 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15KhcJ-000AFc-00 for namedroppers@ops.ietf.org; Thu, 12 Jul 2001 07:38:59 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15KhcJ-000ABo-00 for namedroppers@ops.ietf.org; Thu, 12 Jul 2001 07:38:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Edward Lewis To: Internet-Drafts@ietf.org Cc: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-kamite-dnsext-tkey-secret-renewal-00.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Thu, 12 Jul 2001 07:38:59 -0700 Content-Transfer-Encoding: 7bit First, I'm really happy that someone is working on TKEY usage - it is one of the open areas for improvement in DNS Security. However, I think most of what is suggested in this document can be accomplished by adding another extended RCODE to the TKEY definision. "REKEY" could be a reply from a server to a client when there is an existing secret (temporally valid) that the server wishes to see go away. E.g. At 11pm, client and server agree on a secret to last from 11pm to 3am. At 12am (midnight), client queries with secret, server replies with secret. At 1 am, the server decides the secret is unacceptable (and the client doesn't know this). At 2am, client queries with secret, server replies with "REKEY" ...Without this new rcode, the choices the server has are "BADKEY" and a few others. "BADKEY" might be confusing to the client as this indicates a secret that is unknown/invalid to the server. As far as the client knows, the secret is agreed upon, perhaps the server is just suffering from amnesia. I think REKEY would help clarify this. Of course, the probably action by the client would be to start a rekeying as a reaction to BADKEY, so the clarification isn't for the software, but for the implementors. At 5:10 PM -0400 7/10/01, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : TKEY Secret Key Renewal Mode > Author(s) : Y. Kamite, M. Nakayama > Filename : draft-kamite-dnsext-tkey-secret-renewal-00.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com You fly too often when ... the airport taxi is on speed-dial. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jul 12 15:17:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09628 for ; Thu, 12 Jul 2001 15:17:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15KlMG-000DY4-00 for namedroppers-data@psg.com; Thu, 12 Jul 2001 11:38:40 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15KlMG-000DXy-00 for namedroppers@ops.ietf.org; Thu, 12 Jul 2001 11:38:40 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15KlMF-000H2T-00 for namedroppers@ops.ietf.org; Thu, 12 Jul 2001 11:38:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Brian Wellington To: Edward Lewis cc: , Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-02.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Thu, 12 Jul 2001 11:38:40 -0700 Content-Transfer-Encoding: 7bit On Thu, 12 Jul 2001, Edward Lewis wrote: > Ref. section 2, the term "Authenticated" is used. I think you mean to say > that the data has been verified via a temporally and cryptographically > verified chain of trust back to a configured key. Authenticated is too > broad a term, so you need to qualify it in this context or redefine it. > Even if this is done in another document, you should reference that more > explicitly. Authenticated is defined is RFC 2535, section 6.1. There's a reference to that right above the first use. > Now, for a open question. Authenitcated data presumably means that the > chain was built according to some policy - e.g., RFC 300x. What will > happen when the authenticating server uses a policy that is not strong > enough for the resolver? Will there be a way to indicate the policy used? > (This is also a question to folks wanting to research off-tree validation.) The resolver should only be looking at the AD bit if it trusts the server. Any resolver that has a policy should be doing the validation itself. > Finally - should it be more explicit that data in the additional section is > not (never) checked? I think it's explicit enough. There are only 4 sections - it's not hard to figure out which one isn't referred to :) > Is there a reason to always omit signatures from the > additional section in this case? (Why provide them if they've been > ignored?) Signatures in the additional section and the AD bit are orthogonal, I think. Only stub resolvers should care about the AD bit, and stub resolvers shouldn't use the additional section at all. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jul 12 15:17:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09647 for ; Thu, 12 Jul 2001 15:17:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15KlKU-000DVy-00 for namedroppers-data@psg.com; Thu, 12 Jul 2001 11:36:50 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15KlKU-000DVs-00 for namedroppers@ops.ietf.org; Thu, 12 Jul 2001 11:36:50 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15KlKU-000GzP-00 for namedroppers@ops.ietf.org; Thu, 12 Jul 2001 11:36:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: RFC 2119 section 6 References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Thu, 12 Jul 2001 11:36:50 -0700 Content-Transfer-Encoding: 7bit The problem is not the amount of code. The problem is the time and effort required to deploy that code at thousands of sites. If you extend a protocol without maintaining compatibility, you are inflicting completely unnecessary costs on people who don't want to use your extension. Suppose, for example, that you start randomly sending TKEY records to caches that haven't asked for them. My cache has no special knowledge of TKEY, but it follows the letter and spirit of the RFC 1123 rules on new record types, as explained in http://cr.yp.to/djbdns/newtypes.html; so it will save those records if they're within your bailiwick, and return them in response to appropriate queries. Suppose that---as Brian Wellington seems to suggest---these cached TKEY records will cause your own TKEY-aware clients to fail. (I don't know if this is actually the case. I haven't read the TKEY specification, nor do I see any reason that I should. IPSEC works.) Your extension is then incompatible with the installed base. If you insist on using it, you are creating failures. If you insist that I change my code to work around these failures, you are imposing costs on people---my users---who don't want to use your extension, and you will still have to wait many years before your extension is safe to use. That is not sensible engineering. You should have designed a compatible extension, an extension that would be safe to use immediately. I cannot imagine why anyone would argue in favor of an incompatible extension, except as a deliberate attempt to impose costs on other people. I accuse the BIND company of doing precisely that. Kevin Darcy writes: > Section-agnosticism is not necessary for minimalism, security or > performance, it's just a "feature" Dan made up to justify a fairly > mundane design decision What are you talking about? I've said nothing of the sort. This was a trivial implementation decision: out of the many possible ways to correctly parse an AXFR response message, I chose the one that I found easiest to write. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jul 12 15:17:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09673 for ; Thu, 12 Jul 2001 15:17:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15KkmC-000CrW-00 for namedroppers-data@psg.com; Thu, 12 Jul 2001 11:01:24 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15KkmC-000CrQ-00 for namedroppers@ops.ietf.org; Thu, 12 Jul 2001 11:01:24 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15KkmC-000G1s-00 for namedroppers@ops.ietf.org; Thu, 12 Jul 2001 11:01:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Edward Lewis To: ogud@ogud.com, brian.wellington@nominum.com Cc: lewis@tislabs.com, namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-02.txt In-Reply-To: <200106221111.HAA15809@ietf.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Thu, 12 Jul 2001 11:01:24 -0700 Content-Transfer-Encoding: 7bit Ref. section 2, the term "Authenticated" is used. I think you mean to say that the data has been verified via a temporally and cryptographically verified chain of trust back to a configured key. Authenticated is too broad a term, so you need to qualify it in this context or redefine it. Even if this is done in another document, you should reference that more explicitly. Now, for a open question. Authenitcated data presumably means that the chain was built according to some policy - e.g., RFC 300x. What will happen when the authenticating server uses a policy that is not strong enough for the resolver? Will there be a way to indicate the policy used? (This is also a question to folks wanting to research off-tree validation.) Finally - should it be more explicit that data in the additional section is not (never) checked? Is there a reason to always omit signatures from the additional section in this case? (Why provide them if they've been ignored?) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com You fly too often when ... the airport taxi is on speed-dial. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jul 12 15:24:01 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10556 for ; Thu, 12 Jul 2001 15:23:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15KlLJ-000DWu-00 for namedroppers-data@psg.com; Thu, 12 Jul 2001 11:37:41 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15KlLJ-000DWn-00 for namedroppers@ops.ietf.org; Thu, 12 Jul 2001 11:37:41 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15KlLJ-000H0q-00 for namedroppers@ops.ietf.org; Thu, 12 Jul 2001 11:37:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roy Arends To: , Subject: draft-arends-dnsext-rrsets-00.txt Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Thu, 12 Jul 2001 11:37:41 -0700 Content-Transfer-Encoding: 7bit Hello, I've submitted a draft on allowing Unsigned RRsets in Secure Zones. Below is the abstract. ------------------------------------------------------- Title : Unsigned RRsets in Secure Zones Author(s) : R. Arends Filename : draft-arends-dnsext-rrsets-00.txt Pages : Date : 11-Jul-01 In order for DNSSEC to be deployed operationally, there needs to be a mechanism that allows for unsigned RRsets in a secure zone. In the current definition of DNSSEC [RFC 2535], it is allowed to have 2 types of unsigned records, i.e. glue address RRsets and delegation point NS RRsets. There exists several reasons to allow other unsigned RRsets, all related to the scalability and maintenance of a secure zone. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-arends-dnsext-rrsets-00.txt ------------------------------------------------------ Note, Since this version of the draft did not acknowledge everyone who's help was greatly appreciated, here is section 7 (this is fixed in version 01 of the draft, which has just been submitted): 7. Acknowledgements The work in this draft is based on ideas stated in the [OPTIN] draft. The goals of these drafts are similar, though both use a different approach. The contributions, suggestions and remarks of the following persons (in alphabetic order) to this draft are acknowledged: Mats Dufberg Miek Gieben Olafur Gudmundsson Olaf Kolkman Mark Kosters Edward Lewis David Macka Dan Massey Scott Rose Jakob Schlyter Funding for the RFC Editor function is currently provided by the Internet Society. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jul 12 17:32:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27684 for ; Thu, 12 Jul 2001 17:32:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15KnUL-000Fe0-00 for namedroppers-data@psg.com; Thu, 12 Jul 2001 13:55:09 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15KnUL-000Fdu-00 for namedroppers@ops.ietf.org; Thu, 12 Jul 2001 13:55:09 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15KnUL-000Kpf-00 for namedroppers@ops.ietf.org; Thu, 12 Jul 2001 13:55:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Brian Wellington To: "D. J. Bernstein" cc: Subject: Re: RFC 2119 section 6 In-Reply-To: X-Authentication-Warning: spratly.nominum.com: bwelling owned process doing -bs X-X-Sender: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Thu, 12 Jul 2001 13:55:09 -0700 Content-Transfer-Encoding: 7bit On Thu, 12 Jul 2001, D. J. Bernstein wrote: > The problem is not the amount of code. The problem is the time and > effort required to deploy that code at thousands of sites. No one but you thinks it's necassary that all of these sites deploy the new code. > If you extend a protocol without maintaining compatibility, you are > inflicting completely unnecessary costs on people who don't want to use > your extension. True. I don't think anyone disagrees with this. > Suppose, for example, that you start randomly sending TKEY records to > caches that haven't asked for them. My cache has no special knowledge of > TKEY, but it follows the letter and spirit of the RFC 1123 rules on new > record types, as explained in http://cr.yp.to/djbdns/newtypes.html; so > it will save those records if they're within your bailiwick, and return > them in response to appropriate queries. > > Suppose that---as Brian Wellington seems to suggest---these cached TKEY > records will cause your own TKEY-aware clients to fail. (I don't know if > this is actually the case. I haven't read the TKEY specification, nor do > I see any reason that I should. IPSEC works.) I'm suggesting no such thing. I'm saying that your server will cache the records, which could lead to strange results in the future. For example, the cache TKEY records would be included in the response to an ANY query. For the record, your comments about BIND 9's handling of unknown types in http://cr.yp.to/djbdns/newtypes.html are wrong. > Your extension is then incompatible with the installed base. If you > insist on using it, you are creating failures. If you insist that I > change my code to work around these failures, you are imposing costs on > people---my users---who don't want to use your extension, and you will > still have to wait many years before your extension is safe to use. > > That is not sensible engineering. You should have designed a compatible > extension, an extension that would be safe to use immediately. Exactly which extension are you complaining about? No other implementations have these problems. > I cannot imagine why anyone would argue in favor of an incompatible > extension, except as a deliberate attempt to impose costs on other > people. I accuse the BIND company of doing precisely that. No one's arguing for an incompatible extension. The point is that there are extensions already that are reasonable given the spirit of the original AXFR specification. The axfr-clarify draft clarifies the AXFR specification, which makes these extensions fully legitimate. I'm fairly sure no decisions have ever been made purely to make your life more difficult. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jul 12 18:18:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03850 for ; Thu, 12 Jul 2001 18:18:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15KoDZ-000GL2-00 for namedroppers-data@psg.com; Thu, 12 Jul 2001 14:41:53 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15KoDZ-000GKw-00 for namedroppers@ops.ietf.org; Thu, 12 Jul 2001 14:41:53 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15KoDZ-000M5S-00 for namedroppers@ops.ietf.org; Thu, 12 Jul 2001 14:41:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Kevin Darcy To: namedroppers@ops.ietf.org Subject: Re: RFC 2119 section 6 References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Thu, 12 Jul 2001 14:41:53 -0700 Content-Transfer-Encoding: 7bit D. J. Bernstein wrote: > The problem is not the amount of code. The problem is the time and > effort required to deploy that code at thousands of sites. > > If you extend a protocol without maintaining compatibility, you are > inflicting completely unnecessary costs on people who don't want to use > your extension. > > Suppose, for example, that you start randomly sending TKEY records to > caches that haven't asked for them. My cache has no special knowledge of > TKEY, but it follows the letter and spirit of the RFC 1123 rules on new > record types, as explained in http://cr.yp.to/djbdns/newtypes.html; so > it will save those records if they're within your bailiwick, and return > them in response to appropriate queries. > > Suppose that---as Brian Wellington seems to suggest---these cached TKEY > records will cause your own TKEY-aware clients to fail. (I don't know if > this is actually the case. I haven't read the TKEY specification, nor do > I see any reason that I should. IPSEC works.) > > Your extension is then incompatible with the installed base. If you > insist on using it, you are creating failures. If you insist that I > change my code to work around these failures, you are imposing costs on > people---my users---who don't want to use your extension, and you will > still have to wait many years before your extension is safe to use. > > That is not sensible engineering. You should have designed a compatible > extension, an extension that would be safe to use immediately. Dan, you really *shouldn't* be treating all RR's in an AXFR response as zone data. Whether or not TKEY was implemented shortsightedly is rather a moot point, since implementations are already starting to use it as it is currently specified. And I'm sure other extensions will probably want to use Authority and/or Additional, and won't necessarily think to treat AXFR responses as a special case. You can't expect the rest of the protocol to evolve around AXFR while it stays static. If you want your software to be robust, I don't think you have any other choice but to ignore unexpected RRs in Authority or Additional, regardless of what the clarify draft says, because, bilateral agreement or not, you're going to be *seeing* those RRs, and treating them as zone data is bound to cause problems. > Kevin Darcy writes: > > Section-agnosticism is not necessary for minimalism, security or > > performance, it's just a "feature" Dan made up to justify a fairly > > mundane design decision > > What are you talking about? I've said nothing of the sort. Perhaps I misinterpreted the following statement then: > My AXFR client doesn't look for sections. It treats all records as part > of the zone. It works just fine. > I read this as praise of section-agnoticism. - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jul 12 19:12:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10202 for ; Thu, 12 Jul 2001 19:12:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Kp1y-000HQ5-00 for namedroppers-data@psg.com; Thu, 12 Jul 2001 15:33:58 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15Kp1x-000HPs-00 for namedroppers@ops.ietf.org; Thu, 12 Jul 2001 15:33:57 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15Kp1s-0000L0-00 for namedroppers@ops.ietf.org; Thu, 12 Jul 2001 15:33:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: David Terrell Reply-To: David Terrell To: Brian Zill Cc: namedroppers@ops.ietf.org Subject: Re: Proposed optimization to multicast DNS In-Reply-To: ; from bzill@microsoft.com on Wed, Jul 11, 2001 at 10:54:04PM -0700 References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Thu, 12 Jul 2001 15:33:58 -0700 Content-Transfer-Encoding: 7bit On Wed, Jul 11, 2001 at 10:54:04PM -0700, Brian Zill wrote: > I propose something similar for multicast DNS. All IPv6 responders > should listen to multicast queries on a "solicited name multicast > address" instead of a single well-known multicast address. They derive > their solicited name multicast address(es) by combining a 104-bit > well-known link-local multicast prefix with the 24-bit result of a hash > over the first portion of the name of the record(s) for which they are > authoritative. > > [...] > > Open issues: > > Size of multicast prefix and hash result. I chose 104 and 24, > respectively, simply because those are the lengths used for solicited > node multicast addresses. A smaller hash result would increase the > likelihood of collisions, but the smaller address range might be more > palatable to IANA. The choice of hash function might also figure in > here. > > What hash function to use? Any half-way reasonable hash function would > do, so it might be wise to use a hash function that all IPv6 > implementations are required to have anyway. But MD5 and SHA-1 both > seem a little overkill for this purpose. The internet checksum isn't > great, and only yields 16 bits, but the code is present everywhere. How does DNS's case insensitivity come into play here? -- David Terrell | "To increase the hype, I'm gonna release a bunch Nebcorp PM | of BLT variants (NetBLT, FreeBLT, BLT386, etc) dbt@meat.net | and create artificial rivalries." wwn.nebcorp.com | - Brian Sweltand (www.openblt.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. From owner-namedroppers@ops.ietf.org Thu Jul 12 19:33:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12660 for ; Thu, 12 Jul 2001 19:33:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15KpfA-000ISO-00 for namedroppers-data@psg.com; Thu, 12 Jul 2001 16:14:28 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15KpfA-000ISI-00 for namedroppers@ops.ietf.org; Thu, 12 Jul 2001 16:14:28 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15KpfA-0001UF-00 for namedroppers@ops.ietf.org; Thu, 12 Jul 2001 16:14:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: TKEY compatibility problems References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Thu, 12 Jul 2001 16:14:28 -0700 Content-Transfer-Encoding: 7bit Brian Wellington writes: > I'm saying that your server will cache the > records, which could lead to strange results in the future. I don't know what you mean by ``strange.'' Is there a problem, or not? Will a TKEY-aware client have trouble if I forward it a copy of a TKEY record that someone else spontaneously sent me? If so, the TKEY extension is broken. You said that TKEY servers could spontaneously send TKEY records. Forwarding the records---treating them as zone data---is indisputably correct behavior for my cache. See RFC 1123 section 6.1.3.5. See also http://cr.yp.to/djbdns/newtypes.html. If, on the other hand, there is no problem, then why did you claim that my AXFR client shouldn't forward the records? ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jul 12 19:45:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA14084 for ; Thu, 12 Jul 2001 19:45:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Kpfh-000ITi-00 for namedroppers-data@psg.com; Thu, 12 Jul 2001 16:15:01 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15Kpfh-000ITb-00 for namedroppers@ops.ietf.org; Thu, 12 Jul 2001 16:15:01 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15Kpfh-0001VA-00 for namedroppers@ops.ietf.org; Thu, 12 Jul 2001 16:15:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: RFC 2119 section 6 References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Thu, 12 Jul 2001 16:15:01 -0700 Content-Transfer-Encoding: 7bit Brian Wellington writes: > The point is that there are extensions already that are reasonable > given the spirit of the original AXFR specification. Nothing in the original specification requires that AXFR clients stop reading packets at the end of the answer section. If you dispute this, please quote the text that you believe imposes such a requirement. > No one but you thinks it's necassary that all of these sites deploy the > new code. I have repeatedly asked why I should make this change to the code. What exactly is the benefit? The answer from your coworker Mark Andrews is that he might someday do something that _fails_---causes ``damage,'' he says---if it encounters the unchanged code. He says he wants to avoid ``breaking things.'' But changing the code isn't enough to prevent these failures. The changed code would have to be _deployed_. That's the cost I'm talking about. Deployment takes time and effort. Is the BIND company backing away from demanding that my users suffer this cost? If so, I ask again: What exactly is the benefit of my making this change to the code? > For the record, your comments about BIND 9's handling of unknown types > in http://cr.yp.to/djbdns/newtypes.html are wrong. The page was accurate when I wrote it. Are you saying that BIND was subsequently fixed? Which versions? ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jul 13 11:05:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19839 for ; Fri, 13 Jul 2001 11:05:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15L3GU-000ElF-00 for namedroppers-data@psg.com; Fri, 13 Jul 2001 06:45:54 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15L3GU-000El9-00 for namedroppers@ops.ietf.org; Fri, 13 Jul 2001 06:45:54 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15L3GU-000Cwg-00 for namedroppers@ops.ietf.org; Fri, 13 Jul 2001 06:45:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Yuji Kamite To: namedroppers@ops.ietf.org Cc: nakayama@nc.u-tokyo.ac.jp, kamite@kaynet.ecc.u-tokyo.ac.jp Subject: Re: I-D ACTION:draft-kamite-dnsext-tkey-secret-renewal-00.txt In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Fri, 13 Jul 2001 06:45:54 -0700 Content-Transfer-Encoding: 7bit On Thu, 12 Jul 2001 07:38:59 -0700 Edward Lewis wrote: > However, I think most of what is suggested in this document can be > accomplished by adding another extended RCODE to the TKEY definision. > "REKEY" could be a reply from a server to a client when there is an > existing secret (temporally valid) that the server wishes to see go away. Thanks for your comments. I guess adding a new RCODE may be another choice. I wonder which is better to use TSIG errors (in our drafts, we proposed "PartialRevoke" error), or other things like RDODE. If there are any strong good reasons for using extende RCODE, your indication would be considered better. I think the essential idea is that servers should return messages with some information that secret refreshment is necessary, thus in that sense, our draft is one way for its fulfillment and your indication may be another. Anyway, I think we should make it clear the process for TSIG key refreshment because only by TKEY RFC2930 implementors cannot provide key renewal mechanism, and we need to prepare some new definitions such as new RCODE, Error Code etc. and rollover processes. > > E.g. At 11pm, client and server agree on a secret to last from 11pm to 3am. > > At 12am (midnight), client queries with secret, server replies with secret. > > At 1 am, the server decides the secret is unacceptable (and the client > doesn't know this). > > At 2am, client queries with secret, server replies with "REKEY" > I guess this is a good example. At 2am, client gets "REKEY". At 2:01am, client sends TKEY to make new secret. At 2:02am, client sends queries with new secret. This is an ideal case. On the other hand, At 2am, client gets "REKEY". At 2:01am, client needs to suspend for some reasons or emergency At 3:00am, the key went away from the server At 3:05am, client recovered, and sends TKEY to make new secret. but gets "BADKEY" because client has used removed key. In this case, clients need another authenticaion for TKEY, maybe SIG(0) or another shared secret not expired. This is a littel complicated case because it depends wholely on client when it sends a TKEY request message. We've tried to describe it in our draft. This makes servers be deleberate about the timing of real expiration, i.e. 11am(inception)--2am(demand renewal)---3am(real expiration). Our proposal's "PartialRevoke" seems to have almost the same meaning as demanding renewal by "REKEY". Real expiration above is defined "compulsory revocation" in our drats. On the other hand, your indication and our drafts have some differences about how to deal with expiration time agreed between server and client (by TKEY). > ...Without this new rcode, the choices the server has are "BADKEY" and a > few others. "BADKEY" might be confusing to the client as this indicates a > secret that is unknown/invalid to the server. As far as the client knows, > the secret is agreed upon, perhaps the server is just suffering from > amnesia. I think REKEY would help clarify this. > > Of course, the probably action by the client would be to start a rekeying > as a reaction to BADKEY, so the clarification isn't for the software, but > for the implementors. I agree it is not enough to use "BADKEY" error for managing secret keys for TSIG. Today, clients will get "BADKEY" both when they have signed with keys which are not agreed by servers and when the keys are removed from the servers. Current implementation (BIND9) seems to delete keys in memory whose secret expiry time agreed by TKEY Diffe-Hellman exchage is past the current time, thus clients must be very careful about the expiry times because only by the error code "BADKEY", they cannot distinguish their secret expiration, simple misconfiguration by the client key, and somebody's spoofing. -- Yuji Kamite Information Technology Center, Univ. of Tokyo E-Mail: kamite@kaynet.ecc.u-tokyo.ac.jp to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jul 13 12:22:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01270 for ; Fri, 13 Jul 2001 12:22:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15L4On-000GAD-00 for namedroppers-data@psg.com; Fri, 13 Jul 2001 07:58:33 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15L4On-000GA7-00 for namedroppers@ops.ietf.org; Fri, 13 Jul 2001 07:58:33 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15L4On-000GXn-00 for namedroppers@ops.ietf.org; Fri, 13 Jul 2001 07:58:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Matt Crawford To: namedroppers@ops.ietf.org Subject: Re: Proposed optimization to multicast DNS In-reply-to: "12 Jul 2001 15:33:58 PDT." Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Fri, 13 Jul 2001 07:58:33 -0700 Content-Transfer-Encoding: 7bit For forming the IPv6 multicast address for a query, consider copying the method of draft-ietf-ipngwg-icmp-name-lookups-07.txt, section 3, second paragraph. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jul 13 21:42:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA15076 for ; Fri, 13 Jul 2001 21:42:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15LDdq-0002Xp-00 for namedroppers-data@psg.com; Fri, 13 Jul 2001 17:50:42 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15LDdp-0002Xj-00 for namedroppers@ops.ietf.org; Fri, 13 Jul 2001 17:50:41 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15LDdp-000BE7-00 for namedroppers@ops.ietf.org; Fri, 13 Jul 2001 17:50:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Brian Wellington To: "D. J. Bernstein" cc: Subject: Re: RFC 2119 section 6 In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Fri, 13 Jul 2001 17:50:42 -0700 Content-Transfer-Encoding: 7bit On Thu, 12 Jul 2001, D. J. Bernstein wrote: > Brian Wellington writes: > > The point is that there are extensions already that are reasonable > > given the spirit of the original AXFR specification. > > Nothing in the original specification requires that AXFR clients stop > reading packets at the end of the answer section. If you dispute this, > please quote the text that you believe imposes such a requirement. Dan, you're missing the point. The whole point of the axfr-clarify draft is that the original specification is unclear. Obviously there is no such stated requirement, or we wouldn't be having this painfully long argument. > > No one but you thinks it's necassary that all of these sites deploy the > > new code. > > I have repeatedly asked why I should make this change to the code. What > exactly is the benefit? > > The answer from your coworker Mark Andrews is that he might someday do > something that _fails_---causes ``damage,'' he says---if it encounters > the unchanged code. He says he wants to avoid ``breaking things.'' That seems like a perfectly reasonable point. > But changing the code isn't enough to prevent these failures. The > changed code would have to be _deployed_. That's the cost I'm talking > about. Deployment takes time and effort. Not true. If you changed the code now, deployment would naturally occur by the time incompatible features were used. > Is the BIND company backing away from demanding that my users suffer > this cost? If so, I ask again: What exactly is the benefit of my making > this change to the code? Compatibility with future extensions and the future standard. And the fact that it would take less time than continuing to argue. And it doesn't hurt anything. > > For the record, your comments about BIND 9's handling of unknown types > > in http://cr.yp.to/djbdns/newtypes.html are wrong. > > The page was accurate when I wrote it. Are you saying that BIND was > subsequently fixed? Which versions? 9.1.0. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jul 13 21:44:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA15274 for ; Fri, 13 Jul 2001 21:44:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15LDdz-0002Xy-00 for namedroppers-data@psg.com; Fri, 13 Jul 2001 17:50:51 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15LDdz-0002Xs-00 for namedroppers@ops.ietf.org; Fri, 13 Jul 2001 17:50:51 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15LDdz-000BEZ-00 for namedroppers@ops.ietf.org; Fri, 13 Jul 2001 17:50:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Brian Wellington To: "D. J. Bernstein" cc: Subject: Re: TKEY compatibility problems In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Fri, 13 Jul 2001 17:50:51 -0700 Content-Transfer-Encoding: 7bit On Thu, 12 Jul 2001, D. J. Bernstein wrote: > Brian Wellington writes: > > I'm saying that your server will cache the > > records, which could lead to strange results in the future. > > I don't know what you mean by ``strange.'' Is there a problem, or not? > Will a TKEY-aware client have trouble if I forward it a copy of a TKEY > record that someone else spontaneously sent me? There would be a problem if a client was sanity checking the response of an ANY query, and saw a TKEY record in the answer section. Seeing a meta-type where it's not expected is bad. > If so, the TKEY extension is broken. You said that TKEY servers could > spontaneously send TKEY records. Forwarding the records---treating them > as zone data---is indisputably correct behavior for my cache. See RFC > 1123 section 6.1.3.5. See also http://cr.yp.to/djbdns/newtypes.html. A spontaneous TKEY will only be in the additional section, which means that it shouldn't be treated as zone data. If it was in the answer section, I'd agree that it would be zone data, and that it is a broken extension. > If, on the other hand, there is no problem, then why did you claim that > my AXFR client shouldn't forward the records? Because they're not part of the zone, as indicated by the fact that they're in the additional section. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jul 14 01:22:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA12414 for ; Sat, 14 Jul 2001 01:22:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15LHAw-0007rZ-00 for namedroppers-data@psg.com; Fri, 13 Jul 2001 21:37:06 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15LHAw-0007rT-00 for namedroppers@ops.ietf.org; Fri, 13 Jul 2001 21:37:06 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15LHAw-000MFY-00 for namedroppers@ops.ietf.org; Fri, 13 Jul 2001 21:37:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: TKEY compatibility problems References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Fri, 13 Jul 2001 21:37:06 -0700 Content-Transfer-Encoding: 7bit Suppose I'm a DNS cache with no special knowledge of type TKEY or type XYZZY. Someone asks me for all nominum.com records of type XYZZY. One of the nominum.com servers gives me the following response, including a spontaneously generated TKEY record, which Wellington says is not prohibited by the TKEY specification: query: XYZZY nominum.com answer: nominum.com 3600 XYZZY ... authority: nominum.com 3600 NS ... authority: nominum.com 3600 NS ... authority: nominum.com 3600 NS ... additional: gns1.nominum.com 3600 A ... additional: gns2.nominum.com 3600 A ... additional: nominum.com 3600 TKEY ... All those records are within nominum.com, so I cache all of them. I do _not_ ignore the two records of unrecognized types. As stated in RFC 1123, section 6.1.3.5: ``A name server may acquire, via zone transfer, RRs that the server doesn't know how to convert to printable format. A resolver can receive similar information as the result of queries. For proper operation, this data must be preserved.'' I do _not_ ignore the three authority records, and I do _not_ ignore the three additional records. Wellington's comment ``they're not part of the zone, as indicated by the fact that they're in the additional section'' is completely out of touch with the existing DNS protocol. Someone now asks me for all nominum.com records of type *. I am entirely within my rights to respond with all the cached nominum.com records, including the TKEY record: query: * nominum.com answer: nominum.com 3597 NS ... answer: nominum.com 3597 NS ... answer: nominum.com 3597 NS ... answer: nominum.com 3597 TKEY ... answer: nominum.com 3597 XYZZY ... Wellington claims that TKEY-aware clients may barf on this response. The inescapable conclusion is that the TKEY protocol is broken. It is incompatible with the existing protocol. It has to be fixed. How can a broken protocol be used as an argument against the behavior of my AXFR implementation? I'm indisputably allowed to save records from the authority section and the additional section when I'm a cache, so why can't I do the same when I'm an AXFR client? ---Dan P.S. This particular failure won't actually happen with our current implementations: my cache will stop its * response after the NS records, and the nominum.com servers won't spontaneously generate TKEY records in the first place. But the specifications don't require these protections. P.P.S. Each of my messages, as sent, contains the following statement in the header: ``Copyright 2001, D. J. Bernstein. My transmission of this message to you does not constitute a copyright waiver or any other limitation of my rights, even if you have told me otherwise.'' This statement is being discarded somewhere in Randy Bush's mail system. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jul 14 17:34:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA08065 for ; Sat, 14 Jul 2001 17:34:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15LQqx-000Mui-00 for namedroppers-data@psg.com; Sat, 14 Jul 2001 07:57:07 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15LQqw-000Mub-00 for namedroppers@ops.ietf.org; Sat, 14 Jul 2001 07:57:06 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15LQqw-000101-00 for namedroppers@ops.ietf.org; Sat, 14 Jul 2001 07:57:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Mark Kosters To: namedroppers@ops.ietf.org Subject: announcing opt-in dnssec pilot Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sat, 14 Jul 2001 07:57:07 -0700 Content-Transfer-Encoding: 7bit Hi Along with the opt-in paper (as it currently stands), we have also rolled out a pilot for one to look at and kick the tires. The url for the pilot is http://www.dnssec.research.netsol.com. The pilot showcases: 1) A web interface to three managed domains: gtld-dnssec.com, gtld-dnssec.org, and gtld-dnssec.net that one can edit the contents, secure and unsecure easily. The modified contents are reflected in a dnssec server (rfc 2535 variety). As the zone is secured/unsecured, the web interface talks to the backend database using a modified version of rrp. 2) A key management interface that is basically a webified interface to an enhanced version of rrp. Right now, people can select a domain (or domains) from a list to secure/unsecure. Once secured, one can see how it is reflected through the dnssec opt-in server. 3) An opt-in dnssec server that serves com/net/org and reflects changes to domains secured either in the key management interface or the web interface. Note that this is not currently real time (yet) but is updated every four hours starting at midnight. 4) A dig-like query interface for those who are dig-challenged. Specifics should be on the web site in the FAQ's. If you have any questions, feel free to ask. Regards, Mark PS. Note that this is a pilot - it is not production. We have done this to seek input and validate the relevant dnssec drafts that we need to be concerned with (namely opt-in and parent-sig). As better ideas emerge, we'll try to adjust the pilot accordingly. -- Mark Kosters markk@netsol.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. From owner-namedroppers@ops.ietf.org Sun Jul 15 13:56:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01979 for ; Sun, 15 Jul 2001 13:56:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15LpAZ-000Ctn-00 for namedroppers-data@psg.com; Sun, 15 Jul 2001 09:54:59 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15LpAY-000CtX-00 for namedroppers@ops.ietf.org; Sun, 15 Jul 2001 09:54:58 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15LpAY-000MtA-00 for namedroppers@ops.ietf.org; Sun, 15 Jul 2001 09:54:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: "D. J. Bernstein" cc: namedroppers@ops.ietf.org Subject: Re: TKEY compatibility problems In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sun, 15 Jul 2001 09:54:59 -0700 Content-Transfer-Encoding: 7bit Date: Fri, 13 Jul 2001 21:37:06 -0700 From: "D. J. Bernstein" Message-ID: | I do _not_ ignore the three authority records, and I do _not_ ignore the | three additional records. Wellington's comment ``they're not part of the | zone, as indicated by the fact that they're in the additional section'' | is completely out of touch with the existing DNS protocol. Could you possibly explain, in very plain words, just what it would hurt for you to alter your implementation to make it that only the answer section in an AXFR was used as zone data? Forget the "upgrade costs" argument - no-one is going to be asked to actually install the changed version any time soon. Is there any other reason that this change would do harm? There's no dispute that the zone must all be placed in the answer section by the AXFR server, what real harm can there be in expecting the AXFR client to only look there? This isn't completely out of touch with anything - it was the way that AXFR was always intended to be, but, like a lot of old internet specs, stuff that was obvious to everyone was sometimes omitted (no-one saw the need to actually write it down). That's what is attempting to be fixed now. This is even one where (until recently it seems) no-one had ever even managed to not implement correctly, and in the DNS world, that's near remarkable - even the very clearest parts of the spec have managed to get broken implementations... | P.P.S. Each of my messages, as sent, contains the following statement in | the header: ``Copyright 2001, D. J. Bernstein. My transmission of this | message to you does not constitute a copyright waiver or any other | limitation of my rights, even if you have told me otherwise.'' This | statement is being discarded somewhere in Randy Bush's mail system. Yes, the moderation seems to drop all but a few headers, and re-send as a new message (I have seen other lists do the same, even without any human involvement). Not that it should matter to your missing header, as (notwithstanding the noise going on in poisson at the minute) copyright is implied without a notice (even in the US these days I gather...) kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 16 20:48:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21015 for ; Mon, 16 Jul 2001 20:48:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MI2W-000IZm-00 for namedroppers-data@psg.com; Mon, 16 Jul 2001 16:44:36 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15MI2V-000IZg-00 for namedroppers@ops.ietf.org; Mon, 16 Jul 2001 16:44:35 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15MHp5-000HhQ-00 for namedroppers@ops.ietf.org; Mon, 16 Jul 2001 19:30:43 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Kevin Darcy To: namedroppers@ops.ietf.org Subject: Re: TKEY compatibility problems References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 16 Jul 2001 16:44:36 -0700 Content-Transfer-Encoding: 7bit The key word in the RFC 1123 verbiage is "acquire". The only data that you "acquire" in an AXFR transaction are Answer-section RRs. Anything else in the response is to be considered "meta-data", and if you don't understand it and/or didn't ask for it, you should ignore it. Similarly, for ordinary queries, I don't know that "result", as used in the RFC 1123 verbiage you quoted, extends beyond the direct answer to the query, i.e. the Answer Section. Maybe it also encompasses the contents of the Authority Section in the case of a referral... - Kevin D. J. Bernstein wrote: > Suppose I'm a DNS cache with no special knowledge of type TKEY or type > XYZZY. Someone asks me for all nominum.com records of type XYZZY. > > One of the nominum.com servers gives me the following response, > including a spontaneously generated TKEY record, which Wellington says > is not prohibited by the TKEY specification: > > query: XYZZY nominum.com > answer: nominum.com 3600 XYZZY ... > authority: nominum.com 3600 NS ... > authority: nominum.com 3600 NS ... > authority: nominum.com 3600 NS ... > additional: gns1.nominum.com 3600 A ... > additional: gns2.nominum.com 3600 A ... > additional: nominum.com 3600 TKEY ... > > All those records are within nominum.com, so I cache all of them. > > I do _not_ ignore the two records of unrecognized types. As stated in > RFC 1123, section 6.1.3.5: ``A name server may acquire, via zone > transfer, RRs that the server doesn't know how to convert to printable > format. A resolver can receive similar information as the result of > queries. For proper operation, this data must be preserved.'' > > I do _not_ ignore the three authority records, and I do _not_ ignore the > three additional records. Wellington's comment ``they're not part of the > zone, as indicated by the fact that they're in the additional section'' > is completely out of touch with the existing DNS protocol. > > Someone now asks me for all nominum.com records of type *. I am entirely > within my rights to respond with all the cached nominum.com records, > including the TKEY record: > > query: * nominum.com > answer: nominum.com 3597 NS ... > answer: nominum.com 3597 NS ... > answer: nominum.com 3597 NS ... > answer: nominum.com 3597 TKEY ... > answer: nominum.com 3597 XYZZY ... > > Wellington claims that TKEY-aware clients may barf on this response. > > The inescapable conclusion is that the TKEY protocol is broken. It is > incompatible with the existing protocol. It has to be fixed. > > How can a broken protocol be used as an argument against the behavior of > my AXFR implementation? I'm indisputably allowed to save records from > the authority section and the additional section when I'm a cache, so > why can't I do the same when I'm an AXFR client? > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 16 20:48:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21031 for ; Mon, 16 Jul 2001 20:48:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MI1g-000IVw-00 for namedroppers-data@psg.com; Mon, 16 Jul 2001 16:43:44 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15MI1f-000IVq-00 for namedroppers@ops.ietf.org; Mon, 16 Jul 2001 16:43:43 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15MHe4-000Hd7-00 for namedroppers@ops.ietf.org; Mon, 16 Jul 2001 19:19:20 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Edward Lewis To: namedroppers@ops.ietf.org Cc: lewis@tislabs.com Subject: Question about TSIG, AD/AA, and AXFR Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 16 Jul 2001 16:43:44 -0700 Content-Transfer-Encoding: 7bit I am wondering if there is an unreported protocol problem in the combination of TSIG, AD/AA, and AXFR. My concern is that a resolver may over trust an answer that has come TSIG-protected from a secondary who used an unsecured AXFR to get its zone data. Here is the case-by-case breakdown that led me to this concern. Assuming a "stub" resolver - one that will rely on query/response security and is not able/willing to do full chain processing, and only looking at TSIG-covered answers: Case TSIG AD AA Server-type 1 Y 0 1 Primary "From disk," so it can be trusted 2 Y 0 1 Secondary Via AXFR, trustworthy only if AXFR is secure 3 Y 1 0 Non-auth Server validated the chain 4 Y 1 1 anything Not possible as far as I can tell DNS Security is supposed to be about protecting the resolver, and here we have a case (#2) where the resolver can't be sure of an answer's security. It is fine to recommend that zone transfers use TSIG, but then you're putting discretion in the hands of the zone and not the resolver. (Not to mention that TSIG isn't the only way to secure an AXFR.) Can there be some way to indicate that a secondary has used a secure means to acquire the zone data? (Yeah, "can there be some way to indicate that a *primary* has used a secure means to acquire the zone data?" is the first rebuttal. But we know that a secondary had to get its data from some other machine, so I think this asking about a secondary's source is valid.) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com You fly too often when ... the airport taxi is on speed-dial. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 16 23:04:50 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA12229 for ; Mon, 16 Jul 2001 23:04:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MKKy-000Pkg-00 for namedroppers-data@psg.com; Mon, 16 Jul 2001 19:11:48 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15MKKy-000PkZ-00 for namedroppers@ops.ietf.org; Mon, 16 Jul 2001 19:11:48 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15MKJ6-000HvY-00 for namedroppers@ops.ietf.org; Mon, 16 Jul 2001 22:09:52 -0400 MIME-Version: 1.0 content-class: urn:content-classes:message Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C10E64.5C5B746D" From: "Christian Huitema" To: Subject: FW: I-D ACTION:draft-huitema-ipv6-renumber-00.txt Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 16 Jul 2001 19:11:48 -0700 This is a multi-part message in MIME format. ------_=_NextPart_001_01C10E64.5C5B746D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Site Renumbering Author(s) : C. Huitema Filename : draft-huitema-ipv6-renumber-00.txt Pages : 7 Date : 13-Jul-01 =09 There has been recently a lot of the discussion in the IPNG, NGTRANS=20 and DNSEXT working group about the level at which IPv6 shall support=20 renumbering. A specific question is whether we need special support=20 in the DNS to enable renumbering, as specified in [RFC2874], or if=20 the simpler mechanisms specified in [RFC1886] are sufficient. In=20 order to organize the discussion, this memo presents a set of=20 realistic renumbering scenarios, discusses the possible frequency at=20 which such scenarios can be repeated, presents some tools that can=20 be used to organize the renumbering, and summarizes the operational=20 requirements that have to be met by any renumbering solution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-huitema-ipv6-renumber-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-huitema-ipv6-renumber-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-huitema-ipv6-renumber-00.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C10E64.5C5B746D Content-Type: application/octet-stream; name="ATT358214.TXT" Content-Description: ATT358214.TXT Content-Disposition: attachment; filename="ATT358214.TXT" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7DQoJYWNjZXNzLXR5cGU9Im1haWwt c2VydmVyIjsNCglzZXJ2ZXI9Im1haWxzZXJ2QGlldGYub3JnIg0KDQpDb250ZW50LVR5cGU6IHRl eHQvcGxhaW4NCkNvbnRlbnQtSUQ6CTwyMDAxMDcxMzEyNDAxNS5JLURAaWV0Zi5vcmc+DQoNCkVO Q09ESU5HIG1pbWUNCkZJTEUgL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1odWl0ZW1hLWlwdjYtcmVu dW1iZXItMDAudHh0DQo= ------_=_NextPart_001_01C10E64.5C5B746D Content-Type: application/octet-stream; name="draft-huitema-ipv6-renumber-00.URL" Content-Description: draft-huitema-ipv6-renumber-00.URL Content-Disposition: attachment; filename="draft-huitema-ipv6-renumber-00.URL" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1odWl0ZW1hLWlwdjYtcmVudW1iZXItMDAudHh0DQo= ------_=_NextPart_001_01C10E64.5C5B746D-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 17 08:43:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA25130 for ; Tue, 17 Jul 2001 08:43:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MTrl-000Er7-00 for namedroppers-data@psg.com; Tue, 17 Jul 2001 05:22:17 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15MTrk-000Er1-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 05:22:16 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15MTrj-000INY-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 08:22:15 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Brian Wellington To: Edward Lewis Cc: Subject: Re: Question about TSIG, AD/AA, and AXFR In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 17 Jul 2001 05:22:17 -0700 Content-Transfer-Encoding: 7bit On Mon, 16 Jul 2001, Edward Lewis wrote: > I am wondering if there is an unreported protocol problem in the > combination of TSIG, AD/AA, and AXFR. My concern is that a resolver may > over trust an answer that has come TSIG-protected from a secondary who used > an unsecured AXFR to get its zone data. > > Here is the case-by-case breakdown that led me to this concern. Assuming a > "stub" resolver - one that will rely on query/response security and is not > able/willing to do full chain processing, and only looking at TSIG-covered > answers: > > Case TSIG AD AA Server-type > 1 Y 0 1 Primary "From disk," so it can be trusted > 2 Y 0 1 Secondary Via AXFR, trustworthy only if AXFR is secure > 3 Y 1 0 Non-auth Server validated the chain > 4 Y 1 1 anything Not possible as far as I can tell > > DNS Security is supposed to be about protecting the resolver, and here we > have a case (#2) where the resolver can't be sure of an answer's security. > It is fine to recommend that zone transfers use TSIG, but then you're > putting discretion in the hands of the zone and not the resolver. (Not to > mention that TSIG isn't the only way to secure an AXFR.) > > Can there be some way to indicate that a secondary has used a secure means > to acquire the zone data? (Yeah, "can there be some way to indicate that a > *primary* has used a secure means to acquire the zone data?" is the first > rebuttal. But we know that a secondary had to get its data from some other > machine, so I think this asking about a secondary's source is valid.) I don't know how important this is. As you say, there's no way to guarantee that the primary has obtained the data securely. If the administrators of the secure zone cares enough to sign the zone on a periodic basic and guarantee that the primary is serving it properly, they should care enough to ensure that zone transfers are secured. Especially since TSIG is signficantly easier to set up than DNSSEC. Are you talking about the stub resolver directly contacting a secondary? It should be going through a recursive server, and the recursive server will validate the data. If the data on the secondary has been corrupted or maliciously altered, the recursive server will fail to verify it. About the worst can happen is that the secondary can serve data that's no longer in the zone but still valid, but the same thing can happen with any caching server. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 17 09:16:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02390 for ; Tue, 17 Jul 2001 09:16:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MU4J-000FF2-00 for namedroppers-data@psg.com; Tue, 17 Jul 2001 05:35:15 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15MU4J-000FEw-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 05:35:15 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15MU4I-000IP5-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 08:35:14 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Jakob Schlyter To: Edward Lewis Cc: Subject: Re: Question about TSIG, AD/AA, and AXFR In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 17 Jul 2001 05:35:15 -0700 Content-Transfer-Encoding: 7bit On Mon, 16 Jul 2001, Edward Lewis wrote: > Case TSIG AD AA Server-type > 1 Y 0 1 Primary "From disk," so it can be trusted > 2 Y 0 1 Secondary Via AXFR, trustworthy only if AXFR is secure why can the data be trusted just because the server read it from disk or safely AXFRed? a lot of bad things could have happen to the data between signing och loading, especially if you're doing off-line signing. - the signatures could have expired - the signatures could not be valid yet - someone could maliciously have inserted or altered data - data could be corrupted by other means 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. From owner-namedroppers@ops.ietf.org Tue Jul 17 09:22:01 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03252 for ; Tue, 17 Jul 2001 09:21:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MU3e-000FEb-00 for namedroppers-data@psg.com; Tue, 17 Jul 2001 05:34:34 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15MU3d-000FEV-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 05:34:33 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15MU3d-000IOX-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 08:34:33 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "Brian Zill" To: Cc: "Matt Crawford" , "Jun-ichiro itojun Hagino" , "David Terrell" Subject: RE: Proposed optimization to multicast DNS Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 17 Jul 2001 05:34:34 -0700 Content-Transfer-Encoding: 7bit As Itojun Hagino and Matt Crawford point out, Matt's ICMP name lookups draft (draft-ietf-ipngwg-icmp-name-lookups-07.txt) performs lookups using multicast addresses in essentially the same manner I proposed for mdns below. Even better, blatantly copying the details of Matt's solution resolves the open issues of which particular hash function and multicast prefix to use in forming the address (and also lessens the number of multicast addresses a node implementing both drafts need listen on). Also, Matt's solution addresses the issue raised by David Terrell (answer: lowercase the alphabetic characters before hashing). Thanks Matt. I've proposed this solution to the mdns draft authors. --Brian >-----Original Message----- >From: Brian Zill=20 >Sent: Wednesday, 11 July, 2001 22:52 >To: namedroppers@ops.ietf.org >Subject: Proposed optimization to multicast DNS > > >I'd like to propose the following optimization to the=20 >multicast DNS draft. It is only applicable to IPv6, since it=20 >takes advantage of the larger multicast address space=20 >available in IPv6. > >The current version of the draft=20 >(draft-ietf-dnsext-mdns-01.txt) uses a single well-known=20 >link-local multicast address for all queries. This causes all=20 >responders to perform some packet processing on each query,=20 >even though in most cases this processing is merely to=20 >determine that the packet should be dropped (i.e. the query=20 >isn't for a record belonging to that responder). > >This is an analogous situation to IP address resolution, where=20 >queries are sent to discover a node's link-layer address. In=20 >IPv4 over Ethernet, the ARP protocol uses broadcast packets=20 >(which is equivalent to using a single multicast address that=20 >everyone listens to). In IPv6, however, Neighbor Discovery=20 >uses a more efficient scheme where nodes listen on a multicast=20 >address that is derived from their IP address -- this is the=20 >"solicited node multicast address". By basing the address to=20 >query on the very thing that is being queried, only those=20 >nodes that can actually respond to that query are likely to=20 >ever receive the packet. > >I propose something similar for multicast DNS. All IPv6=20 >responders should listen to multicast queries on a "solicited=20 >name multicast address" instead of a single well-known=20 >multicast address. They derive their solicited name multicast=20 >address(es) by combining a 104-bit well-known link-local=20 >multicast prefix with the 24-bit result of a hash over the=20 >first portion of the name of the record(s) for which they are=20 >authoritative. Senders wishing to issue a query for a given=20 >record would first generate the solicited name multicast=20 >address corresponding to the record they wish to lookup. Then=20 >they would send the query to that address. Only those nodes=20 >listening to that particular multicast address would receive=20 >the packet, thus reducing significantly the amount of packet=20 >processing required by nodes participating in multicast DNS. > >Open issues: > >Size of multicast prefix and hash result. I chose 104 and 24,=20 >respectively, simply because those are the lengths used for=20 >solicited node multicast addresses. A smaller hash result=20 >would increase the likelihood of collisions, but the smaller=20 >address range might be more palatable to IANA. The choice of=20 >hash function might also figure in here. > >What hash function to use? Any half-way reasonable hash=20 >function would do, so it might be wise to use a hash function=20 >that all IPv6 implementations are required to have anyway. =20 >But MD5 and SHA-1 both seem a little overkill for this=20 >purpose. The internet checksum isn't great, and only yields=20 >16 bits, but the code is present everywhere. There are plenty=20 >of other possibilities. > >Comments? >--Brian > to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 17 09:23:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03458 for ; Tue, 17 Jul 2001 09:23:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MUGB-000Fgf-00 for namedroppers-data@psg.com; Tue, 17 Jul 2001 05:47:31 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15MUGA-000FgY-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 05:47:30 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15MUGA-000IQM-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 08:47:30 -0400 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org Subject: I-D ACTION:draft-ietf-dnsext-ecc-key-00.txt Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 17 Jul 2001 05:47:31 -0700 --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 : Elliptic Curve KEYs in the DNS Author(s) : R. Schroeppel, D. Eastlake Filename : draft-ietf-dnsext-ecc-key-00.txt Pages : 14 Date : 16-Jul-01 A standard method for storing elliptic curve cryptographic keys in the Domain Name System is described which utilizes DNS KEY resource record. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ecc-key-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-ecc-key-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-ecc-key-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: <20010716153028.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-ecc-key-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-ecc-key-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010716153028.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 17 09:23:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03466 for ; Tue, 17 Jul 2001 09:23:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MUG8-000FgW-00 for namedroppers-data@psg.com; Tue, 17 Jul 2001 05:47:28 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15MUG7-000FgC-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 05:47:28 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15MUG7-000IQK-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 08:47:27 -0400 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-intro-00.txt Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 17 Jul 2001 05:47:28 -0700 --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) : D. Massey, S. Rose Filename : draft-ietf-dnsext-dnssec-intro-00.txt Pages : 9 Date : 16-Jul-01 The Domain Name System Security Extensions (DNSSEC) provides data and origin authentication and integrity. This document introduces the new DNS extensions and describes the capabilities and limitations of DNS Security. The services that the security extensions provide and not provide are discusses. Lastly, the group of documents that describe the DNS security extensions and their inter-relationships is discussed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-intro-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-intro-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-intro-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: <20010716153018.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-intro-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-intro-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010716153018.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 17 09:23:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03470 for ; Tue, 17 Jul 2001 09:23:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MU78-000FL1-00 for namedroppers-data@psg.com; Tue, 17 Jul 2001 05:38:10 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15MU78-000FKv-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 05:38:10 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15MU77-000IPM-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 08:38:09 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Edward Lewis cc: namedroppers@ops.ietf.org Subject: Re: Question about TSIG, AD/AA, and AXFR In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 17 Jul 2001 05:38:10 -0700 Content-Transfer-Encoding: 7bit Date: Mon, 16 Jul 2001 16:43:44 -0700 From: Edward Lewis Message-ID: | I am wondering if there is an unreported protocol problem in the | combination of TSIG, AD/AA, and AXFR. This isn't protocol problem, it is operational. Using just the protocol you have no way to determine the source of the data for AXFR at all, only that it exists, and is being made available to you (and then the rules for making sense of it all of course). If you don't trust the server you're configured to obtain the data from to send you accurate data, then you should be getting it from elsewhere. All TSIG helps you do is rest assured that the data has truly been sent to you from the server you configured to send it. For anything more than this (knowing that the data is the correct data) you really need to be using dnssec, and verifying all those signatures. | DNS Security is supposed to be about protecting the resolver, But that's not what TSIG is about, I don't think (except when it is being used to enable secure communications between a stub resolver and a back end resolver/cache). TSIG is just the cheap mechanism to get data that is secured via some other means to a node that doesn't want to implement the full security model. If the data wasn't already known to be secure, there's nothing TSIG can possibly do to assist. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 17 09:41:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06142 for ; Tue, 17 Jul 2001 09:41:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MUca-000GWa-00 for namedroppers-data@psg.com; Tue, 17 Jul 2001 06:10:40 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15MUcZ-000GWN-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 06:10:39 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15MUcZ-000ISA-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 09:10:39 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "Scott Rose" To: Cc: Subject: Re: Question about TSIG, AD/AA, and AXFR References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 17 Jul 2001 06:10:40 -0700 Content-Transfer-Encoding: 7bit Good question - I don't think there is any way (using the current DNSSEC spec) for a stub resolver to know that the secondary is using a secure AXFR other than knowing the policy out-of-band. One possible solution would be to include a SIG generated by the primary host along with the data (over the SOA). This would be in addition to the zone key SIG and only included when a secure AXFR is used. However, then the SIG must be verified by contacting the primary host (so we loose some of the benefits of having secondaries since resolvers are still contacting the primary). As Brian said - it may not be that big of an issue. Any malicious alterations of zone data during a transfer will be noticed if the zone is secured. If it is unsecured to begin with, there are multiple points of attack to worry about. Is this a big enough problem to justify adding to the spec? I'm not so sure. > I am wondering if there is an unreported protocol problem in the > combination of TSIG, AD/AA, and AXFR. My concern is that a resolver may > over trust an answer that has come TSIG-protected from a secondary who used > an unsecured AXFR to get its zone data. > > Here is the case-by-case breakdown that led me to this concern. Assuming a > "stub" resolver - one that will rely on query/response security and is not > able/willing to do full chain processing, and only looking at TSIG-covered > answers: > > Case TSIG AD AA Server-type > 1 Y 0 1 Primary "From disk," so it can be trusted > 2 Y 0 1 Secondary Via AXFR, trustworthy only if AXFR is secure > 3 Y 1 0 Non-auth Server validated the chain > 4 Y 1 1 anything Not possible as far as I can tell > > DNS Security is supposed to be about protecting the resolver, and here we > have a case (#2) where the resolver can't be sure of an answer's security. > It is fine to recommend that zone transfers use TSIG, but then you're > putting discretion in the hands of the zone and not the resolver. (Not to > mention that TSIG isn't the only way to secure an AXFR.) > > Can there be some way to indicate that a secondary has used a secure means > to acquire the zone data? (Yeah, "can there be some way to indicate that a > *primary* has used a secure means to acquire the zone data?" is the first > rebuttal. But we know that a secondary had to get its data from some other > machine, so I think this asking about a secondary's source is valid.) to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 17 10:47:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20960 for ; Tue, 17 Jul 2001 10:47:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MVFO-000I03-00 for namedroppers-data@psg.com; Tue, 17 Jul 2001 06:50:46 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15MVFN-000Hzx-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 06:50:45 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15MVFN-0000D7-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 09:50:45 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Edward Lewis To: Jakob Schlyter Cc: Edward Lewis , Subject: Re: Question about TSIG, AD/AA, and AXFR In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 17 Jul 2001 06:50:46 -0700 Content-Transfer-Encoding: 7bit It is true DNSSEC can't guarantee that data is correct nor correctly handled, but at least it will help point out where the fault is. Perhaps I've been assuming "trustworthy" with being able to trace the data back to the (appropriate) source. >From you message it sounds like no one should trust data with the AA bit, as this means the authentication has not been checked. This is an ironic conclusion, as we've been assigning more credibility to AA'd data. (Once again, the credibility vs. authenticated issue arises.) At 3:31 AM -0400 7/17/01, Jakob Schlyter wrote: >On Mon, 16 Jul 2001, Edward Lewis wrote: > >> Case TSIG AD AA Server-type >> 1 Y 0 1 Primary "From disk," so it can be trusted >> 2 Y 0 1 Secondary Via AXFR, trustworthy only if AXFR is secure > >why can the data be trusted just because the server read it from disk or >safely AXFRed? a lot of bad things could have happen to the data between >signing och loading, especially if you're doing off-line signing. > > - the signatures could have expired > - the signatures could not be valid yet > - someone could maliciously have inserted or altered data > - data could be corrupted by other means > > > jakob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com You fly too often when ... the airport taxi is on speed-dial. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 17 10:55:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22891 for ; Tue, 17 Jul 2001 10:55:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MVFG-000Hzo-00 for namedroppers-data@psg.com; Tue, 17 Jul 2001 06:50:38 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15MVFG-000Hzi-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 06:50:38 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15MVFF-0000D5-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 09:50:37 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Edward Lewis To: Brian Wellington Cc: Edward Lewis , Subject: Re: Question about TSIG, AD/AA, and AXFR In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 17 Jul 2001 06:50:38 -0700 Content-Transfer-Encoding: 7bit At 12:40 AM -0400 7/17/01, Brian Wellington wrote: >Are you talking about the stub resolver directly contacting a secondary? >It should be going through a recursive server, and the recursive server >will validate the data. If the data on the secondary has been corrupted >or maliciously altered, the recursive server will fail to verify it. Yeah. I am assuming that the "client" in this case isn't able to establish a chain of trust (no code to do so or at least no configured key). Perhaps the "secondary" is also the "default/recursive" server for the client, or that the client has a configured relationship with the authoritative servers. >About the worst can happen is that the secondary can serve data that's no >longer in the zone but still valid, but the same thing can happen with any >caching server. If the client (I'll use that term) is relying on TSIG, they aren't likely to do signature validation. (Perhaps we should recommend that TSIG queries be issued with the DNSSEC indication off.) There is also the push to adopt TSIG ahead of signing zones. I can see a lot of zones using TSIG in limited runs well ahead of signing the zone - as folks first see the benefit of TSIG, then see how hard it is to manage secerts, and then discover the benefit of scaleable but more intensive public key efforts. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com You fly too often when ... the airport taxi is on speed-dial. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 17 11:02:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24497 for ; Tue, 17 Jul 2001 11:02:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MWBQ-000JzG-00 for namedroppers-data@psg.com; Tue, 17 Jul 2001 07:50:44 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15MWBQ-000Jz8-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 07:50:44 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15MWBP-0000Ew-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 10:50:43 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roy Arends To: Edward Lewis Cc: Subject: Re: Question about TSIG, AD/AA, and AXFR In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 17 Jul 2001 07:50:44 -0700 Content-Transfer-Encoding: 7bit On Mon, 16 Jul 2001, Edward Lewis wrote: > I am wondering if there is an unreported protocol problem in the > combination of TSIG, AD/AA, and AXFR. My concern is that a resolver may > over trust an answer that has come TSIG-protected from a secondary who used > an unsecured AXFR to get its zone data. > > Here is the case-by-case breakdown that led me to this concern. Assuming a > "stub" resolver - one that will rely on query/response security and is not > able/willing to do full chain processing, and only looking at TSIG-covered > answers: > > Case TSIG AD AA Server-type > 1 Y 0 1 Primary "From disk," so it can be trusted > 2 Y 0 1 Secondary Via AXFR, trustworthy only if AXFR is secure > 3 Y 1 0 Non-auth Server validated the chain > 4 Y 1 1 anything Not possible as far as I can tell > > DNS Security is supposed to be about protecting the resolver, and here we > have a case (#2) where the resolver can't be sure of an answer's security. > It is fine to recommend that zone transfers use TSIG, but then you're > putting discretion in the hands of the zone and not the resolver. (Not to > mention that TSIG isn't the only way to secure an AXFR.) > > Can there be some way to indicate that a secondary has used a secure means > to acquire the zone data? (Yeah, "can there be some way to indicate that a > *primary* has used a secure means to acquire the zone data?" is the first > rebuttal. But we know that a secondary had to get its data from some other > machine, so I think this asking about a secondary's source is valid.) WRT axfr-clarify-02, situations 3 and 4 will not occur. The problem is when some caching forwarder is also authoritative for a local domain. Say that local domain is secured and applications using a stub resolver (which forwards all to the local cache) depend on the AD bit. The AD bit will never be set on responses containing local domain data, since the queried server will never (!!!) check it. If a server is willing to verify chains, why not verify the localy configured data that happens to be in the chain, either verify data when queried for it, or verify the data on accepting it (during disk-read, axfr or caching). Ofcourse having an authoritative and cache server in one might be not a good setup, it is not strictly forbidden by a MUST NOT in any RFC. What I'm actually saying is that there _is_ some indication that a secondary trusts the transferred secure zone, by simply verifying the received info, and set the AD bit on every query-response containing this info. In that, an axfr-response is just like any query-response in that the response contents must be verified if possible. 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. From owner-namedroppers@ops.ietf.org Tue Jul 17 11:15:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27642 for ; Tue, 17 Jul 2001 11:15:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MW9q-000Jvg-00 for namedroppers-data@psg.com; Tue, 17 Jul 2001 07:49:06 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15MW9p-000JvZ-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 07:49:06 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15MW9p-0000Et-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 10:49:05 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Matt Crawford To: Brian Zill Cc: namedroppers@ops.ietf.org, Jun-ichiro itojun Hagino , David Terrell Subject: Re: Proposed optimization to multicast DNS In-reply-to: "17 Jul 2001 00:15:46 PDT." Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 17 Jul 2001 07:49:06 -0700 Content-Transfer-Encoding: 7bit listen on). Also, Matt's solution addresses the issue raised by David Terrell (answer: lowercase the alphabetic characters before hashing). More precisely, convert to canonical form as defined by DNSSEC ... When the Subject is a domain name, either fully-qualified or single-component, and the Querier does not have a unicast address for the target node, the query MUST be sent to a link-scope multicast address formed in the following way. The Subject Name is converted to canonical form, as defined by DNS Security [2535], which is uncompressed with all alphabetic characters in lower case. (If additional DNS label types for host names are defined, the rules for canonicalizing those labels will be found in the defining specification.) Compute the MD5 hash [1321] of the first label of the Subject Name -- the portion beginning with the first one-octet length field and up to, but excluding, any subsequent length field. Append the first 32 bits of that 128-bit hash to the prefix FF02:0:0:0:0:2::/96. The resulting multicast address will be termed the "NI Group Address" for the 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. From owner-namedroppers@ops.ietf.org Tue Jul 17 11:25:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29601 for ; Tue, 17 Jul 2001 11:25:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MWYo-000KrV-00 for namedroppers-data@psg.com; Tue, 17 Jul 2001 08:14:54 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15MWYm-000KrM-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 08:14:53 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15MWYm-0000Fd-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 11:14:52 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Edward Lewis To: Roy Arends Cc: Edward Lewis , Brian Wellington , Subject: Re: Question about TSIG, AD/AA, and AXFR In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 17 Jul 2001 08:14:54 -0700 Content-Transfer-Encoding: 7bit If you are doing the chain validation, your queries should be issued with no TSIG and the CD flag on, if you really want to optimize performance (in the "good" case[0]). [0] Meaning - optimizing for the situation when there is no attack on. If you are being flooded with maliciously inserted answers, then, yes, TSIG is a good thing. At 10:29 AM -0400 7/17/01, Roy Arends wrote: >On Tue, 17 Jul 2001, Edward Lewis wrote: > >> (Perhaps we should recommend that TSIG queries be issued with the >> DNSSEC indication off.) > >I think this is not a good idea. > >Since TSIG is server authentication (origin), DNSSEC is zone >authentication (content) we could have the following situation: > >Say there is some application that wants to verify signatures itself (SSH >KEY + SIG(KEY)), using the stub-resolver for queries, which is configured >to TSIG all data from the caching forwarder. No DNSSEC response will then >be received at the stub since the stub uses TSIG and the DO bit unset in >your scenario. > >Roy Arends >Nominum -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com You fly too often when ... the airport taxi is on speed-dial. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 17 11:38:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02621 for ; Tue, 17 Jul 2001 11:38:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MWYJ-000KpX-00 for namedroppers-data@psg.com; Tue, 17 Jul 2001 08:14:23 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15MWYJ-000KpQ-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 08:14:23 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15MWYI-0000FZ-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 11:14:22 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roy Arends To: Edward Lewis Cc: Brian Wellington , Subject: Re: Question about TSIG, AD/AA, and AXFR In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 17 Jul 2001 08:14:23 -0700 Content-Transfer-Encoding: 7bit On Tue, 17 Jul 2001, Edward Lewis wrote: > (Perhaps we should recommend that TSIG queries be issued with the > DNSSEC indication off.) I think this is not a good idea. Since TSIG is server authentication (origin), DNSSEC is zone authentication (content) we could have the following situation: Say there is some application that wants to verify signatures itself (SSH KEY + SIG(KEY)), using the stub-resolver for queries, which is configured to TSIG all data from the caching forwarder. No DNSSEC response will then be received at the stub since the stub uses TSIG and the DO bit unset in your scenario. Roy Arends Nominum to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 17 11:38:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02636 for ; Tue, 17 Jul 2001 11:38:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MWYY-000KrF-00 for namedroppers-data@psg.com; Tue, 17 Jul 2001 08:14:38 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15MWYX-000Kr9-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 08:14:38 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15MWYX-0000Fb-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 11:14:37 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Edward Lewis To: Roy Arends Cc: Edward Lewis , Subject: Re: Question about TSIG, AD/AA, and AXFR In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 17 Jul 2001 08:14:38 -0700 Content-Transfer-Encoding: 7bit At 10:12 AM -0400 7/17/01, Roy Arends wrote: >WRT axfr-clarify-02, situations 3 and 4 will not occur. Case 3 will occur - that's the "nominal case." By "non-auth" I meant to imply a recursive server that isn't authoritative for the answer. >The problem is when some caching forwarder is also authoritative for a >local domain. Say that local domain is secured and applications using a >stub resolver (which forwards all to the local cache) depend on the AD >bit. The AD bit will never be set on responses containing local domain >data, since the queried server will never (!!!) check it. I think that relying on the AD bit alone is not sufficient. A true resolver should have logic that accepts AD or AA bit with TSIG as "as good as I'm gonna get." (This is why I want to know that the AXFR [if any] wasn't vulnerable to a simple attack.) >If a server is willing to verify chains, why not verify the localy >configured data that happens to be in the chain, either verify data when >queried for it, or verify the data on accepting it (during disk-read, >axfr or caching). The arguement against this is the time it takes. But I would like to have the option in some "strict policy" applications. >Ofcourse having an authoritative and cache server in one might be not a >good setup, it is not strictly forbidden by a MUST NOT in any RFC. I wouldn't jump on the no-recursive on an authoritative bandwagon. I think it is reasonable to be authortitative and recurse for just the local stubs (whether by physical interface or key). Heck, I'd even be willing to acl via (untrustworty) IP address in this instance. >What I'm actually saying is that there _is_ some indication that a >secondary trusts the transferred secure zone, by simply verifying the >received info, and set the AD bit on every query-response containing this >info. In that, an axfr-response is just like any query-response in that >the response contents must be verified if possible. I couldn't see .com's zone transfers working this way, but perhaps super-secret.mil's transfers would like this. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com You fly too often when ... the airport taxi is on speed-dial. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 17 12:22:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13328 for ; Tue, 17 Jul 2001 12:22:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MXLs-000Mrv-00 for namedroppers-data@psg.com; Tue, 17 Jul 2001 09:05:36 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15MXLr-000Mrp-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 09:05:35 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15MXLq-0000HJ-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 12:05:34 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Bernard Aboba To: namedroppers@ops.ietf.org cc: aboba@internaut.com, bernarda@microsoft.com Subject: Proposed changes to mDNS -02 draft Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 17 Jul 2001 09:05:36 -0700 Content-Transfer-Encoding: 7bit Proposed changes to draft-ietf-dnsext-mdns-02.txt (and comment disposition from previous revisions) --------------------------------------------------------------- Section 2.1.3: Submitted by: Brian Zill Justification: Use of the solicited node multicast addresses for mDNS in IPv6 would reduce the multicast traffic handled by=20 any particular node.=20 Change: "Namely, this extension allows multicast DNS queries to be sent to and received on port 53 using the LINKLOCAL addresses [2] for IPv4 and IPv6 (below referred as the LINKLOCAL address), which are yet to be assigned by IANA." To: "This extension allows multicast DNS queries to be sent to and=20 received on port 53 using a LINKLOCAL address [2] for IPv4 and the "solicited node" LINKLOCAL multicast addresses for IPv6. The IPv6 LINKLOCAL address a given responder listens to, and to which=20 a sender sends, is a link-local multicast address formed as follows:=20 The name of the resource record in question is expressed in its canonical f= orm=20 (see RFC 2535, section 8.1), which is uncompressed with all alphabetic char= acters=20 in lower case. The first label of the resource record name is then hashed = using=20 the MD5 algorithm (see RFC 1321). The first 32 bits of the resultant 128-b= it hash=20 is then appended to the prefix FF02:0:0:0:0:2::/96 to yield the 128-bit=20 "solicited name multicast address". (Note: this procedure is intended to b= e the=20 same as that specified in section 3 of [x]) A responder that listens for q= ueries=20 for multiple names will necessarily listen to multiple of these solicited n= ame=20 multicast addresses. [x] Crawford, Matt, "IPv6 Node Information Queries", Internet draft (work in progress), draft-ietf-ipngwg-icmp-name-lookups-07.txt, August 2000. Proposed resolution: accept =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Changes to mDNS -01: -------------------------------------------------------------------- Section 5.1 and 5.2 Submitted by: Dave Thaler Justification: current text is unclear about API issues Modify text starting near end of 5.1 as follows: =2E.. Therefore it will continue using its name. Indeed, host myhost cannot=20 distinguish between the situation shown in Figure 2, and that=20 shown in Figure 3 where no conflict exists. [A] | | ----- ----- | | =20 [myhost]=20 Figure 3. Multiple paths to same host This illustrates that the proposed name conflict resolution mechanism does not support detection or resolution of conflicts between hosts on=20 different subnets. This problem ... (rest of 5.1 from change doc) 5.2 Alternatives for solving the multihomed name ambiguity problem RFC 2553 [RFC 2553] provides an API which can partially solve the name=20 ambiguity problem for applications written to use this API, since the=20 sockaddr_in6 structure exposes the scope within which each scoped=20 address exists, and this structure can be used for both IPv4 (using=20 v4-mapped IPv6 addresses) and IPv6 addresses. Following the example in Figure 2, an application on 'myhost' issues the request getaddrinfo("A", ...) with ai_family=3DAF_INET6 and ai_flags=3DAI_ALL|AI_V4MAPPED. mDNS requests will be sent from both=20 interfaces and the resolver library will return a list containing multiple addrinfo structures, each with an associated sockaddr_in6=20 structure. This list will thus contain the IPv4 and IPv6 addresses=20 of both hosts responding to the name 'A'. Link-local addresses will=20 have a sin6_scope_id value that disambiguates which interface is used=20 to reach the address. Of course, to the application, Figures 2 and 3 are still indistinguishable, but this API allows the application to communicate successfully with any address in the list. Resolution: Accept Change reflected in mDNS -02 draft. ---------------------------------------------------------------------- Section 5.2 Submitted by: Erik Guttman Add the following section: "5.2 Alternatives for solving the multihomed name ambiguity problem Unfortunately, simple solutions to this problem do not exist.=20 Existing APIs for name resolution and communicating between hosts via the socket interface do not expose which interface information pertains to. [S] Following the example in Figure 2, if an application on 'myhost' issues the request gethostbyname("A"). mDNS requests will be sent from both interfaces and the resolver library will return a=20 struct hostent data structure: struct hostent { char *h_name; /* canonical name of host */ char **h_aliases; /* alias list */ int h_addrtype; /* host address type */ int h_length; /* length of address */ char **h_addr_list; /* list of addresses */ }; This will include the addresses for both hosts responding to the name 'A'. There is no way to determine or influence which interface was=20 used to retrieve which address, given the above interface. There are some non-solutions to the ambiguous name problem: - disallowing multihomed hosts to use mDNS on more than one interface = =20 - suggesting multihomed hosts to elect to act as IP bridges =20 - suggesting multihomed hosts behave as routers to pass mDNS While a multihomed host could function as a bridge or router, this=20 should be a configured behavior and has profound implications on network topology. Forwarding packets should not be done simply to address a link-local protocol limitation. Avoiding the use of mDNS=20 on more than one interface of multihomed devices does, however,=20 dissolve the problem: One cure for double vision is removing the=20 second eye. There are three possible solutions to the ambigious name problem: Approach Solution Assessment Do not consider Applications could This 'breaks' DNS. ambiguity a problem. come to expect that It removes the names may be ambiguous. proper correspondence They would have to of a domain name=20 establish application with a RR set from layer naming mechanisms. an application's=20 perspective. Resolve the problem. Enhance mDNS to include This would require additional messages so mDNS to deviate from multihomed hosts can DNS. This entails hosts of conflicting further standards names. development. =20 The mDNS protocol specification already allows for 'gratuitous reply messages' (see Section 5). It is not that much further to go to specify behavior by which a multihomed host could send gratuitous reply messages on behalf of mDNS servers on distinct links to which the host is attached. This would entail changing the conflict resolution algorithm and has profound security implications. Cope with the problem. This can only be done by This fails to=20 creating new APIs and support existing new application software apps and requires to make use of them. a substantial API standardization effort. New APIs for name resolution would return the interface associated=20 with the each item in the result. Applications would have to use=20 socket (XTI, etc.) interfaces to explicitly select which interfaces=20 to use for communication. From the perspective of a multihomed host=20 neither names nor addresses are guaranteed to be unique, though the=20 tuple {interface,name} and {interface,address} will be unique." Resolution: Reject. Behavior in this circumstance is=20 largely implementation dependent, so we don't need to analyze it in detail. API text contradicts text submitted by Dave Thaler, accepted as indicated above.=20 -------------------------------------------------------------------- Operational recommendations Submitted by: Erik Guttman, Levon Esibov, Robert Elz Justification: Need section (or separate BCP document) on operational recommendations.=20 Add the following section (or include this in a separate draft): X.0 Operational Recommendations X.1 Recommendations to IANA concerning the operation of the ARPA subdomain: DNS servers SHOULD NOT forward queries for domain names in the local.arpa domain - if the server cannot answer the query from its own database, it should reply with a non-authoritative NXDOMAIN. X.2 Recommendations concerning the operation of the protocol object regis= try There are no protocol object registry requirements implied by the=20 'local.arpa' namespace. This 'arpa' sub-domain exists to support=20 locally administered resources. These resources are not protocol=20 objects per se, unlike for example, PTR RRs in 'in-addr.arpa'.=20 The resources constitute arbitrary DNS RRs served by mDNS servers themselves. Proposed resolution: Accept (within a separate BCP document) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Changes to draft-ietf-dnsext-mdns-00.txt ------------------------------------------------------------------------ Section 1 Submitted by: Erik Guttman, Dave Thaler Justification: existing language does not specify possible limitations of the current approach.=20 Change: " This extension to the DNS protocol consists of a single change to the method of use, and no change to the current format of DNS packets. Namely, this extension allows multicast DNS queries to be sent to and received on port 53 using the LINKLOCAL addresses [2] for IPv4 and IPv6 (below referred as the LINKLOCAL address), which are yet to be assigned by IANA. LINKLOCAL addresses are used to prevent propagation of multicast DNS traffic across routers, potentially flooding the network. Propagation of multicast DNS packets within the local subnet is considered sufficient to enable DNS name resolution, since the expectation is that if a network has a router, then this router can function as a DNS proxy, possibly implementing dynamic DNS. Thus there is not expected to be a need for multicast DNS in networks with multiple subnets." to: " This extension to the DNS protocol consists of a single change to the method of use, and no change to the current format of DNS packets. Namely, this extension allows multicast DNS queries to be sent to and received on port 53. The messages are sent using the LINKLOCAL addresses [2] for IPv4 and IPv6 (below referred as the LINKLOCAL address), which are yet to be assigned by IANA. LINKLOCAL addresses are used to prevent propagation of multicast DNS traffic across routers, potentially flooding the network. Propagation of multicast DNS packets within the local subnet is=20 considered sufficient to enable DNS name resolution in small adhoc networks. The assumption is that if a network has a router,=20 then the network either has a DNS server or the router can function=20 as a DNS proxy, possibly implementing dynamic DNS.=20 In the future, mDNS may be defined to support greater than LINKLOCAL=20 multicast scope. This would occur if LINKLOCAL mDNS deployment is=20 successful, the assumption that mDNS is not needed in multiple=20 subnets proves incorrect, and multicast routing becomes ubiquitous. For example, it is not clear that this assumption will be valid in large adhoc networking scenarios.=20 Once we have experience in mDNS deployment=20 in terms of administrative issues, usability and impact on the network it will be possible reevaluate which multicast scopes are appropriate for use with mDNS." Resolution: Accept Change reflected in -01 draft. ---------------------------------------------------------------- Submitted by: Erik Guttman, Dave Thaler, Robert Elz Justification: Current language does not fully specify retransmission behavior.=20 "If the multicast query is not positively resolved ("positively resolved" refers in this document to a response with the RCODE set to 0) during a limited amount of time, then a sender MAY repeat the transmission of a query in order to assure themselves that the query has been received by a host capable of responding to the query. Repetition MUST NOT be attempted more than 5 times, and the repetition SHOULD NOT be repeated more often than once per 0.1 seconds to reduce unnecessary network traffic. Retry intervals SHOULD be exponentially increased." Change to: "If the multicast query is not positively resolved ("positively resolved" refers in this document to a response with the RCODE set to 0) during a limited amount of time, then a sender MAY repeat the transmission of a query in order to assure themselves that the query has been received by a host capable of responding to the query.=20 Repetition MUST NOT be attempted more than 3 times and SHOULD NOT be repeated more often than once per second to reduce unnecessary network traffic. The delay between attempts should be randomised=20 so as to avoid synchronisation effects."=20 Resolution: Accept Change incorporated in -01 draft ---------------------------------------------------------------- Section 2.1 Submitted by: Erik Guttman, Levon Esibov Justification: Error reply implosion possible with current text. To the following paragraph: "A response to a multicast query is composed in exactly the same manner as a response to the unicast DNS query as specified in [4]. Responders MUST never respond using cached data, and the AA (Authoritative Answer) bit MUST be set. The response is sent to the sender via unicast." add: "A response to an mDNS query MUST have RCODE set to zero, since=20 mDNS responders MUST NOT send error replies in response to=20 multicast requests." Resolution: Accept Change reflected in -01 draft. ------------------------------------------------------------------------ Submitted by: Dave Thaler Justification: Current text does not address the API issues involved with setting and checking of TTL.=20 "The responder MUST set the Hop Limit field in the IPv6 header and the TTL field in IPv4 header of all multicast DNS query responses to 255. The sender MUST verify that the Hop Limit field in the IPv6 header and the TTL field in the IPv4 header of each response to the multicast DNS query is set to 255. If it is not, then the sender MUST ignore such a response." Change to: "For IPv4 LINKLOCAL addressing, section 2.4 of [6] lays out the rules with respect to source address selection, TTL settings, and acceptable source/destination address combinations. IPv6 LINKLOCAL addressing is described in [9]. mDNS queries and responses MUST obey the rules laid out in these documents. In composing an mDNS response, the responder MUST set the Hop Limit field in the IPv6 header and the TTL field in IPv4 header of the multicast DNS response to 255. The sender MUST verify that the Hop Limit field in IPv6 header and TTL field in IPv4 header of each response to the multicast DNS query is set to 255. If it is not, then sender MUST ignore the response. Implementation note: In the sockets API for IPv4, the IP_TTL and IP_MULTICAST_TTL socket options are used to specify the TTL of outgoing unicast and multicast packets. The IP_RECVTTL socket option is available on some platforms to receive the IPv4 TTL of received packets with recvmsg(). RFC 2292 specifies similar options for specifying and receiving the IPv6 Hop Limit. " Resolution: Accept Change reflected in 01 draft.=20 Note from Dave: BTW, the IP_RECVTTL option seems to exist currently in Linux but not in BSD. Don't know about any other OSess. There's nothing referencable that I can find, but anyone who does a search on the web for it can easily find the Linux man page that covers it. ------------------------------------------------------------------------ Submitted by: Erik Guttman Justification: Specification of the cache period is unnecessary. Change: "If no positive response is received, a resolver treats it as a response that no records of the specified type and class for the specified name exist (NXRRSET), which SHOULD be cached for a period that SHOULD NOT exceed 5 seconds." To: "If no positive response is received, a resolver treats it as a response that no records of the specified type and class for the specified name exist (NXRRSET)." Resolution: Accept Change reflected in -01 draft ------------------------------------------------------------------------- Section 3 Submitted by: Bernard Aboba Justification: current text is confusing and contradictory In the paragraph: "If a DNS server is running on a host, the host MUST NOT listen for multicast DNS queries, to prevent the host from listening on port 53 and intercepting DNS queries directed to a DNS server. A DNS server MAY listen and respond to multicast queries. By default, a DNS server MUST NOT listen to multicast DNS queries. For a DNS server, the presence of ".local.arpa." in the domain search list MUST NOT enable multicast DNS." Remove the sentence: "A DNS server MAY listen and respond to multicast queries."=20 Resolution: Accept Change reflected in 01 draft. -------------------------------------------------------------------- Section 4 Submitted by: Bernard Aboba Justification: Current text does not cover addressing limitations. "3. Upon the reception of the response, the sender verifies that the Hop Limit field in IPv6 header or TTL field in IPv4 header (depending on the protocol used) of the response is set to 255.=20 Change to: 3. Upon the reception of the response, the sender verifies that the Hop Limit field in IPv6 header or TTL field in IPv4 header (depending on the protocol used) of the response is set to 255. If the destination address is a LINKLOCAL address, then the sender verifies use of a=20 LINKLOCAL source address. If these conditions are met, then the sender= =20 uses and caches the returned response. If not, then the sender ignores= =20 the response and continues waiting for the response.=20 Resolution: Accept Change reflected in 01 draft ------------------------------------------------------------------- Section 5 Submitted by : Levon Esibov Justification: Use of dynamic update for conflict detection is a cleaner approach.=20 Change: "The uniqueness of the host DNS name MUST be verified when a host boots, when its name is changed, or when it is configured to use multicast DNS (such as when the domain search option is changed to include ".local.arpa."). A gratuitous name resolution query SHOULD be done to check for a name conflict. This is done by having the resolver send a multicast query of type SOA for its own name (i.e. for the name it is authoritative for). If the query is not positively resolved then the host assumes authority for the name. If the query is positively resolved, then the host should verify that the name specified in the RDATA of the SOA record in the answer section of the response is its own host name. If the host verifies this, then it assumes authority for its name. If the returned name does not match its host name, then a conflict has been detected. In order to resolve the name conflict, the host will change its name. A host that has detected a name conflict MUST NOT use the name. This means that the host MUST NOT respond to multicast queries for that name and MUST NOT respond to other multicast queries with resource records within the RDATA field that contain the conflicted name (for example, the PTR record). Note that this name conflict detection mechanism doesn't prevent name conflicts when previously partitioned segments are connected by a bridge. In such a situation, name conflicts are detected when a sender receives more than one response to its multicast DNS query. In this case, the sender sends the first response that it received to all responders that responded to this query except the first one, using unicast. A host that receives a response to a query for its own name, even if it didn't send such a query, sends a multicast query for the SOA record of the name that it is authoritative for. Based on the response, the host detects the name conflict and acts according to the description above." To: "There are some scenarios when multiple responders MAY respond to the same= =20 query. There are other scenarios when only one responder may respond to a= =20 query. Resource records for which the latter queries are submitted are=20 referred as UNIQUE throughout this document. The uniqueness of a resource= =20 record depends on a nature of the name in the query and type of the query. = For=20 example it is expected that - multiple hosts may respond to a query for a SRV type record=20 - multiple hosts may respond to a query for an A type record for a cluster= =20 name (assigned to multiple hosts in the cluster)=20 - only a single host may respond to a query for an A type record for a=20 hostname.=20 Every responder that responds to a multicast DNS query and/or dynamic updat= e=20 request AND includes a UNIQUE record in the response MUST: 1. Verify that there is no other host within the scope of the multicast DNS= =20 query propagation that can return a DNS record for the same name, type and= =20 class.=20 2. Responders MUST NOT include a UNIQUE resource record in the=20 response without having verified its uniqueness.=20 Where a host is configured to respond to multicast DNS queries on more=20 than one interface, the host MUST verify resource record uniqueness on=20 each interface for each UNIQUE resource record that could be used on that= =20 interface. To accomplish this, the host MUST multicast a dynamic DNS update request as specified in RFC 2136 [RFC 2136] for each new UNIQUE= =20 resource record. Uniqueness verification is carried out when the host:=20 - host starts up or=20 - is configured to respond to the multicast DNS queries on some interface= or=20 - is configured to respond to the multicast DNS queries using additional= =20 UNIQUE DNS records.=20 Below we describe the data to be specified in the dynamic update request=20 sections.=20 Header section: contains values according to [RFC 2136].=20 Zone Section=20 The zone name in the zone section MUST be set to the name of the UNIQUE= =20 record.=20 The zone type in the zone section MUST be set to SOA.=20 The zone class in the zone section MUST be set to the class of the UNIQ= UE=20 record.=20 Prerequisite Section=20 This section MUST contain a record set whose semantics are described in= =20 RFC 2136, Section 2.4.3 =93RRset Does Not Exist=94 of [RFC 2136] requesting= that=20 no RRs with a NAME and TYPE of the UNIQUE record can exist. Update Section=20 This section MUST be left empty.=20 Additional Section=20 This section is set according to RFC 2136.=20 When a host that owns a UNIQUE record receives a dynamic=20 update request that requests that the UNIQUE resource record set does=20 not exist, the host MUST respond via unicast with the YXRRSET error,=20 according to the rules described in Section 3 of RFC 2136 [RFC 2136].=20 After client receives an YXRRSET response to its dynamic update request tha= t a=20 UNIQUE resource record does not exist, the host MUST not use the UNIQUE=20 resource record in responses to multicast queries and dynamic update reques= ts. Note that this name conflict detection mechanism doesn't prevent name=20 conflicts when previously partitioned segments are connected by a=20 bridge. In such a situation, name conflicts are detected when a sender=20 receives more than one response to its multicast DNS query. In this=20 case, the sender sends the first response that it received to all=20 responders that responded to this query except the first one, using=20 unicast. A host that receives a query response containing a UNIQUE=20 resource record that it owns, even if it didn't send=20 such a query, MUST verify that no other host within the multicast DNS scope= is=20 authoritative for the same name, using the dynamic DNS update=20 request mechanism described above.=20 Based on the result, the host detects whether there is a name conflict and= =20 acts as described above."=20 Resolution: Accept Change reflected in 01 draft. --------------------------------------------------------------------- Section 5.1 Submitted by: Bernard Aboba Justification: Need additional text addressing name conflict scenarios in multihomed hosts Add the following section: "5.1. Considerations for Multiple Interfaces A multi-homed host may elect to configure multicast DNS on only one of its active interfaces. In many situations this will be adequate. However, should a host wish to configure multicast DNS on more than one of its active interfaces, there are some additional precautions it MUST take. Implementers who are not planning to support multicast DNS on multiple interfaces simultaneously may skip this section. A multi-homed host checks the uniqueness of UNIQUE records as described in Section 5.=20 The situation is illustrated in figure 1 below: ---------- ---------- | | | | [A] [myhost] [myhost] Figure 1. Linklocal name conflict In this situation, the multi-homed myhost will probe for, and defend, its host name on both interfaces. A conflict will be detected on one interface, but not the other, and as a result, the multi-homed myhost will not be able to respond with a host RR for "myhost".=20 Since names are only unique per-link, hosts on different links could be using the same name. If an mDNS client sends requests over multiple=20 interfaces, and receives replies from more than one, the result returned=20 to the client is defined by the implementation. The situation is illustrated in figure 2 below. ---------- ---------- | | | | [A] [myhost] [A] Figure 2. Off-segment name conflict If host myhost is configured to use mDNS on both interfaces, it will send mDNS queries on both interfaces. When host myhost sends a query for the host RR for name "A"=20 it will receive a response from hosts on both interfaces.=20 Host myhost will then forward a response from the first responder to the second responder, who will attempt to verify the uniqueness of host RR for its name, but will not discover a conflict, since the conflicting host resides on a different subnet. Therefore it will continue using its name.=20 This illustrates that the proposed name conflict resolution mechanism does not support resolution of conflicts between hosts on different subnets. This problem can also occur with unicast DNS=20 when a multi-homed host is connected to two different networks with separated name spaces. It is not the=20 intent of this document to address the issue of uniqueness of names within DNS." Resolution: Accept Change reflected in 01 draft. --------------------------------------------------------------------------- Section 7 Submitted by: Bernard Aboba Justification: Addressing limitations should be discussed. Change: "In all received packets, the Hop Limit field in IPv6 and the TTL field in IPv4 is verified to contain 255, the maximum legal value." To: "In all received responses, the Hop Limit field in IPv6 and the TTL field in IPv4 are verified to contain 255, the maximum legal value.=20 Since routers decrement the Hop Limit on all packets they forward, received packets containing a Hop Limit of 255 must have originated from a neighbor. Packets destined for a LINKLOCAL address are=20 verified to have been sent from a LINKLOCAL source address."=20 Resolution: Accept Change reflected in 01 draft. --------------------------------------------------------------------- References Submitted by: Erik Gutttman Justification: Current spec does not cite these documents, which are relevant. Add: [A] Huston, G., "Management Guidelines & Operational Requirements for the Internet Infrastructure Domain ("ARPA")", draft-iab-arpa-02.txt,=20 May 2001, A work in progress. [S] Stevens, W. R., "Unix Network Programming, Networking APIs: Sockets= =20 and XTI", Prentice Hall, Upper Saddle River, NJ, USA, 1998. Resolution: accept Change reflected in 01 draft. ---------------------------------------------------------------------- Section 6 Submitted by: Erik Guttman, Robert Elz Justification: ARPA guidelines section is required.=20 Add the following text: " This document specifies the use of a new sub-domain of the "ARPA"=20 domain. According to Section 2.1 of the ARPA Guidelines [A], this specification requires description and justification. The 'local.arpa' domain is used to distinguish a local namespace. This namespace differs from others in the following respects: - Name servers responding to requests for names in this=20 domain have different rules concerning authority. As explained in Section 2.1, mDNS servers have limited scope of authority, not extending to sub-domains of domain they are authoritative for. - DNS servers SHOULD NOT forward queries for domain names=20 in the local.arpa domain - if the server cannot answer=20 the query from its own database, it should reply with a =20 non-authoritative NXDOMAIN. - Hosts may derive their own names in this namespace,=20 independent of centralized authorization and registration (as defined in section 3 and section 5). - There is no delegation or administrative structure to=20 sub-domains of '.local.arpa'. =20 How protocol objects are mapped into lookup keys: Names are associated with resources which can be requested according to the DNS protocol. However, recursive lookup is impossible. Further, mDNS specifies only the use of multicast to transmit these requests. Resolution: Accept Change reflected in 01 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. From owner-namedroppers@ops.ietf.org Tue Jul 17 14:14:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08193 for ; Tue, 17 Jul 2001 14:14:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MYbM-000PUp-00 for namedroppers-data@psg.com; Tue, 17 Jul 2001 10:25:40 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15MYbL-000PUj-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 10:25:39 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15MYbL-0000LM-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 13:25:39 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: The IESG To: AAA Working Group , ACAP Working Group , ADSLMIB Working Group , AFT Working Group , AGENTX Working Group , APEX Working Group , ATOMMIB Working Group , AVT Working Group , BEEP Working Group , BGMP Working Group , BMWG Working Group , BRIDGE Working Group , CALSCH Working Group , CAT Working Group , CCAMP Working Group , CNRP Working Group , DELTAV Working Group , DHC Working Group , DIFFSERV Working Group , DISMAN Working Group , DNSEXT Working Group , DNSOP Working Group , ECM Working Group , EDIINT Working Group , ENTMIB Working Group , ENUM Working Group , EOS Working Group , FAX Working Group , FRNETMIB Working Group , FTPEXT Working Group , GEOPRIV Working Group , GRIP Working Group , GSMP Working Group , HUBMIB Working Group , IDMR Working Group , IDN Working Group , IDR Working Group , IDWG Working Group , IFMIB Working Group , IMAPEXT Working Group , IMPP Working Group , IPCDN Working Group , IPFC Working Group , IPNGWG Working Group , IPO Working Group , IPORPR Working Group , IPP Working Group , IPPM Working Group , IPS Working Group , IPSEC Working Group , IPSP Working Group , IPSRA Working Group , IPTEL Working Group , ISIS Working Group , ISSLL Working Group , ITRACE Working Group , KINK Working Group , KRB-WG Working Group , L2TPEXT Working Group , LDAPBIS Working Group , LDAPEXT Working Group , LDUP Working Group , MALLOC Working Group , MANET Working Group , MBONED Working Group , MEGACO Working Group , MIDCOM Working Group , MMUSIC Working Group , MOBILEIP Working Group , MPLS Working Group , MSDP Working Group , MSEC Working Group , MSGTRK Working Group , MULTI6 Working Group , NASREQ Working Group , NAT Working Group , NFSV4 Working Group , NGTRANS Working Group , NNTPEXT Working Group , OPENPGP Working Group , OSPF Working Group , OTP Working Group , PILC Working Group , PIM Working Group , PKIX Working Group , POISSON Working Group , POLICY Working Group , PPPEXT Working Group , PPVPN Working Group , PROVREG Working Group , PWE3 Working Group , RAP Working Group , RESCAP Working Group , RIP Working Group , RMONMIB Working Group , RMT Working Group , ROHC Working Group , RSERPOOL Working Group , RUN Working Group , SACRED Working Group , SEAMOBY Working Group , SECSH Working Group , SIGTRAN Working Group , SIMPLE Working Group , SIP Working Group , SMIME Working Group , SMING Working Group , SNMPCONF Working Group , SNMPV3 Working Group , SPIRITS Working Group , SSM Working Group , STIME Working Group , SYSLOG Working Group , TEWG Working Group , TLS Working Group , TN3270E Working Group , TRADE Working Group , TSVWG Working Group , UDLR Working Group , URN Working Group , USEFOR Working Group , USWG Working Group , VPIM Working Group , VRRP Working Group , WEBDAV Working Group , WEBI Working Group , WTS Working Group , XMLDSIG Working Group , ZEROCONF Working Group cc: iesg@ietf.org Subject: Note Well Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 17 Jul 2001 10:25:40 -0700 Content-Transfer-Encoding: 7bit Greetings, This is the revised text of the NOTE WELL statement. ------------------------------------------------------ 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. From owner-namedroppers@ops.ietf.org Tue Jul 17 16:47:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09908 for ; Tue, 17 Jul 2001 16:47:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MbJe-00056a-00 for namedroppers-data@psg.com; Tue, 17 Jul 2001 13:19:34 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15MbJd-00056U-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 13:19:34 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15MbJd-0000UP-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 16:19:33 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: TKEY compatibility problems References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 17 Jul 2001 13:19:34 -0700 Andrew Brown asks why my cache ``promotes'' additional records to answer records. (Apparently his message was discarded by Randy Bush.) Answer: This is how caches have always worked. The additional A record that comes with an MX record, for example, is returned as an answer in response to subsequent A queries. RFC 2181 is simply wrong. Are there any further questions about my TKEY example? The failure of TKEY to work with AXFR clients is just like the failure of TKEY to work with caches. Does everyone agree that the cache is behaving properly? Obviously the TKEY specification needs to be corrected. Robert Elz writes: > Could you possibly explain, in very plain words, just what it would > hurt for you to alter your implementation to make it that only the answer > section in an AXFR was used as zone data? Could you possibly explain just what it would hurt for the BIND company to alter _their_ implementation to handle data in other sections? After all, I might want to deploy an optional AXFR extension that--- without wasting space---communicates a few extra bits of information by putting records into AU or AR instead of AN. This extension would be incompatible with current versions of BIND, so BIND has to be fixed! Now, I realize that there are a million BIND hosts out there, including tens of thousands running ancient versions of BIND, but, gee, surely they'll all upgrade before I deploy my incompatible extension. If they don't, we'll use BIND's ``remote root upgrade'' feature! Whaddya mean, optional extensions have no right to break compatibility? We're talking about the _future_, damn it! Bold new paths! OSI! I know the BIND company doesn't care about these things, but they can't expect the rest of us to acquiesce to their Luddism. Maybe you're not swayed by practical compatibility concerns. Well, how about the spirit of RFC 1034? The RFC says that zone transfer messages carry all the zone records. It _doesn't_ say that the records are in the answer section. Obviously clients are meant to read all the sections! ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 17 16:47:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09973 for ; Tue, 17 Jul 2001 16:47:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MaoL-00041z-00 for namedroppers-data@psg.com; Tue, 17 Jul 2001 12:47:13 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15MaoL-00041t-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 12:47:13 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15MaoK-0000TA-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 15:47:12 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Jakob Schlyter To: Edward Lewis Cc: Subject: Re: Question about TSIG, AD/AA, and AXFR In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 17 Jul 2001 12:47:13 -0700 Content-Transfer-Encoding: 7bit On Tue, 17 Jul 2001, Edward Lewis wrote: > From you message it sounds like no one should trust data with the AA bit, > as this means the authentication has not been checked. This is an ironic > conclusion, as we've been assigning more credibility to AA'd data. (Once > again, the credibility vs. authenticated issue arises.) the nameserver should never set the AD bit without actually verifying the data. some earlier version of bind did set AD if the server itself were authorative. I belive this is wrong - data shouldn't be checked on load, it should be checked on query. I think the AA-bit could be trustworthy for very simple resolvers that, for some reason, do trust their local resolver. 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. From owner-namedroppers@ops.ietf.org Tue Jul 17 17:16:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16252 for ; Tue, 17 Jul 2001 17:16:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MbdO-0005nK-00 for namedroppers-data@psg.com; Tue, 17 Jul 2001 13:39:58 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15MbdL-0005nD-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 13:39:55 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15MbdK-0000Vb-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 16:39:54 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Edward Lewis To: Jakob Schlyter Cc: Edward Lewis , Subject: Re: Question about TSIG, AD/AA, and AXFR In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 17 Jul 2001 13:39:58 -0700 Content-Transfer-Encoding: 7bit At 3:47 PM -0400 7/17/01, Jakob Schlyter wrote: >authorative. I belive this is wrong - data shouldn't be checked on load, >it should be checked on query. What are the chances that this will happen, I mean software development wise? It does make more sense to check on query for two reasons - the SIG validity is more timely and the need to get other data (the key chain) shouldn't slow the loading process. >I think the AA-bit could be trustworthy for very simple resolvers that, >for some reason, do trust their local resolver. I don't think this as "special case" as you make it seem. -------------------------------- (network A) | | Host NS/FW | --------------------- (network B, ie, the Internet) Assuming NS/FW is recursive only for hosts on A, uses TSIG (possibly the criteria for recursion), but answers authoritatively for domains on both A and B: Host should "trust" answers that pass the TSIG test and have either AA or AD. Answers with TSIG and neither ought to be used as "as best as can be gotten, but obviously unreliable." I think a good question is what is the interaction of the "gimme DNSSEC records" bit, the AA bit, and validity period checking. If the authoritative server does not check the validity period, and the SIGs aren't sent, then the stub might accept temporally invalid data. I think I (or someone) needs to document the cases in a more formal way to make sure we're on the same page. To late for an I-D, but perhaps something will be distributed on dnssec@cafax.se in the next few weeks. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com You fly too often when ... the airport taxi is on speed-dial. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 17 17:33:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19772 for ; Tue, 17 Jul 2001 17:33:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15McJ9-0007DB-00 for namedroppers-data@psg.com; Tue, 17 Jul 2001 14:23:07 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15McJ6-0007D5-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 14:23:04 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15McJ5-0000XE-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 17:23:03 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Jakob Schlyter To: Edward Lewis Cc: Subject: Re: Question about TSIG, AD/AA, and AXFR In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 17 Jul 2001 14:23:07 -0700 Content-Transfer-Encoding: 7bit On Tue, 17 Jul 2001, Edward Lewis wrote: > >authorative. I belive this is wrong - data shouldn't be checked on load, > >it should be checked on query. > > What are the chances that this will happen, I mean software development > wise? It does make more sense to check on query for two reasons - the SIG > validity is more timely and the need to get other data (the key chain) > shouldn't slow the loading process. not only does it make more sense to check on query, you will lie if you don't (or at least, possibly lie). bind9 has fixed this (it doesn't check on load anymore) but currently doesn't check data it is authorative for at all. this is of course not a requirement, but it does make it impossible to have a server authorative and act as a resolver at the same time while serving clients that puts their trust into the AD-bit. > >I think the AA-bit could be trustworthy for very simple resolvers that, > >for some reason, do trust their local resolver. > > I don't think this as "special case" as you make it seem. my typo, that should have been "I think the AD-bit could be trustworthy for very simple resolvers that, for some reason, do trust their local resolver." there is no special case, the trust a host put into dns data depends on from whom and how it get it. some may trust AD alone, some may require AD+TSIG, some doesn't care about dnssec at all. > I think I (or someone) needs to document the cases in a more formal > way to make sure we're on the same page. To late for an I-D, but > perhaps something will be distributed on dnssec@cafax.se in the next > few weeks. yes, something that describes dnssec from the resolver perspective needs to be written down. 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. From owner-namedroppers@ops.ietf.org Tue Jul 17 18:01:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24479 for ; Tue, 17 Jul 2001 18:01:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15McKa-0007HP-00 for namedroppers-data@psg.com; Tue, 17 Jul 2001 14:24:36 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15McKZ-0007HH-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 14:24:36 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15McKZ-0000XW-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 17:24:35 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Andrew Brown To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org Subject: Re: TKEY compatibility problems In-Reply-To: ; from djb@cr.yp.to on Tue, Jul 17, 2001 at 01:19:34PM -0700 References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 17 Jul 2001 14:24:36 -0700 Content-Transfer-Encoding: 7bit >Andrew Brown asks why my cache ``promotes'' additional records to answer >records. (Apparently his message was discarded by Randy Bush.) randy didn't. his list server did. but no matter. >Answer: This is how caches have always worked. The additional A record >that comes with an MX record, for example, is returned as an answer in >response to subsequent A queries. RFC 2181 is simply wrong. additional records are glue data. they are there to assist the recursing name server in looking up the answer. they are *not* an answer. i would perhaps argue that an application using a resolver should be able to use additional records as answers, but not a name server. >Are there any further questions about my TKEY example? The failure of >TKEY to work with AXFR clients is just like the failure of TKEY to work >with caches. Does everyone agree that the cache is behaving properly? >Obviously the TKEY specification needs to be corrected. if you receive a tkey record in response to a simple query, there's no conceivable reason you should be able to answer an axfr query that might contain the tkey. if a server returns a tkey to your axfr query, it should not be appended to the zone since it's not in the answer section. they question (axfr) asks for all records in the zone. the zone itself is the answer, the tkey is additional and not an answer per se. my understanding was that additional (or glue) records are supposed to be helpful hints, not answers for servers. -- |-----< "CODE WARRIOR" >-----| codewarrior@daemon.org * "ah! i see you have the internet twofsonet@graffiti.com (Andrew Brown) that goes *ping*!" andrew@crossbar.com * "information is power -- share the wealth." to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 17 20:19:06 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21195 for ; Tue, 17 Jul 2001 20:19:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Mejv-000CbL-00 for namedroppers-data@psg.com; Tue, 17 Jul 2001 16:58:55 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15Meju-000CbA-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 16:58:54 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Mejt-0000Cd-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 19:58:53 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: gson@nominum.com (Andreas Gustafsson) To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org Subject: Re: TKEY compatibility problems In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 17 Jul 2001 16:58:55 -0700 Content-Transfer-Encoding: 7bit D. J. Bernstein writes: > Obviously the TKEY specification needs to be corrected. The problem of servers caching meta-RRs is real, but it is not specific to TKEY, and it has nothing to do with AXFR. I think the best way to solve it is to only allocate meta-RR types from the range reserved exclusively for that purpose (128-255, see RFC2929), and to make caching servers ignore rather than cache unknown records whose types fall within that range. -- Andreas Gustafsson, gson@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 17 20:19:09 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21206 for ; Tue, 17 Jul 2001 20:19:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Mels-000CfA-00 for namedroppers-data@psg.com; Tue, 17 Jul 2001 17:00:56 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15Melr-000Cf4-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 17:00:55 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Melq-0000Cs-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 20:00:54 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: gson@nominum.com (Andreas Gustafsson) To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org Subject: AXFR extensibility In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 17 Jul 2001 17:00:56 -0700 Content-Transfer-Encoding: 7bit > Could you possibly explain just what it would hurt for the BIND company > to alter _their_ implementation to handle data in other sections? > > After all, I might want to deploy an optional AXFR extension that--- > without wasting space---communicates a few extra bits of information by > putting records into AU or AR instead of AN. This extension would be > incompatible with current versions of BIND, so BIND has to be fixed! And someone else might want to deploy an optional extension that communicates more bits than can be represented using the section distinction, by encoding it in RRs that are not part of the zone data. This extension would be incompatible with current versions of TinyDNS. In other words, neither method of extension is currently safe - both will cause interoperability problems with at least one deployed implementation. We can make one or the other (but not both) become safe at some point in the future by unambiguously specifying that non-answer-section records are treated as zone data or are ignored, respectively. The draft as currently written reflects the choice to ignore the records, because I believe it this choice is more consistent with the spirit of RFC103[45], is implemented by a larger proportion of deployed servers, allows more useful forms of extension, and enjoys greater support in the working group. -- Andreas Gustafsson, gson@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 17 20:41:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26728 for ; Tue, 17 Jul 2001 20:41:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Mek4-000CbU-00 for namedroppers-data@psg.com; Tue, 17 Jul 2001 16:59:04 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15Mek3-000CbO-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 16:59:03 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Mek3-0000Cf-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 19:59:03 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: TKEY compatibility problems References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 17 Jul 2001 16:59:04 -0700 Content-Transfer-Encoding: 7bit The BIND 9 cache saves records from the additional section and provides those records as answers to subsequent queries. Same for the BIND 4 cache, the BIND 8 cache, and my cache. Does anyone seriously believe that this is incorrect behavior? We've also been told that the BIND 9.1.0-and-newer cache, just like my cache, handles unrecognized record types as per RFC 1123. Does anyone seriously believe that this is incorrect behavior? Imagine a TKEY2 extension that's similar to the current TKEY but uses a new record type, unrecognized by BIND 9.1.0. Then spontaneous TKEY2 server --> BIND 9.1.0 cache --> TKEY2 client will produce exactly the failures I've described, except with TKEY2 in place of TKEY. Does anyone dispute this? Similarly, if you rip the TKEY support out of BIND 9.1.0, and you put that cache between a spontaneous TKEY server and a TKEY client, you get failures. Does anyone dispute this? The inescapable conclusion is that the TKEY extension is broken. It is incompatible with the unextended protocol. It has to be fixed. How can anyone use a broken extension as an argument against my AXFR client? These are fundamental interoperability issues. They have to be settled. Andrew Brown writes: > additional records are glue data. they are there to assist the > recursing name server in looking up the answer. Sorry, but that simply isn't how DNS works. RFC 1034 defines the additional section as carrying ``RRs which may be helpful in using the RRs in the other sections.'' I already gave the obvious example: A records associated to MX records. The A record is helpful---it saves time. You claim that the A is glue; that's rarely true. You claim that it's ``to assist the recursing name server in looking up the answer''; that's false. There's no support in RFC 1034, RFC 1035, or RFC 1123 for the notion that additional records are second-class citizens. That notion was invented by Paul Vixie as a failed attempt to stop cache poisoning. See http://cr.yp.to/djbdns/notes.html. I would have objected to RFC 2181's credibility rules if I had been involved in DNS programming back then. I object to them now as being useless, harmful, and out of line with existing practice. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 17 20:41:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26739 for ; Tue, 17 Jul 2001 20:41:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Mem0-000CfK-00 for namedroppers-data@psg.com; Tue, 17 Jul 2001 17:01:04 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15Melz-000CfE-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 17:01:03 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Melz-0000Cu-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 20:01:03 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Kevin Darcy To: namedroppers@ops.ietf.org Subject: Re: TKEY compatibility problems References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 17 Jul 2001 17:01:04 -0700 Content-Transfer-Encoding: 7bit D. J. Bernstein wrote: > Andrew Brown asks why my cache ``promotes'' additional records to answer > records. (Apparently his message was discarded by Randy Bush.) > > Answer: This is how caches have always worked. The additional A record > that comes with an MX record, for example, is returned as an answer in > response to subsequent A queries. So what's your point? A totally *different* server may answer the A query. Additional Section records are viewed as inherently less "credible" because the client can't easily tell where they come from vis-a-vis authoritative data or cache. If you really need credible data, you ignore what's in the Additional Section and query the names independently. Or use DNSSEC. > Are there any further questions about my TKEY example? The failure of > TKEY to work with AXFR clients is just like the failure of TKEY to work > with caches. Does everyone agree that the cache is behaving properly? > Obviously the TKEY specification needs to be corrected. No, TKEY is just fine. A "section-agnostic" cache is just as broken as a "section-agnostic" AXFR client. Where would we be if caches started treating referrals or NCACHE SOA records as regular answers? The DNS packet format was sectioned for a *reason*. Different sections provide different contexts, and an RR in one section may have a different meaning than an identical RR in some other section. That's the way it's always been, and the way it was *meant* to be. Whence comes this strange notion that one can take *all* RRs in a response, regardless of section, and treat them on an equivalent basis? That's never been the case. Why even _have_ sections in that case? > Robert Elz writes: > > Could you possibly explain, in very plain words, just what it would > > hurt for you to alter your implementation to make it that only the answer > > section in an AXFR was used as zone data? > > Could you possibly explain just what it would hurt for the BIND company > to alter _their_ implementation to handle data in other sections? > > After all, I might want to deploy an optional AXFR extension that--- > without wasting space---communicates a few extra bits of information by > putting records into AU or AR instead of AN. This extension would be > incompatible with current versions of BIND, so BIND has to be fixed! But what is the inherent *value* of putting zone data into Authority or Additional, Dan? The value of putting metadata into Authority or Additional of an AXFR response is specifically to segregate it from the zone data so the client doesn't get confused. A TKEY, for example, shouldn't be considered part of the zone data, so by segregating it into Additional, we help avoid misinterpretation. Section-agnosticism ruins this mechanism, and means that clients now have to sift through all the records and make decisions about whether or not an RR is part of the zone data, based on its record type and possibly other factors. This is cumbersome, error-prone and inefficient. The only reason section-agnosticism sorta-kinda works today is because there aren't very many extensions which apply to AXFR responses. But this is a moving target we're talking about. You can't expect the rest of the protocol to stand still. > Maybe you're not swayed by practical compatibility concerns. Well, how > about the spirit of RFC 1034? The RFC says that zone transfer messages > carry all the zone records. It _doesn't_ say that the records are in the > answer section. It doesn't say that they're *not* in the Answer Section, either. We all agree, don't we?, that the original specification was unclear. What *is* clear, however, is the general rule that direct answers to DNS questions are found in the Answer Section of the response. AFAIK, every client except yours has assumed that, for AXFR as well as non-AXFR responses. And as far as I can tell, the only reason your AXFR client assumed otherwise was simply because you happened to code it that way. You didn't start getting militant about things until it came time to clarify the specification and you realized that you'd have to change your code. That's the risk you took when you flouted a basic assumption about DNS response-interpretation that everyone else has made. - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 17 22:25:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA16683 for ; Tue, 17 Jul 2001 22:25:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MgGn-000GQ6-00 for namedroppers-data@psg.com; Tue, 17 Jul 2001 18:36:57 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15MgGm-000GQ0-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 18:36:57 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15MgGk-0000IP-00 for namedroppers@ops.ietf.org; Tue, 17 Jul 2001 21:36:54 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Kevin Darcy To: namedroppers@ops.ietf.org Subject: Re: TKEY compatibility problems References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 17 Jul 2001 18:36:57 -0700 Content-Transfer-Encoding: 7bit To tell the truth, I've never been entirely comfortable with the practice of using Additional as a kind of "side-channel" for miscellaneous protocol-extension information. But I think we're already too far down that path to turn back now, and there's still no good alternative for incremental extension of the protocol. Nor do I see any reason to treat AXFR as a special case in this respect. If protocol-extension records can appear in the Additional Section of responses to regular queries, then I don't see why they shouldn't be allowed in the Additional Section of AXFR responses, if the extension is applicable to AXFRs. And the only reliable way I can think of to allow this, is the "ignore unexpected RRs" language of the clarify draft. It also bewilders me somewhat that Dan can *agree* that it's illegal for a server to *send* zone data in non-Answer sections of an AXFR, but at the same time argue that an AXFR client can *accept* it there. To be sure, no client should crash and burn when presented something illegal, but by the same token I think it stretches "be liberal in what you accept" beyond the breaking-point to say that it should accept illegal transactions as *equivalent* to legal ones. I think "ignore" is the appropriate (between the two extremes) action to take here, when you're talking about something as mission-critical as DNS. If this sometimes results in a missing chunk of zone data, that should be quickly detected, the guilty party easily identified and the software fixed. After all, if a server is so deranged that it can't even put the zone data into the right section, who knows what subtle forms of corruption it may have inflicted on the Answer-Section zone data itself? It's a gamble either way. - Kevin D. J. Bernstein wrote: > The BIND 9 cache saves records from the additional section and provides > those records as answers to subsequent queries. Same for the BIND 4 > cache, the BIND 8 cache, and my cache. Does anyone seriously believe > that this is incorrect behavior? > > We've also been told that the BIND 9.1.0-and-newer cache, just like my > cache, handles unrecognized record types as per RFC 1123. Does anyone > seriously believe that this is incorrect behavior? > > Imagine a TKEY2 extension that's similar to the current TKEY but uses a > new record type, unrecognized by BIND 9.1.0. Then > > spontaneous TKEY2 server --> BIND 9.1.0 cache --> TKEY2 client > > will produce exactly the failures I've described, except with TKEY2 in > place of TKEY. Does anyone dispute this? > > Similarly, if you rip the TKEY support out of BIND 9.1.0, and you put > that cache between a spontaneous TKEY server and a TKEY client, you get > failures. Does anyone dispute this? > > The inescapable conclusion is that the TKEY extension is broken. It is > incompatible with the unextended protocol. It has to be fixed. How can > anyone use a broken extension as an argument against my AXFR client? > > These are fundamental interoperability issues. They have to be settled. > > Andrew Brown writes: > > additional records are glue data. they are there to assist the > > recursing name server in looking up the answer. > > Sorry, but that simply isn't how DNS works. > > RFC 1034 defines the additional section as carrying ``RRs which may be > helpful in using the RRs in the other sections.'' > > I already gave the obvious example: A records associated to MX records. > The A record is helpful---it saves time. You claim that the A is glue; > that's rarely true. You claim that it's ``to assist the recursing name > server in looking up the answer''; that's false. > > There's no support in RFC 1034, RFC 1035, or RFC 1123 for the notion > that additional records are second-class citizens. That notion was > invented by Paul Vixie as a failed attempt to stop cache poisoning. See > http://cr.yp.to/djbdns/notes.html. > > I would have objected to RFC 2181's credibility rules if I had been > involved in DNS programming back then. I object to them now as being > useless, harmful, and out of line with existing practice. > > ---Dan > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 18 09:32:48 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21582 for ; Wed, 18 Jul 2001 09:32:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MqlX-000IwB-00 for namedroppers-data@psg.com; Wed, 18 Jul 2001 05:49:23 -0700 Received: from cbb-sc2.cbbtier3.att.net ([12.0.1.9] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15MqlW-000Iw0-00 for namedroppers@ops.ietf.org; Wed, 18 Jul 2001 05:49:22 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Mql2-0000MF-00 for namedroppers@ops.ietf.org; Wed, 18 Jul 2001 08:48:52 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Yuji Kamite To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: Question about TSIG, AD/AA, and AXFR In-Reply-To: References: X-Mailer: Sylpheed version 0.4.4 (GTK+ 1.2.8; FreeBSD 4.2-RELEASE; i386) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 18 Jul 2001 05:49:23 -0700 Content-Transfer-Encoding: 7bit On Tue, 17 Jul 2001 13:39:58 -0700 Edward Lewis wrote: > Host should "trust" answers that pass the TSIG test and have either AA or > AD. Answers with TSIG and neither ought to be used as "as best as can be > gotten, but obviously unreliable." I think a good question is what is the > interaction of the "gimme DNSSEC records" bit, the AA bit, and validity > period checking. If the authoritative server does not check the validity > period, and the SIGs aren't sent, then the stub might accept temporally > invalid data. I have a question about AD and "gimme DNSSEC records". Is it allowed to return responses with AD bit even if they do not include SIG, NXT and so on? I'm a little confused with usage of AD because the definition about AD in documents seems to be obscure, especially about when it must be set. For example, in BIND9 implementaition, recursive resolver seems to set AD flag in answer if given query has "gimme DNSSEC records" bit. It does not set AD unless given query has "gimme DNSSEC records" bit even when the RRs themselves are Authenticated by the server. Is this right behavior? I think it might be okay for the recursive resolver to reply AD-set answer without DNSSEC-related RRs, if the RRs have been authenticated (i.e. if the server has succeeded to verified the RRs' SIGs according to trust chains) and the message to the stub-resolver are protected by TSIG. >From the view of the host (stub-resolver) which asked the recursive resolver, it would like to trust all tasks of the resolver by means of adding TSIG into queries. But it depends totally on the stub-resolver whether it will send queries with "gimme DNSSEC records" bit. Stub-resolver may send query without "gimme DNSSEC records" bit, if it wants to restrict the packet size exchaged. In this case, queries and responses between stub-resolver and recursive resolver are protected by TSIG, so, I think only if the answer's AD can be set, stub-resolvers might be able to trust aquired RRs' validity. -- Yuji Kamite Information Technology Center, Univ. of Tokyo E-Mail: kamite@kaynet.ecc.u-tokyo.ac.jp to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 18 09:32:48 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21591 for ; Wed, 18 Jul 2001 09:32:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MqjY-000Inl-00 for namedroppers-data@psg.com; Wed, 18 Jul 2001 05:47:20 -0700 Received: from cbb-sc2.cbbtier3.att.net ([12.0.1.9] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15MqjX-000InP-00 for namedroppers@ops.ietf.org; Wed, 18 Jul 2001 05:47:19 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Mqj2-0000Ly-00 for namedroppers@ops.ietf.org; Wed, 18 Jul 2001 08:46:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: AXFR extensibility References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 18 Jul 2001 05:47:20 -0700 Content-Transfer-Encoding: 7bit Andreas Gustafsson writes: > In other words, neither method of extension is currently safe But other methods of extension _are_ safe. I have no objections to a new EXFR query type. All you have to do is make sure that EXFR clients are compatible with NXDOMAIN/NODATA responses from non-EXFR servers. (I'm glad you finally fixed this bug in your IXFR clients, by the way.) ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 18 09:32:50 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21602 for ; Wed, 18 Jul 2001 09:32:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Mqk1-000IqU-00 for namedroppers-data@psg.com; Wed, 18 Jul 2001 05:47:49 -0700 Received: from cbb-sc2.cbbtier3.att.net ([12.0.1.9] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15Mqk0-000Ine-00 for namedroppers@ops.ietf.org; Wed, 18 Jul 2001 05:47:48 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15MqjV-0000M2-00 for namedroppers@ops.ietf.org; Wed, 18 Jul 2001 08:47:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: TKEY compatibility problems References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 18 Jul 2001 05:47:49 -0700 Content-Transfer-Encoding: 7bit Kevin Darcy writes: > It also bewilders me somewhat Does it bewilder you that---to take a provocative example---RFC 2821 clearly prohibits SMTP clients from sending non-ASCII header bytes, but clearly allows SMTP servers to accept those bytes? > that Dan can *agree* that it's illegal for a > server to *send* zone data in non-Answer sections of an AXFR, AXFR server implementors have to stick to the answer section for interoperability with BIND. Anything else would be a disaster. > but at the same time argue that an AXFR client can *accept* it there. That works just fine. There's no interoperability problem. The TKEY discussion is about certain nonexistent types of TKEY servers that also wouldn't work with existing caches. Those servers have to be prohibited, not merely discouraged. > If protocol-extension records can > appear in the Additional Section of responses to regular queries, Unextended caches that obey the RFC 1034, RFC 1035, and RFC 1123 rules, such as my cache and the BIND 9 cache, will treat those as normal records. If the protocol extension has a problem with this, as TKEY does, then the extension is broken. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 18 09:32:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21624 for ; Wed, 18 Jul 2001 09:32:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MqkK-000Iql-00 for namedroppers-data@psg.com; Wed, 18 Jul 2001 05:48:08 -0700 Received: from cbb-sc2.cbbtier3.att.net ([12.0.1.9] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15MqkK-000Inq-00 for namedroppers@ops.ietf.org; Wed, 18 Jul 2001 05:48:08 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Mqjp-0000M4-00 for namedroppers@ops.ietf.org; Wed, 18 Jul 2001 08:47:37 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: "D. J. Bernstein" cc: namedroppers@ops.ietf.org Subject: Re: TKEY compatibility problems In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 18 Jul 2001 05:48:08 -0700 Content-Transfer-Encoding: 7bit Date: Tue, 17 Jul 2001 13:19:34 -0700 From: "D. J. Bernstein" Message-ID: | Could you possibly explain just what it would hurt for the BIND company | to alter _their_ implementation to handle data in other sections? If that was the right thing to do (if there was some advantage to be gained by doing that), then it wouldn't hurt at all, and I would be requesting that exactly that happen. Just now, I can't think of any possible benefit that would gain though, if data in an AXFR is supposed to be treated just line the data in the answer section, then it might as well get put in the answer section. After all, there's nothing to be gained by putting it elsewhere. The only point for having multiple sections in answers is so the RRs in those sections can be treated differently, otherwise the different sections wouldn't exist at all. | After all, I might want to deploy an optional AXFR extension that--- | without wasting space---communicates a few extra bits of information by | putting records into AU or AR instead of AN. This extension would be | incompatible with current versions of BIND, so BIND has to be fixed! Yes, if there's any benefit to be gained by that extension, so that it would ever get general agreement, that would be true. So, if you can explain to me just how anyone would ever benefit by deliberately splitting data that is to be treated just the same over multiple sections, then perhaps you would get me (and perhaps even someone else) to agree with you. On the other hand, it is easy to see how if there was ever some data that should not be treated the same could easily be marked as different by putting it in a different section - provided that servers don't go treating the different sections as if they were equivalent. | Now, I realize that there are a million BIND hosts out there, including | tens of thousands running ancient versions of BIND, but, gee, surely | they'll all upgrade before I deploy my incompatible extension. If they | don't, we'll use BIND's ``remote root upgrade'' feature! Yes, they probably would, if there were to be a reason to do this, remaining compatible with ancient BIND into the distant future isn't something to worry about. Retaining compatability with ancient djbdns is even less to worry about. | Whaddya mean, optional extensions have no right to break compatibility? I don't mean that, never did. For sure, the compatability of any extension needs to be carefully considered to see how well it will actually work - that's just the same as evaluating whether the rest of the proposal will actually work. There's no point defining something that won't work in practice, no matter what the reason. But if it will work, and is generally agreed to be required, then breaking old stuff can be OK - it's all part of the trade offs to be considered. | Maybe you're not swayed by practical compatibility concerns. Well, how | about the spirit of RFC 1034? The RFC says that zone transfer messages | carry all the zone records. It _doesn't_ say that the records are in the | answer section. Obviously clients are meant to read all the sections! The conclusion does not follow. More accurate would be "Obviously clients get the AXFR answer from the answer section, we don't need to actually say that". Note that you deliberately avoided answering the question I asked. >From that I assume that there is no rational reason at all why you can't change your implementation to only look in the answer section. Given this, and the notice that you have been given that one day perhaps an AXFR extension may be created which requires servers to treat the different sections in an AXFR message differently (and one might assume, allows servers that don't understand the new stuff to simply ignore it, by ignoring that section and all its data), then if that ever happens, and the users of your server all come complaining that they're being forced to upgrade, and they don't want to (or can't, if your server is no longer being maintained then) - we'll all just refer them to you, and tell them that you knew all about this years ago (from that time in the future) and deliberately decided then to screw them. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 18 09:32:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21631 for ; Wed, 18 Jul 2001 09:32:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Mqkn-000ItB-00 for namedroppers-data@psg.com; Wed, 18 Jul 2001 05:48:37 -0700 Received: from cbb-sc2.cbbtier3.att.net ([12.0.1.9] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15Mqkm-000Iqf-00 for namedroppers@ops.ietf.org; Wed, 18 Jul 2001 05:48:36 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15MqkH-0000MA-00 for namedroppers@ops.ietf.org; Wed, 18 Jul 2001 08:48:05 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: "D. J. Bernstein" cc: namedroppers@ops.ietf.org Subject: Re: TKEY compatibility problems In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 18 Jul 2001 05:48:37 -0700 Content-Transfer-Encoding: 7bit Date: Tue, 17 Jul 2001 16:59:04 -0700 From: "D. J. Bernstein" Message-ID: | The BIND 9 cache saves records from the additional section and provides | those records as answers to subsequent queries. Same for the BIND 4 | cache, the BIND 8 cache, and my cache. Does anyone seriously believe | that this is incorrect behavior? That's an impossible question to answer, how can anyone possibly know whether anyone else believes that? So the best that can happen when you ask a question in that form is to receive silence. Personally, no, I don't believe it is incorrect to cache records from auth or additional sections, and return them in later answers, as long as the AA bit is never set in such an answer. And, as long as no better answer has been obtained by the server, before or after. That is, if you already have an A record received as a direct answer, and you later get an A record in the additional info section of some reply, then the first one is the one you should use, not the second (assuming they're different of course, it makes no difference otherwise - though I am not convinced that the TTL of the additional info should ever be used to extend the TTL on an earlier received answer, even given the RR data is the same). | Similarly, if you rip the TKEY support out of BIND 9.1.0, and you put | that cache between a spontaneous TKEY server and a TKEY client, you get | failures. Does anyone dispute this? If there are TKEY records being invented (calculated...) and inserted in the additional section of regular DNS replies, and assuming that anyone ever actually wants to do a TKEY lookup, then (given the same caveat about "does anyone" questions), no, that would be a problem. However, there is no actual problem if either of those two premises are false - that is, for example, if there's no reason to ever do a TKEY lookup, that is, if a TKEY is meaningful only when it accompanies some other data, then there is no actual problem, regardless of where the odd record might have been cached (the non-understanding server isn't just going to attach it to some random query for the fun of it, and there won't be any query for the TKEY itself, so it is relatively harmless). Similarly, in an AXFR, a TKEY in the additional section won't be included in the zone data, because the zone data is all in the answer section... | The inescapable conclusion is that the TKEY extension is broken. False. | It is incompatible with the unextended protocol. In a way that seems to not matter. | It has to be fixed. At the minute I see no compelling evidence for that. | How can | anyone use a broken extension as an argument against my AXFR client? Even in the wildest case, that TKEY was proved to be fundamentally broken, all it is being used of in that argument is as an example of something which could also be done in the future. | These are fundamental interoperability issues. They have to be settled. Yes. That is what the text in axfr-02 is doing. AXFR clients MUST NOT treat RRs in the auth and additional sections as part of the zone. That solves the interoperability problem by defining exactly what is correct. Then, because we know there are axfr clients written before this was made clear (one implementation anyway), we do all we can to delay actually defining anything to put in those sections (or anything that is likely to be used arbitrarily - tkey is only used by bilateral agreement I think) until sufficient time has elapsed that older clients are likely to have been upgraded for other reasons. And note that AXFR is always a bi-lateral relationship (any AXFR that matters anyway, nslookup's use of it for its "ls" command can be ignored) so any use of a protocol extension can always be avoided by that bilateral relationship if one server cannot be upgraded for any reason when it would be needed to support the extension. | I already gave the obvious example: A records associated to MX records. | The A record is helpful---it saves time. You claim that the A is glue; | that's rarely true. Not rarely at all. There are zillions of domains whose MX records are aimed at uunet or aol or demon, or similar mail servers. The A records that accompany those MX records are glue. They're not at all rare... Now it may be that the server that is answering the query also happens to be authoritative for the zone that contains the A record concerned - but there's no way that you can know that when you receive the reply, unless you go and do an A record lookup, and ignore the one in the answer, and then determine that it came from the same servers (which would be useless effort, if you have obtained the A record from its authoritative servers, then where the glue A record in the additional section of the MX reply came from is simply irrelevant, as is its value, you just discard it.) | You claim that it's ``to assist the recursing name | server in looking up the answer''; that's false. Andrew's ``looking up'' weren't the right words to use, ``making use of'' would be better. The use made of them when they accompany NS records in a referral, is in looking up the original answer. Other uses are made of them in other records. To make use of them it is not necessary to treat them as if they were the equal of answers. | There's no support in RFC 1034, RFC 1035, or RFC 1123 for the notion | that additional records are second-class citizens. I will ignore the "second class" part - both because use of the word "class" might someday be confusing to someone who equates that somehow with the DNS zone class mechanism, and because what is first class and what is second isn't relevant here. But there's certainly support for treating the data in the different sections differently - even if it isn't spelled out in words of one syllable. That is really obvious - if it was all to be treated the same, then there wouldn't need to be markers (counts) in the packet to separate the RRs into different groups. The only explanation for the existence of the different sections is that the data in them is to be treated differently. Or perhaps you can find some other explanation for the existence of the 3 different reply type sections in DNS packets (the question section is obviously different - the RR data section there is omitted - but by your "treat it all the same" argument, I guess you should be taking the RR in the question section of a reply and caching that one as well...) | I would have objected to RFC 2181's credibility rules if I had been | involved in DNS programming back then. I object to them now as being | useless, harmful, and out of line with existing practice. This is perhaps the best argument I've yet seen .... (sarcasm implied). What that translates into is "2181 existed when I wrote my implementation. I decided to ignore it. Now I claim it shouldn't exist because it isn't compatible with my implementation". Or, "I will do what I like, and everyone else better write/change the specs to reflect what I have done". This reminds me of just what any "reputable standards organisation" would do with that line of argument. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 18 17:02:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02326 for ; Wed, 18 Jul 2001 17:02:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MxLO-000DEU-00 for namedroppers-data@psg.com; Wed, 18 Jul 2001 12:50:50 -0700 Received: from cbb-sc2.cbbtier3.att.net ([12.0.1.9] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15MxLN-000DBu-00 for namedroppers@ops.ietf.org; Wed, 18 Jul 2001 12:50:50 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15MxKr-0000RB-00 for namedroppers@ops.ietf.org; Wed, 18 Jul 2001 15:50:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Erik Guttman Reply-To: Erik Guttman To: Bernard Aboba Cc: namedroppers@ops.ietf.org, bernarda@microsoft.com Subject: Re: Proposed changes to mDNS -02 draft In-Reply-To: "Your message with ID" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 18 Jul 2001 12:50:50 -0700 Content-Transfer-Encoding: 7bit Bernard, > Proposed changes to draft-ietf-dnsext-mdns-02.txt > (and comment disposition from previous revisions) I really appreciate your work toward a stable draft including all outstanding comments. I support all the recommendations in the list you posted (including those which reject my proposals :-). I point out that I still want to discuss mDNS configuration via an mDNS enable DHC option instead of the domain search list. I hope we can resolve this at the IETF 51 DNSEXT session. Thanks, Erik to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 18 22:23:17 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA06695 for ; Wed, 18 Jul 2001 22:23:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15N36L-000570-00 for namedroppers-data@psg.com; Wed, 18 Jul 2001 18:59:41 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15N36K-00056q-00 for namedroppers@ops.ietf.org; Wed, 18 Jul 2001 18:59:40 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15N36I-0000c3-00 for namedroppers@ops.ietf.org; Wed, 18 Jul 2001 21:59:38 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: TKEY compatibility problems References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 18 Jul 2001 18:59:41 -0700 Content-Transfer-Encoding: 7bit Robert Elz writes: > and assuming that anyone ever actually wants to do a TKEY lookup Please read more carefully. Here's the failure under discussion, involving a TKEY server, a non-TKEY cache, and a TKEY client: (1) the server sends a spontaneous TKEY---apparently this is not prohibited by the TKEY spec; (2) the cache saves the TKEY record---this is how caches are supposed to behave under RFC 1034/1035/1123, and it's how my cache works, and it's how the current BIND cache would behave if it didn't know about TKEY; (3) the client does a * lookup (_not_ a TKEY lookup!)---this is something that MTAs do frequently, working around old BIND bugs; (4) the cache returns the TKEY record in AN---this, again, is how the current BIND cache would behave if it didn't know about TKEY; (5) the client sees the TKEY record and chokes---the TKEY spec does not allow TKEY in AN. The non-TKEY cache is behaving properly here. The inescapable conclusion is that the TKEY extension is broken. The TKEY specification has to be fixed. It could prevent #1 by prohibiting spontaneous TKEYs, or it could prevent #5 by requiring that TKEY clients ignore unexpected TKEY records, or both. > That solves the interoperability problem by defining exactly what is correct. Writing specs does not solve interoperability problems. _Deploying code_ can solve interoperability problems. Deployment is, however, expensive. Why should my users suffer this cost? Why is the BIND company so amazingly careless with its protocol extensions? I've seen a lot of bad protocol design in the IETF, but never before have I seen such blatant disregard for compatibility. > But if it will work, and is generally agreed to be required, then > breaking old stuff can be OK Nobody claims that TKEY is required; in fact, like TSIG, it seems rather pointless in a world of IPSEC. Nobody claims that the BIND company's hypothetical AXFR extensions are required. The cost of deploying these optional features should be paid by the people who want the features. > The A records that accompany those MX records are glue. As I said, that's rarely true. The server almost always has the A record in its authoritative data, if it has it at all. Perhaps you have forgotten the definition of glue? [ in RFC 1034, RFC 1035, RFC 1123 ] > there's certainly support for treating the data in the different > sections differently Certainly. But there's no support for Vixie's credibility rules, or for your fraudulently labelled ``clarifications'' in RFC 2181. RFC 1035 requires that new data be preferred to cached data in one situation. It never requires that cached data be preferred to new data. It never requires that additional records be kept out of answers. Your sarcastic comments about my deliberate violation of RFC 2181 (``I will do what I like, and everyone else better write/change the specs to reflect what I have done,'' etc.) sound rather stupid in light of the fact that BIND 9 also deliberately violates RFC 2181. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 18 22:42:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA11889 for ; Wed, 18 Jul 2001 22:42:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15N36U-00057y-00 for namedroppers-data@psg.com; Wed, 18 Jul 2001 18:59:50 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15N36T-00057j-00 for namedroppers@ops.ietf.org; Wed, 18 Jul 2001 18:59:49 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15N36R-0000c5-00 for namedroppers@ops.ietf.org; Wed, 18 Jul 2001 21:59:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: TKEY compatibility problems References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 18 Jul 2001 18:59:50 -0700 Content-Transfer-Encoding: 7bit Andreas Gustafsson writes: > make caching servers ignore rather than cache unknown records [ of types 128-255, and then deploy extensions using those types ] Again, blatant disregard for compatibility. We already have a mechanism to prevent caching. You simply have to require (not just recommend) TTL 0. As for ignoring the record entirely, that's the responsibility of the extended client. You can, for example, put the server's IP address at the beginning of the data, and have the client skip the record if the address doesn't match. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jul 19 09:43:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA01826 for ; Thu, 19 Jul 2001 09:43:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15NDje-000DM0-00 for namedroppers-data@psg.com; Thu, 19 Jul 2001 06:20:58 -0700 Received: from kcmso1.att.com ([192.128.133.69] helo=kcmso1.proxy.att.com) by psg.com with esmtp (Exim 3.31 #1) id 15NDjd-000DKU-00 for namedroppers@ops.ietf.org; Thu, 19 Jul 2001 06:20:58 -0700 Received: from roam.psg.com ([135.46.145.131]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f6JDKMD23052 for ; Thu, 19 Jul 2001 09:20:22 -0400 (EDT) Date: Thu, 19 Jul 2001 09:20:22 -0400 (EDT) Message-Id: <200107191320.f6JDKMD23052@kcmso1.proxy.att.com> Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15NDjF-0000DC-00 for namedroppers@ops.ietf.org; Thu, 19 Jul 2001 09:20:33 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: "D. J. Bernstein" cc: namedroppers@ops.ietf.org Subject: Re: TKEY compatibility problems In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Wed, 18 Jul 2001 18:59:41 -0700 From: "D. J. Bernstein" Message-ID: | (3) the client does a * lookup (_not_ a TKEY lookup!)---this is | something that MTAs do frequently, working around old BIND bugs; ANY lookups not directed at an auth server for the zone containing the RR are close to a waste of time, as all they ever return is what the server queried happens to have in its cache at the time (unless, sometimes, that was nothing, and the server queried finds the auth server and does an ANY query of that). A query of an AUTH server won't return a TKEY in the answer section. But should a client for some odd reason decide that an ANY query of a cache actually makes sense, then ... | (5) the client sees the TKEY record and chokes---the TKEY spec does | not allow TKEY in AN. "chokes" in any reasonable implementation will be "ignores the record". In practice, those applications that do do ANY queries, are looking for a couple of particular record types (they'd often rather be sending a query for A AAAA A6 MX and CNAME but can't currently do that in one message) anything else returned (NS, SOA, RP, LOC, HINFO, WKS, ...) just gets ignored anyway - it is kind of hard to see why TKEY is going to be treated differently. | or it could | prevent #5 by requiring that TKEY clients ignore unexpected TKEY | records, Yes, the TKEY spec probably should do that, but that it doesn't doesn't make it fatally flawed, just not as complete as it could be - something to fix when it is revised. | Writing specs does not solve interoperability problems. _Deploying code_ | can solve interoperability problems. Deployment is, however, expensive. Yes, which is why it is good if everyone can agree on what the deployed code should do to void the problem before anyone starts deploying anything. Otherwise the attempts to solve the problems can just cause other problems. That is, writing the specs is a useful first step. | Why should my users suffer this cost? We're not back at this again are we? I thought this had already been made clear ... no-one is asking your users to do anything. We're suggesting that you should change your implementation and then make that available to your users if they want it. You can even delay making the changed version available until there are other updates to the code for other reasons if you like (no need to actually go do the work of making a distribution just for this). Just make the change in your master sources (it doesn't even need any real doc, since it is changing nothing anyone will ever notice) and then let natural selection play its part. You have yet to explain what is difficult/hard/impossible/unreasonable about that. I seem to recall that people who have seen your code have even demonstrated the change that needs to be made... | As I said, that's rarely true. The server almost always has the A record | in its authoritative data, if it has it at all. Perhaps you have | forgotten the definition of glue? No. As I said, the server will often be authoritative for the A record involved (not always, but often), and so the A record didn't come from glue in the server's data. But the resolver that receives the reply has no way to know that - all it sees is an A record that isn't from the same zone as the answer. That's glue. There's no way at all for the resolver to know whether the server was authoritative or not. | Certainly. But there's no support for Vixie's credibility rules, or for | your fraudulently labelled ``clarifications'' in RFC 2181. No question but what started out as clarifications also grew some new specifications (as I recall it, 2181 even makes that clear, despite the title still saying clarifications). So? Call this part "corrections" if you like. | Your sarcastic comments about my deliberate violation of RFC 2181 | [...] sound rather stupid in light of the | fact that BIND 9 also deliberately violates RFC 2181. No, it isn't that your server violates 2181 that I commented on. Nor do I care much whether BIND9 does (nor whether the two of them ignore the same part). When 2181 gets considered for elevation to DS it will get reviewed, and any parts of it that are generally considered to be wrong will either get deleted, or corrected. That's a normal part of our iterative standards development process. What was ludicrous in your statement was the suggestion that the deployed base that you created by deliberately ignoring 2181 was, in itself, a reason for 2181 to be changed. This seems to be based on your flawed assumption that all the IETF does is document that which exists in the wild. That's not true - what we do is document what should exist out there, as best we can judge it. That is heavily influenced by what actually is out there of course - on the assumption that we wouldn't be shipping stuff if we didn't believe it was the right thing - but not always. eg: back in the distant past, old BINDs implemented the SOA.serial field as a (perhaps signed, I forget) integer, with a range from 0 to 2^32-1 (or -2^31 .. 2^31-1 if it was signed). Upon reaching the max value it simply stopped. And the 0 was "magic" (may still be in BIND8, though I hope that is fixed in BIND9). Back then, BIND was essentially the whole deployed base. According to your theory on what the IETF should do, it should have simply documented the serial number as a simple bounded integer value, to match what was actually deployed. But that would have been stupid - not a rational definition of the field, instead, the (almost) whole deployed base was simply made to fix the bug, and now we have serial numbers everywhere that actually work the way they were designed to work. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jul 19 13:49:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23035 for ; Thu, 19 Jul 2001 13:49:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15NHVX-000OVz-00 for namedroppers-data@psg.com; Thu, 19 Jul 2001 10:22:39 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15NHVX-000OVt-00 for namedroppers@ops.ietf.org; Thu, 19 Jul 2001 10:22:39 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15NHVW-0000OH-00 for namedroppers@ops.ietf.org; Thu, 19 Jul 2001 13:22:38 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "Levon Esibov" To: "Stuart Cheshire" , Subject: RE: RFC 2782: SRV weight evaluation Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Thu, 19 Jul 2001 10:22:39 -0700 Content-Transfer-Encoding: 7bit Stuart, We had similar discussion a year ago and agreed to clarify the text to indicate that the "uniform random number" stands for "uniform random real number". Please, see the latest update to RFC 2782 at http://search.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2782bis-01.t xt.=20 Levon -----Original Message----- From: Stuart Cheshire [mailto:cheshire@apple.com]=20 Sent: Friday, June 15, 2001 6:45 PM To: namedroppers@ops.ietf.org Subject: RFC 2782: SRV weight evaluation > In the presence of records containing weights greater > than 0, records with weight 0 should have a very small chance of > being selected. I think we can improve on this. If weights are to have a sensible=20 intuitive meaning, then (in the presence of records containing weights=20 greater than 0) records with weight 0 should *never* be selected. It=20 should make no sense to mix zero and nonzero weights in one RRSet. SRV=20 already supports 16-bit weights, so one server can be preferred 65535=20 times as much as another -- i.e. one server used for 99.998% of all=20 queries and the other used for less than 0.002%. If we really need a way to indicate resolution below 0.002%, SRV should use 32-bit weight values. I suggest the following wording: > In the presence of records containing weights greater > than 0, records with weight 0 should never be selected. --- > To select a target to be contacted next, arrange all SRV RRs > (that have not been ordered yet) in any order, except that all > those with weight 0 are placed at the beginning of the list. > > Compute the sum of the weights of those RRs, and with each RR > associate the running sum in the selected order. Then choose a > uniform random number between 0 and the sum computed > (inclusive), and select the RR whose running sum value is the > first in the selected order which is greater than or equal to > the random number selected. The target host specified in the > selected SRV RR is the next one to be contacted by the client. > Remove this SRV RR from the set of the unordered SRV RRs and > apply the described algorithm to the unordered SRV RRs to select > the next target host. Continue the ordering process until there > are no unordered SRV RRs. This process is repeated for each > Priority. Is a "uniform random number between 0 and the sum computed (inclusive)"=20 intended to imply a uniform random integer, or a uniform random real (aka=20 floating point)?=20 If it is a real number, then saying "inclusive" makes no difference, and the probability of an SRV record with weight zero being chosen (while=20 other SRV records remain at the same priority) is strictly zero, which is=20 fine, and logical. However, floating point calculation is sometimes less efficient to=20 implement, and many implementers are likely to select a random *integer* (which is also suggested by the use of the word "inclusive"). This leads to the following off-by-one bug: Suppose you have two SRV records, one with weight zero and one with=20 weight one: _smtp._tcp.apple.com 0 IN SRV 0 0 25 dontuse.apple.com _smtp._tcp.apple.com 0 IN SRV 0 1 25 mailer.apple.com Sorted List: dontuse.apple.com Weight 0 Running Sum 0 mailer.apple.com Weight 1 Running Sum 1 If you now "choose a uniform random integer between 0 and 1 (inclusive)",=20 the values 0 and 1 are equally likely: Value 0 selects dontuse.apple.com (Running Sum 0 is >=3D Random Integer = 0) Value 1 selects mailer.apple.com (Running Sum 1 is >=3D Random Integer = 1) In this example, "mailer" and "dontuse" are equally likely to be selected=20 (and hence get half the mail load each) which was probably not what the=20 sysadmin had in mind when he or she set up relative weights of zero and=20 one. (I realize the desired effect here could have been achieved using=20 different priorities, but the point I'm making is that the weights, as=20 given in this example, do not yield the intuitive result.) To give another example, consider this, where each SRV has the same=20 weight: _smtp._tcp.apple.com 0 IN SRV 0 1 25 mailer1.apple.com _smtp._tcp.apple.com 0 IN SRV 0 1 25 mailer2.apple.com Sorted List: mailer1.apple.com Weight 1 Running Sum 1 mailer2.apple.com Weight 1 Running Sum 2 If you now "choose a uniform random integer between 0 and 2 (inclusive)",=20 the values 0, 1 and 2 are all equally likely: Value 0 selects mailer1.apple.com (Running Sum 1 is >=3D Random Integer = 0) Value 1 selects mailer1.apple.com (Running Sum 1 is >=3D Random Integer = 1) Value 2 selects mailer2.apple.com (Running Sum 2 is >=3D Random Integer = 2) Here, "mailer1" gets twice as much load as "mailer2" -- again, probably=20 not what the sysadmin had in mind when he or she set up equal relative=20 weights. The problem is the off-by-one bug: If the weights sum to n, then the RFC currently says to select one of (n+1) possible different random integers,=20 and it is the extra "+1" that is skewing the results. The text can be=20 fixed by changing it to say: > To select a target to be contacted next, arrange all SRV RRs (that > have not been ordered yet) in any order. >=20 > Compute the sum of the weights of those RRs, and with each RR > associate the running sum in the selected order. If all RRs have > weight zero (i.e. the sum is zero), then select any of the RRs at > random. Otherwise, choose a uniform random integer between 0 and the > sum computed minus one (inclusive), and select the RR whose running > sum value is the first in the selected order which is greater than > the random integer selected. The target host specified in the > selected SRV RR is the next one to be contacted by the client. Remove > this SRV RR from the set of the unordered SRV RRs and apply the > described algorithm to the unordered SRV RRs to select the next > target host. Continue the ordering process until there are no > unordered SRV RRs. This process is repeated for each Priority. Note that the only changes here are: 1. A random integer is selected, instead of a random real 2. The sum is from "zero to n-1", instead of "zero to n" 3. The comparison is "greater than" instead of "greater than or equal" This modified text produces the mathematically correct result without=20 resorting to floating point arithmetic. In fact it is better, because all=20 floating point arithmetic is an imprecise approximation of real numbers, and usually produces a slightly imprecise result. This integer algorithm produces mathematically perfect results, with no rounding errors. To repeat the above examples again: First Example _smtp._tcp.apple.com 0 IN SRV 0 0 25 dontuse.apple.com _smtp._tcp.apple.com 0 IN SRV 0 1 25 mailer.apple.com Sorted List: dontuse.apple.com Weight 0 Running Sum 0 mailer.apple.com Weight 1 Running Sum 1 Choose a uniform random integer between 0 and n-1 inclusive: The only=20 answer is zero. Value 0 does not select dontuse (Running Sum 0 not > Random Integer 0) Value 0 selects mailer.apple.com (Running Sum 1 is > Random Integer 0) In this example, "mailer" is used all the time, and dontuse is never=20 used. (Correct -- don't mix zero and nonzero weights in one RRSet!) Second Example _smtp._tcp.apple.com 0 IN SRV 0 1 25 mailer1.apple.com _smtp._tcp.apple.com 0 IN SRV 0 1 25 mailer2.apple.com Sorted List: mailer1.apple.com Weight 1 Running Sum 1 mailer2.apple.com Weight 1 Running Sum 2 If you now "choose a uniform random integer between 0 and 1", the values 0 and 1 are all equally likely: Value 0 selects mailer1.apple.com (Running Sum 1 is > Random Integer 0) Value 1 selects mailer2.apple.com (Running Sum 2 is > Random Integer 1) Here, "mailer1" and "mailer2" get equal load. This is correct. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.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. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jul 19 22:33:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA18962 for ; Thu, 19 Jul 2001 22:33:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15NPXv-000CPz-00 for namedroppers-data@psg.com; Thu, 19 Jul 2001 18:57:39 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15NPXu-000CPs-00 for namedroppers@ops.ietf.org; Thu, 19 Jul 2001 18:57:39 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15NPXu-00024U-00 for namedroppers@ops.ietf.org; Thu, 19 Jul 2001 21:57:38 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: TKEY compatibility problems References: <200107191320.f6JDKMD23052@kcmso1.proxy.att.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Thu, 19 Jul 2001 18:57:39 -0700 Content-Transfer-Encoding: 7bit Robert Elz writes: > "chokes" in any reasonable implementation will be "ignores the record". That's not what Wellington told us. ``There would be a problem if a client was sanity checking the response,'' he said. I agree that this potential compatibility problem disappears if TKEY clients ignore unexpected records. Guess what? That also eliminates the potential compatibility problems with AXFR! > You have yet to explain what is difficult/hard/impossible/unreasonable > about that. The benefits are nonexistent. The harms include encouraging further disregard for compatibility. What stops incompetent implementors from demanding another code change every week? Ignore AXFR AR, discard TKEY, ignore types 128-255, recognize IXFR, ignore MS garbage. This is not a sane way to handle optional protocol extensions. > What was ludicrous in your statement was the suggestion that the > deployed base that you created by deliberately ignoring 2181 was, in > itself, a reason for 2181 to be changed. Huh? I explicitly pointed out an important violation of RFC 2181 by * the BIND 4 cache, * the BIND 8 cache, * the BIND 9 cache, and * my cache. Later I objected to RFC 2181 as being useless, harmful, and out of line with existing practice. Where did you get the idea that I was talking about only my cache? ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jul 19 23:20:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA06196 for ; Thu, 19 Jul 2001 23:20:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15NQR1-000EHf-00 for namedroppers-data@psg.com; Thu, 19 Jul 2001 19:54:35 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15NQR1-000EHZ-00 for namedroppers@ops.ietf.org; Thu, 19 Jul 2001 19:54:35 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15NQR1-0000DI-00 for namedroppers@ops.ietf.org; Thu, 19 Jul 2001 22:54:35 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Stuart Cheshire To: "Levon Esibov" , Subject: RE: RFC 2782: SRV weight evaluation Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Thu, 19 Jul 2001 19:54:35 -0700 Content-Transfer-Encoding: 7bit >Stuart, > >We had similar discussion a year ago and agreed to clarify the text to >indicate that the "uniform random number" stands for "uniform random >real number". Please, see the latest update to RFC 2782 at >http://search.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2782bis-01.t >xt. I am very puzzled Levon. I mean that sincerely. I suggested a tiny change to the wording that gives mathematically precise results using simple integer arithmetic. Your response was to change the spec to use real arithmetic. No computer ever made can do real arithmetic. All computers use floating point (or rational) arithmetic which is just an approximation of real arithmetic. Any student of numerical analysis will tell you that estimating the deviation of floating point arithmetic from real arithmetic is very hard, so it is not always even obvious how imprecise the approximation is. Also, floating point arithmetic is more costly to compute than integer arithmetic on many processors. Why would you prefer an inaccurate costly algorithm when there is a precise cheap one available? I have enough respect for you that I know it can't be "Not Invented Here" syndrome, but I just don't understand your objection. > In the presence of records containing weights greater > than 0, records with weight 0 should have a very small chance of > being selected. If the statistical weight of a record is going to be proportional to its "SRV weight" (tautologically true, I hope) then records with weight 0 should have zero weight. They should *never* be selected, while records at the same priority with non-zero weight remain. Why say "a very small chance"? That's like saying that a particle with zero mass should have "a very small chance" of experiencing gravitational attraction. That's not what zero means. Zero does not mean "very small". Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.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. From owner-namedroppers@ops.ietf.org Fri Jul 20 08:51:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA18963 for ; Fri, 20 Jul 2001 08:51:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15NZRw-00068S-00 for namedroppers-data@psg.com; Fri, 20 Jul 2001 05:32:08 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15NZRv-00068L-00 for namedroppers@ops.ietf.org; Fri, 20 Jul 2001 05:32:08 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15NZRq-0000b2-00 for namedroppers@ops.ietf.org; Fri, 20 Jul 2001 08:32:02 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Stuart Cheshire To: Subject: Multicast DNS and Multicast DNS Service Discovery Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Fri, 20 Jul 2001 05:32:08 -0700 Content-Transfer-Encoding: 7bit Last week I submitted two Internet Drafts, one proposing how I think Multicast DNS should work, and a second proposing how to do Service Discovery over Multicast DNS (or indeed conventional unicast DNS). The primary difference between my draft and "draft-ietf-dnsext-mdns-01.txt" is the philosophy about how subdomains of the "local.arpa." domain are delegated. The "draft-ietf..." document proposes that hosts running Multicast DNS Responders each assert an SOA record, thereby claiming to be the sole authority for their own little zone within the "local.arpa." domain. That approach makes it difficult for different hosts to manage two or more resource records with the same name, a feature that has some benefits. My draft proposes that subdomains of the "local.arpa." domain can never be delegated, and instead "local.arpa." is managed as a single zone implemented by a loose collection of hosts cooperatively executing a distributed algorithm. From that philosophical difference, a variety of implementation differences emerge. I'm sure there will be a lot of questions and disagreements, which I will try to answer both on the list and at the meeting in London. >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > Title : Performing DNS queries via IP Multicast > Author(s) : S. Cheshire > Filename : draft-cheshire-dnsext-multicastdns-00.txt > Pages : 19 > Date : 17-Jul-01 > >Multicast DNS is a really obvious idea, whose time has finally come. >This draft proposes one possible way of making it work. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-cheshire-dnsext-multicastdns-00.txt >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Discovering Named Instances of Abstract Services using > DNS > Author(s) : S. Cheshire > Filename : draft-cheshire-dnsext-nias-00.txt > Pages : 10 > Date : 17-Jul-01 > >This document proposes a convention for naming and structuring DNS >resource records that allows clients to discover a list of named >instances of a particular given desired type of service. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-cheshire-dnsext-nias-00.txt Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.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. From owner-namedroppers@ops.ietf.org Fri Jul 20 08:56:50 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA20128 for ; Fri, 20 Jul 2001 08:56:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15NZeP-0006U4-00 for namedroppers-data@psg.com; Fri, 20 Jul 2001 05:45:01 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15NZeO-0006Tw-00 for namedroppers@ops.ietf.org; Fri, 20 Jul 2001 05:45:00 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15NZeI-0000bi-00 for namedroppers@ops.ietf.org; Fri, 20 Jul 2001 08:44:54 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: "D. J. Bernstein" cc: namedroppers@ops.ietf.org Subject: Re: TKEY compatibility problems In-Reply-To: References: <200107191320.f6JDKMD23052@kcmso1.proxy.att.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Fri, 20 Jul 2001 05:45:01 -0700 Content-Transfer-Encoding: 7bit Date: Thu, 19 Jul 2001 18:57:39 -0700 From: "D. J. Bernstein" Message-ID: | I agree that this potential compatibility problem disappears if TKEY | clients ignore unexpected records. Guess what? That also eliminates the | potential compatibility problems with AXFR! Yes, exactly, this is what we have been trying to tell you - just ignore unexpected records (anything at all in the auth or additional sections) and potential compatibility problems will be eliminated. Glad you have finally conceded the point. | What stops incompetent implementors from | demanding another code change every week? Because the community as a whole will react negatively. Here the community as a whole is telling you this is a good thing to do, and in fact, this was what was always intended that you should do - it is just that the doc didn't say that as well as it should, it just assumed that readers would be able to infer it. It is quite correct to point out that the doc wasn't clear - and the solution to that is to clarify it. | Huh? I explicitly pointed out an important violation of RFC 2181 by | | * the BIND 4 cache, Yes, it was what it had been doing, that everyone conceded was incorrect and harming the internet - it was to document a better scheme (and knowingly a new scheme) that those rules were created (after quite a bit of discussion). That's what the WG agreed that servers (not having dnssec yet available to them) should be doing to improve things. No-one was pretending that it was current practice. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jul 20 08:57:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA20198 for ; Fri, 20 Jul 2001 08:57:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15NZcZ-0006QL-00 for namedroppers-data@psg.com; Fri, 20 Jul 2001 05:43:07 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15NZcY-0006QF-00 for namedroppers@ops.ietf.org; Fri, 20 Jul 2001 05:43:06 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15NZcT-0000bR-00 for namedroppers@ops.ietf.org; Fri, 20 Jul 2001 08:43:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Alain Durand To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Cc: randy@psg.com, tony@tndh.net, fink@es.net, Olafur Gudmundsson Subject: NGtrans - DNSext joint meeting, call for participation Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Fri, 20 Jul 2001 05:43:07 -0700 Content-Transfer-Encoding: 7bit The NGtrans/DNSext chairs would like to make a call for participation in the upcoming joint meeting. The goal of the meeting is to facilitate consensus on how IPv6 addresses are represented in DNS and related issues. This meeting requires extensive homework by participants and the chairs would like to request submission of documents for a reading list for this meeting. The output from the meeting will be draft consensus proposal. Here is non exclusive a list of relevant topics: 1 - Design tradeoffs in DNS and IPv6 (AAAA, A6, DNAME, bit string) - DNS operational considerations including DNSSEC costs in regard of address record format - DNS implementation complications due to address record format - IPv6 Remembering requirements and impact on address record format - Case for A6 - Case for AAAA - transition from ip6.int to ip6.arpa - transition from AAAA to A6 2 - tools/protocols/strategies to bridge IPv6 and IPv4 DNS resolution Anybody wishing to make a presentation should send a draft to the chairs of this meeting before July 26th 2001, 21:00 UTC (that is, 2pm PDT, 5pm EDT, 11pm MEST) - Alain Durand - Olafur Gudmundsson Drafts not yet published by the ID editor are acceptable contributions (please include an URL). The chairs will review the list of submission, derived the actual agenda of the meeting from it and send all reading materials to the DNSext and NGtrans mailing list no later than July 27th, 21:00 UTC. - Alain & Olafur. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jul 20 08:59:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA20859 for ; Fri, 20 Jul 2001 08:59:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15NZg9-0006W0-00 for namedroppers-data@psg.com; Fri, 20 Jul 2001 05:46:49 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15NZg9-0006Vu-00 for namedroppers@ops.ietf.org; Fri, 20 Jul 2001 05:46:49 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15NZg3-0000cA-00 for namedroppers@ops.ietf.org; Fri, 20 Jul 2001 08:46:43 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "D. J. Bernstein" To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: NGtrans - DNSext joint meeting, call for participation References: <5.1.0.14.0.20010719220418.03084d78@jurassic> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Fri, 20 Jul 2001 05:46:49 -0700 Content-Transfer-Encoding: 7bit 1. I won't be at the meeting. However, I strongly support elimination of A6/DNAME: http://cr.yp.to/djbdns/killa6.html 2. There's a common error in the evaluation of DNSSEC signing costs. I'd like to draw attention to a new section that I've added to my web page to analyze this error: http://cr.yp.to/djbdns/killa6.html#signingcosts 3. I don't understand why this is an ngtrans issue rather than an ipngwg issue. The question is not how to move smoothly to A6/DNAME; the question is whether we want A6/DNAME at all. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jul 20 09:02:09 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21457 for ; Fri, 20 Jul 2001 09:02:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15NZjR-0006el-00 for namedroppers-data@psg.com; Fri, 20 Jul 2001 05:50:13 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15NZjQ-0006eQ-00 for namedroppers@ops.ietf.org; Fri, 20 Jul 2001 05:50:13 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15NZjJ-0000cW-00 for namedroppers@ops.ietf.org; Fri, 20 Jul 2001 08:50:05 -0400 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org Subject: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Fri, 20 Jul 2001 05:50:13 -0700 --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 : Redefinition of DNS AD bit Author(s) : B. Wellington, O. Gudmundsson Filename : draft-ietf-dnsext-ad-is-secure-03.txt Pages : 5 Date : 19-Jul-01 Based on implementation experience, the current definition of the AD bit in the DNS header is not useful. This draft changes the specification so that the AD bit is only set on answers where signatures have been cryptographically verified. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ad-is-secure-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-ad-is-secure-03.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-ad-is-secure-03.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: <20010719145530.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-ad-is-secure-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-ad-is-secure-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010719145530.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jul 20 09:07:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA22429 for ; Fri, 20 Jul 2001 09:07:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15NZjN-0006dq-00 for namedroppers-data@psg.com; Fri, 20 Jul 2001 05:50:09 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15NZjN-0006dX-00 for namedroppers@ops.ietf.org; Fri, 20 Jul 2001 05:50:09 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15NZjG-0000cT-00 for namedroppers@ops.ietf.org; Fri, 20 Jul 2001 08:50:02 -0400 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org Subject: I-D ACTION:draft-ietf-dnsext-mdns-02.txt Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Fri, 20 Jul 2001 05:50:09 -0700 --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 : Multicast DNS Author(s) : L. Esibov, B. Aboba, D. Thaler Filename : draft-ietf-dnsext-mdns-02.txt Pages : 16 Date : 19-Jul-01 Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a DNS server. In order to allow DNS name resolution in such environments, the use of a multicast DNS is proposed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-mdns-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-mdns-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010719145520.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010719145520.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jul 20 09:09:04 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA22719 for ; Fri, 20 Jul 2001 09:09:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15NZjJ-0006dU-00 for namedroppers-data@psg.com; Fri, 20 Jul 2001 05:50:05 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15NZjI-0006dL-00 for namedroppers@ops.ietf.org; Fri, 20 Jul 2001 05:50:04 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15NZjB-0000cR-00 for namedroppers@ops.ietf.org; Fri, 20 Jul 2001 08:49:57 -0400 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org Subject: I-D ACTION:draft-ietf-dnsext-delegation-signer-01.txt Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Fri, 20 Jul 2001 05:50:05 -0700 --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 : Delegation Signer record in parent Author(s) : O. Gudmundsson Filename : draft-ietf-dnsext-delegation-signer-01.txt Pages : 11 Date : 19-Jul-01 One of the biggest problems in DNS occur when records of the same type can appear on both sides of an delegation. If the contents of these sets differs clients can get confused. RFC2535 KEY records follows the same model as for NS records, parent is responsible for the records but the child is responsible for the contents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-delegation-signer-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-delegation-signer-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-delegation-signer-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: <20010719145511.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-delegation-signer-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-delegation-signer-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010719145511.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jul 20 09:15:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA23669 for ; Fri, 20 Jul 2001 09:15:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15NZtl-00075h-00 for namedroppers-data@psg.com; Fri, 20 Jul 2001 06:00:53 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15NZtl-00075b-00 for namedroppers@ops.ietf.org; Fri, 20 Jul 2001 06:00:53 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15NZtY-0000dh-00 for namedroppers@ops.ietf.org; Fri, 20 Jul 2001 09:00:40 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Alain Durand Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se, tony@tndh.net, fink@es.net, Olafur Gudmundsson Subject: Re: NGtrans - DNSext joint meeting, call for participation References: <5.1.0.14.0.20010719220418.03084d78@jurassic> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Fri, 20 Jul 2001 06:00:53 -0700 Content-Transfer-Encoding: 7bit alain, you have a bug in your mail system. somehow the line which said that rob austien's draft will be used as the agenda driver got dropped. you may want to try to send the agreed message again. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jul 20 10:42:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22731 for ; Fri, 20 Jul 2001 10:42:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Nasd-00094F-00 for namedroppers-data@psg.com; Fri, 20 Jul 2001 07:03:47 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15Nasd-000948-00 for namedroppers@ops.ietf.org; Fri, 20 Jul 2001 07:03:47 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15NasL-0000gK-00 for namedroppers@ops.ietf.org; Fri, 20 Jul 2001 10:03:29 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roy Arends To: Cc: , Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Fri, 20 Jul 2001 07:03:47 -0700 Content-Transfer-Encoding: 7bit Hello, I would like to see some clarifications on the ***** marked sections. Thanks, Roy ------------------------------------------------------------------------ INTERNET-DRAFT AD bit set on secure answers July 2001 2 - Setting of AD bit Section 6.1 of RFC2535 says: "The AD bit MUST NOT be set on a response unless all of the RRs in the answer and authority sections of the response are either Authenticated or Insecure." The changes are to delete the words "either" and "or Insecure" from the sentence. The replacement text reads: "The AD bit MUST NOT be set on a response unless all of the RRsets in the answer and authority sections of the response are Authenticated." "The AD bit SHOULD be set if and only if all RRs in the answer section and any relevant negative response RRs in that authority section are Authenticated." AD should be set if and only if all RRs in the answer section, and any relevant negative response RRs in the authority section are Authenticated. The AD bit MUST NOT be set on a response unless all of the RRsets in the answer and authority sections are Authenticated. A resolver MUST NOT blindly trust the AD bit unless it communicates with the server over secure transport mechanism or using message authentication such as TSIG[RFC2845] or SIG(0)[RFC2931], and the resolver policy is that it can trust the server. Any DNS server supporting the OK bit MUST support this definition of the AD bit. ***** OK bit as in DNSSEC OK bit, specified in draft-ietf-dnsext-dnssec-okbit-02.txt ? If this is the case, please refer to it as DO (DNSSEC OK) bit. ***** A DNS server following this modified specification will only set the AD bit when it has cryptographically verified the data in the answer. In the case of a primary server for a secure zone, the data MAY be considered Authenticated, depending on local policy. ***** I don't know how to read this. In the case of a primary server for a secure zone, the data MAY be considered Authenticated, depending on local policy, when what ? When the AD bit is set ? May it set the AD bit if it is the primary server for a secure zone, though the zone is actually not authenticated by the server ? The last sentence of the above section is a bit confusing. ***** Secondary servers SHOULD NOT consider data Authenticated unless the zone was transfered securely or the data was verified. ***** or ? So if the zone was transferred securely, the secondary can consider the data Authenticated (and thus, set the AD bit) when it actually did not verify the contents of the zone ? I don't like it. ***** 3 - Interpretation of the AD bit A response containing data marked Insecure in the answer or authority section will never have the AD bit set. In this case, the resolver SHOULD treat the data as Insecure whether or not SIG records are present. 4 - Security Considerations: This document redefines a bit in the DNS header. If a resolver trusts the value of the AD bit, it must be sure that the server is using the updated definition, which is any server supporting the OK bit. ***** What are the implictions for the AD bit when the CD bit is set in a query. MAY/SHOULD[NOT]/MUST[NOT] a response have the AD bit set when CD (and optionally DO) bit is set ? The resolver is probably not interested in AD bit when CD bit is set, but a clarification would be good. ***** to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jul 20 14:46:01 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27229 for ; Fri, 20 Jul 2001 14:45:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Nf5R-000GSW-00 for namedroppers-data@psg.com; Fri, 20 Jul 2001 11:33:17 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15Nf5R-000GSQ-00 for namedroppers@ops.ietf.org; Fri, 20 Jul 2001 11:33:17 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Nf54-0000p4-00 for namedroppers@ops.ietf.org; Fri, 20 Jul 2001 14:32:54 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Brian Wellington To: Roy Arends cc: , Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Fri, 20 Jul 2001 11:33:17 -0700 Content-Transfer-Encoding: 7bit On Fri, 20 Jul 2001, Roy Arends wrote: > Hello, I would like to see some clarifications on the ***** marked > sections. > ***** > OK bit as in DNSSEC OK bit, specified in draft-ietf-dnsext-dnssec-okbit-02.txt > ? If this is the case, please refer to it as DO (DNSSEC OK) bit. > ***** Sure. Olafur, want to fix this, since you have the source? > A DNS server following this modified specification will > only set the AD bit when it has cryptographically verified the data > in the answer. In the case of a primary server for a secure zone, > the data MAY be considered Authenticated, depending on local policy. > > ***** > I don't know how to read this. > > In the case of a primary server for a secure zone, the data MAY be > considered Authenticated, depending on local policy, when what ? > When the AD bit is set ? May it set the AD bit if it is the primary server > for a secure zone, though the zone is actually not authenticated by the > server ? The last sentence of the above section is a bit confusing. > ***** "Authenticated" is a term defined in RFC 2535, section 6. It is normally used when referring to the security status of data on a recursive server. This particular text says that the server may consider locally configured data to be in the "Authenticated" state. > Secondary servers SHOULD NOT consider data Authenticated unless the > zone was transfered securely or the data was verified. > > ***** > or ? So if the zone was transferred securely, the secondary can consider > the data Authenticated (and thus, set the AD bit) when it actually did not > verify the contents of the zone ? I don't like it. > ***** If the zone is transferred securely, then the secondary is guaranteed to have the same data as the primary. The primary is allowed to set AD without verifying the data also. > This document redefines a bit in the DNS header. If a resolver > trusts the value of the AD bit, it must be sure that the server is > using the updated definition, which is any server supporting the OK > bit. > > ***** > What are the implictions for the AD bit when the CD bit is set in a query. > MAY/SHOULD[NOT]/MUST[NOT] a response have the AD bit set when CD (and > optionally DO) bit is set ? The resolver is probably not interested in AD > bit when CD bit is set, but a clarification would be good. > ***** There are no implications. Whether the AD bit is on in a response reflects the security status of data, not whether CD was set in the query. Even if CD is set, the response can have AD set if the data had already been verified. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jul 20 14:51:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29160 for ; Fri, 20 Jul 2001 14:51:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15NfCd-000GgF-00 for namedroppers-data@psg.com; Fri, 20 Jul 2001 11:40:43 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15NfCc-000Gg8-00 for namedroppers@ops.ietf.org; Fri, 20 Jul 2001 11:40:42 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15NfCG-0000pr-00 for namedroppers@ops.ietf.org; Fri, 20 Jul 2001 14:40:20 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Brian Wellington To: Roy Arends cc: , Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Fri, 20 Jul 2001 11:40:43 -0700 Content-Transfer-Encoding: 7bit On Fri, 20 Jul 2001, Roy Arends wrote: > Ah, so without cryptographicly authenticating the data which is read > from disk, the primary could set the AD bit on responses since it may > consider locally configured data to be in authenticated state. > > I totally object to this. > > I also do not see a reason for this. This discussion has already been had several times. If you don't trust the on-disk zone data, why would you trust anything else about the server? A key configured into named.conf could be maliciously or accidentally changed in the same way as the master file. The data could expire at some point after the server was loaded, and the server would still give out bad data. In short, verifying data on load has no positive effects, and has the huge negative effect that it exponentially increases server load time. Treating on-disk signed data as "Authenticated" is reasonable behavior, and a server may choose to implement this policy. > > > Secondary servers SHOULD NOT consider data Authenticated unless the > > > zone was transfered securely or the data was verified. > > > > > > ***** > > > or ? So if the zone was transferred securely, the secondary can consider > > > the data Authenticated (and thus, set the AD bit) when it actually did not > > > verify the contents of the zone ? I don't like it. > > > ***** > > > > If the zone is transferred securely, then the secondary is guaranteed to > > have the same data as the primary. The primary is allowed to set AD > > without verifying the data also. > > I totally object to this ! > > TSIG/SIG(0) can transfer a zone securely, even if the data at the > primary is corrupt. > > Only when a server (caching or authoritative) has cryptographicly verified > (according to the local policy) the contents of the answer and authority > section in a response its about to give out, the AD bit may be set. > > IMHO local policy MUST NOT include setting AD bit while the contents are > actually not cryptographicly verified. Again, this is not true. You agree that a secure transfer guarantees that the secondary has the same data as the primary, so if the primary trusts it, the secondary should also. > > > This document redefines a bit in the DNS header. If a resolver > > > trusts the value of the AD bit, it must be sure that the server is > > > using the updated definition, which is any server supporting the OK > > > bit. > > > > > > ***** > > > What are the implictions for the AD bit when the CD bit is set in a query. > > > MAY/SHOULD[NOT]/MUST[NOT] a response have the AD bit set when CD (and > > > optionally DO) bit is set ? The resolver is probably not interested in AD > > > bit when CD bit is set, but a clarification would be good. > > > ***** > > > > There are no implications. Whether the AD bit is on in a response > > reflects the security status of data, not whether CD was set in the query. > > Even if CD is set, the response can have AD set if the data had already > > been verified. > > I agree totally, but IMHO it would be good if this independence of CD (and > DO) is documented. The lack of mention of CD seems to implicitly indicate this, but I don't care too much if more text is added. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jul 20 14:51:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29238 for ; Fri, 20 Jul 2001 14:51:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15NfAK-000Gak-00 for namedroppers-data@psg.com; Fri, 20 Jul 2001 11:38:20 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15NfAJ-000Gae-00 for namedroppers@ops.ietf.org; Fri, 20 Jul 2001 11:38:19 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Nf9x-0000pk-00 for namedroppers@ops.ietf.org; Fri, 20 Jul 2001 14:37:57 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roy Arends To: Brian Wellington Cc: Roy Arends , , Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Fri, 20 Jul 2001 11:38:20 -0700 Content-Transfer-Encoding: 7bit On Fri, 20 Jul 2001, Brian Wellington wrote: > On Fri, 20 Jul 2001, Roy Arends wrote: > > > Hello, I would like to see some clarifications on the ***** marked > > sections. > > > A DNS server following this modified specification will > > only set the AD bit when it has cryptographically verified the data > > in the answer. In the case of a primary server for a secure zone, > > the data MAY be considered Authenticated, depending on local policy. > > > > ***** > > I don't know how to read this. > > > > In the case of a primary server for a secure zone, the data MAY be > > considered Authenticated, depending on local policy, when what ? > > When the AD bit is set ? May it set the AD bit if it is the primary server > > for a secure zone, though the zone is actually not authenticated by the > > server ? The last sentence of the above section is a bit confusing. > > ***** > > "Authenticated" is a term defined in RFC 2535, section 6. It is normally > used when referring to the security status of data on a recursive server. > This particular text says that the server may consider locally configured > data to be in the "Authenticated" state. Ah, so without cryptographicly authenticating the data which is read from disk, the primary could set the AD bit on responses since it may consider locally configured data to be in authenticated state. I totally object to this. I also do not see a reason for this. > > Secondary servers SHOULD NOT consider data Authenticated unless the > > zone was transfered securely or the data was verified. > > > > ***** > > or ? So if the zone was transferred securely, the secondary can consider > > the data Authenticated (and thus, set the AD bit) when it actually did not > > verify the contents of the zone ? I don't like it. > > ***** > > If the zone is transferred securely, then the secondary is guaranteed to > have the same data as the primary. The primary is allowed to set AD > without verifying the data also. I totally object to this ! TSIG/SIG(0) can transfer a zone securely, even if the data at the primary is corrupt. Only when a server (caching or authoritative) has cryptographicly verified (according to the local policy) the contents of the answer and authority section in a response its about to give out, the AD bit may be set. IMHO local policy MUST NOT include setting AD bit while the contents are actually not cryptographicly verified. > > This document redefines a bit in the DNS header. If a resolver > > trusts the value of the AD bit, it must be sure that the server is > > using the updated definition, which is any server supporting the OK > > bit. > > > > ***** > > What are the implictions for the AD bit when the CD bit is set in a query. > > MAY/SHOULD[NOT]/MUST[NOT] a response have the AD bit set when CD (and > > optionally DO) bit is set ? The resolver is probably not interested in AD > > bit when CD bit is set, but a clarification would be good. > > ***** > > There are no implications. Whether the AD bit is on in a response > reflects the security status of data, not whether CD was set in the query. > Even if CD is set, the response can have AD set if the data had already > been verified. I agree totally, but IMHO it would be good if this independence of CD (and DO) is documented. 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. From owner-namedroppers@ops.ietf.org Fri Jul 20 15:06:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03393 for ; Fri, 20 Jul 2001 15:06:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Nf1g-000GMa-00 for namedroppers-data@psg.com; Fri, 20 Jul 2001 11:29:24 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15Nf1f-000GMQ-00 for namedroppers@ops.ietf.org; Fri, 20 Jul 2001 11:29:24 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Nf1J-0000ol-00 for namedroppers@ops.ietf.org; Fri, 20 Jul 2001 14:29:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Matt Crawford To: "D. J. Bernstein" Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: NGtrans - DNSext joint meeting, call for participation In-reply-to: "20 Jul 2001 05:46:49 PDT." Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Fri, 20 Jul 2001 11:29:24 -0700 Content-Transfer-Encoding: 7bit > 2. There's a common error in the evaluation of DNSSEC signing costs. I'd > like to draw attention to a new section that I've added to my web page > to analyze this error: http://cr.yp.to/djbdns/killa6.html#signingcosts Your reasoning is markedly incorrect if applied to A6. If we take site renumbering to be the dominant factor controlling signature-validity times, then the signatures on the A6 records covering interface identifiers and subnets can be valid for a long time, and only one or a small number of A6 rrsets covering the global prefixes needs to be re-signed frequently. > 3. I don't understand why this is an ngtrans issue rather than an ipngwg > issue. The question is not how to move smoothly to A6/DNAME; the > question is whether we want A6/DNAME at all. On this we agree. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jul 20 15:06:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03403 for ; Fri, 20 Jul 2001 15:06:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Nf3n-000GPJ-00 for namedroppers-data@psg.com; Fri, 20 Jul 2001 11:31:35 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15Nf3n-000GPD-00 for namedroppers@ops.ietf.org; Fri, 20 Jul 2001 11:31:35 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Nf3Q-0000oy-00 for namedroppers@ops.ietf.org; Fri, 20 Jul 2001 14:31:12 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: itojun@iijlab.net To: Matt Crawford Cc: "D. J. Bernstein" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: NGtrans - DNSext joint meeting, call for participation In-reply-to: crawdad's message of Fri, 20 Jul 2001 11:59:48 EST. <200107201659.f6KGxmF10588@gungnir.fnal.gov> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Fri, 20 Jul 2001 11:31:35 -0700 Content-Transfer-Encoding: 7bit >> 2. There's a common error in the evaluation of DNSSEC signing costs. I'd >> like to draw attention to a new section that I've added to my web page >> to analyze this error: http://cr.yp.to/djbdns/killa6.html#signingcosts >Your reasoning is markedly incorrect if applied to A6. If we take >site renumbering to be the dominant factor controlling >signature-validity times, then the signatures on the A6 records from what I got from reading djb's webpage, djb's point is that the dominant factor controlling signature-validity time is security, and for that reason he claims it needs to be very short (so there's no real difference in signing overhead for AAAA or A6). so the assumption for the "dominant factor" is totally different between you two. i'm still not sure if djb's claim is right or not, but anyway that's what i got from his note. itojun to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jul 20 15:11:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04633 for ; Fri, 20 Jul 2001 15:11:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15NfDz-000GjS-00 for namedroppers-data@psg.com; Fri, 20 Jul 2001 11:42:07 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15NfDy-000GjM-00 for namedroppers@ops.ietf.org; Fri, 20 Jul 2001 11:42:06 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15NfDc-0000q7-00 for namedroppers@ops.ietf.org; Fri, 20 Jul 2001 14:41:44 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roy Arends To: Brian Wellington Cc: Roy Arends , , Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Fri, 20 Jul 2001 11:42:07 -0700 Content-Transfer-Encoding: 7bit On Fri, 20 Jul 2001, Brian Wellington wrote: > On Fri, 20 Jul 2001, Roy Arends wrote: > > > Ah, so without cryptographicly authenticating the data which is read > > from disk, the primary could set the AD bit on responses since it may > > consider locally configured data to be in authenticated state. > > > > I totally object to this. > > > > I also do not see a reason for this. > > This discussion has already been had several times. I am aware of that. > If you don't trust the on-disk zone data, why would you trust anything > else about the server? A key configured into named.conf could be > maliciously or accidentally changed in the same way as the master > file. The data could expire at some point after the server was > loaded, and the server would still give out bad data. In short, > verifying data on load has no positive effects, and has the huge > negative effect that it exponentially increases server load time. So why not authenticate data on query. That solves the server load problem. Next to that, drop the data (or at least the AD indication) if the sig is expired. > Treating on-disk signed data as "Authenticated" is reasonable behavior, > and a server may choose to implement this policy. This is not acceptable to me. Authenticated data is simply authenticated data, regardless where it comes from. Don't set the AD bit if the data is not authenticated. > > > > Secondary servers SHOULD NOT consider data Authenticated unless the > > > > zone was transfered securely or the data was verified. > > > > > > > > ***** > > > > or ? So if the zone was transferred securely, the secondary can consider > > > > the data Authenticated (and thus, set the AD bit) when it actually did not > > > > verify the contents of the zone ? I don't like it. > > > > ***** > > > > > > If the zone is transferred securely, then the secondary is guaranteed to > > > have the same data as the primary. The primary is allowed to set AD > > > without verifying the data also. > > > > I totally object to this ! > > > > TSIG/SIG(0) can transfer a zone securely, even if the data at the > > primary is corrupt. > > > > Only when a server (caching or authoritative) has cryptographicly verified > > (according to the local policy) the contents of the answer and authority > > section in a response its about to give out, the AD bit may be set. > > > > IMHO local policy MUST NOT include setting AD bit while the contents are > > actually not cryptographicly verified. > > Again, this is not true. You agree that a secure transfer guarantees that > the secondary has the same data as the primary, so if the primary trusts > it, the secondary should also. I agree on the part that the secondary will have the same data as the primary, when securely transferred. But still, the data may be corrupt. TSIG/SIG(0) authenticates resolvers, servers, and will preserve data integrity during transport. Thats it. The data itself may be totally corrupt. DNSSEC is used for origin authentication, and the AD should reflect that. Origin as in Domain, not Server. Regards, Roy Arends Nominum to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jul 21 06:40:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA16583 for ; Sat, 21 Jul 2001 06:40:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15NrEU-00077m-00 for namedroppers-data@psg.com; Sat, 21 Jul 2001 00:31:26 -0700 Received: from roam.psg.com ([147.28.0.10] ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15NrET-00077a-00 for namedroppers@ops.ietf.org; Sat, 21 Jul 2001 00:31:25 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15NrET-0001Fv-00 for namedroppers@ops.ietf.org; Sat, 21 Jul 2001 00:31:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Jakob Schlyter To: Brian Wellington Cc: Roy Arends , , Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sat, 21 Jul 2001 00:31:26 -0700 Content-Transfer-Encoding: 7bit On Fri, 20 Jul 2001, Brian Wellington wrote: > If you don't trust the on-disk zone data, why would you trust anything > else about the server? the data on-disk is signed, that's why you perhaps trust it - not because it is on disk. you might not even generate or sign the zonefile yourself, it could be done by some other entity. I agree with Roy; setting the AD bit without cryptographic verification is wrong and we should not encourage that. > Treating on-disk signed data as "Authenticated" is reasonable behavior, > and a server may choose to implement this policy. is it still reasonable to treat the data as "Authenticated" when the signatures has expired? 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. From owner-namedroppers@ops.ietf.org Sat Jul 21 06:40:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA16590 for ; Sat, 21 Jul 2001 06:40:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15NrNN-00080O-00 for namedroppers-data@psg.com; Sat, 21 Jul 2001 00:40:37 -0700 Received: from roam.psg.com ([147.28.0.10] ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15NrNN-000808-00 for namedroppers@ops.ietf.org; Sat, 21 Jul 2001 00:40:37 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15NrNN-0001qd-00 for namedroppers@ops.ietf.org; Sat, 21 Jul 2001 00:40:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roy Arends To: Cc: , Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sat, 21 Jul 2001 00:40:37 -0700 Content-Transfer-Encoding: 7bit Ha ! , responding to myself :-) Anyway, after an offlist discussion between Brian and myself, I understand and agree with his point of view. It boils down to the following: AD bit indicates data has been authenticated. A cache MUST have authenticated the data when it has the AD bit set on responses. Authoritative and signed data, stored on disk, may have been authenticated already, and therefor authenticating it again is doubling the effort. If an adminstrator authenticated the data on disk according to its policy, it may instruct the server to treat it as such, without having the server actually authenticate the data itself. Ofcourse this could mean that the data served by an authoritative server is not authenticated at all while the AD is set, but that is the responsibility of the administrator/domain holder. So, apart from a few small clarifications, I agree with the draft. Regards, Roy Arends Nominum to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jul 21 06:40:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA16602 for ; Sat, 21 Jul 2001 06:40:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15NrNx-00081V-00 for namedroppers-data@psg.com; Sat, 21 Jul 2001 00:41:13 -0700 Received: from roam.psg.com ([147.28.0.10] ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15NrNw-00081O-00 for namedroppers@ops.ietf.org; Sat, 21 Jul 2001 00:41:12 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15NrNw-0001qh-00 for namedroppers@ops.ietf.org; Sat, 21 Jul 2001 00:41:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "D. J. Bernstein" To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: NGtrans - DNSext joint meeting, call for participation References: <200107202005.f6KK50F11379@gungnir.fnal.gov> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sat, 21 Jul 2001 00:41:13 -0700 Content-Transfer-Encoding: 7bit Matt Crawford writes: > So if it's all right for your > interface ID and/or subnet information to persist for a month, but > you want to be able to change your global prefix(es) on a day's > notice, you get a 30-to-1 work savings on almost all of your RRsets. No. Under your one-month assumption, all records will be signed at least once a month, to eliminate the expiration-date security problem. The extra signings for renumbering happen only when renumbering happens. If we have 10000 30-day-notice MAC addresses with a 1-day-notice prefix, for example, and we have three renumberings over the next twenty years, the difference between AAAA and A6 is the difference between 2465000 signings and 2442305 signings. Where's the 30-to-1 savings? Put differently: You've been saying that it's painfully expensive to sign every record. But now you're admitting that this has to be done at least a dozen times every year! Of course, the other serious problem with your argument is that your one-month assumption is wrong. It is _not_ acceptable for information to persist for a month. I addressed this in my previous message, and in my ``Extremely long TTLs'' message six months ago. I'm not sure why you've waited six months to state your disagreement. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jul 21 06:40:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA16628 for ; Sat, 21 Jul 2001 06:40:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15NqyL-0006cn-00 for namedroppers-data@psg.com; Sat, 21 Jul 2001 00:14:45 -0700 Received: from roam.psg.com ([147.28.0.10] ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15NqyL-0006cc-00 for namedroppers@ops.ietf.org; Sat, 21 Jul 2001 00:14:45 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15NqyL-0001Ds-00 for namedroppers@ops.ietf.org; Sat, 21 Jul 2001 00:14:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Matt Crawford To: itojun@iijlab.net Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: NGtrans - DNSext joint meeting, call for participation In-reply-to: "20 Jul 2001 11:31:35 PDT." Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sat, 21 Jul 2001 00:14:45 -0700 Content-Transfer-Encoding: 7bit > >Your reasoning is markedly incorrect if applied to A6. If we take > >site renumbering to be the dominant factor controlling > >signature-validity times, then the signatures on the A6 records > > from what I got from reading djb's webpage, djb's point is that > the dominant factor controlling signature-validity time is security, > and for that reason he claims it needs to be very short (so there's The reason is security, in that you can't make the record go away until the signature becomes invalid. So if it's all right for your interface ID and/or subnet information to persist for a month, but you want to be able to change your global prefix(es) on a day's notice, you get a 30-to-1 work savings on almost all of your RRsets. (Yes, a day is awfully short for a non-mobile site, but awfully long for a mobile one.) to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jul 21 06:40:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA16635 for ; Sat, 21 Jul 2001 06:40:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15NrDh-00074F-00 for namedroppers-data@psg.com; Sat, 21 Jul 2001 00:30:37 -0700 Received: from roam.psg.com ([147.28.0.10] ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15NrDg-000748-00 for namedroppers@ops.ietf.org; Sat, 21 Jul 2001 00:30:36 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15NrDg-0001Fm-00 for namedroppers@ops.ietf.org; Sat, 21 Jul 2001 00:30:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "D. J. Bernstein" To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: NGtrans - DNSext joint meeting, call for participation References: <200107201659.f6KGxmF10588@gungnir.fnal.gov> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sat, 21 Jul 2001 00:30:37 -0700 Content-Transfer-Encoding: 7bit ``Administrators normally insist on being able to change their records with at most a few days notice,'' my web page says, as a starting point for analyzing the expiration-date security issues. This applies to _all_ records. Existing DNS software assumes, correctly, that long TTLs are a mistake. I elaborated on these points in an ``Extremely long TTLs'' message on ipng in January: Everything changes. Machines acquire extra IP addresses. Machines disappear. Even MAC addresses change: network cards die. (It isn't always possible, never mind easy, to reprogram the MAC address on the new card.) Those of us who write caches don't want to deal with users asking ``why am I getting the old address?'' when a novice administrator starts with a silly 6-week TTL and then suddenly realizes that he has to change the address. My cache never saves data for more than a week. Yes, the average address stays unchanged for a very long time. Yes, it might stay unchanged for even longer with A6. But that's not what TTLs measure! When an address _does_ have to be changed, there's often not much warning. _That_ is what TTLs are for. Matt Crawford writes: > then the signatures on the A6 records covering interface identifiers > and subnets can be valid for a long time, No, they cannot, because that would allow an attacker to interfere with updates. This is the security issue analyzed on my web page. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jul 21 06:40:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA16654 for ; Sat, 21 Jul 2001 06:40:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15NrEK-00076A-00 for namedroppers-data@psg.com; Sat, 21 Jul 2001 00:31:16 -0700 Received: from roam.psg.com ([147.28.0.10] ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15NrEJ-000764-00 for namedroppers@ops.ietf.org; Sat, 21 Jul 2001 00:31:15 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15NrEJ-0001Fs-00 for namedroppers@ops.ietf.org; Sat, 21 Jul 2001 00:31:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: TKEY compatibility problems References: <200107191320.f6JDKMD23052@kcmso1.proxy.att.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sat, 21 Jul 2001 00:31:16 -0700 Content-Transfer-Encoding: 7bit Robert Elz writes: > Yes, exactly, this is what we have been trying to tell you - just > ignore unexpected records I'm going to try one last time to explain this. We're talking about a failure that can happen when you combine TKEY-extended clients, TKEY-extended servers, and unextended caches. We're also talking about a solution, in which THE TKEY CLIENTS ignore unexpected records. This is a good solution, preserving compatibility with the unextended protocol in a straightforward way. This does not mean that THE UNEXTENDED CACHES ignore unexpected records. That would be a thoroughly irresponsible solution, forcing the installed base to upgrade for the sake of an optional protocol extension. I cannot imagine how you interpreted ``TKEY clients ignore unexpected records'' as ``unextended caches ignore unexpected records.'' The reason this discussion started is that the same failure can happen when you combine TKEY-extended clients, TKEY-extended servers, and my AXFR client. (My AXFR client, just like my cache and the BIND cache, saves AU/AR records.) Guess what? If THE TKEY CLIENTS ignore unexpected records, this problem disappears too! > Glad you have finally conceded the point. I find it difficult to believe that you're this stupid. > Here the community as a whole is telling you ``The community as a whole''? Looks like a standards committee packed with representatives of one vendor and users of that vendor's products. The committee has a long history of labelling protocols as ``standards'' if, and only if, that vendor plans to implement them. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jul 21 06:40:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA16671 for ; Sat, 21 Jul 2001 06:40:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Nr02-0006fZ-00 for namedroppers-data@psg.com; Sat, 21 Jul 2001 00:16:30 -0700 Received: from roam.psg.com ([147.28.0.10] ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15Nr01-0006fP-00 for namedroppers@ops.ietf.org; Sat, 21 Jul 2001 00:16:29 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Nr01-0001Dy-00 for namedroppers@ops.ietf.org; Sat, 21 Jul 2001 00:16:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Alain Durand To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Cc: randy@psg.com, tony@tndh.net, fink@es.net, Olafur Gudmundsson Subject: Update, NGtrans - DNSext joint meeting, call for participation Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sat, 21 Jul 2001 00:16:30 -0700 Content-Transfer-Encoding: 7bit Correction on the previous announcement: The NGtrans/DNSext chairs would like to make a call for participation in the upcoming joint meeting. The goal of the meeting is to facilitate consensus on how IPv6 addresses are represented in DNS and related issues. This meeting requires extensive homework by participants and the chairs would like to request submission of documents for a reading list for this meeting. The output from the meeting will be draft consensus proposal. Here is non exclusive a list of relevant topics: 1 - Design tradeoffs in DNS and IPv6 (AAAA, A6, DNAME, bit string) - DNS operational considerations including DNSSEC costs in regard of address record format - DNS implementation complications due to address record format - IPv6 Remembering requirements and impact on address record format - Case for A6 - Case for AAAA - transition from ip6.int to ip6.arpa - transition from AAAA to A6 2 - tools/protocols/strategies to bridge IPv6 and IPv4 DNS resolution Anybody wishing to make a presentation should send a draft to the chairs of this meeting before July 26th 2001, 21:00 UTC (that is, 2pm PDT, 5pm EDT, 11pm MEST) - Randy Bush - Alain Durand - Bob Fink - Olafur Gudmundsson - Tony Hain Drafts not yet published by the ID editor are acceptable contributions (please include an URL). The chairs will review the list of submission, derived the actual agenda of the meeting from it and send all reading materials to the DNSext and NGtrans mailing list no later than July 27th, 21:00 UTC. The format of the meeting is going to be: - Short summary of the discussion points from the documents - Technical discussion on the relevance of the points - Technical discussion on the points from documents as measured by Rob Austein's document draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt - Brainstorming on the best way to go forward - Straw polls leading to consensus building on a plan of action - the chairs. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jul 21 06:40:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA16682 for ; Sat, 21 Jul 2001 06:40:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Nqxy-0006cY-00 for namedroppers-data@psg.com; Sat, 21 Jul 2001 00:14:22 -0700 Received: from roam.psg.com ([147.28.0.10] ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15Nqxy-0006cS-00 for namedroppers@ops.ietf.org; Sat, 21 Jul 2001 00:14:22 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Nqxy-0001Dp-00 for namedroppers@ops.ietf.org; Sat, 21 Jul 2001 00:14:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "Stephan Jager" To: Brian Wellington cc: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt X-mailer: MOP 1.14: Maurice's Own version of Pine Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sat, 21 Jul 2001 00:14:22 -0700 Content-Transfer-Encoding: 7bit On Fri, 20 Jul 2001, Brian Wellington wrote: > On Fri, 20 Jul 2001, Roy Arends wrote: > > > Ah, so without cryptographicly authenticating the data which is read > > from disk, the primary could set the AD bit on responses since it may > > consider locally configured data to be in authenticated state. > > > > I totally object to this. > > So do I. > This discussion has already been had several times. If you don't trust > the on-disk zone data, why would you trust anything else about the server? Suppose the server is hacked. The malisious operater can change the zonefile on disk (can change a SIG, change the RR, remove the SIG), but in all cases, the zone is then BAD, since he cannot make a new correct SIG. (He doesn't have access to the private key) If the zone is loaded again from disk, it is "secure", and when a secondary gets the zone with the AD bit, the zone will still be bad. Is that want we want to happen? -- Stephan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jul 21 12:55:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA27893 for ; Sat, 21 Jul 2001 12:55:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15NzIG-000GsG-00 for namedroppers-data@psg.com; Sat, 21 Jul 2001 09:07:52 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15NzIF-000GsA-00 for namedroppers@ops.ietf.org; Sat, 21 Jul 2001 09:07:51 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15NzIF-000Ks7-00 for namedroppers@ops.ietf.org; Sat, 21 Jul 2001 09:07:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roy Arends To: Stephan Jager Cc: Brian Wellington , Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sat, 21 Jul 2001 09:07:52 -0700 Content-Transfer-Encoding: 7bit On Sat, 21 Jul 2001, Stephan Jager wrote: > > This discussion has already been had several times. If you don't trust > > the on-disk zone data, why would you trust anything else about the server? > > Suppose the server is hacked. The malisious operater can change the > zonefile on disk (can change a SIG, change the RR, remove the SIG), but in > all cases, the zone is then BAD, since he cannot make a new correct SIG. > (He doesn't have access to the private key) If the zone is loaded again > from disk, it is "secure", and when a secondary gets the zone with the AD > bit, the zone will still be bad. > > Is that want we want to happen? Well, I objected to this at first because I thought the AD bit interpretation changed from Authenticated to something less. This is not the case. Suppose the server is hacked, malicious operator and changed zonefiles and all that. If everything could be compromised, the server-software could be compromised too. So extra sig-validation does not help you there. The _only_ situation when a client depends on the AD bit from an Authoritative (!) server is when this client talk directly, with TSIG/SIG(0) to this authoritative server. In that situation, the server must be preconfigured with the shared-TSIG or the public-SIG(0) of the client and vice versa. That means the client conforms to the local policy of the server. If the server trusts the contents on disk, so should the client. In a perfect world, clients do not talk immediatly to authoritative servers. They talk to some local cache. Roy Arends Nominum to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jul 22 10:58:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18812 for ; Sun, 22 Jul 2001 10:58:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15OJ8A-000BJp-00 for namedroppers-data@psg.com; Sun, 22 Jul 2001 06:18:46 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15OJ8A-000BJj-00 for namedroppers@ops.ietf.org; Sun, 22 Jul 2001 06:18:46 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15OJ89-0003M5-00 for namedroppers@ops.ietf.org; Sun, 22 Jul 2001 06:18:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Namedroppers Subject: Re: summary/conclusion of discussion on mdns-00 In-Reply-To: <20010516144940.167DD7E2@starfruit.itojun.org> References: <20010516144940.167DD7E2@starfruit.itojun.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sun, 22 Jul 2001 06:18:46 -0700 Content-Transfer-Encoding: 7bit Date: Wed, 16 May 2001 23:49:40 +0900 From: Jun-ichiro itojun Hagino Message-ID: <20010516144940.167DD7E2@starfruit.itojun.org> | >> [9] Change text: 'A gratuitous name resolution query SHOULD be done | >> to check for a name conflict. This is done by having the resolver | >> send a multicast query for a SOA type query for its own name (i.e. | >> for the name it is authoritative for.' | >> s/SHOULD/MAY/ | >> s/SOA/A/ | >Again, I think that name conflicts are a problem and caution is | >advised. Recommend against the change. | | i strongly object against s/SOA/A/ change. we can't assume that every | device has an IPv4 address (think of IPv6 only devices). Yes, but SOA is wrong too - since servers only send positive, non-empty replies, the changes of an SOA query eliciting a reply are pretty small (only if the name chosen happens to be the same as that of a separate zone, they're the only things that have SOA records). Why is an ANY query not done? What does it matter what kind of data exists - the point is to discover if the name exists, right? That's one of the rare cases where an ANY query actually makes sense (what's more, it doesn't matter if all of the data can't be returned, or even if a truncated answer is returned - if any data is returned the answer that is desired is obtained). The original text seems to be based upon a misunderstanding of the role of SOA, and changing from using that is definitely correct. But as you point out, changing to A is not the answer - that is perhaps more likely to exist than an SOA, but not guaranteed. IN fact, nothing is guaranteed. That's why ANY should work here - no-one cares what type the data is, just that data exist - that is, that the name exists. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jul 22 17:27:55 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA04768 for ; Sun, 22 Jul 2001 17:27:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15OPrh-000GF4-00 for namedroppers-data@psg.com; Sun, 22 Jul 2001 13:30:13 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15OPrh-000GEy-00 for namedroppers@ops.ietf.org; Sun, 22 Jul 2001 13:30:13 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15OPrh-000EQT-00 for namedroppers@ops.ietf.org; Sun, 22 Jul 2001 13:30:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Matt Crawford To: "D. J. Bernstein" Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: NGtrans - DNSext joint meeting, call for participation In-reply-to: "20 Jul 2001 22:13:22 -0000." <20010720221322.4452.qmail@cr.yp.to> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sun, 22 Jul 2001 13:30:13 -0700 Content-Transfer-Encoding: 7bit > ``Administrators normally insist on being able to change their records > with at most a few days notice,'' my web page says, as a starting point > for analyzing the expiration-date security issues. Yes, it does indeed say that. It has to say it, because imposing that ad-hoc restriction is necessary in order to drive to the conclusion you want. Bu tthat doesn't make it so, especially when different records record information with clearly different volatility. > Matt Crawford writes: > > then the signatures on the A6 records covering interface identifiers > > and subnets can be valid for a long time, > > No, they cannot, because that would allow an attacker to interfere with > updates. This is the security issue analyzed on my web page. No, it is not analyzed. What you assert is true, but you have not explored the ramifications. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jul 22 17:40:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07388 for ; Sun, 22 Jul 2001 17:40:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15OPrt-000GFM-00 for namedroppers-data@psg.com; Sun, 22 Jul 2001 13:30:25 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15OPrt-000GFF-00 for namedroppers@ops.ietf.org; Sun, 22 Jul 2001 13:30:25 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15OPrt-000EQs-00 for namedroppers@ops.ietf.org; Sun, 22 Jul 2001 13:30:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Matt Crawford To: "D. J. Bernstein" Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: NGtrans - DNSext joint meeting, call for participation In-reply-to: "21 Jul 2001 04:14:22 -0000." <20010721041422.31726.qmail@cr.yp.to> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sun, 22 Jul 2001 13:30:25 -0700 Content-Transfer-Encoding: 7bit > Matt Crawford writes: > > So if it's all right for your > > interface ID and/or subnet information to persist for a month, but > > you want to be able to change your global prefix(es) on a day's > > notice, you get a 30-to-1 work savings on almost all of your RRsets. > > No. Under your one-month assumption, all records will be signed at least > once a month, to eliminate the expiration-date security problem. The > extra signings for renumbering happen only when renumbering happens. > > If we have 10000 30-day-notice MAC addresses with a 1-day-notice prefix, > for example, and we have three renumberings over the next twenty years, > the difference between AAAA and A6 is the difference between 2465000 > signings and 2442305 signings. Where's the 30-to-1 savings? It's in the arithmetic, which I will do for you. If you'll permit, I'll round off to 360 days per year to make everything transparent. Scenario AAAA: sign every RRset every day for 20 years. 10,000 x 360 x 20 = 72,000,000 Scenario A6: sign the suffix RRsets 12 times a year for 20 years, sign the one prefix RRset every day for 20 years. ( 10,000 x 12 x 20 ) + ( 1 x 360 x 20 ) = 2,407,200 Ratio: 29.91 to 1. This reminds me of a previous argument. > Put differently: You've been saying that it's painfully expensive to > sign every record. Some may have said that, but I didn't. > But now you're admitting that this has to be done at least a dozen > times every year! You seem surprised. > Of course, the other serious problem with your argument is that your > one-month assumption is wrong. It is _not_ acceptable for information to > persist for a month. Sometimes yes, sometimes no. With A6 you get to treat parts differently, according to their needs. (And to whoever it was, not Dan, I think, who said you can't override the MAC address on some hardware: that's utterly irrelevant. You don't need to autoconfigure your address and even if you do, you don't need to use only that address.) to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 23 14:53:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15748 for ; Mon, 23 Jul 2001 14:53:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15OkBh-000EIz-00 for namedroppers-data@psg.com; Mon, 23 Jul 2001 11:12:13 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15OkBg-000EIr-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 11:12:12 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15OkBg-000M94-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 11:12:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Edward Lewis To: Roy Arends Cc: , , Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 23 Jul 2001 11:12:13 -0700 Content-Transfer-Encoding: 7bit At 11:14 PM -0400 7/20/01, Roy Arends wrote: >Ofcourse this could mean that the data served by an authoritative server >is not authenticated at all while the AD is set, but that is the >responsibility of the administrator/domain holder. Gaack, no! Please don't set the AD bit without locally verifying the data. I'd rather have to have the resolver check for either AA or AD than have the AD bit mean something inconsistently. (1 bit = YES/NO, not = YES/NO/MAYBE.) As far as a the arguement that a stub (non-crypto-doing) resolver would always be using a recursive server, I think this is 1) wrong and 2) restricive. Wrong because most of my lookups are for local sites (fileserver., smtp., pop.) as opposed to remote sites (www.sportsscores.com). The server I use for recursion is also authortiative for , hence, my stub resolver is usually going to the authortitative source for data. Restrictive because you are assuming that everyone will run DNS in one way. It used to be (not long ago) that BIND tried to encompass the wide range of configurations that folks put it through. Now it seems that more and more it is being designed for just one best way of use. Why can't the authortitative server be made to optionally "verify on send" and thus set the AD bit that way? Why do I have to buy into the mantra "I just trust what's on my disk?" -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com You fly too often when ... the airport taxi is on speed-dial. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 23 15:06:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16581 for ; Mon, 23 Jul 2001 15:06:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15OjKg-000Cl9-00 for namedroppers-data@psg.com; Mon, 23 Jul 2001 10:17:26 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15OjKg-000Cl3-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 10:17:26 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15OjKf-000JQ8-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 10:17:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Edward Lewis To: Brian Wellington Cc: Edward Lewis , Jakob Schlyter , Roy Arends , , Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 23 Jul 2001 10:17:26 -0700 Content-Transfer-Encoding: 7bit At 12:32 PM -0400 7/23/01, Brian Wellington wrote: >On Mon, 23 Jul 2001, Edward Lewis wrote: > >> At 3:31 AM -0400 7/21/01, Jakob Schlyter wrote: >> >is it still reasonable to treat the data as "Authenticated" when the >> >signatures has expired? >> >> I think not, and this should be covered in a resolver document. > >I think Jakob was talking about an authoritative server, though. The >answer is probably "no", but enforcing this has major implications on the >server, since it requires the server to inspect the data it's returning >for every query, rather than just finding it and sticking it in the >response. So am I...Jakob and I (I think) both agree that the answerer (especially on authoritative servers) should verify-on-reply. >This sounds like another reason to split authoritative and caching >service. The recursive server will be doing the validation anyway, and >can clamp the TTL based on the expiration time. I think Brian's presumption is that the authortitative server should not verify its own data because this represents a waste of time. Others have expressed the opinion that having the authoritative server verify on send has two advantages. First is that verify-on-send would allow the AD bit to be sent, thus making the resolver look just for the AD bit to see if an answer is "secured." (Let's not debate "secured" this instant.) Currently, a resolver would have to check the AA or AD bit to see if the answer is "secured or I personally known it" (speaking for the answering server). This current situation slightly complicates the resolver. (Before anyone starts flaming away, I'm just trying to document the state of the discussion.) Second is that the verify-on-send ensures that there is a currently valid signature for the answer. In the case of a temporal-swiss-cheese zone (meaning there are temporal gaps in signature coverage) an answer shouldn't emerge that might be accepted by a stub resolver. Now for the flame bait. My opinion is that I would like to have the option of having my server verify-on-send. I think a resolver should still accept an AD with TSIG on par with AA with TSIG. And I think any set in a signed zone that is not properly signed should be seen as a SERVFAIL answer. Okay, Brian, disagree away...;) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com You fly too often when ... the airport taxi is on speed-dial. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 23 15:10:08 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16779 for ; Mon, 23 Jul 2001 15:10:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Ofzc-00087V-00 for namedroppers-data@psg.com; Mon, 23 Jul 2001 06:43:28 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15Ofzb-00087P-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 06:43:27 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15Ofzb-0008cv-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 06:43:27 -0700 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org Subject: I-D ACTION:draft-ietf-dnsext-axfr-clarify-03.txt Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 23 Jul 2001 06:43:28 -0700 --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 Zone Transfer Protocol Clarifications Author(s) : A. Gustafsson Filename : draft-ietf-dnsext-axfr-clarify-03.txt Pages : 7 Date : 20-Jul-01 In the Domain Name System, zone data is replicated among authoritative DNS servers by means of the 'zone transfer' protocol, also known as the 'AXFR' protocol. This memo clarifies, updates, and adds missing detail to the original AXFR protocol specification in RFC1034. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-axfr-clarify-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-axfr-clarify-03.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-axfr-clarify-03.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: <20010720082726.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-axfr-clarify-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-axfr-clarify-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010720082726.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 23 15:10:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16824 for ; Mon, 23 Jul 2001 15:10:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15OkAD-000EHB-00 for namedroppers-data@psg.com; Mon, 23 Jul 2001 11:10:41 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15OkAD-000EH5-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 11:10:41 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15OkAD-000M69-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 11:10:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Brian Wellington To: Edward Lewis cc: Jakob Schlyter , Roy Arends , , Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 23 Jul 2001 11:10:41 -0700 Content-Transfer-Encoding: 7bit On Mon, 23 Jul 2001, Edward Lewis wrote: > >I think Jakob was talking about an authoritative server, though. The > >answer is probably "no", but enforcing this has major implications on the > >server, since it requires the server to inspect the data it's returning > >for every query, rather than just finding it and sticking it in the > >response. > > So am I...Jakob and I (I think) both agree that the answerer (especially on > authoritative servers) should verify-on-reply. Nobody seems to understand that verify-on-reply is a bad idea. An authoritative server is designed to serve data, that's it. > >This sounds like another reason to split authoritative and caching > >service. The recursive server will be doing the validation anyway, and > >can clamp the TTL based on the expiration time. > > I think Brian's presumption is that the authortitative server should not > verify its own data because this represents a waste of time. Others have > expressed the opinion that having the authoritative server verify on send > has two advantages. Yes. > First is that verify-on-send would allow the AD bit to be sent, thus making > the resolver look just for the AD bit to see if an answer is "secured." > (Let's not debate "secured" this instant.) Currently, a resolver would > have to check the AA or AD bit to see if the answer is "secured or I > personally known it" (speaking for the answering server). This current > situation slightly complicates the resolver. This goes away if the resolver only talks to a caching server. > Second is that the verify-on-send ensures that there is a currently valid > signature for the answer. In the case of a temporal-swiss-cheese zone > (meaning there are temporal gaps in signature coverage) an answer shouldn't > emerge that might be accepted by a stub resolver. And this does too. There's no reason to put DNSSEC goop in an authoritative server, when caching servers already need it. > My opinion is that I would like to have the option of having my server > verify-on-send. I think a resolver should still accept an AD with TSIG on > par with AA with TSIG. And I think any set in a signed zone that is not > properly signed should be seen as a SERVFAIL answer. > > Okay, Brian, disagree away...;) See above. DNSSEC is very complicated to implement, but all of the complication lies in the validation. The only changes necessary to make an authoritative server support DNSSEC are the ability to return SIGs when necessary and NXTs. That's it. Easy. Making the server validate on queries requires a complicating the code path (violating "optimize for the common case"), and is a huge performance hit. Even if the signatures are valid, the server will need to unpack them and check the times. Please tell me why, if you want your resolver to get the AD bit, you don't just point it at a caching-only server. It works now, and it's the Right Answer (tm). Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 23 15:11:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16975 for ; Mon, 23 Jul 2001 15:11:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Oid6-000BmR-00 for namedroppers-data@psg.com; Mon, 23 Jul 2001 09:32:24 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15Oid5-000BmK-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 09:32:23 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15Oid5-000HAl-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 09:32:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Brian Wellington To: Edward Lewis Cc: Jakob Schlyter , Roy Arends , , Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 23 Jul 2001 09:32:24 -0700 Content-Transfer-Encoding: 7bit On Mon, 23 Jul 2001, Edward Lewis wrote: > At 3:31 AM -0400 7/21/01, Jakob Schlyter wrote: > >is it still reasonable to treat the data as "Authenticated" when the > >signatures has expired? > > I think not, and this should be covered in a resolver document. I think Jakob was talking about an authoritative server, though. The answer is probably "no", but enforcing this has major implications on the server, since it requires the server to inspect the data it's returning for every query, rather than just finding it and sticking it in the response. This sounds like another reason to split authoritative and caching service. The recursive server will be doing the validation anyway, and can clamp the TTL based on the expiration time. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 23 15:14:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17158 for ; Mon, 23 Jul 2001 15:14:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15OhYI-000AKm-00 for namedroppers-data@psg.com; Mon, 23 Jul 2001 08:23:22 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15OhYI-000AKf-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 08:23:22 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15OhYI-000Dgf-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 08:23:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Edward Lewis To: Jakob Schlyter Cc: Brian Wellington , Roy Arends , , Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 23 Jul 2001 08:23:22 -0700 Content-Transfer-Encoding: 7bit At 3:31 AM -0400 7/21/01, Jakob Schlyter wrote: >is it still reasonable to treat the data as "Authenticated" when the >signatures has expired? I think not, and this should be covered in a resolver document. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com You fly too often when ... the airport taxi is on speed-dial. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 23 15:14:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17219 for ; Mon, 23 Jul 2001 15:14:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Ofzf-00087d-00 for namedroppers-data@psg.com; Mon, 23 Jul 2001 06:43:31 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15Ofzf-00087X-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 06:43:31 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15Ofzf-0008d7-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 06:43:31 -0700 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org Subject: I-D ACTION:draft-ietf-dnsext-unknown-rrs-01.txt Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 23 Jul 2001 06:43:31 -0700 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Handling of Unknown DNS RR Types Author(s) : A. Gustafsson Filename : draft-ietf-dnsext-unknown-rrs-01.txt Pages : 6 Date : 20-Jul-01 Extending the Domain Name System with new Resource Record types currently requires changes to name server software. This document specifies the changes necessary to allow future DNS implementations to handle new RR types transparently. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-unknown-rrs-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-unknown-rrs-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-unknown-rrs-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: <20010720082735.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-unknown-rrs-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-unknown-rrs-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010720082735.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 23 15:15:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17294 for ; Mon, 23 Jul 2001 15:15:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Okw1-000Fh1-00 for namedroppers-data@psg.com; Mon, 23 Jul 2001 12:00:05 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15Okw1-000Fgq-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 12:00:05 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15Okw0-000NT1-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 12:00:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Brian Wellington To: Edward Lewis cc: Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 23 Jul 2001 12:00:05 -0700 Content-Transfer-Encoding: 7bit On Mon, 23 Jul 2001, Edward Lewis wrote: > I can't resist the following observation: > > At 2:10 PM -0400 7/23/01, Brian Wellington wrote: > >Nobody seems to understand that verify-on-reply is a bad idea. An > >authoritative server is designed to serve data, that's it. > > Ergo, the consensus is that verify-on-reply is a good idea? Er, no. If everybody jumped off a bridge... Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 23 15:15:50 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17307 for ; Mon, 23 Jul 2001 15:15:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15OfzZ-00087H-00 for namedroppers-data@psg.com; Mon, 23 Jul 2001 06:43:25 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15OfzZ-000878-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 06:43:25 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15OfzZ-0008ck-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 06:43:25 -0700 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org Subject: I-D ACTION:draft-ietf-dnsext-aaaa-a6-01.txt Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 23 Jul 2001 06:43:25 -0700 --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 : Comparison of AAAA and A6 (do we really need A6?) Author(s) : J. Hagino Filename : draft-ietf-dnsext-aaaa-a6-01.txt Pages : 13 Date : 20-Jul-01 At this moment, there are two DNS resource record types defined for holding IPv6 address in the DNS database; AAAA [Thomson, 1995] and A6 [Crawford, 2000] . AAAA has been used for IPv6 network operation since 1996. Questions arose whether we really need A6 or not, or whether it is really possible to migrate to A6 or not. Some says AAAA is enough and A6 is not necessary. Some says A6 is necessary and AAAA should get deprecated. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-aaaa-a6-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-aaaa-a6-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-aaaa-a6-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: <20010720082712.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-aaaa-a6-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-aaaa-a6-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010720082712.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 23 15:15:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17321 for ; Mon, 23 Jul 2001 15:15:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15OkuX-000Fd9-00 for namedroppers-data@psg.com; Mon, 23 Jul 2001 11:58:33 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15OkuW-000Fcx-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 11:58:32 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15OkuW-000NQJ-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 11:58:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Edward Lewis To: Brian Wellington Cc: Edward Lewis , Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 23 Jul 2001 11:58:33 -0700 Content-Transfer-Encoding: 7bit At 2:02 PM -0400 7/23/01, Brian Wellington wrote: >DNSSEC is very complicated to implement, but all of the complication lies >in the validation. The only changes necessary to make an authoritative >server support DNSSEC are the ability to return SIGs when necessary and >NXTs. That's it. Easy. Making the server validate on queries requires a >complicating the code path (violating "optimize for the common case"), and >is a huge performance hit. Even if the signatures are valid, the server >will need to unpack them and check the times. This is a pertinent arguement if the only thing you care about is the construction of the code. There are two reasons I see for verify-on-send (query): 1) Checking the validity period of the signatures. 2) Checking to make sure the key chain is still accessible. IOW - don't hand out data that isn't verifiable. I'm not arguing that these are the concerns of some domains, but they are of others. (See my reiterated point below.) I would like to experiement with these options - possibly verifying-on-send only if TSIG is being used. As far as "violating 'optimize for the common case,'" maintaining this optimization is fine, but don't code only for the common case. >Please tell me why, if you want your resolver to get the AD bit, you don't >just point it at a caching-only server. It works now, and it's the Right >Answer (tm). In the previous mail I sent (I'm catching up out of order), I sent an answer to this - basically, my recursive server is also authoritative for most of my queries. To reiterate my point from the other message - please don't force me to use DNS the way you think it should be used. The "Right Answer" shouldn't be the "Only Solution." -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com You fly too often when ... the airport taxi is on speed-dial. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 23 15:18:02 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17416 for ; Mon, 23 Jul 2001 15:17:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Ofzj-00087m-00 for namedroppers-data@psg.com; Mon, 23 Jul 2001 06:43:35 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15Ofzj-00087g-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 06:43:35 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15Ofzj-0008dM-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 06:43:35 -0700 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org Subject: I-D ACTION:draft-ietf-dnsext-mdns-03.txt Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 23 Jul 2001 06:43:35 -0700 --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 : Multicast DNS Author(s) : L. Esibov, B. Aboba, D. Thaler Filename : draft-ietf-dnsext-mdns-03.txt Pages : 16 Date : 20-Jul-01 Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a DNS server. In order to allow DNS name resolution in such environments, the use of a multicast DNS is proposed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-mdns-03.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-mdns-03.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: <20010720082744.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010720082744.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 23 15:44:12 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18947 for ; Mon, 23 Jul 2001 15:44:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Okuc-000Fdl-00 for namedroppers-data@psg.com; Mon, 23 Jul 2001 11:58:38 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15Okuc-000Fdf-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 11:58:38 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15Okuc-000NQb-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 11:58:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Edward Lewis To: Brian Wellington Cc: Edward Lewis , Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 23 Jul 2001 11:58:38 -0700 Content-Transfer-Encoding: 7bit I can't resist the following observation: At 2:10 PM -0400 7/23/01, Brian Wellington wrote: >Nobody seems to understand that verify-on-reply is a bad idea. An >authoritative server is designed to serve data, that's it. Ergo, the consensus is that verify-on-reply is a good idea? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com You fly too often when ... the airport taxi is on speed-dial. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 23 16:26:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21400 for ; Mon, 23 Jul 2001 16:26:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Olby-000GpC-00 for namedroppers-data@psg.com; Mon, 23 Jul 2001 12:43:26 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15Olbx-000Gp6-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 12:43:25 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15Olbx-000Ofo-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 12:43:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roy Arends To: Edward Lewis Cc: Roy Arends , , , Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 23 Jul 2001 12:43:26 -0700 Content-Transfer-Encoding: 7bit On Mon, 23 Jul 2001, Edward Lewis wrote: > At 11:14 PM -0400 7/20/01, Roy Arends wrote: > >Ofcourse this could mean that the data served by an authoritative server > >is not authenticated at all while the AD is set, but that is the > >responsibility of the administrator/domain holder. > > Gaack, no! > > Please don't set the AD bit without locally verifying the data. I'd rather > have to have the resolver check for either AA or AD than have the AD bit > mean something inconsistently. (1 bit = YES/NO, not = YES/NO/MAYBE.) The key point here is "don't set the AD bit without locally verifying the data". Exactly true, no arguments here. BUT, I happen to verify the data every single day by re-signing the zone. I do not want the extra burdon of double authentication. > As far as a the arguement that a stub (non-crypto-doing) resolver would > always be using a recursive server, I think this is 1) wrong and 2) > restricive. What argument. You are not referring to any statements I've made. In the general case it would be better if a stub (non-crypto-doing) resolver (lemme rephrase that : ANY resolver !) were using a recursive server, because it saves bandwith, load on authoritative servers. This is also true in the cache that someone is doing DNSSEC, regardless of this draft. The argument is that 1) Don't trust AD, unless TSIG/SIG(0) is used. 2) If you do TSIG/SIG(0) to an authoritative serve you implying you trust the authoritative server. 3) If you trust the authoritative server, you don't need the AD bit. > Why can't the authortitative server be made to optionally "verify on send" > and thus set the AD bit that way? Because it does not add extra trust. > Why do I have to buy into the mantra "I just trust what's on my disk?" Come'on, this is like saying, "I wanna trust the server, but I don't want automagically want to trust the data, so the server must validate it". Why would a malicious user not compromise the server-software, if it could compromise the data on disk. If you want to trust an authoritative nameserver, use TSIG/SIG(0), it is the only real trust mechanism in this particular scheme. Roy Arends Nominum to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 23 16:27:06 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21422 for ; Mon, 23 Jul 2001 16:27:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15OlYX-000GkI-00 for namedroppers-data@psg.com; Mon, 23 Jul 2001 12:39:53 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15OlYW-000GkB-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 12:39:52 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15OlYW-000OZf-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 12:39:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Jakob Schlyter To: Brian Wellington Cc: Edward Lewis , Roy Arends , DNSEXT , Olafur Gudmundsson Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 23 Jul 2001 12:39:53 -0700 Content-Transfer-Encoding: 7bit On Mon, 23 Jul 2001, Brian Wellington wrote: > Nobody seems to understand that verify-on-reply is a bad idea. An > authoritative server is designed to serve data, that's it. whether it is bad idea or not to do verify-on-reply is up to the server administrator, not the people writing the specifications. > > First is that verify-on-send would allow the AD bit to be sent, thus making > > the resolver look just for the AD bit to see if an answer is "secured." > > (Let's not debate "secured" this instant.) Currently, a resolver would > > have to check the AA or AD bit to see if the answer is "secured or I > > personally known it" (speaking for the answering server). This current > > situation slightly complicates the resolver. > > This goes away if the resolver only talks to a caching server. but the caching server might also be your authorative server. in reality most authorative server also serve as caching server for some local clients. verify-on-send could of course be configurable, as recursion is in some servers. 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. From owner-namedroppers@ops.ietf.org Mon Jul 23 17:11:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24204 for ; Mon, 23 Jul 2001 17:11:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Omdz-000IU3-00 for namedroppers-data@psg.com; Mon, 23 Jul 2001 13:49:35 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15Omdz-000ITx-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 13:49:35 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15Omdy-0000ZM-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 13:49:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Brian Wellington To: Jakob Schlyter cc: Edward Lewis , Roy Arends , DNSEXT , Olafur Gudmundsson Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 23 Jul 2001 13:49:35 -0700 Content-Transfer-Encoding: 7bit On Mon, 23 Jul 2001, Jakob Schlyter wrote: > On Mon, 23 Jul 2001, Brian Wellington wrote: > > > > verify-on-send could of course be configurable, as recursion is in some > > > servers. > > > > I'd much prefer to see a server with a "recursive" view and an > > "authoritative" view, where all recursive querie went through the > > recursive view. This would allow the server verify authoritative data > > (when the query has the RD bit set), without complicating the > > authoritative server. > > this sounds reasonable. > > > perhaps we should go back to discussing the draft? > > I still think that the draft should say that you MUST NOT set the AD bit > without cryptographic verification of data. could we agree on this? if the > server should try to verify the data at all is an implementational issue. No, we can't all agree on this. Let's say I have a signed zone. I signed it myself. I configured the server myself. I tested the server to make sure it's returning the right answers, and they authenticate. I know everything's correct. Why can't my server set the AD bit? If you don't want your server to behave that way, then don't use that policy. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 23 17:55:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26729 for ; Mon, 23 Jul 2001 17:55:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15OmYa-000IHo-00 for namedroppers-data@psg.com; Mon, 23 Jul 2001 13:44:00 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15OmYa-000IHi-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 13:44:00 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15OmYa-0000Ow-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 13:44:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Edward Lewis To: Roy Arends Cc: Edward Lewis , Roy Arends , , , Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 23 Jul 2001 13:44:00 -0700 Content-Transfer-Encoding: 7bit At 3:40 PM -0400 7/23/01, Roy Arends wrote: > >The key point here is "don't set the AD bit without locally verifying the >data". Exactly true, no arguments here. BUT, I happen to verify the data >every single day by re-signing the zone. I do not want the extra burdon of >double authentication. The BIND 9 signer doesn't always verify the signatures it generates. (There's an option to do so, but the server can't tell if it has been used.) > >> As far as a the arguement that a stub (non-crypto-doing) resolver would >> always be using a recursive server, I think this is 1) wrong and 2) >> restricive. > >What argument. You are not referring to any statements I've made. You're right - the "argument I referred to was the one Brian raised - that the answering server should not be an authoritative server. > In the >general case it would be better if a stub (non-crypto-doing) resolver >(lemme rephrase that : ANY resolver !) were using a recursive server, >because it saves bandwith, load on authoritative servers. This is also >true in the cache that someone is doing DNSSEC, regardless of this draft. Don't pin me into having to use the server just one way! Many folks will combine the authortitative server with a (local-only) recursive server, e.g., as on a firewall. >Because it does not add extra trust. It's not always about trust. (See my earlier message about signature validity and verifying the key chain.) > >> Why do I have to buy into the mantra "I just trust what's on my disk?" > >Come'on, this is like saying, "I wanna trust the server, but I don't want >automagically want to trust the data, so the server must validate it". Why >would a malicious user not compromise the server-software, if it could >compromise the data on disk. > >If you want to trust an authoritative nameserver, use TSIG/SIG(0), it is >the only real trust mechanism in this particular scheme. Well, there is IPSEC too. But my point here is that I don't want the specification to be limited by what is implemented. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com You fly too often when ... the airport taxi is on speed-dial. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 23 18:08:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27328 for ; Mon, 23 Jul 2001 18:08:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15OmYh-000II4-00 for namedroppers-data@psg.com; Mon, 23 Jul 2001 13:44:07 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15OmYg-000IHw-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 13:44:06 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15OmYg-0000PA-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 13:44:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Olafur Gudmundsson To: Roy Arends cc: Edward Lewis , DNSEXT mailing list , Brian Wellington Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 23 Jul 2001 13:44:07 -0700 Content-Transfer-Encoding: 7bit On Mon, 23 Jul 2001, Roy Arends wrote: > On Mon, 23 Jul 2001, Edward Lewis wrote: > > > At 11:14 PM -0400 7/20/01, Roy Arends wrote: > There is an extra dimension missing from this arguement, Nameserver trust. Resolver either trusts a nameserver (by policy) or it does not! If I configure my resolver to trust noone then it will verify all signatures. If I configure it to trust cr.yp.to. then it will verify all signatures execpt the ones that come from cr.yp.to. with the AD bit set. > 1) Don't trust AD, unless TSIG/SIG(0) is used. I think you want to say, Do not trust AD unless message is authenticated AND from a trusted nameserver. Authenticated== TSIG/SIG(0) (IPsec and TLS might also be allowed) As for the nameserver I can use authentication to any server but does that mean I trust them to do everything correctly ? Answer: NO. > 2) If you do TSIG/SIG(0) to an authoritative serve you implying you trust > the authoritative server. TSIG only authenticates the message and origin, what resolver does with the contents depends on policy, it may or may not trust the server. > 3) If you trust the authoritative server, you don't need the AD bit. Correct, in the case of authorative data from that server, For authorative answers (AA set), AD is redundant, but if AA is not set then AD has value. Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 23 18:09:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27380 for ; Mon, 23 Jul 2001 18:09:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15OmtB-000J6j-00 for namedroppers-data@psg.com; Mon, 23 Jul 2001 14:05:17 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15OmtB-000J6d-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 14:05:17 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15OmtA-00012R-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 14:05:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: David Terrell Reply-To: David Terrell To: "D. J. Bernstein" Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: NGtrans - DNSext joint meeting, call for participation In-Reply-To: ; from djb@cr.yp.to on Sat, Jul 21, 2001 at 12:41:13AM -0700 References: <200107202005.f6KK50F11379@gungnir.fnal.gov> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 23 Jul 2001 14:05:17 -0700 Content-Transfer-Encoding: 7bit On Sat, Jul 21, 2001 at 12:41:13AM -0700, D. J. Bernstein wrote: > Of course, the other serious problem with your argument is that your > one-month assumption is wrong. It is _not_ acceptable for information to > persist for a month. I addressed this in my previous message, and in my > ``Extremely long TTLs'' message six months ago. I'm not sure why you've > waited six months to state your disagreement. Did I miss somewhere where the expiration of the cryptographic signature was defined to replace the normal DNS TTL on the record? -- David Terrell | "My question is, if a mime types, isn't dbt@meat.net | that kinda cheating?" http://wwn.nebcorp.com/ | - Jason Zych to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 23 18:10:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27415 for ; Mon, 23 Jul 2001 18:10:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15OmqF-000IyQ-00 for namedroppers-data@psg.com; Mon, 23 Jul 2001 14:02:15 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15OmqF-000IyJ-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 14:02:15 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15OmqF-0000wY-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 14:02:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Matt Crawford To: Alain Durand , Olafur Gudmundsson Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com Subject: Re: NGtrans - DNSext joint meeting, call for participation In-reply-to: "20 Jul 2001 05:43:07 PDT." Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 23 Jul 2001 14:02:15 -0700 Content-Transfer-Encoding: 7bit > The NGtrans/DNSext chairs would like to make a call for participation > in the upcoming joint meeting. > ... > Anybody wishing to make a presentation should send a draft > to the chairs of this meeting before July 26th 2001, 21:00 UTC > (that is, 2pm PDT, 5pm EDT, 11pm MEST) > - Alain Durand > - Olafur Gudmundsson > > Drafts not yet published by the ID editor are acceptable > contributions (please include an URL). I offer http://home.fnal.gov/~crawdad/draft-ietf-dnsext-ipv6-dns-response-00.txt Matt Crawford to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 23 18:12:50 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27553 for ; Mon, 23 Jul 2001 18:12:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15OmYT-000IHb-00 for namedroppers-data@psg.com; Mon, 23 Jul 2001 13:43:53 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15OmYS-000IHV-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 13:43:52 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15OmYS-0000Of-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 13:43:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Brian Wellington To: Jakob Schlyter cc: Edward Lewis , Roy Arends , DNSEXT , Olafur Gudmundsson Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 23 Jul 2001 13:43:53 -0700 Content-Transfer-Encoding: 7bit On Mon, 23 Jul 2001, Jakob Schlyter wrote: > On Mon, 23 Jul 2001, Brian Wellington wrote: > > > Nobody seems to understand that verify-on-reply is a bad idea. An > > authoritative server is designed to serve data, that's it. > > whether it is bad idea or not to do verify-on-reply is up to the server > administrator, not the people writing the specifications. It's also up to the server authors. Speaking as the person most likely to implement this, I think it's a really bad idea. > > > First is that verify-on-send would allow the AD bit to be sent, thus making > > > the resolver look just for the AD bit to see if an answer is "secured." > > > (Let's not debate "secured" this instant.) Currently, a resolver would > > > have to check the AA or AD bit to see if the answer is "secured or I > > > personally known it" (speaking for the answering server). This current > > > situation slightly complicates the resolver. > > > > This goes away if the resolver only talks to a caching server. > > but the caching server might also be your authorative server. in reality > most authorative server also serve as caching server for some local > clients. > > verify-on-send could of course be configurable, as recursion is in some > servers. I'd much prefer to see a server with a "recursive" view and an "authoritative" view, where all recursive querie went through the recursive view. This would allow the server verify authoritative data (when the query has the RD bit set), without complicating the authoritative server. I don't know how difficult it would be to add this functionality to BIND 9, and I'm way too busy with other things to try. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 23 18:13:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27573 for ; Mon, 23 Jul 2001 18:13:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Omc2-000IQn-00 for namedroppers-data@psg.com; Mon, 23 Jul 2001 13:47:34 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15Omc1-000IQg-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 13:47:33 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15Omc1-0000Vv-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 13:47:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Jakob Schlyter To: Brian Wellington Cc: Edward Lewis , Roy Arends , DNSEXT , Olafur Gudmundsson Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 23 Jul 2001 13:47:34 -0700 Content-Transfer-Encoding: 7bit On Mon, 23 Jul 2001, Brian Wellington wrote: > > verify-on-send could of course be configurable, as recursion is in some > > servers. > > I'd much prefer to see a server with a "recursive" view and an > "authoritative" view, where all recursive querie went through the > recursive view. This would allow the server verify authoritative data > (when the query has the RD bit set), without complicating the > authoritative server. this sounds reasonable. perhaps we should go back to discussing the draft? I still think that the draft should say that you MUST NOT set the AD bit without cryptographic verification of data. could we agree on this? if the server should try to verify the data at all is an implementational issue. 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. From owner-namedroppers@ops.ietf.org Mon Jul 23 18:13:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27599 for ; Mon, 23 Jul 2001 18:13:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15OmrB-000J11-00 for namedroppers-data@psg.com; Mon, 23 Jul 2001 14:03:13 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15OmrA-000J0v-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 14:03:12 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15OmrA-0000yO-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 14:03:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Brian Wellington To: Edward Lewis cc: Jakob Schlyter , Roy Arends , DNSEXT , Olafur Gudmundsson Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 23 Jul 2001 14:03:13 -0700 Content-Transfer-Encoding: 7bit On Mon, 23 Jul 2001, Edward Lewis wrote: > At 4:13 PM -0400 7/23/01, Brian Wellington wrote: > >> I still think that the draft should say that you MUST NOT set the AD bit > >> without cryptographic verification of data. could we agree on this? if the > >> server should try to verify the data at all is an implementational issue. > > > >No, we can't all agree on this. > > > >Let's say I have a signed zone. I signed it myself. I configured the > >server myself. I tested the server to make sure it's returning the right > >answers, and they authenticate. I know everything's correct. Why can't > >my server set the AD bit? > > Because the time between your verification of the data and my receipt of > the data may be quite significant. Even if the server does verify-on-query, that might be true. > I would be more comfortable if the authoritative server only set the AA bit > if the data is not checked on send. I don't understand the rationale for > wantint to se the AD bit without checking. (Seems like the operation to > set the bit would be a needless use of a cycle or two.) We're going in circles. The server would set the AD bit, if it used that policy, so that recursive clients would see the AD bit. > >If you don't want your server to behave that way, then don't use that > >policy. > > What do you mean by that? What other server can I use other than BIND? BIND 9 doesn't set the AD bit on authoritative data at all. And specific implementations should have no impact on specs. There's nothing stopping you from writing your own server. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 23 18:14:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27628 for ; Mon, 23 Jul 2001 18:14:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15OmqT-000Iz4-00 for namedroppers-data@psg.com; Mon, 23 Jul 2001 14:02:29 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15OmqS-000Iyx-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 14:02:28 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15OmqS-0000x3-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 14:02:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Brian Wellington To: Edward Lewis cc: Jakob Schlyter , Roy Arends , DNSEXT , Olafur Gudmundsson Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 23 Jul 2001 14:02:29 -0700 Content-Transfer-Encoding: 7bit On Mon, 23 Jul 2001, Edward Lewis wrote: > At 4:13 PM -0400 7/23/01, Brian Wellington wrote: > >> I still think that the draft should say that you MUST NOT set the AD bit > >> without cryptographic verification of data. could we agree on this? if the > >> server should try to verify the data at all is an implementational issue. > > > >No, we can't all agree on this. > > > >Let's say I have a signed zone. I signed it myself. I configured the > >server myself. I tested the server to make sure it's returning the right > >answers, and they authenticate. I know everything's correct. Why can't > >my server set the AD bit? > > Because the time between your verification of the data and my receipt of > the data may be quite significant. Even if the server does verify-on-query, that might be true. > I would be more comfortable if the authoritative server only set the AA bit > if the data is not checked on send. I don't understand the rationale for > wantint to se the AD bit without checking. (Seems like the operation to > set the bit would be a needless use of a cycle or two.) We're going in circles. The server would set the AD bit, if it used that policy, so that recursive clients would see the AD bit. > >If you don't want your server to behave that way, then don't use that > >policy. > > What do you mean by that? What other server can I use other than BIND? BIND 9 doesn't set the AD bit on authoritative data at all. And specific implementations should have no impact on specs. There's nothing stopping you from writing your own server. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 23 18:15:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27703 for ; Mon, 23 Jul 2001 18:15:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15OmiY-000Ifj-00 for namedroppers-data@psg.com; Mon, 23 Jul 2001 13:54:18 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15OmiX-000Ifc-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 13:54:17 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15OmiX-0000hr-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 13:54:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Edward Lewis To: Brian Wellington Cc: Jakob Schlyter , Edward Lewis , Roy Arends , DNSEXT , Olafur Gudmundsson Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 23 Jul 2001 13:54:18 -0700 Content-Transfer-Encoding: 7bit At 4:13 PM -0400 7/23/01, Brian Wellington wrote: >> I still think that the draft should say that you MUST NOT set the AD bit >> without cryptographic verification of data. could we agree on this? if the >> server should try to verify the data at all is an implementational issue. > >No, we can't all agree on this. > >Let's say I have a signed zone. I signed it myself. I configured the >server myself. I tested the server to make sure it's returning the right >answers, and they authenticate. I know everything's correct. Why can't >my server set the AD bit? Because the time between your verification of the data and my receipt of the data may be quite significant. I would be more comfortable if the authoritative server only set the AA bit if the data is not checked on send. I don't understand the rationale for wantint to se the AD bit without checking. (Seems like the operation to set the bit would be a needless use of a cycle or two.) >If you don't want your server to behave that way, then don't use that >policy. What do you mean by that? What other server can I use other than BIND? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com You fly too often when ... the airport taxi is on speed-dial. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 23 18:17:14 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27833 for ; Mon, 23 Jul 2001 18:17:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Omfv-000IYe-00 for namedroppers-data@psg.com; Mon, 23 Jul 2001 13:51:35 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15Omfu-000IYY-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 13:51:34 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15Omfu-0000ct-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 13:51:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Jakob Schlyter To: Brian Wellington Cc: Edward Lewis , Roy Arends , DNSEXT , Olafur Gudmundsson Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 23 Jul 2001 13:51:35 -0700 Content-Transfer-Encoding: 7bit On Mon, 23 Jul 2001, Brian Wellington wrote: > Let's say I have a signed zone. I signed it myself. I configured the > server myself. I tested the server to make sure it's returning the right > answers, and they authenticate. I know everything's correct. Why can't > my server set the AD bit? because the signature will expire and you will set the AD bit on data that is no longer authenticated. I've assumed that authenticated means "authenticated using DNSSEC". if you have another definition, your may be correct. 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. From owner-namedroppers@ops.ietf.org Mon Jul 23 18:24:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28104 for ; Mon, 23 Jul 2001 18:24:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15OnvH-000LMJ-00 for namedroppers-data@psg.com; Mon, 23 Jul 2001 15:11:31 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15OnvH-000LMD-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 15:11:31 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15OnvH-0002tF-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 15:11:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Brian Wellington Cc: Jakob Schlyter , Edward Lewis , Roy Arends , DNSEXT , Olafur Gudmundsson Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 23 Jul 2001 15:11:31 -0700 Content-Transfer-Encoding: 7bit > It's also up to the server authors. Speaking as the person most likely to > implement this, I think it's a really bad idea. whoops! while implementors certainly deserve our sympathy, we need to also be conscious of what users want and what is the technically best protocol. i hope you can separate your roles as document editor and as implementor. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 23 18:59:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29332 for ; Mon, 23 Jul 2001 18:59:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15OoGs-000Lje-00 for namedroppers-data@psg.com; Mon, 23 Jul 2001 15:33:50 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15OoGs-000LjY-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 15:33:50 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15OoGs-0003YK-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 15:33:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Jakob Schlyter To: Olafur Gudmundsson Cc: Roy Arends , Edward Lewis , DNSEXT mailing list , Brian Wellington Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 23 Jul 2001 15:33:50 -0700 Content-Transfer-Encoding: 7bit On Mon, 23 Jul 2001, Olafur Gudmundsson wrote: > > 3) If you trust the authoritative server, you don't need the AD bit. > > Correct, in the case of authorative data from that server, > For authorative answers (AA set), AD is redundant, but > if AA is not set then AD has value. the AD bit is very useful for applications that like to get a hint whether the data was authenticated (i.e. "secured by dnssec") or not. it is currently also the only way for an application that doesn't do dnssec on its own to know if the server verified the data or not. the application shouldn't have to care about AA - just looking at AD is enough if we trust the configured server. a system running a local cache-only nameserver configured to do dnssec verification is one example where this could be used. 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. From owner-namedroppers@ops.ietf.org Mon Jul 23 19:04:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29502 for ; Mon, 23 Jul 2001 19:04:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15OoI4-000LkX-00 for namedroppers-data@psg.com; Mon, 23 Jul 2001 15:35:04 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15OoI3-000LkR-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 15:35:03 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15OoI3-0003aU-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 15:35:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Brian Wellington To: Randy Bush cc: Jakob Schlyter , Edward Lewis , Roy Arends , DNSEXT , Olafur Gudmundsson Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 23 Jul 2001 15:35:04 -0700 Content-Transfer-Encoding: 7bit On Mon, 23 Jul 2001, Randy Bush wrote: > > It's also up to the server authors. Speaking as the person most likely to > > implement this, I think it's a really bad idea. > > whoops! while implementors certainly deserve our sympathy, we need to also > be conscious of what users want and what is the technically best protocol. > i hope you can separate your roles as document editor and as implementor. Sorry if I gave a bad impression. I'll try to clear it up. As the document editor, I think that all of the following are reasonable ideas for handling authoritative data, and should be allowed by the spec. - validation at query time - validation at startup - setting the AD bit without explicit server validation - never setting the AD bit. None of these are wrong, and that's why the draft specifies that the server may set the AD bit, according to local policy. If anyone thinks that one of these is more correct than the others, they can use that policy. As an implementor, I hope to never implement validation at query time, because it's horribly complicated. The others aren't too bad. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 23 19:15:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00056 for ; Mon, 23 Jul 2001 19:15:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15OoR5-000M2L-00 for namedroppers-data@psg.com; Mon, 23 Jul 2001 15:44:23 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15OoR4-000M2F-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 15:44:22 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15OoR4-0003rB-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 15:44:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Brian Wellington To: Jakob Schlyter cc: Edward Lewis , Roy Arends , DNSEXT , Olafur Gudmundsson Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 23 Jul 2001 15:44:23 -0700 Content-Transfer-Encoding: 7bit On Mon, 23 Jul 2001, Jakob Schlyter wrote: > On Mon, 23 Jul 2001, Brian Wellington wrote: > > > Let's say I have a signed zone. I signed it myself. I configured the > > server myself. I tested the server to make sure it's returning the right > > answers, and they authenticate. I know everything's correct. Why can't > > my server set the AD bit? > > because the signature will expire and you will set the AD bit on data that > is no longer authenticated. Not necessarily. If I properly manage my zone, I'll have resigned it and reloaded the server before the data expires. Again, it's local policy. I trust myself to manage my secure zone. > I've assumed that authenticated means "authenticated using DNSSEC". if you > have another definition, your may be correct. RFC 2535: Authenticated means that the data has a valid SIG under a KEY traceable via a chain of zero or more SIG and KEY RRs allowed by the resolvers policies to a KEY staticly configured at the resolver. That's the definition I've been using. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 23 19:51:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA02171 for ; Mon, 23 Jul 2001 19:51:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15OoqO-000Mne-00 for namedroppers-data@psg.com; Mon, 23 Jul 2001 16:10:32 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15OoqO-000MnY-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 16:10:32 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15OoqO-0004by-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 16:10:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roy Arends To: Edward Lewis Cc: Roy Arends , , , Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 23 Jul 2001 16:10:32 -0700 Content-Transfer-Encoding: 7bit On Mon, 23 Jul 2001, Edward Lewis wrote: > At 3:40 PM -0400 7/23/01, Roy Arends wrote: > > > >The key point here is "don't set the AD bit without locally verifying the > >data". Exactly true, no arguments here. BUT, I happen to verify the data > >every single day by re-signing the zone. I do not want the extra burdon of > >double authentication. > > The BIND 9 signer doesn't always verify the signatures it generates. > (There's an option to do so, but the server can't tell if it has been used.) No problem, If I tell the server to trust the data on disk (according to local policy, etc etc), it should not care. > >In the general case it would be better if a stub (non-crypto-doing) > >resolver (lemme rephrase that : ANY resolver !) were using a recursive > >server, because it saves bandwith, load on authoritative servers. This > >is also true in the cache that someone is doing DNSSEC, regardless of > >this draft. > > Don't pin me into having to use the server just one way! Many folks will > combine the authortitative server with a (local-only) recursive server, > e.g., as on a firewall. I'm not doing that, combine authoritative and recursive in whichever way it is conveniant. I said "in the general case" and "would be better" for the situ in general, regardless of crypto. > >Because it does not add extra trust. > > It's not always about trust. (See my earlier message about signature > validity and verifying the key chain.) Trust following local policy. That includes ofcourse how data is handled, how the authoritative server is configured, this should include a statement that the administrator is aware- and will take care of, expirating sigs. > >> Why do I have to buy into the mantra "I just trust what's on my disk?" > > > >Come'on, this is like saying, "I wanna trust the server, but I don't want > >automagically want to trust the data, so the server must validate it". Why > >would a malicious user not compromise the server-software, if it could > >compromise the data on disk. > > > >If you want to trust an authoritative nameserver, use TSIG/SIG(0), it is > >the only real trust mechanism in this particular scheme. > > Well, there is IPSEC too. What I mean is "If you want to be able to trust an authoritative nameserver, do not only rely on the AD bit, but have some transaction authentication in place". > But my point here is that I don't want the specification to be limited > by what is implemented. The specification is not limited, its more open. Roy Arends Nominum to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 23 20:02:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA02762 for ; Mon, 23 Jul 2001 20:02:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15OoqO-000Mne-00 for namedroppers-data@psg.com; Mon, 23 Jul 2001 16:10:32 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15OoqO-000MnY-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 16:10:32 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15OoqO-0004by-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 16:10:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roy Arends To: Edward Lewis Cc: Roy Arends , , , Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 23 Jul 2001 16:10:32 -0700 Content-Transfer-Encoding: 7bit On Mon, 23 Jul 2001, Edward Lewis wrote: > At 3:40 PM -0400 7/23/01, Roy Arends wrote: > > > >The key point here is "don't set the AD bit without locally verifying the > >data". Exactly true, no arguments here. BUT, I happen to verify the data > >every single day by re-signing the zone. I do not want the extra burdon of > >double authentication. > > The BIND 9 signer doesn't always verify the signatures it generates. > (There's an option to do so, but the server can't tell if it has been used.) No problem, If I tell the server to trust the data on disk (according to local policy, etc etc), it should not care. > >In the general case it would be better if a stub (non-crypto-doing) > >resolver (lemme rephrase that : ANY resolver !) were using a recursive > >server, because it saves bandwith, load on authoritative servers. This > >is also true in the cache that someone is doing DNSSEC, regardless of > >this draft. > > Don't pin me into having to use the server just one way! Many folks will > combine the authortitative server with a (local-only) recursive server, > e.g., as on a firewall. I'm not doing that, combine authoritative and recursive in whichever way it is conveniant. I said "in the general case" and "would be better" for the situ in general, regardless of crypto. > >Because it does not add extra trust. > > It's not always about trust. (See my earlier message about signature > validity and verifying the key chain.) Trust following local policy. That includes ofcourse how data is handled, how the authoritative server is configured, this should include a statement that the administrator is aware- and will take care of, expirating sigs. > >> Why do I have to buy into the mantra "I just trust what's on my disk?" > > > >Come'on, this is like saying, "I wanna trust the server, but I don't want > >automagically want to trust the data, so the server must validate it". Why > >would a malicious user not compromise the server-software, if it could > >compromise the data on disk. > > > >If you want to trust an authoritative nameserver, use TSIG/SIG(0), it is > >the only real trust mechanism in this particular scheme. > > Well, there is IPSEC too. What I mean is "If you want to be able to trust an authoritative nameserver, do not only rely on the AD bit, but have some transaction authentication in place". > But my point here is that I don't want the specification to be limited > by what is implemented. The specification is not limited, its more open. Roy Arends Nominum to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 23 20:19:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA03713 for ; Mon, 23 Jul 2001 20:19:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15OpFj-000NSW-00 for namedroppers-data@psg.com; Mon, 23 Jul 2001 16:36:43 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15OpFj-000NSQ-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 16:36:43 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15OpFj-0005MA-00 for namedroppers@ops.ietf.org; Mon, 23 Jul 2001 16:36:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roy Arends To: Olafur Gudmundsson Cc: Roy Arends , Edward Lewis , DNSEXT mailing list , Brian Wellington Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 23 Jul 2001 16:36:43 -0700 Content-Transfer-Encoding: 7bit On Mon, 23 Jul 2001, Olafur Gudmundsson wrote: > There is an extra dimension missing from this arguement, Nameserver trust. > Resolver either trusts a nameserver (by policy) or it does not! > > If I configure my resolver to trust noone then it will verify all > signatures. If I configure it to trust cr.yp.to. then it will verify all > signatures execpt the ones that come from cr.yp.to. with the AD bit set. > > > > 1) Don't trust AD, unless TSIG/SIG(0) is used. > > I think you want to say, > Do not trust AD unless message is authenticated AND from a > trusted nameserver. Yes. > > 2) If you do TSIG/SIG(0) to an authoritative serve you implying you trust > > the authoritative server. > > TSIG only authenticates the message and origin, what resolver does > with the contents depends on policy, it may or may not trust the > server. If the local trust policy of a resolver states "trust a query-response with the AD bit set from ba.di.mp" it would be worthless without stating "only trust AD bit for ba.di.mp when transaction is validated" (implying some secure transaction, maybe even TSIG/SIG(0)). As I said, using TSIG/SIG(0) to an authoritative server the resolver implies that it trust the authoritative server. The contents coming from that server is a different thing. If the AD bit is set, a server indicates that it validated the contents in the answer/authority section according to its own policy. Keyword here is _server_. Now, if the resolver can trust the server (or message from that server), it can trust that the AD bit was indeed set by that server. Indeed, if it will/wants to/can trust the contents, following its own policy, is up to the resolver. > > 3) If you trust the authoritative server, you don't need the AD bit. > > Correct, in the case of authorative data from that server, > For authorative answers (AA set), AD is redundant. Exactly ! > but if AA is not set then AD has value. Exactly ! Roy Arends Nominum to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 24 11:38:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25534 for ; Tue, 24 Jul 2001 11:38:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15P3TY-0000jj-00 for namedroppers-data@psg.com; Tue, 24 Jul 2001 07:47:56 -0700 Received: from [147.28.4.2] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15P3TW-0000jd-00 for namedroppers@ops.ietf.org; Tue, 24 Jul 2001 07:47:55 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15P3TV-0001xg-00 for namedroppers@ops.ietf.org; Tue, 24 Jul 2001 07:47:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: ted@tednet.nl (Ted Lindgreen) Reply-To: Ted.Lindgreen@tednet.nl To: Brian Wellington , Jakob Schlyter Cc: Edward Lewis , Roy Arends , DNSEXT , Olafur Gudmundsson Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: "Brian Wellington's message as of Jul 24, 1:02" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 24 Jul 2001 07:47:56 -0700 Content-Transfer-Encoding: 7bit [Quoting Brian Wellington, on Jul 24, 1:02, in "Re: I-D ACTION:draft ..."] > On Mon, 23 Jul 2001, Jakob Schlyter wrote: > > > On Mon, 23 Jul 2001, Brian Wellington wrote: > > > > > Let's say I have a signed zone. I signed it myself. I configured the > > > server myself. I tested the server to make sure it's returning the right > > > answers, and they authenticate. I know everything's correct. Why can't > > > my server set the AD bit? > > > > because the signature will expire and you will set the AD bit on data that > > is no longer authenticated. > > Not necessarily. If I properly manage my zone, I'll have resigned it and > reloaded the server before the data expires. Again, it's local policy. > I trust myself to manage my secure zone. The problem is that BIND-9 is forcing the world to adopt your policy to "properly manage my zone", while practice has learned that many systemadministrators have a hard time doing that always and timely. >From the .nl.nl DNSSEC experiment, running for over a year now, we have experienced, that none of the participants, including ourselves, have managed to always resign their zones in time. In most cases, sig-expires are followed by a period, where the sigs remain expired until someone notices it and warns, and someone else says "Ooops" :-) As an off-topic side note: how do we find out that sigs are expired? We run good-old bind-8 on one of the secondary servers, which we periodically restart. In contrast to bind-9, bind-8 complains loudly when started with outdated signatures. However, I would like to retire bind-8 someday.... Regards, -- ted to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 24 11:38:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25553 for ; Tue, 24 Jul 2001 11:38:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15P3P4-0000Zu-00 for namedroppers-data@psg.com; Tue, 24 Jul 2001 07:43:18 -0700 Received: from [147.28.4.2] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15P3P3-0000Zo-00 for namedroppers@ops.ietf.org; Tue, 24 Jul 2001 07:43:17 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15P3P1-0001x8-00 for namedroppers@ops.ietf.org; Tue, 24 Jul 2001 07:43:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roy Arends To: Brian Wellington Cc: Randy Bush , Jakob Schlyter , Edward Lewis , Roy Arends , DNSEXT , Olafur Gudmundsson Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 24 Jul 2001 07:43:18 -0700 Content-Transfer-Encoding: 7bit On Mon, 23 Jul 2001, Brian Wellington wrote: > As the document editor, I think that all of the following are reasonable > ideas for handling authoritative data, and should be allowed by the spec. > > - validation at query time > - validation at startup > - setting the AD bit without explicit server validation > - never setting the AD bit. > > None of these are wrong, and that's why the draft specifies that the > server may set the AD bit, according to local policy. If anyone thinks > that one of these is more correct than the others, they can use that > policy. > > As an implementor, I hope to never implement validation at query time, > because it's horribly complicated. The others aren't too bad. As an administrator, I have tested the following: An alternative for validation at query time for BIND 9. A server (BIND 9), using views where in the authoritative view only the server itself is allowed to query (and secondaries), and the recursive view where the world is allowed to query. That plus a trusted key statement for the zones on disk. This will result in a server which loads data from disk, and at query time will validate the answer, and if appropriate, sets the AD bit in the response, in responses to world. Validation at query time & loaded from disk by the same server. Roy Arends Nominum to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 24 13:28:09 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04304 for ; Tue, 24 Jul 2001 13:28:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15P5ZR-0005bH-00 for namedroppers-data@psg.com; Tue, 24 Jul 2001 10:02:09 -0700 Received: from dhcp-sjc9-171-70-52-63.cisco.com ([171.70.52.63] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15P5ZR-0005aS-00 for namedroppers@ops.ietf.org; Tue, 24 Jul 2001 10:02:09 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15P5Yw-0002B0-00 for namedroppers@ops.ietf.org; Tue, 24 Jul 2001 10:01:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Brian Wellington To: Cc: Jakob Schlyter , Edward Lewis , Roy Arends , DNSEXT , Olafur Gudmundsson Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: <200107241213.f6OCDb177818@open.nlnetlabs.nl> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 24 Jul 2001 10:02:09 -0700 Content-Transfer-Encoding: 7bit On Tue, 24 Jul 2001, Ted Lindgreen wrote: > [Quoting Brian Wellington, on Jul 24, 1:02, in "Re: I-D ACTION:draft ..."] > > On Mon, 23 Jul 2001, Jakob Schlyter wrote: > > > > > On Mon, 23 Jul 2001, Brian Wellington wrote: > > > > > > > Let's say I have a signed zone. I signed it myself. I configured the > > > > server myself. I tested the server to make sure it's returning the right > > > > answers, and they authenticate. I know everything's correct. Why can't > > > > my server set the AD bit? > > > > > > because the signature will expire and you will set the AD bit on data that > > > is no longer authenticated. > > > > Not necessarily. If I properly manage my zone, I'll have resigned it and > > reloaded the server before the data expires. Again, it's local policy. > > I trust myself to manage my secure zone. > > The problem is that BIND-9 is forcing the world to adopt your policy > to "properly manage my zone", while practice has learned that many > systemadministrators have a hard time doing that always and timely. No it isn't. BIND 9 supports the "never set the AD bit on authoritative zone" policy. It has the advantage of being the cleanest to implement. See the message posted earlier today by Roy Arends on how to set up BIND 9 with multiple views to get verification of authoritative data. > From the .nl.nl DNSSEC experiment, running for over a year now, we > have experienced, that none of the participants, including ourselves, > have managed to always resign their zones in time. In most cases, > sig-expires are followed by a period, where the sigs remain expired > until someone notices it and warns, and someone else says "Ooops" :-) I can honestly say that I have no experience running a production signed zone. If I did, I'd probably use cron to remind myself to resign it. > As an off-topic side note: how do we find out that sigs are expired? > We run good-old bind-8 on one of the secondary servers, which we > periodically restart. In contrast to bind-9, bind-8 complains > loudly when started with outdated signatures. However, I would > like to retire bind-8 someday.... Find and/or write an external program to do this. The fact that bind 8 does signature checking on load makes it unacceptably slow to start. It's possible that bind 9 will at least do expiration checking on load at some point, but not anytime in the near future. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 24 14:24:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09003 for ; Tue, 24 Jul 2001 14:24:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15P6Bi-0006mz-00 for namedroppers-data@psg.com; Tue, 24 Jul 2001 10:41:42 -0700 Received: from dhcp-sjc9-171-70-52-63.cisco.com ([171.70.52.63] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15P6Bh-0006ma-00 for namedroppers@ops.ietf.org; Tue, 24 Jul 2001 10:41:41 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15P61i-0002CR-00 for namedroppers@ops.ietf.org; Tue, 24 Jul 2001 10:31:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Edward Lewis To: Brian Wellington Cc: Edward Lewis , DNSEXT Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: References: <200107241213.f6OCDb177818@open.nlnetlabs.nl> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 24 Jul 2001 10:41:42 -0700 Content-Transfer-Encoding: 7bit At 12:19 PM -0400 7/24/01, Brian Wellington wrote: >Find and/or write an external program to do this. The fact that bind 8 >does signature checking on load makes it unacceptably slow to start. It's >possible that bind 9 will at least do expiration checking on load at some >point, but not anytime in the near future. It seems that non-cryptographic checking of signatures seems to be at least a compromise solution. This means validity period, other semantic checks, but exclusive of building the key chain and even a local verification (meaning the key is on hand). Although I have been arguing for verify-on-send/reply, I should be clear that I realize that this is an onerous operation and I believe this isn't to be the norm (given the assumption that resolvers look for AD AA). There have been some research applications where this feature would be desirable, which is why I've expressed that it should be an option (and I'm willing to live with this as an unimplemented option so long as ISC will at some time accept patches to BIND if the research applications ever perform the implementation). -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com You fly too often when ... the airport taxi is on speed-dial. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 24 15:25:17 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13466 for ; Tue, 24 Jul 2001 15:25:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15P7KY-0009FN-00 for namedroppers-data@psg.com; Tue, 24 Jul 2001 11:54:54 -0700 Received: from dhcp-sjc9-171-70-52-63.cisco.com ([171.70.52.63] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15P7KX-0009F4-00 for namedroppers@ops.ietf.org; Tue, 24 Jul 2001 11:54:54 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15P7K2-0002H8-00 for namedroppers@ops.ietf.org; Tue, 24 Jul 2001 11:54:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Brian Wellington To: Edward Lewis cc: DNSEXT Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 24 Jul 2001 11:54:54 -0700 Content-Transfer-Encoding: 7bit On Tue, 24 Jul 2001, Edward Lewis wrote: > At 12:19 PM -0400 7/24/01, Brian Wellington wrote: > >Find and/or write an external program to do this. The fact that bind 8 > >does signature checking on load makes it unacceptably slow to start. It's > >possible that bind 9 will at least do expiration checking on load at some > >point, but not anytime in the near future. > > It seems that non-cryptographic checking of signatures seems to be at least > a compromise solution. This means validity period, other semantic checks, > but exclusive of building the key chain and even a local verification > (meaning the key is on hand). 944. [func] Check for expired signatures on load. It only prints one warning per zone, since the BIND 8 method of filling up syslog with hundreds of messages is silly. > Although I have been arguing for verify-on-send/reply, I should be clear > that I realize that this is an onerous operation and I believe this isn't > to be the norm (given the assumption that resolvers look for AD AA). > There have been some research applications where this feature would be > desirable, which is why I've expressed that it should be an option (and I'm > willing to live with this as an unimplemented option so long as ISC will at > some time accept patches to BIND if the research applications ever perform > the implementation). Would such an implementation offer anything over the multiple-view solution? Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 24 16:43:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20790 for ; Tue, 24 Jul 2001 16:43:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15P8Sb-000Bde-00 for namedroppers-data@psg.com; Tue, 24 Jul 2001 13:07:17 -0700 Received: from dhcp-sjc9-171-70-52-63.cisco.com ([171.70.52.63] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15P8Sa-000BcS-00 for namedroppers@ops.ietf.org; Tue, 24 Jul 2001 13:07:16 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15P8S3-0002LU-00 for namedroppers@ops.ietf.org; Tue, 24 Jul 2001 13:06:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: ted@tednet.nl (Ted Lindgreen) Reply-To: Ted.Lindgreen@tednet.nl To: Edward Lewis , Brian Wellington Cc: DNSEXT Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: "Edward Lewis's message as of Jul 24, 20:33" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 24 Jul 2001 13:07:17 -0700 Content-Transfer-Encoding: 7bit [Quoting Edward Lewis, on Jul 24, 20:33, in "Re: I-D ACTION:draft ..."] > Although I have been arguing for verify-on-send/reply, ... I totally agree with this, like probably almost everyone else on this list, certainly for the common case of all reasonably sized zones, which is > 99% of all zones. A special solution (an option to disable it) seems more logical to cope with the special case. I can understand that for a handfull of superlarge zones like .com, BIND can run into a performance problem, but I don't understand why this must lead to not implement signature checking of local data at all into nameserver software meant for general use. Or should we conclude from this that BIND-9, in contrast to all previous BIND implementations, is geared towards the special case of superlarge zones, and this special case only? Also, another proposal from Nominum (Roy Arends) to separate the functions from authorative servers and caching forwarders, which does not fit in many (most?) situations, like nameservers on company, university, etc. networks, seems to support the above conclusion. However, I can not believe that such is what ISC wants, and what the various organisations that donate to ISC for BIND development expect. Or am I missing something? Confused, -- ted to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 24 19:09:11 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00363 for ; Tue, 24 Jul 2001 19:09:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15PAPv-000FNs-00 for namedroppers-data@psg.com; Tue, 24 Jul 2001 15:12:39 -0700 Received: from [147.28.4.2] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15PAPs-000FNl-00 for namedroppers@ops.ietf.org; Tue, 24 Jul 2001 15:12:38 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15PAP3-0002N6-00 for namedroppers@ops.ietf.org; Tue, 24 Jul 2001 15:11:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: ted@tednet.nl (Ted Lindgreen) Reply-To: Ted.Lindgreen@tednet.nl To: Edward Lewis , Brian Wellington Cc: DNSEXT Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: "Edward Lewis's message as of Jul 24, 20:33" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 24 Jul 2001 15:12:39 -0700 Content-Transfer-Encoding: 7bit [Quoting Edward Lewis, on Jul 24, 20:33, in "Re: I-D ACTION:draft ..."] > Although I have been arguing for verify-on-send/reply, ... I totally agree with this, like probably almost everyone else on this list, certainly for the common case of all reasonably sized zones, which is > 99% of all zones. A special solution (an option to disable it) seems more logical to cope with the special case. I can understand that for a handfull of superlarge zones like .com, BIND can run into a performance problem, but I don't understand why this must lead to not implement signature checking of local data at all into nameserver software meant for general use. Or should we conclude from this that BIND-9, in contrast to all previous BIND implementations, is geared towards the special case of superlarge zones, and this special case only? Also, another proposal from Nominum (Roy Arends) to separate the functions from authorative servers and caching forwarders, which does not fit in many (most?) situations, like nameservers on company, university, etc. networks, seems to support the above conclusion. However, I can not believe that such is what ISC wants, and what the various organisations that donate to ISC for BIND development expect. Or am I missing something? Confused, -- ted to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 24 19:20:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00835 for ; Tue, 24 Jul 2001 19:20:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15PB2o-000Gju-00 for namedroppers-data@psg.com; Tue, 24 Jul 2001 15:52:50 -0700 Received: from [147.28.4.2] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15PB2o-000Gjo-00 for namedroppers@ops.ietf.org; Tue, 24 Jul 2001 15:52:50 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15PB2m-0002Rp-00 for namedroppers@ops.ietf.org; Tue, 24 Jul 2001 15:52:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Brian Wellington Cc: DNSEXT Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt References: <200107242005.f6OK5AL79071@open.nlnetlabs.nl> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 24 Jul 2001 15:52:50 -0700 Content-Transfer-Encoding: 7bit > I'm confused as to how "almost everyone" agrees with this. most of us are silent unless we have something new to say. but if you want meeee tooooos. randy, individual hat for sure to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 24 19:20:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00839 for ; Tue, 24 Jul 2001 19:20:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15PATS-000FS2-00 for namedroppers-data@psg.com; Tue, 24 Jul 2001 15:16:18 -0700 Received: from [147.28.4.2] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15PATQ-000FRw-00 for namedroppers@ops.ietf.org; Tue, 24 Jul 2001 15:16:17 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15PATO-0002Nk-00 for namedroppers@ops.ietf.org; Tue, 24 Jul 2001 15:16:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Brian Wellington To: cc: Edward Lewis , DNSEXT Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: <200107242005.f6OK5AL79071@open.nlnetlabs.nl> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 24 Jul 2001 15:16:18 -0700 Content-Transfer-Encoding: 7bit On Tue, 24 Jul 2001, Ted Lindgreen wrote: > [Quoting Edward Lewis, on Jul 24, 20:33, in "Re: I-D ACTION:draft ..."] > > > Although I have been arguing for verify-on-send/reply, ... > > I totally agree with this, like probably almost everyone else on > this list, certainly for the common case of all reasonably sized > zones, which is > 99% of all zones. A special solution (an option > to disable it) seems more logical to cope with the special case. I'm confused as to how "almost everyone" agrees with this. From what I can tell, there are about 5 people participating in this discussion, and only 3 are in favor of this. verify-on-query is incredibly inefficient, even for small zones. Authoritative DNS servers can easily answer thousands of queries per second. Modern computers can maybe do a few hundred signature verifications per second. Combined with other overhead, I'd be surprised if a server doing verify-on-query was less than 10x times slower than an ordinary server. Would you want to run a server like that? I wouldn't. > I can understand that for a handful of superlarge zones like .com, > BIND can run into a performance problem, but I don't understand > why this must lead to not implement signature checking of local > data at all into nameserver software meant for general use. This is not a BIND issue. It's a fundamental problem that DNSSEC verification is slow, and the authoritative server should not be doing it. > Or should we conclude from this that BIND-9, in contrast to all > previous BIND implementations, is geared towards the special > case of superlarge zones, and this special case only? No. BIND 9 is geared towards use. verify-on-query has nothing to do with the size of the zone. It uniformly reduces performance by a significant amount, for virtually no gain. > Also, another proposal from Nominum (Roy Arends) to separate the > functions from authorative servers and caching forwarders, which > does not fit in many (most?) situations, like nameservers on company, > university, etc. networks, seems to support the above conclusion. The multiple-views idea fits perfectly well into any situation. It's still one server. The only difference is that the authoritative part of the server doesn't deal with verification. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 25 09:35:09 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20906 for ; Wed, 25 Jul 2001 09:35:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15POZr-000Ja8-00 for namedroppers-data@psg.com; Wed, 25 Jul 2001 06:19:51 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15POZr-000Ja1-00 for namedroppers@ops.ietf.org; Wed, 25 Jul 2001 06:19:51 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15POZp-0002f4-00 for namedroppers@ops.ietf.org; Wed, 25 Jul 2001 06:19:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Jakob Schlyter To: Brian Wellington Cc: , Edward Lewis , DNSEXT Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 25 Jul 2001 06:19:51 -0700 Content-Transfer-Encoding: 7bit On Tue, 24 Jul 2001, Brian Wellington wrote: > verify-on-query is incredibly inefficient, even for small zones. > Authoritative DNS servers can easily answer thousands of queries per > second. Modern computers can maybe do a few hundred signature > verifications per second. Combined with other overhead, I'd be surprised > if a server doing verify-on-query was less than 10x times slower than an > ordinary server. Would you want to run a server like that? I wouldn't. if you combine an acl for which clients to do verify-on-query for with only doing verify-on-query when the client resolver indicates DNSSEC support (using the EDNS0 DO bit), I do not think this would be a big performance issue. it's also a lot easier than the multiple-view magic. 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. From owner-namedroppers@ops.ietf.org Wed Jul 25 10:08:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23447 for ; Wed, 25 Jul 2001 10:08:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15POE7-000IdS-00 for namedroppers-data@psg.com; Wed, 25 Jul 2001 05:57:23 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15POE6-000IdD-00 for namedroppers@ops.ietf.org; Wed, 25 Jul 2001 05:57:22 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15POE6-0002ZZ-00 for namedroppers@ops.ietf.org; Wed, 25 Jul 2001 05:57:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: gson@nominum.com (Andreas Gustafsson) To: Matt Crawford Cc: Alain Durand , Olafur Gudmundsson , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com Subject: Re: NGtrans - DNSext joint meeting, call for participation In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 25 Jul 2001 05:57:23 -0700 Content-Transfer-Encoding: 7bit Matt Crawford writes: > I offer > http://home.fnal.gov/~crawdad/draft-ietf-dnsext-ipv6-dns-response-00.txt I would like to comment on section 1.3: > 1.3. DNSSEC - Aggravation or Amelioration? > > An extreme case of A6 deployment (some might say a nightmare case), > in the A6 record for each portion of an address is in a zone > belonging to the party by whom that set of bits has been assigned. > This is a situation which is improved by ubiquitous use of DNSSEC > [DNSSEC] since the leaf site can cache authenticated data for its > entire prefix chain and a DNS client can confidently accept that > data without having to make extra queries. You seem to be suggesting that if or when DNSSEC is deployed, authoritative servers should start actively caching data related to the data they are authoritative for, and resolvers (aka caching servers) should start making use of response data outside the domain for which the authoritative server is being queried, rather than discarding it like current resolvers do. I disagree. Having authoritative servers send such cached data, and having resolvers accept it, is a bad idea whether or not DNSSEC is being used. If a DNSSEC aware resolver accepts data from a poisoned cache, DNSSEC will detect the poisoning, but this does not in any way guarantee that the resolution will succeed - in practice, a much more likely outcome is that a security error is returned to the client. This could be exploited for denial of service attacks. -- Andreas Gustafsson, gson@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 25 10:16:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24251 for ; Wed, 25 Jul 2001 10:16:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15POgk-000Jtn-00 for namedroppers-data@psg.com; Wed, 25 Jul 2001 06:26:58 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15POgk-000Jtg-00 for namedroppers@ops.ietf.org; Wed, 25 Jul 2001 06:26:58 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15POgi-0002gb-00 for namedroppers@ops.ietf.org; Wed, 25 Jul 2001 06:26:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: ted@tednet.nl (Ted Lindgreen) Reply-To: Ted.Lindgreen@tednet.nl To: "David R. Conrad" , Ted.Lindgreen@tednet.nl, Edward Lewis , Brian Wellington Cc: DNSEXT Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: ""David R. Conrad"'s message as of Jul 25, 2:22" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 25 Jul 2001 06:26:58 -0700 Content-Transfer-Encoding: 7bit [Quoting "David R. Conrad", on Jul 25, 2:22, in "Re: I-D ACTION:draft ..."] > Hmmm. > > I thought this list was not supposed to delve into particular implementations. You are right, and I'm sorry. > Discussions about what ISC's plans are (or intents were) with BIND are > probably more appropriate on bind{,9}-{users,workers}@isc.org or with ISC's > board directly. While I am not able to speak for ISC in any way, I > suspect ISC will do whatever people who fund it want it to do. I also > suspect that ISC would be willing to consider donations of code for > functionality that people wish to have implemented including something like > verify-on-send/reply or whatever (particularly if it is configurable to > "off" by the administrator who actually wants his/her nameserver to do > something other than verify data). Yes, that's what I expected to hear. Actually, we are trying to make extentions on "host" and "dig", like it was available in Bind-8, to perform SIG verification. However, e-mail exchange with Brian made clear, that such extentions are not desired and will definately not ever be included in BIND-9. So, I'm a bit confused, again. We, NLnet Labs, think that SIG verification tools should be a necessary part of BIND. -- ted to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 25 10:16:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24261 for ; Wed, 25 Jul 2001 10:16:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15POiG-000Jy5-00 for namedroppers-data@psg.com; Wed, 25 Jul 2001 06:28:32 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15POiF-000Jxz-00 for namedroppers@ops.ietf.org; Wed, 25 Jul 2001 06:28:31 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15POiE-0002hE-00 for namedroppers@ops.ietf.org; Wed, 25 Jul 2001 06:28:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "D. J. Bernstein" To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: NGtrans - DNSext joint meeting, call for participation References: <200107202005.f6KK50F11379@gungnir.fnal.gov> <20010723140044.A17822@pianosa.catch22.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 25 Jul 2001 06:28:32 -0700 Content-Transfer-Encoding: 7bit Crawford wants your signatures today to last for a month. What happens if you decide tomorrow to change a machine's address list---for example, adding or removing a second address? Answer: An attacker can interfere with this change for 29 agonizing days. All he has to do is replay the old data under the old signature. The whole point of an expiration date is to stop this attack. Expiration dates far in the future don't do that. Are you willing to have your old data persist for a month after you make a change? Of course not. This is why typical TTLs are at most 1 day, and it's why typical expiration dates will be at most 1 day in the future. Example: My cr.yp.to address is extremely stable. But I want the ability to set up a second cr.yp.to web server with at most one day's notice. That's why my TTL is 1 day, and it's why any signatures that I create will expire within 1 day. The question is not, as Crawford would have you believe, whether the old data lasted for a month. The question is how much _warning_ you have before the old data is replaced with the new data. That's what TTLs measure, and it's what expiration dates measure. Conclusion: The computer will sign every record every day. Renumbering every day, with AAAA or A6, adds _nothing_ to this signing cost. David Terrell writes: > Did I miss somewhere where the expiration of the cryptographic > signature was defined to replace the normal DNS TTL on the record? In DNSSEC, the lifetime of a record is limited by the relative TTL _and_ by the absolute expiration date. See RFC 2535, section 4.4. As for ``replace'': It's true that a better-designed protocol would simply use absolute dates, not relative times. However, DNSSEC servers are still supposed to manage TTLs for compatibility with non-DNSSEC servers. See RFC 2535, section 2.3.3. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 25 10:17:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24347 for ; Wed, 25 Jul 2001 10:17:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15POf3-000Jnx-00 for namedroppers-data@psg.com; Wed, 25 Jul 2001 06:25:13 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15POf3-000Jnr-00 for namedroppers@ops.ietf.org; Wed, 25 Jul 2001 06:25:13 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15POf1-0002gI-00 for namedroppers@ops.ietf.org; Wed, 25 Jul 2001 06:25:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: ted@tednet.nl (Ted Lindgreen) Reply-To: Ted.Lindgreen@tednet.nl To: Brian Wellington , Cc: Edward Lewis , DNSEXT Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: "Brian Wellington's message as of Jul 25, 0:32" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 25 Jul 2001 06:25:13 -0700 Content-Transfer-Encoding: 7bit [Quoting Brian Wellington, on Jul 25, 0:32, in "Re: I-D ACTION:draft ..."] > This is not a BIND issue. It's a fundamental problem that DNSSEC > verification is slow, and the authoritative server should not be doing it. I do not think that many people on this list agree with this statement. The main question was: When an authorative nameserver sets the AD, is it then: - A MUST that the nameserver software makes sure the data is sane? - Is it sufficient to rely on the fact that the data comes from disk and that the sysadm has taken care of putting valid data there and always refreshing the sigs in time? I think many of us, especially those with operational experience in large scale production environments, think that the latter is not sufficient. Further, I personaly think that not setting the AD bit and splitting functionality of authorative and caching servers are just workarounds. If efficiency is a big issue, I think that everybody can very well live with more efficient procedures than a verify on each and every query, like a one-time verify on startup, reload and AXFR, plus a timer to prevent unnoticed sigexpires. I don't think that many people will agree that just omitting all sanity checks are the solution to efficiency problems. Regards, -- ted PS. About your confusion: > I'm confused as to how "almost everyone" agrees with this. From what I > can tell, there are about 5 people participating in this discussion, and > only 3 are in favor of this. Indeed, in the last discussion only 5 people spoke up, but this issue is not new. It has been a topic on at least 4 IETF meetings, 4 RIPE meetings, other (ccTLD) meetings and conferences, and more DNSSEC workshops than I can remember exactly how many. Sofar, almost everybody I heard about this issue, had the opinion, that secure aware nameservers, including and especially authorative nameservers, should be careful not to produce data with bad and/or expired sigantures. During the various workshops, everybody, without exception, was amazed, to say it mildly, on finding out that BIND-9 does not do any checking on the data it's authorative for and starts up and happliy answers with outdated SIGs. My statement "almost everyone" was based on this experience. But, my remark, that the current software, BIND-9, does not do any sanity check on SIGs, while the former BIND-8 release did a resonable job here, is an implementation issue and indeed off-topic on this list, for which I apologise. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 25 10:17:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24367 for ; Wed, 25 Jul 2001 10:17:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15POga-000JtZ-00 for namedroppers-data@psg.com; Wed, 25 Jul 2001 06:26:48 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15POgZ-000JtT-00 for namedroppers@ops.ietf.org; Wed, 25 Jul 2001 06:26:47 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15POgY-0002gY-00 for namedroppers@ops.ietf.org; Wed, 25 Jul 2001 06:26:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "David R. Conrad" To: Ted.Lindgreen@tednet.nl, Edward Lewis , Brian Wellington Cc: DNSEXT Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: References: <"Edward Lewis's message as of Jul 24, 20:33"> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 25 Jul 2001 06:26:48 -0700 Content-Transfer-Encoding: 7bit Hmmm. I thought this list was not supposed to delve into particular implementations. Discussions about what ISC's plans are (or intents were) with BIND are probably more appropriate on bind{,9}-{users,workers}@isc.org or with ISC's board directly. While I am not able to speak for ISC in any way, I suspect ISC will do whatever people who fund it want it to do. I also suspect that ISC would be willing to consider donations of code for functionality that people wish to have implemented including something like verify-on-send/reply or whatever (particularly if it is configurable to "off" by the administrator who actually wants his/her nameserver to do something other than verify data). Rgds, -drc At 01:07 PM 7/24/2001 -0700, Ted Lindgreen wrote: >[Quoting Edward Lewis, on Jul 24, 20:33, in "Re: I-D ACTION:draft ..."] > > > Although I have been arguing for verify-on-send/reply, ... > >I totally agree with this, like probably almost everyone else on >this list, certainly for the common case of all reasonably sized >zones, which is > 99% of all zones. A special solution (an option >to disable it) seems more logical to cope with the special case. > >I can understand that for a handfull of superlarge zones like .com, >BIND can run into a performance problem, but I don't understand >why this must lead to not implement signature checking of local >data at all into nameserver software meant for general use. > >Or should we conclude from this that BIND-9, in contrast to all >previous BIND implementations, is geared towards the special >case of superlarge zones, and this special case only? > >Also, another proposal from Nominum (Roy Arends) to separate the >functions from authorative servers and caching forwarders, which >does not fit in many (most?) situations, like nameservers on company, >university, etc. networks, seems to support the above conclusion. > >However, I can not believe that such is what ISC wants, and what >the various organisations that donate to ISC for BIND development >expect. Or am I missing something? > >Confused, >-- ted > > >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 25 10:19:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24513 for ; Wed, 25 Jul 2001 10:19:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15PODz-000Ic4-00 for namedroppers-data@psg.com; Wed, 25 Jul 2001 05:57:15 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15PODy-000Iby-00 for namedroppers@ops.ietf.org; Wed, 25 Jul 2001 05:57:14 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15PODx-0002ZX-00 for namedroppers@ops.ietf.org; Wed, 25 Jul 2001 05:57:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roy Arends To: Cc: Edward Lewis , Brian Wellington , DNSEXT Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 25 Jul 2001 05:57:15 -0700 Content-Transfer-Encoding: 7bit On Tue, 24 Jul 2001, Ted Lindgreen wrote: > Also, another proposal from Nominum (Roy Arends) to separate the > functions from authorative servers and caching forwarders, which > does not fit in many (most?) situations, like nameservers on company, > university, etc. networks, seems to support the above conclusion. If you are referring to my mail from today which stated "as an administrator", this was merely an alternative for validation at query time, using views. Works like a charm. Please enlighten me why it does not fit in many (most?) situations, like nameservers on company, university, etc. networks. > Or should we conclude from this that BIND-9 in contrast to all The draft is a protocol design issue. Please don't confuse implementations with protocols. Now, going back to the draft, I see the following as correct (and generic for _all_ implementations that wish to implement this): On Mon, 23 Jul 2001, Brian Wellington wrote: > As the document editor, I think that all of the following are reasonable > ideas for handling authoritative data, and should be allowed by the > spec. > > - validation at query time > - validation at startup > - setting the AD bit without explicit server validation > - never setting the AD bit. > > None of these are wrong, and that's why the draft specifies that the > server may set the AD bit, according to local policy. If anyone thinks > that one of these is more correct than the others, they can use that > policy. Regards, Roy Arends Nominum to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 25 12:30:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07691 for ; Wed, 25 Jul 2001 12:30:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15PQDt-000OSF-00 for namedroppers-data@psg.com; Wed, 25 Jul 2001 08:05:17 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15PQDt-000ORr-00 for namedroppers@ops.ietf.org; Wed, 25 Jul 2001 08:05:17 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15PQDq-0002pk-00 for namedroppers@ops.ietf.org; Wed, 25 Jul 2001 08:05:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: ted@tednet.nl (Ted Lindgreen) Reply-To: Ted.Lindgreen@tednet.nl To: Roy Arends Cc: DNSEXT Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: "Roy Arends's message as of Jul 25, 15:33" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 25 Jul 2001 08:05:17 -0700 Content-Transfer-Encoding: 7bit [Quoting Roy Arends, on Jul 25, 15:33, in "Re: I-D ACTION:draft ..."] > On Tue, 24 Jul 2001, Ted Lindgreen wrote: > If you are referring to my mail from today which stated "as an > administrator", this was merely an alternative for validation at query > time, using views. Works like a charm. > > Please enlighten me why it does not fit in many (most?) situations, like > nameservers on company, university, etc. networks. OK, these guys (their sysadm's) usually have one or more nameservers, being authorative for the local domain and acting as caching forwarders for their local users. Usually for many years, and many of those sysadm's have experience with various BIND versions over the years. Many of them are not really affraid of upgrading to the next BIND release. However.... With multiple views, either the views must somehow be able to determine for which one an incoming query was meant, or the query must be sent to the right view directly. Since the former is not possible (queries from a stubresolver and from a caching forwarder look the same, at least without further protocol extentions), one must do the latter. So, now we have two named-processes on one machine, either listening on different port numbers, or listening on different IP-numbers. Exploring the first possibility: the sysadm has has no control over all cachers in the world, so asking them to use a special portnumber does not work. So, your authorative view must keep listening on port 53. The next possibility: the sysadm asks and assists all of its local users to change the portnumbers where their stubresolvers send queries. If at all possible on the various OS-flavors, "as an administrator" you should know how happy such a job will make most sysadm's ;-) So, we are stuck with the last option: run the nameservers on a multihomed host, with different IP-numbers for the different views, and either go to the parent (.com, .nl, .de, etc.) to change the delegation, or to all local users who have hardcoded the local dnsservers in their resolve.conf or M$-equivalent to have them change their setup. So, setting up a multihomed host, setting up multiple named-views and getting either TLD or local users to do some administration right is not a job that the average sysadm really looks forward to. That's what I meant with "does not fit". -- ted. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 25 12:36:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08329 for ; Wed, 25 Jul 2001 12:36:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15PQVX-000PIY-00 for namedroppers-data@psg.com; Wed, 25 Jul 2001 08:23:31 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15PQVW-000PIR-00 for namedroppers@ops.ietf.org; Wed, 25 Jul 2001 08:23:30 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15PQVT-0002qY-00 for namedroppers@ops.ietf.org; Wed, 25 Jul 2001 08:23:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Paul A Vixie To: DNSEXT Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: Message from ted@tednet.nl (Ted Lindgreen) of "Wed, 25 Jul 2001 06:26:58 PDT." Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 25 Jul 2001 08:23:31 -0700 Content-Transfer-Encoding: 7bit > Yes, that's what I expected to hear. Actually, we are trying to make > extentions on "host" and "dig", like it was available in Bind-8, to > perform SIG verification. However, e-mail exchange with Brian made > clear, that such extentions are not desired and will definately not > ever be included in BIND-9. > > So, I'm a bit confused, again. We, NLnet Labs, think that SIG > verification tools should be a necessary part of BIND. if it's clean code and includes changes to the documentation and is an option that defaults to off and there are no restrictive licenses on it, isc would include it in a subsequent release. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 25 12:50:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09875 for ; Wed, 25 Jul 2001 12:50:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15PQDa-000ORC-00 for namedroppers-data@psg.com; Wed, 25 Jul 2001 08:04:58 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15PQDZ-000OR6-00 for namedroppers@ops.ietf.org; Wed, 25 Jul 2001 08:04:57 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15PQDW-0002ph-00 for namedroppers@ops.ietf.org; Wed, 25 Jul 2001 08:04:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Edward Lewis To: ogud@ogud.com, Brian.Wellington@nominum.com Cc: DNSEXT Subject: restart: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: References: ""David R. Conrad"'s message as of Jul 25, 2:22" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 25 Jul 2001 08:04:58 -0700 Content-Transfer-Encoding: 7bit The discussion on this document has certainly gotten off course. I think that is a symptom of problems in some of the wording in the document. The document says (in section 2): >The replacement text reads: > > "The AD bit MUST NOT be set on a response unless all of the RRsets in > the answer and authority sections of the response are Authenticated." > > "The AD bit SHOULD be set if and only if all RRs in the answer > section and any relevant negative response RRs in that authority > section are Authenticated." The first paragraph contains a double negative. Although this is a grammer problem, many times such occurrances result in misinterpretations. My more pertinent concern is the referral to "are Authenticated." One possible interpretation is that the data is authenticated upon entry into the server - this is the interpretation held by, at least Brian [0] (can't speak for Olafur as I didn't get an indication from his messages). Another interpretation of this phrase is that data is authenticated upon exit from the server. Other participants in the discussion - Roy, Jakob, and I arrived at this interpretation and discussed this at NIST. Ted's viewpoint is also in line with "the gang of three" from earlier discussions, he was not at the particular workshop. So, my suggestion is for the authors to clarity the meaning of "are Authenticated" in the temporal sense (and use proper capitalization ;)). I understand that this seems like a silly clarification, but the lack of this has resulted in the thread we've witnessed. [0] Not naming names to lay blame, just to clarify that my comment applies to one of the two document authors. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com You fly too often when ... the airport taxi is on speed-dial. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 25 13:39:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15265 for ; Wed, 25 Jul 2001 13:39:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15PRzc-0003ts-00 for namedroppers-data@psg.com; Wed, 25 Jul 2001 09:58:40 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15PRzb-0003tl-00 for namedroppers@ops.ietf.org; Wed, 25 Jul 2001 09:58:40 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15PRzb-0000Gq-00 for namedroppers@ops.ietf.org; Wed, 25 Jul 2001 09:58:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Brian Wellington To: Cc: "David R. Conrad" , Edward Lewis , DNSEXT Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: <200107251104.NAA06359@omval.tednet.nl> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 25 Jul 2001 09:58:40 -0700 Content-Transfer-Encoding: 7bit On Wed, 25 Jul 2001, Ted Lindgreen wrote: > Yes, that's what I expected to hear. Actually, we are trying to make > extentions on "host" and "dig", like it was available in Bind-8, to > perform SIG verification. However, e-mail exchange with Brian made > clear, that such extentions are not desired and will definately not > ever be included in BIND-9. You're taking things out of context. I said that it's not likely that these extensions would be added to dig or host, because dig and host are already bloated enough, and validting chains of signatures is not in the spirit of what they're supposed to do. I said that this should be a separate, and see no reason why the separate tool could not be included. The dig and host extensions in BIND 8 never worked very well, in my opinion. I'd prefer to see something good. > So, I'm a bit confused, again. We, NLnet Labs, think that SIG > verification tools should be a necessary part of BIND. I agree. Just not as a part of dig or host. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 25 13:51:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16563 for ; Wed, 25 Jul 2001 13:51:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15PRpK-0003Gk-00 for namedroppers-data@psg.com; Wed, 25 Jul 2001 09:48:02 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15PRpJ-0003Gd-00 for namedroppers@ops.ietf.org; Wed, 25 Jul 2001 09:48:01 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15PRpJ-0000GO-00 for namedroppers@ops.ietf.org; Wed, 25 Jul 2001 09:48:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "Christian Huitema" To: "D. J. Bernstein" , , Subject: RE: NGtrans - DNSext joint meeting, call for participation Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 25 Jul 2001 09:48:02 -0700 Content-Transfer-Encoding: 7bit > Crawford wants your signatures today to last for a month.=20 > What happens if you decide tomorrow to change a machine's=20 > address list---for example, adding or removing a second address? >=20 > Answer: An attacker can interfere with this change for 29=20 > agonizing days. All he has to do is replay the old data under=20 > the old signature. Dan, What you are saying is that in order to deploy DNSSEC with confidence, a domain administrator should be ready to resign all records on short notice; you define short as one day, but we could easily imagine the requirement being twice a day, as suggested in one of the IPv6 scenarios. There is some aesthetical beauty to the argument, but there is also a flip side: it follows that domain administrators should not deploy DNSSEC if they cannot resign everyone of their records in a flash. So, the question is, how many iterations of Moore's law do we have to wait for until this "renumbering in a flash" becomes reality? Let's define flash as "a few minutes." If we believe Bill Sommerfeld experiment with the mit.edu zone, we are not quite in flash territory yet (90 minutes for 80,000 records), but we are not very far either. Bill used a 333 MHz Celeron laptop; a dual processor 1.7 GHz server could arguably do the job in about 10 minutes. If we changed nothing, if the number of hosts per zone stayed roughly constant and if the key length did not increased, then we could be in flash territory within two iterations of Moore's law. This means that, for reasonable zones, the impact of cost of signature on renumbering could disappear in about 3 years. But Moore's law will not result in a straight gain. As the computers become more powerful, we will need to increase the key length somewhat. As the computers become less expensive, they tend to become more numerous, and we may find more entries in any given zone. We may just as well be 5 years away from nirvana. In between, DNSSEC deployment will remain clumsy, and resigning will still be perceived as an expensive operation. I guess looking at the issue this way helps frame the debate: 3 to 5 years from now, there won't be much practical difference, from a cost of signing point of view, between AAAA and A6.=20 -- Christian Huitema =20 to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 25 14:04:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17764 for ; Wed, 25 Jul 2001 14:04:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15PS1D-0003xN-00 for namedroppers-data@psg.com; Wed, 25 Jul 2001 10:00:19 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15PS1C-0003xH-00 for namedroppers@ops.ietf.org; Wed, 25 Jul 2001 10:00:18 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15PS1B-0000Gw-00 for namedroppers@ops.ietf.org; Wed, 25 Jul 2001 10:00:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Brian Wellington To: Edward Lewis Cc: , DNSEXT Subject: Re: restart: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 25 Jul 2001 10:00:19 -0700 Content-Transfer-Encoding: 7bit On Wed, 25 Jul 2001, Edward Lewis wrote: > The discussion on this document has certainly gotten off course. I think > that is a symptom of problems in some of the wording in the document. I disagree. > The document says (in section 2): > > >The replacement text reads: > > > > "The AD bit MUST NOT be set on a response unless all of the RRsets in > > the answer and authority sections of the response are Authenticated." > > > > "The AD bit SHOULD be set if and only if all RRs in the answer > > section and any relevant negative response RRs in that authority > > section are Authenticated." > > The first paragraph contains a double negative. Although this is a grammer > problem, many times such occurrances result in misinterpretations. > > My more pertinent concern is the referral to "are Authenticated." > > One possible interpretation is that the data is authenticated upon entry > into the server - this is the interpretation held by, at least Brian [0] > (can't speak for Olafur as I didn't get an indication from his messages). > > Another interpretation of this phrase is that data is authenticated upon > exit from the server. Other participants in the discussion - Roy, Jakob, > and I arrived at this interpretation and discussed this at NIST. Ted's > viewpoint is also in line with "the gang of three" from earlier > discussions, he was not at the particular workshop. In the context of a primary server: In the case of a primary server for a secure zone, the data MAY be considered Authenticated, depending on local policy. As far as I can tell, the entire discussion has centered around the statement. So, a primary server can set Authenticated based on whatever criteria it wants. For a recursive server, it doesn't matter. If the data is Authenticated when it's received by the server, the TTL is clamped such that the server drops it before it should be considered anything but Authenticated. So, assuming you trust your clock, it will be Authenticated when handed out. > So, my suggestion is for the authors to clarity the meaning of "are > Authenticated" in the temporal sense (and use proper capitalization ;)). I > understand that this seems like a silly clarification, but the lack of this > has resulted in the thread we've witnessed. I don't a problem here. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 25 14:16:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18947 for ; Wed, 25 Jul 2001 14:16:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15PRpa-0003H6-00 for namedroppers-data@psg.com; Wed, 25 Jul 2001 09:48:18 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15PRpa-0003Gz-00 for namedroppers@ops.ietf.org; Wed, 25 Jul 2001 09:48:18 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15PRpZ-0000GQ-00 for namedroppers@ops.ietf.org; Wed, 25 Jul 2001 09:48:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Brian Wellington To: Jakob Schlyter Cc: , Edward Lewis , DNSEXT Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 25 Jul 2001 09:48:18 -0700 Content-Transfer-Encoding: 7bit On Wed, 25 Jul 2001, Jakob Schlyter wrote: > On Tue, 24 Jul 2001, Brian Wellington wrote: > > > verify-on-query is incredibly inefficient, even for small zones. > > Authoritative DNS servers can easily answer thousands of queries per > > second. Modern computers can maybe do a few hundred signature > > verifications per second. Combined with other overhead, I'd be surprised > > if a server doing verify-on-query was less than 10x times slower than an > > ordinary server. Would you want to run a server like that? I wouldn't. > > if you combine an acl for which clients to do verify-on-query for with > only doing verify-on-query when the client resolver indicates DNSSEC > support (using the EDNS0 DO bit), I do not think this would be a big > performance issue. it's also a lot easier than the multiple-view magic. I don't think you understand the architecture of a name server. There is a 'server' and a 'resolver'. The server deals with authoritative data, and the resolver deals with retrieving and caching data. These modules were hopelessly intertwined in BIND 8; they are mostly separate in BIND 9. All DNSSEC verification occurs in the resolver. The server is only responsible for handing out data, either from authoritative zones or the cache. If it needs something that's not there, it dispatches a resolver to get it. verify-on-query complicates the server, by adding complicated DNSSEC validation logic, and would require significant changes to the existing code. The multiple-view method causes recursive queries to enter the server in such a way that it doesn't consult authoritative data directly, but only cached data. Before it is cached, data is retrieved from the authoritative view, and normal processing causes it to be DNSSEC validated. This works now. It's not much more complicated - about 10 lines of named.conf to define a second view. Yes, I think this is getting off topic for namedroppers, but I completely fail to comprehend why the existing solution is not sufficient. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 25 14:55:11 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23067 for ; Wed, 25 Jul 2001 14:55:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15PT26-0006xp-00 for namedroppers-data@psg.com; Wed, 25 Jul 2001 11:05:18 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15PT25-0006xh-00 for namedroppers@ops.ietf.org; Wed, 25 Jul 2001 11:05:17 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15PT25-0000Iv-00 for namedroppers@ops.ietf.org; Wed, 25 Jul 2001 11:05:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Brian Wellington To: Cc: Edward Lewis , DNSEXT Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: <200107251021.f6PAL0E81771@open.nlnetlabs.nl> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 25 Jul 2001 11:05:18 -0700 Content-Transfer-Encoding: 7bit On Wed, 25 Jul 2001, Ted Lindgreen wrote: > [Quoting Brian Wellington, on Jul 25, 0:32, in "Re: I-D ACTION:draft ..."] > > > This is not a BIND issue. It's a fundamental problem that DNSSEC > > verification is slow, and the authoritative server should not be doing it. > > I do not think that many people on this list agree with this statement. Given that the people who care about DNSSEC are an incredibly small fraction of the total users of DNS, and verify-on-query will slow everything down, someone needs to speak up for them. Authoritative name servers should be handing out data. That's it. > The main question was: > When an authorative nameserver sets the AD, is it then: > - A MUST that the nameserver software makes sure the data is sane? > - Is it sufficient to rely on the fact that the data comes from disk > and that the sysadm has taken care of putting valid data there > and always refreshing the sigs in time? > > I think many of us, especially those with operational experience > in large scale production environments, think that the latter is > not sufficient. Further, I personaly think that not setting the > AD bit and splitting functionality of authorative and caching > servers are just workarounds. Does an authoritative server sanity check anything else? Does it check that your A records point to the correct address? Or that your delegations are sane? No. It checks structural validity for all records. Why should SIGs be any different? > If efficiency is a big issue, I think that everybody can very well > live with more efficient procedures than a verify on each and every > query, like a one-time verify on startup, reload and AXFR, plus a > timer to prevent unnoticed sigexpires. I don't think that many > people will agree that just omitting all sanity checks are the > solution to efficiency problems. That's still not efficient. Anything involving verification at query time could cause the first query to time out while the data is being validated, which will make users unhappy. Adding timers also doesn't scale to large zones, especially large zones with incremental updates. > > I'm confused as to how "almost everyone" agrees with this. From what I > > can tell, there are about 5 people participating in this discussion, and > > only 3 are in favor of this. > > Indeed, in the last discussion only 5 people spoke up, but this > issue is not new. It has been a topic on at least 4 IETF meetings, > 4 RIPE meetings, other (ccTLD) meetings and conferences, and more > DNSSEC workshops than I can remember exactly how many. > > Sofar, almost everybody I heard about this issue, had the opinion, > that secure aware nameservers, including and especially authorative > nameservers, should be careful not to produce data with bad and/or > expired sigantures. During the various workshops, everybody, without > exception, was amazed, to say it mildly, on finding out that BIND-9 > does not do any checking on the data it's authorative for and > starts up and happliy answers with outdated SIGs. > > My statement "almost everyone" was based on this experience. But, > my remark, that the current software, BIND-9, does not do any sanity > check on SIGs, while the former BIND-8 release did a resonable job > here, is an implementation issue and indeed off-topic on this list, > for which I apologise. I don't remember this coming up at any IETFs that I've been to (I've only missed 1 recently) or the DNSSEC workshops I've attended, or the RIPE meeting, but I'll take your word for it. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 25 20:01:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA23172 for ; Wed, 25 Jul 2001 20:01:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15PWNp-000Gqi-00 for namedroppers-data@psg.com; Wed, 25 Jul 2001 14:39:57 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15PWNo-000Gqb-00 for namedroppers@ops.ietf.org; Wed, 25 Jul 2001 14:39:56 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15PWNo-0000Cq-00 for namedroppers@ops.ietf.org; Wed, 25 Jul 2001 14:39:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Mark Kosters To: Brian Wellington Cc: Ted.Lindgreen@tednet.nl, Edward Lewis , DNSEXT Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: ; from Brian.Wellington@nominum.com on Wed, Jul 25, 2001 at 11:05:18AM -0700 References: <200107251021.f6PAL0E81771@open.nlnetlabs.nl> X-Mailer: Mutt 1.0.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 25 Jul 2001 14:39:57 -0700 Content-Transfer-Encoding: 7bit On Wed, Jul 25, 2001 at 11:05:18AM -0700, Brian Wellington wrote: > > > This is not a BIND issue. It's a fundamental problem that DNSSEC > > > verification is slow, and the authoritative server should not be doing it. > > > > I do not think that many people on this list agree with this statement. > > Given that the people who care about DNSSEC are an incredibly small > fraction of the total users of DNS, and verify-on-query will slow > everything down, someone needs to speak up for them. Authoritative name > servers should be handing out data. That's it. Just so Brian does not feel alone, I wince in pain thinking that the gtld or root servers (or any other high query rate authoritative server) would have to perform verify-on-query. Mark to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 25 20:07:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA23481 for ; Wed, 25 Jul 2001 20:07:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15PXie-000Lih-00 for namedroppers-data@psg.com; Wed, 25 Jul 2001 16:05:32 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15PXid-000Lib-00 for namedroppers@ops.ietf.org; Wed, 25 Jul 2001 16:05:31 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15PXic-0000HX-00 for namedroppers@ops.ietf.org; Wed, 25 Jul 2001 19:05:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roy Arends To: Cc: Roy Arends , DNSEXT Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 25 Jul 2001 16:05:32 -0700 Content-Transfer-Encoding: 7bit On Wed, 25 Jul 2001, Ted Lindgreen wrote: > [Quoting Roy Arends, on Jul 25, 15:33, in "Re: I-D ACTION:draft ..."] > > > On Tue, 24 Jul 2001, Ted Lindgreen wrote: > > > If you are referring to my mail from today which stated "as an > > administrator", this was merely an alternative for validation at query > > time, using views. Works like a charm. > > > > Please enlighten me why it does not fit in many (most?) situations, like > > nameservers on company, university, etc. networks. [cut] > So, setting up a multihomed host, setting up multiple named-views > and getting either TLD or local users to do some administration > right is not a job that the average sysadm really looks forward > to. That's what I meant with "does not fit". Ofcourse, the solution would not fit a TLD, since it is not scalable. That is the reason why servers serving TLD's do (should) not allow recursion. And for the same reason (i.e. scaling) administrators administring TLD's probably don't (shouldn't) want crypto-validation on the authoritative servers. This scheme would be perfect for those entities who are authoritative for some zone and offer recursion for their constiuency all on one server. The phrase "don't look forward to" does not really hold, since there are more issues at hand when using DNSSEC then this simpel configuration scheme. Multihomed has really nothing to do with this. Roy Arends Nominum. ------------------------------------------------------- Appendix: I know that the following is totally off-topic, my apologies to the list for that, but since I had a few requests for this, here is how the scheme I mentioned recently can be configured: solution: one server (bind-9), one ip-address. two views. 1) constituency queries recursive view. 2) recursive view queries authoritative view. Config example: Say machine has ip address 192.168.1.1 BEFORE: zone "." {type hint; file "named.root";}; zone "0.0.127.IN-ADDR.ARPA." {type master;file "localhost.rev";}; zone "example.com." {type master;file "example.com.signed";}; AFTER: trusted-keys { example.com. .. .. .. ..; }; view "authoritative" { match-clients { 192.168.1.1; }; recursion no; zone "example.com." {type master;file "example.com.signed";}; }; view "recursive" { match-clients { !192.168.1.1;any; }; recursion yes; zone "." { type hint; file "named.root";}; zone "0.0.127.IN-ADDR.ARPA." { type master;file "localhost.rev";}; }; to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 25 20:09:04 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA23577 for ; Wed, 25 Jul 2001 20:09:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15PWri-000IZp-00 for namedroppers-data@psg.com; Wed, 25 Jul 2001 15:10:50 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15PWrh-000IZi-00 for namedroppers@ops.ietf.org; Wed, 25 Jul 2001 15:10:50 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15PWrh-0000GA-00 for namedroppers@ops.ietf.org; Wed, 25 Jul 2001 18:10:49 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Edward Lewis To: Mark Kosters Cc: Brian Wellington , Ted.Lindgreen@tednet.nl, Edward Lewis , DNSEXT Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: <20010725144436.L1144@slam.admin.cto.netsol.com> References: ; from Brian.Wellington@nominum.com on Wed, Jul 25, 2001 at 11:05:18AM -0700 <200107251021.f6PAL0E81771@open.nlnetlabs.nl> X-Sender: lewis@pop.tislabs.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 25 Jul 2001 15:10:50 -0700 Content-Transfer-Encoding: 7bit At 2:44 PM -0400 7/25/01, Mark Kosters wrote: >Just so Brian does not feel alone, I wince in pain thinking that the gtld >or root servers (or any other high query rate authoritative server) would >have to perform verify-on-query. Everyone does (the wince in pain thing). The two arguments are over the definition of the AD bit setting and that there is a desire to have an option to do verify-on-query. As Brian has stated that he thinks his words are sufficient as is, I'll try to submit some alternate text that is in line with an understanding generated at a recent workshop. The differences of opinion are slight, but the fact that so many of us were able to derive a coherently different meaning from Brian's text concerns me. My position is that the text needs to be tightened. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com You fly too often when ... the airport taxi is on speed-dial. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 25 20:09:06 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA23587 for ; Wed, 25 Jul 2001 20:09:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15PWrx-000IaB-00 for namedroppers-data@psg.com; Wed, 25 Jul 2001 15:11:05 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15PWrx-000Ia5-00 for namedroppers@ops.ietf.org; Wed, 25 Jul 2001 15:11:05 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15PWrw-0000GC-00 for namedroppers@ops.ietf.org; Wed, 25 Jul 2001 18:11:04 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Brian Wellington Cc: , Edward Lewis , DNSEXT Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt References: <200107251021.f6PAL0E81771@open.nlnetlabs.nl> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 25 Jul 2001 15:11:05 -0700 Content-Transfer-Encoding: 7bit > Given that the people who care about DNSSEC are an incredibly small > fraction of the total users of DNS until the first major attack. and six months from then, being able to efficiently handle heavily mixed modes will be useful. and that attack will come. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 25 23:13:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA06772 for ; Wed, 25 Jul 2001 23:13:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Pb2G-0007EZ-00 for namedroppers-data@psg.com; Wed, 25 Jul 2001 19:38:00 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15Pb2F-0007ET-00 for namedroppers@ops.ietf.org; Wed, 25 Jul 2001 19:38:00 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Pb2F-0000Qw-00 for namedroppers@ops.ietf.org; Wed, 25 Jul 2001 22:37:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: gson@nominum.com (Andreas Gustafsson) To: Ted.Lindgreen@tednet.nl Cc: Roy Arends , Brian Wellington , DNSEXT Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 25 Jul 2001 19:38:00 -0700 Content-Transfer-Encoding: 7bit Ted Lindgreen writes: > OK, these guys (their sysadm's) usually have one or more nameservers, > being authorative for the local domain and acting as caching > forwarders for their local users. Usually for many years, and many > of those sysadm's have experience with various BIND versions over > the years. Many of them are not really affraid of upgrading to > the next BIND release. However.... > > With multiple views, either the views must somehow be able to > determine for which one an incoming query was meant, or the query > must be sent to the right view directly. Since the former is not > possible (queries from a stubresolver and from a caching forwarder > look the same, at least without further protocol extentions), one > must do the latter. No - one must do the former. There is no need to distinguish between local stub resolvers and local caching forwarders - you typically want to provide cryptographically validated results to both. If a local caching forwarder wants to do its own validation, it will set the CD bit. Any existing security conscious DNS installation already makes a distinction between local clients (whether stubs or forwarders) that are authorized to use their caching servers for recursive queries and external clients that are not. This distinction may be implemented using separate servers and a firewall, BIND 9 views, or a simple "allow-recursion" ACL, but it is there. To use a separate view for DNSSEC validation, you simply make the view match the clients that are currently authorized to perform recursion. -- Andreas Gustafsson, gson@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jul 26 15:04:07 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04093 for ; Thu, 26 Jul 2001 15:04:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Pon6-0007wv-00 for namedroppers-data@psg.com; Thu, 26 Jul 2001 10:19:16 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15Pon5-0007wj-00 for namedroppers@ops.ietf.org; Thu, 26 Jul 2001 10:19:15 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Pon5-00011R-00 for namedroppers@ops.ietf.org; Thu, 26 Jul 2001 13:19:15 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Brian Wellington To: Cc: DNSEXT Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Thu, 26 Jul 2001 10:19:16 -0700 Content-Transfer-Encoding: 7bit On Thu, 26 Jul 2001, Ted Lindgreen wrote: > Note: It would have been different, if BIND in the "recursive view" > would actually check the data it is authorative for query-time, > but as far as I know this is not in the code at the moment. You missed the point again. In the "recursive view", there is no authoritative data. There is only cached data. If the cached data is obtained from the "authoritative view", it's treated just like data obtained from any other source, meaning it is validated at the time it's received and the TTL is properly clamped. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jul 26 15:04:08 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04104 for ; Thu, 26 Jul 2001 15:04:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15PoXu-00073p-00 for namedroppers-data@psg.com; Thu, 26 Jul 2001 10:03:34 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15PoXt-00073Z-00 for namedroppers@ops.ietf.org; Thu, 26 Jul 2001 10:03:33 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15PoXs-00010j-00 for namedroppers@ops.ietf.org; Thu, 26 Jul 2001 13:03:32 -0400 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Brian Wellington To: Edward Lewis Cc: , DNSEXT Subject: Re: restart: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Thu, 26 Jul 2001 10:03:34 -0700 On Thu, 26 Jul 2001, Edward Lewis wrote: > Anyway, here is (a start on) how I would clean up the text: > > "In an answer in which all RR sets in the answer and authority sections are > cryptographically authenticated according to the responding servers policy, > the AD bit MUST be set to 1 if the query indicates the resolver understands > DNSSEC [ref: DNSSEC OK draft]. > > [[Note the use of MUST and not SHOULD.]] > > "Unless the responder has cryptographically authenticated all of the RR > sets in the answer and authority sections of the response, the AD bit MUST > be set to 0. Any authentication MUST include authentication of all key > sets used when chaining. The authentication MAY occur upon receipt of the > data or MAY occur upon reply. Did you intend to change "any relevant negative response RRs in the authority section" to "all RR sets in the ... authority section"? I have no strong feelings one way or the other, but it is a change. I might also change the last sentence to: The authentication MAY occur upon receipt of the data or MAY occur upon reply. If authentication is performed on receipt, the TTL MUST be trimmed as described in RFC 2535, section 4.4. These two forms of authentication are considered equivalent. Does this apply to recursive servers, authoritative servers, or both? If recursive only, I agree with the new wording. Since it looks like the next paragraph specifically deals with authoritative answers, I'll assume recursive only, and suggest that the text be modified to make this more clear. > "In an authoritative answer (AA bit is set), with RR sets obtained from a > zone file or zone transfer but not cryptographically authenticated by the > name server, the AD bit MUST be set to 0. This is definitely not a cleanup to the text; this is completely different than the draft. Would you settle for something like "guaranteed to be cryptographically verifiable"? To paraphrase my earlier argument that was ignored, I don't see any reason why if I sign (and resign) data in a timely manner and verify it by hand, that I can't run a nameserver with no crypto and have it indicate that my data has been authenticated. How about if the name server popped up a window saying "Someone has requested www.foo.com. Its SIG record is <...>. Is this valid?" This lets the server safely say that the data is verifiable, but not perform any verifications itself. It would also be insane. Basically, my point is that if I give out bad data and the my server's not doing authentication, it's my own fault. This only affects clients using my server for recursive queries, which I as administrator would probably not allow anyway, since authoritative and caching services should be split. > "If the resolver does not indicate knowledge of DNSSEC, the AD bit MUST be > set to 0." OK. > > A table to summarize AD bit settings: > Server: from disk no check verify/get verify/put fail verification > --------- -------- ---------- ---------- ----------------- > Resolver: > doesn't know DNSSEC 0 0 0 0 0 serv fail > knows DNSSEC 0 0 1 1 0 serv fail I'd really prefer: Server: disk secure-xfr insecure-xfr verified failed verify ------ ---------- ------------ -------- --------------- DO not set 0 0 0 0 servfail DO set 0/1 0/1 0 1 servfail where 0/1 indicates either value may be used, depending on whether the data is "guaranteed to be cryptographically verifiable" Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jul 26 15:04:08 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04115 for ; Thu, 26 Jul 2001 15:04:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15PmnH-000PqX-00 for namedroppers-data@psg.com; Thu, 26 Jul 2001 08:11:19 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15PmnG-000PqQ-00 for namedroppers@ops.ietf.org; Thu, 26 Jul 2001 08:11:18 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15PmnG-0000wa-00 for namedroppers@ops.ietf.org; Thu, 26 Jul 2001 11:11:18 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Edward Lewis To: Brian Wellington Cc: Edward Lewis , , DNSEXT Subject: Re: restart: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Thu, 26 Jul 2001 08:11:19 -0700 Content-Transfer-Encoding: 7bit At 1:00 PM -0400 7/25/01, Brian Wellington wrote: >I disagree. Sigh. Anyway, here is (a start on) how I would clean up the text: "In an answer in which all RR sets in the answer and authority sections are cryptographically authenticated according to the responding servers policy, the AD bit MUST be set to 1 if the query indicates the resolver understands DNSSEC [ref: DNSSEC OK draft]. [[Note the use of MUST and not SHOULD.]] "Unless the responder has cryptographically authenticated all of the RR sets in the answer and authority sections of the response, the AD bit MUST be set to 0. Any authentication MUST include authentication of all key sets used when chaining. The authentication MAY occur upon receipt of the data or MAY occur upon reply. "In an authoritative answer (AA bit is set), with RR sets obtained from a zone file or zone transfer but not cryptographically authenticated by the name server, the AD bit MUST be set to 0. "If the resolver does not indicate knowledge of DNSSEC, the AD bit MUST be set to 0." A table to summarize AD bit settings: Server: from disk no check verify/get verify/put fail verification --------- -------- ---------- ---------- ----------------- Resolver: doesn't know DNSSEC 0 0 0 0 0 serv fail knows DNSSEC 0 0 1 1 0 serv fail -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com You fly too often when ... the airport taxi is on speed-dial. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jul 26 15:04:12 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04154 for ; Thu, 26 Jul 2001 15:04:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15PjBJ-000CWP-00 for namedroppers-data@psg.com; Thu, 26 Jul 2001 04:19:53 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15PjBJ-000CWJ-00 for namedroppers@ops.ietf.org; Thu, 26 Jul 2001 04:19:53 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15PjBI-0000oX-00 for namedroppers@ops.ietf.org; Thu, 26 Jul 2001 07:19:52 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: ted@tednet.nl (Ted Lindgreen) Reply-To: Ted.Lindgreen@tednet.nl To: DNSEXT Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: "Andreas Gustafsson's message as of Jul 26, 4:58" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Thu, 26 Jul 2001 04:19:53 -0700 Content-Transfer-Encoding: 7bit [Quoting Andreas Gustafsson, on Jul 26, 4:58, in "Re: I-D ACTION:draft ..."] > To use a separate view for DNSSEC validation, you simply make the view > match the clients that are currently authorized to perform recursion. OK, thanks for explaining this to me, I was heavily wondering how views were supposed to clean up the definition of the AD-bit. I now understand what Roy meant, but this is an answer to another problem: "who is authorized to query for what?" (See Note below). So, let us go back to the topic. Like Lewis said: it is the interpretation of the description of the meaning of the AD-bit. Yes, a wording problems, and because many of us aren't native English speakers a difficult problem. A number of people interprete, or would like to interprete, the AD-bit as something that would state that: The server tells us, by setting the AD-bit, that the answer is valid and secured by cryptographic authentication at the time that the query is answered by this server. Some other people, however, interprete it as: A set AD-bit means that once in the past the data was valid and secured by cryptographic authentication. Making an implementation sidestep (which is on-topic now, I hope, because it helps understanding the protocol issue): With the second interpretation (in the BIND-9 implementation), we have the strange phenominum that the same server treats data for which it is authorative differently from recursively acquired data: - for the former it depends on local policy whether the answer is valid at query time. - for the latter, the software takes care, by active checking at acquiring-time and reducing TTL, if needed, for sig-expire, that at query time the answer is still valid. Now, in this specific implementation, one can go and try to distinguish between authorative and non-authorative servers and/or data to make the AD-bit meaningful again at query-time. However, I am affraid we need not to wait long before we'll see alternative implementations which stretches the interpretation of the AD-bit further. I think, and I guess everyone agrees, that we need to resolve this issue NOW and to settle for one unambiguous interpretation. And I think there are two choices: 1. If AD is set, the answer is valid at query time. 2. The AD bit has no meaning for the validity of the answer at query time. This is so important, because it means a day and night difference for both ISPs and people who are developing resolver software: - if the AD-bit is meaningful at query-time, we can concentrate on securing communication between simple stub-resolvers and trusted secure aware nameservers. ISPs can prepare to install and maintain secure aware caching forwarders. - if the AD-bit has no meaning at query-time, we better forget the former approach and go for "full-service" resolvers, which do the recursing and the checking internally. ISPs can skip the effort to install secure aware nameservers. Regards, -- ted Note: It would have been different, if BIND in the "recursive view" would actually check the data it is authorative for query-time, but as far as I know this is not in the code at the moment. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jul 27 08:47:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13416 for ; Fri, 27 Jul 2001 08:47:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Q6e9-000JnZ-00 for namedroppers-data@psg.com; Fri, 27 Jul 2001 05:23:13 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15Q6e8-000JnK-00 for namedroppers@ops.ietf.org; Fri, 27 Jul 2001 05:23:12 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Q6e7-00028f-00 for namedroppers@ops.ietf.org; Fri, 27 Jul 2001 08:23:11 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz Reply-To: Robert Elz To: "D. J. Bernstein" cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: (ngtrans) Re: NGtrans - DNSext joint meeting, call for participation In-Reply-To: References: <200107202005.f6KK50F11379@gungnir.fnal.gov> <20010723140044.A17822@pianosa.catch22.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Fri, 27 Jul 2001 05:23:13 -0700 Content-Transfer-Encoding: 7bit Date: Wed, 25 Jul 2001 06:28:32 -0700 From: "D. J. Bernstein" Message-ID: | Crawford wants your signatures today to last for a month. I doubt that Matt cares how long anyone's, but his own, signatures last. | What happens | if you decide tomorrow to change a machine's address list---for example, | adding or removing a second address? I wait until the previous signed record is ready to be resigned, and then I sign new ones, with different data, different TTLs, or anything else that I want. | Answer: An attacker can interfere with this change for 29 agonizing | days. All he has to do is replay the old data under the old signature. This has nothing whatever to do with attackers - the only way an attacker can interfere with this is if you're attempting to bypass the protocols. What you're really saying here is that people shouldn't use long expiration dates. What you should be doing, is explaining the pros and cons of different signing policies. I know that for most of my systems, nothing ever changes - and if something is to change, I can wait several weeks for it to happen (generally it takes that long to build up the energy to make the change anyway). Trivial stuff like ethernet cards dying, etc, can be handled by just configuring the (IPv6) address of the system to what it used to autoconfig to, until it is time to update the DNS (if ever). Adding new interfaces, addresses, etc - all takes planning. That all takes time. Now certainly when designing my signing policy I should be taking into account all of these factors. But when I do that I know that I am not going to come up with any simple number as the answer for everyone. | Are you willing to have your old data persist for a month after you make | a change? Of course not. No, but if I define things that way, I'm prepared to wait a month before making the change, so I can do it properly. If I didn't want to wait that long I'd use a smaller expiration time. | This is why typical TTLs are at most 1 day, and Yes, and because they're cheap (the cost of a 1 day, compared to 7 day expiration is negligible). | it's why typical expiration dates will be at most 1 day in the future. But that's not cheap. And it almost certainly simply won't work in general. Signing, and retaining security, is a time consuming business (the CPU time consumed is not what I am measuring here, but the human time). The data needs to be somehow carried to the key (which cannot be exposed anywhere near any network), the signing done, and then the data carried back again. Doing that once a month for most people just might be tolerable - once a day and all that will ever exist are expired signatures. After all, how many sites are going to have people (people with authority to get at the keys) available every day of the year (no holidays permitted) to resign the zone file? | Example: My cr.yp.to address is extremely stable. But I want the ability | to set up a second cr.yp.to web server with at most one day's notice. | That's why my TTL is 1 day, and it's why any signatures that I create | will expire within 1 day. You can do that with your private zone file - and hope that you're available to resign every day (or you can blow security and stick your key on the server and have it all automated). Don't expect almost anyone else to follow your example. | The question is not, as Crawford would have you believe, whether the old | data lasted for a month. The question is how much _warning_ you have | before the old data is replaced with the new data. That's what TTLs | measure, and it's what expiration dates measure. That's absolutely true, except I doubt that Matt expects anyone to believe what you claim he does. It certainly isn't what he said. | Conclusion: The computer will sign every record every day. And that's not a conclusion at all, but a speculation, and most likely, for most sites, an obviously bogus one. | Renumbering | every day, with AAAA or A6, adds _nothing_ to this signing cost. That would be true, if you were resigning everything every day, but almost no-one is going to be doing that. For A6/AAAA records, which is where this discussion started, the average system will retain the same set of interface identifiers for long periods (very long periods), and on the odd occasions when those are to change, a delay before making the change is entirely acceptable. It doesn't have to happen right now. Nothing is going to require that. Hence a long expiration time is just fine (how long will depend upon individual site requirements, for me, I think 3 months would be about right). On the other hand, someone else can command me to change the upper parts of the address (my ISP just changed its ISP for whatever reason, all their addresses are now from a different block, they're keeping the old ones for a week...) In that situation I have to be able to change the upper bits quickly, those can be out of my control. So that part I need to be able to update quickly, that one I will have to resign fairly frequently (I'd probably make it once or twice a week though, not once a day). | As for ``replace'': It's true that a better-designed protocol would | simply use absolute dates, That would be nice, if we could mandate that any two systems use the same idea of the time. Until that happens (like never) relative times are what works (well enough). kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jul 27 08:47:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13419 for ; Fri, 27 Jul 2001 08:47:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Q6dY-000JiL-00 for namedroppers-data@psg.com; Fri, 27 Jul 2001 05:22:36 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15Q6dX-000JiF-00 for namedroppers@ops.ietf.org; Fri, 27 Jul 2001 05:22:35 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Q6dW-00028Z-00 for namedroppers@ops.ietf.org; Fri, 27 Jul 2001 08:22:34 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: "D. J. Bernstein" cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: NGtrans - DNSext joint meeting, call for participation In-Reply-To: References: <200107202005.f6KK50F11379@gungnir.fnal.gov> <20010723140044.A17822@pianosa.catch22.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Fri, 27 Jul 2001 05:22:36 -0700 Content-Transfer-Encoding: 7bit Date: Wed, 25 Jul 2001 06:28:32 -0700 From: "D. J. Bernstein" Message-ID: | Crawford wants your signatures today to last for a month. I doubt that Matt cares how long anyone's, but his own, signatures last. | What happens | if you decide tomorrow to change a machine's address list---for example, | adding or removing a second address? I wait until the previous signed record is ready to be resigned, and then I sign new ones, with different data, different TTLs, or anything else that I want. | Answer: An attacker can interfere with this change for 29 agonizing | days. All he has to do is replay the old data under the old signature. This has nothing whatever to do with attackers - the only way an attacker can interfere with this is if you're attempting to bypass the protocols. What you're really saying here is that people shouldn't use long expiration dates. What you should be doing, is explaining the pros and cons of different signing policies. I know that for most of my systems, nothing ever changes - and if something is to change, I can wait several weeks for it to happen (generally it takes that long to build up the energy to make the change anyway). Trivial stuff like ethernet cards dying, etc, can be handled by just configuring the (IPv6) address of the system to what it used to autoconfig to, until it is time to update the DNS (if ever). Adding new interfaces, addresses, etc - all takes planning. That all takes time. Now certainly when designing my signing policy I should be taking into account all of these factors. But when I do that I know that I am not going to come up with any simple number as the answer for everyone. | Are you willing to have your old data persist for a month after you make | a change? Of course not. No, but if I define things that way, I'm prepared to wait a month before making the change, so I can do it properly. If I didn't want to wait that long I'd use a smaller expiration time. | This is why typical TTLs are at most 1 day, and Yes, and because they're cheap (the cost of a 1 day, compared to 7 day expiration is negligible). | it's why typical expiration dates will be at most 1 day in the future. But that's not cheap. And it almost certainly simply won't work in general. Signing, and retaining security, is a time consuming business (the CPU time consumed is not what I am measuring here, but the human time). The data needs to be somehow carried to the key (which cannot be exposed anywhere near any network), the signing done, and then the data carried back again. Doing that once a month for most people just might be tolerable - once a day and all that will ever exist are expired signatures. After all, how many sites are going to have people (people with authority to get at the keys) available every day of the year (no holidays permitted) to resign the zone file? | Example: My cr.yp.to address is extremely stable. But I want the ability | to set up a second cr.yp.to web server with at most one day's notice. | That's why my TTL is 1 day, and it's why any signatures that I create | will expire within 1 day. You can do that with your private zone file - and hope that you're available to resign every day (or you can blow security and stick your key on the server and have it all automated). Don't expect almost anyone else to follow your example. | The question is not, as Crawford would have you believe, whether the old | data lasted for a month. The question is how much _warning_ you have | before the old data is replaced with the new data. That's what TTLs | measure, and it's what expiration dates measure. That's absolutely true, except I doubt that Matt expects anyone to believe what you claim he does. It certainly isn't what he said. | Conclusion: The computer will sign every record every day. And that's not a conclusion at all, but a speculation, and most likely, for most sites, an obviously bogus one. | Renumbering | every day, with AAAA or A6, adds _nothing_ to this signing cost. That would be true, if you were resigning everything every day, but almost no-one is going to be doing that. For A6/AAAA records, which is where this discussion started, the average system will retain the same set of interface identifiers for long periods (very long periods), and on the odd occasions when those are to change, a delay before making the change is entirely acceptable. It doesn't have to happen right now. Nothing is going to require that. Hence a long expiration time is just fine (how long will depend upon individual site requirements, for me, I think 3 months would be about right). On the other hand, someone else can command me to change the upper parts of the address (my ISP just changed its ISP for whatever reason, all their addresses are now from a different block, they're keeping the old ones for a week...) In that situation I have to be able to change the upper bits quickly, those can be out of my control. So that part I need to be able to update quickly, that one I will have to resign fairly frequently (I'd probably make it once or twice a week though, not once a day). | As for ``replace'': It's true that a better-designed protocol would | simply use absolute dates, That would be nice, if we could mandate that any two systems use the same idea of the time. Until that happens (like never) relative times are what works (well enough). kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jul 27 09:19:44 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15991 for ; Fri, 27 Jul 2001 09:19:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Q6eG-000JoR-00 for namedroppers-data@psg.com; Fri, 27 Jul 2001 05:23:20 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15Q6eF-000JoL-00 for namedroppers@ops.ietf.org; Fri, 27 Jul 2001 05:23:19 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Q6eE-00028k-00 for namedroppers@ops.ietf.org; Fri, 27 Jul 2001 08:23:18 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz Reply-To: Robert Elz To: "D. J. Bernstein" cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: (ngtrans) Re: NGtrans - DNSext joint meeting, call for participation In-Reply-To: References: <200107202005.f6KK50F11379@gungnir.fnal.gov> <20010723140044.A17822@pianosa.catch22.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Fri, 27 Jul 2001 05:23:20 -0700 Content-Transfer-Encoding: 7bit Date: Wed, 25 Jul 2001 06:28:32 -0700 From: "D. J. Bernstein" Message-ID: | Crawford wants your signatures today to last for a month. I doubt that Matt cares how long anyone's, but his own, signatures last. | What happens | if you decide tomorrow to change a machine's address list---for example, | adding or removing a second address? I wait until the previous signed record is ready to be resigned, and then I sign new ones, with different data, different TTLs, or anything else that I want. | Answer: An attacker can interfere with this change for 29 agonizing | days. All he has to do is replay the old data under the old signature. This has nothing whatever to do with attackers - the only way an attacker can interfere with this is if you're attempting to bypass the protocols. What you're really saying here is that people shouldn't use long expiration dates. What you should be doing, is explaining the pros and cons of different signing policies. I know that for most of my systems, nothing ever changes - and if something is to change, I can wait several weeks for it to happen (generally it takes that long to build up the energy to make the change anyway). Trivial stuff like ethernet cards dying, etc, can be handled by just configuring the (IPv6) address of the system to what it used to autoconfig to, until it is time to update the DNS (if ever). Adding new interfaces, addresses, etc - all takes planning. That all takes time. Now certainly when designing my signing policy I should be taking into account all of these factors. But when I do that I know that I am not going to come up with any simple number as the answer for everyone. | Are you willing to have your old data persist for a month after you make | a change? Of course not. No, but if I define things that way, I'm prepared to wait a month before making the change, so I can do it properly. If I didn't want to wait that long I'd use a smaller expiration time. | This is why typical TTLs are at most 1 day, and Yes, and because they're cheap (the cost of a 1 day, compared to 7 day expiration is negligible). | it's why typical expiration dates will be at most 1 day in the future. But that's not cheap. And it almost certainly simply won't work in general. Signing, and retaining security, is a time consuming business (the CPU time consumed is not what I am measuring here, but the human time). The data needs to be somehow carried to the key (which cannot be exposed anywhere near any network), the signing done, and then the data carried back again. Doing that once a month for most people just might be tolerable - once a day and all that will ever exist are expired signatures. After all, how many sites are going to have people (people with authority to get at the keys) available every day of the year (no holidays permitted) to resign the zone file? | Example: My cr.yp.to address is extremely stable. But I want the ability | to set up a second cr.yp.to web server with at most one day's notice. | That's why my TTL is 1 day, and it's why any signatures that I create | will expire within 1 day. You can do that with your private zone file - and hope that you're available to resign every day (or you can blow security and stick your key on the server and have it all automated). Don't expect almost anyone else to follow your example. | The question is not, as Crawford would have you believe, whether the old | data lasted for a month. The question is how much _warning_ you have | before the old data is replaced with the new data. That's what TTLs | measure, and it's what expiration dates measure. That's absolutely true, except I doubt that Matt expects anyone to believe what you claim he does. It certainly isn't what he said. | Conclusion: The computer will sign every record every day. And that's not a conclusion at all, but a speculation, and most likely, for most sites, an obviously bogus one. | Renumbering | every day, with AAAA or A6, adds _nothing_ to this signing cost. That would be true, if you were resigning everything every day, but almost no-one is going to be doing that. For A6/AAAA records, which is where this discussion started, the average system will retain the same set of interface identifiers for long periods (very long periods), and on the odd occasions when those are to change, a delay before making the change is entirely acceptable. It doesn't have to happen right now. Nothing is going to require that. Hence a long expiration time is just fine (how long will depend upon individual site requirements, for me, I think 3 months would be about right). On the other hand, someone else can command me to change the upper parts of the address (my ISP just changed its ISP for whatever reason, all their addresses are now from a different block, they're keeping the old ones for a week...) In that situation I have to be able to change the upper bits quickly, those can be out of my control. So that part I need to be able to update quickly, that one I will have to resign fairly frequently (I'd probably make it once or twice a week though, not once a day). | As for ``replace'': It's true that a better-designed protocol would | simply use absolute dates, That would be nice, if we could mandate that any two systems use the same idea of the time. Until that happens (like never) relative times are what works (well enough). kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jul 27 09:19:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15996 for ; Fri, 27 Jul 2001 09:19:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Q6e1-000JlK-00 for namedroppers-data@psg.com; Fri, 27 Jul 2001 05:23:05 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15Q6dy-000JlE-00 for namedroppers@ops.ietf.org; Fri, 27 Jul 2001 05:23:02 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Q6dx-00028d-00 for namedroppers@ops.ietf.org; Fri, 27 Jul 2001 08:23:01 -0400 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dhcid-rr-03.txt Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Fri, 27 Jul 2001 05:23:05 -0700 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : A DNS RR for encoding DHCP information (DHCID RR) Author(s) : M. Stapp, T. Lemon, A. Gustafsson Filename : draft-ietf-dnsext-dhcid-rr-03.txt Pages : 9 Date : 26-Jul-01 It is possible for multiple DHCP clients to attempt to update the same DNS FQDN as they obtain DHCP leases. Whether the DHCP server or the clients themselves perform the DNS updates, conflicts can arise. To resolve such conflicts, 'Resolution of DNS Name Conflicts'[1] proposes storing client identifiers in the DNS to unambiguously associate domain names with the DHCP clients to which they refer. This memo defines a distinct RR type for this purpose for use by DHCP clients and servers, the 'DHCID' RR. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dhcid-rr-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dhcid-rr-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dhcid-rr-03.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: <20010726170529.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dhcid-rr-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dhcid-rr-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010726170529.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jul 27 09:41:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13417 for ; Fri, 27 Jul 2001 08:47:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Q6dp-000JlA-00 for namedroppers-data@psg.com; Fri, 27 Jul 2001 05:22:53 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15Q6do-000Jl4-00 for namedroppers@ops.ietf.org; Fri, 27 Jul 2001 05:22:52 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Q6dn-00028b-00 for namedroppers@ops.ietf.org; Fri, 27 Jul 2001 08:22:51 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz Reply-To: Robert Elz To: "D. J. Bernstein" cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: (ngtrans) Re: NGtrans - DNSext joint meeting, call for participation In-Reply-To: References: <200107202005.f6KK50F11379@gungnir.fnal.gov> <20010723140044.A17822@pianosa.catch22.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Fri, 27 Jul 2001 05:22:53 -0700 Content-Transfer-Encoding: 7bit Date: Wed, 25 Jul 2001 06:28:32 -0700 From: "D. J. Bernstein" Message-ID: | Crawford wants your signatures today to last for a month. I doubt that Matt cares how long anyone's, but his own, signatures last. | What happens | if you decide tomorrow to change a machine's address list---for example, | adding or removing a second address? I wait until the previous signed record is ready to be resigned, and then I sign new ones, with different data, different TTLs, or anything else that I want. | Answer: An attacker can interfere with this change for 29 agonizing | days. All he has to do is replay the old data under the old signature. This has nothing whatever to do with attackers - the only way an attacker can interfere with this is if you're attempting to bypass the protocols. What you're really saying here is that people shouldn't use long expiration dates. What you should be doing, is explaining the pros and cons of different signing policies. I know that for most of my systems, nothing ever changes - and if something is to change, I can wait several weeks for it to happen (generally it takes that long to build up the energy to make the change anyway). Trivial stuff like ethernet cards dying, etc, can be handled by just configuring the (IPv6) address of the system to what it used to autoconfig to, until it is time to update the DNS (if ever). Adding new interfaces, addresses, etc - all takes planning. That all takes time. Now certainly when designing my signing policy I should be taking into account all of these factors. But when I do that I know that I am not going to come up with any simple number as the answer for everyone. | Are you willing to have your old data persist for a month after you make | a change? Of course not. No, but if I define things that way, I'm prepared to wait a month before making the change, so I can do it properly. If I didn't want to wait that long I'd use a smaller expiration time. | This is why typical TTLs are at most 1 day, and Yes, and because they're cheap (the cost of a 1 day, compared to 7 day expiration is negligible). | it's why typical expiration dates will be at most 1 day in the future. But that's not cheap. And it almost certainly simply won't work in general. Signing, and retaining security, is a time consuming business (the CPU time consumed is not what I am measuring here, but the human time). The data needs to be somehow carried to the key (which cannot be exposed anywhere near any network), the signing done, and then the data carried back again. Doing that once a month for most people just might be tolerable - once a day and all that will ever exist are expired signatures. After all, how many sites are going to have people (people with authority to get at the keys) available every day of the year (no holidays permitted) to resign the zone file? | Example: My cr.yp.to address is extremely stable. But I want the ability | to set up a second cr.yp.to web server with at most one day's notice. | That's why my TTL is 1 day, and it's why any signatures that I create | will expire within 1 day. You can do that with your private zone file - and hope that you're available to resign every day (or you can blow security and stick your key on the server and have it all automated). Don't expect almost anyone else to follow your example. | The question is not, as Crawford would have you believe, whether the old | data lasted for a month. The question is how much _warning_ you have | before the old data is replaced with the new data. That's what TTLs | measure, and it's what expiration dates measure. That's absolutely true, except I doubt that Matt expects anyone to believe what you claim he does. It certainly isn't what he said. | Conclusion: The computer will sign every record every day. And that's not a conclusion at all, but a speculation, and most likely, for most sites, an obviously bogus one. | Renumbering | every day, with AAAA or A6, adds _nothing_ to this signing cost. That would be true, if you were resigning everything every day, but almost no-one is going to be doing that. For A6/AAAA records, which is where this discussion started, the average system will retain the same set of interface identifiers for long periods (very long periods), and on the odd occasions when those are to change, a delay before making the change is entirely acceptable. It doesn't have to happen right now. Nothing is going to require that. Hence a long expiration time is just fine (how long will depend upon individual site requirements, for me, I think 3 months would be about right). On the other hand, someone else can command me to change the upper parts of the address (my ISP just changed its ISP for whatever reason, all their addresses are now from a different block, they're keeping the old ones for a week...) In that situation I have to be able to change the upper bits quickly, those can be out of my control. So that part I need to be able to update quickly, that one I will have to resign fairly frequently (I'd probably make it once or twice a week though, not once a day). | As for ``replace'': It's true that a better-designed protocol would | simply use absolute dates, That would be nice, if we could mandate that any two systems use the same idea of the time. Until that happens (like never) relative times are what works (well enough). kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jul 29 01:52:13 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA13802 for ; Sun, 29 Jul 2001 01:52:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15QiXW-0008PX-00 for namedroppers-data@psg.com; Sat, 28 Jul 2001 21:50:54 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15QiXV-0008PR-00 for namedroppers@ops.ietf.org; Sat, 28 Jul 2001 21:50:53 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15QiXV-000Im3-00 for namedroppers@ops.ietf.org; Sat, 28 Jul 2001 21:50:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Jakob Schlyter To: Edward Lewis Cc: Brian Wellington , , DNSEXT Subject: Re: restart: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sat, 28 Jul 2001 21:50:54 -0700 Content-Transfer-Encoding: 7bit On Sat, 28 Jul 2001, Edward Lewis wrote: > IMHO an AA bit outranks an AD bit. Data with AA=1,AD=0 is reputedly > coming from *the* source (TSIG, et.al.) Data with AA=0,AD=1 is > reputedly data that some intermediary has verified as coming from the > source. I would assign higher credibility to AA=1,AD=0 than > AA=0,AD=1. an application could put trust in a dns reply by several reasons: reply source (i.e. who did I query) reply transport (i.e. tsig, tkey or nothing) status of some bits in the header (AA, AD, ...) I have to configure who and how I send my query, so this is a very basic administrative problem (except for the policy part, but let's leave that out for the moment). the AD-bit however is harder and needs to be well defined as applications will interpret it without knowing the verification policy. the reason I like the nameserver to use the AD-bit, and only the AD-bit, to signal that the data is authenticated cryptographically is simplicity. I do not care about whether my nameserver is authorative or not - I only care if it has validated the data or not. it could be authorative, yet the zonefile could be invalid (e.g. the nameserver is secondary and doesn't fully trust source). let us, for the people using this - not the implementators, keep this simple. finding something to trust and communicate securely with that entity is hard enough. 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. From owner-namedroppers@ops.ietf.org Sun Jul 29 01:52:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA13847 for ; Sun, 29 Jul 2001 01:52:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15QaCz-000JXZ-00 for namedroppers-data@psg.com; Sat, 28 Jul 2001 12:57:09 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15QaCy-000JXS-00 for namedroppers@ops.ietf.org; Sat, 28 Jul 2001 12:57:08 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15QaCy-0004VX-00 for namedroppers@ops.ietf.org; Sat, 28 Jul 2001 12:57:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Greg Hudson To: John Gilmore cc: DNSEXT Subject: Re: AS IF: draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: Your message of "Sat, 28 Jul 2001 12:35:22 PDT." Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sat, 28 Jul 2001 12:57:09 -0700 Content-Transfer-Encoding: 7bit (Risks dropped from the cc line.) > Any client implementation that listens to a single bit of the > response to tell it whether the response is cryptographically valid > must be considered noncompliant with the DNSSEC spec. It's just an > old fashioned insecure DNS client. There's nothing wrong with that, > as long as you don't have any high trust expecations for it. I think you're overreacting. What we're looking for is a way to deal with situations like this: in Unix, the libc resolver is generally pretty lightweight. It will only do one query; if you ask for something which turns out to be a CNAME, it expects the recursive name server to supply the pointed-to record. If you want your machine to do full recursive resolution, you run a local named (or dnscache, or whatever) and point your stub resolver at that. Pursuant to that architecture, the stub resolver probably doesn't want to be validating DNS signatures, especially if it would have to go out and fetch SIG records up to the root. We have several lightweight mechanisms for securing the path from the stub resolver to the recursive resolver: putting it on the machine, TSIG, and (blech) firewalls plus the presumption of no internal attackers. I have yet to understand why anyone wants to set the AD bit on unchecked data. Sure, an authoritative server shouldn't have to do cryptography, but it also shouldn't ever need to set the AD bit unless it's also acting as a recursive resolver for clients. In which case it had better be prepared to do cryptography if it wants to set AD bits. > PS: I know, I know, the "valid" bit will be secured by some "out of > band" means. Like a shared static key, and/or by the security of > the file system on the server. Right. For extra credit: composing > several weak security primitives produces what? Strong security or > weak security? In the scenario I described with the cache on the same machine as the stub resolver, where is the weak security primitive? to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jul 29 01:52:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA13861 for ; Sun, 29 Jul 2001 01:52:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15QZru-000Iv6-00 for namedroppers-data@psg.com; Sat, 28 Jul 2001 12:35:22 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15QZru-000Iv0-00 for namedroppers@ops.ietf.org; Sat, 28 Jul 2001 12:35:22 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15QZru-0003vc-00 for namedroppers@ops.ietf.org; Sat, 28 Jul 2001 12:35:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: John Gilmore To: DNSEXT , gnu@toad.com Cc: risks@csl.sri.com Subject: AS IF: draft-ietf-dnsext-ad-is-secure-03.txt In-reply-to: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sat, 28 Jul 2001 12:35:22 -0700 Content-Transfer-Encoding: 7bit I think some of you guys have gotten so tied up in micromanaging DNS Security implementation details that you forgot what swamp we were trying to drain. There is no point in building a cryptographically-secured DNS in which many of the machines will be configured to "just believe whatever they are told, regardless of the cryptographic signatures"! We already have such a DNS -- today's. It doesn't need signatures or AD bits or big packets or any other changes. Anyone who is happy with that can go home and stop arguing. The rest of us are interested in the real security and integrity of the Internet. Any client implementation that listens to a single bit of the response to tell it whether the response is cryptographically valid must be considered noncompliant with the DNSSEC spec. It's just an old fashioned insecure DNS client. There's nothing wrong with that, as long as you don't have any high trust expecations for it. Any server which deposits a single bit in the response to claim to clients that it has cryptographically validated the results, so they don't have to, is just encouraging the above abuse. I'm not shocked to find people advocating that such a server actually lie to the clients about whether it has validated the data. The entire model (trusting a packet to tell you whether somebody else has validated the data) provides ample opportunities for not only your friends but your enemies to lie to you. Just like in the current DNS. John PS: I know, I know, the "valid" bit will be secured by some "out of band" means. Like a shared static key, and/or by the security of the file system on the server. Right. For extra credit: composing several weak security primitives produces what? Strong security or weak security? PPS: The real question is why anyone is advocating that the DNS be "secured" by lame security. There are challenges aplenty even when you're working with strong primitives; trying to mix in weak stuff is just wasting everyone's time. People have encouraged me in the past to assume the possibility of mere incompetence rather than assuming actual malice (e.g. when the FBI's Louis Freeh testified to Congress about the security of DES). So: Were any of you on the standards committees for cellphone privacy? How about on the 802.11 "Wiretap Equivalent Privacy" committee? Did any of you have a hand in shortening the key in DES? Perhaps you designed the encryption scheme used in DVDs or in Adobe eBooks? Whether you're incompetent or malicious, stick to breaking codes, it's much easier. Especially when you break them in the standards committee before they're deployed. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jul 29 01:52:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA13872 for ; Sun, 29 Jul 2001 01:52:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15QX4U-000E6d-00 for namedroppers-data@psg.com; Sat, 28 Jul 2001 09:36:10 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15QX4U-000E6X-00 for namedroppers@ops.ietf.org; Sat, 28 Jul 2001 09:36:10 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15QX4U-000PBg-00 for namedroppers@ops.ietf.org; Sat, 28 Jul 2001 09:36:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Mark.Andrews@nominum.com To: Mark.Andrews@nominum.com Cc: "D. J. Bernstein" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: NGtrans - DNSext joint meeting, call for participation In-reply-to: Your message of "Sat, 28 Jul 2001 17:38:08 +1000." <200107280738.f6S7c8u63269@drugs.dv.isc.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sat, 28 Jul 2001 09:36:10 -0700 Content-Transfer-Encoding: 7bit Third time lucky ... > Dan, > your claim is that you have to re-sign every record in > a zone daily to achieve a 1 day replay window. I'm stating > that you can achieve the same protection without re-signing > every record daily. > > Pre change: > example.com KEY alpha > example.com SIG KEY expire=200107292257 (1 day) > host.example.com A 1.2.3.4 > host.example.com SIG A expire=200108272257 (30 days) > > Post change: > example.com KEY beta > example.com SIG KEY expire=200107072258 (1 day) This should have been example.com SIG KEY expire=200107292258 (1 day) > host.example.com A 1.2.3.5 > host.example.com SIG A expire=200108272258 (30 days) > > Please explain how you can verify > host.example.com A 1.2.3.4 > host.example.com SIG A expire=200108272257 > after 200107292257. > > Mark -- Mark Andrews, Nominum Inc. 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jul 29 01:52:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA13885 for ; Sun, 29 Jul 2001 01:52:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15QX4Q-000E6R-00 for namedroppers-data@psg.com; Sat, 28 Jul 2001 09:36:06 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15QX4Q-000E6K-00 for namedroppers@ops.ietf.org; Sat, 28 Jul 2001 09:36:06 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15QX4Q-000PBP-00 for namedroppers@ops.ietf.org; Sat, 28 Jul 2001 09:36:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Mark.Andrews@nominum.com To: Mark.Andrews@nominum.com Cc: "D. J. Bernstein" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: NGtrans - DNSext joint meeting, call for participation In-reply-to: Your message of "Sat, 28 Jul 2001 17:31:20 +1000." Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sat, 28 Jul 2001 09:36:06 -0700 Content-Transfer-Encoding: 7bit > > > Mark.Andrews@nominum.com writes: > > > there is no requirement to re-sign every record to achieve > > > your 1 day expiry. Just change the zone key whenever you change > > > zone data and have a 1 day expiry on the zone key's signature. > > > > No. If you maintain the validity of signatures on old records, you're > > allowing the attack to succeed. If you don't maintain the validity of > > those signatures, you have to immediately sign those records again. > > > > Please withdraw your claim. > > Dan, > your claim is that you have to re-sign every record in > a zone daily to achieve a 1 day replay window. I'm stating > that you can achieve the same protection without re-signing > every record daily. > > Pre change: > example.com KEY alpha > example.com SIG KEY expire=200107292257 (1 day) > host.example.com A 1.2.3.4 > host.example.com SIG A expire=200108272257 (30 days) > > Post change: > example.com KEY beta > example.com SIG KEY expire=200107072258 (1 day) This should have been example.com SIG KEY expire=200107272258 (1 day) > host.example.com A 1.2.3.5 > host.example.com SIG A expire=200108272258 (30 days) > > Please explain how you can verify > host.example.com A 1.2.3.4 > host.example.com SIG A expire=200108272257 > after 200107292257. > > Mark > -- > Mark Andrews, Nominum Inc. > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@nominum.com -- Mark Andrews, Nominum Inc. 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jul 29 01:52:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA13898 for ; Sun, 29 Jul 2001 01:52:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15QX4C-000E4o-00 for namedroppers-data@psg.com; Sat, 28 Jul 2001 09:35:52 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15QX4B-000E4i-00 for namedroppers@ops.ietf.org; Sat, 28 Jul 2001 09:35:51 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15QX4B-000PB0-00 for namedroppers@ops.ietf.org; Sat, 28 Jul 2001 09:35:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Mark.Andrews@nominum.com To: "D. J. Bernstein" Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: NGtrans - DNSext joint meeting, call for participation In-reply-to: Your message of "28 Jul 2001 06:08:23 GMT." <20010728060823.20080.qmail@cr.yp.to> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sat, 28 Jul 2001 09:35:52 -0700 Content-Transfer-Encoding: 7bit > Mark.Andrews@nominum.com writes: > > there is no requirement to re-sign every record to achieve > > your 1 day expiry. Just change the zone key whenever you change > > zone data and have a 1 day expiry on the zone key's signature. > > No. If you maintain the validity of signatures on old records, you're > allowing the attack to succeed. If you don't maintain the validity of > those signatures, you have to immediately sign those records again. > > Please withdraw your claim. Dan, your claim is that you have to re-sign every record in a zone daily to achieve a 1 day replay window. I'm stating that you can achieve the same protection without re-signing every record daily. Pre change: example.com KEY alpha example.com SIG KEY expire=200107292257 (1 day) host.example.com A 1.2.3.4 host.example.com SIG A expire=200108272257 (30 days) Post change: example.com KEY beta example.com SIG KEY expire=200107072258 (1 day) host.example.com A 1.2.3.5 host.example.com SIG A expire=200108272258 (30 days) Please explain how you can verify host.example.com A 1.2.3.4 host.example.com SIG A expire=200108272257 after 200107292257. Mark -- Mark Andrews, Nominum Inc. 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jul 29 01:52:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA13917 for ; Sun, 29 Jul 2001 01:52:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15QX17-000DyM-00 for namedroppers-data@psg.com; Sat, 28 Jul 2001 09:32:41 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15QX17-000DyG-00 for namedroppers@ops.ietf.org; Sat, 28 Jul 2001 09:32:41 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15QX17-000P5U-00 for namedroppers@ops.ietf.org; Sat, 28 Jul 2001 09:32:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "D. J. Bernstein" To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: NGtrans - DNSext joint meeting, call for participation References: <2261.996231603@brandenburg.cs.mu.OZ.AU> <200107280036.f6S0acu60948@drugs.dv.isc.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sat, 28 Jul 2001 09:32:41 -0700 Content-Transfer-Encoding: 7bit Mark.Andrews@nominum.com writes: > there is no requirement to re-sign every record to achieve > your 1 day expiry. Just change the zone key whenever you change > zone data and have a 1 day expiry on the zone key's signature. No. If you maintain the validity of signatures on old records, you're allowing the attack to succeed. If you don't maintain the validity of those signatures, you have to immediately sign those records again. Please withdraw your claim. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jul 29 01:52:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA13927 for ; Sun, 29 Jul 2001 01:52:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15QWwU-000Dp7-00 for namedroppers-data@psg.com; Sat, 28 Jul 2001 09:27:54 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15QWwU-000Dp1-00 for namedroppers@ops.ietf.org; Sat, 28 Jul 2001 09:27:54 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15QWwU-000Oww-00 for namedroppers@ops.ietf.org; Sat, 28 Jul 2001 09:27:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Mark.Andrews@nominum.com To: Robert Elz Cc: "D. J. Bernstein" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: NGtrans - DNSext joint meeting, call for participation In-reply-to: Your message of "Fri, 27 Jul 2001 18:00:03 +0700." <2261.996231603@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sat, 28 Jul 2001 09:27:54 -0700 Content-Transfer-Encoding: 7bit Dan, there is no requirement to re-sign every record to achieve your 1 day expiry. Just change the zone key whenever you change zone data and have a 1 day expiry on the zone key's signature. So daily you re-sign two RRsets. Mark -- Mark Andrews, Nominum Inc. 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jul 29 01:52:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA13938 for ; Sun, 29 Jul 2001 01:52:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15QWnK-000DWO-00 for namedroppers-data@psg.com; Sat, 28 Jul 2001 09:18:26 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15QWnJ-000DWI-00 for namedroppers@ops.ietf.org; Sat, 28 Jul 2001 09:18:25 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15QWnJ-000OgE-00 for namedroppers@ops.ietf.org; Sat, 28 Jul 2001 09:18:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Alain Durand To: ngtrans List , dnsop@cafax.se, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com Cc: olafur Gudmundsson , randy Bush , tony@tndh.net, fink@es.net, erik Nordmark , Thomas Narten , bwijnen@lucent.com Subject: Reading materials for the joint NGtrans-DNSext meeting in London Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sat, 28 Jul 2001 09:18:26 -0700 Content-Transfer-Encoding: 7bit The goal of the joint meeting is to facilitate consensus on how IPv6 addresses are represented in DNS and related issues. This meeting requires extensive homework by participants. Here is the list of material that have been submitted to the wg chairs and will be used during the discussion in London. Knowledge of those documents will be assumed in London, so we strongly encourage reading them all prior to the meeting! 1 Rob Austein: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt 2 Christian Huitema: http://www.ietf.org/internet-drafts/draft-huitema-ipv6-renumber-00.txt 3 Matt Crawford: http://home.fnal.gov/~crawdad/draft-ietf-dnsext-ipv6-dns-response-00.txt 4 Jun-ichiro itojun Hagino : http://www.ietf.org/internet-drafts/draft-ietf-dnsext-aaaa-a6-01.txt 5 Dan Bernstein: http://cr.yp.to/djbdns/killa6.html For those who need it, a short introduction to DNSSEC can be found at: http://www.pgp.com/research/nailabs/network-security/an-introduction.asp Good reading! - the chairs. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jul 29 01:52:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA13979 for ; Sun, 29 Jul 2001 01:52:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15QWPH-000CkC-00 for namedroppers-data@psg.com; Sat, 28 Jul 2001 08:53:35 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15QWPH-000Ck6-00 for namedroppers@ops.ietf.org; Sat, 28 Jul 2001 08:53:35 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15QWPH-000Nwk-00 for namedroppers@ops.ietf.org; Sat, 28 Jul 2001 08:53:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Edward Lewis To: Brian Wellington Cc: Edward Lewis , , DNSEXT Subject: Re: restart: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sat, 28 Jul 2001 08:53:35 -0700 Content-Transfer-Encoding: 7bit At 2:07 PM -0400 7/27/01, Brian Wellington wrote: Finally - I can see the motivation. "Intents," or requirements, should appear in the introduction to set the context for the document. >And all I want is the ability to run an authoritative server without >crypto that can set the AD bit to 1 on data that is secure. I don't think this should be permitted. Why is it so important to have the AD bit set to 1 if the answering server does not bother with cryptography? The AA bit and AD bit exist on different planes of the DNS protocol. (This is a bit abstract.) AA rests on the name server plane, and is topology-based. The AA bit indicates that there is no better place to get an answer than this. AD rests on the zone data plan, it relates to the end-to-end security of data from its zone to the resolver. The AD bit indicates that the responder has checked the data it has received and is now forwarding on. IMHO an AA bit outranks an AD bit. Data with AA=1,AD=0 is reputedly coming from *the* source (TSIG, et.al.) Data with AA=0,AD=1 is reputedly data that some intermediary has verified as coming from the source. I would assign higher credibility to AA=1,AD=0 than AA=0,AD=1. If both AA=1 ,and AD=1, then the data is coming from a rather conservative source. (Which some applications may demand.) If the setting of AD=1 is allowed without doing crypto, some information is lost (specifically, how conservative is the source). (Perhaps we could Jakob to comment on this.) >The intention was basically to stop: > - recursive servers from setting the AD bit on provably insecure data. > - authoritative servers from setting the AD bit on unsecured zones. I think that this effort isn't strong enough then. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com You fly too often when ... the airport taxi is on speed-dial. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jul 29 01:52:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA13992 for ; Sun, 29 Jul 2001 01:52:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15QWCM-000CFY-00 for namedroppers-data@psg.com; Sat, 28 Jul 2001 08:40:14 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15QWCM-000CFS-00 for namedroppers@ops.ietf.org; Sat, 28 Jul 2001 08:40:14 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15QWCL-000NZW-00 for namedroppers@ops.ietf.org; Sat, 28 Jul 2001 08:40:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Brian Wellington To: Edward Lewis cc: , DNSEXT Subject: Re: restart: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sat, 28 Jul 2001 08:40:14 -0700 Content-Transfer-Encoding: 7bit On Fri, 27 Jul 2001, Edward Lewis wrote: > At 12:10 PM -0400 7/27/01, Brian Wellington wrote: > >On Fri, 27 Jul 2001, Edward Lewis wrote: > > > >> At 1:03 PM -0400 7/26/01, Brian Wellington wrote: > >> >On Thu, 26 Jul 2001, Edward Lewis wrote: > >> > > >> >> Anyway, here is (a start on) how I would clean up the text: > >> >> > >> >> "In an answer in which all RR sets in the answer and authority > >>sections are > >> >> cryptographically authenticated according to the responding servers > >>policy, > >> >> the AD bit MUST be set to 1 if the query indicates the resolver > >>understands > >> >> DNSSEC [ref: DNSSEC OK draft]. > >> >> > >> >> [[Note the use of MUST and not SHOULD.]] > >> >> > >> >> "Unless the responder has cryptographically authenticated all of the RR > >> >> sets in the answer and authority sections of the response, the AD bit > >>MUST > >> >> be set to 0. Any authentication MUST include authentication of all key > >> >> sets used when chaining. The authentication MAY occur upon receipt > >>of the > >> >> data or MAY occur upon reply. > >> > > >> >Did you intend to change "any relevant negative response RRs in the > >> >authority section" to "all RR sets in the ... authority section"? I have > >> >no strong feelings one way or the other, but it is a change. > >> > > >> >I might also change the last sentence to: > >> > > >> > The authentication MAY occur upon receipt of the data or MAY occur > >> > upon reply. If authentication is performed on receipt, the TTL > >> > MUST be trimmed as described in RFC 2535, section 4.4. These two > >> > forms of authentication are considered equivalent. > >> > >> I would omit the last sentence. It is true in some contexts that the forms > >> described are equivalent, but not in other contexts. Within the context of > >> the time-ignorant, non-revokable DNS (which he have today), the two are > >> equivalent. In an application which is time-sensitive, the two are not. > >> Whether one feels that a time-sensitive application should be making use of > >> DNS for uptodate data is a point to argued elsewhere. > > > >I would hope that the DNS protocol is replaced with something different > >before the ability to revoke records is added. As there is currently > >not such a notion, I see no reason not to treat authentication at-receipt > >and on-reply equivalently. > > > > I didn't say anything about treating them differently. But they two > situations are not equivalent, and stating that they are does not help in > any way. I suggest you simple omit any commentary on the equivalence. If > I am interpreting your words right, you are saying that the two are > equivalent in the implementation of the name server. I agree with that, > but this spec is supposed to be discussing just the protocol elements and > not the implementation. That's fine. I just don't think the spec should explicity differentiate these cases, which your alternative wording did. > >> >Does this apply to recursive servers, authoritative servers, or both? If > >> >recursive only, I agree with the new wording. Since it looks like the > >> >next paragraph specifically deals with authoritative answers, I'll assume > >> >recursive only, and suggest that the text be modified to make this more > >> >clear. > >> > >> I actually intended the above to apply to all servers. "Receipt" could be > >> via recursive fetching or by zone loading from disk. I don't know why the > >> distinction between recursive and authoritative is important in this case. > >> I really did word the clause for all server types. > > > >Well, then I'll reiterate the complaint that this is not a wording change. > > > > Well, yes. Now what? Um, stop trying to change the underlying meaning and calling it a "wording change"? > >> >> "In an authoritative answer (AA bit is set), with RR sets obtained from a > >> >> zone file or zone transfer but not cryptographically authenticated by the > >> >> name server, the AD bit MUST be set to 0. > >> > > >> >This is definitely not a cleanup to the text; this is completely different > >> >than the draft. Would you settle for something like "guaranteed to be > >> >cryptographically verifiable"? > >> > > >> > >> Yeah, this isn't a cleanup, but pushing a point that seems to be under > >> debate. I wouldn't want the word "guaranteed" as this is even more vague. > >> I, and I believe a few others, really want the answering process (the one > >> that transmit the AD bit as 1) to be the one that does the crypto. I > >> specifically want to avoid allowing an AD bit to be 1 when the > >> administrator is willing to trust the signing process to generate good > >> signatures. > > > >Yes, guaranteed probably isn't a good work. It was an idea, and not a > >particularly good one. > > > >I, and I believe a few others, want the AD bit to be useful. It's not > >useful if the spec requires the server to do verify-on-query, because > >there are enough problems with that so that it will not work in practice. > > No where do I require a server to do verify-on-query. I thought it has > been made clear that such an operation is not intended to be main-line > processing. I and a few others have thought it might be a good option to > have - and an option means "not the default." > > How about this - for the remaining discussion on this document, > verify-on-query is not mentioned as an operation. Sounds fair. > All I have been asking for is to limit the setting of AD to 1 in situations > in which the responder (responding process) has verified the sets itself. > This means a server that loads a zone without verification doesn't set the > AD to 1. Just about every other situation would lead to AD being 1. And all I'm asking is that the responder trusts the set itself, either due to validation or some other reason (like the data was properly configured). > >> (What I wanted to say is that "the sending process itself performed the > >> crypto and is sending the result." I didin't say that because I was trying > >> to avoid any implementation reference.) > > > >What I wanted to say is that "the sending process has good reason to > >believe that the data verifies, either because it has verified it itself > >or obtained this knowledge through a trusted channel". > > A "good reason to believe" isn't good enough in my opinion. > > I would like to know why you want to allow a server to set the bit based on > something as weak as a "good reason." Asking you as an implementor - do > you plan to set the AD bit because you assume there's a "good reason" to do > so? As the implementor of BIND, you said you won't set the bit. Because > of that statement, I'm a bit puzzled as to why you want a relaxed reason as > a precondition to setting the bit. Huh? As an implementor, I said that the current implementation doesn't set the bit, not that it won't. I believe that it serves no purpose to have an authoritative server verify data, and still don't see how hit improves security. If you sign the data on the same machine as the server (or a different machine, and transmit it securely), the server will see the signed data. At that point, any error that the server encounters validating the data is as likely to be the fault of the server as the data. You're arguing that administrators should not be allowed to be competent wnough to manage their signed zones. > >> >To paraphrase my earlier argument that was ignored, I don't see any reason > >> >why if I sign (and resign) data in a timely manner and verify it by hand, > >> >that I can't run a nameserver with no crypto and have it indicate that my > >> >data has been authenticated. > >> > >> My concern is that if we allow the answering process to apply the AD bit > >> because it considers (without checking) that the signatures will verify, > >> what is to stop an implementation from just setting the bit on all data - > >> authortitative and learned? I think the meaning of the AD bit is to convey > >> that "the answerer has checked this" and we want to maintain this - whether > >> the next hop is secured by TSIG, IPsec, or the receiver's rechecking of the > >> chain. > > > >What is to stop an implementation from violating any spec? Nothing. Such > >an implementation would be noncompliant. RFC 2535, section 6.1, > >says: > > > > The AD (authentic data) bit indicates > > in a response that all the data included in the answer and authority > > portion of the response has been authenticated by the server > > according to the policies of that server. > > > >and in section 4.3: > > > > 1. A security aware resolver that receives a response from a > > security aware server via a secure communication with the AD bit > > (see Section 6.1) set, MAY choose to accept the RRs as received > > without verifying the zone SIG RRs. > > > >The first paragraph describes the major point of contention (and I note > >that this never came up when 2535 was written), and the second describes > >the intent. The intent is to indicate to the resolver that it doesn't > >need to check SIG records, not to explicity indicate that it has verified > >the records. > > > >Note also that AD is defined as "authentic data", not "authenticated > >data". If I generate and sign my own data, it is authentic. > > > > The reason for bringing this up now is an increase in work on applications > that will make use of DNSSEC-backed data. I realize that a security > sensitive application should check the answer on its own, but there are a > lot of applications that want to sit at a point where they don't do crypto, > but do want to know. Right. > I am asking to have this document to clarify the "authenticated by the > server according to the policies of that server" to include an assurance > (at least in spec) that the policy includes doing the crypto. After all, > the document's purpose is to redefine the AD bit to be set to 0 if there is > no SIG RR to check. (In other words, AD means that the data has at > sometime been checked. Well, an unsigned zone can be considered checked if > the admin says "yup, that's mine" - so we are back to square one and don't > need this draft at all.) But the server wouldn't set AD if the data was not signed. That's the point of the draft - the AD bit means the data is secure (the draft is called ad-is-secure, not ad-is-cryptographically-verified-by-the-responding-process, after all). > >> I also feel that it is alright for a server to answer with authoritative > >> data plus signatures that it hasn't checked - but should indicate this via > >> the AA=1, AD=0 bit settings. I don't see the need to want to force AA=1, > >> AD=1. > > > >Neither do I, but I want to allow it. That's why the draft (still) > >contains the term "local policy". > > Allow it, yes, but don't make it worthless. Make the AD bit mean something. It does. That the data is secure, according to the local policy of the server. > >> >How about if the name server popped up a window saying "Someone has > >> >requested www.foo.com. Its SIG record is <...>. Is this valid?" This > >> >lets the server safely say that the data is verifiable, but not perform > >> >any verifications itself. It would also be insane. > >> > >> Yeah, for one, ISC would need to hire an X window programmer who could port > >> his/her results to Windows. (I am puzzled about "also be insane." What > >> does the also refer to?) > > > >So, you agree that the calling process doesn't need to do that actual > >verification, and it would be ok to set the AD bit if a trained monkey > >clicked on the "Yes" button every time this popped up? At that point, > >there's no difference between this and just trusting that the server has > >the right data in the first place. > > I don't follow this part of the thread. I really don't know where you're > going with this. I'm trying to get the point across that data can be declared secure without crypto in the server itself. It's not working, I guess. > >> >Basically, my point is that if I give out bad data and the my server's not > >> >doing authentication, it's my own fault. This only affects clients using > >> >my server for recursive queries, which I as administrator would probably > >> >not allow anyway, since authoritative and caching services should be split. > >> > >> First - remember that DNSSEC is about securing the answer the resolver > >> gets, not the reply the server sends. Be tight with what we allow the > >> server to do - leave less to local configuration so that a recursive server > >> can do what it needs to do. > > > >Right. But I can configure a server to give out good data to a resolver > >without it being forced to do validation. > > > > "it" - the resolver? If so, that's the point. The server does the > validation, the resolver believes it (via TSIG, IPsec, firewall, blind > faith). No, "it" == the server. The server indicates that the data is secure according to its local policy (which may mean that it verified it), and the resolver believes it. > >> Second - don't assume that admins will run DNS the way you think. BIND is > >> built for just about any situation, and there have been many in use in the > >> past. Don't pen admins into one right mental model about how to run DNS. > > > >I'm not. The draft (still) says "local policy". You're the one saying > >that all admins should be forced to run a server that verifies > >authoritative data. I'm saying that it should be optional. > > No, I never said that "admins should be forced to run a server that verifies > authoritative data." Again, it would be a nice option to have. Two, all I > want to have is the AD bit set to 0 if the answerer did not do the checking. And all I want is the ability to run an authoritative server without crypto that can set the AD bit to 1 on data that is secure. > I have repeatedly said that it is fine for a resolver to see AA=1, AD=0 and > the answer protected by some local link method (TSIG, et.al.) and (the > resolver) can still believe the answer to be true. Have you? I haven't seen this recently. I believe someone else (Jacob?) has complained that checking both AD and AA makes things more complicate for the resolver. > >It's getting pretty obvious that we're not going to reach a compromise, > >since the draft is trying to retain the spirit of the original > >specification, which you're disagreeing with, and you're completely > >missing the fact that the draft doesn't require AD to be set on > >authoritative data, but allows it. > > Since you stated this as a personal attack, I'll respond that way. I am > not missing the fact mentioned above. I don't know where you got the idea > that I want to tie the AD bit to the authoritativeness of the responder. > How many times do I need to say "it is fine for the resolver to accept AA=1 > AD=0 TSIG'd (et.al.) answers as trustworthy? I don't want the AD bit set > on authortative data! (Unless the authortative server bothered to check it > - which doesn't mean I want the server to check it - but if checked, AD can > be 1.) Where have you said this? Not in this thread. I didn't mean that as a personal attack, just a statement of frustration. > PS - If your draft is trying to retain the spirit of the original, why > bother writing it? I thought this was to be a clarification to the spec. The intention was basically to stop: - recursive servers from setting the AD bit on provably insecure data. - authoritative servers from setting the AD bit on unsecured zones. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jul 29 01:52:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA14017 for ; Sun, 29 Jul 2001 01:52:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15QW5X-000Bz7-00 for namedroppers-data@psg.com; Sat, 28 Jul 2001 08:33:11 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15QW5W-000Bz1-00 for namedroppers@ops.ietf.org; Sat, 28 Jul 2001 08:33:10 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15QW5W-000NN5-00 for namedroppers@ops.ietf.org; Sat, 28 Jul 2001 08:33:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Edward Lewis To: Brian Wellington Cc: Edward Lewis , , DNSEXT Subject: Re: restart: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sat, 28 Jul 2001 08:33:11 -0700 Content-Transfer-Encoding: 7bit At 12:10 PM -0400 7/27/01, Brian Wellington wrote: >On Fri, 27 Jul 2001, Edward Lewis wrote: > >> At 1:03 PM -0400 7/26/01, Brian Wellington wrote: >> >On Thu, 26 Jul 2001, Edward Lewis wrote: >> > >> >> Anyway, here is (a start on) how I would clean up the text: >> >> >> >> "In an answer in which all RR sets in the answer and authority >>sections are >> >> cryptographically authenticated according to the responding servers >>policy, >> >> the AD bit MUST be set to 1 if the query indicates the resolver >>understands >> >> DNSSEC [ref: DNSSEC OK draft]. >> >> >> >> [[Note the use of MUST and not SHOULD.]] >> >> >> >> "Unless the responder has cryptographically authenticated all of the RR >> >> sets in the answer and authority sections of the response, the AD bit >>MUST >> >> be set to 0. Any authentication MUST include authentication of all key >> >> sets used when chaining. The authentication MAY occur upon receipt >>of the >> >> data or MAY occur upon reply. >> > >> >Did you intend to change "any relevant negative response RRs in the >> >authority section" to "all RR sets in the ... authority section"? I have >> >no strong feelings one way or the other, but it is a change. >> > >> >I might also change the last sentence to: >> > >> > The authentication MAY occur upon receipt of the data or MAY occur >> > upon reply. If authentication is performed on receipt, the TTL >> > MUST be trimmed as described in RFC 2535, section 4.4. These two >> > forms of authentication are considered equivalent. >> >> I would omit the last sentence. It is true in some contexts that the forms >> described are equivalent, but not in other contexts. Within the context of >> the time-ignorant, non-revokable DNS (which he have today), the two are >> equivalent. In an application which is time-sensitive, the two are not. >> Whether one feels that a time-sensitive application should be making use of >> DNS for uptodate data is a point to argued elsewhere. > >I would hope that the DNS protocol is replaced with something different >before the ability to revoke records is added. As there is currently >not such a notion, I see no reason not to treat authentication at-receipt >and on-reply equivalently. > I didn't say anything about treating them differently. But they two situations are not equivalent, and stating that they are does not help in any way. I suggest you simple omit any commentary on the equivalence. If I am interpreting your words right, you are saying that the two are equivalent in the implementation of the name server. I agree with that, but this spec is supposed to be discussing just the protocol elements and not the implementation. >> >Does this apply to recursive servers, authoritative servers, or both? If >> >recursive only, I agree with the new wording. Since it looks like the >> >next paragraph specifically deals with authoritative answers, I'll assume >> >recursive only, and suggest that the text be modified to make this more >> >clear. >> >> I actually intended the above to apply to all servers. "Receipt" could be >> via recursive fetching or by zone loading from disk. I don't know why the >> distinction between recursive and authoritative is important in this case. >> I really did word the clause for all server types. > >Well, then I'll reiterate the complaint that this is not a wording change. > Well, yes. Now what? >> >> "In an authoritative answer (AA bit is set), with RR sets obtained from a >> >> zone file or zone transfer but not cryptographically authenticated by the >> >> name server, the AD bit MUST be set to 0. >> > >> >This is definitely not a cleanup to the text; this is completely different >> >than the draft. Would you settle for something like "guaranteed to be >> >cryptographically verifiable"? >> > >> >> Yeah, this isn't a cleanup, but pushing a point that seems to be under >> debate. I wouldn't want the word "guaranteed" as this is even more vague. >> I, and I believe a few others, really want the answering process (the one >> that transmit the AD bit as 1) to be the one that does the crypto. I >> specifically want to avoid allowing an AD bit to be 1 when the >> administrator is willing to trust the signing process to generate good >> signatures. > >Yes, guaranteed probably isn't a good work. It was an idea, and not a >particularly good one. > >I, and I believe a few others, want the AD bit to be useful. It's not >useful if the spec requires the server to do verify-on-query, because >there are enough problems with that so that it will not work in practice. No where do I require a server to do verify-on-query. I thought it has been made clear that such an operation is not intended to be main-line processing. I and a few others have thought it might be a good option to have - and an option means "not the default." How about this - for the remaining discussion on this document, verify-on-query is not mentioned as an operation. All I have been asking for is to limit the setting of AD to 1 in situations in which the responder (responding process) has verified the sets itself. This means a server that loads a zone without verification doesn't set the AD to 1. Just about every other situation would lead to AD being 1. >> (What I wanted to say is that "the sending process itself performed the >> crypto and is sending the result." I didin't say that because I was trying >> to avoid any implementation reference.) > >What I wanted to say is that "the sending process has good reason to >believe that the data verifies, either because it has verified it itself >or obtained this knowledge through a trusted channel". > A "good reason to believe" isn't good enough in my opinion. I would like to know why you want to allow a server to set the bit based on something as weak as a "good reason." Asking you as an implementor - do you plan to set the AD bit because you assume there's a "good reason" to do so? As the implementor of BIND, you said you won't set the bit. Because of that statement, I'm a bit puzzled as to why you want a relaxed reason as a precondition to setting the bit. >> >To paraphrase my earlier argument that was ignored, I don't see any reason >> >why if I sign (and resign) data in a timely manner and verify it by hand, >> >that I can't run a nameserver with no crypto and have it indicate that my >> >data has been authenticated. >> >> My concern is that if we allow the answering process to apply the AD bit >> because it considers (without checking) that the signatures will verify, >> what is to stop an implementation from just setting the bit on all data - >> authortitative and learned? I think the meaning of the AD bit is to convey >> that "the answerer has checked this" and we want to maintain this - whether >> the next hop is secured by TSIG, IPsec, or the receiver's rechecking of the >> chain. > >What is to stop an implementation from violating any spec? Nothing. Such >an implementation would be noncompliant. RFC 2535, section 6.1, >says: > > The AD (authentic data) bit indicates > in a response that all the data included in the answer and authority > portion of the response has been authenticated by the server > according to the policies of that server. > >and in section 4.3: > > 1. A security aware resolver that receives a response from a > security aware server via a secure communication with the AD bit > (see Section 6.1) set, MAY choose to accept the RRs as received > without verifying the zone SIG RRs. > >The first paragraph describes the major point of contention (and I note >that this never came up when 2535 was written), and the second describes >the intent. The intent is to indicate to the resolver that it doesn't >need to check SIG records, not to explicity indicate that it has verified >the records. > >Note also that AD is defined as "authentic data", not "authenticated >data". If I generate and sign my own data, it is authentic. > The reason for bringing this up now is an increase in work on applications that will make use of DNSSEC-backed data. I realize that a security sensitive application should check the answer on its own, but there are a lot of applications that want to sit at a point where they don't do crypto, but do want to know. I am asking to have this document to clarify the "authenticated by the server according to the policies of that server" to include an assurance (at least in spec) that the policy includes doing the crypto. After all, the document's purpose is to redefine the AD bit to be set to 0 if there is no SIG RR to check. (In other words, AD means that the data has at sometime been checked. Well, an unsigned zone can be considered checked if the admin says "yup, that's mine" - so we are back to square one and don't need this draft at all.) >> I also feel that it is alright for a server to answer with authoritative >> data plus signatures that it hasn't checked - but should indicate this via >> the AA=1, AD=0 bit settings. I don't see the need to want to force AA=1, >> AD=1. > >Neither do I, but I want to allow it. That's why the draft (still) >contains the term "local policy". Allow it, yes, but don't make it worthless. Make the AD bit mean something. >> >How about if the name server popped up a window saying "Someone has >> >requested www.foo.com. Its SIG record is <...>. Is this valid?" This >> >lets the server safely say that the data is verifiable, but not perform >> >any verifications itself. It would also be insane. >> >> Yeah, for one, ISC would need to hire an X window programmer who could port >> his/her results to Windows. (I am puzzled about "also be insane." What >> does the also refer to?) > >So, you agree that the calling process doesn't need to do that actual >verification, and it would be ok to set the AD bit if a trained monkey >clicked on the "Yes" button every time this popped up? At that point, >there's no difference between this and just trusting that the server has >the right data in the first place. I don't follow this part of the thread. I really don't know where you're going with this. >("would also be insane" means that anyone who wrote such code would be >insane. Not important) > >> >Basically, my point is that if I give out bad data and the my server's not >> >doing authentication, it's my own fault. This only affects clients using >> >my server for recursive queries, which I as administrator would probably >> >not allow anyway, since authoritative and caching services should be split. >> >> First - remember that DNSSEC is about securing the answer the resolver >> gets, not the reply the server sends. Be tight with what we allow the >> server to do - leave less to local configuration so that a recursive server >> can do what it needs to do. > >Right. But I can configure a server to give out good data to a resolver >without it being forced to do validation. > "it" - the resolver? If so, that's the point. The server does the validation, the resolver believes it (via TSIG, IPsec, firewall, blind faith). >> Second - don't assume that admins will run DNS the way you think. BIND is >> built for just about any situation, and there have been many in use in the >> past. Don't pen admins into one right mental model about how to run DNS. > >I'm not. The draft (still) says "local policy". You're the one saying >that all admins should be forced to run a server that verifies >authoritative data. I'm saying that it should be optional. > No, I never said that "admins should be forced to run a server that verifies authoritative data." Again, it would be a nice option to have. Two, all I want to have is the AD bit set to 0 if the answerer did not do the checking. I have repeatedly said that it is fine for a resolver to see AA=1, AD=0 and the answer protected by some local link method (TSIG, et.al.) and (the resolver) can still believe the answer to be true. I have never advocated requiring admins to run a server in a particular manner. >> >> A table to summarize AD bit settings: >> >> Server: from disk no check verify/get verify/put fail >> >>verification >> >> --------- -------- ---------- ---------- >> >>----------------- >> >> Resolver: >> >> doesn't know DNSSEC 0 0 0 0 0 serv fail >> >> knows DNSSEC 0 0 1 1 0 serv fail >> > >> >I'd really prefer: >> > >> >Server: disk secure-xfr insecure-xfr verified failed verify >> > ------ ---------- ------------ -------- --------------- >> >DO not set 0 0 0 0 servfail >> >DO set 0/1 0/1 0 1 servfail >> > >> >where 0/1 indicates either value may be used, depending on whether the >> >data is "guaranteed to be cryptographically verifiable" >> >> I don't agree with allowing "guaranteed" to be there. (Same arguement as >> before.) I think this weakens the definition. > >I agree that guaranteed is a not a particularly good word. > >It's getting pretty obvious that we're not going to reach a compromise, >since the draft is trying to retain the spirit of the original >specification, which you're disagreeing with, and you're completely >missing the fact that the draft doesn't require AD to be set on >authoritative data, but allows it. Since you stated this as a personal attack, I'll respond that way. I am not missing the fact mentioned above. I don't know where you got the idea that I want to tie the AD bit to the authoritativeness of the responder. How many times do I need to say "it is fine for the resolver to accept AA=1 AD=0 TSIG'd (et.al.) answers as trustworthy? I don't want the AD bit set on authortative data! (Unless the authortative server bothered to check it - which doesn't mean I want the server to check it - but if checked, AD can be 1.) PS - If your draft is trying to retain the spirit of the original, why bother writing it? I thought this was to be a clarification to the spec. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com You fly too often when ... the airport taxi is on speed-dial. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jul 29 01:52:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA14038 for ; Sun, 29 Jul 2001 01:52:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15QW5Q-000Byj-00 for namedroppers-data@psg.com; Sat, 28 Jul 2001 08:33:04 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15QW5P-000Byd-00 for namedroppers@ops.ietf.org; Sat, 28 Jul 2001 08:33:03 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15QW5P-000NMt-00 for namedroppers@ops.ietf.org; Sat, 28 Jul 2001 08:33:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Edward Lewis To: Brian Wellington Cc: Edward Lewis , , DNSEXT Subject: shortened Re: restart: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sat, 28 Jul 2001 08:33:04 -0700 Content-Transfer-Encoding: 7bit What is the motivation for allowing a responding element (e.g., a name server) to set the AD bit 1 for data that the responder has not authenticated? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com You fly too often when ... the airport taxi is on speed-dial. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jul 29 01:52:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA14054 for ; Sun, 29 Jul 2001 01:52:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15QVvU-000BdA-00 for namedroppers-data@psg.com; Sat, 28 Jul 2001 08:22:48 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15QVvU-000Bd3-00 for namedroppers@ops.ietf.org; Sat, 28 Jul 2001 08:22:48 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15QVvU-000N4g-00 for namedroppers@ops.ietf.org; Sat, 28 Jul 2001 08:22:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Brian Wellington To: Edward Lewis Cc: , DNSEXT Subject: Re: restart: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sat, 28 Jul 2001 08:22:48 -0700 Content-Transfer-Encoding: 7bit On Fri, 27 Jul 2001, Edward Lewis wrote: > At 1:03 PM -0400 7/26/01, Brian Wellington wrote: > >On Thu, 26 Jul 2001, Edward Lewis wrote: > > > >> Anyway, here is (a start on) how I would clean up the text: > >> > >> "In an answer in which all RR sets in the answer and authority sections are > >> cryptographically authenticated according to the responding servers policy, > >> the AD bit MUST be set to 1 if the query indicates the resolver understands > >> DNSSEC [ref: DNSSEC OK draft]. > >> > >> [[Note the use of MUST and not SHOULD.]] > >> > >> "Unless the responder has cryptographically authenticated all of the RR > >> sets in the answer and authority sections of the response, the AD bit MUST > >> be set to 0. Any authentication MUST include authentication of all key > >> sets used when chaining. The authentication MAY occur upon receipt of the > >> data or MAY occur upon reply. > > > >Did you intend to change "any relevant negative response RRs in the > >authority section" to "all RR sets in the ... authority section"? I have > >no strong feelings one way or the other, but it is a change. > > > >I might also change the last sentence to: > > > > The authentication MAY occur upon receipt of the data or MAY occur > > upon reply. If authentication is performed on receipt, the TTL > > MUST be trimmed as described in RFC 2535, section 4.4. These two > > forms of authentication are considered equivalent. > > I would omit the last sentence. It is true in some contexts that the forms > described are equivalent, but not in other contexts. Within the context of > the time-ignorant, non-revokable DNS (which he have today), the two are > equivalent. In an application which is time-sensitive, the two are not. > Whether one feels that a time-sensitive application should be making use of > DNS for uptodate data is a point to argued elsewhere. I would hope that the DNS protocol is replaced with something different before the ability to revoke records is added. As there is currently not such a notion, I see no reason not to treat authentication at-receipt and on-reply equivalently. > >Does this apply to recursive servers, authoritative servers, or both? If > >recursive only, I agree with the new wording. Since it looks like the > >next paragraph specifically deals with authoritative answers, I'll assume > >recursive only, and suggest that the text be modified to make this more > >clear. > > I actually intended the above to apply to all servers. "Receipt" could be > via recursive fetching or by zone loading from disk. I don't know why the > distinction between recursive and authoritative is important in this case. > I really did word the clause for all server types. Well, then I'll reiterate the complaint that this is not a wording change. > >> "In an authoritative answer (AA bit is set), with RR sets obtained from a > >> zone file or zone transfer but not cryptographically authenticated by the > >> name server, the AD bit MUST be set to 0. > > > >This is definitely not a cleanup to the text; this is completely different > >than the draft. Would you settle for something like "guaranteed to be > >cryptographically verifiable"? > > > > Yeah, this isn't a cleanup, but pushing a point that seems to be under > debate. I wouldn't want the word "guaranteed" as this is even more vague. > I, and I believe a few others, really want the answering process (the one > that transmit the AD bit as 1) to be the one that does the crypto. I > specifically want to avoid allowing an AD bit to be 1 when the > administrator is willing to trust the signing process to generate good > signatures. Yes, guaranteed probably isn't a good work. It was an idea, and not a particularly good one. I, and I believe a few others, want the AD bit to be useful. It's not useful if the spec requires the server to do verify-on-query, because there are enough problems with that so that it will not work in practice. > (What I wanted to say is that "the sending process itself performed the > crypto and is sending the result." I didin't say that because I was trying > to avoid any implementation reference.) What I wanted to say is that "the sending process has good reason to believe that the data verifies, either because it has verified it itself or obtained this knowledge through a trusted channel". > >To paraphrase my earlier argument that was ignored, I don't see any reason > >why if I sign (and resign) data in a timely manner and verify it by hand, > >that I can't run a nameserver with no crypto and have it indicate that my > >data has been authenticated. > > My concern is that if we allow the answering process to apply the AD bit > because it considers (without checking) that the signatures will verify, > what is to stop an implementation from just setting the bit on all data - > authortitative and learned? I think the meaning of the AD bit is to convey > that "the answerer has checked this" and we want to maintain this - whether > the next hop is secured by TSIG, IPsec, or the receiver's rechecking of the > chain. What is to stop an implementation from violating any spec? Nothing. Such an implementation would be noncompliant. RFC 2535, section 6.1, says: The AD (authentic data) bit indicates in a response that all the data included in the answer and authority portion of the response has been authenticated by the server according to the policies of that server. and in section 4.3: 1. A security aware resolver that receives a response from a security aware server via a secure communication with the AD bit (see Section 6.1) set, MAY choose to accept the RRs as received without verifying the zone SIG RRs. The first paragraph describes the major point of contention (and I note that this never came up when 2535 was written), and the second describes the intent. The intent is to indicate to the resolver that it doesn't need to check SIG records, not to explicity indicate that it has verified the records. Note also that AD is defined as "authentic data", not "authenticated data". If I generate and sign my own data, it is authentic. > I also feel that it is alright for a server to answer with authoritative > data plus signatures that it hasn't checked - but should indicate this via > the AA=1, AD=0 bit settings. I don't see the need to want to force AA=1, > AD=1. Neither do I, but I want to allow it. That's why the draft (still) contains the term "local policy". > >How about if the name server popped up a window saying "Someone has > >requested www.foo.com. Its SIG record is <...>. Is this valid?" This > >lets the server safely say that the data is verifiable, but not perform > >any verifications itself. It would also be insane. > > Yeah, for one, ISC would need to hire an X window programmer who could port > his/her results to Windows. (I am puzzled about "also be insane." What > does the also refer to?) So, you agree that the calling process doesn't need to do that actual verification, and it would be ok to set the AD bit if a trained monkey clicked on the "Yes" button every time this popped up? At that point, there's no difference between this and just trusting that the server has the right data in the first place. ("would also be insane" means that anyone who wrote such code would be insane. Not important) > >Basically, my point is that if I give out bad data and the my server's not > >doing authentication, it's my own fault. This only affects clients using > >my server for recursive queries, which I as administrator would probably > >not allow anyway, since authoritative and caching services should be split. > > First - remember that DNSSEC is about securing the answer the resolver > gets, not the reply the server sends. Be tight with what we allow the > server to do - leave less to local configuration so that a recursive server > can do what it needs to do. Right. But I can configure a server to give out good data to a resolver without it being forced to do validation. > Second - don't assume that admins will run DNS the way you think. BIND is > built for just about any situation, and there have been many in use in the > past. Don't pen admins into one right mental model about how to run DNS. I'm not. The draft (still) says "local policy". You're the one saying that all admins should be forced to run a server that verifies authoritative data. I'm saying that it should be optional. > >> A table to summarize AD bit settings: > >> Server: from disk no check verify/get verify/put fail > >>verification > >> --------- -------- ---------- ---------- > >>----------------- > >> Resolver: > >> doesn't know DNSSEC 0 0 0 0 0 serv fail > >> knows DNSSEC 0 0 1 1 0 serv fail > > > >I'd really prefer: > > > >Server: disk secure-xfr insecure-xfr verified failed verify > > ------ ---------- ------------ -------- --------------- > >DO not set 0 0 0 0 servfail > >DO set 0/1 0/1 0 1 servfail > > > >where 0/1 indicates either value may be used, depending on whether the > >data is "guaranteed to be cryptographically verifiable" > > I don't agree with allowing "guaranteed" to be there. (Same arguement as > before.) I think this weakens the definition. I agree that guaranteed is a not a particularly good word. It's getting pretty obvious that we're not going to reach a compromise, since the draft is trying to retain the spirit of the original specification, which you're disagreeing with, and you're completely missing the fact that the draft doesn't require AD to be set on authoritative data, but allows it. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jul 29 01:52:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA14072 for ; Sun, 29 Jul 2001 01:52:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15QVwn-000Bg8-00 for namedroppers-data@psg.com; Sat, 28 Jul 2001 08:24:09 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15QVwm-000Bg2-00 for namedroppers@ops.ietf.org; Sat, 28 Jul 2001 08:24:08 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15QVwm-000N77-00 for namedroppers@ops.ietf.org; Sat, 28 Jul 2001 08:24:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Brian Wellington To: Cc: DNSEXT Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: <200107271350.PAA09366@omval.tednet.nl> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sat, 28 Jul 2001 08:24:09 -0700 Content-Transfer-Encoding: 7bit On Fri, 27 Jul 2001, Ted Lindgreen wrote: > [Quoting Brian Wellington, on Jul 26, 18:06, in "Re: I-D ACTION:draft ..."] > > On Thu, 26 Jul 2001, Ted Lindgreen wrote: > > > > > Note: It would have been different, if BIND in the "recursive view" > > > would actually check the data it is authorative for query-time, > > > but as far as I know this is not in the code at the moment. > > > > You missed the point again. In the "recursive view", there is no > > authoritative data. There is only cached data. If the cached data is > > obtained from the "authoritative view", it's treated just like data > > obtained from any other source, meaning it is validated at the time it's > > received and the TTL is properly clamped. > > Dear Brian, > > I stand corrected, indeed, I did not understand that from the > same server, you get different answers, depending on to what view > you belong. Your answer made me further very happy, as it now > appears, that with some careful configuration the software can do > something close to what we want (be careful not to advertize data > with bad and/or outdated sig's). Good. > However, my happiness did not last very long :-( > > Of course, I tried it out immediately to see how we can adopt > this scheme in our DNSSEC testbed for .nl.nl. > > However, after trying out various configuration setups I found out, > that setting up multiple views is extremenly tricky, especially if > your systems are authorative for various domains at different levels > in the tree. Although we are doing something special with DNSSEC, > I don't think our tree-structure is very uncommon in the real world. It shouldn't be tricky. If you describe what you did (to a more appropriate place, like bind9-users), someone might be able to find the problem. > After reconfigurating for 6 hours now, I still have not found > a configuration, that would reliably produce verified data where > I want it to do that, and to provide authoritive data where it must > do that to prevent the delegations from getting lame. Yes, this is a real problem. Fortunately, I'm one step ahead of you. Added yesterday: 945. [func] Add the new view-specific options "match-destinations" and "match-recursive-only". "match-recursive-only" will allow recursive clients to match the recursive view, while non-recursive clients (such as forwarding servers and zone transfer clients) to match an authoritative view. This will be in BIND 9.2.0b2, due (I think) Monday. > I've given up now, and only left the testdomain "ted.dnssec.nl.nl" > secured on a dual view server in case any anyone is interested to > look at it: sanne.nlnetlabs.nl is the dual-view server, and > auth-parent-servers plus its own secondaries are in the auth. view; > the rest of the world in the recursive view; with > dig @sanne.nlnetlabs.nl +dnssec -t txt ted.dnssec.nl.nl > you can see, that sometimes the answer is as Brian predicted above, > and sometimes you get "SERVFAIL". I have not been able to find out > what the reason for this inconsistance is. It's probably that problem with nonauthoritative answers. Can you try the same setup with 9.2.0b2 when released? > Because of trickyness and the stability problem, I reverted to the > old setup for all other domains, where bad and outdated sigs are > happily provided. > > PS. To go back on topic: I still think that it's a hack, and that > it is better to have the AD-bit to mean the same thing in every > view or context. It does mean the same thing in every context. The current version of BIND 9, for example, only sets AD when the data has been verified. Unless I'm mistaken, this is exactly what you're arguing for. The "bad or outdated" SIGs are coming from an authoritative zone, and the AD bit is not set. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jul 29 01:52:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA14083 for ; Sun, 29 Jul 2001 01:52:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15QVgk-000BE4-00 for namedroppers-data@psg.com; Sat, 28 Jul 2001 08:07:34 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15QVgj-000BDy-00 for namedroppers@ops.ietf.org; Sat, 28 Jul 2001 08:07:33 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15QVgj-000MfF-00 for namedroppers@ops.ietf.org; Sat, 28 Jul 2001 08:07:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Edward Lewis To: Brian Wellington Cc: Edward Lewis , , DNSEXT Subject: Re: restart: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sat, 28 Jul 2001 08:07:34 -0700 Content-Transfer-Encoding: 7bit At 1:03 PM -0400 7/26/01, Brian Wellington wrote: >On Thu, 26 Jul 2001, Edward Lewis wrote: > >> Anyway, here is (a start on) how I would clean up the text: >> >> "In an answer in which all RR sets in the answer and authority sections are >> cryptographically authenticated according to the responding servers policy, >> the AD bit MUST be set to 1 if the query indicates the resolver understands >> DNSSEC [ref: DNSSEC OK draft]. >> >> [[Note the use of MUST and not SHOULD.]] >> >> "Unless the responder has cryptographically authenticated all of the RR >> sets in the answer and authority sections of the response, the AD bit MUST >> be set to 0. Any authentication MUST include authentication of all key >> sets used when chaining. The authentication MAY occur upon receipt of the >> data or MAY occur upon reply. > >Did you intend to change "any relevant negative response RRs in the >authority section" to "all RR sets in the ... authority section"? I have >no strong feelings one way or the other, but it is a change. > >I might also change the last sentence to: > > The authentication MAY occur upon receipt of the data or MAY occur > upon reply. If authentication is performed on receipt, the TTL > MUST be trimmed as described in RFC 2535, section 4.4. These two > forms of authentication are considered equivalent. I would omit the last sentence. It is true in some contexts that the forms described are equivalent, but not in other contexts. Within the context of the time-ignorant, non-revokable DNS (which he have today), the two are equivalent. In an application which is time-sensitive, the two are not. Whether one feels that a time-sensitive application should be making use of DNS for uptodate data is a point to argued elsewhere. >Does this apply to recursive servers, authoritative servers, or both? If >recursive only, I agree with the new wording. Since it looks like the >next paragraph specifically deals with authoritative answers, I'll assume >recursive only, and suggest that the text be modified to make this more >clear. I actually intended the above to apply to all servers. "Receipt" could be via recursive fetching or by zone loading from disk. I don't know why the distinction between recursive and authoritative is important in this case. I really did word the clause for all server types. >> "In an authoritative answer (AA bit is set), with RR sets obtained from a >> zone file or zone transfer but not cryptographically authenticated by the >> name server, the AD bit MUST be set to 0. > >This is definitely not a cleanup to the text; this is completely different >than the draft. Would you settle for something like "guaranteed to be >cryptographically verifiable"? > Yeah, this isn't a cleanup, but pushing a point that seems to be under debate. I wouldn't want the word "guaranteed" as this is even more vague. I, and I believe a few others, really want the answering process (the one that transmit the AD bit as 1) to be the one that does the crypto. I specifically want to avoid allowing an AD bit to be 1 when the administrator is willing to trust the signing process to generate good signatures. (What I wanted to say is that "the sending process itself performed the crypto and is sending the result." I didin't say that because I was trying to avoid any implementation reference.) >To paraphrase my earlier argument that was ignored, I don't see any reason >why if I sign (and resign) data in a timely manner and verify it by hand, >that I can't run a nameserver with no crypto and have it indicate that my >data has been authenticated. My concern is that if we allow the answering process to apply the AD bit because it considers (without checking) that the signatures will verify, what is to stop an implementation from just setting the bit on all data - authortitative and learned? I think the meaning of the AD bit is to convey that "the answerer has checked this" and we want to maintain this - whether the next hop is secured by TSIG, IPsec, or the receiver's rechecking of the chain. I also feel that it is alright for a server to answer with authoritative data plus signatures that it hasn't checked - but should indicate this via the AA=1, AD=0 bit settings. I don't see the need to want to force AA=1, AD=1. >How about if the name server popped up a window saying "Someone has >requested www.foo.com. Its SIG record is <...>. Is this valid?" This >lets the server safely say that the data is verifiable, but not perform >any verifications itself. It would also be insane. Yeah, for one, ISC would need to hire an X window programmer who could port his/her results to Windows. (I am puzzled about "also be insane." What does the also refer to?) >Basically, my point is that if I give out bad data and the my server's not >doing authentication, it's my own fault. This only affects clients using >my server for recursive queries, which I as administrator would probably >not allow anyway, since authoritative and caching services should be split. First - remember that DNSSEC is about securing the answer the resolver gets, not the reply the server sends. Be tight with what we allow the server to do - leave less to local configuration so that a recursive server can do what it needs to do. Second - don't assume that admins will run DNS the way you think. BIND is built for just about any situation, and there have been many in use in the past. Don't pen admins into one right mental model about how to run DNS. >> "If the resolver does not indicate knowledge of DNSSEC, the AD bit MUST be >> set to 0." > >OK. > >> >> A table to summarize AD bit settings: >> Server: from disk no check verify/get verify/put fail >>verification >> --------- -------- ---------- ---------- >>----------------- >> Resolver: >> doesn't know DNSSEC 0 0 0 0 0 serv fail >> knows DNSSEC 0 0 1 1 0 serv fail > >I'd really prefer: > >Server: disk secure-xfr insecure-xfr verified failed verify > ------ ---------- ------------ -------- --------------- >DO not set 0 0 0 0 servfail >DO set 0/1 0/1 0 1 servfail > >where 0/1 indicates either value may be used, depending on whether the >data is "guaranteed to be cryptographically verifiable" I don't agree with allowing "guaranteed" to be there. (Same arguement as before.) I think this weakens the definition. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com You fly too often when ... the airport taxi is on speed-dial. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jul 29 01:52:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA14095 for ; Sun, 29 Jul 2001 01:52:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15QVhI-000BFe-00 for namedroppers-data@psg.com; Sat, 28 Jul 2001 08:08:08 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15QVhH-000BFY-00 for namedroppers@ops.ietf.org; Sat, 28 Jul 2001 08:08:07 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15QVhH-000MgC-00 for namedroppers@ops.ietf.org; Sat, 28 Jul 2001 08:08:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: ted@tednet.nl (Ted Lindgreen) To: Brian Wellington , Cc: DNSEXT Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: "Brian Wellington's message as of Jul 26, 18:06" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sat, 28 Jul 2001 08:08:08 -0700 Content-Transfer-Encoding: 7bit [Quoting Brian Wellington, on Jul 26, 18:06, in "Re: I-D ACTION:draft ..."] > On Thu, 26 Jul 2001, Ted Lindgreen wrote: > > > Note: It would have been different, if BIND in the "recursive view" > > would actually check the data it is authorative for query-time, > > but as far as I know this is not in the code at the moment. > > You missed the point again. In the "recursive view", there is no > authoritative data. There is only cached data. If the cached data is > obtained from the "authoritative view", it's treated just like data > obtained from any other source, meaning it is validated at the time it's > received and the TTL is properly clamped. Dear Brian, I stand corrected, indeed, I did not understand that from the same server, you get different answers, depending on to what view you belong. Your answer made me further very happy, as it now appears, that with some careful configuration the software can do something close to what we want (be careful not to advertize data with bad and/or outdated sig's). However, my happiness did not last very long :-( Of course, I tried it out immediately to see how we can adopt this scheme in our DNSSEC testbed for .nl.nl. However, after trying out various configuration setups I found out, that setting up multiple views is extremenly tricky, especially if your systems are authorative for various domains at different levels in the tree. Although we are doing something special with DNSSEC, I don't think our tree-structure is very uncommon in the real world. After reconfigurating for 6 hours now, I still have not found a configuration, that would reliably produce verified data where I want it to do that, and to provide authoritive data where it must do that to prevent the delegations from getting lame. I sure hope, that the average system administrator is more clever than I am. I've given up now, and only left the testdomain "ted.dnssec.nl.nl" secured on a dual view server in case any anyone is interested to look at it: sanne.nlnetlabs.nl is the dual-view server, and auth-parent-servers plus its own secondaries are in the auth. view; the rest of the world in the recursive view; with dig @sanne.nlnetlabs.nl +dnssec -t txt ted.dnssec.nl.nl you can see, that sometimes the answer is as Brian predicted above, and sometimes you get "SERVFAIL". I have not been able to find out what the reason for this inconsistance is. Because of trickyness and the stability problem, I reverted to the old setup for all other domains, where bad and outdated sigs are happily provided. Regards, -- ted PS. To go back on topic: I still think that it's a hack, and that it is better to have the AD-bit to mean the same thing in every view or context. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jul 29 10:49:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22548 for ; Sun, 29 Jul 2001 10:49:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Qr8v-000M6L-00 for namedroppers-data@psg.com; Sun, 29 Jul 2001 07:02:05 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15Qr8v-000M6F-00 for namedroppers@ops.ietf.org; Sun, 29 Jul 2001 07:02:05 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15Qr8v-000JJc-00 for namedroppers@ops.ietf.org; Sun, 29 Jul 2001 07:02:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "D. J. Bernstein" To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Re: NGtrans - DNSext joint meeting, call for participation References: <200107202005.f6KK50F11379@gungnir.fnal.gov> <20010723140044.A17822@pianosa.catch22.org> <2261.996231603@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sun, 29 Jul 2001 07:02:05 -0700 Content-Transfer-Encoding: 7bit Robert Elz writes: > The data needs to be somehow carried to the key (which cannot be > exposed anywhere near any network), the signing done, and then the > data carried back again. Doing that once a month for most people > just might be tolerable - once a day and all that will ever exist are > expired signatures. How, pray tell, do you expect a large site to sign its DNS records, if it has access to its signing key only twelve times a year? This is even worse than ``wait a month for old records to go away.'' It also means ``wait a month for new records to appear.'' Do you seriously believe that administrators and users will tolerate this? ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jul 29 10:49:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22560 for ; Sun, 29 Jul 2001 10:49:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Qr1D-000Lu0-00 for namedroppers-data@psg.com; Sun, 29 Jul 2001 06:54:07 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15Qr1C-000Ltu-00 for namedroppers@ops.ietf.org; Sun, 29 Jul 2001 06:54:06 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15Qr1C-000Iv1-00 for namedroppers@ops.ietf.org; Sun, 29 Jul 2001 06:54:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "D. J. Bernstein" To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: NGtrans - DNSext joint meeting, call for participation References: <20010728060823.20080.qmail@cr.yp.to> <200107280731.f6S7VKu63249@drugs.dv.isc.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sun, 29 Jul 2001 06:54:07 -0700 Content-Transfer-Encoding: 7bit Mark.Andrews@nominum.com writes: > Pre change: > example.com SIG KEY expire=200107292257 (1 day) > host.example.com SIG A expire=200108272257 (30 days) > Post change: > example.com SIG KEY expire=200107072258 (1 day) > host.example.com SIG A expire=200108272258 (30 days) You are, as I said, signing the host record again. You have to sign all your other records too, never mind the costs of generating and distributing the new key. If you change at least one of your records every day---certainly a reasonable assumption for the big organizations we're talking about--- then you are signing all your records every day. The key change isn't accomplishing anything. The bottom line remains the same. Even without renumbering, you are signing every record every day. If that isn't a problem, then occasional renumbering certainly isn't a problem. If you have one day warning, you can renumber for free. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jul 29 11:39:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22549 for ; Sun, 29 Jul 2001 10:49:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Qr1W-000LuV-00 for namedroppers-data@psg.com; Sun, 29 Jul 2001 06:54:26 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15Qr1V-000LuP-00 for namedroppers@ops.ietf.org; Sun, 29 Jul 2001 06:54:25 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15Qr1V-000Iw0-00 for namedroppers@ops.ietf.org; Sun, 29 Jul 2001 06:54:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Mark.Andrews@nominum.com To: "D. J. Bernstein" Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: NGtrans - DNSext joint meeting, call for participation In-reply-to: Your message of "29 Jul 2001 12:14:24 GMT." <20010729121424.4964.qmail@cr.yp.to> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sun, 29 Jul 2001 06:54:26 -0700 Content-Transfer-Encoding: 7bit > Mark.Andrews@nominum.com writes: > > Pre change: > > example.com SIG KEY expire=200107292257 (1 day) > > host.example.com SIG A expire=200108272257 (30 days) > > Post change: > > example.com SIG KEY expire=200107072258 (1 day) > > host.example.com SIG A expire=200108272258 (30 days) > > You are, as I said, signing the host record again. You have to sign all > your other records too, never mind the costs of generating and > distributing the new key. Is the cost of generating a new key occasionally more or less than that of signing all the zone daily. As for the cost of distributing the new key, it is no different to continue to distribute the old key apart from the cost in getting it signed (which is the same in both your and my cases). > > If you change at least one of your records every day---certainly a > reasonable assumption for the big organizations we're talking about--- > then you are signing all your records every day. The key change isn't > accomplishing anything. You are making ungrounded assumptions here. Not all large organizations keep everything in one flat namespace. If you use the DNS as it was designed to be used you don't see every zone in a organization changing daily or even monthly (or even a large pecentage of them). > > The bottom line remains the same. Even without renumbering, you are > signing every record every day. Really. Real life has plenty of examples where existing zones are not changed daily. To get 1 day replay protection something needs to be signed daily, however it doesn't have to be everything. > If that isn't a problem, then occasional > renumbering certainly isn't a problem. If you have one day warning, you > can renumber for free. Iff your assumptions hold true. In the real world there are plenty of case they don't. > > ---Dan Mark -- Mark Andrews, Nominum Inc. 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 30 03:41:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA05359 for ; Mon, 30 Jul 2001 03:41:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15R5HF-000FCZ-00 for namedroppers-data@psg.com; Sun, 29 Jul 2001 22:07:37 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15R5HE-000FCQ-00 for namedroppers@ops.ietf.org; Sun, 29 Jul 2001 22:07:36 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15R5HE-000AtC-00 for namedroppers@ops.ietf.org; Sun, 29 Jul 2001 22:07:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Brian Wellington To: Jakob Schlyter Cc: Edward Lewis , , DNSEXT Subject: Re: restart: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sun, 29 Jul 2001 22:07:37 -0700 Content-Transfer-Encoding: 7bit On Sun, 29 Jul 2001, Jakob Schlyter wrote: > On Sat, 28 Jul 2001, Edward Lewis wrote: > > > IMHO an AA bit outranks an AD bit. Data with AA=1,AD=0 is reputedly > > coming from *the* source (TSIG, et.al.) Data with AA=0,AD=1 is > > reputedly data that some intermediary has verified as coming from the > > source. I would assign higher credibility to AA=1,AD=0 than > > AA=0,AD=1. > > an application could put trust in a dns reply by several reasons: > > reply source (i.e. who did I query) > reply transport (i.e. tsig, tkey or nothing) > status of some bits in the header (AA, AD, ...) > > I have to configure who and how I send my query, so this is a very basic > administrative problem (except for the policy part, but let's leave that > out for the moment). the AD-bit however is harder and needs to be well > defined as applications will interpret it without knowing the verification > policy. I agree so far. > the reason I like the nameserver to use the AD-bit, and only the AD-bit, > to signal that the data is authenticated cryptographically is simplicity. > I do not care about whether my nameserver is authorative or not - I only > care if it has validated the data or not. it could be authorative, yet the > zonefile could be invalid (e.g. the nameserver is secondary and doesn't > fully trust source). This is the problem. The stub resolver should not care whether the server has validated the data or not. If the resolver trusts the server, the server trusts the data, and the communication is secure, the resolver should trust the data. Let me give an example. I have a server that's authoritative for foo.com, which is signed. It also does recursion for my network. Assume that my resolver communicate securely with this server, and I trust it. If I query for bar.com, which is also signed, the server recursively fetches data data, does the validation, and returns a response with AD set. The resolver sees the AD bit, so it trusts the data. No one's arguing about this. If I query for foo.com, I would like to be able to trust the answer without having cryptographic validation done. I trust the server, and the communication, so I can trust the data. I'm arguing that it's ok to allow the server to set the AD bit on locally configured secure data. Ed said that the server shouldn't set the AD bit, but the resolver could trust data with the AA bit. You're saying that the resolver shouldn't trust this data at all unless cryptographic verification is done. This only comes up when querying a server for authoritative data. The only time stub resolvers query authoritative servers is for locally managed data. The resolver should be allowed to trust locally managed data. This is not about protecting the resolver from arbitrary broken servers; it's about allowing resolvers to trust local servers without forcing them to explicitly verify data. > let us, for the people using this - not the implementators, keep this > simple. finding something to trust and communicate securely with that > entity is hard enough. The above is from the point of view of a user. I'd like to be able to sign my zone at home and use DNSSEC capable applications (like a modified SSH), without forcing my server to needlessly verify data that it either loads from disk or obtains through a secure zone transfer. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 30 03:41:44 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA05366 for ; Mon, 30 Jul 2001 03:41:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15R5Ju-000FFw-00 for namedroppers-data@psg.com; Sun, 29 Jul 2001 22:10:22 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15R5Jt-000FFp-00 for namedroppers@ops.ietf.org; Sun, 29 Jul 2001 22:10:21 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15R5Jt-000B1Q-00 for namedroppers@ops.ietf.org; Sun, 29 Jul 2001 22:10:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Greg Hudson To: Brian Wellington cc: DNSEXT Subject: Re: AS IF: draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: Your message of "Sun, 29 Jul 2001 17:34:48 PDT." Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sun, 29 Jul 2001 22:10:22 -0700 Content-Transfer-Encoding: 7bit > Which sounds more secure? 2, obviously. Until you notice that the > key is read from disk also. First, the reason not to set AD bits on unchecked data is not to protected against compromised data on the server, but to detect expired signatures. Under your scheme, an authoritative server might yield a different value of the AD bit than a checking recursive resolver, and that's confusing and error-prone. Second, you've given an argument why it might be acceptable to set AD on non-checked responses, but do not give any motivation for doing so. An authoritative server is probably not acting as a recursive resolver for stub resolvers; if it is, then it needs to be prepared to do cryptographic checking if it wants to set AD bits on out of zone data at least. I can't envision a realistic scenario where your scheme adds any value. A cryptography-free authoritative server which also serves stub resolvers and sets AD bits but only on in-zone data? Seems a bit of a stretch. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 30 03:47:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA05621 for ; Mon, 30 Jul 2001 03:47:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15R5L8-000FIG-00 for namedroppers-data@psg.com; Sun, 29 Jul 2001 22:11:38 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15R5L8-000FI4-00 for namedroppers@ops.ietf.org; Sun, 29 Jul 2001 22:11:38 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15R5L8-000B5H-00 for namedroppers@ops.ietf.org; Sun, 29 Jul 2001 22:11:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Brian Wellington To: Greg Hudson Cc: DNSEXT Subject: Re: AS IF: draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: <200107300119.VAA07808@egyptian-gods.MIT.EDU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sun, 29 Jul 2001 22:11:38 -0700 Content-Transfer-Encoding: 7bit On Sun, 29 Jul 2001, Greg Hudson wrote: > > Which sounds more secure? 2, obviously. Until you notice that the > > key is read from disk also. > > First, the reason not to set AD bits on unchecked data is not to > protected against compromised data on the server, but to detect > expired signatures. Either I'm misunderstanding you, or you'd have no problem with setting AD on unchecked data after only checking the expiration time was. No crypto is needed to detect expired signatures. > Under your scheme, an authoritative server might > yield a different value of the AD bit than a checking recursive > resolver, and that's confusing and error-prone. Possibly. But this is a reason why the draft specifies that the server MAY classify local data as Authenticated. If the server will never be serving expired data (that is, is resigned on time), then that won't happen. > Second, you've given an argument why it might be acceptable to set AD > on non-checked responses, but do not give any motivation for doing so. > An authoritative server is probably not acting as a recursive resolver > for stub resolvers; if it is, then it needs to be prepared to do > cryptographic checking if it wants to set AD bits on out of zone data > at least. I can't envision a realistic scenario where your scheme > adds any value. A cryptography-free authoritative server which also > serves stub resolvers and sets AD bits but only on in-zone data? > Seems a bit of a stretch. Just because a server can do crypto doesn't mean it should. Crypto operations are slow, and there's no reason to slow down either lookups of local data and/or server startup when the zone is properly managed. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 30 03:59:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA06235 for ; Mon, 30 Jul 2001 03:59:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15R5Hq-000FDL-00 for namedroppers-data@psg.com; Sun, 29 Jul 2001 22:08:14 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15R5Hp-000FDF-00 for namedroppers@ops.ietf.org; Sun, 29 Jul 2001 22:08:13 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15R5Hp-000Av6-00 for namedroppers@ops.ietf.org; Sun, 29 Jul 2001 22:08:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Brian Wellington To: Greg Hudson Cc: John Gilmore , DNSEXT Subject: Re: AS IF: draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sun, 29 Jul 2001 22:08:14 -0700 Content-Transfer-Encoding: 7bit On Sat, 28 Jul 2001, Greg Hudson wrote: > I have yet to understand why anyone wants to set the AD bit on > unchecked data. Sure, an authoritative server shouldn't have to do > cryptography, but it also shouldn't ever need to set the AD bit unless > it's also acting as a recursive resolver for clients. In which case > it had better be prepared to do cryptography if it wants to set AD > bits. Scenario 1: A server reads secure data from a zone file, trusting the disk. It then can set the AD bit on responses from that file. Scenario 2: A server reads secure data from a zone file, and the key from a configuration file. Before setting the AD bit, it verifies the necessary signatures. Which sounds more secure? 2, obviously. Until you notice that the key is read from disk also. If someone can corrupt your zone files so that you give out bad data, they can surely corrupt the key so that the bad data properly verifies. Or, if they don't want to do that, they can just hijack your server and insert bad keys into the running process. The point is that if you trust a server enough to believe that it has verified data, you should trust it enough to read signed data from disk. Conversely, if you don't trust it enough to read signed data from disk, you shouldn't trust it enough that you believe it when it claims to have verified data. That's why I believe that setting the AD bit on locally configured data is acceptable. It's no more or less secure than having the server verify it. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 30 10:53:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25666 for ; Mon, 30 Jul 2001 10:53:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15RCx2-0000id-00 for namedroppers-data@psg.com; Mon, 30 Jul 2001 06:19:16 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15RCx2-0000iX-00 for namedroppers@ops.ietf.org; Mon, 30 Jul 2001 06:19:16 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15RCx2-0008XL-00 for namedroppers@ops.ietf.org; Mon, 30 Jul 2001 06:19:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Jakob Schlyter To: Brian Wellington Cc: Edward Lewis , , DNSEXT Subject: Re: restart: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 30 Jul 2001 06:19:16 -0700 Content-Transfer-Encoding: 7bit On Sun, 29 Jul 2001, Brian Wellington wrote: > > the reason I like the nameserver to use the AD-bit, and only the AD-bit, > > to signal that the data is authenticated cryptographically is simplicity. > > I do not care about whether my nameserver is authorative or not - I only > > care if it has validated the data or not. it could be authorative, yet the > > zonefile could be invalid (e.g. the nameserver is secondary and doesn't > > fully trust source). > > This is the problem. The stub resolver should not care whether the > server has validated the data or not. If the resolver trusts the > server, the server trusts the data, and the communication is secure, > the resolver should trust the data. the stub resolver may care whether the server has validated the data or not. if the servers hasn't validated the data, e.g. data data was never protected by dnssec, it can choose not to trust it at all. > I'd like to be able to sign my zone at home and use DNSSEC capable > applications (like a modified SSH), without forcing my server to > needlessly verify data that it either loads from disk or obtains > through a secure zone transfer. the "only" disagreement here is whether you may set AD without doing any cryptographic validation - on load (and checking for expired signatures on reply) or on reply. I'd like a "MUST NOT set the AD bit without cryptographic validation", but could go for a "SHOULD NOT" if that's the consensus of the WG. something less stronger is to weak I believe. how do we resolve this? it would be nice if we could continue to secure the world instead of debating bits the headers :-) 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. From owner-namedroppers@ops.ietf.org Mon Jul 30 10:54:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25756 for ; Mon, 30 Jul 2001 10:54:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15RDca-0001qT-00 for namedroppers-data@psg.com; Mon, 30 Jul 2001 07:02:12 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15RDca-0001qN-00 for namedroppers@ops.ietf.org; Mon, 30 Jul 2001 07:02:12 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15RDca-000AhL-00 for namedroppers@ops.ietf.org; Mon, 30 Jul 2001 07:02:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Olafur Gudmundsson To: agenda@ietf.org, DNSEXT mailing list Subject: 51 IETF DNSEXT meeting Agenda X-Sender: ogud@hlid.dc.ogud.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 30 Jul 2001 07:02:12 -0700 Content-Transfer-Encoding: 7bit DNS extensions DNSEXT Agenda at the 51 IETF 2001/Aug/9 9:00 - 11:30 (Thursday) Palace Suite/Buckingham (check for updates on room change) Chairs: Olafur Gudmundsson Randy Bush There will be two DNSEXT meetings at the 51 IETF. This is the agenda for the SECOND one on Thursday. The first meeting on Monday, is a joint meeting with NGTRANS and there will be separate agenda posted. DNSEXT Agenda 05 min Agenda Bashing Olafur Gudmundsson 05 min WG status Olafur Gudmundsson 05 min Summary of DNSEXT/NGTRANS Olafur Gudmundsson Next on the agenda will be the main focus of the meeting to asses the current DNSSEC status and how it should evolve from now on. 20 min Current DNSSEC status and options on how to progress Edward Lewis + Olafur Gudmundsson 05 min DNSSEC editing status Dan Massey, Scott Rose 10 min Opt IN plan Mark Kosters 10 min No SIG Roy Arens 10 min Delegation Signer Olafur Gudmundsson 05 min SIG@Parent Miek Gieben 40 min Next steps in DNSSEC Randy Bush This will be open mike session to air opinions on which of the following options to go with. The chairs will take the suggestions and results of strawpolls to formulate a plan of action to propose to the working group on the the mailing list. The options are: - Finished tweaking DNSSEC (no more changes) - Few more tweaks (which ones) - Major Surgery (any collection new proposals such as opt-in, delegation signer, no, no-sig, ) - Start over, because the current approach is not going to work Old Working Group documents 05 min Multicast DNS Dave Thaler Relvatant Documents in Other working groups 05 min DHC MulticastDNS enable option Erik Guttman New documents requesting to become working group documents 05 min TKEY rekey mode Yuji Kamite 05 min SEC rr Edward Lewis 05 min Generic KEY RR Protocol value Edward Lewis 05 min ECC KEY rr Donald Eastlake 05 min Alternate DNS multicast proposal Stewart Cheshire to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 30 11:14:44 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27160 for ; Mon, 30 Jul 2001 11:14:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15RDln-00026h-00 for namedroppers-data@psg.com; Mon, 30 Jul 2001 07:11:43 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15RDlm-00026b-00 for namedroppers@ops.ietf.org; Mon, 30 Jul 2001 07:11:42 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15RDlm-000BAg-00 for namedroppers@ops.ietf.org; Mon, 30 Jul 2001 07:11:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Miek Gieben To: Jakob Schlyter Cc: Brian Wellington , Edward Lewis , ogud@ogud.com, DNSEXT Subject: Re: restart: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: ; from jakob@crt.se on Mon, Jul 30, 2001 at 06:19:16AM -0700 References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 30 Jul 2001 07:11:43 -0700 Content-Transfer-Encoding: 7bit [On 30 Jul, 2001, Jakob Schlyter wrote in " Re: restart: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt "] > I'd like a "MUST NOT set the AD bit without cryptographic validation", but > could go for a "SHOULD NOT" if that's the consensus of the WG. something > less stronger is to weak I believe. currently the AD bit has no meaning, and the draft tries to give it meaning, therefore it should not be "SHOULD NOT" :) , but a "MUST NOT". 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. From owner-namedroppers@ops.ietf.org Mon Jul 30 15:14:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16722 for ; Mon, 30 Jul 2001 15:14:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15RICP-0008dx-00 for namedroppers-data@psg.com; Mon, 30 Jul 2001 11:55:29 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15RICP-0008dr-00 for namedroppers@ops.ietf.org; Mon, 30 Jul 2001 11:55:29 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15RICO-000P45-00 for namedroppers@ops.ietf.org; Mon, 30 Jul 2001 11:55:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Olafur Gudmundsson/DNSEXT co-chair To: agenda@ietf.org Cc: namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, Alain Durand , Olafur Gudmundsson Subject: Joint DNSEXT & NGTRANS agenda Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 30 Jul 2001 11:55:29 -0700 Content-Transfer-Encoding: 7bit 51 IETF DNSEXT NGTRANS Joint Meeting on IPv6 Addresses in DNS Monday 2001/Aug/6 15:30-17:30 Room: King's Suite/Balmoral 2 Chairs: Alain Durand (for NGTRANS) Olafur Gudmundsson (for DNSEXT) Goal: The goal of the joint meeting is to facilitate consensus on how IPv6 addresses are represented in DNS and related issues. This meeting requires extensive homework by participants. Background: Here is the list of material that have been submitted to the wg chairs and will be used during the discussion in London. Knowledge of those documents will be assumed in London, so we strongly encourage reading them all prior to the meeting! 1 Rob Austein: 2 Christian Huitema: 3 Matt Crawford: 4 Jun-ichiro itojun Hagino : 5 Dan Bernstein: For those who need it, a short introduction to DNSSEC can be found at: to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 30 16:02:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20323 for ; Mon, 30 Jul 2001 16:02:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15RHjy-0008Ax-00 for namedroppers-data@psg.com; Mon, 30 Jul 2001 11:26:06 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15RHjy-0008Ar-00 for namedroppers@ops.ietf.org; Mon, 30 Jul 2001 11:26:06 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15RHjx-000NdH-00 for namedroppers@ops.ietf.org; Mon, 30 Jul 2001 11:26:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Brian Wellington To: Jakob Schlyter Cc: Edward Lewis , , DNSEXT Subject: Re: restart: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 30 Jul 2001 11:26:06 -0700 Content-Transfer-Encoding: 7bit On Mon, 30 Jul 2001, Jakob Schlyter wrote: > On Sun, 29 Jul 2001, Brian Wellington wrote: > > > > the reason I like the nameserver to use the AD-bit, and only the AD-bit, > > > to signal that the data is authenticated cryptographically is simplicity. > > > I do not care about whether my nameserver is authorative or not - I only > > > care if it has validated the data or not. it could be authorative, yet the > > > zonefile could be invalid (e.g. the nameserver is secondary and doesn't > > > fully trust source). > > > > This is the problem. The stub resolver should not care whether the > > server has validated the data or not. If the resolver trusts the > > server, the server trusts the data, and the communication is secure, > > the resolver should trust the data. > > the stub resolver may care whether the server has validated the data or > not. if the servers hasn't validated the data, e.g. data data was never > protected by dnssec, it can choose not to trust it at all. Please reread the preceding paragraph, and the argument I've been making for the past week. The server should be able to avoid validating the data because it implicitly trusts the data. The stub resolver shouldn't care why the server trusts it; it should just care that it does. If it doesn't trust the server to properly set the AD on implicitly trusted data, it shouldn't believe the AD bit at all. > > I'd like to be able to sign my zone at home and use DNSSEC capable > > applications (like a modified SSH), without forcing my server to > > needlessly verify data that it either loads from disk or obtains > > through a secure zone transfer. > > the "only" disagreement here is whether you may set AD without doing any > cryptographic validation - on load (and checking for expired signatures on > reply) or on reply. Right. > I'd like a "MUST NOT set the AD bit without cryptographic validation", but > could go for a "SHOULD NOT" if that's the consensus of the WG. something > less stronger is to weak I believe. And I'd like the draft to stay as it is. I'll note (yet again) that it currently allows both the policy that I'm advocating and the policy that you're advocating. > how do we resolve this? it would be nice if we could continue to secure > the world instead of debating bits the headers :-) The draft has already been through last call several times, and has had only minor clarifications. It might have progressed along the standards process if people weren't trying to fundamentally change it now. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 31 11:00:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19680 for ; Tue, 31 Jul 2001 11:00:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Raaj-0007lC-00 for namedroppers-data@psg.com; Tue, 31 Jul 2001 07:33:49 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15Raaj-0007l4-00 for namedroppers@ops.ietf.org; Tue, 31 Jul 2001 07:33:49 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15Raaj-000KEY-00 for namedroppers@ops.ietf.org; Tue, 31 Jul 2001 07:33:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: bmanning@vacation.karoshi.com To: narten@raleigh.ibm.com (Thomas Narten) Cc: erik.guttman@sun.com, vixie@isc.org, bmanning@karoshi.com, randy@psg.com (Randy Bush), ogud@ogud.com (Olafur Gudmundsson), namedroppers@ops.ietf.org (namedroppers), Erik.Nordmark@eng.sun.com (Erik Nordmark) Subject: Re: draft-ymbk-opcode-discover-02.txt In-Reply-To: <200107311039.f6VAdIF04138@cichlid.adsl.duke.edu> from "Thomas Narten" at Jul 31, 2001 06:39:17 AM Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 31 Jul 2001 07:33:49 -0700 Content-Transfer-Encoding: 7bit Thank you for a prompt response. While the AD's did instruct the WG chairs that discussion could continue, the WG chairs have made no such statements to the list. As long as the prohibition is in force, it will be impossible to take this work to the DNSEXT wg and allow them to conside the work, as you suggest. If the prohibition is released, then the document, with boilerplate #2, can be considered by the WG to gauge their reaction as to its applicability. Once the WG determines that this really is work that would be in-scope (not to disparage the IESG & the DNSEXT chairs thoughts on this matter) then there will be no problem changing the boilerplate to give the IETF change control. Leaving the prohibition in place, and then recommending that it not be published w/o WG review places the work in limbo. > The RFC editor recently received a request to publish > draft-ymbk-opcode-discover-02.txt as an Experimental RFC. As with all > RFC submissions, the IESG was asked whether it related to on-going WG > activity and whether it was appropriate to publish the document at > this time. The IESG, in consultation with the DNSEXT chairs, has > recommended that it not be published at this time, as the document > clearly relates to work that would be in-scope for the DNSEXT WG. The > authors should take the document to the DNSEXT WG for further > consideration. > > Quoting from the document: > > > Per instructions from a chair of the IETF DNSEXT WG to the moderator of > > the namedropppers@ops.ietf.org mailing list, it is forbidden to discuss > > this draft on that list or in the context of that IETF working > > group. > > Per the June 19 note from the Internet ADs (appended below), this > document may be discussed on the namedroppers mailing list. However, > because the document has a non-derivative rights clause, and thus > doesn't give the IETF change control, the WG needs to be careful to > not invest significant resources on the document, so long as there is > question whether the WG has adequate change control rights over the > document. > > Note that there are at least two issues that need to be resolved > before this document can be published as an RFC. First, the WG needs > to agree that it is OK to publish the document based on its content. > Second, the non-derivative rights clause will likely have to be > removed in order to give the IETF change control over the > document. IETF change control is needed, if the IETF is ever to revise > the document, e.g., to fix bugs, clarify text, or put it on the > Standards Track. Thus, it is an open question whether the IESG should > ever support publication of this draft as an RFC if the IETF does not > retain change control. > > The quickest way to get past the above issues is to reissue the > document with Statement 1 boilerplate and build support for it within > the DNSEXT WG to publish the document. > > Thomas & Erik > > From: Thomas Narten > To: Robert Elz > cc: iesg@ietf.org, poised@lists.tislabs.com, > namedroppers , Randy Bush , > Olafur Gudmundsson > Date: Wed, 20 Jun 2001 07:53:30 -0400 > Subject: Re: Inactivity appeal > > The Internet ADs have reviewed the set of events related to the > posting of draft-ymbk-opcode-discover-01.txt to the namedroppers > mailing list and the subsequent decision to block discussion of the ID > on the namedroppers list. This note requests that discussion of the > draft resume on the WG mailing list and notes that one significant > issue with the document has apparently been rectified in the > just-submitted -02 ID. > > Background: > > On June 3, 2001, Bill Manning posted a message to the namedroppers > mailing list that included the entire contents of > draft-opcode-discover-01.txt. That ID contains boilerplate text that > includes the words: > > > This document is an Internet-Draft and is NOT offered in accordance > > with Section 10 of RFC2026, and the author does not provide the IETF > > with any rights other than to publish as an Internet-Draft. This > > document is a submission to the domain name system extentions > > (DNSEXT) working group of the Internet Engineering Task Force > > (IETF). > > At that time, the Internet and other ADs noted and discussed the > boilerplate text, and then pointed out to the WG chairs that a > document with such boilerplate was not appropriate for discussion on > an IETF WG mailing list. There main reason for this is: > > - The above boilerplate indicates that the contribution is not > subject to all the rules in Section 10 of RFC 2026. WGs should not > spend significant cycles on documents with such risks, lest they > invest cycles working on a technology for which IPR issues are > discovered at a later time that should have been disclosed > earlier. Furthermore, allowing significant WG discussion of such > documents raises serious issues as to whether the IETF is > following its own rules for openness. Such an issue could, for > example, adversly impact the IETF's insurance coverage. > > Consequently, the WG chairs were asked to limit discussion on the > document. In retrospect, the decision to prohibit all discussion of > the draft (e.g., including whether it was relevant to the WG) was too > strong. With this note, we request that that WG chairs allow > discussion of the draft on the WG mailing list, with the following > caveats. > > The document cannot become a WG document until/unless it is submitted > with boilerplate statement 1. Statement 2 & 3 boilerplates do not > grant the IETF/WG any rights to produce a followup ID, excerpt text, > modify text, etc., as is necessary for IETF WGs to do their work. Note > that there have been cases in the past where a document author has > included a restricted copyright clause in a document, had the WG > invest cycles in the ID, and then subsequently refused to make > specific changes requested by the WG, forcing the WG to rewrite a > document from scratch in order to avoid copyright infringement > issues. This can waste significant time and WG resources and should be > avoided. The Chairs and the WG should keep this in mind as discussion > takes place. > > The WG & WG chairs should note that with a statement 3 boilerplate, > the author is specifically disclaiming the need to adhere to the IPR > portions of section 10 of 2026. This is at odds with the IETF's own > stated rules for a WG contribution and is unacceptable for a document > for which there is a reasonable expectation that its contents might be > incorporated into a WG document. Discussion of such documents on IETF > mailing lists should be undertaken carefully and limited to a context > that takes into considerations the reasons why statement 3 boilerplate > was used and the limitations that implies. Note that the recent > submission of a -02 version of the document (posted 6/19/01) contains > a statement 2 boilerplate, apparently making the issue moot in this > particular case. > > Thomas & Erik > to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 31 11:00:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19690 for ; Tue, 31 Jul 2001 11:00:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15RaUD-0007cc-00 for namedroppers-data@psg.com; Tue, 31 Jul 2001 07:27:05 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15RaUC-0007cW-00 for namedroppers@ops.ietf.org; Tue, 31 Jul 2001 07:27:04 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15RaUC-000Jtg-00 for namedroppers@ops.ietf.org; Tue, 31 Jul 2001 07:27:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Thomas Narten To: erik.guttman@sun.com, vixie@isc.org, bmanning@karoshi.com cc: Randy Bush , Olafur Gudmundsson , namedroppers , Erik Nordmark Subject: draft-ymbk-opcode-discover-02.txt Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 31 Jul 2001 07:27:05 -0700 Content-Transfer-Encoding: 7bit The RFC editor recently received a request to publish draft-ymbk-opcode-discover-02.txt as an Experimental RFC. As with all RFC submissions, the IESG was asked whether it related to on-going WG activity and whether it was appropriate to publish the document at this time. The IESG, in consultation with the DNSEXT chairs, has recommended that it not be published at this time, as the document clearly relates to work that would be in-scope for the DNSEXT WG. The authors should take the document to the DNSEXT WG for further consideration. Quoting from the document: > Per instructions from a chair of the IETF DNSEXT WG to the moderator of > the namedropppers@ops.ietf.org mailing list, it is forbidden to discuss > this draft on that list or in the context of that IETF working > group. Per the June 19 note from the Internet ADs (appended below), this document may be discussed on the namedroppers mailing list. However, because the document has a non-derivative rights clause, and thus doesn't give the IETF change control, the WG needs to be careful to not invest significant resources on the document, so long as there is question whether the WG has adequate change control rights over the document. Note that there are at least two issues that need to be resolved before this document can be published as an RFC. First, the WG needs to agree that it is OK to publish the document based on its content. Second, the non-derivative rights clause will likely have to be removed in order to give the IETF change control over the document. IETF change control is needed, if the IETF is ever to revise the document, e.g., to fix bugs, clarify text, or put it on the Standards Track. Thus, it is an open question whether the IESG should ever support publication of this draft as an RFC if the IETF does not retain change control. The quickest way to get past the above issues is to reissue the document with Statement 1 boilerplate and build support for it within the DNSEXT WG to publish the document. Thomas & Erik From: Thomas Narten To: Robert Elz cc: iesg@ietf.org, poised@lists.tislabs.com, namedroppers , Randy Bush , Olafur Gudmundsson Date: Wed, 20 Jun 2001 07:53:30 -0400 Subject: Re: Inactivity appeal The Internet ADs have reviewed the set of events related to the posting of draft-ymbk-opcode-discover-01.txt to the namedroppers mailing list and the subsequent decision to block discussion of the ID on the namedroppers list. This note requests that discussion of the draft resume on the WG mailing list and notes that one significant issue with the document has apparently been rectified in the just-submitted -02 ID. Background: On June 3, 2001, Bill Manning posted a message to the namedroppers mailing list that included the entire contents of draft-opcode-discover-01.txt. That ID contains boilerplate text that includes the words: > This document is an Internet-Draft and is NOT offered in accordance > with Section 10 of RFC2026, and the author does not provide the IETF > with any rights other than to publish as an Internet-Draft. This > document is a submission to the domain name system extentions > (DNSEXT) working group of the Internet Engineering Task Force > (IETF). At that time, the Internet and other ADs noted and discussed the boilerplate text, and then pointed out to the WG chairs that a document with such boilerplate was not appropriate for discussion on an IETF WG mailing list. There main reason for this is: - The above boilerplate indicates that the contribution is not subject to all the rules in Section 10 of RFC 2026. WGs should not spend significant cycles on documents with such risks, lest they invest cycles working on a technology for which IPR issues are discovered at a later time that should have been disclosed earlier. Furthermore, allowing significant WG discussion of such documents raises serious issues as to whether the IETF is following its own rules for openness. Such an issue could, for example, adversly impact the IETF's insurance coverage. Consequently, the WG chairs were asked to limit discussion on the document. In retrospect, the decision to prohibit all discussion of the draft (e.g., including whether it was relevant to the WG) was too strong. With this note, we request that that WG chairs allow discussion of the draft on the WG mailing list, with the following caveats. The document cannot become a WG document until/unless it is submitted with boilerplate statement 1. Statement 2 & 3 boilerplates do not grant the IETF/WG any rights to produce a followup ID, excerpt text, modify text, etc., as is necessary for IETF WGs to do their work. Note that there have been cases in the past where a document author has included a restricted copyright clause in a document, had the WG invest cycles in the ID, and then subsequently refused to make specific changes requested by the WG, forcing the WG to rewrite a document from scratch in order to avoid copyright infringement issues. This can waste significant time and WG resources and should be avoided. The Chairs and the WG should keep this in mind as discussion takes place. The WG & WG chairs should note that with a statement 3 boilerplate, the author is specifically disclaiming the need to adhere to the IPR portions of section 10 of 2026. This is at odds with the IETF's own stated rules for a WG contribution and is unacceptable for a document for which there is a reasonable expectation that its contents might be incorporated into a WG document. Discussion of such documents on IETF mailing lists should be undertaken carefully and limited to a context that takes into considerations the reasons why statement 3 boilerplate was used and the limitations that implies. Note that the recent submission of a -02 version of the document (posted 6/19/01) contains a statement 2 boilerplate, apparently making the issue moot in this particular case. Thomas & Erik to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 31 11:04:44 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19960 for ; Tue, 31 Jul 2001 11:04:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15RajE-0007zv-00 for namedroppers-data@psg.com; Tue, 31 Jul 2001 07:42:36 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15RajD-0007zp-00 for namedroppers@ops.ietf.org; Tue, 31 Jul 2001 07:42:35 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15RajD-000Keb-00 for namedroppers@ops.ietf.org; Tue, 31 Jul 2001 07:42:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Olafur Gudmundsson/DNSEXT co-chair , namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, Alain Durand , ipng@sunroof.eng.sun.com Subject: Re: Joint DNSEXT & NGTRANS agenda In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 31 Jul 2001 07:42:36 -0700 Content-Transfer-Encoding: 7bit Date: Mon, 30 Jul 2001 11:55:29 -0700 From: Olafur Gudmundsson/DNSEXT co-chair Message-ID: | 51 IETF DNSEXT NGTRANS Joint Meeting on | IPv6 Addresses in DNS | | Monday 2001/Aug/6 15:30-17:30 | Room: King's Suite/Balmoral 2 I'm not going to be there, and thus didn't write a draft to speak about at the meeting (which the earlier request seemed to be about). I will make some comments about the 5 drafts (well, 4 drafts and a web page) that are to be considered though. Before I begin, I'd like to point out again that this issue really has nothing whatever to do with ngtrans - it should be being considered in the ipngwg rather than ngtrans. This issue has nothing specifically to do with transition arrangements (other than that a solution is needed so the transition can happen - but that is or was true of everything else related to IPv6 - the basic protocol doc might just as well have been done in ngtrans if that was the criteria). ngtrans should be concerning itself with those short term issues needed to allow the v4 internet to turn itself into the v6 internet. The result when that has finished should be what has been defined by the ipngwg, all the ngtrans issues should eventually simply vanish (eventually may be a long time away, that's OK). Nor is this really a dnsext issue - when the RR types were being defined that made sense, but it doesn't really any more. The question is just which RR type (which exists in the DNS definitions already) IPv6 should actually be using (not for the transition period, but forever). Once that decision is made, if ngtrans wants to map a path to get from where we are now, to the eventual end point, that's fine. But it really is a bit hard for ngtrans to plan a transition when the end point isn't yet fixed. | 1 Rob Austein: | This is an excellent analysis of the issues. (It also makes the point that this is really an ipv6 issue - ipngwg that is). About the only issue I have with it is the assumption that whether to use AAAA or A6 should be decided merely by the relative frequency of renumberings expected for IPv6 systems. One reason for not simply going that way, is that it is an issue upon which no-one really agrees. There are hopes, expectations, and dooms day scenarios, which all produce different expectations. Personally I have no idea how frequently IPv6 nets will renumber. What I am sure of however, is that I want to do everything possible to allow for renumberings to happen with the greatest possible ease, with the smallest possible notice, and the greatest possible frequency. Planning that way maximises the chances that we will actually end up with something which will work in the environment that develops - whether that means permanent addresses, and no renumbering at all for anything (ie: we manage to make the routing system deal with routing to arbitrary /128's), or if we end up in a state where major sites are expected to renumber four times a day as traffic patterns shift going to and from the work user and home user peak periods. | 2 Christian Huitema: | This is just a summary of what's involved in renumbering in some interesting cases. The draft is fine, but I'm not sure it adds a whole lot to the A6 vs AAAA debate. | 3 Matt Crawford: | I have nothing much to say about this one, other than that I essentially agree with all of it. | 4 Jun-ichiro itojun Hagino : | This one contains a bunch of info on the current state of the world, followed by a large amount of FUD. There's essentially nothing in it of value to the discussion. I could analyse this doc paragraph by paragraph, and was once planning to do so - but I think that would be a waste of everyone's time. | 5 Dan Bernstein: | And this one points out that with A6 it will be possible for sites to create ludicrous setups that won't work. Without A6 sites can create ludicrous setups that won't work, so there is nothing really new here. Just one extra way to shoot yourself in the foot. Big deal. What is missing in all of this is any real data upon which anyone could really base a decision. There's no comparisons of how many queries it will take to resolve names in various common cases, what the cache effectiveness can be expected to be, how much cache churn renumbering will cause, how big the DNS packets for various scenarios will actually be - nothing like this at all. The effect of that is that any decision on which way to go cannot be based upon any more than either guesswork or fear. I had hoped to have collected some data on all of this by now, but for various reasons it hasn't happened yet (even if it had, there wouldn't have been very much yet, so it probably still would have been premature to use it for much). I am still planning to (ie: actually doing the setup for now) collect some data, initially on A6 vs AAAA - that is, so see whether any extra round trips that are needed actually make a difference to name resolution for rationally configured setups (I'll also look at some irrational configurations of course). kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 31 15:32:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13820 for ; Tue, 31 Jul 2001 15:32:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Rdyq-000Ctc-00 for namedroppers-data@psg.com; Tue, 31 Jul 2001 11:10:56 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15Rdyp-000CtW-00 for namedroppers@ops.ietf.org; Tue, 31 Jul 2001 11:10:55 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15Rdyp-0004y3-00 for namedroppers@ops.ietf.org; Tue, 31 Jul 2001 11:10:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Olafur Gudmundsson/DNSEXT co-chair To: namedroppers@ops.ietf.org Subject: Discovery discussion restrictions NOT X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 31 Jul 2001 11:10:56 -0700 Content-Transfer-Encoding: 7bit For those who for some strange reason do not seem to notice that the discussion is taking place, with his message of June 19 Thomas Narten lifted the restrictions imposed on discussion on above draft by chair on June 5th. Olafur & Randy DNSEXT chairs to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 31 19:30:12 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03411 for ; Tue, 31 Jul 2001 19:30:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Riex-000JzB-00 for namedroppers-data@psg.com; Tue, 31 Jul 2001 16:10:43 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15Riex-000Jz3-00 for namedroppers@ops.ietf.org; Tue, 31 Jul 2001 16:10:43 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15Riex-000K0X-00 for namedroppers@ops.ietf.org; Tue, 31 Jul 2001 16:10:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Bill Manning To: ogud@ogud.com (Olafur Gudmundsson/DNSEXT co-chair) Cc: namedroppers@ops.ietf.org Subject: Re: Discovery discussion restrictions NOT In-Reply-To: from "Olafur Gudmundsson/DNSEXT co-chair" at Jul 31, 2001 11:10:56 AM X-Mailer: ELM [version 2.5 PL3] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 31 Jul 2001 16:10:43 -0700 Content-Transfer-Encoding: 7bit % % % For those who for some strange reason do not seem to notice that the % discussion is taking place, with his message of June 19 Thomas Narten % lifted the restrictions imposed on discussion on above draft by chair % on June 5th. % % Olafur & Randy DNSEXT chairs % % to unsubscribe send a message to namedroppers-request@ops.ietf.org with % the word 'unsubscribe' in a single line as the message text body. Thanks. There is an -02 version of the draft out. If there is interest by WG participants for taking this on as a WG item, I'd appreciate hearing about it. -- --bill to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 31 19:30:14 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03425 for ; Tue, 31 Jul 2001 19:30:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15RilJ-000K4m-00 for namedroppers-data@psg.com; Tue, 31 Jul 2001 16:17:17 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15RilI-000K4g-00 for namedroppers@ops.ietf.org; Tue, 31 Jul 2001 16:17:16 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15RilI-000KKf-00 for namedroppers@ops.ietf.org; Tue, 31 Jul 2001 16:17:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "D. J. Bernstein" To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: Joint DNSEXT & NGTRANS agenda References: <2914.996582086@brandenburg.cs.mu.OZ.AU> <200107202005.f6KK50F11379@gungnir.fnal.gov> <20010723140044.A17822@pianosa.catch22.org> <2261.996231603@brandenburg.cs.mu.OZ.AU> <20010729135707.10649.qmail@cr.yp.to> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 31 Jul 2001 16:17:17 -0700 Content-Transfer-Encoding: 7bit Robert Elz writes: > And this one points out that with A6 it will be possible for sites to > create ludicrous setups that won't work. In the aol.com example, the sysadmin sets up dns-01.ns.aol.com A6 ... prefix.aol.net, and similarly dns-02.ns.aol.com A6 ... prefix.aol.net. What's ``ludicrous'' about that? It's exactly what the A6 specifications encourage him to do. But it destroys connectivity to AOL. All the efficiency issues are minor. The reliability issues are crucial. The A6 proponents keep claiming that a limited form of A6 is safe, but they never answer when I ask them to identify the exact limitation that has this magical effect. How is the DNS administrator supposed to tell the difference between ``ludicrous'' A6 records and normal A6 records? > Without A6 sites can create ludicrous setups that won't work, so there > is nothing really new here. My web page explains three ways that A6 and DNAME lead to problems. ``These problems are not new,'' it says. But it then explains why the problems are under control now, and why they will spiral out of control with A6 and DNAME. My web page also analyzes the alleged benefits of A6 and DNAME. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 31 20:09:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA07145 for ; Tue, 31 Jul 2001 20:09:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15RilJ-000K4m-00 for namedroppers-data@psg.com; Tue, 31 Jul 2001 16:17:17 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15RilI-000K4g-00 for namedroppers@ops.ietf.org; Tue, 31 Jul 2001 16:17:16 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15RilI-000KKf-00 for namedroppers@ops.ietf.org; Tue, 31 Jul 2001 16:17:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "D. J. Bernstein" To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: Joint DNSEXT & NGTRANS agenda References: <2914.996582086@brandenburg.cs.mu.OZ.AU> <200107202005.f6KK50F11379@gungnir.fnal.gov> <20010723140044.A17822@pianosa.catch22.org> <2261.996231603@brandenburg.cs.mu.OZ.AU> <20010729135707.10649.qmail@cr.yp.to> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 31 Jul 2001 16:17:17 -0700 Content-Transfer-Encoding: 7bit Robert Elz writes: > And this one points out that with A6 it will be possible for sites to > create ludicrous setups that won't work. In the aol.com example, the sysadmin sets up dns-01.ns.aol.com A6 ... prefix.aol.net, and similarly dns-02.ns.aol.com A6 ... prefix.aol.net. What's ``ludicrous'' about that? It's exactly what the A6 specifications encourage him to do. But it destroys connectivity to AOL. All the efficiency issues are minor. The reliability issues are crucial. The A6 proponents keep claiming that a limited form of A6 is safe, but they never answer when I ask them to identify the exact limitation that has this magical effect. How is the DNS administrator supposed to tell the difference between ``ludicrous'' A6 records and normal A6 records? > Without A6 sites can create ludicrous setups that won't work, so there > is nothing really new here. My web page explains three ways that A6 and DNAME lead to problems. ``These problems are not new,'' it says. But it then explains why the problems are under control now, and why they will spiral out of control with A6 and DNAME. My web page also analyzes the alleged benefits of A6 and DNAME. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 31 22:23:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA16360 for ; Tue, 31 Jul 2001 22:23:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15RlWE-000Nfu-00 for namedroppers-data@psg.com; Tue, 31 Jul 2001 19:13:54 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15RlWD-000Nfo-00 for namedroppers@ops.ietf.org; Tue, 31 Jul 2001 19:13:53 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15RlWD-00034o-00 for namedroppers@ops.ietf.org; Tue, 31 Jul 2001 19:13:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Olafur Gudmundsson To: Masataka Ohta cc: namedroppers@ops.ietf.org Subject: Re: Discovery discussion restrictions NOT In-Reply-To: <200108010055.JAA11336@necom830.hpcl.titech.ac.jp> X-Sender: ogud@hlid.dc.ogud.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 31 Jul 2001 19:13:54 -0700 Content-Transfer-Encoding: 7bit On Wed, 1 Aug 2001, Masataka Ohta wrote: > Olafur; > > > For those who for some strange reason do not seem to notice that the > > discussion is taking place, with his message of June 19 Thomas Narten > > lifted the restrictions imposed on discussion on above draft by chair > > on June 5th. > > "above"? Which draft? > draft-ymbk--opcode-discover-02.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. From owner-namedroppers@ops.ietf.org Tue Jul 31 22:23:48 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA16378 for ; Tue, 31 Jul 2001 22:23:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15RlTa-000NcZ-00 for namedroppers-data@psg.com; Tue, 31 Jul 2001 19:11:10 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15RlTa-000NcS-00 for namedroppers@ops.ietf.org; Tue, 31 Jul 2001 19:11:10 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15RlTa-0002vt-00 for namedroppers@ops.ietf.org; Tue, 31 Jul 2001 19:11:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Masataka Ohta To: Olafur Gudmundsson/DNSEXT co-chair CC: namedroppers@ops.ietf.org Subject: Re: Discovery discussion restrictions NOT In-Reply-To: from Olafur Gudmundsson/DNSEXT co-chair at "Jul 31, 2001 11:10:56 am" X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 31 Jul 2001 19:11:10 -0700 Content-Transfer-Encoding: 7bit Olafur; > For those who for some strange reason do not seem to notice that the > discussion is taking place, with his message of June 19 Thomas Narten > lifted the restrictions imposed on discussion on above draft by chair > on June 5th. "above"? Which draft? Masataka Ohta to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 31 22:24:00 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA16392 for ; Tue, 31 Jul 2001 22:23:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15RlWm-000Ngz-00 for namedroppers-data@psg.com; Tue, 31 Jul 2001 19:14:28 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15RlWl-000Ngt-00 for namedroppers@ops.ietf.org; Tue, 31 Jul 2001 19:14:27 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15RlWl-00036g-00 for namedroppers@ops.ietf.org; Tue, 31 Jul 2001 19:14:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Olafur Gudmundsson To: Bill Manning cc: namedroppers@ops.ietf.org Subject: Re: Discovery discussion restrictions NOT In-Reply-To: <200107312310.f6VNAE404169@zed.isi.edu> X-Sender: ogud@hlid.dc.ogud.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 31 Jul 2001 19:14:28 -0700 Content-Transfer-Encoding: 7bit On Tue, 31 Jul 2001, Bill Manning wrote: > % For those who for some strange reason do not seem to notice that the > % discussion is taking place, with his message of June 19 Thomas Narten > % lifted the restrictions imposed on discussion on above draft by chair > % on June 5th. > % > % Olafur & Randy DNSEXT chairs > % > % to unsubscribe send a message to namedroppers-request@ops.ietf.org with > % the word 'unsubscribe' in a single line as the message text body. > > > Thanks. There is an -02 version of the draft out. > If there is interest by WG participants for taking this > on as a WG item, I'd appreciate hearing about it. draft-ymbk-opcode-discover-02.txt will be on the agenda with the other new documents asking for the same thing. 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.