From owner-namedroppers@ops.ietf.org Tue May 2 05:31:02 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26190 for ; Tue, 2 May 2000 05:31:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12mXbv-000LvC-00 for namedroppers-data@psg.com; Tue, 02 May 2000 01:00:51 -0700 Received: from citadel.cdsec.com ([192.96.22.18] helo=citadel.cequrux.com) by psg.com with esmtp (Exim 3.13 #1) id 12mXbq-000Lv6-00 for namedroppers@ops.ietf.org; Tue, 02 May 2000 01:00:49 -0700 Received: (from nobody@localhost) by citadel.cequrux.com (8.9.3/8.9.3) id KAA18397 for ; Tue, 2 May 2000 10:00:38 +0200 (SAST) Received: by citadel.cequrux.com via recvmail id 18318; Tue May 2 09:59:41 2000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <390E3E21.9EC6C90C@cequrux.com> Date: Mon, 01 May 2000 19:32:01 -0700 From: Terry Lambert To: namedroppers@ops.ietf.org Subject: Unfinished DNS UPDATE work... Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit RFC 2136 says: | 7.6. It is not possible to create a zone using this protocol, | since there is no provision for a slave server to be told who | its master servers are. It is expected that this protocol | will be extended in the future to cover this case. Therefore, | at this time, the addition of SOA RRs is unsupported. For | similar reasons, deletion of SOA RRs is also unsupported. It seems to me that it's about time to tackle this work; is anyone else interested in this as well? BTW: The rationale here seems a bit thin; there's no reason that, for example, the master can't be updated to add or delete an SOA. The only loser on this is the slave. Of course, if SOA updates to slaves resulted in the slave doing a search-from-root to auto-detect the master, that would work; alternately, a "push" relationship could be established, where the master notifies the slave, and because of this, the slave saves off the source of the notification. This would work for all slaves for which there were NS records specified in the master. Or something else could happen, and that would be like a DNS update, too... the point is to start talking about the problem. -- Terry Lambert -- Whistle Communications, Inc., an I.B.M. Company -- terry@whistle.com ------------------------------------------------------------------- This is formal notice under California Assembly Bill 1629, enacted 9/26/98 that any UCE sent to my email address will be billed $50 per incident to the legally allowed maximum of $25,000. to unsubscribe send a message to 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 May 2 14:58:44 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07288 for ; Tue, 2 May 2000 14:58:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12mgxN-000DAw-00 for namedroppers-data@psg.com; Tue, 02 May 2000 10:59:37 -0700 Received: from dhcp239.ws.afnog.org ([137.158.216.239] helo=dhcp117.cequrux.com) by psg.com with esmtp (Exim 3.13 #1) id 12mgxI-000DAC-00 for namedroppers@ops.ietf.org; Tue, 02 May 2000 10:59:37 -0700 Received: from randy by dhcp117.cequrux.com with local (Exim 3.12 #1) id 12mgx8-0003cm-00 for namedroppers@ops.ietf.org; Tue, 02 May 2000 19:59:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200005021655.JAA69559@redpaul.mibh.net> To: namedroppers@ops.ietf.org Subject: Re: Unfinished DNS UPDATE work... In-reply-to: Your message of "Mon, 01 May 2000 19:32:01 PDT." <390E3E21.9EC6C90C@cequrux.com> Date: Tue, 02 May 2000 09:55:43 -0700 From: Paul A Vixie Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > | 7.6. It is not possible to create a zone using this protocol, > | since there is no provision for a slave server to be told who > | its master servers are. It is expected that this protocol > | will be extended in the future to cover this case. Therefore, > | at this time, the addition of SOA RRs is unsupported. For > | similar reasons, deletion of SOA RRs is also unsupported. > > BTW: The rationale here seems a bit thin; there's no reason > that, for example, the master can't be updated to add or > delete an SOA. The only loser on this is the slave. we can't let zone owners commandeer other folks' slaves. so the thing we'd have to do is form a secure relationship between a master and each slave. the security of that relationship can be out of band, or in-band, either of which is a far more difficult problem to solve than "what update transactions would create a new 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 Tue May 2 23:54:50 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14405 for ; Tue, 2 May 2000 23:54:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12mp55-0004TK-00 for namedroppers-data@psg.com; Tue, 02 May 2000 19:40:07 -0700 Received: from dhcp239.ws.afnog.org ([137.158.216.239] helo=dhcp117.cequrux.com) by psg.com with esmtp (Exim 3.13 #1) id 12mp52-0004Sw-00 for namedroppers@ops.ietf.org; Tue, 02 May 2000 19:40:05 -0700 Received: from randy by dhcp117.cequrux.com with local (Exim 3.12 #1) id 12mp4n-0004D2-00 for namedroppers@ops.ietf.org; Wed, 03 May 2000 04:39:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <200005021655.JAA69559@redpaul.mibh.net> References: Your message of "Mon, 01 May 2000 19:32:01 PDT." <390E3E21.9EC6C90C@cequrux.com> Date: Tue, 2 May 2000 15:42:17 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: Unfinished DNS UPDATE work... Cc: lewis@tislabs.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit While this sounds like an(other) interesting area to work on, IMHO, this should wait until the current updates to DNS settle down. (E.g., DNSSEC, IPv6, EDNS0.) At 12:55 PM -0400 5/2/00, Paul A Vixie wrote: Quoting someone else, who is quoting a document: >> | 7.6. It is not possible to create a zone using this protocol, >> | since there is no provision for a slave server to be told who >> | its master servers are. It is expected that this protocol >> | will be extended in the future to cover this case. Therefore, >> | at this time, the addition of SOA RRs is unsupported. For >> | similar reasons, deletion of SOA RRs is also unsupported. >> >> BTW: The rationale here seems a bit thin; there's no reason >> that, for example, the master can't be updated to add or >> delete an SOA. The only loser on this is the slave. > >we can't let zone owners commandeer other folks' slaves. so the >thing we'd have to do is form a secure relationship between a master >and each slave. the security of that relationship can be out of band, >or in-band, either of which is a far more difficult problem to solve >than "what update transactions would create a new zone?" -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "It takes years of training to know when to do nothing" - Dogbert 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 May 2 23:59:06 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14430 for ; Tue, 2 May 2000 23:59:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12mp7A-0004X3-00 for namedroppers-data@psg.com; Tue, 02 May 2000 19:42:16 -0700 Received: from dhcp239.ws.afnog.org ([137.158.216.239] helo=dhcp117.cequrux.com) by psg.com with esmtp (Exim 3.13 #1) id 12mp77-0004Ws-00 for namedroppers@ops.ietf.org; Tue, 02 May 2000 19:42:14 -0700 Received: from randy by dhcp117.cequrux.com with local (Exim 3.12 #1) id 12mp79-0004DC-00 for namedroppers@ops.ietf.org; Wed, 03 May 2000 04:42:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <390F371C.9174E4@whistle.com> Date: Tue, 02 May 2000 13:14:20 -0700 From: Terry Lambert To: Paul A Vixie CC: namedroppers@ops.ietf.org Subject: Re: Unfinished DNS UPDATE work... References: <200005021655.JAA69559@redpaul.mibh.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul A Vixie wrote: > > | 7.6. It is not possible to create a zone using this protocol, > > | since there is no provision for a slave server to be told who > > | its master servers are. It is expected that this protocol > > | will be extended in the future to cover this case. Therefore, > > | at this time, the addition of SOA RRs is unsupported. For > > | similar reasons, deletion of SOA RRs is also unsupported. > > > > BTW: The rationale here seems a bit thin; there's no reason > > that, for example, the master can't be updated to add or > > delete an SOA. The only loser on this is the slave. > > we can't let zone owners commandeer other folks' slaves. > so the thing we'd have to do is form a secure relationship > between a master and each slave. the security of that > relationship can be out of band, or in-band, either of > which is a far more difficult problem to solve than "what > update transactions would create a new zone?" Right now, my primary concern is the creation of new zones on a large DNS, so as to minimize the downtime while the thing is reloading. If I can create a zone with DNSUPDAT, then I can have zero downtime on the master, whereas right now I have up to several minutes of downtime during the reload during which the server is unresponsive to requests (this is annoying because I have active checks for the server being alive which result in people getting paged, but that's my process definition problem to solve, and not the group's problem; I'm more concerned with the downtime, but that's probably because I'm not the one being paged). The slave issues would, I think, be handled by whether or not the DNSUPDAT was permitted for the master. Clearly, as you point out, a slave with a relationship with several masters would have a problem with this. I think this could be handled in a gross sense by using one of the previously suggested techniques, and then permitting the master to update or not based on syntactic sugar that is associated with the credentials. The default would be the current "ignore the update request" behaviour we see for both the master and the slaves. This would presumably go in as an option in the "options" section. Is there a particular security reason that creation of zones in a master server via DNSUPDAT should not be permitted? All of the rationale appears to be aimed at the long standing issue of how to inform a slave of its slave status in regard to a newly defined zone in a master for which the slave is supposed to zone transfer. That is, the historical master/slave relationship issues which arise when one wants to decouple a master and a slave such that a slave is not necessarily a slave for every zone for which the master is the master, and so on. Thanks, -- Terry Lambert -- Whistle Communications, Inc., an I.B.M. Company -- terry@whistle.com ------------------------------------------------------------------- This is formal notice under California Assembly Bill 1629, enacted 9/26/98 that any UCE sent to my email address will be billed $50 per incident to the legally allowed maximum of $25,000. to unsubscribe send a message to 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 May 3 00:06:17 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14514 for ; Wed, 3 May 2000 00:06:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12mpNX-0005SW-00 for namedroppers-data@psg.com; Tue, 02 May 2000 19:59:11 -0700 Received: from dhcp239.ws.afnog.org ([137.158.216.239] helo=dhcp117.cequrux.com) by psg.com with esmtp (Exim 3.13 #1) id 12mpNV-0005SB-00 for namedroppers@ops.ietf.org; Tue, 02 May 2000 19:59:10 -0700 Received: from randy by dhcp117.cequrux.com with local (Exim 3.12 #1) id 12mpNO-0004Ee-00 for namedroppers@ops.ietf.org; Wed, 03 May 2000 04:59:02 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200005022344.QAA12843@toad.com> To: namedroppers@ops.ietf.org, gnu@toad.com Subject: Re: Unfinished DNS UPDATE work... In-reply-to: <200005021655.JAA69559@redpaul.mibh.net> Date: Tue, 02 May 2000 16:44:10 -0700 From: John Gilmore Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > BTW: The rationale here seems a bit thin; there's no reason > > that, for example, the master can't be updated to add or > > delete an SOA. The only loser on this is the slave. > > we can't let zone owners commandeer other folks' slaves. so the > thing we'd have to do is form a secure relationship between a master > and each slave. the security of that relationship can be out of band, > or in-band, either of which is a far more difficult problem to solve > than "what update transactions would create a new zone?" A zone could be created by dynamic update on the master, including NS records that refer to slaves. If the master sends a notification to the slaves, they can each make their own decision about whether to begin serving the zone. These can be relayed back to the originator of the update, who could then modify the zone if desired. A config file for slave servers that lets the user say, e.g.: * Become a slave for any zone served by ns.i-am-an-isp.com * Become a slave for any zone under the mycompany.com domain * Become a slave for any zone under 140.144.in-addr.arpa. * Become a slave for ... * Reject all other new-zone notifications would provide easy to configure pre-authorization for a large fraction of users. John to unsubscribe send a message to 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 May 3 00:08:12 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14406 for ; Tue, 2 May 2000 23:54:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12mp7S-0004XM-00 for namedroppers-data@psg.com; Tue, 02 May 2000 19:42:34 -0700 Received: from dhcp239.ws.afnog.org ([137.158.216.239] helo=dhcp117.cequrux.com) by psg.com with esmtp (Exim 3.13 #1) id 12mp7Q-0004XF-00 for namedroppers@ops.ietf.org; Tue, 02 May 2000 19:42:33 -0700 Received: from randy by dhcp117.cequrux.com with local (Exim 3.12 #1) id 12mp7U-0004DJ-00 for namedroppers@ops.ietf.org; Wed, 03 May 2000 04:42:36 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <390F394E.CED1B055@daimlerchrysler.com> Date: Tue, 02 May 2000 16:23:42 -0400 From: Kevin Darcy To: namedroppers@ops.ietf.org Subject: Re: Unfinished DNS UPDATE work... References: <200005021655.JAA69559@redpaul.mibh.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul A Vixie wrote: > > | 7.6. It is not possible to create a zone using this protocol, > > | since there is no provision for a slave server to be told who > > | its master servers are. It is expected that this protocol > > | will be extended in the future to cover this case. Therefore, > > | at this time, the addition of SOA RRs is unsupported. For > > | similar reasons, deletion of SOA RRs is also unsupported. > > > > BTW: The rationale here seems a bit thin; there's no reason > > that, for example, the master can't be updated to add or > > delete an SOA. The only loser on this is the slave. > > we can't let zone owners commandeer other folks' slaves. so the > thing we'd have to do is form a secure relationship between a master > and each slave. the security of that relationship can be out of band, > or in-band, either of which is a far more difficult problem to solve > than "what update transactions would create a new zone?" I'm not sure what you mean by "commandeer". Can a server not check delegations and/or the zone SOA to verify that the entity which is requesting a master-slave relationship isn't just some random pirate? - 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 May 3 03:40:34 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27244 for ; Wed, 3 May 2000 03:40:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12mtIA-000IAg-00 for namedroppers-data@psg.com; Wed, 03 May 2000 00:09:54 -0700 Received: from dhcp239.ws.afnog.org ([137.158.216.239] helo=dhcp117.cequrux.com) by psg.com with esmtp (Exim 3.13 #1) id 12mtI8-000IAU-00 for namedroppers@ops.ietf.org; Wed, 03 May 2000 00:09:53 -0700 Received: from randy by dhcp117.cequrux.com with local (Exim 3.12 #1) id 12mtI9-0004Xr-00 for namedroppers@ops.ietf.org; Wed, 03 May 2000 09:09:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: terry@whistle.com Cc: vixie@mibh.net, namedroppers@ops.ietf.org Subject: Re: Unfinished DNS UPDATE work... From: sthaug@nethelp.no In-Reply-To: Your message of "Tue, 02 May 2000 13:14:20 -0700" References: <390F371C.9174E4@whistle.com> Date: Wed, 03 May 2000 08:04:42 +0200 Message-ID: <45083.957333882@verdi.nethelp.no> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Right now, my primary concern is the creation of new zones > on a large DNS, so as to minimize the downtime while the > thing is reloading. Have you tried ndc reconfig, instead of ndc reload? The difference can be dramatic if you have thousands of zones... Steinar Haug, Nethelp consulting, sthaug@nethelp.no to unsubscribe send a message to 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 May 3 03:50:22 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27293 for ; Wed, 3 May 2000 03:50:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12mtFZ-000I1t-00 for namedroppers-data@psg.com; Wed, 03 May 2000 00:07:13 -0700 Received: from dhcp239.ws.afnog.org ([137.158.216.239] helo=dhcp117.cequrux.com) by psg.com with esmtp (Exim 3.13 #1) id 12mtFX-000I1k-00 for namedroppers@ops.ietf.org; Wed, 03 May 2000 00:07:12 -0700 Received: from randy by dhcp117.cequrux.com with local (Exim 3.12 #1) id 12mtFY-0004Xf-00 for namedroppers@ops.ietf.org; Wed, 03 May 2000 09:07:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Terry Lambert Cc: namedroppers@internic.net Subject: Re: Unfinished DNS UPDATE work... In-Reply-To: Your message of "Tue, 02 May 2000 13:14:20 MST." <390F371C.9174E4@whistle.com> Date: Wed, 03 May 2000 15:37:03 +1000 Message-Id: <23529.957332223@mundamutti.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Tue, 02 May 2000 13:14:20 -0700 From: Terry Lambert Message-ID: <390F371C.9174E4@whistle.com> | Right now, my primary concern is the creation of new zones | on a large DNS, so as to minimize the downtime while the | thing is reloading. This looks like a request for the software you're running to have a "create a zone" interface. Aside from your software (apparently) having DDNS which does much the same function (updates the server dynamically), I don't see the relationship. Would not just an administrative command to your server "create zone X using the data in the new zone file x" be a more appropriate way to solve the problem you're referring to? And I know the problem well, it takes munnari over 15 minutes to become responsive again if its nameserver has to restart, or do a large reload. 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 May 3 04:03:18 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27422 for ; Wed, 3 May 2000 04:03:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12mtTq-000IOh-00 for namedroppers-data@psg.com; Wed, 03 May 2000 00:21:58 -0700 Received: from dhcp239.ws.afnog.org ([137.158.216.239] helo=dhcp117.cequrux.com) by psg.com with esmtp (Exim 3.13 #1) id 12mtTm-000IOb-00 for namedroppers@ops.ietf.org; Wed, 03 May 2000 00:21:56 -0700 Received: from randy by dhcp117.cequrux.com with local (Exim 3.12 #1) id 12mtTn-0004Z3-00 for namedroppers@ops.ietf.org; Wed, 03 May 2000 09:21:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.1.2.20000503085923.0138ca70@dokka.kvatro.no> Date: Wed, 03 May 2000 09:08:25 +0200 To: John Gilmore , namedroppers@ops.ietf.org, gnu@toad.com From: Harald Tveit Alvestrand Subject: Re: Unfinished DNS UPDATE work... In-Reply-To: <200005022344.QAA12843@toad.com> References: <200005021655.JAA69559@redpaul.mibh.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 16:44 02.05.2000 -0700, John Gilmore wrote: >A zone could be created by dynamic update on the master, including NS >records that refer to slaves. If the master sends a notification to >the slaves, they can each make their own decision about whether to >begin serving the zone. These can be relayed back to the originator >of the update, who could then modify the zone if desired. > >A config file for slave servers that lets the user say, e.g.: > > * Become a slave for any zone served by ns.i-am-an-isp.com > * Become a slave for any zone under the mycompany.com domain > * Become a slave for any zone under 140.144.in-addr.arpa. > * Become a slave for ... > * Reject all other new-zone notifications > >would provide easy to configure pre-authorization for a large fraction >of users. this seems to me an area where experimentation could be encouraged without significant harm to the Internet. that is: - if someone comments out the lines in BIND that refuse to create a SOA record using DNSUPDATE, you have a working master, with no harm to the rest of the network - if someone hacks a BIND (or something else) to do intelligent things when getting a NOTIFY for a zone that it is not currently a slave for, we have a working slave, with no harm to the rest of the network - if someone writes up exactly what protocol changes needed to be made (if any), and what the operational problems were (including the case where the slave is misconfigured to not allow an authorized master to update, and how to detect that case at the master side), we have proof of running code (and perhaps reasons not to do it). at the moment, it seems to me that a signed NOTIFY is required for this to make sense, but don't know if NOTIFY contains the required information or if it can be signed in the Right Way so that configuration is easy at the slave side, or if the sig on the NS in the notified zone is the Right Thing to check instead. (BTW, one of the NORID - .no naming authority - nameservers is secondary for a couple of thousand zones. Such a scheme would greatly lessen the administrative overhead of providing that service, but some kind of limit would have to be in place - it probably could not handle being secondary for a million zones) Harald -- Harald Tveit Alvestrand, EDB Maxware, Norway Harald.Alvestrand@edb.maxware.no to unsubscribe send a message to 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 May 3 13:40:35 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07290 for ; Wed, 3 May 2000 13:40:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12n21U-000Od8-00 for namedroppers-data@psg.com; Wed, 03 May 2000 09:29:16 -0700 Received: from dhcp239.ws.afnog.org ([137.158.216.239] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 12n21S-000Ocp-00 for namedroppers@ops.ietf.org; Wed, 03 May 2000 09:29:15 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12n21e-0000BW-00 for namedroppers@ops.ietf.org; Wed, 03 May 2000 18:29:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <3.0.32.20000503114559.00fb47e8@odie.av8.com> Date: Wed, 03 May 2000 11:59:40 -0400 To: Kevin Darcy , namedroppers@ops.ietf.org From: Dean Anderson Subject: Re: Unfinished DNS UPDATE work... Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Around 04:23 PM 5/2/2000 -0400, rumor has it that Kevin Darcy said: >I'm not sure what you mean by "commandeer". Can a server not check >delegations and/or the zone SOA to verify that the entity which is >requesting a master-slave relationship isn't just some random pirate? If a zone is created dynamicly, then no. At least, as has been discussed. But I think you suggest that perhaps it might be reasonable for the server to permit masters for which the server has staticly configured slave zones to create zones. Then there is already a prexisting master/slave relationship for some zone, and it seems reasonable one might slave for other zones from the same master server. This avoids the need for a complicated additional trust exchange protocol. I can't see why you would ever have a slave server without any staticly configured slave zones, so such a relationship either already exists, or the update is from a random pirate, and should be denied. --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean@av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.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 May 3 15:04:29 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09166 for ; Wed, 3 May 2000 15:04:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12n3nb-0000GG-00 for namedroppers-data@psg.com; Wed, 03 May 2000 11:23:03 -0700 Received: from [137.158.216.239] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 12n3nX-0000Fx-00 for namedroppers@ops.ietf.org; Wed, 03 May 2000 11:23:00 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12n3n9-0000II-00 for namedroppers@ops.ietf.org; Wed, 03 May 2000 20:22:35 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39105DBB.9E853747@whistle.com> Date: Wed, 03 May 2000 10:11:23 -0700 From: Terry Lambert To: Robert Elz CC: namedroppers@internic.net Subject: Re: Unfinished DNS UPDATE work... References: <23529.957332223@mundamutti.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Robert Elz wrote: > | Right now, my primary concern is the creation of new zones > | on a large DNS, so as to minimize the downtime while the > | thing is reloading. > > This looks like a request for the software you're running > to have a "create a zone" interface. Aside from your > software (apparently) having DDNS which does much the same > function (updates the server dynamically), I don't see the > relationship. The RFC definiting DDNS explicitly calls out for future work to define this capability. > Would not just an administrative command to your server > "create zone X using the data in the new zone file x" be > a more appropriate way to solve the problem you're > referring to? The "administrative interface" I would have for this is: vi db/named.noc ... add the new zone ... cvs ci db/named.noc kill -HUP `cat named.pid` If I have to define a new interface to do this, it might as well be in the context of the future work called out in the DDNS RFC, and become standard, instead of being a private interface I kludge for my own purposes. > And I know the problem well, it takes munnari over 15 > minutes to become responsive again if its nameserver has > to restart, or do a large reload. Do you use a private interface for zone creation? What software are you using? Mine is ISC bind; as far as I can tell, it has no such interface. As I said: I would prefer that the interface be standard, instead of being a figment of my imagination which my firewall administration refuses to buy into. Also as I said: I still don't see the rationale for denying SOA creation via DDNS in masters. I'd be happy to group this corner case in with the slave update problem and tackle it at the same time, if someone could provide some real reason that permitting zone creation in a master can cause problems. I know that I can kludge this by making the software do a periodic stat of the config files it has read, and do an incremental reload, if the dates have changed. But one of my issues is that I am making heavy use of DDNS at this point, so monotonically increasing serial numbers become an issue. That's an implementation detail that belongs in DNSOPS, though, and is seperate from the DDNS zone creation issue. -- Terry Lambert -- Whistle Communications, Inc., an I.B.M. Company -- terry@whistle.com ------------------------------------------------------------------- This is formal notice under California Assembly Bill 1629, enacted 9/26/98 that any UCE sent to my email address will be billed $50 per incident to the legally allowed maximum of $25,000. to unsubscribe send a message to 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 May 3 22:57:26 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16098 for ; Wed, 3 May 2000 22:57:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12nB83-000CV6-00 for namedroppers-data@psg.com; Wed, 03 May 2000 19:12:39 -0700 Received: from [137.158.216.239] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 12nB7w-000CSp-00 for namedroppers@ops.ietf.org; Wed, 03 May 2000 19:12:33 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12nB7e-0000oW-00 for namedroppers@ops.ietf.org; Thu, 04 May 2000 04:12:14 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <391074CB.CD47DBB2@whistle.com> Date: Wed, 03 May 2000 11:49:47 -0700 From: Terry Lambert To: Dean Anderson CC: Kevin Darcy , namedroppers@ops.ietf.org Subject: Re: Unfinished DNS UPDATE work... References: <3.0.32.20000503114559.00fb47e8@odie.av8.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit All in all, a lot of productive comments and thought, which is exactly what I had hoped would happen! It seems it may be time for some experimentation on the side, but we should keep the discussion going, so here's a couple more comments: Harald Tveit Alvestrand wrote (commenting on John Gilmore's note): [ ... ] > at the moment, it seems to me that a signed NOTIFY is > required for this to make sense, but don't know if NOTIFY > contains the required information or if it can be signed > in the Right Way so that configuration is easy at the > slave side, or if the sig on the NS in the notified zone > is the Right Thing to check instead. One caveat: DDNS doesn't currently require signatures, since you are permitted to statically configure access control lists. This same mechanism could be used, in lieu of signatures, to provide the capability. Dean Anderson wrote: > Around 04:23 PM 5/2/2000 -0400, rumor has it that Kevin > Darcy said: > >I'm not sure what you mean by "commandeer". Can a server > >not check delegations and/or the zone SOA to verify that > >the entity which is requesting a master-slave relationship > >isn't just some random pirate? > > If a zone is created dynamicly, then no. At least, as has > been discussed. > > But I think you suggest that perhaps it might be reasonable > for the server to permit masters for which the server has > staticly configured slave zones to create zones. > > Then there is already a prexisting master/slave relationship > for some zone, and it seems reasonable one might slave for > other zones from the same master server. In fact, one could statically establish this relationship, e.g. "I am the slave for at least one zone from this master", by configuring the slave as a [stealth] slave of the master's own zone, assuming it's self hosting, or any one zone, in the unlikely case that it is not. > This avoids the need for a complicated additional trust > exchange protocol. > > I can't see why you would ever have a slave server without > any staticly configured slave zones, so such a relationship > either already exists, or the update is from a random pirate, > and should be denied. I can see several cases where this might not be something that would be configured. I think that you could adapt John Gilmore's excellent suggestion to cover this case, though, by permitting the NOTIFY-based-create in the options section of the slave, without requiring a zone be preconfigured. One could imagine an "empty" slave being populated by a master using the "NOTIFY to create SOA in case of NS record specified to master" to trigger the notify by the master to the slave. If we didn't use the ACL method, but instead used the preestablished relationship method to control this, we could do this merely by configuring the slave as a stealth slave for one zone, thus permitting non-stealth zones to be configured by master NOTIFY events. I think it's now time for me to start grovelling through the relevent RFCs for NOTIFY, and to see what it would take to ACL at least SOA creation on the master by way of the options configuration, instead of the assumption of a preexisting SOA for the zone being modified... maybe the code can also be directly applied to the slave, as well, if it's done right. -- Terry Lambert -- Whistle Communications, Inc., an I.B.M. Company -- terry@whistle.com ------------------------------------------------------------------- This is formal notice under California Assembly Bill 1629, enacted 9/26/98 that any UCE sent to my email address will be billed $50 per incident to the legally allowed maximum of $25,000. to unsubscribe send a message to 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 May 3 23:00:08 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16120 for ; Wed, 3 May 2000 23:00:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12nBH6-000CqT-00 for namedroppers-data@psg.com; Wed, 03 May 2000 19:22:00 -0700 Received: from [137.158.216.239] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 12nBH3-000CqJ-00 for namedroppers@ops.ietf.org; Wed, 03 May 2000 19:21:58 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12nBGq-0000pP-00 for namedroppers@ops.ietf.org; Thu, 04 May 2000 04:21:44 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <053c01bfb535$80afc400$7cc2a8ce@WALTERB> From: "Cricket Liu" To: "Kevin Darcy" , , "Dean Anderson" References: <3.0.32.20000503114559.00fb47e8@odie.av8.com> Subject: Re: Unfinished DNS UPDATE work... Date: Wed, 3 May 2000 13:26:37 -0600 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Around 04:23 PM 5/2/2000 -0400, rumor has it that Kevin Darcy said: > >I'm not sure what you mean by "commandeer". Can a server not check > >delegations and/or the zone SOA to verify that the entity which is > >requesting a master-slave relationship isn't just some random pirate? > > If a zone is created dynamicly, then no. At least, as has been discussed. > > But I think you suggest that perhaps it might be reasonable for the server > to permit masters for which the server has staticly configured slave zones > to create zones. Or simply add a new server substatement like: server 192.168.0.1 { allow-add-slave-zones yes; keys { foo-bar.; }; }; Using TSIG to authenticate powerful mechanisms like this would be a good idea, I think. > Then there is already a prexisting master/slave relationship for some zone, > and it seems reasonable one might slave for other zones from the same > master server. I'd rather define that on a master-by-master basis. > This avoids the need for a complicated additional trust exchange protocol. > > I can't see why you would ever have a slave server without any staticly > configured slave zones, so such a relationship either already exists, or > the update is from a random pirate, and should be denied. There's the much-sought-after "slave for all zones this primary master is authoritative for." It'd be nice to bootstrap a new slave with just a server statement like the above. cricket to unsubscribe send a message to 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 May 4 04:32:31 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01063 for ; Thu, 4 May 2000 04:32:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12nGAQ-000P2d-00 for namedroppers-data@psg.com; Thu, 04 May 2000 00:35:26 -0700 Received: from citadel.cdsec.com ([192.96.22.18] helo=citadel.cequrux.com) by psg.com with esmtp (Exim 3.13 #1) id 12nGAI-000P2V-00 for namedroppers@ops.ietf.org; Thu, 04 May 2000 00:35:24 -0700 Received: (from nobody@localhost) by citadel.cequrux.com (8.9.3/8.9.3) id JAA02878 for ; Thu, 4 May 2000 09:35:13 +0200 (SAST) Received: by citadel.cequrux.com via recvmail id 2872; Thu May 4 09:35:12 2000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.1.2.20000504073728.057218d0@cequrux.com> Date: Thu, 04 May 2000 08:07:44 +0200 To: Terry Lambert , Dean Anderson From: Harald Tveit Alvestrand Subject: Re: Unfinished DNS UPDATE work... Cc: Kevin Darcy , namedroppers@ops.ietf.org In-Reply-To: <391074CB.CD47DBB2@whistle.com> References: <3.0.32.20000503114559.00fb47e8@odie.av8.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 11:49 03.05.2000 -0700, Terry Lambert wrote: >Harald Tveit Alvestrand wrote (commenting on John Gilmore's note): >[ ... ] > > at the moment, it seems to me that a signed NOTIFY is > > required for this to make sense, but don't know if NOTIFY > > contains the required information or if it can be signed > > in the Right Way so that configuration is easy at the > > slave side, or if the sig on the NS in the notified zone > > is the Right Thing to check instead. > >One caveat: DDNS doesn't currently require signatures, >since you are permitted to statically configure access >control lists. This same mechanism could be used, in >lieu of signatures, to provide the capability. What are ACLs usually based on? If you're using source IP as an authenticator for a connectionless, no-handshake protocol, I've got a great bridge to sell you..... from RFC 2136 (Dynamic Update): 8 - Security Considerations 8.1. In the absence of [RFC2137] or equivilent technology, the protocol described by this document makes it possible for anyone who can reach an authoritative name server to alter the contents of any zones on that server. This is a serious increase in vulnerability from the current technology. Therefore it is very strongly recommended that the protocols described in this document not be used without [RFC2137] or other equivalently strong security measures, e.g. IPsec. Source IP + requirement that MAC is on the local wire mostly works as a defense against the outside bogons, if you can swing it, I think. (Against the insider there are few good non-cryptographic defenses). But this is not a common case for zone-transfer stuff. Harald -- Harald Tveit Alvestrand, EDB Maxware, Norway Harald.Alvestrand@edb.maxware.no to unsubscribe send a message to 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 May 4 06:51:15 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02109 for ; Thu, 4 May 2000 06:51:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12nIfl-0000sN-00 for namedroppers-data@psg.com; Thu, 04 May 2000 03:15:57 -0700 Received: from citadel.cdsec.com ([192.96.22.18] helo=citadel.cequrux.com) by psg.com with esmtp (Exim 3.13 #1) id 12nIfi-0000sF-00 for namedroppers@ops.ietf.org; Thu, 04 May 2000 03:15:56 -0700 Received: (from nobody@localhost) by citadel.cequrux.com (8.9.3/8.9.3) id MAA13020 for ; Thu, 4 May 2000 12:15:49 +0200 (SAST) Received: by citadel.cequrux.com via recvmail id 12942; Thu May 4 12:14:46 2000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 4 May 2000 09:18:43 -0000 Message-ID: <20000504091843.15946.qmail@cequrux.com> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: Unfinished DNS UPDATE work... References: <200005021655.JAA69559@redpaul.mibh.net> <200005022344.QAA12843@toad.com> <4.3.1.2.20000503085923.0138ca70@dokka.kvatro.no> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Harald Tveit Alvestrand writes: > this seems to me an area where experimentation could be encouraged without > significant harm to the Internet. There's already a protocol that's used at many sites instead of zone transfers. Feature comparison: AXFR + IETF experiments This protocol ----------------------------------------------------------------- Immediate replication Yes Yes Error notification No Yes Incremental transfers Yes Yes Compressed transfers No Yes Add zones automatically No Yes Encryption No Yes Authentication Yes Yes Usable for other services No Yes The protocol, in short, is to actively copy the service configuration through rsync (http://rsync.samba.org) over ssh. Replicating your DNS service through AXFR is like replicating your organization's HTTP service through an uncompressed, unencrypted, ad-hoc error-hiding pull protocol that demands separate configuration for each new subdirectory that you want to replicate. Yes, it can be done, but it's laughably crude. ---Dan P.S. I agree that reload outages are an implementation problem, not a protocol problem. If the server is tinydns, part of the DNScache package (http://cr.yp.to/dnscache.html), then there are no outages. to unsubscribe send a message to 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 May 4 17:35:33 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18755 for ; Thu, 4 May 2000 17:35:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12nSHR-0009ws-00 for namedroppers-data@psg.com; Thu, 04 May 2000 13:31:29 -0700 Received: from dhcp246.ws.afnog.org ([137.158.216.246] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 12nSHL-0009vG-00 for namedroppers@ops.ietf.org; Thu, 04 May 2000 13:31:26 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12nSG2-0000Wf-00 for namedroppers@ops.ietf.org; Thu, 04 May 2000 22:30:02 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3911BFE1.B190A1F8@whistle.com> Date: Thu, 04 May 2000 11:22:25 -0700 From: Terry Lambert To: Harald Tveit Alvestrand CC: Dean Anderson , Kevin Darcy , namedroppers@ops.ietf.org Subject: Re: Unfinished DNS UPDATE work... References: <3.0.32.20000503114559.00fb47e8@odie.av8.com> <4.3.1.2.20000504073728.057218d0@cequrux.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Harald Tveit Alvestrand wrote: > >One caveat: DDNS doesn't currently require signatures, > >since you are permitted to statically configure access > >control lists. This same mechanism could be used, in > >lieu of signatures, to provide the capability. > > What are ACLs usually based on? IP address. > If you're using source IP as an authenticator for a > connectionless, no-handshake protocol, I've got a great > bridge to sell you..... from RFC 2136 (Dynamic Update): You would require TCP for this. The connection would not be established unless the source IP was valid, in the absence of source routing. I don't know of any networks (non-experimental) which enable source routing at this time. > 8 - Security Considerations > > 8.1. In the absence of [RFC2137] or equivilent technology, I think that IP based ACLs requring a TCP connection can be considered "equivalent technology". -- Terry Lambert -- Whistle Communications, Inc., an I.B.M. Company -- terry@whistle.com ------------------------------------------------------------------- This is formal notice under California Assembly Bill 1629, enacted 9/26/98 that any UCE sent to my email address will be billed $50 per incident to the legally allowed maximum of $25,000. to unsubscribe send a message to 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 May 5 00:44:53 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28556 for ; Fri, 5 May 2000 00:44:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12nZH9-000KsH-00 for namedroppers-data@psg.com; Thu, 04 May 2000 20:59:39 -0700 Received: from dhcp246.ws.afnog.org ([137.158.216.246] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 12nZH5-000Ks9-00 for namedroppers@ops.ietf.org; Thu, 04 May 2000 20:59:37 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12nZGq-0001LY-00 for namedroppers@ops.ietf.org; Fri, 05 May 2000 05:59:20 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.1.2.20000504211743.04e18270@dokka.kvatro.no> Date: Thu, 04 May 2000 21:40:49 +0200 To: Terry Lambert From: Harald Tveit Alvestrand Subject: Re: Unfinished DNS UPDATE work... Cc: Dean Anderson , Kevin Darcy , namedroppers@ops.ietf.org In-Reply-To: <3911BFE1.B190A1F8@whistle.com> References: <3.0.32.20000503114559.00fb47e8@odie.av8.com> <4.3.1.2.20000504073728.057218d0@cequrux.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 11:22 04.05.2000 -0700, Terry Lambert wrote: > > If you're using source IP as an authenticator for a > > connectionless, no-handshake protocol, I've got a great > > bridge to sell you..... from RFC 2136 (Dynamic Update): > >You would require TCP for this. The connection would not >be established unless the source IP was valid, in the >absence of source routing. I don't know of any networks >(non-experimental) which enable source routing at this time. this = what? the initial NOTIFY, or the slave-initiated zone transfer? The initial NOTIFY is most likely UDP; easily faked. The outgoing AXFR would be sent to the address given as the source of the NOTIFY, and could be hijacked by an adversary with the ability to listen to outgoing packets and reply with fake-source-address packets; such an attack was used at MIT to break encrypted sessions in Netscape (by modifying the page in Netscape that contained the crypto code when it was loaded using NFS from the fileserver). Alternatively, an attack on the routing tables of any router between the fake-source-address and the server being attacked would give access. With luck, you could even manage to hijack the session without being able to listen; that's what sequence number attacks are for. This vulnerability is noted in RFC 1996 (NOTIFY), btw. Harald -- Harald Tveit Alvestrand, EDB Maxware, Norway Harald.Alvestrand@edb.maxware.no to unsubscribe send a message to 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 May 5 01:16:34 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00345 for ; Fri, 5 May 2000 01:16:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12nZZH-000LSC-00 for namedroppers-data@psg.com; Thu, 04 May 2000 21:18:23 -0700 Received: from [137.158.216.246] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 12nZZD-000LRq-00 for namedroppers@ops.ietf.org; Thu, 04 May 2000 21:18:21 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12nZYx-0001YQ-00 for namedroppers@ops.ietf.org; Fri, 05 May 2000 06:18:03 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39120AC0.F9CA12@whistle.com> Date: Thu, 04 May 2000 16:41:52 -0700 From: Terry Lambert To: Harald Tveit Alvestrand CC: Dean Anderson , Kevin Darcy , namedroppers@ops.ietf.org Subject: Re: Unfinished DNS UPDATE work... References: <3.0.32.20000503114559.00fb47e8@odie.av8.com> <4.3.1.2.20000504073728.057218d0@cequrux.com> <4.3.1.2.20000504211743.04e18270@dokka.kvatro.no> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Harald Tveit Alvestrand wrote: > At 11:22 04.05.2000 -0700, Terry Lambert wrote: > > > If you're using source IP as an authenticator for a > > > connectionless, no-handshake protocol, I've got a great > > > bridge to sell you..... from RFC 2136 (Dynamic Update): > > > >You would require TCP for this. The connection would not > >be established unless the source IP was valid, in the > >absence of source routing. I don't know of any networks > >(non-experimental) which enable source routing at this time. > > this = what? the initial NOTIFY, or the slave-initiated > zone transfer? Using source IP as an authenticator. If it wasn't TCP, you wouldn't permit zone creation. This is practically the same case as with signatures, where the payload bloats so big the packets have to go TCP anyway. > The initial NOTIFY is most likely UDP; easily faked. If it's UDP, you refuse the zone creation. Period. So the rest of the argument predicated on UDP is irrelevant. There are really two cases here: (1) someone substitutes data, or (2) someone utilizes my servers to serve legitimate data, without my permission. Nothing stops them from hijacking normal zone transfers today. If we are worried about substitute data, then solve that problem first. Zone transfers are less likely than zone creation. If someone legitimately owns a zone, has it pointed at my server without permission, and hacks my server so that it serves their zone for them, well, I'm not the guy getting paid for zone registration in the first place, so I really don't care. Compared to my normal server load, that's noise. If they asked me with as much effort as a hack would take, I'd probably have done it for them. > Alternatively, an attack on the routing tables of any > router between the fake-source-address and the server > being attacked would give access. If they are in control of any part of the network infrastructure between my servers, I'm screwed anyway. Why don't I just wait for TLS in IPv6, when all of this signature cruft becomes irrelevent anyway, because I can trust the remote machine's identity? I just want the best resolution available within the near term future. John Gilmore's and other suggestions look like it, unless someone has something else productive to add about solving the problem, instead of why it can't be solved until six years from now. Thanks, -- Terry Lambert -- Whistle Communications, Inc., an I.B.M. Company -- terry@whistle.com ------------------------------------------------------------------- This is formal notice under California Assembly Bill 1629, enacted 9/26/98 that any UCE sent to my email address will be billed $50 per incident to the legally allowed maximum of $25,000. to unsubscribe send a message to 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 May 5 01:16:54 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00402 for ; Fri, 5 May 2000 01:16:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12nZpu-000M3R-00 for namedroppers-data@psg.com; Thu, 04 May 2000 21:35:34 -0700 Received: from dhcp246.ws.afnog.org ([137.158.216.246] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 12nZps-000M3I-00 for namedroppers@ops.ietf.org; Thu, 04 May 2000 21:35:33 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12nZph-0001a0-00 for namedroppers@ops.ietf.org; Fri, 05 May 2000 06:35:21 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 4 May 2000 23:54:20 -0400 From: Andrew Brown To: Terry Lambert Cc: namedroppers@ops.ietf.org Subject: Re: Unfinished DNS UPDATE work... Message-ID: <20000504235419.A5039@noc.untraceable.net> References: <3.0.32.20000503114559.00fb47e8@odie.av8.com> <4.3.1.2.20000504073728.057218d0@cequrux.com> <3911BFE1.B190A1F8@whistle.com> In-Reply-To: <3911BFE1.B190A1F8@whistle.com>; from terry@whistle.com on Thu, May 04, 2000 at 11:22:25AM -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> If you're using source IP as an authenticator for a >> connectionless, no-handshake protocol, I've got a great >> bridge to sell you..... from RFC 2136 (Dynamic Update): > >You would require TCP for this. The connection would not >be established unless the source IP was valid, in the >absence of source routing. I don't know of any networks >(non-experimental) which enable source routing at this time. perhaps i'm a cynic, but i'm pretty sure you're talking about the "other" half of the internet. you might have turned it off, and i sure have, but has *everyone* else done so? i think not. -- |-----< "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 Fri May 5 01:25:04 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01599 for ; Fri, 5 May 2000 01:25:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12nZaD-000LSu-00 for namedroppers-data@psg.com; Thu, 04 May 2000 21:19:21 -0700 Received: from dhcp246.ws.afnog.org ([137.158.216.246] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 12nZaA-000LSk-00 for namedroppers@ops.ietf.org; Thu, 04 May 2000 21:19:19 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12nZZy-0001YU-00 for namedroppers@ops.ietf.org; Fri, 05 May 2000 06:19:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39120E2D.4DAB82F0@whistle.com> Date: Thu, 04 May 2000 16:56:29 -0700 From: Terry Lambert To: "D. J. Bernstein" CC: namedroppers@ops.ietf.org Subject: Re: Unfinished DNS UPDATE work... References: <200005021655.JAA69559@redpaul.mibh.net> <200005022344.QAA12843@toad.com> <4.3.1.2.20000503085923.0138ca70@dokka.kvatro.no> <20000504091843.15946.qmail@cequrux.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit D. J. Bernstein wrote [ edited ]: > AXFR + IETF experiments Rsync + SSH > ----------------------------------------------------------------- > Immediate replication Yes Yes > Error notification No Yes > Incremental transfers Yes Yes > Compressed transfers No Yes > Add zones automatically No Yes ------------------------> depends on the experiment > Encryption No Yes ------------------------> depends on the transport > Authentication Yes Yes > Usable for other services No Yes Can create zones in master Yes No Handles master/slave SOAs Yes No No reload/reconfig latency Yes No No new firewall holes Yes No Commercializable license Yes No > P.S. I agree that reload outages are an implementation problem, > not a protocol problem. If the server is tinydns, part of the > DNScache package (http://cr.yp.to/dnscache.html), then there > are no outages. The problem with this is that it is a UDP-only server, and zone creation requires local access to the machine, where the zone is being created, instead of protocol access in the context of DNS (e.g. ssh is not a sufficient soloution). -- Terry Lambert -- Whistle Communications, Inc., an I.B.M. Company -- terry@whistle.com ------------------------------------------------------------------- This is formal notice under California Assembly Bill 1629, enacted 9/26/98 that any UCE sent to my email address will be billed $50 per incident to the legally allowed maximum of $25,000. to unsubscribe send a message to 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 May 5 01:34:30 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02955 for ; Fri, 5 May 2000 01:34:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12na2Y-000MZO-00 for namedroppers-data@psg.com; Thu, 04 May 2000 21:48:38 -0700 Received: from [137.158.216.246] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 12na2W-000MZ7-00 for namedroppers@ops.ietf.org; Thu, 04 May 2000 21:48:38 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12na2A-0000AQ-00 for namedroppers@ops.ietf.org; Fri, 05 May 2000 06:48:14 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200005050434.VAA81776@redpaul.mibh.net> To: namedroppers@ops.ietf.org Subject: Re: Unfinished DNS UPDATE work... In-reply-to: Your message of "Thu, 04 May 2000 21:40:49 +0200." <4.3.1.2.20000504211743.04e18270@dokka.kvatro.no> Date: Thu, 04 May 2000 21:34:24 -0700 From: Paul A Vixie Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > This vulnerability is noted in RFC 1996 (NOTIFY), btw. all of the reasons why zone creation isn't specified yet are in the later dns rfc's and in the namedroppers archives (including the dnsind minutes). it's not that it should not be done, but rather, that it's not a simple knob that was merely forgotten in the other specifications -- it's a big deal. a hard problem. a task worthy of a hero. such a hero would have to do his or her homework first, though. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri May 5 08:38:26 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16829 for ; Fri, 5 May 2000 08:38:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12ngYU-0004lM-00 for namedroppers-data@psg.com; Fri, 05 May 2000 04:46:02 -0700 Received: from citadel.cdsec.com ([192.96.22.18] helo=citadel.cequrux.com) by psg.com with esmtp (Exim 3.13 #1) id 12ngYR-0004kr-00 for namedroppers@ops.ietf.org; Fri, 05 May 2000 04:46:00 -0700 Received: (from nobody@localhost) by citadel.cequrux.com (8.9.3/8.9.3) id NAA13742 for ; Fri, 5 May 2000 13:45:50 +0200 (SAST) Received: by citadel.cequrux.com via recvmail id 13670; Fri May 5 13:45:00 2000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 5 May 2000 07:33:19 -0000 Message-ID: <20000505073319.7729.qmail@cequrux.com> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: Unfinished DNS UPDATE work... References: <200005021655.JAA69559@redpaul.mibh.net> <200005022344.QAA12843@toad.com> <4.3.1.2.20000503085923.0138ca70@dokka.kvatro.no> <20000504091843.15946.qmail@cequrux.com> <39120E2D.4DAB82F0@whistle.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit There are two different administrative activities under discussion: editing your DNS records, and replicating your DNS service. I compared two different replication protocols: AXFR+NOTIFY+IXFR+TSIG and rsync+ssh. One of the advantages of rsync+ssh is that it can easily replicate the _entire_ service, solving the add-zones-to-the-slave problem that Cricket mentioned. When Terry talks about ``create zones in master'' he's obviously thinking of editing, not replication. Of course, there are ssh-based editing protocols too. Terry Lambert writes: > Commercializable license I don't understand. You're complaining about the rsync and ssh protocols because implementations are available for free? > new firewall holes So remote file editing is okay if it's done with experimental software on port 53, but not if it's done with stable software on a dedicated port that you can precisely control? This makes no sense. As far as I'm concerned, cramming six separate protocols into port 53 is a horrible idea. It defeats the demultiplexing provided by UDP and TCP implementations, so it adds extra work for people who want to handle the protocols in separate programs. Putting the protocols on separate ports encourages modularity and encourages competition. > reload/reconfig latency My tinydns-data program compiles a 30-megabyte database in 10 seconds on a typical workstation. During those 10 seconds, queries are answered from the old database. What exactly are you worried about? > it is a UDP-only server You can provide TCP service if you want to; it's simply not the default. RTFM: http://cr.yp.to/dnscache/faq/tinydns.html#tcp ---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 May 5 18:09:39 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00041 for ; Fri, 5 May 2000 18:09:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12npFu-000N76-00 for namedroppers-data@psg.com; Fri, 05 May 2000 14:03:26 -0700 Received: from [137.158.216.130] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 12npFq-000N6z-00 for namedroppers@ops.ietf.org; Fri, 05 May 2000 14:03:24 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12npFL-0000au-00 for namedroppers@ops.ietf.org; Fri, 05 May 2000 23:02:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3913140E.A82CFAE0@whistle.com> Date: Fri, 05 May 2000 11:33:50 -0700 From: Terry Lambert To: "D. J. Bernstein" CC: namedroppers@ops.ietf.org Subject: Re: Unfinished DNS UPDATE work... References: <200005021655.JAA69559@redpaul.mibh.net> <200005022344.QAA12843@toad.com> <4.3.1.2.20000503085923.0138ca70@dokka.kvatro.no> <20000504091843.15946.qmail@cequrux.com> <39120E2D.4DAB82F0@whistle.com> <20000505073319.7729.qmail@cequrux.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit D. J. Bernstein wrote: > > There are two different administrative activities under > discussion: editing your DNS records, and replicating > your DNS service. > > I compared two different replication protocols: > AXFR+NOTIFY+IXFR+TSIG and rsync+ssh. One of the advantages > of rsync+ssh is that it can easily replicate the _entire_ > service, solving the add-zones-to-the-slave problem that > Cricket mentioned. I have a problem with replicating the data verbatim. In particular, I have a serious issue with the fact that this would mean that my slaves would really be masters in their own right. Any replication has to be hierarchical, as the DNS is hierarchical. People may not like this any more than they like it in LDAP or NIS, but that's irrelevent. You are implicitly advocating a use model which discards the concept of slaves, and I am not willing to go that far without a serious amount of justification. When you can get the working group to withdraw the work that you object to, then I will be willing to quit using it. > When Terry talks about ``create zones in master'' he's > obviously thinking of editing, not replication. Of > course, there are ssh-based editing protocols too. I am thinking about all of the tasks I normally have to do while running the server, and the fact that I can't do them all over port 53 (yet). > Terry Lambert writes: > > Commercializable license > > I don't understand. You're complaining about the rsync > and ssh protocols because implementations are available > for free? No. And I don't want a license merit discussion. I mean I can't sell a product based on it and linked with code which embodies my patented algorithm without tacitly giving license to use my patented algorithm, for free, when anyone demands my source code. License merit is irrelevant. My lawyers will simply not let me do this, and any argument you put forth to me is just so much wasted breath, because I am not my lawyers. > > new firewall holes > > So remote file editing is okay if it's done with > experimental software on port 53, Yes. > but not if it's done with stable software on a dedicated > port that you can precisely control? This makes no sense. The protocol you advocate letting in permits shell access, which is administratively prohibited. > As far as I'm concerned, cramming six separate protocols > into port 53 is a horrible idea. I definitely agree. Which is why I'm only talking about DNS data manipulation, not modifying my crontab as a result of port 53 traffic. > Putting the protocols on separate ports encourages > modularity and encourages competition. Only among people who do not understand principles of modular programming in the first place, such that they create something which is not modular based on first principles. As a counter-example, there are many SNMP daemons that allow registration of subtree handlers. So do almost all LDAP servers. So do some DNS servers. All UNIX file systems. I could go on; it's a common attribute of most hierarchical databases, and those which do not include the capability are generally considered deficient. > > reload/reconfig latency > > My tinydns-data program compiles a 30-megabyte database > in 10 seconds on a typical workstation. During those 10 > seconds, queries are answered from the old database. What > exactly are you worried about? We were talking about your protocol, not your DNS implementation. I am worried about using a DNS from someone other than you: one I will be permitted to deploy. > > it is a UDP-only server [ ... suggestion to use a different glue program ... ] This does not address the primary complaint: | zone creation requires local access to the machine, where | the zone is being created, instead of protocol access in the | context of DNS (e.g. ssh is not a sufficient soloution). -- Terry Lambert -- Whistle Communications, Inc., an I.B.M. Company -- terry@whistle.com ------------------------------------------------------------------- This is formal notice under California Assembly Bill 1629, enacted 9/26/98 that any UCE sent to my email address will be billed $50 per incident to the legally allowed maximum of $25,000. to unsubscribe send a message to 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 May 6 01:29:29 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09768 for ; Sat, 6 May 2000 01:29:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12nwWW-000M8f-00 for namedroppers-data@psg.com; Fri, 05 May 2000 21:49:04 -0700 Received: from [137.158.216.130] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 12nwWT-000M8Z-00 for namedroppers@ops.ietf.org; Fri, 05 May 2000 21:49:02 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12nwWG-0001f5-00 for namedroppers@ops.ietf.org; Sat, 06 May 2000 06:48:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 6 May 2000 00:08:06 -0000 Message-ID: <20000506000806.225.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: Unfinished DNS UPDATE work... References: <200005021655.JAA69559@redpaul.mibh.net> <200005022344.QAA12843@toad.com> <4.3.1.2.20000503085923.0138ca70@dokka.kvatro.no> <20000504091843.15946.qmail@cequrux.com> <39120E2D.4DAB82F0@whistle.com> <20000505073319.7729.qmail@cequrux.com> <3913140E.A82CFAE0@whistle.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Terry Lambert writes: > my slaves would really be masters On the contrary. They're still slaves. DNS records are edited on the master and then copied to the slaves. The only difference is that the copying happens through a better protocol. BIND incorrectly refers to these slaves as ``masters,'' because BIND incorrectly assumes that all replication will take place through the crude protocols built into BIND; but these mistakes don't change the reality of what's happening. > The protocol you advocate letting in permits shell access, On the contrary. It's a general-purpose protocol, like TCP. Shell access is merely one application. DNS replication is another application. DNS editing is another application. > ssh is not a sufficient soloution You keep saying that these things can't be done, but they can be, and they often are, because existing general-purpose tools do the job today, while DNS-specific vaporware doesn't. > As a counter-example, there are many SNMP daemons that > allow registration of subtree handlers. So do almost all > LDAP servers. So do some DNS servers. I didn't say that demultiplexing couldn't be done in a DNS server. I said that it adds unnecessary implementation costs for modular servers. A competent protocol designer will use separate ports to take advantage of the demultiplexing features that are already provided by UDP/IP and TCP/IP stacks. > We were talking about your protocol, not your DNS implementation. You mentioned a BIND implementation flaw, namely failure to answer queries while new data is being read. You mischaracterized this flaw as a problem in replication protocols that use rsync+ssh. (When you hear that BIND's IXFR implementation keeps crashing, do you conclude that IXFR must be a bad protocol?) I pointed out that these outages simply don't occur with tinydns-data. This makes clear that your problems are with one implementation, not with the 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 Sat May 6 01:37:51 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11011 for ; Sat, 6 May 2000 01:37:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12nwQk-000LkS-00 for namedroppers-data@psg.com; Fri, 05 May 2000 21:43:06 -0700 Received: from [137.158.216.130] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 12nwQh-000LkH-00 for namedroppers@ops.ietf.org; Fri, 05 May 2000 21:43:04 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12nwQQ-0001eH-00 for namedroppers@ops.ietf.org; Sat, 06 May 2000 06:42:46 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39135D07.E8975F82@daimlerchrysler.com> Date: Fri, 05 May 2000 19:45:11 -0400 From: Kevin Darcy To: namedroppers@ops.ietf.org Subject: Re: Unfinished DNS UPDATE work... References: <200005050434.VAA81776@redpaul.mibh.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul A Vixie wrote: > > This vulnerability is noted in RFC 1996 (NOTIFY), btw. > > all of the reasons why zone creation isn't specified yet are in the later > dns rfc's and in the namedroppers archives (including the dnsind minutes). > it's not that it should not be done, but rather, that it's not a simple > knob that was merely forgotten in the other specifications -- it's a big > deal. a hard problem. a task worthy of a hero. > > such a hero would have to do his or her homework first, though. I searched the entire namedroppers archives available at ftp://ftp.ietf.org/pub/lists for compound phrases containing both "zone" and "creation" (the term you used) or reasonable variations thereof, and got only 2 relevant hits (by "relevant", I exclude variations of the RFC text itself explaining that zone creation isn't currently possible with Dynamic Update, since we've already seen that in this thread): #1: Bill Simpson questioned the aforementioned RFC text, in November of 1996, and asked "..., doesn't this preclude us from using this for distributed updating of the TLD zones?". As far as I can tell, no-one answered his query. #2: in response to a generic "why can't I create a zone with Dynamic Update?"-type question, from Matt O'Connell in May of 1998, the following answer was given by James Cutler: > Zones form the shape and structure of the name tree. > The structure must be designed and put into place. > > RRs are leaves on the tree and may grow and fall off. > This is an operations issue, not a design issue. > Dynamic updates support the operation within the design. This is hardly in the same category as the "it's really hard" hand-waving I've been seeing lately. I also eyeballed all of the messages with "minutes" in their Subject: lines, just in case the mechanical search might have missed relevant content using slightly different terminology. Zilch. The same mechanical search of all of the RFC's in the BIND 9 Beta 2 "doc/rfc" directory yielded no relevant hits. Could you provide some more specific pointers? Or, better yet, could one of the "it's really hard" oldbie faction give a quick *summary* to us "why not?" newbies? This might be more efficient than a bunch of folks running around trying to hunt down references in RFC's and old list archives. --- As a potential slave, if I have a list of all the servers which are allowed to initiate master-slave relationships with me, and I get a crypto-verified NOTIFY from one of them, and I (optionally) check the delegations, optionally with crypto-verification of the responses to verify that, yes, the server sending me the NOTIFY really has been delegated the zone it wants me to slave, how much more paranoid do I have to be before going ahead and becoming a slave to the zone? What is the "hard problem" to be solved here? - 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 May 6 01:52:58 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11903 for ; Sat, 6 May 2000 01:52:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12nwmr-000N4b-00 for namedroppers-data@psg.com; Fri, 05 May 2000 22:05:57 -0700 Received: from [137.158.216.130] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 12nwmo-000N4T-00 for namedroppers@ops.ietf.org; Fri, 05 May 2000 22:05:55 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12nwmc-0001gS-00 for namedroppers@ops.ietf.org; Sat, 06 May 2000 07:05:42 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Terry Lambert Cc: namedroppers@internic.net Subject: Re: Unfinished DNS UPDATE work... In-Reply-To: Your message of "Fri, 05 May 2000 11:33:50 MST." <3913140E.A82CFAE0@whistle.com> Date: Sat, 06 May 2000 13:55:12 +1000 Message-Id: <26409.957585312@mundamutti.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Fri, 05 May 2000 11:33:50 -0700 From: Terry Lambert Message-ID: <3913140E.A82CFAE0@whistle.com> | Any replication has to be hierarchical, as the DNS is | hierarchical. People may not like this any more than | they like it in LDAP or NIS, but that's irrelevent. I don't generally agree with Dr Bernstein - about anything at all. But in this instance, he's right - it doesn't matter in the least how the DNS data is replicated, as long as it is accurately and reliably replicated. AXFR (or IXFR) is one way, ssh is another. The root zones used to be (and for all I know, may still be) replicated using FTP. The only problem I have encountered with using other than *XFR is that I have seen either implementations or operators (I haven't worked out which yet) who seem to have misunderstood "replication" and make subtle changes to the data in the secondary servers (in particular having the SOA.MNAME reflect the name of the server, rather than the data from the zone file). But that's just a bug - correctly operated servers that have been correctly implemented will work however the master file is transferred from primary to secondary server. 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 Sat May 6 03:46:14 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18858 for ; Sat, 6 May 2000 03:46:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12nyuc-0005DX-00 for namedroppers-data@psg.com; Sat, 06 May 2000 00:22:06 -0700 Received: from [137.158.216.130] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 12nyua-0005DR-00 for namedroppers@ops.ietf.org; Sat, 06 May 2000 00:22:05 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12nyuJ-0001pK-00 for namedroppers@ops.ietf.org; Sat, 06 May 2000 09:21:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: "D. J. Bernstein" Cc: namedroppers Subject: Re: Unfinished DNS UPDATE work... References: <200005021655.JAA69559@redpaul.mibh.net> <200005022344.QAA12843@toad.com> <4.3.1.2.20000503085923.0138ca70@dokka.kvatro.no> <20000504091843.15946.qmail@cequrux.com> <39120E2D.4DAB82F0@whistle.com> <20000505073319.7729.qmail@cequrux.com> <3913140E.A82CFAE0@whistle.com> <20000506000806.225.qmail@cr.yp.to> Message-Id: Date: Sat, 06 May 2000 09:02:08 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit it was thought prudent for the protocol specification to provide a clear and documented means to move zone files between he master/primary and slaves/ secondaries. if one has other means to accomplish the same end, then cool. but the other means must achieve the semantically identical results as judged by the bits on the wire as far as clients (resolvers) and others can tell. i.e., when you're through being cute, the duck must still walk like a duck. 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 Sun May 7 05:10:01 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06390 for ; Sun, 7 May 2000 05:10:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12oMEN-0005sT-00 for namedroppers-data@psg.com; Sun, 07 May 2000 01:16:03 -0700 Received: from [137.158.216.130] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 12oMEJ-0005ol-00 for namedroppers@ops.ietf.org; Sun, 07 May 2000 01:16:01 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12oMDo-0000C0-00 for namedroppers@ops.ietf.org; Sun, 07 May 2000 10:15:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200005061621.JAA90694@redpaul.mibh.net> To: namedroppers Subject: Re: Unfinished DNS UPDATE work... In-reply-to: Your message of "Sat, 06 May 2000 09:02:08 +0200." Date: Sat, 06 May 2000 09:21:01 -0700 From: Paul A Vixie Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > it was thought prudent for the protocol specification to provide a clear and > documented means to move zone files between he master/primary and slaves/ > secondaries. if one has other means to accomplish the same end, then cool. > but the other means must achieve the semantically identical results as > judged by the bits on the wire as far as clients (resolvers) and others can > tell. i.e., when you're through being cute, the duck must still walk like a > duck. right. i've used nfs, rcp, rdist, rsync, uux, ftp, tftp and who knows what else to move zone files when there were firewalls in the way i didn't control. but none of those methods did what the zone transfer spec says, and by the time i would get done trying to do serial number comparison including 32-bit wrapping, refresh intervals, retry intervals, and expiration, it wasn't just a little cron job running a shell script any more, and it ended up being easier to have fixed the firewall. same thing for using dig rather than named-xfer. axfr's biggest problem was fixed by IXFR. its second biggest problem could be fixed with what BIND calls "ZXFR" which is just gzip on the transport session; i never finished it and it's disabled by #ifdef's but you get the idea. to unsubscribe send a message to 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 May 8 14:54:47 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15317 for ; Mon, 8 May 2000 14:54:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12oroT-0002l5-00 for namedroppers-data@psg.com; Mon, 08 May 2000 10:59:25 -0700 Received: from ts-dbn-243.cis.co.za ([196.2.27.243] helo=gatekeeper.frcs.alt.za) by psg.com with esmtp (Exim 3.13 #1) id 12oroL-0002iw-00 for namedroppers@ops.ietf.org; Mon, 08 May 2000 10:59:23 -0700 Received: (from nobody@localhost) by gatekeeper.frcs.alt.za (8.8.8/8.6.9) id TAA23667 for ; Mon, 8 May 2000 19:48:37 +0200 (SAST) Received: by gatekeeper.frcs.alt.za via recvmail id 23664; Mon May 8 19:47:49 2000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 8 May 2000 00:13:23 -0000 Message-ID: <20000508001323.17055.qmail@frcs.alt.za> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: Unfinished DNS UPDATE work... References: <200005061621.JAA90694@redpaul.mibh.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul A Vixie writes: > serial number comparison including 32-bit wrapping, The normal use of ssh for DNS replication doesn't rely on serial numbers at all. The master immediately pushes new data to the slaves. > refresh intervals, retry intervals, and expiration One advantage of pushing data in the foreground through ssh is that you receive immediate and reliable notification if anything goes wrong. If you run out of disk space editing your web pages, would you like your editor to try saving the file for the first time only after you log out? Then have it destroy the old pages after retrying for weeks? Or would you prefer to have it see the problem and tell you about it as soon as you say ``save''? I'm not saying that refresh-retry-expire is difficult to implement. I'm saying that it's a poor substitute for what people actually want. > axfr's biggest problem was fixed by IXFR. The same problem was fixed much earlier by sysadmins using the standard general-purpose ``diff'' and ``patch'' tools. Nowadays, with rsync, the master doesn't even need to keep a log of changes. Anyway, I can't agree that this is AXFR's biggest problem. The lack of immediate failure notices, the lack of a mechanism to modify zone lists, and the lack of security are much bigger problems for most sysadmins. ---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 May 8 17:34:08 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20324 for ; Mon, 8 May 2000 17:34:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12ouf1-0008bG-00 for namedroppers-data@psg.com; Mon, 08 May 2000 14:01:51 -0700 Received: from ts-dbn-243.cis.co.za ([196.2.27.243] helo=gatekeeper.frcs.alt.za) by psg.com with esmtp (Exim 3.13 #1) id 12oueu-0008af-00 for namedroppers@ops.ietf.org; Mon, 08 May 2000 14:01:48 -0700 Received: (from nobody@localhost) by gatekeeper.frcs.alt.za (8.8.8/8.6.9) id WAA05343 for ; Mon, 8 May 2000 22:51:05 +0200 (SAST) Received: by gatekeeper.frcs.alt.za via recvmail id 5337; Mon May 8 22:50:42 2000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3917203C.E873E36C@frcs.alt.za> Date: Mon, 08 May 2000 13:14:52 -0700 From: Terry Lambert To: "D. J. Bernstein" CC: namedroppers@ops.ietf.org Subject: Re: Unfinished DNS UPDATE work... References: <200005021655.JAA69559@redpaul.mibh.net> <200005022344.QAA12843@toad.com> <4.3.1.2.20000503085923.0138ca70@dokka.kvatro.no> <20000504091843.15946.qmail@cequrux.com> <39120E2D.4DAB82F0@whistle.com> <20000505073319.7729.qmail@cequrux.com> <3913140E.A82CFAE0@whistle.com> <20000506000806.225.qmail@cr.yp.to> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit D. J. Bernstein wrote: > > my slaves would really be masters > > On the contrary. They're still slaves. DNS records are edited > on the master and then copied to the slaves. The only difference > is that the copying happens through a better protocol. > > BIND incorrectly refers to these slaves as ``masters,'' because > BIND incorrectly assumes that all replication will take place > through the crude protocols built into BIND; but these mistakes > don't change the reality of what's happening. In that case, my master is an SQL database from which the DNS configuration data is derived. I think that, semantic games aside, your method will result in not having explicit configuration exposed to call out the relationship between the servers. It also means that your slaves will be clones of your master, and you may not want that; in particular, if I am going to have three machines at three colocation facilities for high availability and robustness in the face of the occasional fiber cut, then the load on each of the machines is 2/3rds of my total zones, with each zone served by two facilities. Assymetry can be both intentional and useful. > > ssh is not a sufficient soloution > > You keep saying that these things can't be done, but > they can be, and they often are, because existing > general-purpose tools do the job today, while DNS-specific > vaporware doesn't. I don't say that "it can't be done", I say "it would be unwise to do it this way" and "use of ssh is administratively prohibited". > I didn't say that demultiplexing couldn't be done in a DNS > server. I said that it adds unnecessary implementation > costs for modular servers. A competent protocol designer > will use separate ports to take advantage of the > demultiplexing features that are already provided by UDP/IP > and TCP/IP stacks. I have figured out why this bothers me so much. It is the same argument one would use to justify using ssh to deliver email, rather than overloading the SMTP port by adding more commands that the command interpreter then has to demux. It's the job of DNS to deal with DNS data, just as it is the job of SMTP to transport email. > > We were talking about your protocol, not your DNS > > implementation. > > You mentioned a BIND implementation flaw, namely failure > to answer queries while new data is being read. You > mischaracterized this flaw as a problem in replication > protocols that use rsync+ssh. (When you hear that BIND's > IXFR implementation keeps crashing, do you conclude that > IXFR must be a bad protocol?) > > I pointed out that these outages simply don't occur with > tinydns-data. This makes clear that your problems are with > one implementation, not with the protocol. I think the flaw lies not in reading new data causing the server to be unresponsive, but the fact that the new data is actualized by being read, instead of having some other protocol-based method of communicating it to the server. If you use a protocol to communicate the new data, rather than hacking files and clubbing the server over the head, then there is no unresponsiveness problem. In other words, this is a protocol problem, not an implementation problem. Yes, it's possible to replicate data with some external mechanism that will be non-interoperable between all of the DNS servers on the planet because everyone has their own favorite Rube-Goldberg one-off set of scripts. But it it not wise to do this. It is better to define a protocol that everyone who wishes to claim compliance with the RFCs will have to implement. I think it's ridiculous to put this protocol on a new port for no apparent technical reason, givem that DNS servers must already demux based on command code, and adding another command code doesn't increase the mux complexity one whit, but perhaps you can get the working group to buy off on the idea (I doubt it; they probably have their own firewall gestappo to contend with when it comes to opening yet more ports). -- Terry Lambert -- Whistle Communications, Inc., an I.B.M. Company -- terry@whistle.com ------------------------------------------------------------------- This is formal notice under California Assembly Bill 1629, enacted 9/26/98 that any UCE sent to my email address will be billed $50 per incident to the legally allowed maximum of $25,000. to unsubscribe send a message to 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 May 8 17:34:09 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20326 for ; Mon, 8 May 2000 17:34:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12ouZa-0008Qa-00 for namedroppers-data@psg.com; Mon, 08 May 2000 13:56:14 -0700 Received: from ts-dbn-243.cis.co.za ([196.2.27.243] helo=gatekeeper.frcs.alt.za) by psg.com with esmtp (Exim 3.13 #1) id 12ouZU-0008OD-00 for namedroppers@ops.ietf.org; Mon, 08 May 2000 13:56:12 -0700 Received: (from nobody@localhost) by gatekeeper.frcs.alt.za (8.8.8/8.6.9) id WAA05005 for ; Mon, 8 May 2000 22:45:26 +0200 (SAST) Received: by gatekeeper.frcs.alt.za via recvmail id 4941; Mon May 8 22:45:12 2000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: namedroppers@internic.net Subject: Re: Unfinished DNS UPDATE work... In-Reply-To: Your message of "08 May 2000 00:13:23 GMT." <20000508001323.17055.qmail@frcs.alt.za> Date: Tue, 09 May 2000 04:51:54 +1000 Message-Id: <3561.957811914@frcs.alt.za> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: 8 May 2000 00:13:23 -0000 From: "D. J. Bernstein" Message-ID: <20000508001323.17055.qmail@frcs.alt.za> | Paul A Vixie writes: | > serial number comparison including 32-bit wrapping, | | The normal use of ssh for DNS replication doesn't rely on serial numbers | at all. The master immediately pushes new data to the slaves. That's broken. If the secondary has a higher serial number than the master, it must not update to the master's copy. That allows data to be preserved when the master recovers from a backup, and ends up with an older zone copy. Before dynamic update that might not have been all that important, as lost updates would often just be done again at the master (though I generally preferred to AXFR the zone back from the secondary), but with dynamic update, if the master loses updates that have been made, and secondaries then blindly follow, there's a totally unnecessary data loss. Not only that, but it is entirely reasonable for a cache to determine the serial number of a zone, and internally refresh all RRs it has from that zone by just verifying that the serial number has not increased at an authoritative server (essentially pretending it had just done queries on all the RRs and had the same data returned, but with new TTLs). If the serial number protocols aren't followed correctly, all that breaks. | One advantage of pushing data in the foreground through ssh is that you | receive immediate and reliable notification if anything goes wrong. That's an implementation nit. It is entirely possible to use ssh in a way that you don't get that notification. It is also entirely possible to use the AXFR protocols and provide all the notification that you could want (either with the secondary providing the notification of a failure, or with the primary notifying cases where the zone has not been compleetly fetched, and most likely with both - the primary logs work when the secondary ihas simply forgotten the zone, including when it has crashed, and the secondary notification working when the transfer is attempted, but for some reason does not succeed properly). | I'm not saying that refresh-retry-expire is difficult to implement. I'm | saying that it's a poor substitute for what people actually want. It is an essential part of the protocol. 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 May 9 00:43:30 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29688 for ; Tue, 9 May 2000 00:43:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12p148-0006yh-00 for namedroppers-data@psg.com; Mon, 08 May 2000 20:52:12 -0700 Received: from [196.2.27.243] (helo=gatekeeper.frcs.alt.za) by psg.com with esmtp (Exim 3.13 #1) id 12p13t-0006v9-00 for namedroppers@ops.ietf.org; Mon, 08 May 2000 20:52:05 -0700 Received: (from nobody@localhost) by gatekeeper.frcs.alt.za (8.8.8/8.6.9) id FAA01534 for ; Tue, 9 May 2000 05:40:46 +0200 (SAST) Received: by gatekeeper.frcs.alt.za via recvmail id 1532; Tue May 9 05:40:13 2000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 9 May 2000 03:28:28 -0000 Message-ID: <20000509032828.17676.qmail@frcs.alt.za> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: Unfinished DNS UPDATE work... References: <20000508001323.17055.qmail@frcs.alt.za> <3561.957811914@frcs.alt.za> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ this is the last message on this subject i plan to approve on namedroppers. folk, please take it to dnsop or elsewhere. -- rabdy ] Robert Elz writes: > when the master recovers from a backup, and ends up with an older zone One of the virtues of immediate replication is that, if one machine dies, the sysadmin has up-to-date copies of the data on other machines. In particular, if the master dies, the sysadmin can set up one of the other machines as a master, or copy the up-to-date information to a new master, so your ``totally unnecessary data loss'' simply doesn't occur. Furthermore, if the sysadmin _does_ decide that he wants to move the master back to the data he had before, proper replication means that the slaves will do the same thing. Slaves cause an incredible amount of damage when they fail to copy data that they don't like. > It is also entirely possible to use the AXFR protocols and provide all > the notification that you could want When a sysadmin uses rsync+ssh with tinydns, he can type ./add-mx lion.heaven.af.mil 1.2.3.5 make and reliably see any relevant error messages before the next prompt. Normally the next prompt shows up very quickly with no error message; this guarantees that the new data is available from the master and from all the slaves. The IETF DNS protocols don't support these features. AXFR-based replication is slow, even with NOTIFY; see RFC 1996, section 4.3. The master isn't told when a transfer succeeds; it has to poll for new data, wasting even more time. Most importantly, there's no way for the master to find out what went wrong if a transfer fails. ---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 May 11 07:16:54 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23830 for ; Thu, 11 May 2000 07:16:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12pq5a-000CZH-00 for namedroppers-data@psg.com; Thu, 11 May 2000 03:21:06 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12pq5a-000CZB-00 for namedroppers@ops.ietf.org; Thu, 11 May 2000 03:21:06 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12pq5a-000LxB-00 for namedroppers@ops.ietf.org; Thu, 11 May 2000 03:21:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 11 May 2000 10:52:19 +0200 (CEST) From: Roy Arends To: namedroppers Subject: Remarks on the DNS Security Extension Clarification on Zone Status draft Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Comments by Roy Arends and Ted Lindgreen from NLnet Labs on the Internet-Draft: DNS Security Extension Clarification on Zone Status April 13, 2000, by Edward Lewis. We start with our conclusions: - A clarifying document is very worthwile, but we would like to suggest not to use the terms "Fully Secured" and "Privately Secured" - It would be good to have a Best Current Practice document to guide DNS-administrators on implementing DNSSEC. - The proposed updates to RFC 2535 all seem either unnecessary or undesirable. Mr. Lewis introduces terms and definitions of security levels: "Fully Secured", "Privately Secured", and "Unsecured". We feel that this is very confusing as a zone is either "Secured" or "Unsecured". Also confusing is the interaction between parent and child zones that enter the picture. There is no relation between this interaction and the level of security. We would therefore prefer that these confusing terms and definitions would not be used. Note, the signing of a zone KEY is an interaction which is outside the scope of this draft (as mentioned in the Introduction). Therefore we view the terms and definitions for "On-tree Validation" and "Off-tree Validation", which itself are very useful, as outside the scope of this Draft. We suggest to define these terms in a BCP for DNS-administrators on implementing the DNS Security Extensions. Also much confusion stems from the statement in the introduction of the Draft, that "a delegating zone is required to indicate whether a child zone is secured". In general this is not true, as the zone itself is responsible for its security. There is one and only one special and temporal case when a parent must indicate that a child is unsecure: when a parent zone converts from unsecure to secure, while its childs have no KEY (or NULL-KEY) yet. It could be recommended in a BCP for DNS-administrators, that childs of zones that convert to be secure are expected to either convert also or update their own zone file with a NULL-KEY as soon as possible. Proposed terms and definitions. Assuming correct configurations only, we would like to define: A zone is "Secured" then and only then if the resolver expects a zone KEY for this zone and finds it to be a non-NULL KEY. A zone is "Unsecured" if no zone KEY is expected or a NULL-KEY is found. These "Secured" and "Unsecured" definitions can be viewed from the perspective from the two parties involved to clarify what must be done: The zone administrator that wants his zone to be "Secured" - needs to generate a zone KEY, and have this KEY signed or advertized in such a way that the resolvers of interest expect it and can verify it; - inserts NULL-KEY's at delegation points for child zones that have not yet their own KEY (or NULL-KEY) as a temporal measure to prevent them from dangling. - takes care of properly signing the zone (which includes the addition of NXT RRs). The resolver that is security minded about certain parts of the DNS tree - must be configured to know which parts of the DNS tree it expects to be Secured; - must be able to walk a verification path from the zone KEY to one of its known and trusted KEYs; - must be able to verify the SIGs of the relevant RRs in the zone with the zone KEY. Please note that we make no mention of any special way of signing, nor about the path of verification. Also note that there is no mentioning of parent-child interaction, except for the temporal need to take care of not yet converted or updated children during the conversion from "Unsecured" to "Secured". We read from RFC 2535 that it supports a general mechanisme of verification, and also describes a specific possible implementation: along the reverse of the delegation path. We view it as very important that the general mechanisme is fully retained. Also note that we make no mention about the algorithms that are used. It is up to the zone administrator and with the producers of the resolvers of interest to choose the most suitible algorithms. We suggest that a Best Current Practice document is produced to recommend on parent-child and KEY holder-signer communication issues and on which algorithms to use. Proposed updates to RFC 2535. In 2.a of the Draft is a proposal to update RFC 2535-3.1.3 on the requirement of the protocol field. We don't see the need for this update as RFC 2535 is already clear on this matter (see detail number 3 in RFC 2535-3.1.3). In 2.1.c is a proposal to update RFC 2535-2.3.2 on the requirement to use NXT RRs. On reading RFC 2535 carefully it is clear that this requirement is already there (see RFC 2535-5.3) and is also already implicated by the signing process itself. Therefore, if their remains any doubt about this, a clarification should suffice. In 2.1.d is a proposal to update RFC 2535-2.3.1 on signing each RR, and using a Mandatory to Implement algorithm. The former part of this requirement is already in RFC 2535 (see 2.3.1, 2.3.4, and 3.1.1). So this part of the update is unnecessary. The latter part of this proposed, new requirement severly restricts the DNS Security Extension by disallowing other algorithm than DSA, including the Recommended to Implement algorithms (as RSA). This part of the proposed update is undesirable. In 2.2.d the first part of the same proposal is repeated, which is again an update that is unnecessary. In 3.1 a "Child Has Keys" bit is introduced which updates at least RFC 2535-2.3.4. In contrast to the proposed name of this bit, it appears on careful reading, that this proposed bit signals that "The Parent Has Signed The KEY Of This Child". This is very different from its name, and it defeats the possibility of any other verification mechanisme than the special case along the reverse of the delegation path. So this is a major update of the DNS Security Extension. We feel that the disavantage of the limitation of the original general verification mechanisme significantly outweights the advantage of having a somewhat smaller parent zone for some time after the conversion from Unsecured to Secured. We therefore conclude that this update is undesirable. In 5 is a proposal to update RFC 2535-3.4 on the experimental status. The need for this update disappears when the functionality of the NULL-KEY is retained. Regards, Roy Arends, NLnet Labs to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu May 11 12:58:33 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03036 for ; Thu, 11 May 2000 12:58:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12pvBJ-000FZq-00 for namedroppers-data@psg.com; Thu, 11 May 2000 08:47:21 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12pvBJ-000FZk-00 for namedroppers@ops.ietf.org; Thu, 11 May 2000 08:47:21 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12pvBI-000NNx-00 for namedroppers@ops.ietf.org; Thu, 11 May 2000 08:47:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: Date: Thu, 11 May 2000 09:30:32 -0400 To: Roy Arends From: Edward Lewis Subject: Re: Remarks on the DNS Security Extension Clarification on Zone Status draft Cc: namedroppers Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 4:52 AM -0400 5/11/00, Roy Arends wrote: >Comments by Roy Arends and Ted Lindgreen from NLnet Labs on the >Internet-Draft: Thanks - I already need to rewrite this based on comments from developers. >We start with our conclusions: >- A clarifying document is very worthwile, but we would like to suggest >not to use the terms "Fully Secured" and "Privately Secured" Partly addressing comments later on, there is a distinction to be made amongst "secured" zones. The rationale is that a zone's security is dependent on factors decided by the zone admin and by factors beyond the control of the zone admin (i.e., the parent, grandparent, etc., zone admins). So the three stages are unsecured, secured as best as can be, and recognizably secure. These correspond to local admins doing nothing, local admins taking steps but not remote admins, and all admins taking steps. (Paraphrasing...) >- It would be good to have a Best Current Practice document to guide >DNS-administrators on implementing DNSSEC. Before such a document is ripe to be written, we need to have BINDv9 out, a couple of workshops to iron out the parent-child interaction and resolver interpretation issues. >- The proposed updates to RFC 2535 all seem either unnecessary or >undesirable. We'd have to look at that on a case-by-case basis. >Mr. Lewis introduces terms and definitions of security levels: "Fully >Secured", "Privately Secured", and "Unsecured". We feel that this is very >confusing as a zone is either "Secured" or "Unsecured". Also confusing is >the interaction between parent and child zones that enter the picture. >There is no relation between this interaction and the level of security. >We would therefore prefer that these confusing terms and definitions would >not be used. The interaction between parent and child is very important in determining the child's percieved security level. E.g., I could take evey step in securing tislabs.com, but if com is not secured, tislabs.com won't be secured (according to my definition of "normal" security). >Note, the signing of a zone KEY is an interaction which is outside the >scope of this draft (as mentioned in the Introduction). Therefore we >view the terms and definitions for "On-tree Validation" and >"Off-tree Validation", which itself are very useful, as outside the >scope of this Draft. We suggest to define these terms in a BCP for >DNS-administrators on implementing the DNS Security Extensions. What I meant was that how the "signing is done" is outside the scope of this document. (Perhaps I need to reword that section.) Understanding the difference between on-tree and off-tree are important. Perhaps there is some more history to this document than has come out in writing. I have been approached by a number of folks who have proposed using off-tree signing for validation. E.g., governmental agencies often contract to firms to run the operations of government centers. One such contractor asked me if he could sign the government's zone with his contractor key - a mismatch of names. My reply was to get permission to generate a key pair himself but name it as being owned by the government. If he didn't, no one else would know he was authorized to sign the data. If he did, resolvers would trust by default his signatures. >Also much confusion stems from the statement in the introduction of the >Draft, that "a delegating zone is required to indicate whether a child >zone is secured". >In general this is not true, as the zone itself is responsible for its >security. There is one and only one special and temporal case when a >parent must indicate that a child is unsecure: > when a parent zone converts from unsecure to secure, while its childs > have no KEY (or NULL-KEY) yet. A parent MUST indicate whether a child is secure or not, for some definition of secure. Assume a resolver gets an unsigned A record for a piece of data that should be signed. The resolver only knows that no SIG has arrived, so it needs to set out to determine if there should have been a SIG. Starting from some already known-to-be-secure (grand)parent of the target zone, the resolver has to decend to see if the secure chain is maintained. Once the chain is broken, all zones below are considered unsecured, whether or not they are signed. Note that this assume on-tree validation. During this search down through zones, it is possible to ask either the upper half of a delegation whether the next step is secure or ask the lower half of the delegation whether it is secure. If we rely on asking the zone directly (the lower half), we are open to zone-jacking attacks. An unsecured zone could be replaced by a maliciously signed zone. Either this would result in a denial of acceptance of data as the signatures wouldn't be accepted (no chain of trust), or, if off-tree validation is improperly allowed, the zone-jacked data may be accepted over the true data. A converse attack is also possible. If the true zone is secured and claims itself to be, a zone-jacker could put up an unsigned, unsecured replacement. In this case, the malicious zone would not have the problem of trying generate signatures. This is why a delegating zone must indicate (implicitly or explicitly) whether it's delegee is secure. Now, if off-tree validation is allowed, this very hard to do, which is why I bothered to include on-tree validation as a prerequisite for now. (I do have a research vehicle on the horizon to address off-tree validation issues.) >Proposed terms and definitions. > >Assuming correct configurations only, we would like to define: > A zone is "Secured" then and only then if the resolver expects a zone > KEY for this zone and finds it to be a non-NULL KEY. But, how does a resolver know to "expect" a zone key? The answer I have in mind is through the proposed key-bit, or by implicit returns from the parent zone. > A zone is "Unsecured" if no zone KEY is expected or a NULL-KEY is found. > >These "Secured" and "Unsecured" definitions can be viewed from the >perspective from the two parties involved to clarify what must be done: > >The zone administrator that wants his zone to be "Secured" >- needs to generate a zone KEY, and have this KEY signed or advertized in > such a way that the resolvers of interest expect it and can verify it; What you are saying here is true, but defining "such a way that...expect" is not so easy. This is where this draft sits in the problem space. I am trying to clarify what "such a way" means - and finding that for a single admin to do this, s/he must rely on others to cooperate. Whether they cooperate or not is the dividing line that drives my two kinds of security. >We read from RFC 2535 that it supports a general mechanisme of >verification, and also describes a specific possible implementation: along >the reverse of the delegation path. We view it as very important that the >general mechanisme is fully retained. The problem with the general mechanism is that it is open to far too many vulernabilities. I agree that the generality is desired, but I see this as part of an evolutionary process. In the early stages of DNSSEC (or any secure system), you can choose to be tight and loosen rules as time goes on, or do the reverse, start loose and tighten as time goes on. I am choosing to push a tight start and research ways into loosening the rules. The main reason is tied to software revisions. If older revisions are looser than new ones, then folks who don't upgrade may be open to some attacks. Also, attackers could use the looser software to create problems. By starting with tight rules and loosening them in later releases, we accomplish a few things. One is that we have more time to understand 1) what desired loosness truely exists, and 2) the impact of the looser rules. Also, we now have a means to encourage folks to upgrade. (Instead of upgrade of you risk problems, it's upgrade and you better stuff.) >Also note that we make no mention about the algorithms that are used. It >is up to the zone administrator and with the producers of the resolvers of >interest to choose the most suitible algorithms. This is a bit of a different issue. I don't want to push any algorithm. However, in the workshops, there has been a point of confusion when we mix folks who use just one of the two currently available algortihms. I want to stress that this is an issue amongst "mandatory to implement" algorithms and algorithms that are not. This isn't an RSA vs. DSA issue, or an issue of whether some secret agency wants to use a "superior" digital signature technology. >Proposed updates to RFC 2535. > >In 2.a of the Draft is a proposal to update RFC 2535-3.1.3 on the >requirement of the protocol field. We don't see the need for this update >as RFC 2535 is already clear on this matter (see detail number 3 in RFC >2535-3.1.3). The (albeit few) implementers I spoke too don't agree that the wording if the RFC is a good idea. Just about all code I've come across, mine and others, checks that value anyway. As far as the RFC, it takes a half-dozen lines to describe what should be said in one line. >In 2.1.c is a proposal to update RFC 2535-2.3.2 on the requirement to use >NXT RRs. On reading RFC 2535 carefully it is clear that this requirement >is already there (see RFC 2535-5.3) and is also already implicated by the >signing process itself. Therefore, if their remains any doubt about this, >a clarification should suffice. That's what this update is about. There are far too many times a "careful" reading is required to understand the finer points of the standard. (Section 5.3 is "Additional Complexity Due to Wildcards" which isn't the place I'd stick in a "must use NXTs.") >In 2.1.d is a proposal to update RFC 2535-2.3.1 on signing each RR, and >using a Mandatory to Implement algorithm. The former part of this >requirement is already in RFC 2535 (see 2.3.1, 2.3.4, and 3.1.1). So this >part of the update is unnecessary. The latter part of this proposed, new >requirement severly restricts the DNS Security Extension by disallowing >other algorithm than DSA, including the Recommended to Implement >algorithms (as RSA). This part of the proposed update is undesirable. >In 2.2.d the first part of the same proposal is repeated, which is >again an update that is unnecessary. There is misinterpretation going on here. This "must" only applies to being fully secured, as opposed to being partly secured (or whatever words are now in use). Note that in 2.2 this isn't a requirement. >In 3.1 a "Child Has Keys" bit is introduced which updates at least RFC >2535-2.3.4. In contrast to the proposed name of this bit, it appears on >careful reading, that this proposed bit signals that "The Parent Has >Signed The KEY Of This Child". This is very different from its name, and >it defeats the possibility of any other verification mechanisme than the >special case along the reverse of the delegation path. So this is a major >update of the DNS Security Extension. We feel that the disavantage of the >limitation of the original general verification mechanisme significantly >outweights the advantage of having a somewhat smaller parent zone for some >time after the conversion from Unsecured to Secured. We therefore >conclude that this update is undesirable. This is the section that will be revised to say "the bit is one if the parent says the child is secure, zero otherwise." This change is based on a conversation with BIND developers (who *still* owe me emailed comments). As far as restricting other verification meachanisms, I think I already addressed that. >In 5 is a proposal to update RFC 2535-3.4 on the experimental status. The >need for this update disappears when the functionality of the NULL-KEY is >retained. We are trying hard to drop the NULL key. The main reason is that it is now required for indicating a zone below is unsecured, the impact is that it is another record a parent has to sign. By removing the NULL key, we remove a SIG from the parent. Although this is crucial to just a few zones, e.g., .com, adoption by these zone are crucial to the use of DNSSEC. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "It takes years of training to know when to do nothing" - Dogbert 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 Sat May 13 22:06:04 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14760 for ; Sat, 13 May 2000 22:06:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12qmv0-000MXb-00 for namedroppers-data@psg.com; Sat, 13 May 2000 18:10:06 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12qmv0-000MXV-00 for namedroppers@ops.ietf.org; Sat, 13 May 2000 18:10:06 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12qmv0-000HbO-00 for namedroppers@ops.ietf.org; Sat, 13 May 2000 18:10:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 13 May 2000 18:09:52 -0700 Subject: RFC 2782 questions From: Stuart Cheshire To: Message-Id: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Greetings all. I'm new to the namedroppers list, though some of you may know me through the ZEROCONF work. I've been reading RFC 2782, and a few things are not clear to me. I have several questions, but I will restrict myself to one question per email, or things will get very confusing. The first is here; the remainder will follow in separate messages. > In general, it is expected that SRV records will be used by clients > for applications where the relevant protocol specification indicates > that clients should use the SRV record. Such specification MUST > define the symbolic name to be used in the Service field of the SRV > record as described below. It also MUST include security > considerations. Service SRV records SHOULD NOT be used in the absence > of such specification. This seems to imply that I SHOULD NOT write a new web browser that uses an SRV lookup for _http._tcp.example.com to locate a web server, because HTTP does not specify the use of SRV records. Is that the intention of this text? If so, why? Stuart 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 Sat May 13 22:06:07 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14771 for ; Sat, 13 May 2000 22:06:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12qnCR-000MlL-00 for namedroppers-data@psg.com; Sat, 13 May 2000 18:28:07 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12qnCQ-000MlF-00 for namedroppers@ops.ietf.org; Sat, 13 May 2000 18:28:06 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12qnCQ-000Hh9-00 for namedroppers@ops.ietf.org; Sat, 13 May 2000 18:28:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 13 May 2000 18:27:29 -0700 Subject: RFC 2782: The format of SRV names From: Stuart Cheshire To: Message-Id: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Proto > The symbolic name of the desired protocol, with an underscore > (_) prepended to prevent collisions with DNS labels that occur > in nature. _TCP and _UDP are at present the most useful values > for this field, though any name defined by Assigned Numbers or > locally may be used (as for Service). The Proto is case > insensitive. Does this really mean ANY name? How about "_smtp._http.example.com"? (Mail tunnelled over http) Along those lines, can the protocol or service contain dots? What about "_smtp._http._tcp.example.com" (Mail tunnelled over http which runs over tcp)? What about "_telnet.example.com" (telnet only runs over tcp, so it is redundant and unnecessary to specify that in the SRV)? Is there a strong reason why the name of an SRV record is restricted to the specific syntax of "_firstpart._secondpart.name"? Stuart 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 Sat May 13 22:21:06 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14808 for ; Sat, 13 May 2000 22:21:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12qnLx-000MwR-00 for namedroppers-data@psg.com; Sat, 13 May 2000 18:37:57 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12qnLx-000MwL-00 for namedroppers@ops.ietf.org; Sat, 13 May 2000 18:37:57 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12qnLx-000Hkh-00 for namedroppers@ops.ietf.org; Sat, 13 May 2000 18:37:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 13 May 2000 18:38:21 -0700 Subject: RFC 2782: The SRV RR is unique... From: Stuart Cheshire To: Message-Id: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Name > The domain this RR refers to. The SRV RR is unique in that the > name one searches for is not this name; the example near the end > shows this clearly. I don't understand what this is trying to say, and the example near the end did not help. It it just saying that the *name* of the SRV record is the complete thing, "_Service._Proto.Name", rather than just the part *labeled* "Name"? If so, perhaps the RFC should use the notation Name = "_Service._Proto.Domain", make it clear that the name of the SRV record is the whole thing, not just the trailing part. Stuart 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 Sat May 13 22:29:12 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14845 for ; Sat, 13 May 2000 22:29:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12qnU9-000N5v-00 for namedroppers-data@psg.com; Sat, 13 May 2000 18:46:25 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12qnU9-000N5p-00 for namedroppers@ops.ietf.org; Sat, 13 May 2000 18:46:25 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12qnU8-000HnR-00 for namedroppers@ops.ietf.org; Sat, 13 May 2000 18:46:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 13 May 2000 18:45:57 -0700 Subject: RFC 2782: Off-by-one bug in weighting algorithm From: Stuart Cheshire To: Message-Id: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > 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. When the RFC says "choose a uniform random number..." it doesn't say whether it should be a real number or an integer. 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 other SRV records remain at the same priority) is strictly zero, which is fine, and logical. However, most implementers are likely to select a random *integer* (which is also suggested by the use of the word "inclusive") and this leads to the following off-by-one bug: Suppose you have two SRV records, one with weight zero and one with weight one: _smtp._tcp.apple.com 0 IN SRV 0 0 25 backup.apple.com _smtp._tcp.apple.com 0 IN SRV 0 1 25 mailer.apple.com Sorted List: backup.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)", the values 0 and 1 are equally likely: Value 0 selects backup.apple.com (Running Sum 0 is >= 0) Value 1 selects mailer.apple.com (Running Sum 1 is >= 1) In this example, "mailer" and "backup" are equally likely to be selected (and hence get half the mail load each) which was probably not what the sysadmin had in mind when he or she set up relative weights of zero and one. (I realize the desired effect here could have been achieved using different priorities, but the point I'm making is that the weights, as given in this example, do not yield the intuitive result.) To give another example, consider this, where each SRV has the same 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)", the values 0, 1 and 2 are all equally likely: Value 0 selects mailer1.apple.com (Running Sum 1 is >= 0) Value 1 selects mailer1.apple.com (Running Sum 1 is >= 1) Value 2 selects mailer1.apple.com (Running Sum 2 is >= 2) Here, "mailer1" gets twice as much load as "mailer2" -- again, probably not what the sysadmin had in mind when he or she set up equal relative 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 numbers, and it is the extra "+1" that is skewing the results. The text can be 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. > > 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. Stuart 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 Sat May 13 22:29:27 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14856 for ; Sat, 13 May 2000 22:29:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12qnWl-000N9d-00 for namedroppers-data@psg.com; Sat, 13 May 2000 18:49:07 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12qnWl-000N9X-00 for namedroppers@ops.ietf.org; Sat, 13 May 2000 18:49:07 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12qnWl-000HoZ-00 for namedroppers@ops.ietf.org; Sat, 13 May 2000 18:49:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200005140148.VAA04500@small-gods.mit.edu> To: Stuart Cheshire cc: namedroppers@ops.ietf.org Subject: Re: RFC 2782 questions In-Reply-To: Your message of "Sat, 13 May 2000 18:09:52 PDT." Date: Sat, 13 May 2000 21:48:34 -0400 From: Greg Hudson Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > This seems to imply that I SHOULD NOT write a new web browser that > uses an SRV lookup for _http._tcp.example.com to locate a web > server, because HTTP does not specify the use of SRV records. Is > that the intention of this text? If so, why? That is precisely the intention of the text (and was the subject of a little disagreement). The rationale is that blindly implementing SRV for existing protocols could cause problems; for example, in the absence of negative caching, your new web browser could significantly increase the amount of DNS traffic on the Internet. By encouraging people not to implement in absence of some kind of specification process, the area directors in particular hoped to get people to think about possible problems earlier rather than later. to unsubscribe send a message to 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 May 13 22:29:31 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14867 for ; Sat, 13 May 2000 22:29:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12qnUI-000N65-00 for namedroppers-data@psg.com; Sat, 13 May 2000 18:46:34 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12qnUH-000N5z-00 for namedroppers@ops.ietf.org; Sat, 13 May 2000 18:46:33 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12qnUH-000HnW-00 for namedroppers@ops.ietf.org; Sat, 13 May 2000 18:46:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 13 May 2000 18:46:25 -0700 Subject: RFC 2782: Name compression for the target host From: Stuart Cheshire To: Message-Id: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Target > The domain name of the target host. There MUST be one or more > address records for this name, the name MUST NOT be an alias (in > the sense of RFC 1034 or RFC 2181). Implementors are urged, but > not required, to return the address record(s) in the Additional > Data section. Unless and until permitted by future standards > action, name compression is not to be used for this field. Why is name compression not used (especially given some of the previous comments on this list about wastage of space in DNS packets)? Stuart 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 Sat May 13 22:29:49 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14878 for ; Sat, 13 May 2000 22:29:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12qnX7-000NAD-00 for namedroppers-data@psg.com; Sat, 13 May 2000 18:49:29 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12qnX6-000NA7-00 for namedroppers@ops.ietf.org; Sat, 13 May 2000 18:49:28 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12qnX6-000Hon-00 for namedroppers@ops.ietf.org; Sat, 13 May 2000 18:49:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 13 May 2000 18:49:36 -0700 Subject: RFC 2782: Usage rules From: Stuart Cheshire To: Message-Id: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Usage rules > > A SRV-cognizant client SHOULD use this procedure to locate a list of > servers and connect to the preferred one: > > Do a lookup for QNAME=_service._protocol.target, QCLASS=IN, > QTYPE=SRV. Everywhere else in the RFC, the term "target" is used to refer to a component of the value of the SRV RR (the thing that appears on the right-hand side), whereas here it is being used to refer to a sub-part of the name of the SRV RR (the thing that appears on the left-hand side). It might be clearer to say: "Do a lookup for QNAME=_service._protocol.domain, QCLASS=IN,..." Stuart 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 Sat May 13 22:29:51 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14889 for ; Sat, 13 May 2000 22:29:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12qngF-000NSE-00 for namedroppers-data@psg.com; Sat, 13 May 2000 18:58:55 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12qngE-000NS6-00 for namedroppers@ops.ietf.org; Sat, 13 May 2000 18:58:54 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12qngE-000HsA-00 for namedroppers@ops.ietf.org; Sat, 13 May 2000 18:58:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200005140158.SAA35785@redpaul.mibh.net> To: namedroppers@ops.ietf.org Subject: Re: RFC 2782: The SRV RR is unique... In-reply-to: Your message of "Sat, 13 May 2000 18:38:21 PDT." Date: Sat, 13 May 2000 18:58:02 -0700 From: Paul A Vixie Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > ... It it just saying that the *name* of the SRV record is the > complete thing, "_Service._Proto.Name", rather than just the part *labeled* > "Name"? If so, perhaps the RFC should use the notation Name = > "_Service._Proto.Domain", make it clear that the name of the SRV record is > the whole thing, not just the trailing part. yes. to unsubscribe send a message to 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 May 13 22:30:15 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14956 for ; Sat, 13 May 2000 22:30:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12qnaw-000NHh-00 for namedroppers-data@psg.com; Sat, 13 May 2000 18:53:26 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12qnaw-000NHb-00 for namedroppers@ops.ietf.org; Sat, 13 May 2000 18:53:26 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12qnaw-000Hpr-00 for namedroppers@ops.ietf.org; Sat, 13 May 2000 18:53:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200005140152.SAA35736@redpaul.mibh.net> To: namedroppers@ops.ietf.org Subject: Re: RFC 2782: The format of SRV names In-reply-to: Your message of "Sat, 13 May 2000 18:27:29 PDT." Date: Sat, 13 May 2000 18:52:36 -0700 From: Paul A Vixie Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > How about "_smtp._http.example.com"? (Mail tunnelled over http) > Along those lines, can the protocol or service contain dots? What about > "_smtp._http._tcp.example.com" (Mail tunnelled over http which runs over > tcp)? those cases weren't considered when SRV was first specified. they are perfectly natural extensions, assuming an RFC is written about them. > What about "_telnet.example.com" (telnet only runs over tcp, so it is > redundant and unnecessary to specify that in the SRV)? redundant or not, the existing naming specification requires the _tcp there. > Is there a strong reason why the name of an SRV record is restricted to the > specific syntax of "_firstpart._secondpart.name"? that's all we envisioned or needed at the time of the specification. we did not intend to limit future extensive specifications. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat May 13 22:31:22 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15339 for ; Sat, 13 May 2000 22:31:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12qnfu-000NQe-00 for namedroppers-data@psg.com; Sat, 13 May 2000 18:58:34 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12qnfu-000NQX-00 for namedroppers@ops.ietf.org; Sat, 13 May 2000 18:58:34 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12qnfu-000Hru-00 for namedroppers@ops.ietf.org; Sat, 13 May 2000 18:58:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200005140157.VAA04543@small-gods.mit.edu> To: Stuart Cheshire cc: namedroppers@ops.ietf.org Subject: Re: RFC 2782: The format of SRV names In-Reply-To: Your message of "Sat, 13 May 2000 18:27:29 PDT." Date: Sat, 13 May 2000 21:57:32 -0400 From: Greg Hudson Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> _TCP and _UDP are at present the most useful values for this field, >> though any name defined by Assigned Numbers or locally may be used >> (as for Service). The Proto is case insensitive. > Does this really mean ANY name? My reading would be "any name in ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers", although it could be clearer. > How about "_smtp._http.example.com"? (Mail tunnelled over http) > Along those lines, can the protocol or service contain dots? What > about "_smtp._http._tcp.example.com" (Mail tunnelled over http which > runs over tcp)? By my reading, no, none of these are allowed, except for the first one on a local basis. > What about "_telnet.example.com" (telnet only runs over tcp, so it > is redundant and unnecessary to specify that in the SRV)? Again, bad. If half the world decides the _tcp is "redundant and unnecessary" and half doesn't, we have an interoperability problem. (And it would be the fault of the first half, since they would be violating the RFC.) > Is there a strong reason why the name of an SRV record is restricted > to the specific syntax of "_firstpart._secondpart.name"? I don't know if there's a strong reason. The authors were probably not envisioning tunneling and other forms of multilayered transports; I suspect the second part is only there for the sake of protocols like SIP (RFC 2543) which can run over both TCP and UDP. to unsubscribe send a message to 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 May 13 22:35:41 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15874 for ; Sat, 13 May 2000 22:35:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12qnje-000NYS-00 for namedroppers-data@psg.com; Sat, 13 May 2000 19:02:26 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12qnje-000NYM-00 for namedroppers@ops.ietf.org; Sat, 13 May 2000 19:02:26 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12qnjd-000HtH-00 for namedroppers@ops.ietf.org; Sat, 13 May 2000 19:02:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200005140201.WAA04580@small-gods.mit.edu> To: Stuart Cheshire cc: namedroppers@ops.ietf.org Subject: Re: RFC 2782: The SRV RR is unique... In-Reply-To: Your message of "Sat, 13 May 2000 18:38:21 PDT." Date: Sat, 13 May 2000 22:01:41 -0400 From: Greg Hudson Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> Name The domain this RR refers to. The SRV RR is unique in that >> the name one searches for is not this name; the example near the >> end shows this clearly. > I don't understand what this is trying to say, and the example near > the end did not help. It it just saying that the *name* of the SRV > record is the complete thing, "_Service._Proto.Name", rather than > just the part *labeled* "Name"? Yes. (For other record types, you query the name you're interested in directly; the SRV record is the first one where you stick stuff on the front first.) to unsubscribe send a message to 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 May 13 22:41:40 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15986 for ; Sat, 13 May 2000 22:41:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12qnqO-000NnG-00 for namedroppers-data@psg.com; Sat, 13 May 2000 19:09:24 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12qnqO-000NnA-00 for namedroppers@ops.ietf.org; Sat, 13 May 2000 19:09:24 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12qnqO-000HvQ-00 for namedroppers@ops.ietf.org; Sat, 13 May 2000 19:09:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200005140206.WAA04611@small-gods.mit.edu> To: Stuart Cheshire cc: namedroppers@ops.ietf.org Subject: Re: RFC 2782: Name compression for the target host In-Reply-To: Your message of "Sat, 13 May 2000 18:46:25 PDT." Date: Sat, 13 May 2000 22:06:59 -0400 From: Greg Hudson Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Why is name compression not used (especially given some of the > previous comments on this list about wastage of space in DNS > packets)? Global compression on the record would break caching; a cache which doesn't understand SRV records wouldn't know to pull out the compressed names. Local compression was nixed in this group, for reasons I don't remember well enough to recap. to unsubscribe send a message to 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 May 14 02:34:15 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29038 for ; Sun, 14 May 2000 02:34:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12qrFu-0002G5-00 for namedroppers-data@psg.com; Sat, 13 May 2000 22:47:58 -0700 Received: from roam.psg.com ([147.28.0.38]) by psg.com with esmtp (Exim 3.13 #1) id 12qrFr-0002Fk-00 for namedroppers@ops.ietf.org; Sat, 13 May 2000 22:47:55 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12pZCf-0000jl-00 for namedroppers@ops.ietf.org; Wed, 10 May 2000 18:19:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3918687D.197F0D3F@daimlerchrysler.com> Date: Tue, 09 May 2000 15:35:25 -0400 From: Kevin Darcy To: namedroppers@ops.ietf.org Subject: Re: Unfinished DNS UPDATE work... References: <20000508001323.17055.qmail@frcs.alt.za> <3561.957811914@frcs.alt.za> <20000509032828.17676.qmail@frcs.alt.za> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > [ this is the last message on this subject i plan to approve on > namedroppers. folk, please take it to dnsop or elsewhere. -- rabdy ] Whoa, wait just a minute there! Could we at least call for a rough concensus on whether the ban on SOA addition/deletion should be excised in 2136bis? If nothing else in this thread, *that* is strictly a protocol issue. - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun May 14 10:21:31 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08509 for ; Sun, 14 May 2000 10:21:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12qyhX-00099r-00 for namedroppers-data@psg.com; Sun, 14 May 2000 06:44:59 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12qyhW-00099l-00 for namedroppers@ops.ietf.org; Sun, 14 May 2000 06:44:58 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12qyhW-000LFk-00 for namedroppers@ops.ietf.org; Sun, 14 May 2000 06:44:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 14 May 2000 9:42:28 EDT From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: Paul A Vixie Cc: namedroppers@ops.ietf.org Subject: Re: RFC 2782: The format of SRV names In-Reply-To: Your message of Sat, 13 May 2000 18:52:36 -0700 Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > How about "_smtp._http.example.com"? (Mail tunnelled over http) > > Along those lines, can the protocol or service contain dots? What about > > "_smtp._http._tcp.example.com" (Mail tunnelled over http which runs over > > tcp)? > > those cases weren't considered when SRV was first specified. they are > perfectly natural extensions, assuming an RFC is written about them. > > > Is there a strong reason why the name of an SRV record is restricted to the > > specific syntax of "_firstpart._secondpart.name"? > > that's all we envisioned or needed at the time of the specification. we > did not intend to limit future extensive specifications. In the case of the Kerberos DNS SRV spec we needed to specify subclasses. Our conclusion was that it would in appropriate to increase the number of segments due to the fact that eventually someone will extend the resolv library to include a function to return the SRV data which takes the "service" and the "protocol" as the only parameters (without the underscore prefixes). It would be unclear how a multisegment service name would be passed to the function. Our conclusion was that service names with multiple parts should be separated with dashes. _smtp-http._tcp.example.com for instance. Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * kermit-support@kermit-project.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 Sun May 14 10:21:36 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08520 for ; Sun, 14 May 2000 10:21:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12qyhe-0009A0-00 for namedroppers-data@psg.com; Sun, 14 May 2000 06:45:06 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12qyhe-00099u-00 for namedroppers@ops.ietf.org; Sun, 14 May 2000 06:45:06 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12qyhd-000LFp-00 for namedroppers@ops.ietf.org; Sun, 14 May 2000 06:45:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 14 May 2000 9:44:02 EDT From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: Greg Hudson Cc: Stuart Cheshire , namedroppers@ops.ietf.org Subject: Re: RFC 2782: The format of SRV names In-Reply-To: Your message of Sat, 13 May 2000 21:57:32 -0400 Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > What about "_telnet.example.com" (telnet only runs over tcp, so it > > is redundant and unnecessary to specify that in the SRV)? > > Again, bad. If half the world decides the _tcp is "redundant and > unnecessary" and half doesn't, we have an interoperability problem. > (And it would be the fault of the first half, since they would be > violating the RFC.) Besides, there may eventually be a version of telnet that runs on top of some protocol other than TCP. Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * kermit-support@kermit-project.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 Sun May 14 11:34:45 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08912 for ; Sun, 14 May 2000 11:34:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12r014-000AU6-00 for namedroppers-data@psg.com; Sun, 14 May 2000 08:09:14 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12r014-000AU0-00 for namedroppers@ops.ietf.org; Sun, 14 May 2000 08:09:14 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12r014-000LbJ-00 for namedroppers@ops.ietf.org; Sun, 14 May 2000 08:09:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: References: Date: Sun, 14 May 2000 16:58:48 +0200 To: Stuart Cheshire , From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: RFC 2782 questions Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 18.09 -0700 00-05-13, Stuart Cheshire wrote: >This seems to imply that I SHOULD NOT write a new web browser that uses an >SRV lookup for _http._tcp.example.com to locate a web server, because HTTP >does not specify the use of SRV records. Is that the intention of this text? >If so, why? That is correct. Someone have to write the text, even if it is short, on how/where the SRV resolution is to be done when you take an HTTP URI and resolve it. Think especially about relative URI, and the discussions about how to find the base...it is not so simple as one might think. Also, in the registration of port numbers, I find the following: >http 80/tcp World Wide Web HTTP >http 80/udp World Wide Web HTTP >www 80/tcp World Wide Web HTTP >www 80/udp World Wide Web HTTP >www-http 80/tcp World Wide Web HTTP >www-http 80/udp World Wide Web HTTP Which one of the words to the left is to be used? It might be a simple task to write the text, but it has to be done. Patrik to unsubscribe send a message to 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 May 14 17:36:22 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11435 for ; Sun, 14 May 2000 17:36:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12r5Wn-000G63-00 for namedroppers-data@psg.com; Sun, 14 May 2000 14:02:21 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 12r5Wl-000G5x-00 for namedroppers@ops.ietf.org; Sun, 14 May 2000 14:02:20 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12r5Wn-0001Uu-00 for namedroppers@ops.ietf.org; Sun, 14 May 2000 14:02:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 14 May 2000 14:31:53 -0400 From: Andrew Brown To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: namedroppers@ops.ietf.org Subject: Re: RFC 2782 questions Message-ID: <20000514143153.A16621@noc.untraceable.net> Reply-To: Andrew Brown References: In-Reply-To: ; from paf@swip.net on Sun, May 14, 2000 at 04:58:48PM +0200 X-Hi-To-All-My-Friends-In-Domestic-Surveillance: hi there, sports fans :) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>http 80/tcp World Wide Web HTTP >>http 80/udp World Wide Web HTTP >>www 80/tcp World Wide Web HTTP >>www 80/udp World Wide Web HTTP >>www-http 80/tcp World Wide Web HTTP >>www-http 80/udp World Wide Web HTTP > >Which one of the words to the left is to be used? imho, http is the protocol or service name (and should be used in the srv records), www is the function, and www-http is just plain wrong. -- |-----< "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 Sun May 14 17:45:43 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11507 for ; Sun, 14 May 2000 17:45:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12r5OR-000Fw7-00 for namedroppers-data@psg.com; Sun, 14 May 2000 13:53:43 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 12r5OQ-000Fw1-00 for namedroppers@ops.ietf.org; Sun, 14 May 2000 13:53:42 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12r5OL-0001UE-00 for namedroppers@ops.ietf.org; Sun, 14 May 2000 13:53:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Stuart Cheshire Cc: namedroppers@internic.net Subject: Re: RFC 2782: Off-by-one bug in weighting algorithm In-Reply-To: Your message of "Sat, 13 May 2000 18:45:57 MST." Date: Mon, 15 May 2000 01:33:47 +1000 Message-Id: <12668.958318427@mundamutti.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Sat, 13 May 2000 18:45:57 -0700 From: Stuart Cheshire Message-ID: | When the RFC says "choose a uniform random number..." it doesn't say whether | it should be a real number or an integer. 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 other SRV records remain at the same | priority) is strictly zero, which is fine, and logical. The intent was that it be a real number, without requiring the actual use of floating point arithmetic. Using integer arithmetic the same basic effect needs to be achieved. One way might be to use 32 bit integers, with the weight values multiplied by 10000 (ie: effectively fixed point arithmetic). Simply doing dumb integer arithmetic on the basic weight values is likely to produce anomalies, as you noticed. 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 May 16 17:43:41 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12975 for ; Tue, 16 May 2000 17:43:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12roGf-000GFi-00 for namedroppers-data@psg.com; Tue, 16 May 2000 13:48:41 -0700 Received: from pub187.ripemtg.ripe.net ([193.0.5.187]) by psg.com with esmtp (Exim 3.13 #1) id 12roGe-000GFZ-00 for namedroppers@ops.ietf.org; Tue, 16 May 2000 13:48:41 -0700 Received: from randy by pub187.ripemtg.ripe.net with local (Exim 3.12 #1) id 12roGc-0000XB-00 for namedroppers@ops.ietf.org; Tue, 16 May 2000 22:48:38 +0200 Message-Id: <200005161030.GAA00548@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-simple-secure-update-01.txt Date: Tue, 16 May 2000 06:30:57 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Simple Secure Domain Name System (DNS) Dynamic Update Author(s) : B. Wellington Filename : draft-ietf-dnsext-simple-secure-update-01.txt Pages : 8 Date : 15-May-00 This document proposes a method for performing secure Domain Name System (DNS) dynamic updates. The method described here is intended to be flexible and useful while requiring as few changes to the protocol as possible. The authentication of the dynamic update message is separate from later DNSSEC validation of the data. Secure communication based on authenticated requests and transactions is used to provide authorization. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-simple-secure-update-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-simple-secure-update-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-simple-secure-update-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: <20000515095018.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-simple-secure-update-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-simple-secure-update-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000515095018.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 May 16 17:44:45 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12990 for ; Tue, 16 May 2000 17:44:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12roGZ-000GFX-00 for namedroppers-data@psg.com; Tue, 16 May 2000 13:48:35 -0700 Received: from pub187.ripemtg.ripe.net ([193.0.5.187]) by psg.com with esmtp (Exim 3.13 #1) id 12roGY-000GFM-00 for namedroppers@ops.ietf.org; Tue, 16 May 2000 13:48:34 -0700 Received: from randy by pub187.ripemtg.ripe.net with local (Exim 3.12 #1) id 12roGV-0000X9-00 for namedroppers@ops.ietf.org; Tue, 16 May 2000 22:48:31 +0200 Message-Id: <200005161030.GAA00531@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-signing-auth-01.txt Date: Tue, 16 May 2000 06:30:51 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Domain Name System Security (DNSSEC) Signing Authority Author(s) : B. Wellington Filename : draft-ietf-dnsext-signing-auth-01.txt Pages : 7 Date : 15-May-00 This document proposes a revised model of Domain Name System Security (DNSSEC) Signing Authority. The revised model is designed to clarify earlier documents and add additional restrictions to simplify the secure resolution process. Specifically, this affects the authorization of keys to sign sets of records. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-signing-auth-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-signing-auth-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-signing-auth-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: <20000515095001.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-signing-auth-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-signing-auth-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000515095001.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 May 18 11:24:54 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08605 for ; Thu, 18 May 2000 11:24:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12sR2u-000GEQ-00 for namedroppers-data@psg.com; Thu, 18 May 2000 07:13:04 -0700 Received: from pub187.ripemtg.ripe.net ([193.0.5.187]) by psg.com with esmtp (Exim 3.13 #1) id 12sR2s-000GDs-00 for namedroppers@ops.ietf.org; Thu, 18 May 2000 07:13:03 -0700 Received: from randy by pub187.ripemtg.ripe.net with local (Exim 3.12 #1) id 12sR2k-00036p-00 for namedroppers@ops.ietf.org; Thu, 18 May 2000 16:12:54 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200005181350.IAA14958@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com cc: namedroppers@ops.ietf.org From: "Matt Crawford" Subject: Re: I-D ACTION:draft-ietf-ipngwg-dns-lookups-08.txt In-reply-to: Your message of Thu, 18 May 2000 06:54:56 EDT. <200005181055.GAA02231@ietf.org> Date: Thu, 18 May 2000 08:50:23 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Differences between -07 and -08 are: IP6.INT -> IP6.ARPA for new style (bit based rather than nibble based) reverse lookups. + Implementers are reminded of the necessity to limit the + amount of work a resolver will perform in response to a + client request. This principle MUST be extended to also + limit the generation of DNS requests in response to one + name-to-address (or address-to-name) lookup request. Fixed a misformatted references. to unsubscribe send a message to 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 May 20 01:01:28 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15695 for ; Sat, 20 May 2000 01:01:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12t0Gf-00002r-00 for namedroppers-data@psg.com; Fri, 19 May 2000 20:49:37 -0700 Received: from mg-206253200-87.ricochet.net ([206.253.200.87] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 12t0Gc-00002f-00 for namedroppers@ops.ietf.org; Fri, 19 May 2000 20:49:35 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12swJy-0000am-00 for namedroppers@ops.ietf.org; Fri, 19 May 2000 16:36:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: References: Date: Fri, 19 May 2000 14:49:56 -0400 To: Roy Arends From: Edward Lewis Subject: Re: Remarks on the DNS Security Extension Clarification on Zone Status draft Cc: Edward Lewis , namedroppers Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 9:46 AM -0400 5/19/00, Roy Arends wrote: >Comments by Roy Arends and Ted Lindgreen from NLnet Labs When I came to work today, I was planning on updating the draft. When I went search for your previous message, this arrived in my in-box. What timing! There's a lot of substance in here. I'll try to address some of it now and leave more when I can better express some of my thoughts. >1. You see the result of the implementation of secured DNS as a > completely secured tree, starting at the root. For the sake of interoperability, I hope so. If you publish data in such a way that is seen as secure to only a subset of the users, then you are probably going to be seen as unsecured to the rest. Hence, the zone is spoofable to the rest. Granted, what the rest of the world sees of your zone may not be important. There's a counter example which I'll put into another message - the example was related to me last fall during a workshop. > Part of the DNS tree, perhaps including the root, may not be > secured at all for quite some time. I agree with this. Your statements on secure roots, secure trees that drop into unsecured trees, and not back, are right on. I did some work on this a few years ago and noticed this. I didn't reflect this in the draft because, well, it's a lot of work to fully explain. >2. You introduce levels of security. We think that a zone is either > secure or not and nothing in between. Perhaps this is caused by > an approach to the zone from the eyes of the zone administrator > who wants to secure his zone as good as possible but is limited > by his span of control. We approach it from a resolver point of > view with staticly configured KEYS for defined secure entry-points > into the DNS tree. Yes. Maybe this is a way to visualize what's going on: Server Resolver (zone1) Secure<---------->Secure (zone2) Secure<---------->UnSecure (something happened external to zone) (zone3) Unsecure<-------->Unsecure Zone1 is fully secure, both the server and resolver see it as secure. Zone2 is partly secure, the server has signed the zone but the resolver can't validate it. Zone 3 is just unsecure. In the draft, I am not creating levels of security within the protocol. I am trying to identify the Zone 2 situation to alert zone admins that certain actions will make an otherwise secure zone seem unsecure. The draft is merely trying to label a potential problems spot. >3. You state that "a parent MUST indicate whether a child is secure > or not". We have studied this matter in detail, and read all the > communications on this we could find, including the comments from > Donald Eastlake (author of RFC 2535) on the previous version of > this Draft. Our conclusion is that this statement is incorrect. > We explain below. I am not sure how to answer this. When I say that "a parent MUST indicate," the indication may be implicit. RFC 2535 implicitly indicates a secure child. RFC 2535 conveys "if the parent is secure, assume the child is too, unless you see a NULL key." I would prefer that implicit notification of security not be used, this is a feeling shared by some. However, what RFC 2535 says meets the need, so justifying a change is not reasonable. Do you still disagree with the "MUST" above? >4. You state that off-tree validation opens the possibility to > "zone-jacking" attacks. The opening you have described does not > exits when RFC 2535 is properly applied. > However, attacks are possible in both cases, but may be more > severe in the on-tree than in the off-tree case. This could take a long time to explain. One problem is that the policy in RFC section 6 is not generally accepted, and didn't achieve consensus of the WG when the document went to the IESG a few years ago. I recall a promise that section 6 was to be removed, obviously it wasn't. You are right that the zone-jacking example wouldn't succeed if the policy there is applied correctly. I picked a bad example, one that was based on another version of the policy that was discussed a while back. I need to refresh my memory more often. The problems with the written ("recommended") policy include this: The first clause usurps the delegation of the child zone by the parent. In other words, although .example might delegate army.example, .example has the right to sign www.subdept.army.example. What if subdept.army.example's delegation is suspended by army.example? The signed data still exists. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "It takes years of training to know when to do nothing" - Dogbert 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 Sat May 20 01:08:32 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16202 for ; Sat, 20 May 2000 01:08:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12t0GL-00002W-00 for namedroppers-data@psg.com; Fri, 19 May 2000 20:49:17 -0700 Received: from mg-206253200-87.ricochet.net ([206.253.200.87] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 12t0GG-00002K-00 for namedroppers@ops.ietf.org; Fri, 19 May 2000 20:49:13 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12svr3-0000R3-00 for namedroppers@ops.ietf.org; Fri, 19 May 2000 16:06:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 19 May 2000 15:46:59 +0200 (CEST) From: Roy Arends To: Edward Lewis cc: namedroppers Subject: Re: Remarks on the DNS Security Extension Clarification on Zone Status draft In-Reply-To: Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Comments by Roy Arends and Ted Lindgreen Dear Mr. Lewis, Thank you for your response on our comments. There appears to be a difference in view on 4 subjects: 1. You see the result of the implementation of secured DNS as a completely secured tree, starting at the root. We expect that the result will be several secured subtrees, with different types or strenght of encryption. Different resolvers may see different parts of the DNStree as secured. Part of the DNS tree, perhaps including the root, may not be secured at all for quite some time. 2. You introduce levels of security. We think that a zone is either secure or not and nothing in between. Perhaps this is caused by an approach to the zone from the eyes of the zone administrator who wants to secure his zone as good as possible but is limited by his span of control. We approach it from a resolver point of view with staticly configured KEYS for defined secure entry-points into the DNS tree. 3. You state that "a parent MUST indicate whether a child is secure or not". We have studied this matter in detail, and read all the communications on this we could find, including the comments from Donald Eastlake (author of RFC 2535) on the previous version of this Draft. Our conclusion is that this statement is incorrect. We explain below. 4. You state that off-tree validation opens the possibility to "zone-jacking" attacks. The opening you have described does not exits when RFC 2535 is properly applied. However, attacks are possible in both cases, but may be more severe in the on-tree than in the off-tree case. Before we go into detail first some background to clarify NLnet Labs position. - NLnet Labs is working in a Working Group of CENTR to implement DNSSEC in ccTLDs. We aim to have it implemented in Sweden before 1/1/2001, and in Germany and The Netherlands in Q1 of 2001, and we expect other ccTLDs to join in during this timeframe. - Tests to secure the .se, .de, and .nl zones, using the current BIND9 prerelease have been completed succesfully. - We are currently setting up secured shadow versions of the three ccTLDs mentioned above. With these tests we intend to gain hands-on experience with the practical side of parent-child and KEYholder-KEYsigner communications and scaling problems. - The results of our test will be compiled into document which we plan to shape such that it can be used as a BCP document for zone-administrators. Because we view the proposed standard RFC 2535 as well thought-out, and fully usable as it is now, we think that this RFC is ready to get the status of draft standard. For that reason, we think that only updates to this standard should be carried out, for which there is a strong need. Now for a detailed discussion: ad 1. We do not expect that DNSSEC can or will be implemented in a fully top-down manner, starting at the root, quickly enough to satify the current demand for DNS security. Another reason why off-tree validation is necessary, is that certain sub-zones require stronger KEYs than their parents provide. Also KEYholder-KEYsigner relations crossing national or legal borders may not be suitable for some puposes. Finally, there are childs that need to be in control over their own security, and are not in control of their parent zones. Fortunately RFC 2535 allows off-tree validation of any zone in the global DNS tree. ad 2. Let us look at DNSSEC from the security aware resolvers point of view. Security starts with one or more defined secure entry-points in the DNS tree, perhaps the root when DNSSEC is fully implemented, or any other points down. For these entry-points the resolver has one or more staticly configured KEYs to verify the zone-KEY it expects. Now, suppose the resolver-user wants to lookup a certain RR that belongs to some domainname. First thing to do is to check whether the domainname or an upper part of it is known to be Secured. If more parts match, it uses the longest match. ad 2.1. Case: not in the list of Secured entry-points. Now the resolver falls back to unsecure DNS. ad 2.2. Case: Secured entry-point is found. Now, the resolver will lookup and verify the zone-KEY and enters the DNS tree in secure mode at this entry-point. The resolver descends the tree towards the requested RR, validating KEYs and finally the RR on its way. On doing so, it may face certain complications, let's check two of them. ad 2.2.1 Some zone KEY in between is not signed by its secure parent. This is a new entry-point, the resolver does not know about. The resolver must declare this zone as BAD, and the resolver-user may want to check for updates of his resolver. ad 2.2.2 On decending, the resolver encounters a NULL-KEY. This means that the secure part of the tree has ended, and the resolver falls back to unsecure DNS. Please note that we have made some implicit statements on the way: - before doing the first lookup query, the resolver already knows whether to expect security or not. - having started in the unsecure manner, it can never get secure. - having started in the secure manner, it can only get into the unsecure state when traversing a delegation with a NULL-KEY. - after going from secure via a NULL-KEY to unsecure, it can never get secure again. ad 3. With every delegation from a Secured parent, there must be a zone KEY for the child. This follows directly and unambiguously from RFC 2535. There are 3 likely possibilities: 1. The KEY is signed by the parent and the child-zone holds it. This is the usual case. The KEY can be a zone-signing KEY or a NULL-KEY. Note that the parent says nothing about the childs security. 2. The KEY is third party signed and is hold by the child. This defines a Secured-entry point, which must be preconfigured in the resolvers of interest for this branche of the DNS tree. Note that the parent says nothing about the childs security. 3. The KEY is signed by the parent and is hold by the parent. This is undesirable, especially for large zones (like TLDs), but necessary when the child is clueless or in the transitional state of implementing DNSSEC. The KEY is then a NULL-KEY. Note that the parents says "watch out, this child is clueless, so security ends here". There are other possibilities, but these are all unlikely and/or undesirable. ad 4. First let's look at the security hole you have described. You state that asking whether a zone is secure or not must not be done at the lower half of the delegation. We disagree on this. Perhaps you meant to say that we must not rely on the lower half on the question whether a zone has a KEY or not. Yes, we agree that this is absolutely essential. There are four possibilities: 1. The resolver is configured to know the zone is secured (and has a KEY to check it). This zone is "off-tree" signed. else 2. The parent is Secured and has no NULL-KEY for the child. Then this child must have a KEY, and that KEY must be signed by the parent (otherwise we have to declare the zone BAD). This zone is "on-tree" signed. else 3. The parent is Secured and the parent or the child holds a NULL-KEY. This zone is "Unsecured". else 4. The parent is Unsecured. The child is also Unsecured. Note, whenever we leave a Secured area of the DNS tree and we happen to find a KEY or SIG we can never rely on it and we better ignore it. RFC 2535 is specific about this. Failing to do so opens your security hole, but following RFC 2535 makes this hole to disappear. More on zone-jacking. Note that the childs NS records are not signed in the parents zone file. Zone jacking and other malicious attacks are possible by spoofing illegal delegation NS RR's into the DNS system. Security aware resolvers will spot the attack in secure zones, but may face DoS, other resolvers will simply get fooled with wrong information. For better understanding let's work out the various situations to see what is needed and how difficult it is to pin-point a party we can blame and sue for damage afterwards. Assume a security aware resolver is used. ad. 4.1. Secured zone, with the KEY off-tree signed by a KEY which public part is made available and is preconfigured in the resolvers of interest. Now, to hi-jack the zone and make it undetectable, the private KEY of the signing party needs to be stolen or cracked, or someone at the signing party needs to fooled or corrupted to sign the hi-jackers KEY. Pin-pointing the responsible party is straightforward: the signing party (who may or may not be able to point to the hi-jackers in turn). Claiming damage will depend on the signing party, and likely economic rules will apply for third party signers (value for money). It may also be expected that some very security minded zone-holders will take the signing of their zones in their own hands. ad. 4.2. Secured zone, delegated and signed by Secured parent. This involves that the parents KEY is stolen or cracked, or that the parents zone administrator has been fooled or corrupted to sign the jackers KEY. So this depends on the parents organisation and the strenght of the KEY they use. Pin-pointing the responsible party is straightforward (the parent), but claiming damage may be difficult, because of disclaimers, or legal and national borders. One can expect that large zones, as TLDs, will not be so keen to delegate cheaply when high claims can be faced, so one may expect either disclaimers or huge delegation costs, or that these zones simply do not implement DNSSEC at all. ad. 4.3. Unsecured zone delegated by Secured parent. This is easy, and the responsible party is difficult to point out. It makes little difference whether the NULL-KEY is hold by parent or child (in the latter case, the jacker just copies NULL-KEY and SIG from the real child). ad. 4 4. Unsecured zone delegated by Unsecured parent. This is just as easy to do as 4.3. Note, after a on-tree signed child has converted from Unsecured to Secured, this child is vulnerable to zone-jacking as long as the old NULL-KEY is still valid. Therefore, NULL-KEYs must have a reasonable short SIG expiration time. But this is something for the Best Current Practice document. Regards, Roy Arends, Ted Lindgreen, 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 Mon May 22 12:53:35 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05105 for ; Mon, 22 May 2000 12:53:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12tuIJ-0002EH-00 for namedroppers-data@psg.com; Mon, 22 May 2000 08:39:03 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12tuIJ-0002EB-00 for namedroppers@ops.ietf.org; Mon, 22 May 2000 08:39:03 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12tuII-000AWi-00 for namedroppers@ops.ietf.org; Mon, 22 May 2000 08:39:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Bill Manning Message-Id: <200005221531.IAA10850@zephyr.isi.edu> Subject: Re: confusing documentation To: owner-6bone@ISI.EDU Date: Mon, 22 May 2000 08:31:20 -0700 (PDT) Cc: namedroppers@internic.net In-Reply-To: <200005212131.OAA27386@zephyr.isi.edu> from "owner-6bone@ISI.EDU" at May 21, 2000 02:31:03 PM Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % Hello % % It's a piece of cake to setup zone for ipv6...but i got really confused % with the reverse, practicing by the manual presented at 6bone.net... I % have 2001:600:4:80cf::/64 delegation and i need to set the reverse. If % someone could help me set this zone up, both the zone declaration in % named.conf and the zone file itself i'd be grateful and give a beer away % for that person % % Thanks!! % % Radu Malica Like so: (from http://www.6bone.net/6bone_hookup.html & http://www.isi.edu/~sekiya/IPv6/DNS.html ) and granted, the documentation is not particularly clear. --------------------------------------------- In your named.conf: // // zone "f.c.0.8.4.0.0.0.0.6.0.1.0.0.2.ip6.int" { type master; file "2001:0600:0004.80cf"; }; and then in your zone file "2001:0600:0004.80cf" you have: ; File: 3ffe:0600:0004:80cf ; For the 6Bone pTLA ; ; $TTL 86400 @ IN SOA authoritative-master.example.net hostmaster.example.com ( 100013117 3H ; refresh 15M ; retry 1W ; expiry 1D ) ; minimum IN NS ns.example.com. IN NS ns.example.net ; ; Set the origin to the pTLA prefix. ; $ORIGIN f.c.0.8.4.0.0.0.0.0.6.0.e.f.f.3.ip6.int. 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR pTLA-example.com. 2.8.9.1.2.3.e.f.f.f.9.7.8.a.2.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR host1.v6.example.com. 0.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR www.v6.example.com. ; -- --bill to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon May 22 14:47:56 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07752 for ; Mon, 22 May 2000 14:47:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12twZY-00041f-00 for namedroppers-data@psg.com; Mon, 22 May 2000 11:05:00 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12twZX-00041Z-00 for namedroppers@ops.ietf.org; Mon, 22 May 2000 11:04:59 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12twZX-000Dmf-00 for namedroppers@ops.ietf.org; Mon, 22 May 2000 11:04:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: References: Date: Mon, 22 May 2000 13:58:12 -0400 To: Roy Arends From: Edward Lewis Subject: part II - Re: Remarks on the DNS Security Extension Clarification on Zone Status draft Cc: Edward Lewis , namedroppers Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit (I appologize that this is still one and a bit rambling.) Here are some thoughts I have driving the draft and the resultant discussion. I bring this up because in many places I agree with the premises presented but disagree with the conclusions. The original problem I had in mind when I began writing this draft was the protection of, e.g., "www.army.example." Assume that the army is contracting out its DNS operations to "contractor.xy." The desire of the army would be to have www.army.example's A records signed by contractor.xy. One reason for this is to stop spoofing the address of the army website. The army would then configure all of it's resolvers to trust the keys of contractor.xy, hence all the army folks would trust the unspoofed address. However, this gives a false sense of security. Although the army's resolvers will now not fall to address spoofs, the true audience, those it hopes to recruit (assuming the US version of non-drafted army) would not trust the real address and would be open to believing a spoofed address. There isn't a mechanism for army.example to express to the general audience that contractor.xy is the desired signatory authority for the data. This missing mechanism is something I've tried to address before and without success. The original intent of the draft was to convey some definitions that could be used in a later document on how to set up secure zones. The levels of security I define here are not intended to be meaningful to the protocol, but put names to the classification of whether the zone is secured in the general view, or secured in the view of just a few, or not secured at all. Falling back to the example, had the army arranged for the contractor to sign the zone using the army's domain name, i.e., the name which a resolver would expect to see signing the zone barring configuration, then you would have www.army.example signed by army.example. This would be a "completely" or "fully" secured zone. With the example as stated, the zone may be safely secured and recognized by the army resolvers, but the zone would not be seen as secured by the general population of resolvers. This is the situation in which the zone is said to be "privately" or "partially" secured. I am making the distinction on paper so that administrators can see the impact of so-called non-standard signing algorithms and authenticators. There is also the latent issue that the policy in section 6 of RFC 2535 is not one that I am happy with. Further, at the time the DNSSEC WG pushed this document into the IESG, there was no consensus on that section and I was promised that it would be removed. 1) The definition of DNSSEC protects resolvers, not servers. At 9:46 AM -0400 5/19/00, Roy Arends wrote: >There appears to be a difference in view on 4 subjects: > >1. You see the result of the implementation of secured DNS as a > completely secured tree, starting at the root. For the sake of interoperability, I hope that eventually this is the case. > We expect that the result will be several secured subtrees, > with different types or strenght of encryption. Different > resolvers may see different parts of the DNStree as secured. Is this acceptable? As in the example above, my zone may seem secure to all of my resolvers, but not to other resolvers. > Part of the DNS tree, perhaps including the root, may not be > secured at all for quite some time. I agree with this and have already written software that looked at the DNS tree as being comprised of mini trusted trees, rooted at pre-configured trusted points and "ending" where unsecured children existed. > >2. You introduce levels of security. We think that a zone is either > secure or not and nothing in between. Perhaps this is caused by > an approach to the zone from the eyes of the zone administrator > who wants to secure his zone as good as possible but is limited > by his span of control. We approach it from a resolver point of > view with staticly configured KEYS for defined secure entry-points > into the DNS tree. You are right. I am trying to document the situation from the point of view of the server administrator. >Because we view the proposed standard RFC 2535 as well thought-out, >and fully usable as it is now, we think that this RFC is ready to >get the status of draft standard. For that reason, we think that >only updates to this standard should be carried out, for which >there is a strong need. I think that this opinion is counter to that of some implementers. This dissatisfaction with RFC 2535 by implementers is what has been driving recent drafts such as the one we are talking about now. I really want to avoid a section-by-section analysis of RFC 2535 in this message. >Now for a detailed discussion: > >ad 1. > Fortunately RFC 2535 allows off-tree validation of any zone in > the global DNS tree. I think the problem with off-tree validation is that there is no way a zone can safely convey who are valid signers of its data. Let's say that validator.example is a respected signer of data and have their keys distributed with resolvers everywhere. If I, as a zone owner, do not want validator.example to sign my data, I won't be able to do so. I realize the off-tree validation is important. In the draft I choose not to deal with it as I see it needing more refinement. I am not against this, I just think we need to understand how this can be done securely. > >ad 2. > Let us look at DNSSEC from the security aware resolvers point of view. That would be a discussion for a different draft. Mine is trying to write from the server's point of view. As far as the rest of this section, this is approximately the algorithm I implmented in my secured resolver (non-released, antiquated, code). >ad 3. > 3. The KEY is signed by the parent and is hold by the parent. > This is undesirable, especially for large zones (like TLDs), > but necessary when the child is clueless or in the transitional > state of implementing DNSSEC. The KEY is then a NULL-KEY. > Note that the parents says > "watch out, this child is clueless, so security ends here". This is why the proposal to use a bit in the NXT is made; to avoid the parent from holding NULL keys. >ad 4. > First let's look at the security hole you have described. > You state that asking whether a zone is secure or not must > not be done at the lower half of the delegation. > We disagree on this. > > Perhaps you meant to say that we must not rely on the lower > half on the question whether a zone has a KEY or not. > Yes, we agree that this is absolutely essential. I'm not sure how to respond to this. There are two questions, "is zone A secure" and "does zone A have KEYs?" The questions are related, differ slightly, but both are best answered by the parent (until we figure a secure way to go off-tree). if zone A is secure ==> zone A has KEYs if zone A is unsecured ==> zone A has no KEYs OR zone A has KEYs w/o zone KEY if zone A has no KEYs ==> zone A is unsecured if zone A has KEYs and a zone KEY ==> zone A is secured if zone A has Keys but no zone KEY ==> zone A is unsecured My draft now asks "does zone A have KEYS". After a conversation with implmenters, I am going to rewrite the draft to ask "is zone A secure" because of issues with the validator routines. > There are four possibilities: > 1. The resolver is configured to know the zone is secured > (and has a KEY to check it). > This zone is "off-tree" signed. I had not considered pre-configured to be off-tree, but intrinsically trusted. I always thought of off-tree as only pertaining to data signed by keys obtained elsewhere, ultimately coming back to a trusted point. > More on zone-jacking. Note that the childs NS records are not > signed in the parents zone file. Zone jacking and other malicious > attacks are possible by spoofing illegal delegation NS RR's into > the DNS system. Security aware resolvers will spot the attack in > secure zones, but may face DoS, other resolvers will simply get > fooled with wrong information. What my secured resolver did was, at a secured parent: 1) get the keys for the child (if present) 2) get the NS for the child 3) get the glue for the child and then trying the NS set of the child 1) get the NS for the child 2) get the KEY for the child (if needed) 3) verify the NS from the child and make sure this was used instead of the set from #2 above. and so on. > For better understanding let's work out the various situations > to see what is needed and how difficult it is to pin-point a > party we can blame and sue for damage afterwards. > Assume a security aware resolver is used. This raised a point that has been bothering me all weekend. If we assume that DNS servers are reasonably well intentioned, then we can be fairly loose in our policies. If we are willing to just be able to "blame and sue" we can also use loose policies. I have been working from a point of view that is "paranoid" and "real time." I don't place trust in other servers, so I seek restrictive policies. I also try to prevent the use of bad data (e.g., my verification of the "hint NS" as I decend the tree). Another factor, besides my bias, is that tighter policies make the software easier to write. Releasing software that allows looser policies is more palatable to me than having to patch old software because it used a policy that is too loose. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "It takes years of training to know when to do nothing" - Dogbert 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 May 23 10:50:26 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04425 for ; Tue, 23 May 2000 10:50:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12uF0G-0001nS-00 for namedroppers-data@psg.com; Tue, 23 May 2000 06:45:48 -0700 Received: from mg136-005.ricochet.net ([204.179.136.5] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 12uEzt-0001nD-00 for namedroppers@ops.ietf.org; Tue, 23 May 2000 06:45:45 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12uEzb-0000r7-00 for namedroppers@ops.ietf.org; Tue, 23 May 2000 06:45:07 -0700 Message-Id: <200005231034.GAA29240@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-costanzo-dns-gl-02.txt Date: Tue, 23 May 2000 06:34:50 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Definition of the DNS GL Resource Record used to encode Geographic Locations Author(s) : A. Costanzo Filename : draft-costanzo-dns-gl-02.txt Pages : 9 Date : 22-May-00 This document defines the format of a new Resource Record (RR) namely GL for the Domain Naming System (DNS), and reserves a corresponding DNS type mnemonic and numerical code. This definition deals with associating geographical host location mappings to host names within a domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-costanzo-dns-gl-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-costanzo-dns-gl-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-costanzo-dns-gl-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: <20000522111241.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-costanzo-dns-gl-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-costanzo-dns-gl-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000522111241.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 May 23 19:37:19 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13363 for ; Tue, 23 May 2000 19:37:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12uNFs-0008Le-00 for namedroppers-data@psg.com; Tue, 23 May 2000 15:34:28 -0700 Received: from mg131-191.ricochet.net ([204.179.131.191] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 12uNFp-0008KU-00 for namedroppers@ops.ietf.org; Tue, 23 May 2000 15:34:27 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12uNFx-00014L-00 for namedroppers@ops.ietf.org; Tue, 23 May 2000 15:34:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200005231404.HAA27270@sh.lh.vix.com> To: namedroppers@ops.ietf.org Subject: Re: Remarks on the DNS Security Extension Clarification on Zone Status draft In-reply-to: Your message of "Fri, 19 May 2000 15:46:59 +0200." Date: Tue, 23 May 2000 07:04:23 -0700 From: Jerry Scharf Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Roy, Your proposed solution to allow off-tree signing seemd wonderful but created the mother of all key distribution problems. How does oen get the keys in, how does one change them... In particular, in you analysis of attacks, you missed the one that the attacker first persuades the resolver to configure in the wrong key, then does as he will. Given the explicit ability to have multiple keys (something needed in the normal case), it only takes getting an extra key on the system to destroy security. If you punt the problem and allow an external security system to handle the keys, then you have fundamentally changes the definition of the problem. Having been in some of the discussions about what is really required to handle the root key, this is very very hard. You can increase the strength of the security of the zone key as much as you like, but until the entire delivery chain including the configuration of the public key onto the system at hand is addresses, the security is limited. Also, I am assuming that you were using the resolver point of view in a didactic form. It has been the general belief that most of the work for secure DNS would happen on the local recursive nameservers, and use tsig/other/nothing to pass the response back to the resolver. Given your expansion of the key delivery problem, you would have to be strongly in favor of this. Doing the security at the local nameserver is also the only way to secure DNS without waiting for the installed base of local resolvers to be changed out (maybe 5-10 years.) jerry to unsubscribe send a message to 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 May 26 12:28:15 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19445 for ; Fri, 26 May 2000 12:28:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12vLbY-00039A-00 for namedroppers-data@psg.com; Fri, 26 May 2000 08:00:52 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12vLbX-000394-00 for namedroppers@ops.ietf.org; Fri, 26 May 2000 08:00:51 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12vLbW-000FHl-00 for namedroppers@ops.ietf.org; Fri, 26 May 2000 08:00:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 26 May 2000 16:59:52 +0200 (CEST) From: Roy Arends To: Edward Lewis cc: namedroppers Subject: Re: part II - Re: Remarks on the DNS Security Extension Clarification on Zone Status draft Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear mr. Lewis, Thanks for pointing out that we have used different definitions of "off-tree" signing. Indeed we interpreted "off-tree" as what you call "intrinsically trusted". What you meant by "off-tree" is something we did not take into consideration, because we thought of that as a too weak implementation of DNSSEC, and we were unaware of the discussions about section 6 of RFC 2535. I think we are in full agreement that: 1. Security starts at one or more well defined secured entry-points in the DNS-tree and follows delegations until security ends verifyably. 2. Signing random RR's by an external (non-parent) signer is vulnerable to spoofing for all resolvers that are not pre-configured to know who the signer is and what it has signed exactly. Such detailed pre-configuration seems impractical and scales badly. About the Draft: Perhaps a clarification of secured entry-points, and the possible existance of "mini trusted trees" is useful. Our tests to deploy DNSSEC on the largest ccTLDs convinced us that a NULL-KEY is not so bad in terms of size and effort, that it calls for a major update of the current proposed standard. (NULL-KEY's are temporal, small, and signing them is not a big issue.) We think it is best to put our effort to do large scale testing of the current RFC. And finally, about your remarks on loose versus tight policies, we probably agree on that, and it was certainly not our intention to plead for a weak DNSSEC implementation. Regards, -- Roy and Ted. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri May 26 15:22:37 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23356 for ; Fri, 26 May 2000 15:22:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12vPBU-0004un-00 for namedroppers-data@psg.com; Fri, 26 May 2000 11:50:12 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12vPBU-0004uh-00 for namedroppers@ops.ietf.org; Fri, 26 May 2000 11:50:12 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12vPBT-000Gc0-00 for namedroppers@ops.ietf.org; Fri, 26 May 2000 11:50:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.1.20000526134936.00a869e0@localhost> Date: Fri, 26 May 2000 14:42:32 -0400 To: Roy Arends , Edward Lewis From: Olafur Gudmundsson Subject: Re: part II - Re: Remarks on the DNS Security Extension Clarification on Zone Status draft Cc: namedroppers In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 10:59 AM 5/26/00 , Roy Arends wrote: >About the Draft: >Perhaps a clarification of secured entry-points, and the possible >existance of "mini trusted trees" is useful. > Agreed, >Our tests to deploy DNSSEC on the largest ccTLDs convinced us that >a NULL-KEY is not so bad in terms of size and effort, that it calls >for a major update of the current proposed standard. (NULL-KEY's >are temporal, small, and signing them is not a big issue.) >We think it is best to put our effort to do large scale testing of >the current RFC. If you and the other entity the one that operates .com agree that you can live with NULL keys for 90% of your delegations for the for seeable future, then there is no need to get rid of NULL keys. The MAIN motivator for this proposed change was the desire to reduce storage requirements in the TLD servers. COM right now is say 10M delegations. If they sign the zone with DSA keys then they will have 9M NULL keys records and signatures taking at least 900MB of storage. If on the other hand the KEY bit off the NXT record is overloaded then these 18M RR's will not have to be loaded. This is a tradeoff between recurring storage/reload/signing cost versus a some extra code in all implementations. 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 May 26 15:30:03 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23468 for ; Fri, 26 May 2000 15:30:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12vPLb-0004zn-00 for namedroppers-data@psg.com; Fri, 26 May 2000 12:00:39 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12vPLb-0004zh-00 for namedroppers@ops.ietf.org; Fri, 26 May 2000 12:00:39 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12vPLa-000Gfz-00 for namedroppers@ops.ietf.org; Fri, 26 May 2000 12:00:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: Date: Fri, 26 May 2000 12:55:52 -0600 From: "Glendon Whiteley" To: Cc: Subject: Re: SRV clients Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>> "Eric A. Hall" 04/11/00 03:28PM >>> >Are there any known clients which have implemented SRV support? Web >browsers? NOS clients? Anything? Novell's GroupWise 5.1 (and later) Message Transfer Agent uses SRV (per rfc2052) to locate MTAs in external domains. Novell's next NDS server uses SRV (per rfc2782) to locate directory servers outside its administrative domain. - Glendon Whiteley, Novell Inc. gwhiteley@novell.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 May 26 16:03:35 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24363 for ; Fri, 26 May 2000 16:03:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12vPk2-0005HV-00 for namedroppers-data@psg.com; Fri, 26 May 2000 12:25:54 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12vPk2-0005HP-00 for namedroppers@ops.ietf.org; Fri, 26 May 2000 12:25:54 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12vPk2-000Gou-00 for namedroppers@ops.ietf.org; Fri, 26 May 2000 12:25:54 -0700 Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 26 May 2000 15:10:00 -0400 To: Roy Arends From: Edward Lewis Subject: Re: part II - Re: Remarks on the DNS Security Extension Clarification on Zone Status draft Cc: Edward Lewis , namedroppers Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 10:59 AM -0400 5/26/00, Roy Arends wrote: I figured that, with the similarity in our assumptions, the differences in our conclusions probably meant that there were misinterpretations of terms and phrases happening. Which leads to... >About the Draft: >Perhaps a clarification of secured entry-points, and the possible >existance of "mini trusted trees" is useful. ...thanks for the suggestion. I have realized that I need to improve the introduction section to avoid misunderstandings. I have omitted too many ideas that are well-known-in-the-hallway but not expressed in drafts. >Our tests to deploy DNSSEC on the largest ccTLDs convinced us that >a NULL-KEY is not so bad in terms of size and effort, that it calls >for a major update of the current proposed standard. (NULL-KEY's >are temporal, small, and signing them is not a big issue.) >We think it is best to put our effort to do large scale testing of >the current RFC. Keep us posted! We need real-life experience to go along with the philosophical musings of people like me. It is interesting that you say that the NULL key isn't a problem. I'll look into that, I had heard differently from other large-domain operators. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "It takes years of training to know when to do nothing" - Dogbert Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri May 26 16:17:25 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24582 for ; Fri, 26 May 2000 16:17:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12vQ8n-0005bm-00 for namedroppers-data@psg.com; Fri, 26 May 2000 12:51:29 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12vQ8n-0005bg-00 for namedroppers@ops.ietf.org; Fri, 26 May 2000 12:51:29 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12vQ8n-000GzJ-00 for namedroppers@ops.ietf.org; Fri, 26 May 2000 12:51:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200005261948.MAA22485@sh.lh.vix.com> To: Olafur Gudmundsson cc: namedroppers Subject: Re: part II - Re: Remarks on the DNS Security Extension Clarification on Zone Status draft In-reply-to: Your message of "Fri, 26 May 2000 14:42:32 EDT." <4.1.20000526134936.00a869e0@localhost> Date: Fri, 26 May 2000 12:48:54 -0700 From: Jerry Scharf Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think that an incremental signer and working incremental transfer would go a long way to making the issue of big zones with mostly NULL keys manageable. As bad as it sounds, 900MB of extra stuff that is not changed very often can work OK. As long as you need something that is signed to come back, the issues related to message size and lack of EDNS0 are still the biggest issues for the TLD servers. jerry to unsubscribe send a message to 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 May 29 10:36:30 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00767 for ; Mon, 29 May 2000 10:36:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12wPoY-000HxK-00 for namedroppers-data@psg.com; Mon, 29 May 2000 06:42:42 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12wPoY-000HxC-00 for namedroppers@ops.ietf.org; Mon, 29 May 2000 06:42:42 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12wPoY-0003e7-00 for namedroppers@ops.ietf.org; Mon, 29 May 2000 06:42:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 29 May 2000 12:04:54 +0200 (CEST) From: Roy Arends To: Olafur Gudmundsson cc: Edward Lewis , namedroppers Subject: Re: part II - Re: Remarks on the DNS Security Extension Clarification on Zone Status draft Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 26 May 2000, Olafur Gudmundsson wrote: > If you and the other entity the one that operates .com agree that > you can live with NULL keys for 90% of your delegations for the > for seeable future, then there is no need to get rid of NULL keys. > The MAIN motivator for this proposed change was the desire to reduce > storage requirements in the TLD servers. > COM right now is say 10M delegations. If they sign the zone with DSA keys > then they will have 9M NULL keys records and signatures taking at least > 900MB of storage. > If on the other hand the KEY bit off the NXT record is overloaded > then these 18M RR's will not have to be loaded. It's not that we object against replacing the NULL-KEY with a bit in the NXT record. But we do have problem with the interpretation that the draft proposes for the bit in the NXT record, because this differs in a subtle, but fundamental way from the meaning of a parent holding a NULL-KEY. The former says: - the parent has signed a KEY for this child The latter says: - the child is clueless We are affraid that this difference leads to unforseen complications. If the draft would have proposed that the meaning of a KEY bit set in the NXT RR AND no KEY RR is present, were : "a NULL-KEY is implied" we would not have this problem. This would then also be downward compatible. Regards, Roy and 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 Mon May 29 15:12:04 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02972 for ; Mon, 29 May 2000 15:12:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12wUB4-00049i-00 for namedroppers-data@psg.com; Mon, 29 May 2000 11:22:14 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12wUB3-00049c-00 for namedroppers@ops.ietf.org; Mon, 29 May 2000 11:22:13 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12wUB3-0009Pw-00 for namedroppers@ops.ietf.org; Mon, 29 May 2000 11:22:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200005291816.LAA22768@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Edward Lewis cc: Roy Arends , namedroppers , gnu@toad.com Subject: Re: part II - Re: Remarks on the DNS Security Extension Clarification on Zone Status draft In-reply-to: Date: Mon, 29 May 2000 11:16:19 -0700 From: John Gilmore Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The desire of the army would be to have www.army.example's A records signed > by contractor.xy. ... > > There isn't a mechanism for army.example to express to the general audience > that contractor.xy is the desired signatory authority for the data. Yes there is. Give contractor.xy the private key to army.example, and let them use it to sign www.army.example. This is how you express trust -- by sharing your privates. :-) John to unsubscribe send a message to 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 May 30 11:32:07 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01590 for ; Tue, 30 May 2000 11:32:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12wn6s-0007mJ-00 for namedroppers-data@psg.com; Tue, 30 May 2000 07:35:10 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12wn6s-0007mD-00 for namedroppers@ops.ietf.org; Tue, 30 May 2000 07:35:10 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12wn6s-000Fq6-00 for namedroppers@ops.ietf.org; Tue, 30 May 2000 07:35:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <200005291816.LAA22768@toad.com> References: Date: Mon, 29 May 2000 09:23:42 -0400 To: John Gilmore From: Edward Lewis Subject: Re: part II - Re: Remarks on the DNS Security Extension Clarification on Zone Status draft Cc: Edward Lewis , Roy Arends , namedroppers , gnu@toad.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 2:16 PM -0400 5/29/00, John Gilmore wrote: >> The desire of the army would be to have www.army.example's A records signed >> by contractor.xy. ... >> >> There isn't a mechanism for army.example to express to the general audience >> that contractor.xy is the desired signatory authority for the data. > >Yes there is. Give contractor.xy the private key to army.example, and >let them use it to sign www.army.example. Yeah, that's the solution I suggested when I first heard the situation. In other words, bend reality into the DNS world and then follow the restrictive rules. I can live with that, but here's the rub. Having company A sign the data for companies B, C, D, etc. is one thing, having company A hold the private keys for B, C, D, etc., sounds like key escrow. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "It takes years of training to know when to do nothing" - Dogbert 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 May 30 11:35:33 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01735 for ; Tue, 30 May 2000 11:35:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12wn6f-0007m4-00 for namedroppers-data@psg.com; Tue, 30 May 2000 07:34:57 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12wn6f-0007ly-00 for namedroppers@ops.ietf.org; Tue, 30 May 2000 07:34:57 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12wn6f-000Fpw-00 for namedroppers@ops.ietf.org; Tue, 30 May 2000 07:34:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: Date: Mon, 29 May 2000 09:15:17 -0400 To: Roy Arends From: Edward Lewis Subject: Re: part II - Re: Remarks on the DNS Security Extension Clarification on Zone Status draft Cc: Olafur Gudmundsson , Edward Lewis , namedroppers Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 6:04 AM -0400 5/29/00, Roy Arends wrote: >If the draft would have proposed that the meaning of a KEY bit set >in the NXT RR AND no KEY RR is present, were : > "a NULL-KEY is implied" >we would not have this problem. This would then also be downward >compatible. I think this is where I am heading with the draft. The bit would be on if the parent signs a key set for the child that includes a zone key, hence "securing" the child. The problem with allowing both the NULL KEY to signify an unsigned child *and* a bit setting in the NXT is that this complicates life for the resolver (and I don't mean that only the code is hard to write). -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "It takes years of training to know when to do nothing" - Dogbert 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 May 31 08:11:05 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05756 for ; Wed, 31 May 2000 08:11:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12x6Uj-000FjW-00 for namedroppers-data@psg.com; Wed, 31 May 2000 04:17:05 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12x6Uj-000FjQ-00 for namedroppers@ops.ietf.org; Wed, 31 May 2000 04:17:05 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12x6Uj-000MT3-00 for namedroppers@ops.ietf.org; Wed, 31 May 2000 04:17:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200005311016.MAA03040@open.nlnetlabs.nl> From: ted@tednet.nl (Ted Lindgreen) Date: Wed, 31 May 2000 12:16:07 +0200 In-Reply-To: "Roy Arends's message as of May 30, 15:43" Reply-To: Ted.Lindgreen@tednet.nl To: Edward Lewis Subject: Re: part II - Re: Remarks on the DNS Security Extension Clarification on Zone Status draft (fwd) Cc: namedroppers Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Quoting Edward Lewis ] > > >If the draft would have proposed that the meaning of a KEY bit set > >in the NXT RR AND no KEY RR is present, were : > > "a NULL-KEY is implied" > >we would not have this problem. This would then also be downward > >compatible. > > I think this is where I am heading with the draft. > > The bit would be on if the parent signs a key set for the child that > includes a zone key, hence "securing" the child. No, this would mean something quite different, but both proposals have problems. Actually we have 4 different questions: 1. How bad do we need to get rid of the NULL-KEY? 2. Is the KEY-bit in the NXT-RR redundant information, i.e. can we use the case "KEY-bit set _AND_ no KEY RR present" to get rid of the NULL-KEY? 3. Do we need to retain the exact functionality of the NULL-KEY? 4. Do we need to add new functionality, i.e. "the parent has signed this childs KEY"? Let's review them one by one: ad. 1. For large TLDs it would be nice to get rid of the NULL-KEYs as it reduces the size of the zone file with some 30%. However, this reduction is dwarfed by the growth of 20% every month which these TDLs are currently facing. ad. 2. The original meaning of the KEY-bit in the NXT-RR is that an RR of type KEY is present. Now what happens if we set this bit and omit the corresponding RR? - If we define this case to imply a NULL-KEY, it opens a security leak: spoofers "caching" server needs only to present the original NXT and faked NS-glue-RR's to certifyably fool a secure aware resolver. - If we define this case to imply "the parent signs a key set for the child that includes a zone key": - In the backwards-compatible mode it would mean the parent zone is BAD. - If the child holds the KEY and SIG, the KEY-bit info is redundant, as it must have been there anyway to conform to RFC 2535. - If the child does not hold a KEY the child zone is BAD. Now, suppose the KEY-bit is off (and of course no KEY-RR either): - In the original RFC-2535 this would mean that the child MUST have its own KEY (and is otherwise BAD or hi-jacked). - As proposed in the Draft, it would mean that the child is certifyably unsecured. This opens a security leak for externally signed childs. In conclusion we think it is very dangerous to allow the KEY-bit to indicate something else than what RFC-2535 intended it to mean. ad. 3. The functionality of NULL-KEY is to indicate the end of a secured branch of the DNS tree. This functionality is needed to prevent zone-jacking. If we want to get rid of the NULL-KEY (and more important its SIG), we need something that _exactly_ reflects its functionality. ad. 4. The proposal in the Draft replaces the functionality of the NULL-KEY (end of security) by "parent has signed". We think the latter info is redundant, as: 1. There MUST be a zone KEY when no NULL-KEY is present. 2. There MUST a SIG over the KEY to validate it. 3. This SIG provides the necessary info about its signer already and in a certifyable manner. So, in conclusion, we think that: - The need to get rid of the NULL-KEY is a minor issue. - Misusing the KEY-bit in the NXT-RR is both dangerous and unnecessary. - The functionality of NULL-KEY is needed. - The proposed new functionality is not needed. > The problem with allowing both the NULL KEY to signify an unsigned child > *and* a bit setting in the NXT is that this complicates life for the > resolver (and I don't mean that only the code is hard to write). The functionality of the KEY (or NULL-KEY) is to indicate that the zone, to which the KEY belongs, is secure (or unsecure). The functionality of the bits in the NXT is to indicate what RRs are present in the RR-set. These functionalities are different, and both are needed for security. That security complicates life for the resolver is true and unfortunate, but using shortcuts that open leaks is worse. Regards, -- Ted. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed May 31 18:05:36 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25966 for ; Wed, 31 May 2000 18:05:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12xFoY-0000Ur-00 for namedroppers-data@psg.com; Wed, 31 May 2000 14:14:10 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 12xFoW-0000Uk-00 for namedroppers@ops.ietf.org; Wed, 31 May 2000 14:14:08 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12xFoP-0000P0-00 for namedroppers@ops.ietf.org; Wed, 31 May 2000 14:14:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: Date: Tue, 30 May 2000 11:09:23 -0400 To: namedroppers From: Edward Lewis Subject: Why I want to remove the null key SIG Cc: lewis@tislabs.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This relates to the thread on the DNSSEC Clarification on Zone Status draft, but I wanted to separate this to draw comments on an issue that is not directly addressed by the draft. Removing the null KEY is rumored to drop a signed, widely-delegated zone by about a third. As has been pointed out, this is sizeable, but not sizeable considering the monthly rate of increase in domain name registrations experienced in some of the up-and-coming TLDs. The obvious rationale is that removing a third of the records would make DNSSEC more adoptable by limiting the up-front resource investment. A less obvious rationale is that saving space now may help in the transition out of DNSSECv1 to DNSSECv2 (let's face it, it will happen). I envision that there may be a need to create a new record at a parent to indicate something about the child. This is an idle thought - not only am I reluctant to persue a draft on this, I think it is premature to even guess of how or what form such a transition may take. In case you are wondering - I don't think the addition of the aforementioned record is a foregone conclusion. I am trying to identify ways that reduce the amount of information a parent must know and hold about a child. Will the introduction of parent-authoritative data at a delegation point prove to be DNSSEC's biggest faux pas? Will the weakness of DNS delegation indication (no delegation record) be a problem to DNSSEC? Will dynamic update make the delegation information more consistent, sophisticated, reliable? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "It takes years of training to know when to do nothing" - Dogbert 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 May 31 18:12:49 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26093 for ; Wed, 31 May 2000 18:12:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12xFw3-0000eV-00 for namedroppers-data@psg.com; Wed, 31 May 2000 14:21:55 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 12xFw2-0000eP-00 for namedroppers@ops.ietf.org; Wed, 31 May 2000 14:21:54 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12xFw0-0000Pc-00 for namedroppers@ops.ietf.org; Wed, 31 May 2000 14:21:52 -0700 Message-Id: <200005311909.MAA28953@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 2845 on DNS TSIG Cc: rfc-ed@ISI.EDU, namedroppers@internic.net Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 31 May 2000 12:09:20 -0700 From: RFC Editor Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2845 Title: Secret Key Transaction Authentication for DNS (TSIG) Author(s): P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington Status: Standards Track Date: May 2000 Mailbox: vixie@isc.org, ogud@tislabs.com, dee3@torque.pothole.com, Brian.Wellington@nominum.com Pages: 15 Characters: 32272 Updates: 1035 I-D Tag: draft-ietf-dnsext-tsig-00.txt URL: ftp://ftp.isi.edu/in-notes/rfc2845.txt This protocol allows for transaction level authentication using shared secrets and one way hashing. It can be used to authenticate dynamic updates as coming from an approved client, or to authenticate responses as coming from an approved recursive name server. No provision has been made here for distributing the shared secrets; it is expected that a network administrator will statically configure name servers and clients using some out of band mechanism such as sneaker-net until a secure automated mechanism for key distribution is available. This document is a product of the DNS Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <000531120649.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2845 --OtherAccess Content-Type: Message/External-body; name="rfc2845.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <000531120649.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body.