From owner-namedroppers@ops.ietf.org Mon Oct 1 11:49:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21266 for ; Mon, 1 Oct 2001 11:49:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15o4Bb-000EaC-00 for namedroppers-data@psg.com; Mon, 01 Oct 2001 07:36:47 -0700 Received: from dhcp118.ripemtg.ripe.net ([193.0.8.118] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15o47t-000EU8-00 for namedroppers@ops.ietf.org; Mon, 01 Oct 2001 07:36:39 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.33 #1) id 15o43T-000CAl-00 for namedroppers@ops.ietf.org; Mon, 01 Oct 2001 16:28:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: namedroppers@ops.ietf.org Subject: list policy Message-Id: From: Randy Bush Date: Mon, 01 Oct 2001 03:00:00 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit namedroppers@ops.ietf.org is the mailing list for the ietf dnsext wg. see for the wg charter. messages should be on topics appropriate to the dnsext wg, which are various discussion of the dns protocols or administrivia of the wg itself. the list is moderated. calls for papers, announcements of events not directly relevant to the dns protocols, etc. are not appropriate. discussion of problems with particular implementations, announcements of releases, sites' misconfigurations, etc. should be done on mailing lists for the particular implementations. there is a wg for dns operational practice, dnsop, whose charter can be found at . there is a mailing list for discussion of whose implementation is better, and why someone else's is broken. it is weenie-war@ops.ietf.org. all discussions of such nature should occur there or on /dev/null. unlike the namedroppers list, weenie-war@ops.ietf.org is not archived. questions or concerns related to the acceptance or rejection of specific messages to the namedroppers mailing list should first be discussed with the wg chairs, with followup appeals using the normal appeals process of rfc 2026 (i.e., follup with area directors, then iesg, etc.). there is a mailing list for the discussion of ietf processes, which includes any general discussion of the moderation of ietf mailing lists. it is ietf-process@lists.elistx.com. --- NOTE WELL: All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Oct 1 12:15:08 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22002 for ; Mon, 1 Oct 2001 12:15:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15o4RK-000F1G-00 for namedroppers-data@psg.com; Mon, 01 Oct 2001 07:53:02 -0700 Received: from dhcp118.ripemtg.ripe.net ([193.0.8.118] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15o4RI-000Evk-00 for namedroppers@ops.ietf.org; Mon, 01 Oct 2001 07:53:02 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.33 #1) id 15o4JL-000CCZ-00 for namedroppers@ops.ietf.org; Mon, 01 Oct 2001 16:44:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-00.txt In-Reply-To: References: <200109281109.HAA09046@ietf.org> <5.1.0.14.2.20010928141318.028528f0@localhost> Date: Mon, 01 Oct 2001 18:57:12 +0700 Message-ID: <7415.1001937432@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On the off chance this pseudo-last-call ends before I have a chance to get on the net again, I object to this draft as well - certainly to it going anywhere until there's some actual evidence, rather than superstition to support it. eg: 2(c) which is currently ... c) It is not known if the benefits of A6 outweigh the costs and risks. can exactly equivalently be written as ... c) It is not known if the costs and risks of A6 outweigh the benefits. which when read gives exactly the opposite impression as the former choice of words. What's more, that's true whether the term "A6" there is shorthand for "deployment of A6 RRs" or "failure to deploy A6 records". kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Oct 1 12:16:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22066 for ; Mon, 1 Oct 2001 12:16:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15o4SZ-000F35-00 for namedroppers-data@psg.com; Mon, 01 Oct 2001 07:54:19 -0700 Received: from dhcp118.ripemtg.ripe.net ([193.0.8.118]) by psg.com with esmtp (Exim 3.33 #1) id 15o4RX-000Ezq-00 for namedroppers@ops.ietf.org; Mon, 01 Oct 2001 07:54:18 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.33 #1) id 15o4QP-000CDF-00 for namedroppers@ops.ietf.org; Mon, 01 Oct 2001 16:52:05 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 01 Oct 2001 08:54:00 -0500 From: Matt Crawford Subject: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-00.txt In-reply-to: "28 Sep 2001 14:17:29 EDT." <5.1.0.14.2.20010928141318.028528f0@localhost> To: namedroppers@ops.ietf.org Cc: iesg@ietf.org Message-id: <200110011354.f91Ds1m29955@gungnir.fnal.gov> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > Just a note; I support this but in all honesty, perhaps s/consensus/rough > > consensus/ would be closer to the community opinion. :-) > > The point of the document is to judge consensus, editors tried to > capture the "sense of the room" in London and this is now put out > for judging what kind consensus is for the recommendations, by the > working group. In London we were told that the last part of the joint meeting, but there was only a voice poll. The minutes told us that consensus would be judged on the mailing list. On the mailing list we were told to wait for this document. This document asserts a consensus that did not exist in the meeting, the minutes or on the list. (I have re-read the archives and still maintain this opinion.) Furthermore, this document makes some purely technical claims that were soundly rebutted on the mailing list before and after the meeting. Matt Crawford to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Oct 2 03:57:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29887 for ; Tue, 2 Oct 2001 03:57:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15oKBu-000Ca3-00 for namedroppers-data@psg.com; Tue, 02 Oct 2001 00:42:10 -0700 Received: from dhcp118.ripemtg.ripe.net ([193.0.8.118] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15oKBt-000CZe-00 for namedroppers@ops.ietf.org; Tue, 02 Oct 2001 00:42:10 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.33 #1) id 15oJVe-000CgZ-00 for namedroppers@ops.ietf.org; Tue, 02 Oct 2001 08:58:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 01 Oct 2001 14:17:01 -0500 (CDT) From: Matt Crawford To: namedroppers@ops.ietf.org Message-id: <200110011917.f91JH1m01698@gungnir.fnal.gov> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit From vixie@as.vix.com Mon Oct 01 10: 17:07 2001 Message-Id: <200110011715.f91HFeH65528@as.vix.com> To: Matt Crawford cc: namedroppers@ops.ietf.org, iesg@ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-00.txt In-Reply-To: Message from Matt Crawford of "Mon, 01 Oct 2001 08:54:00 CDT." <200110011354.f91Ds1m29955@gungnir.fnal.gov> Date: Mon, 01 Oct 2001 10:15:40 -0700 From: Paul A Vixie Resent-To: namedroppers@ops.ietf.org Resent-Date: Mon, 01 Oct 2001 14:17:01 -0500 Resent-From: Matt Crawford > ... > Furthermore, this document makes some purely technical claims that > were soundly rebutted on the mailing list before and after the > meeting. > Matt Crawford uh-oh. matt, i thought you knew the secret handshake so i wasn't worried that i didn't (know it). i guess things are worse than they seemed. to unsubscribe send a message to 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 Oct 2 03:57:44 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29898 for ; Tue, 2 Oct 2001 03:57:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15oKBl-000CYx-00 for namedroppers-data@psg.com; Tue, 02 Oct 2001 00:42:01 -0700 Received: from dhcp118.ripemtg.ripe.net ([193.0.8.118] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15oKBk-000CYi-00 for namedroppers@ops.ietf.org; Tue, 02 Oct 2001 00:42:01 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.33 #1) id 15o6nU-000CMe-00 for namedroppers@ops.ietf.org; Mon, 01 Oct 2001 19:24:04 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Matt Crawford Cc: namedroppers@ops.ietf.org, iesg@ietf.org Reply-To: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-00.txt In-Reply-To: Message from Matt Crawford of "Mon, 01 Oct 2001 08:54:00 CDT." <200110011354.f91Ds1m29955@gungnir.fnal.gov> Date: Mon, 01 Oct 2001 13:01:26 -0400 From: Rob Austein Message-Id: <20011001170127.0A6C61B2D@thrintun.hactrn.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Mon, 01 Oct 2001 08:54:00 -0500 From: Matt Crawford Furthermore, this document makes some purely technical claims that were soundly rebutted on the mailing list before and after the meeting. Please specify. (Is it really necessary to CC the IESG on this discussion?) to unsubscribe send a message to 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 Oct 2 03:58:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29919 for ; Tue, 2 Oct 2001 03:58:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15oKDm-000CdO-00 for namedroppers-data@psg.com; Tue, 02 Oct 2001 00:44:06 -0700 Received: from dhcp118.ripemtg.ripe.net ([193.0.8.118] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15oKDk-000CdH-00 for namedroppers@ops.ietf.org; Tue, 02 Oct 2001 00:44:06 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.33 #1) id 15oJTB-000Cft-00 for namedroppers@ops.ietf.org; Tue, 02 Oct 2001 08:55:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 01 Oct 2001 13:57:32 -0500 From: Matt Crawford Subject: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-00.txt In-reply-to: "01 Oct 2001 13:01:26 EDT." <20011001170127.0A6C61B2D@thrintun.hactrn.net> To: namedroppers@ops.ietf.org Cc: iesg@ietf.org Message-id: <200110011857.f91IvWm01604@gungnir.fnal.gov> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Furthermore, this document makes some purely technical claims that > were soundly rebutted on the mailing list before and after the > meeting. > > Please specify. 1. That the time to collect an N-link chain of A6 records is proportional to N. 2. That the chance of failure to complete a chain is "roughly proportional to N, since each of the queries involved in resolving an A6 chain has roughly the same probability of failure as a single AAAA query." Finally, one that was either invented out of whole cloth for this new document or the result of a gross misunderstanding of something you wrote in -ipv6-dns-tradeoffs-00: 3. That "The issues for DNAME chaining in the reverse tree are substantially identical to the issues for A6 chaining in the forward tree." > (Is it really necessary to CC the IESG on this discussion?) If we are to believe what the chairs have said, then yes. In a strictly logical universe, perhaps not. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Oct 2 03:59:10 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29944 for ; Tue, 2 Oct 2001 03:59:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15oKBp-000CZ5-00 for namedroppers-data@psg.com; Tue, 02 Oct 2001 00:42:05 -0700 Received: from dhcp118.ripemtg.ripe.net ([193.0.8.118] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15oKBn-000CYz-00 for namedroppers@ops.ietf.org; Tue, 02 Oct 2001 00:42:03 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.33 #1) id 15oJYX-000Chg-00 for namedroppers@ops.ietf.org; Tue, 02 Oct 2001 09:01:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 01 Oct 2001 15:10:39 -0500 From: Matt Crawford Subject: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-00.txt To: namedroppers@ops.ietf.org Message-id: <200110012010.f91KAdm01979@gungnir.fnal.gov> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Forwarded by request, ... ------- Forwarded Message Resent: Mon, 01 Oct 2001 14:17:02 -0500 Resent: namedroppers@ops.ietf.org X-rationale: "could you fwd my note to namedroppers, please? randy's not willing." To: Matt Crawford cc: namedroppers@ops.ietf.org, iesg@ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-00.txt In-Reply-To: Message from Matt Crawford of "Mon, 01 Oct 2001 08:54:00 CDT." <200110011354.f91Ds1m29955@gungnir.fnal.gov> Date: Mon, 01 Oct 2001 10:15:40 -0700 From: Paul A Vixie > ... > Furthermore, this document makes some purely technical claims that > were soundly rebutted on the mailing list before and after the > meeting. > Matt Crawford uh-oh. matt, i thought you knew the secret handshake so i wasn't worried that i didn't (know it). i guess things are worse than they seemed. ------- End of Forwarded Message to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Oct 2 04:00:00 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29974 for ; Tue, 2 Oct 2001 03:59:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15oKDj-000CdB-00 for namedroppers-data@psg.com; Tue, 02 Oct 2001 00:44:03 -0700 Received: from dhcp118.ripemtg.ripe.net ([193.0.8.118] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15oKDi-000Cd5-00 for namedroppers@ops.ietf.org; Tue, 02 Oct 2001 00:44:02 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.33 #1) id 15oJLs-000CdB-00 for namedroppers@ops.ietf.org; Tue, 02 Oct 2001 08:48:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: namedroppers@ops.ietf.org Reply-To: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-00.txt In-Reply-To: Message from Matt Crawford of "Mon, 01 Oct 2001 08:54:00 CDT." <200110011354.f91Ds1m29955@gungnir.fnal.gov> From: Rob Austein Date: Mon, 01 Oct 2001 14:04:00 -0400 Message-Id: <20011001180400.707271B64@thrintun.hactrn.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Mon, 01 Oct 2001 08:54:00 -0500 From: Matt Crawford Furthermore, this document makes some purely technical claims that were soundly rebutted on the mailing list before and after the meeting. Please specify. (Is it really necessary to CC the IESG on this discussion?) to unsubscribe send a message to 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 Oct 2 12:20:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19134 for ; Tue, 2 Oct 2001 12:20:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15oRub-000O3L-00 for namedroppers-data@psg.com; Tue, 02 Oct 2001 08:56:49 -0700 Received: from dhcp118.ripemtg.ripe.net ([193.0.8.118]) by psg.com with esmtp (Exim 3.33 #1) id 15oRuZ-000O3E-00 for namedroppers@ops.ietf.org; Tue, 02 Oct 2001 08:56:48 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.33 #1) id 15oRuX-000DWg-00 for namedroppers@ops.ietf.org; Tue, 02 Oct 2001 17:56:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: namedroppers@ops.ietf.org Subject: DNAME (was: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-00.txt) References: <200109281109.HAA09046@ietf.org> From: Johan Ihren Date: 02 Oct 2001 17:38:30 +0200 In-Reply-To: Internet-Drafts@ietf.org's message of "Fri, 28 Sep 2001 07:09:25 -0400" Message-ID: <2cbsjqcart.fsf@snout.autonomica.se> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In the draft I stumbled upon this: > 4 DNAME in IPv6 reverse tree > The issues for DNAME chaining in the reverse tree are substantially > identical to the issues for A6 chaining in the forward tree. > Therefore, in moving RFC 2874 to experimental, the intent of this > document is that use of DNAME RRs in the reverse tree be deprecated. I cannot remember anything about explicitly deprecating DNAME anywhere. The contentious issue was obviously A6 vs AAAA, the bitstrings were more or less non-starters and DNAME was more or less glanced over and deferred back to DNSEXT as purely a DNS issue. But regardless of that, there is one issue of DNAME that did not come up and that I think is worth pointing out explicitly: With DNAME it is possible to renumber (i.e. change the prefix) without changing the *name of the zone* containing the data. Without DNAME that is no longer possible. And this is true regardless of whether the reverse tree is based upon bitstrings or nibbles. And regardless of how often various people think we will or should renumber, there is from an operations point of view a rather sharp difference between a change in zone contents (which happens all the time) and a change in zone names (which require new nameserver configurations, new agreements with slaves, new delegations, etc, etc). And all this recursively all the way down the tree from the point of the prefix change... AAAA in the forward tree will cause more changes to forward zones in time of a prefix change but at least the changes will be in the *same* zone. Not so in the reverse tree without DNAME. In short: the maintenance headaches in the reverse tree go way up without DNAME regardless of whether we have A6 or AAAA in the forward tree. And since they are orthogonal issues the future of DNAME in the reverse tree should be decoupled from whatever happens to A6. And I believe that deprecating DNAME in the reverse tree will either cement a no-renumbering future or kill of the reverse tree for v6 entirely. Regards, Johan Ihren Autonomica to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Oct 3 03:31:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01923 for ; Wed, 3 Oct 2001 03:31:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15og9M-000LfR-00 for namedroppers-data@psg.com; Wed, 03 Oct 2001 00:09:00 -0700 Received: from dhcp118.ripemtg.ripe.net ([193.0.8.118]) by psg.com with esmtp (Exim 3.33 #1) id 15og9L-000LfK-00 for namedroppers@ops.ietf.org; Wed, 03 Oct 2001 00:08:59 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.33 #1) id 15og9J-000EE2-00 for namedroppers@ops.ietf.org; Wed, 03 Oct 2001 09:08:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 2 Oct 2001 17:30:19 -0000 Message-ID: <20011002173019.1816.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Cc: iesg@ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-00.txt References: <20011001170127.0A6C61B2D@thrintun.hactrn.net> <200110011857.f91IvWm01604@gungnir.fnal.gov> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit If you're following a chain of n out-of-bailiwick pointers, and each pointer has probability p of succeeding, independently of the other pointers, then your chance of reaching the end of the chain is p^n. A more sophisticated analysis, taking account of timeouts and retries and multiple servers, produces essentially the same formula. As I put it in http://cr.yp.to/djbdns/killa6.html, the success chance decreases exponentially with the number of out-of-bailiwick pointers. p^n is approximately 1 - (1-p)n if n is not very large and p is close to 1, so the failure chance is roughly proportional to n. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Oct 3 03:36:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01963 for ; Wed, 3 Oct 2001 03:36:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15ogIA-000LvL-00 for namedroppers-data@psg.com; Wed, 03 Oct 2001 00:18:06 -0700 Received: from dhcp118.ripemtg.ripe.net ([193.0.8.118]) by psg.com with esmtp (Exim 3.33 #1) id 15ogI9-000LvC-00 for namedroppers@ops.ietf.org; Wed, 03 Oct 2001 00:18:05 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.33 #1) id 15ogI6-000EFA-00 for namedroppers@ops.ietf.org; Wed, 03 Oct 2001 09:18:02 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 2 Oct 2001 18:02:01 -0000 Message-ID: <20011002180201.12250.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: DNAME (was: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-00.txt) References: <200109281109.HAA09046@ietf.org> <2cbsjqcart.fsf@snout.autonomica.se> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Johan Ihren writes: > there is from an operations point of view a rather sharp difference > between a change in zone contents (which happens all the time) and a > change in zone names This is a local problem, and you are wildly exaggerating the difficulty of solving it. None of IETF's DNS-replication protocols handle new zones. That's why ISPs use better replication protocols, such as rsync. Better protocols are becoming increasingly popular at small sites too. See http://cr.yp.to/djbdns/faq/axfrdns.html#what for a more detailed discussion of DNS replication. Similar comments apply to configuration-file formats, web-based DNS administration tools, etc. Saying ``This rare operation is difficult with our current tools; what a disaster it would be if the operation were more frequent!'' ignores the fact that tools can and do change. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Oct 3 10:21:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16058 for ; Wed, 3 Oct 2001 10:21:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15omYI-0006Hl-00 for namedroppers-data@psg.com; Wed, 03 Oct 2001 06:59:10 -0700 Received: from dhcp118.ripemtg.ripe.net ([193.0.8.118]) by psg.com with esmtp (Exim 3.33 #1) id 15omYH-0006Hd-00 for namedroppers@ops.ietf.org; Wed, 03 Oct 2001 06:59:10 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.33 #1) id 15omYB-000Egc-00 for namedroppers@ops.ietf.org; Wed, 03 Oct 2001 15:59:03 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: Date: Wed, 3 Oct 2001 09:36:14 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-00.txt Cc: lewis@tislabs.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 3:42 PM -0400 9/28/01, Paul Vixie wrote: >indeed, that is true. i am a strong dissenter. A6 has to be mandatory if >IPv6 is going to solve more problems than it creates. As someone who really has no strong opinion (yet) in the A6-vs-AAAA debate: one obstacle to the adoption of A6 is tied to a lack of clarity as to how it will solve problems. I don't know of a clear, concise discussion of the problems that need to be addressed. As a consequence there is no clear indication what A6 will achieve. (Unfortunately, I am not in position to supply such a document.) <> I think A6 is cool because I am an engineer and tend to like Rube Goldberg devices. (Not to imply that A6 is a lot of activity for no benefit, but to imply that A6 is a simply a lot of activity.) However, I really can't back the A6-as-standards track because I don't know whether "A6" is good or not. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com You fly too often when ... the airport taxi is on speed-dial. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Oct 3 11:11:09 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18036 for ; Wed, 3 Oct 2001 11:11:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15onFv-0007dl-00 for namedroppers-data@psg.com; Wed, 03 Oct 2001 07:44:15 -0700 Received: from dhcp118.ripemtg.ripe.net ([193.0.8.118]) by psg.com with esmtp (Exim 3.33 #1) id 15onFu-0007dd-00 for namedroppers@ops.ietf.org; Wed, 03 Oct 2001 07:44:15 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.33 #1) id 15onFp-000EjS-00 for namedroppers@ops.ietf.org; Wed, 03 Oct 2001 16:44:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 03 Oct 2001 09:41:37 -0500 From: Matt Crawford Subject: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-00.txt In-reply-to: "02 Oct 2001 17:30:19 -0000." <20011002173019.1816.qmail@cr.yp.to> To: namedroppers@ops.ietf.org, iesg@ietf.org Message-id: <200110031441.f93Efbm06650@gungnir.fnal.gov> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > If you're following a chain of n out-of-bailiwick pointers, and each > pointer has probability p of succeeding, independently of the other > pointers, With or without the undefined "out-of-bailiwick" modifier, this is a large *if* not supported by facts in evidence, and directly contradicted by recommendations of RFC 2874, section 6. to unsubscribe send a message to 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 Oct 4 04:11:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01428 for ; Thu, 4 Oct 2001 04:11:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15p3Bn-000HSG-00 for namedroppers-data@psg.com; Thu, 04 Oct 2001 00:45:03 -0700 Received: from dhcp118.ripemtg.ripe.net ([193.0.8.118]) by psg.com with esmtp (Exim 3.33 #1) id 15p3Bm-000HS9-00 for namedroppers@ops.ietf.org; Thu, 04 Oct 2001 00:45:02 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.33 #1) id 15p3Bk-000F68-00 for namedroppers@ops.ietf.org; Thu, 04 Oct 2001 09:45:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org Subject: Re: DNAME (was: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-00.txt) References: <200109281109.HAA09046@ietf.org> <2cbsjqcart.fsf@snout.autonomica.se> <20011002180201.12250.qmail@cr.yp.to> From: Johan Ihren Date: 03 Oct 2001 18:19:28 +0200 In-Reply-To: "D. J. Bernstein"'s message of "2 Oct 2001 18:02:01 -0000" Message-ID: <2czo78wvan.fsf@snout.autonomica.se> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "D. J. Bernstein" writes: > Johan Ihren writes: > > there is from an operations point of view a rather sharp difference > > between a change in zone contents (which happens all the time) and a > > change in zone names > > This is a local problem, and you are wildly exaggerating the difficulty > of solving it. How is it a local problem when it recursively propagates down the entire hierarchy below the point of the prefix change? > None of IETF's DNS-replication protocols handle new zones. That's why > ISPs use better replication protocols, such as rsync. Better protocols > are becoming increasingly popular at small sites too. > > See http://cr.yp.to/djbdns/faq/axfrdns.html#what for a more detailed > discussion of DNS replication. > > Similar comments apply to configuration-file formats, web-based DNS > administration tools, etc. Saying ``This rare operation is difficult > with our current tools; what a disaster it would be if the operation > were more frequent!'' ignores the fact that tools can and do change. While I'm all in favour of new tools I see no tool on the horizon that will make reconstructing an entire delegation hierarchy even semi-automatic. The main problem as I see it is not one of better zone-replication protocols, nor tools automating inclusion of new zones, etc, but rather one of delegation management and to some extent trust. Automation of new delegations, in a possibly quite deep hierarchy implies a certain amount of trust between several layers and I think that is very far off. As it should be, for security reasons. Regards, Johan Ihren Autonomica to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Oct 4 04:11:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01439 for ; Thu, 4 Oct 2001 04:11:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15p3HO-000Hii-00 for namedroppers-data@psg.com; Thu, 04 Oct 2001 00:50:50 -0700 Received: from dhcp118.ripemtg.ripe.net ([193.0.8.118]) by psg.com with esmtp (Exim 3.33 #1) id 15p3HN-000Hhx-00 for namedroppers@ops.ietf.org; Thu, 04 Oct 2001 00:50:50 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.33 #1) id 15p3HK-000F6X-00 for namedroppers@ops.ietf.org; Thu, 04 Oct 2001 09:50:46 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3BBB4407.D8F7C972@unixpeople.com> Date: Wed, 03 Oct 2001 09:59:51 -0700 From: "Andy W. Barclay" To: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-00.txt References: <20011001170127.0A6C61B2D@thrintun.hactrn.net> <200110011857.f91IvWm01604@gungnir.fnal.gov> <20011002173019.1816.qmail@cr.yp.to> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I feel you are over-simplifying the problem. You are assuming that each of the queries is independent. I know that its not an absolute, but I feel that generally, a dependency exists, such that if query "n" succeeds, query "n+1" has an increased chance of success. This would imply that the p^n is too pessimistic. "D. J. Bernstein" wrote: > > If you're following a chain of n out-of-bailiwick pointers, and each > pointer has probability p of succeeding, independently of the other > pointers, then your chance of reaching the end of the chain is p^n. A > more sophisticated analysis, taking account of timeouts and retries and > multiple servers, produces essentially the same formula. > > As I put it in http://cr.yp.to/djbdns/killa6.html, the success chance > decreases exponentially with the number of out-of-bailiwick pointers. > > p^n is approximately 1 - (1-p)n if n is not very large and p is close to > 1, so the failure chance is roughly proportional to n. > > ---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. -- Regards, Andy W. Barclay. abarclay@unixpeople.com fax (781) 823-8276 Always a UNIX Evangelist (and sometimes a system and network architect) And The Lord said unto the Good Shepherd "Get lost...This is cattle country" to unsubscribe send a message to 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 Oct 4 04:41:07 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01876 for ; Thu, 4 Oct 2001 04:41:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15p3pR-000JBs-00 for namedroppers-data@psg.com; Thu, 04 Oct 2001 01:26:01 -0700 Received: from dhcp118.ripemtg.ripe.net ([193.0.8.118]) by psg.com with esmtp (Exim 3.33 #1) id 15p3pP-000JBl-00 for namedroppers@ops.ietf.org; Thu, 04 Oct 2001 01:26:00 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.33 #1) id 15p3pM-000F9j-00 for namedroppers@ops.ietf.org; Thu, 04 Oct 2001 10:25:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3BBB7D53.CB7ACA8F@daimlerchrysler.com> Date: Wed, 03 Oct 2001 17:04:19 -0400 From: Kevin Darcy To: namedroppers@ops.ietf.org Subject: Re: DNAME (was: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-00.txt) References: <200109281109.HAA09046@ietf.org> <2cbsjqcart.fsf@snout.autonomica.se> <20011002180201.12250.qmail@cr.yp.to> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit D. J. Bernstein wrote: > Johan Ihren writes: > > there is from an operations point of view a rather sharp difference > > between a change in zone contents (which happens all the time) and a > > change in zone names > > This is a local problem, and you are wildly exaggerating the difficulty > of solving it. > > None of IETF's DNS-replication protocols handle new zones. That's why > ISPs use better replication protocols, such as rsync. Better protocols > are becoming increasingly popular at small sites too. As much as it surprises me, I'm mostly in agreement with Dan here. The lack of automatic zone-creation and -deletion is a *MAJOR* shortcoming of the DNS protocol suite -- every vendor of DNS management tools seems to do it differently, and interoperability between the different methodologies is basically non-existent. This is creating a high degree of "vendor lock-in" to specific products. I keep hearing vague claims that automatic zone-creation and -deletion is barred by some sort of insurmountable security issue, but, frankly speaking, that's a crock of you-know-what. Even if it were true, any such security issue would be out of the scope of the DNS protocol _per_se_. Where I part ways with Dan is in the solution to the problem. He seems to feel that generic tools like rsync and ssh are appropriate for the task. I would prefer for automatic zone-creation and -deletion to be made part of the protocol so that the solution could be self-contained within a DNS implementation and not have as much dependency on operating-system architecture and configuration. - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Oct 4 06:13:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04044 for ; Thu, 4 Oct 2001 06:13:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15p5E7-000Mq8-00 for namedroppers-data@psg.com; Thu, 04 Oct 2001 02:55:35 -0700 Received: from dhcp118.ripemtg.ripe.net ([193.0.8.118]) by psg.com with esmtp (Exim 3.33 #1) id 15p5E5-000Mq1-00 for namedroppers@ops.ietf.org; Thu, 04 Oct 2001 02:55:34 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.33 #1) id 15p5E3-000FHI-00 for namedroppers@ops.ietf.org; Thu, 04 Oct 2001 11:55:31 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Paul A Vixie Cc: namedroppers@ops.ietf.org Subject: Re: DNAME (was: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-00.txt) References: <200110040809.f9489PH25841@as.vix.com> From: Johan Ihren Date: 04 Oct 2001 11:48:31 +0200 In-Reply-To: Paul A Vixie's message of "Thu, 04 Oct 2001 01:09:25 -0700" Message-ID: <2cwv2bviq8.fsf@snout.autonomica.se> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul A Vixie writes: Paul, I am fairly sure that you and I are misunderstanding each other here. I'll try to make my point somewhat clearer... > and you think an AAAA/PTR tree will have fewer redelegation points > than an A6/DNAME tree? why? No, no, no, no. > please answer on-list, i can't post there right now. I make no claims whatsoever about the number of delegation points in the tree. For the sake of discussion I like to assume that there are exactly the same number of delegations regardless of the metod used for delegation. Also, I only talk about the reverse tree here, and usage of DNAME in it. The AAAA vs A6 issue is completely orthogonal to this. My point is that regardless of how many delegations there are below the point of a prefix change, these delgations * with DNAME will survive, since only the DNAMEs at the apex has to be changed (a maximum of sixteen given nibbles). * with traditional NS delegations the entire subtree will break apart, since the names of every single down-tree old delegation point will change. A very contrived example: let's say that 192.in-addr.arpa gets changed to 193.in-addr.arpa (yes, I said it was contrived...): With DNAME: change 1.192.in-addr.arpa. DNAME ip6.isp1.net. 2.192.in-addr.arpa. DNAME ip6.isp2.net. ... into 1.193.in-addr.arpa. DNAME ip6.isp1.net. 2.193.in-addr.arpa. DNAME ip6.isp2.net. ... and we're done. Without DNAME: recursively update every single delegation point in the set *.*.192.in-addr.arpa. NS ... ... For 192.in-addr.arpa this is roughly 2000+ delegation points as far as I know, but that's only because 192 is unusually clean. And because the v6 nibbles have a much deeper hierarchy I guess that it is not unreasonable to expect more delegations in the v6 reverse trees. My claim is that an hierarchy with thousands of delegation points will not simply reconstruct itself if you break it apart from above unless there is a *really* driving force for it, and then they will still be rather unpleased about all the extra work. Regards, Johan Ihren Autonomica to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Oct 4 12:09:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17528 for ; Thu, 4 Oct 2001 12:09:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15pAhK-000CNO-00 for namedroppers-data@psg.com; Thu, 04 Oct 2001 08:46:06 -0700 Received: from dhcp118.ripemtg.ripe.net ([193.0.8.118]) by psg.com with esmtp (Exim 3.33 #1) id 15pAhJ-000CNI-00 for namedroppers@ops.ietf.org; Thu, 04 Oct 2001 08:46:05 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.33 #1) id 15pAhF-000FjT-00 for namedroppers@ops.ietf.org; Thu, 04 Oct 2001 17:46:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Kevin Darcy Cc: namedroppers@ops.ietf.org Subject: Re: DNAME (was: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-00.txt) References: <200109281109.HAA09046@ietf.org> <2cbsjqcart.fsf@snout.autonomica.se> <20011002180201.12250.qmail@cr.yp.to> <3BBB7D53.CB7ACA8F@daimlerchrysler.com> From: Johan Ihren Date: 04 Oct 2001 17:28:56 +0200 In-Reply-To: Kevin Darcy's message of "Wed, 03 Oct 2001 17:04:19 -0400" Message-ID: <2cn137toef.fsf@snout.autonomica.se> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kevin Darcy writes: > D. J. Bernstein wrote: > > > Johan Ihren writes: > > > there is from an operations point of view a rather sharp difference > > > between a change in zone contents (which happens all the time) and a > > > change in zone names > > > > This is a local problem, and you are wildly exaggerating the difficulty > > of solving it. > > > > None of IETF's DNS-replication protocols handle new zones. That's why > > ISPs use better replication protocols, such as rsync. Better protocols > > are becoming increasingly popular at small sites too. > > As much as it surprises me, I'm mostly in agreement with Dan here. The > lack of automatic zone-creation and -deletion is a *MAJOR* shortcoming of > the DNS protocol suite -- every vendor of DNS management tools seems to do > it differently, and interoperability between the different methodologies > is basically non-existent. This is creating a high degree of "vendor > lock-in" to specific products. > > I keep hearing vague claims that automatic zone-creation and -deletion is > barred by some sort of insurmountable security issue, but, frankly > speaking, that's a crock of you-know-what. Even if it were true, any such > security issue would be out of the scope of the DNS protocol _per_se_. > > Where I part ways with Dan is in the solution to the problem. He seems to > feel that generic tools like rsync and ssh are appropriate for the task. I > would prefer for automatic zone-creation and -deletion to be made part of > the protocol so that the solution could be self-contained within a > DNS implementation and not have as much dependency on operating-system > architecture and configuration. ...and I still think that you are both focusing on the wrong issue. Zone creation is a problem, yes, but it is possibly a question of implementation (mostly). The real issue is reconstructing the delegation hierarchy for the entire subtree when every single owner name has changed. Regards, Johan Ihren Autonomica to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Oct 5 05:03:12 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17360 for ; Fri, 5 Oct 2001 05:03:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15pQZ1-0003qZ-00 for namedroppers-data@psg.com; Fri, 05 Oct 2001 01:42:35 -0700 Received: from [62.41.12.14] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15pQZ0-0003qR-00 for namedroppers@ops.ietf.org; Fri, 05 Oct 2001 01:42:34 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15pK0a-0000UG-00 for namedroppers@ops.ietf.org; Fri, 05 Oct 2001 03:42:36 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 4 Oct 2001 22:45:07 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org cc: dthaler@microsoft.com Subject: IPv6 mDNS configuration issue Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit It has been pointed out that just because a DNS server may be configured for IPv4 (such as via DHCPv4 DNS server option), doesn't mean that it is available for IPv6. For example, a router might support stateless autoconfig, but have not support DHCPv6, so that the only way to get dynamic naming on the home network is to enable mDNS. Therefore, it appears that the decision on use of mDNS needs to be made separately for IPv4 and IPv6. On a network with a router with stateless autoconfig, but no DNS discovery, and no DHCPv6, mDNS SHOULD be enabled. Does this make sense? to unsubscribe send a message to 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 Oct 5 05:03:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17374 for ; Fri, 5 Oct 2001 05:03:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15pQYt-0003qP-00 for namedroppers-data@psg.com; Fri, 05 Oct 2001 01:42:27 -0700 Received: from [62.41.12.14] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15pQYs-0003qJ-00 for namedroppers@ops.ietf.org; Fri, 05 Oct 2001 01:42:26 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15pK0R-0000U4-00 for namedroppers@ops.ietf.org; Fri, 05 Oct 2001 03:42:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 4 Oct 2001 22:19:32 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Resolution of comments on mdns-05 Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Changes proposed to draft-ietf-dnsext-mdns-05.txt Bernard Aboba --------------------------------------------------------------- Section 2: Submitted by: Bernard Aboba Justification: The specification is not clear about why mDNS is not enabled by default for home networks where a DHCP server is present. It is also not clear about whether mDNS is enabled when there is a router, but no DHCP or DNS server (as might be the case when using IPv6 with stateless autoconfig). Change: "Propagation of multicast DNS packets within the local subnet is considered sufficient to enable DNS name resolution in small adhoc networks. The assumption is that if a network has a router, then the network either has a DNS server or the router can function as a DNS proxy, possibly implementing dynamic DNS." To: "Propagation of multicast DNS packets within the local subnet is considered sufficient to enable DNS name resolution in small adhoc networks. The assumption is that if a network has a router, then the network either has a DNS server support dynamic DNS, or the router can function as a DNS proxy. By implementing DHCP as well as a DNS proxy and dynamic DNS, routers can provide name resolution for the names of the hosts on the local network. This functionality is easily provided, and so in such cases it is assumed that multicast DNS need not be enabled by default." Proposed resolution: Accept --------------------------------------------------------------- Section 3: Submitted by: Levon Esibov Justification: Sending a unicast query for a name ending with the ".local.arpa" suffix should be ok over any transport after a response to a multicast request is received with the TC bit set, not just TCP. Change: " a. A sender repeats a query over TCP after it received a response to the previous multicast query with the TC bit set, or " To: " a. A sender repeats a query after it received a response to the previous multicast query with the TC bit set, or " Proposed resolution: Accept --------------------------------------------------------------- Section 3: Submitted by: Levon Esibov Justification: Prohibiting DNS servers from listening to or responding to mDNS queries seems a bit extreme. Why can't DNS servers listen to and respond to queries for their own name? Change: "If a DNS server is running on a host, the host MUST NOT listen for multicast DNS queries, to prevent the host from listening on port 53 and intercepting DNS queries directed to a DNS server. By default, a DNS server MUST NOT listen to multicast DNS queries." To: "If a DNS server is running on a host, only the DNS server MAY listen for multicast DNS queries. Other services running on such a host MUST NOT listen for multicast DNS queries on port 53, since otherwise they would intercept DNS queries directed to a DNS server." Proposed resolution: Discuss --------------------------------------------------------------- Section 3.1: Submitted by: Levon Esibov, Aidan Williams Justification: In some cases, it might make sense to enable mDNS by default, so this shouldn't be prohibited. Change: " Multicast DNS usage can be configured manually or automatically. On interfaces where no manual or automatic configuration has been performed, multicast DNS is enabled by default." To: "Multicast DNS usage can be configured manually or automatically. On interfaces where no manual or automatic configuration has been performed, multicast DNS SHOULD be enabled by default." Proposed resolution: Accept --------------------------------------------------------------- Section 3.1: Submitted by: Levon Esibov, Aidan Williams Justification: A DNS server shouldn't be prohibited from answering mDNS queries for its own name. Also, the prohibition on enabling of mDNS in situations where there is configuration seems a bit harsh. Change: "If an interface has been configured via any automatic configuration mechanism which is able to supply DNS configuration information, then multicast DNS MUST NOT be used on that interface unless it has been explicitly enabled, whether via that mechanism or any other. This ensures that upgraded hosts do not change their default behavior, without requiring the source of the configuration information to be simultaneously updated. This implies that on the interface, the host will neither listen on the DNS LINKLOCAL multicast address, nor will it send queries to that address. For a DNS server, automatic configuration mechanisms MUST NOT enable multicast DNS on any interface." To: "If an interface has been configured via any automatic configuration mechanism which is able to supply DNS configuration information, then multicast DNS SHOULD NOT be used on that interface unless it has been explicitly enabled, whether via that mechanism or any other. This ensures that upgraded hosts do not change their default behavior, without requiring the source of the configuration information to be simultaneously updated. This implies that on the interface, the host will neither listen on the DNS LINKLOCAL multicast address, nor will it send queries to that address." Proposed resolution: Accept --------------------------------------------------------------- Section 5: Submitted by: Levon Esibov Justification: not isn't capitalized when it has standards language meaning. "the" is missing from the sentence. Change: "After client receives an YXRRSET response to its dynamic update request that a UNIQUE resource record does not exist, the host MUST not use the UNIQUE resource record in responses to multicast queries and dynamic update requests." To: "After the client receives an YXRRSET response to its dynamic update request that a UNIQUE resource record does not exist, the host MUST NOT use the UNIQUE resource record in responses to multicast queries and dynamic update requests." Proposed resolution: Accept --------------------------------------------------------------- Section 5.1: Submitted by: Levon Esibov Justification: name conflicts will only exist in situations where hosts use a name on an interface. If the name is not used, then conflicts will not occur. Change: "In this situation, the multi-homed myhost will probe for, and defend, its host name on both interfaces. A conflict will be detected on one interface, but not the other, and as a result, the multi-homed myhost will not be able to respond with a host RR for "myhost." To: "In this situation, the multi-homed myhost will probe for, and defend, its host name on both interfaces. A conflict will be detected on one interface, but not the other, and as a result, the multi-homed myhost will not be able to respond with a host RR for 'myhost', unless the host is configured to use the 'myhost' name only on the left (see Figure 1) network connection." Proposed resolution: Discuss --------------------------------------------------------------- Section 7: Submitted by: Levon Esibov Justification: Recursive resolution of mDNS queries shouldn't be allowable. Rather than replying with non-authoritative NXDOMAIN, it makes more sense for a DNS server not to reply at all. Change: " - DNS servers SHOULD NOT forward queries for domain names in the local.arpa domain - if the server cannot answer the query from its own database, it should reply with a non-authoritative NXDOMAIN. " To: " - DNS servers SHOULD NOT forward or recursively resolve queries for domain names in the local.arpa domain - if the server cannot answer the query from its own database, it MUST NOT reply. " Proposed resolution: Accept --------------------------------------------------------------- Section 9: Submitted by: Levon Esibov Justification: The current specification wording doesn't distinguish between behavior of mDNS senders and ordinary hosts. Change: "The mechanism specified in this draft does not require use of the DNSSEC, which means that the responses to the multicast DNS queries may not be authenticated. If a network contains a "signed key distribution center" for all (or at least some) of the DNS zones that the responders are authoritative for, then hosts on such a network are configured with the key for the top zone, "local.arpa." (hosted by "signed keys distribution center") and may use DNSSEC for authentication of the responders using DNSSEC." To: "The mechanism specified in this draft does not require use of DNSSEC. As a result, responses to multicast DNS queries MAY NOT be authenticated. If a network contains a "signed key distribution center" for some of the DNS zones that the responders are authoritative for, and senders on that network are configured with the key for the top zone "local.arpa." (hosted by "signed keys distribution center"), then senders MAY authenticate the responses using DNSSEC." Proposed resolution: Accept to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Oct 6 19:41:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01519 for ; Sat, 6 Oct 2001 19:41:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15q0jJ-000FJ2-00 for namedroppers-data@psg.com; Sat, 06 Oct 2001 16:19:37 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15q0jH-000FIw-00 for namedroppers@ops.ietf.org; Sat, 06 Oct 2001 16:19:36 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15q0jF-0000vI-00 for namedroppers@ops.ietf.org; Sat, 06 Oct 2001 16:19:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 5 Oct 2001 12:35:01 -0700 (PDT) Message-Id: <200110051935.MAA04318@gulag.araneus.fi> To: Kevin Darcy Cc: namedroppers Subject: Re: wg last call for draft-ietf-dnsext-unknown-rrs-01.txt In-Reply-To: <3BB52A7D.5C859040@daimlerchrysler.com> References: <20010926111745.A10616@outpost.ds9a.nl> <200109261904.MAA03755@gulag.araneus.fi> <3BB23A32.4FB62E0D@daimlerchrysler.com> <200109262147.OAA03864@gulag.araneus.fi> <3BB251E7.E77BE8AB@daimlerchrysler.com> <200109271742.KAA04466@gulag.araneus.fi> <3BB3A0A7.3B63FB1B@daimlerchrysler.com> <200109281744.KAA05226@gulag.araneus.fi> <3BB4E766.11981711@daimlerchrysler.com> <200109282314.QAA05401@gulag.araneus.fi> <3BB52A7D.5C859040@daimlerchrysler.com> From: gson@isc.org (Andreas Gustafsson) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kevin Darcy writes: > EDNS0 undercuts the rationale for prohibiting compression in new record types, > because it provides a "safe", point-to-point way to compress records of those > types. Agreed, that's not technically the same as "obsoleting" the > prohibition, but it does raise a significant likelihood that exceptions will > become necessary. It doesn't raise the likelihood that exceptions are necessary, it just makes it easier to implement such exceptions if they turn out to be necessary. I don't think they will be. > I think there should at least be some language in the > document acknowledging this fact, because -- let's face it -- you're not just > "documenting" an existing prohibition, you're *reinforcing* it. And reinforced it should be. If we leave an explicit loophole for negotiated compression schemes, people will come up with them whether they are truly necessary or not. > It wouldn't necessarily be a manual operation, and it wouldn't necessarily be > burdensome. If the new record type has only a specialized use, then perhaps > implementations will default it OFF and only those administrators who go out > of their way to do so -- presumably with a full understanding of their local > network/DNS environment and/or the tradeoffs of using the new record type -- > will turn it ON. All that just to save a couple of bytes? It's just not worth the effort. -- Andreas Gustafsson, gson@isc.org to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Oct 6 19:44:44 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01531 for ; Sat, 6 Oct 2001 19:44:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15q0rc-000Fcd-00 for namedroppers-data@psg.com; Sat, 06 Oct 2001 16:28:12 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15q0rb-000FcX-00 for namedroppers@ops.ietf.org; Sat, 06 Oct 2001 16:28:11 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15q0ra-0000w1-00 for namedroppers@ops.ietf.org; Sat, 06 Oct 2001 16:28:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 6 Oct 2001 01:55:30 -0000 Message-ID: <20011006015530.21390.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: DNAME (was: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-00.txt) References: <200109281109.HAA09046@ietf.org> <2cbsjqcart.fsf@snout.autonomica.se> <20011002180201.12250.qmail@cr.yp.to> <3BBB7D53.CB7ACA8F@daimlerchrysler.com> <2cn137toef.fsf@snout.autonomica.se> Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Johan Ihren writes: > The real issue is reconstructing the delegation hierarchy for the > entire subtree when every single owner name has changed. What's the big deal? If you're changing 128.248.* to 131.193.*, for example, then obviously you're also changing *.248.128.in-addr.arpa to *.193.131.in-addr.arpa. This is a straightforward one-pass operation if the DNS data file format was designed by a competent programmer. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Oct 7 06:39:06 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21753 for ; Sun, 7 Oct 2001 06:39:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15qB4K-000DNZ-00 for namedroppers-data@psg.com; Sun, 07 Oct 2001 03:22:00 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15qB4I-000DNS-00 for namedroppers@ops.ietf.org; Sun, 07 Oct 2001 03:21:59 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15qB4H-00012m-00 for namedroppers@ops.ietf.org; Sun, 07 Oct 2001 03:21:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Sun, 7 Oct 2001 11:00:19 +0200 From: =?iso-8859-1?Q?M=E5ns_Nilsson?= To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org Subject: Re: DNAME (was: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-00.txt) Message-ID: <20011007110019.A19854@besserwisser.org> References: <200109281109.HAA09046@ietf.org> <2cbsjqcart.fsf@snout.autonomica.se> <20011002180201.12250.qmail@cr.yp.to> <3BBB7D53.CB7ACA8F@daimlerchrysler.com> <2cn137toef.fsf@snout.autonomica.se> <20011006015530.21390.qmail@cr.yp.to> In-Reply-To: <20011006015530.21390.qmail@cr.yp.to>; from djb@cr.yp.to on Sat, Oct 06, 2001 at 01:55:30AM -0000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Subject: Re: DNAME (was: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-00.txt) Date: Sat, Oct 06, 2001 at 01:55:30AM -0000 Quoting D. J. Bernstein (djb@cr.yp.to): > Johan Ihren writes: > > The real issue is reconstructing the delegation hierarchy for the > > entire subtree when every single owner name has changed. > > What's the big deal? If you're changing 128.248.* to 131.193.*, for > example, then obviously you're also changing *.248.128.in-addr.arpa to > *.193.131.in-addr.arpa. This is a straightforward one-pass operation if > the DNS data file format was designed by a competent programmer. You obviously haven't tried in real life. I'm really sorry, Dan. This is something you can't use to throw blame on the Bind company; the master file format is the small (if any at all) problem. The big issue is to find people that run subzones and get them to understand that they must perform the necessary steps, as well as updating the rest of the network structure, since all must happen in coordination. As this now is a matter for the DNSOP wg (if at all an IETF matter) I will stop. Regards, -- Måns Nilsson MN1334-RIPE http://vvv.besserwisser.org GOOD-NIGHT, everybody ... Now I have to go administer FIRST-AID to my pet LEISURE SUIT!! to unsubscribe send a message to 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 Oct 8 04:01:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16058 for ; Mon, 8 Oct 2001 04:01:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15qV4M-000Bwq-00 for namedroppers-data@psg.com; Mon, 08 Oct 2001 00:43:22 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15qV4L-000Bwk-00 for namedroppers@ops.ietf.org; Mon, 08 Oct 2001 00:43:21 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15qV4L-000FC6-00 for namedroppers@ops.ietf.org; Mon, 08 Oct 2001 00:43:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 7 Oct 2001 20:13:31 -0000 Message-ID: <20011007201331.30422.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: DNAME (was: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-00.txt) References: <200109281109.HAA09046@ietf.org> <2cbsjqcart.fsf@snout.autonomica.se> <20011002180201.12250.qmail@cr.yp.to> <3BBB7D53.CB7ACA8F@daimlerchrysler.com> <2cn137toef.fsf@snout.autonomica.se> <20011006015530.21390.qmail@cr.yp.to> <20011007110019.A19854@besserwisser.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Nilsson writes: > You obviously haven't tried in real life. UIC renumbered half its network a few years ago. DNS records were the easiest part of the process. UIC had already delegated math.uic.edu to the math department. That zone had a bunch of records referring to 128.248.178.*, for example. The math.uic.edu administrator had to change those to 131.193.178.*. You seem to be claiming that DNAME would have eliminated the need for UIC to notify the math.uic.edu administrator that the network was being renumbered. That's ridiculous. Ihren was talking about something different: namely, the difficulty of renaming the 178.248.128.in-addr.arpa zone to 178.193.131.in-addr.arpa. Automating this change is difficult with BIND's configuration-file format. But it's easy with the tinydns data format. Ihren was claiming that, in a world of frequent renumbering, renaming zones of this type would be a serious problem. My point is that, in a world of frequent renumbering, people would use tools that make the renaming easy. This is a purely local issue. Coming back to the protocol issues: We could use DNAME to eliminate zones of this type. But Ihren was wildly overestimating the benefits of eliminating these zones. Meanwhile, there are huge costs: * We'd have to change the DNS software on millions of computers before we could start deploying DNAME records. * Deploying DNAME records would hurt the reliability of DNS lookups, as explained in http://cr.yp.to/djbdns/killa6.html. So I continue to object to DNAME. > The big issue is to find people that run subzones and get them to > understand that they must perform the necessary steps, In case you haven't noticed, your DNS data includes a list of all your child zones. It even tells you the names of the relevant servers! Finding all the relevant DNS servers is trivial compared to finding all the other places---in disk files and, for machines that shouldn't be rebooted, in RAM---where IP addresses are stored. Of course, there's also the _really_ big issue of eliminating long-lived TCP connections from the Internet protocol suite. I've seen a few people talking about renumbering sites every day; I haven't seen them give any details of how they'll keep their ssh login sessions going. None of this is rocket science. If the idea of frequent renumbering is meant to be taken seriously then all the problems will be solved. This doesn't mean that we should mindlessly adopt a proposal merely because it is labelled as ``support for renumbering.'' ---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 Oct 8 04:02:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16070 for ; Mon, 8 Oct 2001 04:02:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15qV4f-000Bxz-00 for namedroppers-data@psg.com; Mon, 08 Oct 2001 00:43:41 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15qV4f-000Bxs-00 for namedroppers@ops.ietf.org; Mon, 08 Oct 2001 00:43:41 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15qV4f-000FCg-00 for namedroppers@ops.ietf.org; Mon, 08 Oct 2001 00:43:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 7 Oct 2001 13:18:56 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Additional proposed changes to mdns-05 Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Additional changes proposed to draft-ietf-dnsext-mdns-05.txt Bernard Aboba --------------------------------------------------------------- Section 3.1 Submitted by: Bernard Aboba Justification: IPv6 and IPv4 mDNS configuration are handled separately. It is possible for mDNS to be enabled for IPv6 at the same time it is disabled for IPv4. The text needs to be modified to clarify this. Change: "Multicast DNS usage can be configured manually or automatically. On interfaces where no manual or automatic configuration has been performed, multicast DNS SHOULD be enabled by default. For IPv6, the stateless DNS discovery mechanisms described in "IPv6 Stateless DNS Discovery" [19] can be used to discover whether multicast DNS is globally enabled or disabled. Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to configure multicast DNS on an interface. The mDNS Enable Option, described in [6], can be used to explicitly enable or disable use of multicast DNS on an interface, as well as to specify the order in which DNS and multicast DNS is used on that interface. The mDNS Enable Option affects only DNS resolver behavior, that is, how DNS resolution is performed, and whether multicast DNS is used. The mDNS Enable Option does not determine whether or in which order DNS itself is used for name resolution. This can be specified, for example, using the Name Service Search Option for DHCP, RFC 2937 [3], which can be used to globally determine where DNS is used within the name service search order. If an interface has been configured via any automatic configuration mechanism which is able to supply DNS configuration information, then multicast DNS SHOULD NOT be used on that interface unless it has been explicitly enabled, whether via that mechanism or any other. This ensures that upgraded hosts do not change their default behavior, without requiring the source of the configuration information to be simultaneously updated. This implies that on the interface, the host will neither listen on the DNS LINKLOCAL multicast address, nor will it send queries to that address." To: "Multicast DNS usage can be configured manually or automatically. On interfaces where no manual or automatic configuration has been performed for a given protocol (IPv4 or IPv6), multicast DNS SHOULD be enabled by default for that protocol. For IPv6, the stateless DNS discovery mechanisms described in "IPv6 Stateless DNS Discovery" [19] can be used to discover whether multicast DNS is globally enabled or disabled. Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to configure multicast DNS on an interface. The mDNS Enable Option, described in [6], can be used to explicitly enable or disable use of multicast DNS on an interface for a given protocol, as well as to specify the order in which DNS and multicast DNS is used on that interface. The mDNS Enable Option affects only DNS resolver behavior, that is, how DNS resolution is performed, and whether multicast DNS is used. The mDNS Enable Option does not determine whether or in which order DNS itself is used for name resolution. This can be specified, for example, using the Name Service Search Option for DHCP, RFC 2937 [3], which can be used to globally determine where DNS is used within the name service search order. If an interface has been configured for a given protocol via any automatic configuration mechanism which is able to supply DNS configuration information, then multicast DNS SHOULD NOT be used on that interface for that protocol unless it has been explicitly enabled, whether via that mechanism or any other. This ensures that upgraded hosts do not change their default behavior, without requiring the source of the configuration information to be simultaneously updated. This implies that on the interface, the host will neither listen on the DNS LINKLOCAL multicast address, nor will it send queries to that address. Note that it is possible for mDNS to be enabled for use with IPv6 at the same time it is disabled for IPv4, and vice versa. For example, where a home gateway implements a DNS proxy and DHCPv4, but not DHCPv6 or DNS autoconfiguration, there may be no mechanism for allowing IPv6 hosts to resolve the names of other IPV6 hosts on the home network. In this situation, mDNS is useful for resolution of dynamic names, and it will be enabled for use with IPv6, even though it is disabled for use with IPv4." Proposed resolution: Accept --------------------------------------------------------------- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Oct 8 04:44:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16254 for ; Mon, 8 Oct 2001 04:44:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15qVtX-000E0H-00 for namedroppers-data@psg.com; Mon, 08 Oct 2001 01:36:15 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15qVtX-000E0A-00 for namedroppers@ops.ietf.org; Mon, 08 Oct 2001 01:36:15 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15qVtX-000Gde-00 for namedroppers@ops.ietf.org; Mon, 08 Oct 2001 01:36:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org Subject: Re: DNAME (was: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-00.txt) References: <200109281109.HAA09046@ietf.org> <2cbsjqcart.fsf@snout.autonomica.se> <20011002180201.12250.qmail@cr.yp.to> <3BBB7D53.CB7ACA8F@daimlerchrysler.com> <2cn137toef.fsf@snout.autonomica.se> <20011006015530.21390.qmail@cr.yp.to> <20011007110019.A19854@besserwisser.org> <20011007201331.30422.qmail@cr.yp.to> Message-Id: Date: Mon, 08 Oct 2001 01:32:47 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > If the idea of frequent renumbering is meant to be taken seriously then > all the problems will be solved. This doesn't mean that we should > mindlessly adopt a proposal merely because it is labelled as ``support > for renumbering.'' ^ without clearly and simply describing how the ENTIRE frequent and/or fast system will COMPLETELY work. without hand-waving. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Oct 8 11:19:02 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23471 for ; Mon, 8 Oct 2001 11:19:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15qbmq-000Mx0-00 for namedroppers-data@psg.com; Mon, 08 Oct 2001 07:53:44 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15qbmq-000Mwu-00 for namedroppers@ops.ietf.org; Mon, 08 Oct 2001 07:53:44 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15qbmq-0000XU-00 for namedroppers@ops.ietf.org; Mon, 08 Oct 2001 07:53:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 8 Oct 2001 14:22:02 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: Re: Proposed changes to mdns-05 To: Bernard Aboba , namedroppers@ops.ietf.org Cc: erik.guttman@sun.com In-Reply-To: "Your message with ID" Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Bernard, I include comments on discussion items. > --------------------------------------------------------------- > Section 3: > > Submitted by: Levon Esibov > Justification: Prohibiting DNS servers from listening to or > responding to mDNS queries seems a bit extreme. Why can't DNS > servers listen to and respond to queries for their own name? > > Change: > > "If a DNS server is running on a host, the host MUST NOT listen for > multicast DNS queries, to prevent the host from listening on port 53 > and intercepting DNS queries directed to a DNS server. > By default, a DNS server MUST NOT listen to multicast DNS queries." > > To: > > "If a DNS server is running on a host, only the DNS server MAY listen for > multicast DNS queries. Other services running on such a host MUST NOT listen > for multicast DNS queries on port 53, since otherwise they would intercept > DNS queries directed to a DNS server." > > Proposed resolution: Discuss What should the DNS server do with the requests it receives? Should the DNS server only respond to multicast requests for its own name - or should it respond to multicast requests for any name. Or, should we just be silent about this? If the DNS server responds for names other than its own, there is the possibility that another host will respond with a different answer. > --------------------------------------------------------------- > Section 5.1: > > Submitted by: Levon Esibov > Justification: name conflicts will only exist in situations where > hosts use a name on an interface. If the name is not used, then > conflicts will not occur. > > Change: > > "In this situation, the multi-homed myhost will probe for, and defend, > its host name on both interfaces. A conflict will be detected on one > interface, but not the other, and as a result, the multi-homed myhost > will not be able to respond with a host RR for "myhost." > > To: > > "In this situation, the multi-homed myhost will probe for, and defend, > its host name on both interfaces. A conflict will be detected on one > interface, but not the other, and as a result, the multi-homed myhost > will not be able to respond with a host RR for 'myhost', unless the > host is configured to use the 'myhost' name only on the left (see > Figure 1) network connection." > > Proposed resolution: Discuss By limiting the scope of the problem, it can be solved. I like this. The wording is pretty awkward though. How about: In this situation, the multi-homed myhost will probe for, and defend, its host name on both interfaces. A conflict will be detected on one interface, but not the other. The multi-homed myhost will not be able to respond with a host RR for 'myhost' on the interface on the right (see Figure 1). The multi-homed host may, however, be configured to use the 'myhost' name on the interface on left. > --------------------------------------------------------------- > > Section 7: > > Submitted by: Levon Esibov > Justification: Recursive resolution of mDNS queries shouldn't > be allowable. Rather than replying with non-authoritative NXDOMAIN, > it makes more sense for a DNS server not to reply at all. > To: > - DNS servers SHOULD NOT forward or recursively resolve > queries for domain names in the local.arpa domain - if the > server cannot answer the query from its own database, > it MUST NOT reply. Excellent. Erik to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Oct 9 15:06:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11712 for ; Tue, 9 Oct 2001 15:06:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15r1pp-000GFT-00 for namedroppers-data@psg.com; Tue, 09 Oct 2001 11:42:33 -0700 Received: from mpfg.attlabs.net ([12.106.35.2] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15r1po-000GFM-00 for namedroppers@ops.ietf.org; Tue, 09 Oct 2001 11:42:32 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15r1pl-0000wA-00 for namedroppers@ops.ietf.org; Tue, 09 Oct 2001 11:42:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200110091619.f99GJbH36924@as.vix.com> To: namedroppers@ops.ietf.org Subject: EDNS1 Date: Tue, 09 Oct 2001 09:19:37 -0700 From: Paul A Vixie Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit several folks in the last few weeks have asked me about EDNS1 and so i'd like to revive the draft and give it the discussion (and/or decent burial) that it needs. here's the last published version, which i'd like to hear some comments about so i can improve it (somehow?) and officially resubmit. DNSIND Working Group Paul Vixie INTERNET-DRAFT ISC June, 1999 Extensions to DNS (EDNS1) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document specifies a number of extensions within the Extended DNS framework defined by [EDNS0], including several new extended label types and the ability to ask multiple questions in a single request. 1 - Rationale and Scope 1.1. EDNS (see [EDNS0]) specifies an extension mechanism to DNS (see [RFC1035]) which provides for larger message sizes, additional label types, and new message flags. 1.2. This document makes use of the EDNS extension mechanisms to add several new extended label types and message options, and the ability to ask multiple questions in a single request. Expires December 1999 [Page 1] INTERNET-DRAFT EDNS1 June 1999 2 - Affected Protocol Elements 2.1. Compression pointers are 14 bits in size and are relative to the start of the DNS Message, which can be 64KB in length. 14 bits restrict pointers to the first 16KB of the message, which makes labels introduced in the last 48KB of the message unreachable by compression pointers. A longer pointer format is needed. 2.2. DNS Messages are limited to 65535 octets in size when sent over TCP. This acts as an effective maximum on RRset size, since multiple TCP messages are only possible in the case of zone transfers. Some mechanism must be created to allow normal DNS responses (other than zone transfers) to span multiple DNS Messages when TCP is used. 2.3. Multiple queries in a question section have not been supported in DNS due the applicability of some DNS Message Header flags (such as AA) and of the RCODE field only to a single QNAME, QTYPE, and QCLASS. Multiple questions per request are desirable, and some way of asking them must be made available. 3 - Extended Label Types 3.1. In [EDNS0], the ``0 1'' label type was specified to denote an extended label type, whose value is encoded in the lower six bits of the first octet of a label, and an extended label type of ``1 1 1 1 1 1'' was further reserved for use in future multibyte extended label types. 3.2. The ``0 0 0 0 0 0'' extended label type will indicate an extended compression pointer, such that the following two octets comprise a 16-bit compression pointer in network byte order. Like the normal compression pointer, this pointer is relative to the start of the DNS Message. 3.3. The ``0 0 0 0 0 1'' extended label type will indicate a counted bit string label as described in [CRAW98]. 3.4. The ``0 0 0 0 1 0'' extended label type will indicate a ``long local compression pointer'' as described in [KOCH98]. Expires December 1999 [Page 2] INTERNET-DRAFT EDNS1 June 1999 4 - OPT pseudo-RR Flags and Options 4.1. The extended RCODE and flags are structured as follows: +0 (MSB) +1 (LSB) +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 0: | EXTENDED-RCODE | VERSION | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2: |MD |FM |RRD|LM | Z | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ EXTENDED-RCODE Forms upper 8 bits of extended 12-bit RCODE. (As defined by [EDNS0].) VERSION Indicates the implementation level of whoever sets it. Full conformance with the draft standard version of this specification is version ``1.'' Note that both requestors and responders should set this to the highest level they implement, that responders should send back RCODE=BADVERS and that requestors should be prepared to probe using lower version numbers if they receive an RCODE=BADVERS. MD ``More data'' flag. Valid only in TCP streams where message ordering and reliability are guaranteed. This flag indicates that the current message is not the complete request or response, and should be aggregated with the following message(s) before being considered complete. Such messages are called ``segmented.'' It is an error for the RCODE (including the EXTENDED- RCODE), AA flag, or DNS Message ID to differ among segments of a segmented message. It is an error for TC to be set on any message of a segmented message. Any given RR must fit completely within a message, and all messages will both begin and end on RR boundaries. Each section in a multipart message must appear in normal message order, and each section must be complete before later sections are added. All segments of a message must be transmitted contiguously, without interleaving of other messages. FM ``First match'' flag. Notable only when multiple questions are present. If set in a request, questions will be processed in wire order and the first question whose answer would have NOERROR AND ANCOUNT>0 is treated Expires December 1999 [Page 3] INTERNET-DRAFT EDNS1 June 1999 as if it were the only question in the query message. Otherwise, questions can be processed in any order and all possible answer records will be included in the response. Response FM should be ignored by requestors. RRD ``Recursion really desired'' flag. Notable only when a request is processed by an intermediate name server (``forwarder'') who is not authoritative for the zone containing QNAME, and where QTYPE=ANY or QDCOUNT>1. If set in a request, the intermediate name server can only answer using unexpired cached answers (either positive or negative) which were atomically acquired using (a) the same QTYPE or set of QTYPEs present in the current question and whose TTLs were each minimized to the smallest among them when first cached, and (b) the same FM and LM settings present in the current question. LM ``Longest match'' flag. If this flag is present in a query message, then for any question whose QNAME is not fully matched by zone or cache data, the longest trailing label-bounded suffix of the QNAME for which zone or cache data is present will be eligible for use as an answer. Note that an intervening wildcard name shall supercede this behaviour and the rules described in [RFC1034 4.3.2, 4.3.3] shall apply, except that the owner name of the answer will be the wildcard name rather than the QNAME. Any of: QTYPE=ANY, or QCLASS=ANY, or QCOUNT>1, shall be considered an error if the LM flag is set. If LM is set in a request, then LM has meaning in the response as follows: If the content of the response would have been different without the LM flag being set on the request, then the response LM will be set; If the content of the response was not determined or affected by the request LM, then the response LM will be cleared. If the request LM was not set, then the response LM is not meaningful and should be set to zero by responders and ignored by requestors. Z Set to zero by senders and ignored by receivers, unless modified in a subsequent specification. Expires December 1999 [Page 4] INTERNET-DRAFT EDNS1 June 1999 5 - Multiple Questions for QUERY 5.1. If QDCOUNT>1, multiple questions are present. All questions must be for the same QNAME and QCLASS; only the QTYPE is allowed to vary. It is an error for QDCOUNT>1 and any QTYPE=ANY or QCLASS=ANY. 5.2. RCODE and AA apply to all RRs in the answer section having the QNAME that is shared by all questions in the question section. AA applies to all matching answers, and will not be set unless the exact original request was processed by an authoritative server and the response forwarded in its entirety. 5.3. If a multiple question request is processed by an intermediate server and the authority server does not support multiple questions, the intermediate server must generate an answer iteratively by making multiple requests of the authority server. In this case, AA must never be set in the final answer due to lack of atomicity of the contributing authoritative responses. 5.4. If iteratively processing a multiple question request using an authority server which can only process single question requests, if any contributing request generates a SERVFAIL response, then the final response's RCODE should be SERVFAIL. 6 - Acknowledgements Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley, Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, Michael Patton, and Michael Graff were each instrumental in creating this specification. 7 - References [RFC1035] P. Mockapetris, ``Domain Names - Implementation and Specification,'' RFC 1035, USC/Information Sciences Institute, November 1987. [EDNS0] P. Vixie, ``Extension mechanisms for DNS (EDNS0),'' Draft draft-ietf-dnsind-edns0-XX, IETF DNSIND, September 1998 [CRAW98] M. Crawford, ``Binary Labels in the Domain Name System,'' Draft draft-ietf-dnsind-binary-labels-XX, IETF DNSIND, March 1998. [KOCH98] P. Koch, ``A New Scheme for the Compression of Domain Names,'' Draft draft-ietf-dnsind-local-compression-XX.txt. Expires December 1999 [Page 5] INTERNET-DRAFT EDNS1 June 1999 IETF DNSIND, March 1998. 8 - Author's Address Paul Vixie Internet Software Consortium 950 Charter Street Redwood City, CA 94063 +1 650 779 7001 Expires December 1999 [Page 6] to unsubscribe send a message to 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 Oct 10 02:03:12 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27004 for ; Wed, 10 Oct 2001 02:03:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15rCC8-000DFb-00 for namedroppers-data@psg.com; Tue, 09 Oct 2001 22:46:16 -0700 Received: from mpfg.attlabs.net ([12.106.35.2] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15rCC8-000DFV-00 for namedroppers@ops.ietf.org; Tue, 09 Oct 2001 22:46:16 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15rCC6-0001Cq-00 for namedroppers@ops.ietf.org; Tue, 09 Oct 2001 22:46:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3BC3AE2A.30095FEF@daimlerchrysler.com> Date: Tue, 09 Oct 2001 22:10:50 -0400 From: Kevin Darcy To: namedroppers Subject: Re: wg last call for draft-ietf-dnsext-unknown-rrs-01.txt References: <20010926111745.A10616@outpost.ds9a.nl> <200109261904.MAA03755@gulag.araneus.fi> <3BB23A32.4FB62E0D@daimlerchrysler.com> <200109262147.OAA03864@gulag.araneus.fi> <3BB251E7.E77BE8AB@daimlerchrysler.com> <200109271742.KAA04466@gulag.araneus.fi> <3BB3A0A7.3B63FB1B@daimlerchrysler.com> <200109281744.KAA05226@gulag.araneus.fi> <3BB4E766.11981711@daimlerchrysler.com> <200109282314.QAA05401@gulag.araneus.fi> <3BB52A7D.5C859040@daimlerchrysler.com> <200110051935.MAA04318@gulag.araneus.fi> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit gson@isc.org wrote: > Kevin Darcy writes: > > EDNS0 undercuts the rationale for prohibiting compression in new record types, > > because it provides a "safe", point-to-point way to compress records of those > > types. Agreed, that's not technically the same as "obsoleting" the > > prohibition, but it does raise a significant likelihood that exceptions will > > become necessary. > > It doesn't raise the likelihood that exceptions are necessary, it > just makes it easier to implement such exceptions if they turn out to > be necessary. This is getting a little convoluted. The bottom line is that EDNS0 makes it *possible* to implement compression safely in new types. If your rationale for forbidding name compression in new types is that it is invariably unsafe, then to put it bluntly, that is a false rationale, given EDNS0. So, either the prohibition is a raw edict with no legitimate rationale, or you make an exception to the prohibition so that the rationale holds true. Your choice. > > I think there should at least be some language in the > > document acknowledging this fact, because -- let's face it -- you're not just > > "documenting" an existing prohibition, you're *reinforcing* it. > > And reinforced it should be. If we leave an explicit loophole for > negotiated compression schemes, people will come up with them whether > they are truly necessary or not. I don't think it's appropriate for the draft to be making broad assumptions about what future extensions may be "necessary" or not. It should be clarifying/standardizing/documenting how unknown RRs are handled, and leaving the specifics of how *known* RRs are implemented, up to those who are proposing them, without imposing unnecessary burdens on them to explicitly override your document in this regard. > > It wouldn't necessarily be a manual operation, and it wouldn't necessarily be > > burdensome. If the new record type has only a specialized use, then perhaps > > implementations will default it OFF and only those administrators who go out > > of their way to do so -- presumably with a full understanding of their local > > network/DNS environment and/or the tradeoffs of using the new record type -- > > will turn it ON. > > All that just to save a couple of bytes? It's just not worth the effort. 1. By the same reasoning, why bother with compression at all? 2. Who is to say it is only "a couple of bytes"? If a future record type were adopted, with literally dozens of names in its RDATA, ripe for compression, would that change your answer? We have to look not at just the format of extant record types, but at the *possible* formats of record types yet to be conceived. Compression is a tool -- albeit a fairly crude one -- for dealing with the packet-space impact of resource records, and it may save a little space, or a lot, depending on the record format and how many resource records are being compressed in a given packet. To deny the use of that tool based on a fuzzy prediction of what record formats may or may not be adopted in the future, strikes me as rather short-sighted. We should leave that tool available for situations where it may come in useful and can be employed in a safe, interoperable way. - 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 Oct 10 02:05:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29673 for ; Wed, 10 Oct 2001 02:05:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15rCHr-000DlK-00 for namedroppers-data@psg.com; Tue, 09 Oct 2001 22:52:11 -0700 Received: from mpfg.attlabs.net ([12.106.35.2] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15rCHq-000Dks-00 for namedroppers@ops.ietf.org; Tue, 09 Oct 2001 22:52:10 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15rCHp-0001D9-00 for namedroppers@ops.ietf.org; Tue, 09 Oct 2001 22:52:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Paul A Vixie cc: namedroppers@ops.ietf.org Subject: Re: EDNS1 In-Reply-To: <200110091619.f99GJbH36924@as.vix.com> References: <200110091619.f99GJbH36924@as.vix.com> Date: Wed, 10 Oct 2001 11:48:07 +0700 Message-ID: <1297.1002689287@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Tue, 09 Oct 2001 09:19:37 -0700 From: Paul A Vixie Message-ID: <200110091619.f99GJbH36924@as.vix.com> | 2 - Affected Protocol Elements I'd like to see ... 2.4. Only a subset of DNS RR types support compression of labels in the RDATA, as explained in [...whatever that new draft is...]. Where it is known that the requestor, and the server, both recognise other RR types, and so can locate labels in the RDATA, and decompress them, name compression can be permitted in the RDATA of additional RR types. added, and then: | 4 - OPT pseudo-RR Flags and Options 4.1. The extended RCODE and flags | are structured as follows: | | +0 (MSB) +1 (LSB) | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 0: | EXTENDED-RCODE | VERSION | | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 2: |MD |FM |RRD|LM |XC | Z | | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | XC If set to 1 by the sender, then the sender understands label compression in the extended set of RR types as defined for the VERSION specified. If set to 1 in a response, the server indicates that it is able to compress labels for the extended set of RR types as defined for the VERSION specified. Any label compression scheme defined by the DNS for the EDNS VERSION agreed between sender and responder may be used. and then add a new section (6) below (and renumber those that were 6, 7, 8 into 7, 8, 9, of course) 6. Extended Label Compression RDATA RR types Any DNS system that supports extended compression (sets the XC bit in the OPT RR) and supports EDNS version 1, must support label compression in all domain names included in the RDATA of the followingRR types, as well as all of those defined by RFC1035. NXT (rfc2535) SRV (rfc2782) A6 (rfc2874) TKEY (rfc2930) NAPTR (rfc2915) TSIG (rfc2845) DNAME (rfc2672) KX (rfc2230) PX (rfc2163) AFSDB (rfc1183) RP (rfc1183) (OK, including the algorithm "domain name" from TKEY and TSIG might be going a bit overboard, deleting those from this list wouldn't harm a lot I don't think). If I missed any that should be added, then add them... (if any of those I found are so obsolete that no-one will ever use them, then we should drop them from the list, so as to avoid requiring people to support rubbish). I know NXT allows compression anyway, according to 2535 anyway, though I'm not sure that is really appropriate ... it is intended to only be used between servers that understand it, but I'm not sure how that is actually enforced. In any case, explicitly specifying it to be OK for EDNS1 can't hurt. (continuing the above section to be inserted...) A DNS server capable of compressing the domain labels in the RDATA of all of the RR types listed above (plus all of the RR types defined to support compression in rfc1035) MAY set the XC bit in the OPT RR in responses it sends that include that RR, where the version indicated as supported is 1. If support for a higher version number is available, the XC bit MUST NOT be set in responses unless any additional RRs defined for that EDNS version are also supported. In any case, a server MUST NOT compress labels for any of the above RR types, unless it is responding to a query received containing an OPT RR with the XC bit set, and a version of at least 1. When responding to a query wich was received with the XC bit set in an included OPT RR which has a version of 1 or greater, the server MAY compress labels in the above RR formats using any compression scheme available to be used in the EDNS version applicable. Domain names in the RDATA field of RR types not listed here, or in rfc1035, or in the specification of some later EDNS version agreed between sender and server, MUST NOT be compressed. Aside from that, I'd fix ... | 5.4. If iteratively processing a multiple question request using an | authority server which can only process single question requests, if any | contributing request generates a SERVFAIL response, then the final | response's RCODE should be SERVFAIL. to be 5.4. If iteratively processing a multiple question request using an authority server which can only process single question requests, if any contributing request generates only a SERVFAIL response, then the final response's RCODE should be SERVFAIL. That is, if there are 2 auth servers listed for a QNAME, the intermediate server tries one, and gets SERVFAIL, but then tries the other, and gets all the answers it needs, it shouldn't be setting SERVFAIL in the response, only if it is unable to get an answer to one of the questions from any of the auth servers for the QNAME (that it chooses to try). | 7 - References Most of the ones in this list that were drafts are RFCs now... except ... | [KOCH98] P. Koch, ``A New Scheme for the Compression of Domain | Names,'' Draft draft-ietf-dnsind-local-compression-XX.txt. which seems to have vanished completely. If it isn't coming back, the reference, and the label code tentatively allocated for it, need to go as well. 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 Oct 10 15:53:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19583 for ; Wed, 10 Oct 2001 15:53:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15rP2V-000NO8-00 for namedroppers-data@psg.com; Wed, 10 Oct 2001 12:29:11 -0700 Received: from ip-216-73-191-29.hqglobal.net ([216.73.191.29] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15rP2U-000NO2-00 for namedroppers@ops.ietf.org; Wed, 10 Oct 2001 12:29:10 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15rP2Y-0000KN-00 for namedroppers@ops.ietf.org; Wed, 10 Oct 2001 12:29:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 10 Oct 2001 10:38:32 -0400 (EDT) From: Olafur Gudmundsson To: Kevin Darcy cc: namedroppers Subject: Re: wg last call for draft-ietf-dnsext-unknown-rrs-01.txt In-Reply-To: <3BC3AE2A.30095FEF@daimlerchrysler.com> Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 9 Oct 2001, Kevin Darcy wrote: > gson@isc.org wrote: > > > Kevin Darcy writes: > > > EDNS0 undercuts the rationale for prohibiting compression in new record types, > > > because it provides a "safe", point-to-point way to compress records of those > > > types. Agreed, that's not technically the same as "obsoleting" the > > > prohibition, but it does raise a significant likelihood that exceptions will > > > become necessary. > > > > It doesn't raise the likelihood that exceptions are necessary, it > > just makes it easier to implement such exceptions if they turn out to > > be necessary. > > This is getting a little convoluted. The bottom line is that EDNS0 makes it > *possible* to implement compression safely in new types. If your rationale for > forbidding name compression in new types is that it is invariably unsafe, then to > put it bluntly, that is a false rationale, given EDNS0. So, either the prohibition > is a raw edict with no legitimate rationale, or you make an exception to the > prohibition so that the rationale holds true. Your choice. DNS Compression is evil, adding compression to new types is a real bad idea. (I speak from personal experiance of implementing new types allowing compression and test deployment). We need a blanket ban on compression of RDATA of new types. This is the only safe thing to do, as it improves the chances that a new type can pass through a server that does not know the format of that type. We need to learn from experience, even if a standards document says something is possible we must be able restrict that based on experience. Remember RFC1034 and RFC1035 did not go through the 3 stage standards process, but the one step to full standard. The time it takes to upgrade DNS servers is measured in many years. First we need to wait the next release of the DNS software (0-12 months), then we wait for the OS vendors to add this to their release (6-24 months) then customers install (0-36 months), then wait for the computer to die or be upgraded (0-120 months). For the most recently defined type (APL) we will probably have to wait for 16 years before over 99% of the DNS servers on the Internet know APL. > > > > I think there should at least be some language in the > > > document acknowledging this fact, because -- let's face it -- you're not just > > > "documenting" an existing prohibition, you're *reinforcing* it. > > > > And reinforced it should be. If we leave an explicit loophole for > > negotiated compression schemes, people will come up with them whether > > they are truly necessary or not. > > I don't think it's appropriate for the draft to be making broad assumptions about > what future extensions may be "necessary" or not. It should be > clarifying/standardizing/documenting how unknown RRs are handled, and leaving the > specifics of how *known* RRs are implemented, up to those who are proposing them, > without imposing unnecessary burdens on them to explicitly override your document > in this regard. It it quite appropriate (see below). > > > > It wouldn't necessarily be a manual operation, and it wouldn't necessarily be > > > burdensome. If the new record type has only a specialized use, then perhaps > > > implementations will default it OFF and only those administrators who go out > > > of their way to do so -- presumably with a full understanding of their local > > > network/DNS environment and/or the tradeoffs of using the new record type -- > > > will turn it ON. > > > > All that just to save a couple of bytes? It's just not worth the effort. > > 1. By the same reasoning, why bother with compression at all? Historical background: DNS was designed in the middle 80's, at that time general purpose compression was advancing rapidly, but it was not clear what compression would work well on DNS packets and general purpose compression was real expensive. Network bandwidth was limited and reassembly was not reliable, thus requiring some compression made sense. The choice of name compression was a reasonable one, it looks inexpensive and has no complicated binary encodings, but keeping track of compression pointers and ordering them is more complicated than it seems. Further the code dealing with compression is interspersed all through the RR type processing. A better choice would have been to make the RRset the main DNS wire envelope rather than the RR, something like [ ]+ Requires a 1 extra byes for RRset structure, but for each additional RR there is a 2 byte header instead of 12 byte one (assuming full compression) at much lower cost in computation. Today the choice could simply be that a header bit signals that the remainder of the message is compressed (with zlib). In this case the transmitting server can make the choice AFTER the message is assembled and only apply compression when it is beneficial and resources are available. Further benefit is that all new types are covered without any extra complexity. But we do not have the luxury at this time to change the protocol in this radical way, instead making the protocol more reliable is more important than possibly saving few bytes from some hyperthetical future RR type. > > 2. Who is to say it is only "a couple of bytes"? If a future record type were > adopted, with literally dozens of names in its RDATA, ripe for compression, would > that change your answer? We have to look not at just the format of extant record > types, but at the *possible* formats of record types yet to be conceived. > Compression is a tool -- albeit a fairly crude one -- for dealing with the > packet-space impact of resource records, and it may save a little space, or a lot, > depending on the record format and how many resource records are being compressed > in a given packet. To deny the use of that tool based on a fuzzy prediction of what > record formats may or may not be adopted in the future, strikes me as rather > short-sighted. We should leave that tool available for situations where it may come > in useful and can be employed in a safe, inter-operable way. > Such a type is a bad idea and I do not think a type like this will ever get passed the working group and/or IESG. DNS main role is to hand out small chucks of data and provide pointers to data stores containing the larger chucks. 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 Thu Oct 11 01:49:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00361 for ; Thu, 11 Oct 2001 01:49:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15rYPM-000N2n-00 for namedroppers-data@psg.com; Wed, 10 Oct 2001 22:29:24 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15rYPM-000N2b-00 for namedroppers@ops.ietf.org; Wed, 10 Oct 2001 22:29:24 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15rYPM-000CTn-00 for namedroppers@ops.ietf.org; Wed, 10 Oct 2001 22:29:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3BC4FA5F.4CCA35C@daimlerchrysler.com> Date: Wed, 10 Oct 2001 21:48:15 -0400 From: Kevin Darcy To: namedroppers Subject: Re: wg last call for draft-ietf-dnsext-unknown-rrs-01.txt References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Olafur Gudmundsson wrote: > On Tue, 9 Oct 2001, Kevin Darcy wrote: > > > gson@isc.org wrote: > > > > > Kevin Darcy writes: > > > > EDNS0 undercuts the rationale for prohibiting compression in new record types, > > > > because it provides a "safe", point-to-point way to compress records of those > > > > types. Agreed, that's not technically the same as "obsoleting" the > > > > prohibition, but it does raise a significant likelihood that exceptions will > > > > become necessary. > > > > > > It doesn't raise the likelihood that exceptions are necessary, it > > > just makes it easier to implement such exceptions if they turn out to > > > be necessary. > > > > This is getting a little convoluted. The bottom line is that EDNS0 makes it > > *possible* to implement compression safely in new types. If your rationale for > > forbidding name compression in new types is that it is invariably unsafe, then to > > put it bluntly, that is a false rationale, given EDNS0. So, either the prohibition > > is a raw edict with no legitimate rationale, or you make an exception to the > > prohibition so that the rationale holds true. Your choice. > > > DNS Compression is evil, adding compression to new types is a > real bad idea. (I speak from personal experiance of implementing new types > allowing compression and test deployment). > We need a blanket ban on compression of RDATA of new types. > This is the only safe thing to do, as it improves the chances that a new > type can pass through a server that does not know the format of that type. > > > We need to learn from experience, even if a standards document says > something is possible we must be able restrict that based on experience. > Remember RFC1034 and RFC1035 did not go through the 3 stage standards > process, but the one step to full standard. > > The time it takes to upgrade DNS servers is measured in many years. > First we need to wait the next release of the DNS software (0-12 > months), then we wait for the OS vendors to add this to their release > (6-24 months) then customers install (0-36 months), then wait for > the computer to die or be upgraded (0-120 months). > > For the most recently defined type (APL) we will probably have to wait > for 16 years before over 99% of the DNS servers on the Internet know APL. > > > > > > > I think there should at least be some language in the > > > > document acknowledging this fact, because -- let's face it -- you're not just > > > > "documenting" an existing prohibition, you're *reinforcing* it. > > > > > > And reinforced it should be. If we leave an explicit loophole for > > > negotiated compression schemes, people will come up with them whether > > > they are truly necessary or not. > > > > I don't think it's appropriate for the draft to be making broad assumptions about > > what future extensions may be "necessary" or not. It should be > > clarifying/standardizing/documenting how unknown RRs are handled, and leaving the > > specifics of how *known* RRs are implemented, up to those who are proposing them, > > without imposing unnecessary burdens on them to explicitly override your document > > in this regard. > > It it quite appropriate (see below). > > > > > > > It wouldn't necessarily be a manual operation, and it wouldn't necessarily be > > > > burdensome. If the new record type has only a specialized use, then perhaps > > > > implementations will default it OFF and only those administrators who go out > > > > of their way to do so -- presumably with a full understanding of their local > > > > network/DNS environment and/or the tradeoffs of using the new record type -- > > > > will turn it ON. > > > > > > All that just to save a couple of bytes? It's just not worth the effort. > > > > 1. By the same reasoning, why bother with compression at all? > > Historical background: DNS was designed in the middle 80's, at that > time general purpose compression was advancing rapidly, but it was not > clear what compression would work well on DNS packets and general purpose > compression was real expensive. Network bandwidth was limited and > reassembly was not reliable, thus requiring some compression made sense. > The choice of name compression was a reasonable one, it looks inexpensive > and has no complicated binary encodings, but keeping track of compression > pointers and ordering them is more complicated than it seems. Further the > code dealing with compression is interspersed all through the RR type > processing. > > A better choice would have been to make the RRset the main DNS > wire envelope rather than the RR, something like > [ ]+ > Requires a 1 extra byes for RRset structure, but for each additional > RR there is a 2 byte header instead of 12 byte one (assuming full > compression) at much lower cost in computation. > > Today the choice could simply be that a header bit signals that > the remainder of the message is compressed (with zlib). In this case > the transmitting server can make the choice AFTER the message is > assembled and only apply compression when it is beneficial and > resources are available. Further benefit is that all new types > are covered without any extra complexity. > > But we do not have the luxury at this time to change the protocol in > this radical way, instead making the protocol more reliable > is more important than possibly saving few bytes from some > hyperthetical future RR type. Well, I would have to agree that, in hindsight, the record-format-dependent compression scheme of DNS is rather old-fashioned and awful. Something more flexible and effective should replace it. But I'm still not convinced that "forbid it now, relax the ban later if appropriate" is the right tack to take with respect to *safe* implementations of compression in new types, e.g. through EDNS OPTIONs or whatever. I'd still like to see some sort of limitation or exception in the prohibition, but if that's not the concensus of the WG, then so be it. By the way, I'm totally in agreement that RRsets should have been the main DNS wire envelope from the very beginning. Not only that, but there should have been an "options" section or something similar, to allow for future extensibility, e.g. new compression schemes or the use of new record types, without all of this pain. Isn't hindsight wonderful? > > 2. Who is to say it is only "a couple of bytes"? If a future record type were > > adopted, with literally dozens of names in its RDATA, ripe for compression, would > > that change your answer? We have to look not at just the format of extant record > > types, but at the *possible* formats of record types yet to be conceived. > > Compression is a tool -- albeit a fairly crude one -- for dealing with the > > packet-space impact of resource records, and it may save a little space, or a lot, > > depending on the record format and how many resource records are being compressed > > in a given packet. To deny the use of that tool based on a fuzzy prediction of what > > record formats may or may not be adopted in the future, strikes me as rather > > short-sighted. We should leave that tool available for situations where it may come > > in useful and can be employed in a safe, inter-operable way. > > > > Such a type is a bad idea and I do not think a type like this will ever > get passed the working group and/or IESG. > > DNS main role is to hand out small chucks of data and provide pointers to > data stores containing the larger chucks. As a general rule, I agree. But who knows what the future may bring? Maybe the benefit of such large RRs might be perceived to outweigh the costs. After all, did anyone in the RFC 1034/1035 era think that we'd ever be comfortable routinely slinging around RRs the size of SIGs? - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Oct 11 13:16:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20251 for ; Thu, 11 Oct 2001 13:16:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15rj0m-0002rJ-00 for namedroppers-data@psg.com; Thu, 11 Oct 2001 09:48:44 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15rj0m-0002rD-00 for namedroppers@ops.ietf.org; Thu, 11 Oct 2001 09:48:44 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15rj0m-0009Li-00 for namedroppers@ops.ietf.org; Thu, 11 Oct 2001 09:48:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: namedroppers@ops.ietf.org Subject: Re: EDNS1 References: <200110091619.f99GJbH36924@as.vix.com> <1297.1002689287@brandenburg.cs.mu.OZ.AU> From: Paul Vixie Date: 11 Oct 2001 09:48:23 -0700 In-Reply-To: Robert Elz's message of "9 Oct 2001 22:59:38 -0700" Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit so far in response to my reposting of the 1999 EDNS1 draft i've seen: 1. several requests to kill it 2. one statement (from a WG cochair) indicating that it was already dead, was nonrevivable, and that DNS-NG was the next great thing 3. one request to attach a rider based on the current compression debate every feature in the 1999 draft was topical at the time it was released, but may be less so now. if we've moved on and don't need any of that stuff then there's no reason to revive it. unless someone publically indicates support for any of the features described in the 1999 EDNS1 draft, i'm going to move it to historic, i.e., kill it. the thing that would surprise me is if noone in the IPv6 arena wanted to be able to ask multiple questions in the same query, for AAAA and A. (if A6 dies, then QDCOUNT>1 would be a performance win for an AAAA world.) to unsubscribe send a message to 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 Oct 11 18:19:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27255 for ; Thu, 11 Oct 2001 18:19:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15rnhK-000HEq-00 for namedroppers-data@psg.com; Thu, 11 Oct 2001 14:48:58 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15rnhK-000HEk-00 for namedroppers@ops.ietf.org; Thu, 11 Oct 2001 14:48:58 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15rnhK-000ICx-00 for namedroppers@ops.ietf.org; Thu, 11 Oct 2001 14:48:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200110112142.RAA26244@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: namedroppers@ops.ietf.org From: The IESG Subject: Protocol Action: DNS Server MIB Extensions to Historic Standard Date: Thu, 11 Oct 2001 17:42:04 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The IESG has approved reclassifying the following RFCs as Historic documents: RFC1611 DNS Server MIB Extensions RFC1612 DNS Resolver MIB Extensions In the same action, the IESG approved publication of Applicability Statement for DNS MIB Extensions as an Informational RFC. This document is the product of the DNS Extensions Working Group. The contact persons are Erik Nordmark and Thomas Narten. Technical Summary The document states the reasons for moving RFC 1611 and RFC 1612 to historical: More than six years after the DNS Server and Resolver MIB extensions became proposed standards, there still has not been any significant deployment of these MIB extensions. This note examines the reasons why these MIB extensions were never deployed, and recommends retiring these MIB extensions by moving them to Historical status. Working Group Summary There was consensus in the working group to reclassify the DNS MIB documents. Interested parties where encouraged to form a design team to produce more usable MIBs for DNS and bring them to the DNSEXT WG when they are ready for review. Protocol Quality This document has been reviewed for the IESG by Erik Nordmark. Note to RFC Editor: Please replace the Security Considerations section in draft-ietf-dnsext-dnsmib-historical-00.txt with the following text: Re-classifying an existing MIB document from Proposed Std to Historic does not have any negative impact on security for the Internet. to unsubscribe send a message to 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 Oct 11 21:33:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00363 for ; Thu, 11 Oct 2001 21:33:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15rqzk-000Ohe-00 for namedroppers-data@psg.com; Thu, 11 Oct 2001 18:20:12 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15rqzj-000OhY-00 for namedroppers@ops.ietf.org; Thu, 11 Oct 2001 18:20:11 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15rqzj-000OIz-00 for namedroppers@ops.ietf.org; Thu, 11 Oct 2001 18:20:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: namedroppers Subject: Re: draft-ietf-dnsext-dhcid-rr-03.txt References: Message-Id: Date: Thu, 11 Oct 2001 18:17:06 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Date: Wed, 26 Sep 2001 11:56:35 -0700 > this starts a two week wg last call on draft-ietf-dnsext-dhcid-rr-03.txt > for proposed standard. the wg last call has ended. there seems to have been zero comment on this draft. unless i hear to the contrary, i will assume that no one is sufficiently interssted in adding yarr, and we can let it die. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Oct 11 21:37:50 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01389 for ; Thu, 11 Oct 2001 21:37:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15rqxu-000Ocx-00 for namedroppers-data@psg.com; Thu, 11 Oct 2001 18:18:18 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15rqxu-000Ocr-00 for namedroppers@ops.ietf.org; Thu, 11 Oct 2001 18:18:18 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15rqxu-000OFv-00 for namedroppers@ops.ietf.org; Thu, 11 Oct 2001 18:18:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: namedroppers Subject: Re: wg last call for draft-ietf-dnsext-unknown-rrs-01.txt References: Message-Id: Date: Thu, 11 Oct 2001 18:13:16 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Date: Tue, 25 Sep 2001 22:12:00 -0700 > two week last call starts for draft-ietf-dnsext-unknown-rrs-01.txt for > proposed standard. the last call has ended. there has been much discussion of this draft. see the thread off http://psg.com/lists/namedroppers/namedroppers.2001/msg01066.html my read is that there is NOT rough consensus. please feel free to disabuse me of that notion. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Oct 12 13:01:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03507 for ; Fri, 12 Oct 2001 13:01:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15s5J0-0004dW-00 for namedroppers-data@psg.com; Fri, 12 Oct 2001 09:37:02 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15s5Iz-0004dQ-00 for namedroppers@ops.ietf.org; Fri, 12 Oct 2001 09:37:01 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15s5Iz-000NZC-00 for namedroppers@ops.ietf.org; Fri, 12 Oct 2001 09:37:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.2.7.2.20011012091725.01ad4a60@funnel.cisco.com> Date: Fri, 12 Oct 2001 09:32:56 -0400 To: Randy Bush From: Mark Stapp Subject: Re: draft-ietf-dnsext-dhcid-rr-03.txt Cc: namedroppers , dhcwg@ietf.org In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I wonder whether the lack of objections to this draft might be interpreted another way. The rr is designed for use in networks where dhcp servers and clients are updating A and PTR rrs as dhcp protocol interactions take place. Since the dhcid rr doesn't have any special dns protocol semantic significance, it doesn't raise any contentious issues for the dns server community. It's not surprising, then, if the dns community doesn't have much objection to the new rr. The dhcp community has a dependency on this specification, however, and the use of this rr does have significance for us. Perhaps I've misunderstood the point of the wg last call: I thought it was a way of soliciting suggestions and complaints. I didn't realize that if no one objected, that the draft would die. That doesn't quite make sense to me, actually. In any case, I'm cross-posting this to the dhc working group list in the hope that some of that group's participants will express some support for this dnsext draft. If it dies, however quietly, the dhc group will have to start designing dhcp-dns interaction specifications from scratch. -- Mark At 06:17 PM 10/11/2001 -0700, Randy Bush wrote: > > Date: Wed, 26 Sep 2001 11:56:35 -0700 > > this starts a two week wg last call on draft-ietf-dnsext-dhcid-rr-03.txt > > for proposed standard. > >the wg last call has ended. there seems to have been zero comment on >this draft. unless i hear to the contrary, i will assume that no one >is sufficiently interssted in adding yarr, and we can let it die. > >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. to unsubscribe send a message to 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 Oct 12 13:02:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03527 for ; Fri, 12 Oct 2001 13:02:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15s5Ol-0004qY-00 for namedroppers-data@psg.com; Fri, 12 Oct 2001 09:42:59 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15s5Ok-0004qS-00 for namedroppers@ops.ietf.org; Fri, 12 Oct 2001 09:42:58 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15s5Ok-000Nj0-00 for namedroppers@ops.ietf.org; Fri, 12 Oct 2001 09:42:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <006c01c1532f$29984d60$b9370681@antd.nist.gov> From: "Scott Rose" To: "DNSEXT WG Mailing list" Subject: DNSSEC and backward compatiblity Date: Fri, 12 Oct 2001 11:04:16 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I've noticed the slow down on discussion of backwards compatiblity within DNSSEC, or optionally: How to best state a child's security status in a delegation. First question: what are all the options we want to have the child state? The next one: How best to do that: A new RR, or a flag field in the DS record (assuming there is one)? or EDNS variables in the OPT record? Just trying to get a debate going Scott to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Oct 12 13:04:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03627 for ; Fri, 12 Oct 2001 13:04:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15s5NZ-0004nC-00 for namedroppers-data@psg.com; Fri, 12 Oct 2001 09:41:45 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15s5NZ-0004n4-00 for namedroppers@ops.ietf.org; Fri, 12 Oct 2001 09:41:45 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15s5NZ-000Ngw-00 for namedroppers@ops.ietf.org; Fri, 12 Oct 2001 09:41:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 12 Oct 2001 10:41:24 -0400 Subject: Re: draft-ietf-dnsext-dhcid-rr-03.txt From: Ted Lemon To: namedroppers In-Reply-To: <5.0.2.1.2.20011011183727.02f0eb28@localhost> Message-Id: <35B58F06-BF1F-11D5-B823-00039317663C@fugue.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > the wg last call has ended. there seems to have been zero comment on > this draft. unless i hear to the contrary, i will assume that no one > is sufficiently interssted in adding yarr, and we can let it die. We absolutely need the dhcid rr. We have been trying to get this draft to happen for several years now, and there have been repeated efforts to kill it. This is the silliest one yet - "the draft isn't controversial, so that must mean nobody wants it." Randy, please send this draft along. This isn't funny. _MelloN_ to unsubscribe send a message to 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 Oct 12 13:30:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04471 for ; Fri, 12 Oct 2001 13:30:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15s5iV-0005iM-00 for namedroppers-data@psg.com; Fri, 12 Oct 2001 10:03:23 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15s5iV-0005iG-00 for namedroppers@ops.ietf.org; Fri, 12 Oct 2001 10:03:23 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15s5iV-000OGP-00 for namedroppers@ops.ietf.org; Fri, 12 Oct 2001 10:03:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Mark Stapp Cc: namedroppers , dhcwg@ietf.org Subject: Re: draft-ietf-dnsext-dhcid-rr-03.txt References: <4.3.2.7.2.20011012091725.01ad4a60@funnel.cisco.com> Message-Id: Date: Fri, 12 Oct 2001 10:03:09 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit if folk want it, they should speak up. we don't need a hoard. just a few folk to say "yes, we want this." randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Oct 12 13:42:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04734 for ; Fri, 12 Oct 2001 13:42:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15s5z9-0006Ri-00 for namedroppers-data@psg.com; Fri, 12 Oct 2001 10:20:35 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15s5z8-0006Rc-00 for namedroppers@ops.ietf.org; Fri, 12 Oct 2001 10:20:34 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15s5z8-000Oif-00 for namedroppers@ops.ietf.org; Fri, 12 Oct 2001 10:20:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.2.7.2.20011012125604.00b93750@funnel.cisco.com> Date: Fri, 12 Oct 2001 13:11:40 -0400 To: Randy Bush From: Ralph Droms Subject: Re: [dhcwg] Re: draft-ietf-dnsext-dhcid-rr-03.txt Cc: Mark Stapp , namedroppers , dhcwg@ietf.org In-Reply-To: <4.3.2.7.2.20011012091725.01ad4a60@funnel.cisco.com> References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I have no objections to draft-ietf-dnsext-dhcid-rr-03.txt and recommend that it be accepted by the WG for submission as a Proposed Standard. This new RR is crucial to the standard mechanism under review in the DHC WG to support the interaction of DHCP and DNS in dynamic updates to DNS. The DHCID RR is of specific interest to the DHCP community, so posting to the DHC WG mailing list is likely to reach the widest audience of interested persons. Randy, now that we know you're looking for positive responses as well comments, the DHC WG will be able to respond to indicate our interest in seeing this draft move forward. - Ralph At 09:32 AM 10/12/2001 -0400, Mark Stapp wrote: >I wonder whether the lack of objections to this draft might be interpreted >another way. The rr is designed for use in networks where dhcp servers and >clients are updating A and PTR rrs as dhcp protocol interactions take >place. Since the dhcid rr doesn't have any special dns protocol semantic >significance, it doesn't raise any contentious issues for the dns server >community. It's not surprising, then, if the dns community doesn't have >much objection to the new rr. > >The dhcp community has a dependency on this specification, however, and >the use of this rr does have significance for us. Perhaps I've >misunderstood the point of the wg last call: I thought it was a way of >soliciting suggestions and complaints. I didn't realize that if no one >objected, that the draft would die. That doesn't quite make sense to me, >actually. In any case, I'm cross-posting this to the dhc working group >list in the hope that some of that group's participants will express some >support for this dnsext draft. If it dies, however quietly, the dhc group >will have to start designing dhcp-dns interaction specifications from scratch. > >-- Mark > >At 06:17 PM 10/11/2001 -0700, Randy Bush wrote: >> > Date: Wed, 26 Sep 2001 11:56:35 -0700 >> > this starts a two week wg last call on draft-ietf-dnsext-dhcid-rr-03.txt >> > for proposed standard. >> >>the wg last call has ended. there seems to have been zero comment on >>this draft. unless i hear to the contrary, i will assume that no one >>is sufficiently interssted in adding yarr, and we can let it die. >> >>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. > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >http://www1.ietf.org/mailman/listinfo/dhcwg to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Oct 12 13:49:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04894 for ; Fri, 12 Oct 2001 13:49:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15s66B-0006jC-00 for namedroppers-data@psg.com; Fri, 12 Oct 2001 10:27:51 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15s66B-0006j5-00 for namedroppers@ops.ietf.org; Fri, 12 Oct 2001 10:27:51 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15s66B-000Oun-00 for namedroppers@ops.ietf.org; Fri, 12 Oct 2001 10:27:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 12 Oct 2001 13:25:27 -0400 Subject: Re: [dhcwg] Re: draft-ietf-dnsext-dhcid-rr-03.txt Cc: Mark Stapp , namedroppers , dhcwg@ietf.org To: Randy Bush From: Ted Lemon In-Reply-To: Message-Id: <20894808-BF36-11D5-B823-00039317663C@fugue.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > if folk want it, they should speak up. we don't need a hoard. just a > few folk to say "yes, we want this." Folk have flown to IETF in foreign countries specifically for the purpose of saying "yes, we want this." I have done it on several occasions. I know Mark has as well. That is why it was before the working group. You now have three people who have publically stated on namedroppers that they want it, all within a matter of minutes of you unexpectedly proposing to kill it. So please send it along. Thanks! _MelloN_ to unsubscribe send a message to 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 Oct 12 14:21:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05795 for ; Fri, 12 Oct 2001 14:21:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15s6fQ-0007lk-00 for namedroppers-data@psg.com; Fri, 12 Oct 2001 11:04:16 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15s6fP-0007le-00 for namedroppers@ops.ietf.org; Fri, 12 Oct 2001 11:04:15 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15s6fP-000Pt1-00 for namedroppers@ops.ietf.org; Fri, 12 Oct 2001 11:04:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "Barr Hibbs" To: "namedroppers" Cc: "Dhcwg" Subject: RE: draft-ietf-dnsext-dhcid-rr-03.txt Date: Fri, 12 Oct 2001 11:01:02 -0700 Message-ID: In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Randy Bush > Sent: Thursday, October 11, 2001 18:17 > the wg last call has ended. there seems to have been zero comment on > this draft. unless i hear to the contrary, i will assume that no one > is sufficiently interested in adding yarr, and we can let it die. > I don't see why "zero comment" is equivalent to "no one is sufficiently interested" but aside from that, this RR type is necessary for a DHCP server to dynamically update a DNS server on behalf of a client that has received an IP address lease from the DHCP server. Do not let this simply slip into oblivion. --Barr to unsubscribe send a message to 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 Oct 15 12:32:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04387 for ; Mon, 15 Oct 2001 12:32:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15tA2D-0003ha-00 for namedroppers-data@psg.com; Mon, 15 Oct 2001 08:52:09 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15tA2C-0003hU-00 for namedroppers@ops.ietf.org; Mon, 15 Oct 2001 08:52:08 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15tA2C-000Nzo-00 for namedroppers@ops.ietf.org; Mon, 15 Oct 2001 08:52:08 -0700 Message-Id: <200110151100.HAA23006@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-mdns-06.txt Date: Mon, 15 Oct 2001 07:00:19 -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 : Multicast DNS Author(s) : L. Esibov, B. Aboba, D. Thaler Filename : draft-ietf-dnsext-mdns-06.txt Pages : 18 Date : 12-Oct-01 Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a DNS server. In order to allow DNS name resolution in such environments, the use of a multicast DNS is proposed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-mdns-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-mdns-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011012150859.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011012150859.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Oct 15 19:09:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14984 for ; Mon, 15 Oct 2001 19:09:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15tGVS-000Af0-00 for namedroppers-data@psg.com; Mon, 15 Oct 2001 15:46:46 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15tGVR-000Aeu-00 for namedroppers@ops.ietf.org; Mon, 15 Oct 2001 15:46:45 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15tGVR-0009aY-00 for namedroppers@ops.ietf.org; Mon, 15 Oct 2001 15:46:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 15 Oct 2001 15:40:32 -0700 (PDT) Message-Id: <200110152240.PAA11260@gulag.araneus.fi> To: namedroppers Subject: Re: wg last call for draft-ietf-dnsext-unknown-rrs-01.txt In-Reply-To: References: From: gson@isc.org (Andreas Gustafsson) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Randy Bush writes: > my read is that there is NOT rough consensus. please feel free to disabuse > me of that notion. This is how I would summarize the discussion: Bert Hubert expressed worry about the lack of support for mandatory additional section processing, but still said it was a "very good proposal". Mark Gritter worried about the treatment of meta-RRs, which are outside the scope of the draft. Dan Bernstein opposed the draft for multiple reasons. Kevin Darcy opposed the unconditional prohibition of compression in new types and asked that the draft specifically allow for compression when negotiated using some future mechanism (e.g., based on EDNS). The author, Roy Arends, Mark Andrews, Robert Elz, and Olafur Gudmundsson defended the current text of the draft. Of these, I view only Dan's and Kevin's messages as significant opposition to the draft. Interestingly, these two cases of opposition represent almost diametrically opposed viewpoints: Dan is saying that the draft is unnecessary because there already is an absolute prohibition on compression in new types and that the draft is too loose, while Kevin is effectively saying that the draft is harmful because the existing prohibition on compression is not absolute, and that the draft is too strict. To me this suggests that the draft actually is a reasonably compromise consistent with the views of the majority of the working group. I'd like to ask all those who have an opinion either for or against the draft and who have not yet expressed it on the list to please speak up. -- Andreas Gustafsson, gson@isc.org to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Oct 15 19:55:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15703 for ; Mon, 15 Oct 2001 19:55:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15tHRR-000Bgu-00 for namedroppers-data@psg.com; Mon, 15 Oct 2001 16:46:41 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15tHRR-000Bgo-00 for namedroppers@ops.ietf.org; Mon, 15 Oct 2001 16:46:41 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15tHRR-000BDQ-00 for namedroppers@ops.ietf.org; Mon, 15 Oct 2001 16:46:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 15 Oct 2001 16:44:53 -0700 From: Mark Gritter To: namedroppers@ops.ietf.org Subject: Re: wg last call for draft-ietf-dnsext-unknown-rrs-01.txt Message-ID: <20011015164452.A14155@Xenon.Stanford.EDU> References: <200110152240.PAA11260@gulag.araneus.fi> In-Reply-To: <200110152240.PAA11260@gulag.araneus.fi>; from gson@isc.org on Mon, Oct 15, 2001 at 03:40:32PM -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit While I still feel that meta-RRs need to be addressed, I accept Andreas' argument that they are out of the scope of the draft (particularly since they are likely to be contentious, and I _am_ very interested in getting something done in this area as soon as possible.) So, I support the draft going forward in its current form; I agree that the proposal is the correct way to handle individual RRs. Mark Gritter On Mon, Oct 15, 2001 at 03:40:32PM -0700, Andreas Gustafsson wrote: > Randy Bush writes: > > my read is that there is NOT rough consensus. please feel free to disabuse > > me of that notion. > > This is how I would summarize the discussion: > > Bert Hubert expressed worry about the lack of support for mandatory > additional section processing, but still said it was a "very good > proposal". > > Mark Gritter worried about the treatment of meta-RRs, which are > outside the scope of the draft. > [snip] > -- > Andreas Gustafsson, gson@isc.org > > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. -- Mark Gritter http://www-cs-students.stanford.edu/~mgritter/ to unsubscribe send a message to 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 Oct 15 20:04:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15868 for ; Mon, 15 Oct 2001 20:04:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15tHVm-000BnC-00 for namedroppers-data@psg.com; Mon, 15 Oct 2001 16:51:10 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15tHVm-000Bn6-00 for namedroppers@ops.ietf.org; Mon, 15 Oct 2001 16:51:10 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15tHVm-000BLA-00 for namedroppers@ops.ietf.org; Mon, 15 Oct 2001 16:51:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: gson@isc.org (Andreas Gustafsson) Cc: namedroppers Subject: Re: wg last call for draft-ietf-dnsext-unknown-rrs-01.txt References: <200110152240.PAA11260@gulag.araneus.fi> Message-Id: Date: Mon, 15 Oct 2001 16:50:37 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Dan is saying that the draft is unnecessary because there already is an > absolute prohibition on compression in new types and that the draft is > too loose, while Kevin is effectively saying that the draft is harmful > because the existing prohibition on compression is not absolute, and that > the draft is too strict. To me this suggests that the draft actually is > a reasonably compromise consistent with the views of the majority of the > working group. two other hypotheses: o compromises are not always the best solution. sofa beds make neither good sofas nor good beds o the document is not sufficiently clear > I'd like to ask all those who have an opinion either for or against > the draft and who have not yet expressed it on the list to please > speak up. voting, schmoting. i'd rather one comment for each issue, stating the issue clearly enough that, if folk feel it is salient, that the document could be revised based on the comment. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Oct 15 20:19:10 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16039 for ; Mon, 15 Oct 2001 20:19:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15tHmB-000CAx-00 for namedroppers-data@psg.com; Mon, 15 Oct 2001 17:08:07 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15tHmA-000CAr-00 for namedroppers@ops.ietf.org; Mon, 15 Oct 2001 17:08:06 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15tHmA-000Bod-00 for namedroppers@ops.ietf.org; Mon, 15 Oct 2001 17:08:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "Jesper G. Hoy" To: "'Andreas Gustafsson'" , "'namedroppers'" Subject: RE: wg last call for draft-ietf-dnsext-unknown-rrs-01.txt Date: Mon, 15 Oct 2001 20:05:03 -0400 Message-ID: <000a01c155d6$34929af0$6400a8c0@hp> In-Reply-To: <200110152240.PAA11260@gulag.araneus.fi> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I am for the draft - but... I agree that we need to establish exactly which RR types may have compressed RDATA. And I welcome the formalization of text representation for unknown RR types. But banning compression (and additional section processing) for ALL new RR types could be a problem with the 512 byte limit on UDP messages. Wouldn't it be possible to set aside a certain range of RR type numbers that are "safe to cache as unknown" ? Meaning those RR type numbers (when assigned) won't use compression in RDATA and won't require additional section processing. And another "unsafe" range which would be dropped or result in SERVFAIL when encountered and unknown. Also, the document does not address compression of record labels. As far as I can tell this should never cause any problems. I would like to see an addition to section 4 like "record labels MAY be compressed for ALL record types" Jesper G. Hoy -----Original Message----- From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Andreas Gustafsson Sent: Monday, October 15, 2001 6:41 PM To: namedroppers Subject: Re: wg last call for draft-ietf-dnsext-unknown-rrs-01.txt Randy Bush writes: > my read is that there is NOT rough consensus. please feel free to disabuse > me of that notion. This is how I would summarize the discussion: Bert Hubert expressed worry about the lack of support for mandatory additional section processing, but still said it was a "very good proposal". Mark Gritter worried about the treatment of meta-RRs, which are outside the scope of the draft. Dan Bernstein opposed the draft for multiple reasons. Kevin Darcy opposed the unconditional prohibition of compression in new types and asked that the draft specifically allow for compression when negotiated using some future mechanism (e.g., based on EDNS). The author, Roy Arends, Mark Andrews, Robert Elz, and Olafur Gudmundsson defended the current text of the draft. Of these, I view only Dan's and Kevin's messages as significant opposition to the draft. Interestingly, these two cases of opposition represent almost diametrically opposed viewpoints: Dan is saying that the draft is unnecessary because there already is an absolute prohibition on compression in new types and that the draft is too loose, while Kevin is effectively saying that the draft is harmful because the existing prohibition on compression is not absolute, and that the draft is too strict. To me this suggests that the draft actually is a reasonably compromise consistent with the views of the majority of the working group. I'd like to ask all those who have an opinion either for or against the draft and who have not yet expressed it on the list to please speak up. -- Andreas Gustafsson, gson@isc.org to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. to unsubscribe send a message to 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 Oct 15 20:19:55 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16058 for ; Mon, 15 Oct 2001 20:19:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15tHml-000CBg-00 for namedroppers-data@psg.com; Mon, 15 Oct 2001 17:08:43 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15tHml-000CBa-00 for namedroppers@ops.ietf.org; Mon, 15 Oct 2001 17:08:43 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15tHml-000Bpb-00 for namedroppers@ops.ietf.org; Mon, 15 Oct 2001 17:08:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3BCB79D0.8926441B@daimlerchrysler.com> Date: Mon, 15 Oct 2001 20:05:36 -0400 From: Kevin Darcy To: namedroppers Subject: Re: wg last call for draft-ietf-dnsext-unknown-rrs-01.txt References: <200110152240.PAA11260@gulag.araneus.fi> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Well, I think I've already stated my opinion in sufficient detail. I'd have preferred that the prohibition on RDATA compression contained an exception for situations in which it can be used safely, e.g. when negotiated via EDNS or some similar mechanism. But, as Andreas pointed out, such exceptions can always be made on a case-by-case basis by whomever may be proposing the new types. As such, I have no *strong* objection to the advancement of the draft. - Kevin gson@isc.org wrote: > Randy Bush writes: > > my read is that there is NOT rough consensus. please feel free to disabuse > > me of that notion. > > This is how I would summarize the discussion: > > Bert Hubert expressed worry about the lack of support for mandatory > additional section processing, but still said it was a "very good > proposal". > > Mark Gritter worried about the treatment of meta-RRs, which are > outside the scope of the draft. > > Dan Bernstein opposed the draft for multiple reasons. > > Kevin Darcy opposed the unconditional prohibition of compression > in new types and asked that the draft specifically allow for > compression when negotiated using some future mechanism (e.g., > based on EDNS). > > The author, Roy Arends, Mark Andrews, Robert Elz, and Olafur > Gudmundsson defended the current text of the draft. > > Of these, I view only Dan's and Kevin's messages as significant > opposition to the draft. Interestingly, these two cases of opposition > represent almost diametrically opposed viewpoints: Dan is saying that > the draft is unnecessary because there already is an absolute > prohibition on compression in new types and that the draft is too > loose, while Kevin is effectively saying that the draft is harmful > because the existing prohibition on compression is not absolute, and > that the draft is too strict. To me this suggests that the draft > actually is a reasonably compromise consistent with the views of the > majority of the working group. > > I'd like to ask all those who have an opinion either for or against > the draft and who have not yet expressed it on the list to please > speak up. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Oct 15 22:07:48 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17896 for ; Mon, 15 Oct 2001 22:07:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15tJSY-000E4k-00 for namedroppers-data@psg.com; Mon, 15 Oct 2001 18:55:58 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15tJSX-000E4e-00 for namedroppers@ops.ietf.org; Mon, 15 Oct 2001 18:55:57 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15tJSX-000EmX-00 for namedroppers@ops.ietf.org; Mon, 15 Oct 2001 18:55:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200110160153.f9G1r0986115@drugs.dv.isc.org> To: namedroppers From: Mark.Andrews@isc.org Subject: Re: wg last call for draft-ietf-dnsext-unknown-rrs-01.txt In-reply-to: Your message of "Mon, 15 Oct 2001 16:50:37 MST." Date: Tue, 16 Oct 2001 11:53:00 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This draft is really just documenting existing practice as described in existing RFCs (not just 1034 and 1035) and how to deal some of the mistakes in those RFCs. There is only one thing new in this draft. That is that it describes a text format that can be used to in master files to describe the contents of a RR and have it be read by multiple implementations instead of each implementation going and doing it there own way. This draft was not intended to extend on wire functionality. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Oct 15 22:07:55 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17907 for ; Mon, 15 Oct 2001 22:07:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15tJQS-000E23-00 for namedroppers-data@psg.com; Mon, 15 Oct 2001 18:53:48 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15tJQR-000E1x-00 for namedroppers@ops.ietf.org; Mon, 15 Oct 2001 18:53:47 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15tJQR-000Eip-00 for namedroppers@ops.ietf.org; Mon, 15 Oct 2001 18:53:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: namedroppers Subject: dnssec key manglement Message-Id: Date: Mon, 15 Oct 2001 18:52:54 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit from a discussion with a secret friend :-) > current techniques are oob via a web page or email. these do not > do well for frequent re-keying. i am not sure if this has been > thought out at any scale. This is a good time to think it out: DS is a lot simpler keying scenario to manage than sig@child Maybe there's a simple key exchange protocol buried in IKE or coming in JFK that can be used to meet dnssec requirements. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Oct 15 23:28:02 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19817 for ; Mon, 15 Oct 2001 23:28:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15tKYn-000FEr-00 for namedroppers-data@psg.com; Mon, 15 Oct 2001 20:06:29 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15tKYn-000FEl-00 for namedroppers@ops.ietf.org; Mon, 15 Oct 2001 20:06:29 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15tKYn-000Gfk-00 for namedroppers@ops.ietf.org; Mon, 15 Oct 2001 20:06:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 16 Oct 2001 03:04:05 -0000 Message-ID: <20011016030405.745.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: wg last call for draft-ietf-dnsext-unknown-rrs-01.txt References: <200110152240.PAA11260@gulag.araneus.fi> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Andreas Gustafsson writes: > Dan is saying that the draft is unnecessary because there already is > an absolute prohibition on compression in new types and that the draft > is too loose, That is an astoundingly inaccurate summary. Here's what I actually said: : Gustafsson's document says that caches ``SHOULD also decompress RRs of : type RP, AFSDB, RT, SIG, PX, NXT, NAPTR, and SRV.'' : : I objected to that text in December 2000, and I continue to object to : it, for several reasons: : : * RFC 1035 clearly prohibits compression except in owner names, NS : data, CNAME data, PTR data, MX data, and SOA data. Compression in : RP, AFSDB, etc. is inexcusable. There are no legitimate situations : where decompression of RP, AFSDB, etc. will accomplish anything. : : * My cache, which is deployed at tens of thousands of sites, handles : exactly the forms of compression allowed by RFC 1035. It does _not_ : decompress RP, AFSDB, etc. It works just fine. : : * Gustafsson's text violates RFC 2119, section 6. It is not necessary : for interoperability. It is an abuse of the standards process. : : * BIND's support for bogus compressed records was exactly what led to : the http://www.cert.org/advisories/CA-2000-20.html disaster. We do : _not_ want more of these disasters. : : The text should be replaced by the opposite recommendation. Implementors : should be encouraged to make their decompression code as limited as : possible, handling RFC 1035 compression and nothing else. : : Gustafsson's only response to these points has been ``it's a SHOULD, not : a MUST,'' completely ignoring the substance of my objections. : : I also object to this document's failure to point out that transparent : handling of new types is already required by the existing DNS standards. : See http://cr.yp.to/djbdns/newtypes.html. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Oct 16 00:32:01 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20959 for ; Tue, 16 Oct 2001 00:32:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15tLeX-000GHg-00 for namedroppers-data@psg.com; Mon, 15 Oct 2001 21:16:29 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15tLeX-000GHa-00 for namedroppers@ops.ietf.org; Mon, 15 Oct 2001 21:16:29 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15tLeX-000IZn-00 for namedroppers@ops.ietf.org; Mon, 15 Oct 2001 21:16:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200110160411.f9G4B3986456@drugs.dv.isc.org> To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: wg last call for draft-ietf-dnsext-unknown-rrs-01.txt In-reply-to: Your message of "16 Oct 2001 03:04:05 GMT." <20011016030405.745.qmail@cr.yp.to> Date: Tue, 16 Oct 2001 14:11:03 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Andreas Gustafsson writes: > > Dan is saying that the draft is unnecessary because there already is > > an absolute prohibition on compression in new types and that the draft > > is too loose, > > That is an astoundingly inaccurate summary. Here's what I actually said: > Dan, we can all look up what you said. It appears to have little bearing on reality and is more based on wishful thinking that no RFC was written that said you could use compression. Deal with reality. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Oct 16 12:38:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09746 for ; Tue, 16 Oct 2001 12:38:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15tWif-000154-00 for namedroppers-data@psg.com; Tue, 16 Oct 2001 09:05:29 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15tWif-00014y-00 for namedroppers@ops.ietf.org; Tue, 16 Oct 2001 09:05:29 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15tWib-000C4Y-00 for namedroppers@ops.ietf.org; Tue, 16 Oct 2001 09:05:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: "Jesper G. Hoy" cc: "'Andreas Gustafsson'" , "'namedroppers'" Subject: Re: wg last call for draft-ietf-dnsext-unknown-rrs-01.txt In-Reply-To: <000a01c155d6$34929af0$6400a8c0@hp> References: <000a01c155d6$34929af0$6400a8c0@hp> Date: Tue, 16 Oct 2001 17:20:30 +0700 Message-ID: <11922.1003227630@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Mon, 15 Oct 2001 20:05:03 -0400 From: "Jesper G. Hoy" Message-ID: <000a01c155d6$34929af0$6400a8c0@hp> | But banning compression (and additional section processing) for ALL new | RR types could be a problem with the 512 byte limit on UDP messages. Other than knowing RDATA encodings, and knowing that they're known, it is the only way. | Wouldn't it be possible to set aside a certain range of RR type numbers | that are "safe to cache as unknown" ? | Meaning those RR type numbers (when assigned) won't use compression in | RDATA and won't require additional section processing. Additional section processing isn't a big issue - it's really just an efficiency win, so there's no real need to say anything about that at all. If it doesn't happen because a cache doesn't understand the RR type, then more queries happen. Not optimal, but not fatal either. For compression, define the "certain range" as "all except for the magic N", and that's what we have today. | And another "unsafe" range which would be dropped or result in SERVFAIL | when encountered and unknown. This is what you're really proposing - defining a range of RR identifiers which might contain weird stuff (compressed labels) and which thus can never be cached by anyone who doesn't understand them. The effect of that would be largely to set aside a range of RR identifiers as unusable, as in practice, an RR that can't get through random caches isn't going to work very well. Just about anyone who wants a new RR type will define it to not permit compression of any labels in its RDATA just to avoid this. And even if it was to be considered, there's still the problem of all those other caches out there which don't know there's this magic set of RR types they've never heard of, and they're not allowed to cache. | Also, the document does not address compression of record labels. | As far as I can tell this should never cause any problems. | I would like to see an addition to section 4 like "record labels MAY be | compressed for ALL record types" It wouldn't hurt adding that, but that's also pretty much given - compression of labels is allowed in 1035, there's nothing new about that - it isn't really in any doubt at all. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Oct 16 15:13:14 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16299 for ; Tue, 16 Oct 2001 15:13:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15tZ85-0003hS-00 for namedroppers-data@psg.com; Tue, 16 Oct 2001 11:39:53 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15tZ85-0003hM-00 for namedroppers@ops.ietf.org; Tue, 16 Oct 2001 11:39:53 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15tZ85-000GM9-00 for namedroppers@ops.ietf.org; Tue, 16 Oct 2001 11:39:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <5.1.0.14.2.20011016142232.025f4de0@localhost> Date: Tue, 16 Oct 2001 14:31:55 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Admitting more documents: TKEY secret removal Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This document has requested to be added to the working group work items. This document is within the working charter is there any objection to admitting it ? draft-kamite-dnsext-tkey-secret-removal-00.txt Abstract: TKEY [RFC2930] provides methods of setting up shared secret keys for TSIG [RFC2845] other than manual exchange. But TKEY itself cannot control timing of key renewal very well though it can add or delete shared keys. Since continuing to sign messages with old keys permanently is not safe, hosts which make use of TSIG should pay attention to the time limit of secret usage. This document proposes a new Secret Key Renewal Mode in TKEY which periodically changes secret shared between two hosts. Servers check valid period of secret when they receive messages from clients, and if they have already expired, the servers demand that clients should send TKEY key renewal requests which are based on Diffie-Hellman exchange. After secret establishment by exchange, new secret keys become valid and the previous old keys are completely invalidated. to unsubscribe send a message to 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 Oct 16 15:13:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16326 for ; Tue, 16 Oct 2001 15:13:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15tZ7w-0003h3-00 for namedroppers-data@psg.com; Tue, 16 Oct 2001 11:39:44 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15tZ7w-0003gx-00 for namedroppers@ops.ietf.org; Tue, 16 Oct 2001 11:39:44 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15tZ7w-000GLu-00 for namedroppers@ops.ietf.org; Tue, 16 Oct 2001 11:39:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <5.1.0.14.2.20011016143043.00afad90@localhost> Date: Tue, 16 Oct 2001 14:35:31 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Admitting more documents: application keys in DNS Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit These two documents take a different approach on how applications can store key information in DNS, one uses generic key protocol value, the other one proposes a new RR type. If admitted it is expected that at most one of these documents will advance. Is there any objection to adding the documents to the working group plate? draft-schlyter-appkey-00.txt draft-lewis-dnsext-key-genprot-00.txt Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Oct 16 15:14:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16420 for ; Tue, 16 Oct 2001 15:14:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15tZ02-0003Ye-00 for namedroppers-data@psg.com; Tue, 16 Oct 2001 11:31:34 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15tZ01-0003YY-00 for namedroppers@ops.ietf.org; Tue, 16 Oct 2001 11:31:33 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15tZ01-000G7U-00 for namedroppers@ops.ietf.org; Tue, 16 Oct 2001 11:31:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <5.1.0.14.2.20011016123744.025df4a0@localhost> Date: Tue, 16 Oct 2001 14:22:28 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Admitting Opcode discover draft? Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit As discussed in the DNSEXT meeting in London, the author will change copyright statement if and only if working group agrees to adopt as a work item. An i-d of the same technical content as the ID named above will be issued, the new document will fully conform to RFC2026 with standard copyright without any changes or additions. Is the working group willing to adopt this work (please be civil and technical) ? Olafur >To: IETF-Announce: ; >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-ymbk-opcode-discover-02.txt >Date: Tue, 19 Jun 2001 10:31:34 -0400 >Sender: nsyracus@cnri.reston.va.us >X-UIDL: h\_"!e%4"!T;#"!J:G!! > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : The DISCOVER opcode > Author(s) : B. Manning, P. Vixie, E. Guttman > Filename : draft-ymbk-opcode-discover-02.txt > Pages : > Date : 18-Jun-01 > >The QUERY opcode in the DNS is designed for unicast. With the >development of multicast capabilities in the DNS, it is desireable >to have a more robust opcode for server interactions since a single >request may result in replies from multiple responders. So DISCOVER >is defined to deal with replies from multiple responders. >As such, this document extend the core DNS specifications to allow >clients to have a method for coping with replies from multiple >responders. Use of this new opcode may facilitate DNS operations in >modern networking topologies. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ymbk-opcode-discover-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-ymbk-opcode-discover-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-ymbk-opcode-discover-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. >Content-Type: text/plain >Content-ID: <20010619102814.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ymbk-opcode-discover-02.txt > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Oct 16 15:20:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16659 for ; Tue, 16 Oct 2001 15:20:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15tZQW-00043U-00 for namedroppers-data@psg.com; Tue, 16 Oct 2001 11:58:56 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15tZQU-00043B-00 for namedroppers@ops.ietf.org; Tue, 16 Oct 2001 11:58:54 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15tZQU-000Gtn-00 for namedroppers@ops.ietf.org; Tue, 16 Oct 2001 11:58:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <5.1.0.14.2.20011016144218.025d9290@localhost> Date: Tue, 16 Oct 2001 14:46:47 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: DNSEXT WGLC: obsolete Iquery Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a last call for this document, it obsoletes a part of RFC1035 that has been known to be of more harm than use. WGLC will conclude 2001/10/31 at 23:59 UTC. Silence on this document will be interpreted as support for this action. http://www.ietf.org/internet-drafts/draft-ietf-dnsext-obsolete-iquery-01.txt Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Oct 16 17:01:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20889 for ; Tue, 16 Oct 2001 17:01:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15tb71-00068Y-00 for namedroppers-data@psg.com; Tue, 16 Oct 2001 13:46:55 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15tb6z-00068S-00 for namedroppers@ops.ietf.org; Tue, 16 Oct 2001 13:46:53 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15tb6z-000JvT-00 for namedroppers@ops.ietf.org; Tue, 16 Oct 2001 13:46:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: namedroppers@ops.ietf.org Cc: dnssec@cafax.se Subject: comments on delegation signer From: David Blacka Date: 16 Oct 2001 16:28:35 -0400 Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I have a few comments about the Delegation Signer draft . First is a fairly minor issue: the DS draft states that in the textual representation of a DS record, HEX should be used to display the SHA-1 hash. However, this is inconsistent with the other DNSSEC RR types. This forces implementors to create or have access to a base16 conversion library, in addition to a base64 library. I can see no particularly compelling reason to use hex here, especially considering that base64 is sufficient for the other DNSSEC records. My second comment centers around how resolvers determine the security status of a child zone under this draft. Section 2.2 states "If a DS RR set accompanies the NS RR set, the intent is to state that the child zone is secured. If an NS RR set exists without a DS RR set the intent is to state that the child zone is unsecure." This presents (I think) a security flaw. If we posit the existence of a sophisticated "man in the middle" attacker that can arbitrarily change DNS response packets, then this attacker can convert a secure delegation to an unsecure, hijacked destination by removing the DS records and signatures and altering the unsigned NS records. This vulnerability does not exist using RFC 2535 semantics. This attacker could only convert an unsecure delegation to a secure one (by removing the NULL KEY), which does him no good. He cannot convert a secure delegation to an unsecure one, because that would require the ability to sign a NULL KEY record. Instead, a better approach might be to require DS enabled servers to return either: NS RR set + DS RR set + SIG{DS} set (for secure delegations) OR NS RR set + NXT + SIG{NXT}. (for insecure delegations) The NXT record needs to show the non-existence of a DS (or KEY) RR set. Merely receiving NS RRs could either be an error (if we are aware that the zone is using DS) or could be interpreted as a SIG@child delegation. This could eliminate the need for a SEC RR or bit in the KEY record to indicate use of DS, as there would be no ambiguous cases: delegation: sec unsec +---------+---------------+ SIG@child | NS | NS, NULL KEY, | | only | SIG{KEY} | +---------+---------------+ DS | NS,DS | NS, NXT | | SIG{DS} | SIG{NXT} | +---------+---------------+ -- David Blacka Sr. Research Engineer Verisign Applied Research to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Oct 16 17:02:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20909 for ; Tue, 16 Oct 2001 17:02:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15tb7I-0006A1-00 for namedroppers-data@psg.com; Tue, 16 Oct 2001 13:47:12 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15tb7H-00069r-00 for namedroppers@ops.ietf.org; Tue, 16 Oct 2001 13:47:11 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15tb7H-000Jw4-00 for namedroppers@ops.ietf.org; Tue, 16 Oct 2001 13:47:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 16 Oct 2001 13:33:17 -0700 (PDT) Message-Id: <200110162033.NAA11933@gulag.araneus.fi> To: "Jesper G. Hoy" Cc: namedroppers@ops.ietf.org Subject: RE: wg last call for draft-ietf-dnsext-unknown-rrs-01.txt In-Reply-To: <000a01c155d6$34929af0$6400a8c0@hp> References: <200110152240.PAA11260@gulag.araneus.fi> <000a01c155d6$34929af0$6400a8c0@hp> From: gson@isc.org (Andreas Gustafsson) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jesper G. Hoy writes: > Wouldn't it be possible to set aside a certain range of RR type numbers > that are "safe to cache as unknown" ? One problem with this approach is that the NXT record deals poorly with high-numbered types. > Also, the document does not address compression of record labels. > As far as I can tell this should never cause any problems. > I would like to see an addition to section 4 like "record labels MAY be > compressed for ALL record types" This is already noted in RFC1123 section 6.1.3.5. I will add a reference to this section in the next revision of the draft. -- Andreas Gustafsson, gson@isc.org to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Oct 16 18:16:07 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21941 for ; Tue, 16 Oct 2001 18:16:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15tc6p-0007MB-00 for namedroppers-data@psg.com; Tue, 16 Oct 2001 14:50:47 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15tc6p-0007M5-00 for namedroppers@ops.ietf.org; Tue, 16 Oct 2001 14:50:47 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15tc6p-000LjK-00 for namedroppers@ops.ietf.org; Tue, 16 Oct 2001 14:50:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: =?iso-8859-1?q?=D3lafur_Gu=F0mundsson?= Cc: namedroppers@ops.ietf.org Subject: Re: Admitting more documents: application keys in DNS References: <5.1.0.14.2.20011016143043.00afad90@localhost> From: Simon Josefsson In-Reply-To: <5.1.0.14.2.20011016143043.00afad90@localhost> =?iso-8859-1?q?(=D3lafur_Gu=F0mundsson's?= message of "Tue, 16 Oct 2001 14:35:31 -0400") Date: Tue, 16 Oct 2001 23:38:29 +0200 Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit =D3lafur Gu=F0mundsson writes: > These two documents take a different approach on how applications can > store key information in DNS, one uses generic key protocol value, the > other one proposes a new RR type. > If admitted it is expected that at most one of these documents will advan= ce. > Is there any objection to adding the documents to the working group plate? >=20 > draft-schlyter-appkey-00.txt > draft-lewis-dnsext-key-genprot-00.txt For the record I'd like to mention two alternative approaches: * Specifying new RR types for each application * Using CERT RR (RFC 2538) for this purpose Both of the drafts above, and the two alternative approaches, accomplish the same goal: Separating DNSSEC keying material from non-DNS, application specific, keying material. This is good, hence one of the ideas should be recommended. (Some people argue that application keys should not be present in DNS at all, but I haven't seen much in the area of technical arguments for that opinion.) The first draft, APPKEY, introduces a new RR for this, which makes things nice and clean. I think the draft would require changes to DNS software though, and neglects experience with the CERT RR (see below). The second draft suggests using the DNSSEC KEY RR combined with owner name guidelines. It solves the problem of separating DNSSEC and non-DNSSEC keying material, and the large RRset problem. However, IMHO it is a kludge, and draft-schlyter-appkey seem to agree (sorry if I'm putting words in people's mouths): Although this would indeed solve the problem with large RR sets when querying for an application key, it could also make the protocol field lose its value in practice as new applications would not require a new protocol value. The author believes that combining unique protocol values with SRV-like encode of protocol would be a better solution solving both the issue with large RR sets and a large number of possible applications. Using a new RR for each application avoids sub-typing RR and solves all problems. However, this is probably only a academic idea since new RRs seem to take ages to happen, and application designers will probably not want to go through that effort. The fourth idea, using the CERT record has the same advantages of the proposed APPKEY but it is also implemented by DNS software, as well as applications. It also fulfills the requirements in the quotation above. As far as I have been able to understand, the only disadvantage of the fourth idea is that some people feel that the CERT RR is intended to only carry "certificates" according to some strict definition that would only match X.509 or similar, and exclude "raw" keys such as those used for e.g. SSH. I think this is wrong, the CERT RR can be regarded as a RR intended to support key material for applications. If you step out of the box, a raw key (stored in a CERT RR) which has a binding to a name which is guaranteed by DNSSEC _is_ a "certificate" in the abstract definition, so it is fine to store it in the CERT RR. If it hasn't been obvious, I'd like to see the CERT RR updated with owner name guidelines as the solution to the problem of application keying material in DNS. PS. These ideas has been discussed on http://www.cafax.se/dnssec/ previously. to unsubscribe send a message to 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 Oct 16 20:37:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23279 for ; Tue, 16 Oct 2001 20:37:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15teIX-0009rY-00 for namedroppers-data@psg.com; Tue, 16 Oct 2001 17:11:01 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15teIX-0009rR-00 for namedroppers@ops.ietf.org; Tue, 16 Oct 2001 17:11:01 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15teIW-000PiS-00 for namedroppers@ops.ietf.org; Tue, 16 Oct 2001 17:11:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <5.1.0.14.0.20011016170502.048642a8@jurassic.eng.sun.com> Date: Tue, 16 Oct 2001 17:08:35 -0700 To: namedroppers@ops.ietf.org, dnsop@cafax.se From: Alain Durand Subject: IPv6 DNS bridging system: lookup proxy Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit FYI, NGtrans just started a 2 weeks last call on draft-ietf-ngtrans-dns-ops-req-02.txt I guess this draft will also have to be discussed in DNS-ops. One of the things that this requirement draft highlights is the need for a bridging system. After many discussions with Johan Ihren and Akira Kato, I'm convinced that something like a lookup proxy is needed to bridge from IPv6 to IPv4. I have published a draft that outline a _possible_ solution: http://search.ietf.org/internet-drafts/draft-durand-dns-proxy-00.txt. I would like to bring this draft to DNS-OPS and/or DNS-ext as a contribution for discussion. - Alain. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Oct 17 00:59:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29476 for ; Wed, 17 Oct 2001 00:59:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15tiQW-000EYb-00 for namedroppers-data@psg.com; Tue, 16 Oct 2001 21:35:32 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15tiQV-000EYV-00 for namedroppers@ops.ietf.org; Tue, 16 Oct 2001 21:35:31 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15tiQV-000717-00 for namedroppers@ops.ietf.org; Tue, 16 Oct 2001 21:35:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: David Blacka Cc: namedroppers@ops.ietf.org, dnssec@cafax.se Subject: Re: comments on delegation signer References: From: Derek Atkins Date: 16 Oct 2001 21:19:12 -0400 In-Reply-To: David Blacka's message of "16 Oct 2001 16:28:35 -0400" Message-ID: Lines: 55 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit David Blacka writes: > First is a fairly minor issue: the DS draft states that in the textual > representation of a DS record, HEX should be used to display the SHA-1 > hash. However, this is inconsistent with the other DNSSEC RR types. > This forces implementors to create or have access to a base16 > conversion library, in addition to a base64 library. I can see no > particularly compelling reason to use hex here, especially considering > that base64 is sufficient for the other DNSSEC records. Hex is used in the DS draft because pretty much every other security protocol uses hex to represent hash values. As for a base-16 "library", last I checked it was provided in LIBC. Two particular functions you should know about: "printf" and "scanf". If that isn't sufficient for your tastes, any programmer worth their grain in salt can write a base16 parser in less that 10 lines of C. > Instead, a better approach might be to require DS enabled servers to > return either: > > NS RR set + DS RR set + SIG{DS} set (for secure delegations) > > OR > > NS RR set + NXT + SIG{NXT}. (for insecure delegations) > > The NXT record needs to show the non-existence of a DS (or KEY) RR > set. I was under the impression that this was implied by the fact that the parent zone was secured in the first place. The DS SIG on the DS record is implied by the fact that the parent is secure. So in the case of a secure delegation the client should expect NS + DS + SIG{DS}. Alternatively is should expect expect NS + NXT + SIG{NXT} in the case on an insecure delegation. Again, this is implied by 2535. > Merely receiving NS RRs could either be an error (if we are aware that > the zone is using DS) or could be interpreted as a SIG@child > delegation. Merely receiving NS RRs would violate 2535, so the client would know something was up. OTOH, DNSSec does not protect against most DoS attacks. > -- > David Blacka > Sr. Research Engineer Verisign Applied Research -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Oct 17 01:00:03 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29510 for ; Wed, 17 Oct 2001 01:00:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15tiMt-000EUN-00 for namedroppers-data@psg.com; Tue, 16 Oct 2001 21:31:47 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15tiMt-000EUH-00 for namedroppers@ops.ietf.org; Tue, 16 Oct 2001 21:31:47 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15tiMs-0006um-00 for namedroppers@ops.ietf.org; Tue, 16 Oct 2001 21:31:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alain Durand Cc: namedroppers@ops.ietf.org, dnsop@cafax.se In-reply-to: alain.durand's message of Tue, 16 Oct 2001 17:08:35 MST. <5.1.0.14.0.20011016170502.048642a8@jurassic.eng.sun.com> Subject: Re: IPv6 DNS bridging system: lookup proxy From: itojun@iijlab.net Date: Wed, 17 Oct 2001 10:10:21 +0900 Message-ID: <16992.1003281021@itojun.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >One of the things that this requirement draft highlights is the need for a >bridging >system. After many discussions with Johan Ihren and Akira Kato, >I'm convinced that something like a lookup proxy is needed to bridge >from IPv6 to IPv4. >I have published a draft that outline a _possible_ solution: >http://search.ietf.org/internet-drafts/draft-durand-dns-proxy-00.txt. > >I would like to bring this draft to DNS-OPS and/or DNS-ext as a >contribution for discussion. section 6, "anycast issues" says that it is prohibited to use an anycast address source address (from RFC2460). however, section 3.3 describes the use of TCP with the anycast prefix (P::a.b.c.d). these sections are inconsistent at best (TCP cannot be established without using P::a.b.c.d as source). itojun to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Oct 17 08:44:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21335 for ; Wed, 17 Oct 2001 08:44:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15tpjr-000N3N-00 for namedroppers-data@psg.com; Wed, 17 Oct 2001 05:23:59 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15tpjr-000N3H-00 for namedroppers@ops.ietf.org; Wed, 17 Oct 2001 05:23:59 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15tpjq-000Jr4-00 for namedroppers@ops.ietf.org; Wed, 17 Oct 2001 05:23:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200110171057.f9HAvrP78099@quasar.kaynet.ecc.u-tokyo.ac.jp> Date: Wed, 17 Oct 2001 19:57:53 +0900 From: Yuji Kamite To: namedroppers@ops.ietf.org Cc: kamite@kaynet.ecc.u-tokyo.ac.jp, nakayama@nc.u-tokyo.ac.jp Subject: TKEY secret renewal In-Reply-To: <5.1.0.14.2.20011016142232.025f4de0@localhost> References: <5.1.0.14.2.20011016142232.025f4de0@localhost> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 16 Oct 2001 14:31:55 -0400 _lafur Gu_mundsson wrote: > This document has requested to be added to the working group > work items. This document is within the working charter is there any > objection to admitting it ? > > draft-kamite-dnsext-tkey-secret-removal-00.txt The title is wrong. Correct one is draft-kamite-dnsext-tkey-secret-renewal-00.txt Please be careful not to fail to read. This document is about the management of secret keys used for TSIG, which suggests smooth key renewal (rekeying) procedure making use of TKEY. Now we are reconsidering some definitions of secret key inception, renewal timing, and expiration etc. (perhaps which we think are obscure) in this draft. In order to explain more clearly, we are going to submit a revised version by the next meeting, if possible. Thank you. -- Yuji Kamite Information Technology Center, Univ. of Tokyo E-Mail: kamite@kaynet.ecc.u-tokyo.ac.jp > Abstract: > TKEY [RFC2930] provides methods of setting up shared secret keys for > TSIG [RFC2845] other than manual exchange. But TKEY itself cannot > control timing of key renewal very well though it can add or delete > shared keys. Since continuing to sign messages with old keys > permanently is not safe, hosts which make use of TSIG should pay > attention to the time limit of secret usage. > > This document proposes a new Secret Key Renewal Mode in TKEY which > periodically changes secret shared between two hosts. Servers check > valid period of secret when they receive messages from clients, and > if they have already expired, the servers demand that clients should > send TKEY key renewal requests which are based on Diffie-Hellman > exchange. After secret establishment by exchange, new secret keys > become valid and the previous old keys are completely invalidated. > > > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Oct 17 11:58:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28182 for ; Wed, 17 Oct 2001 11:58:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15tsid-0000Pn-00 for namedroppers-data@psg.com; Wed, 17 Oct 2001 08:34:55 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15tsid-0000Ph-00 for namedroppers@ops.ietf.org; Wed, 17 Oct 2001 08:34:55 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15tsid-000PAY-00 for namedroppers@ops.ietf.org; Wed, 17 Oct 2001 08:34:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: References: <5.1.0.14.2.20011016143043.00afad90@localhost> ( =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_?= =?iso-8859-1?Q?Gu=F0mundsson=27s?= message of "Tue, 16 Oct 2001 14:35:31 -0400") <5.1.0.14.2.20011016143043.00afad90@localhost> Date: Wed, 17 Oct 2001 11:28:25 -0400 To: Simon Josefsson From: Edward Lewis Subject: Re: Admitting more documents: application keys in DNS Cc: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_?= =?iso-8859-1?Q?Gu=F0mundsson?= , namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 5:38 PM -0400 10/16/01, Simon Josefsson wrote: >PS. These ideas has been discussed on http://www.cafax.se/dnssec/ >previously. ...but no one has written drafts defining the alternate proposals. That's the second step (the first being the discussion on the list above). I think the two drafts are admittable - we do need to define a generic way in which DNS will handle application keys (at least a framework for the support). I'm not saying that the two drafts proposed are the solution - but they are the only documented approaches available. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com You fly too often when ... the airport taxi is on speed-dial. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Oct 17 13:11:06 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00484 for ; Wed, 17 Oct 2001 13:11:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15ttev-0001bD-00 for namedroppers-data@psg.com; Wed, 17 Oct 2001 09:35:09 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15tteu-0001az-00 for namedroppers@ops.ietf.org; Wed, 17 Oct 2001 09:35:08 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15ttet-0000oe-00 for namedroppers@ops.ietf.org; Wed, 17 Oct 2001 09:35:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 17 Oct 2001 18:10:10 +0200 (CEST) From: Simon Josefsson To: Edward Lewis cc: Subject: Re: Admitting more documents: application keys in DNS In-Reply-To: Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 17 Oct 2001, Edward Lewis wrote: > At 5:38 PM -0400 10/16/01, Simon Josefsson wrote: > >PS. These ideas has been discussed on http://www.cafax.se/dnssec/ > >previously. > > ...but no one has written drafts defining the alternate proposals. That's > the second step (the first being the discussion on the list above). The first idea, using one RR for each application, cannot be written generically so we have to wait for SSH, S/MIME, IPSEC, PGP etc to write each spec. I assume a brief document saying that DNSEXT would support the approach could be written, but I haven't seen anyone seriously advocating this idea so maybe noone will write it. The second alternative, to use CERT with RR owner name guidelines, has been written for S/MIME, SSL, IPSEC and CRL distribution in: http://www.ietf.org/internet-drafts/draft-josefsson-pkix-dns-00.txt [1] As such the draft has nothing to do with DNSEXT, but I guess I could take on re-drafting this for a DNSEXT point of view (if someone wants to help, please do :)) unless a resolution can't be reached by discussing the alternatives only. [1] It seems it expire tomorrow, how appropriate. to unsubscribe send a message to 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 Oct 17 16:31:01 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06709 for ; Wed, 17 Oct 2001 16:31:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15twmZ-0005m8-00 for namedroppers-data@psg.com; Wed, 17 Oct 2001 12:55:15 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15twmX-0005lu-00 for namedroppers@ops.ietf.org; Wed, 17 Oct 2001 12:55:13 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15twmX-0006Pl-00 for namedroppers@ops.ietf.org; Wed, 17 Oct 2001 12:55:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <015501c15741$0f643240$b9370681@antd.nist.gov> From: "Scott Rose" To: References: <5.1.0.14.2.20011016123744.025df4a0@localhost> Subject: Re: Admitting Opcode discover draft? Date: Wed, 17 Oct 2001 15:22:28 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit I guess you could call this an objection: >From reading the DISCOVER query draft, I got the feeling that it would almost become a lightweight resource discovery protocol. Much like SLP, only with fewer features. Do we really want to mangle DNS to make it do resouce discovery? (the section of using QTYPE = SRV is what I'm talking about). Discovery of DNS servers would be the best use of this new query type (and keep it limited to that). If the rest of the working group want to adopt this draft, I can live with it, but it my vote is it's re-inventing the wheel and forcing DNS to become a service/resource discovery protocol (which should be avoided). Scott =============================================================== Scott Rose Advanced Network Technologies Division NIST ph: 301-975-8439 fax: 301-590-0932 http://www.nist.gov =============================================================== ----- Original Message ----- From: "Ólafur Guðmundsson" To: Sent: Tuesday, October 16, 2001 2:22 PM Subject: Admitting Opcode discover draft? > As discussed in the DNSEXT meeting in London, the author will change > copyright statement if and only if working group agrees to adopt > as a work item. An i-d of the same technical content as the ID > named above will be issued, the new document will fully conform to > RFC2026 with standard copyright without any changes or additions. > > Is the working group willing to adopt this work (please be > civil and technical) ? > > Olafur > > >To: IETF-Announce: ; > >From: Internet-Drafts@ietf.org > >Reply-to: Internet-Drafts@ietf.org > >Subject: I-D ACTION:draft-ymbk-opcode-discover-02.txt > >Date: Tue, 19 Jun 2001 10:31:34 -0400 > >Sender: nsyracus@cnri.reston.va.us > >X-UIDL: h\_"!e%4"!T;#"!J:G!! > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > > > > > Title : The DISCOVER opcode > > Author(s) : B. Manning, P. Vixie, E. Guttman > > Filename : draft-ymbk-opcode-discover-02.txt > > Pages : > > Date : 18-Jun-01 > > > >The QUERY opcode in the DNS is designed for unicast. With the > >development of multicast capabilities in the DNS, it is desireable > >to have a more robust opcode for server interactions since a single > >request may result in replies from multiple responders. So DISCOVER > >is defined to deal with replies from multiple responders. > >As such, this document extend the core DNS specifications to allow > >clients to have a method for coping with replies from multiple > >responders. Use of this new opcode may facilitate DNS operations in > >modern networking topologies. > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-ymbk-opcode-discover-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-ymbk-opcode-discover-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-ymbk-opcode-discover-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. > >Content-Type: text/plain > >Content-ID: <20010619102814.I-D@ietf.org> > > > >ENCODING mime > >FILE /internet-drafts/draft-ymbk-opcode-discover-02.txt > > > > > > > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. to unsubscribe send a message to 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 Oct 17 18:41:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08768 for ; Wed, 17 Oct 2001 18:41:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15tz4q-0008QJ-00 for namedroppers-data@psg.com; Wed, 17 Oct 2001 15:22:16 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15tz4q-0008QC-00 for namedroppers@ops.ietf.org; Wed, 17 Oct 2001 15:22:16 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15tz4q-000AUk-00 for namedroppers@ops.ietf.org; Wed, 17 Oct 2001 15:22:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: References: David Blacka's message of "16 Oct 2001 16:28:35 -0400" Date: Wed, 17 Oct 2001 16:40:10 -0400 To: Derek Atkins From: Edward Lewis Subject: Re: comments on delegation signer Cc: David Blacka , namedroppers@ops.ietf.org, dnssec@cafax.se Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 9:19 PM -0400 10/16/01, Derek Atkins wrote: >I was under the impression that this was implied by the fact that the Either way, the document should make the inclusion of DS or NXT explicit. Mr. Blacka's assessment that stripping data to go from secure to unsecure is a concern. I wonder if that was the thought (that removing data only makes the source appeared to be more secured[1]) behind the NULL KEY RR set way back in the day when DNSSEC was first hammered out. [1] I.e., by removing an insecurity statement, the source appears to be more secure - hence a signature is expected. Since zonejackers can more easily remove records than add seemingly valid signatures, the NULL KEY was the way to go - up until operational considerations made us question the workload needed for the approach. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com You fly too often when ... the airport taxi is on speed-dial. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Oct 17 22:41:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13200 for ; Wed, 17 Oct 2001 22:41:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15u2kG-000CaG-00 for namedroppers-data@psg.com; Wed, 17 Oct 2001 19:17:16 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15u2kG-000CaA-00 for namedroppers@ops.ietf.org; Wed, 17 Oct 2001 19:17:16 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15u2kG-000H5f-00 for namedroppers@ops.ietf.org; Wed, 17 Oct 2001 19:17:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <5.1.0.14.2.20011017140806.02a3ccf0@localhost> Date: Wed, 17 Oct 2001 14:46:38 -0400 To: Simon Josefsson From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: Admitting more documents: application keys in DNS Cc: In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 12:10 PM 10/17/2001, Simon Josefsson wrote: >On Wed, 17 Oct 2001, Edward Lewis wrote: > > > At 5:38 PM -0400 10/16/01, Simon Josefsson wrote: > > >PS. These ideas has been discussed on http://www.cafax.se/dnssec/ > > >previously. > > > > ...but no one has written drafts defining the alternate proposals. That's > > the second step (the first being the discussion on the list above). > >The first idea, using one RR for each application, cannot be written >generically so we have to wait for SSH, S/MIME, IPSEC, PGP etc to write >each spec. I assume a brief document saying that DNSEXT would support the >approach could be written, but I haven't seen anyone seriously advocating >this idea so maybe noone will write it. > >The second alternative, to use CERT with RR owner name guidelines, has >been written for S/MIME, SSL, IPSEC and CRL distribution in: > >http://www.ietf.org/internet-drafts/draft-josefsson-pkix-dns-00.txt [1] You bring up a interesting point. Some applications have CERT usage defined and should use CERT records. The question is more for applications that do NOT have certificates defined how can they advertise public keys ? I do not think this is one shoe fits all situation. >As such the draft has nothing to do with DNSEXT, but I guess I could >take on re-drafting this for a DNSEXT point of view (if someone wants to >help, please do :)) unless a resolution can't be reached by discussing the >alternatives only. > >[1] It seems it expire tomorrow, how appropriate. The only DNS issue in your draft is the selection of the names. For SSL for example you say use the host name of the SSL server. This is fine for dedicated servers, what about servers that service multiple storefronts, do they use the same SSL cert for all? 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 Thu Oct 18 09:28:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08987 for ; Thu, 18 Oct 2001 09:28:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15uCaN-000O2Q-00 for namedroppers-data@psg.com; Thu, 18 Oct 2001 05:47:43 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15uCaN-000O2K-00 for namedroppers@ops.ietf.org; Thu, 18 Oct 2001 05:47:43 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15uCaN-0009jz-00 for namedroppers@ops.ietf.org; Thu, 18 Oct 2001 05:47:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 18 Oct 2001 12:16:10 +0200 (MEST) From: Jakob Schlyter To: Simon Josefsson Cc: =?iso-8859-1?q?=D3lafur_Gu=F0mundsson?= , Subject: Re: Admitting more documents: application keys in DNS In-Reply-To: Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 16 Oct 2001, Simon Josefsson wrote: > The first draft, APPKEY, introduces a new RR for this, which makes > things nice and clean. I think the draft would require changes to DNS > software though, and neglects experience with the CERT RR (see below). yes, the draft requires that DNS software adds support for APPKEY although new server software should handle unknown RR-types transparently. regarding the experience with the CERT the draft says: "The APPKEY RR is not intended for storage of certificates and a separate certificate RR, defined in RFC 2538, has been developed for that purpose." > The fourth idea, using the CERT record has the same advantages of the > proposed APPKEY but it is also implemented by DNS software, as well as > applications. It also fulfills the requirements in the quotation > above. whether a raw public key is a certificate or not has been discussed many times and we have reached no consensus on this. because of this, I still think that separating these two (i.e. having both CERT and APPKEY) are a good thing. currently installed base of applications is not an issue, except for various experimental software. I do not think that I exaggerate if I say that the total number of applications supporting KEY or CERT for non-DNS use is less than ten. > If you step out of the box, a raw key (stored in a CERT RR) which has > a binding to a name which is guaranteed by DNSSEC _is_ a "certificate" > in the abstract definition, so it is fine to store it in the CERT RR. the primary issue here is that a CERT carries its own security, independently of DNSSEC - APPKEY does not, but APPKEY+SIG(APPKEY) does. jakob to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Oct 18 10:33:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11155 for ; Thu, 18 Oct 2001 10:33:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15uDu3-000Pun-00 for namedroppers-data@psg.com; Thu, 18 Oct 2001 07:12:07 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15uDu2-000Pug-00 for namedroppers@ops.ietf.org; Thu, 18 Oct 2001 07:12:06 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15uDu2-000C6R-00 for namedroppers@ops.ietf.org; Thu, 18 Oct 2001 07:12:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: mjs@cisco.com, mellon@nominum.com, gson@nominum.com Cc: namedroppers Subject: Re: wg last call for draft-ietf-dnsext-dhcid-rr-03.txt to ps References: Message-Id: Date: Thu, 18 Oct 2001 07:11:46 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit i have received comment that this draft does not make explicit that this RR should only be defined for the IN class. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Oct 18 10:37:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11409 for ; Thu, 18 Oct 2001 10:37:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15uE4j-0000BW-00 for namedroppers-data@psg.com; Thu, 18 Oct 2001 07:23:09 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15uE4j-0000BQ-00 for namedroppers@ops.ietf.org; Thu, 18 Oct 2001 07:23:09 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15uE4j-000CQA-00 for namedroppers@ops.ietf.org; Thu, 18 Oct 2001 07:23:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.2.7.2.20011018102055.03750130@funnel.cisco.com> Date: Thu, 18 Oct 2001 10:22:43 -0400 To: Randy Bush From: Mark Stapp Subject: Re: wg last call for draft-ietf-dnsext-dhcid-rr-03.txt to ps Cc: mellon@nominum.com, gson@nominum.com, namedroppers In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit May I make that change and resubmit the -04 rev? Do you then submit that to the iesg, or do I need to do something to move it there? Thanks, Mark At 07:11 AM 10/18/2001 -0700, Randy Bush wrote: >i have received comment that this draft does not make explicit that this RR >should only be defined for the IN class. > >randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Oct 18 10:52:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11775 for ; Thu, 18 Oct 2001 10:52:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15uEIV-0000cK-00 for namedroppers-data@psg.com; Thu, 18 Oct 2001 07:37:23 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15uEIV-0000cE-00 for namedroppers@ops.ietf.org; Thu, 18 Oct 2001 07:37:23 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15uEIU-000CqU-00 for namedroppers@ops.ietf.org; Thu, 18 Oct 2001 07:37:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: References: Date: Thu, 18 Oct 2001 09:47:19 -0400 To: Jakob Schlyter From: Edward Lewis Subject: Re: Admitting more documents: application keys in DNS Cc: Simon Josefsson , =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_?= =?iso-8859-1?Q?Gu=F0mundsson?= , Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 6:16 AM -0400 10/18/01, Jakob Schlyter wrote: >yes, the draft requires that DNS software adds support for APPKEY although >new server software should handle unknown RR-types transparently. BTW, there is an effort underway to do a prototype implementation of APPKEY in BIND 9.2.0rc$i {$i in 0..7}. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com You fly too often when ... the airport taxi is on speed-dial. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Oct 18 11:57:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13574 for ; Thu, 18 Oct 2001 11:57:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15uFKi-0002bW-00 for namedroppers-data@psg.com; Thu, 18 Oct 2001 08:43:44 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15uFKh-0002bQ-00 for namedroppers@ops.ietf.org; Thu, 18 Oct 2001 08:43:43 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15uFKh-000Eou-00 for namedroppers@ops.ietf.org; Thu, 18 Oct 2001 08:43:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 18 Oct 2001 17:49:37 +0200 (CEST) From: Simon Josefsson To: Bill Manning cc: Jakob Schlyter , =?iso-8859-1?q?=D3lafur_Gu=F0mundsson?= , Subject: Re: Admitting more documents: application keys in DNS In-Reply-To: <200110181526.f9IFQmx00502@zed.isi.edu> Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 18 Oct 2001, Bill Manning wrote: > % currently installed base of applications is not an issue, except for > % various experimental software. I do not think that I exaggerate if I say > % that the total number of applications supporting KEY or CERT for non-DNS > % use is less than ten. > > Quick dump of stats on b.root-servers.net > > KEY: 2202 > CERT: 2 > > I'd say ten is agressive. :) FWIW there seem to be IPSEC implementations that uses TXT as well: http://www.ietf.org/internet-drafts/draft-richardson-ipsec-opportunistic-02.txt to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Oct 18 11:59:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13618 for ; Thu, 18 Oct 2001 11:59:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15uFKK-0002an-00 for namedroppers-data@psg.com; Thu, 18 Oct 2001 08:43:20 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15uFKK-0002ah-00 for namedroppers@ops.ietf.org; Thu, 18 Oct 2001 08:43:20 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15uFKK-000Enw-00 for namedroppers@ops.ietf.org; Thu, 18 Oct 2001 08:43:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Bill Manning Message-Id: <200110181526.f9IFQmx00502@zed.isi.edu> Subject: Re: Admitting more documents: application keys in DNS To: jakob@crt.se (Jakob Schlyter) Date: Thu, 18 Oct 2001 08:26:48 -0700 (PDT) Cc: jas@extundo.com (Simon Josefsson), ogud@ogud.com (=?iso-8859-1?q?=D3lafur_Gu=F0mundsson?=), namedroppers@ops.ietf.org In-Reply-To: from "Jakob Schlyter" at Oct 18, 2001 12:16:10 PM Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % currently installed base of applications is not an issue, except for % various experimental software. I do not think that I exaggerate if I say % that the total number of applications supporting KEY or CERT for non-DNS % use is less than ten. Quick dump of stats on b.root-servers.net KEY: 2202 CERT: 2 I'd say ten is agressive. :) --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 Thu Oct 18 12:40:55 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14730 for ; Thu, 18 Oct 2001 12:40:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15uFxJ-0003wg-00 for namedroppers-data@psg.com; Thu, 18 Oct 2001 09:23:37 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15uFxJ-0003wa-00 for namedroppers@ops.ietf.org; Thu, 18 Oct 2001 09:23:37 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15uFxJ-000FyP-00 for namedroppers@ops.ietf.org; Thu, 18 Oct 2001 09:23:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: <5.1.0.14.2.20011018091703.01eacf10@dcrocker.net> Date: Thu, 18 Oct 2001 09:22:54 -0700 To: namedroppers@ops.ietf.org From: Dave Crocker Subject: same protocol, different ports In-Reply-To: <5.1.0.14.2.20011016143043.00afad90@localhost> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit At 11:35 AM 10/16/2001, Ólafur Guðmundsson wrote: >These two documents take a different approach on how applications can >store key information in DNS, The DNS has long been appealing, for discussion as a venue for a wide variety of lookup services. Notably, few have actually gained much traction, though the appeal is serious and legitimate. Recently, the email protocol folks separated initial posting from later relaying, by "copying" SMTP for use on a separate mail submission TCP port, and permitting divergent specification of the protocol, over time. This approach could be very helpful for DNS. The core DNS function is so massively integral to Internet infrastructure operations, it would be wise to pursue other uses of the protocol on a separate port, as a separate service. At a minimum, this permits a) independent administration of core DNS data from value-added services, and b) separation of reliability concerns. Thoughts? d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.273.6464 to unsubscribe send a message to 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 Oct 18 12:53:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15072 for ; Thu, 18 Oct 2001 12:53:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15uGHj-0004ZW-00 for namedroppers-data@psg.com; Thu, 18 Oct 2001 09:44:43 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15uGHg-0004ZE-00 for namedroppers@ops.ietf.org; Thu, 18 Oct 2001 09:44:40 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15uGHg-000GZt-00 for namedroppers@ops.ietf.org; Thu, 18 Oct 2001 09:44:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.2.7.2.20011018123149.0189eec8@diablo.cisco.com> Date: Thu, 18 Oct 2001 12:42:01 -0400 To: Dave Crocker From: John Schnizlein Subject: Re: same protocol, different ports Cc: namedroppers@ops.ietf.org In-Reply-To: <5.1.0.14.2.20011018091703.01eacf10@dcrocker.net> References: <5.1.0.14.2.20011016143043.00afad90@localhost> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 12:22 PM 10/18/2001, Dave Crocker wrote: >The core DNS function is so massively integral to Internet infrastructure >operations, it would be wise to pursue other uses of the protocol on a >separate port, as a separate service. > >At a minimum, this permits a) independent administration of core DNS data >from value-added services, and b) separation of reliability concerns. > >Thoughts? Good idea. This would work well with the normal firewall treatment of port 53, requiring changes to opt-in for the value-added services. It would also provide a good environment to experiment with Randy's encouragement to make better use (more values) of the class field of a RR. 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 Thu Oct 18 13:36:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16282 for ; Thu, 18 Oct 2001 13:36:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15uGm7-0005WW-00 for namedroppers-data@psg.com; Thu, 18 Oct 2001 10:16:07 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15uGm6-0005WQ-00 for namedroppers@ops.ietf.org; Thu, 18 Oct 2001 10:16:06 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15uGm6-000Hco-00 for namedroppers@ops.ietf.org; Thu, 18 Oct 2001 10:16:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Thu, 18 Oct 2001 13:12:02 -0400 From: Michael Mealling To: Dave Crocker Cc: namedroppers@ops.ietf.org Subject: Re: same protocol, different ports Message-ID: <20011018131202.K5336@bailey.dscga.com> References: <5.1.0.14.2.20011016143043.00afad90@localhost> <5.1.0.14.2.20011018091703.01eacf10@dcrocker.net> In-Reply-To: <5.1.0.14.2.20011018091703.01eacf10@dcrocker.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit On Thu, Oct 18, 2001 at 09:22:54AM -0700, Dave Crocker wrote: > At 11:35 AM 10/16/2001, Ólafur Guðmundsson wrote: > >These two documents take a different approach on how applications can > >store key information in DNS, > > The DNS has long been appealing, for discussion as a venue for a wide > variety of lookup services. Notably, few have actually gained much > traction, though the appeal is serious and legitimate. > > Recently, the email protocol folks separated initial posting from later > relaying, by "copying" SMTP for use on a separate mail submission TCP port, > and permitting divergent specification of the protocol, over time. > > This approach could be very helpful for DNS. > > The core DNS function is so massively integral to Internet infrastructure > operations, it would be wise to pursue other uses of the protocol on a > separate port, as a separate service. > > At a minimum, this permits a) independent administration of core DNS data > from value-added services, and b) separation of reliability concerns. > > Thoughts? I've often thought of this and the conclusion I've come to is that the reason people want to use the DNS often has more to do with the APIs that are available to them and the fact that policies and procedures ensure that its a somewhat stable namespace. The problem I ran into when I thought about replicating the protocol to another port was that just about none of the APIs support the ability to ask DNS questions on another port. BIND derived APIs allow it but these days that's become a small subset. So, even if you were to run a special purpose nameserver on another port the applications developer would have no pre-defined way of getting at it (short of including their own DNS client software). The problem with that is you then bypass the OS's policy and configuration options for network directories... IMHO, dns-ext could help the world if it would at least define a set of requirements on DNS APIs. My minimum set would be: 1) any query must be able to define a port and server 2) all responses and queries must have a method for dealing with unknown resource records (usually by passing the caller the raw packet) So, yes, its an option, but if it could have been easily done it would have been done already... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Oct 18 13:36:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16295 for ; Thu, 18 Oct 2001 13:36:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15uGuO-0005na-00 for namedroppers-data@psg.com; Thu, 18 Oct 2001 10:24:40 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15uGuO-0005nR-00 for namedroppers@ops.ietf.org; Thu, 18 Oct 2001 10:24:40 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15uGuO-000Hzh-00 for namedroppers@ops.ietf.org; Thu, 18 Oct 2001 10:24:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <5.1.0.14.2.20011018101713.03a83008@dcrocker.net> Date: Thu, 18 Oct 2001 10:22:37 -0700 To: Michael Mealling From: Dave Crocker Subject: Re: same protocol, different ports Cc: namedroppers@ops.ietf.org In-Reply-To: <20011018131202.K5336@bailey.dscga.com> References: <5.1.0.14.2.20011018091703.01eacf10@dcrocker.net> <5.1.0.14.2.20011016143043.00afad90@localhost> <5.1.0.14.2.20011018091703.01eacf10@dcrocker.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 10:12 AM 10/18/2001, Michael Mealling wrote: >I've often thought of this and the conclusion I've come to is that >the reason people want to use the DNS often has more to do with >the APIs that are available to them and the fact that policies and >procedures ensure that its a somewhat stable namespace. 1. Whether to diverge the namespace would be an open question. My own (rather strong) opinion is that there should be only one namespace. It is the RR's that could/should/would diverge. 2. Whether to diverge any of the technology, including APIs, is another open question. I don't see the need to diverge, but perhaps others do. 3. Same for basic administration policies and procedures. In other words, I agree with you, and therefore am only suggesting a separation of the databases of "values" being looked up. >The problem I ran into when I thought about replicating the protocol >to another port was that just about none of the APIs support the >ability to ask DNS questions on another port. given that it would be new applications (given that we are talking about new uses of the DNS) then having to make that small a change to an API seems... a small matter. >IMHO, dns-ext could help the world if it would at least define a set of >requirements on DNS APIs. My minimum set would be: The IETF has always been reluctant to specify APIs. They are platform dependent and the IETF does platform INdependent work. And its transgressions into that space have not been met with spectacular success. d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.273.6464 to unsubscribe send a message to 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 Oct 18 13:38:02 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16373 for ; Thu, 18 Oct 2001 13:38:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15uGu8-0005n0-00 for namedroppers-data@psg.com; Thu, 18 Oct 2001 10:24:24 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15uGu7-0005mq-00 for namedroppers@ops.ietf.org; Thu, 18 Oct 2001 10:24:23 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15uGu7-000HyP-00 for namedroppers@ops.ietf.org; Thu, 18 Oct 2001 10:24:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200110181719.NAA16468@error-messages.mit.edu> To: Dave Crocker cc: namedroppers@ops.ietf.org Subject: Re: same protocol, different ports In-Reply-To: Your message of "Thu, 18 Oct 2001 09:22:54 PDT." <5.1.0.14.2.20011018091703.01eacf10@dcrocker.net> Date: Thu, 18 Oct 2001 13:19:49 -0400 From: Greg Hudson Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The core DNS function is so massively integral to Internet > infrastructure operations, it would be wise to pursue other uses of > the protocol on a separate port, as a separate service. > At a minimum, this permits a) independent administration of core DNS > data from value-added services, and b) separation of reliability > concerns. I think this is a bad idea. By changing the port number, you force these other lookup services to recreate the entire DNS hierarchy before they can achieve any kind of traction. The benefits you cite are easily achieved through zone delegation. (Well, the delegated value-added service will depend on the reliabiliy of the core service, but that's okay.) In essence, you're saying "let's not define any new record types, and tell people who want to define them to go play in this little ghetto where they are guaranteed never to get anywhere." The designers of the MIT Hesiod service made the same mistake, except they thought they wanted a separate query class instead of a separate port. They, too, thought a different mode of operation was necessary in order to achieve independent administration and separation of reliability concerns, but those benefits were already trivially achieved because Hesiod data lived under ns.athena.mit.edu instead of mit.edu. So the benefit of the separate query class was illusory, but the cost was great: a separate global root was required for the HS tree, and every recursive resolver needed special configuration to know about it. In addition, BIND 8 lost the ability to act as a recursive resolver for query classes other than IN. Luckily, we had already made a transition back to the IN class before that became an issue, but otherwise we would have lost due to having marginalized ourselves by using a slightly different mode of operation than the rest of the DNS. Such marginalization is exactly what you're proposing value-added services start doing. to unsubscribe send a message to 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 Oct 18 13:48:13 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16635 for ; Thu, 18 Oct 2001 13:48:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15uH5s-0006ER-00 for namedroppers-data@psg.com; Thu, 18 Oct 2001 10:36:32 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15uH5s-0006EL-00 for namedroppers@ops.ietf.org; Thu, 18 Oct 2001 10:36:32 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15uH5s-000IsM-00 for namedroppers@ops.ietf.org; Thu, 18 Oct 2001 10:36:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 18 Oct 2001 13:30:42 -0400 From: Michael Mealling To: Dave Crocker Cc: Michael Mealling , namedroppers@ops.ietf.org Subject: Re: same protocol, different ports Message-ID: <20011018133042.L5336@bailey.dscga.com> References: <5.1.0.14.2.20011018091703.01eacf10@dcrocker.net> <5.1.0.14.2.20011016143043.00afad90@localhost> <5.1.0.14.2.20011018091703.01eacf10@dcrocker.net> <5.1.0.14.2.20011018101713.03a83008@dcrocker.net> In-Reply-To: <5.1.0.14.2.20011018101713.03a83008@dcrocker.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, Oct 18, 2001 at 10:22:37AM -0700, Dave Crocker wrote: > At 10:12 AM 10/18/2001, Michael Mealling wrote: > >I've often thought of this and the conclusion I've come to is that > >the reason people want to use the DNS often has more to do with > >the APIs that are available to them and the fact that policies and > >procedures ensure that its a somewhat stable namespace. > > 1. Whether to diverge the namespace would be an open question. My own > (rather strong) opinion is that there should be only one namespace. It is > the RR's that could/should/would diverge. > > 2. Whether to diverge any of the technology, including APIs, is another > open question. I don't see the need to diverge, but perhaps others do. > > 3. Same for basic administration policies and procedures. > > In other words, I agree with you, and therefore am only suggesting a > separation of the databases of "values" being looked up. Sure... just a slightly different take on John's "new class" approach... > >The problem I ran into when I thought about replicating the protocol > >to another port was that just about none of the APIs support the > >ability to ask DNS questions on another port. > > given that it would be new applications (given that we are talking about > new uses of the DNS) then having to make that small a change to an API > seems... a small matter. It depends on how you deploy it. Do you setup a whole new set of root nameservers on another port or do you use the existing port 53 delegation process and then only switch ports when you get to the 'last' nameserver? How much of the OS' native DNS implementation do you use? If its none then you have to get all of the delegating nameservers upgraded to run a listener on those other ports. If its some then you have existing API issues. I've looked at just about every single DNS client side implementation and for about 80% of the machines on today's internet it would be a hard thing to deploy. I'm not saying its a show stopper, just that if you do decide you want to do it you should make it clear to client developers how they should deal with it. > >IMHO, dns-ext could help the world if it would at least define a set of > >requirements on DNS APIs. My minimum set would be: > > The IETF has always been reluctant to specify APIs. They are platform > dependent and the IETF does platform INdependent work. And its > transgressions into that space have not been met with spectacular success. I wasn't suggesting that we specify the actual API. I'm suggesting we create some guidance for API developers so they are aware that the DNS has moved beyond the old gethostbyname() and they should as well... I.e. there's a disconnect between what we think of as 'DNS' and what developers think it is. Their view causes them to create APIs that make it next to impossible to deploy DNS enhancements... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Oct 18 14:19:11 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17400 for ; Thu, 18 Oct 2001 14:19:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15uHQ5-0006zA-00 for namedroppers-data@psg.com; Thu, 18 Oct 2001 10:57:25 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15uHQ5-0006z1-00 for namedroppers@ops.ietf.org; Thu, 18 Oct 2001 10:57:25 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15uHQ4-000JZv-00 for namedroppers@ops.ietf.org; Thu, 18 Oct 2001 10:57:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <5.1.0.14.2.20011018105030.03be5e20@dcrocker.net> Date: Thu, 18 Oct 2001 10:56:32 -0700 To: Michael Mealling From: Dave Crocker Subject: Re: same protocol, different ports Cc: namedroppers@ops.ietf.org In-Reply-To: <20011018133042.L5336@bailey.dscga.com> References: <5.1.0.14.2.20011018101713.03a83008@dcrocker.net> <5.1.0.14.2.20011018091703.01eacf10@dcrocker.net> <5.1.0.14.2.20011016143043.00afad90@localhost> <5.1.0.14.2.20011018091703.01eacf10@dcrocker.net> <5.1.0.14.2.20011018101713.03a83008@dcrocker.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 10:30 AM 10/18/2001, Michael Mealling wrote: > > given that it would be new applications (given that we are talking about > > new uses of the DNS) then having to make that small a change to an API > > seems... a small matter. > >It depends on how you deploy it. Do you setup a whole new set of root >nameservers on another port or do you use the existing port 53 >delegation process and then only switch ports when you get to the >'last' nameserver? This is a really excellent point for discussion, as would be others about making the idea practical. First reaction, to the specific point you raise: Using the same namespace lookup sequence -- ie, only making the leaf query be on a different port -- ensures that the namespace administration -- and operation -- is consistent and shared. >I've looked at just about every single DNS client side implementation >and for about 80% of the machines on today's internet it would be >a hard thing to deploy. I'm not saying its a show stopper, just that >if you do decide you want to do it you should make it clear to >client developers how they should deal with it. My simplistic view is that having the DNS client module switch ports based on the RR being sought would be sufficient. And there is nothing wrong with having the responding "value-add DNS" server continue the friendly pattern of including additional, related-but-unrequested RRs, including relevant ones from the core DNS. d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.273.6464 to unsubscribe send a message to 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 Oct 18 17:27:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20088 for ; Thu, 18 Oct 2001 17:27:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15uKQE-000CV8-00 for namedroppers-data@psg.com; Thu, 18 Oct 2001 14:09:46 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15uKQD-000CV1-00 for namedroppers@ops.ietf.org; Thu, 18 Oct 2001 14:09:45 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15uKQD-000OwZ-00 for namedroppers@ops.ietf.org; Thu, 18 Oct 2001 14:09:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Michael Mealling Cc: namedroppers@ops.ietf.org Subject: Re: same protocol, different ports References: <5.1.0.14.2.20011018091703.01eacf10@dcrocker.net> <5.1.0.14.2.20011016143043.00afad90@localhost> <5.1.0.14.2.20011018101713.03a83008@dcrocker.net> <20011018133042.L5336@bailey.dscga.com> Message-Id: Date: Thu, 18 Oct 2001 14:09:19 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > just a slightly different take on John's "new class" approach... actually, i'll take the blame for that one sick part of idea. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Oct 19 02:32:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08986 for ; Fri, 19 Oct 2001 02:32:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15uStG-0002DK-00 for namedroppers-data@psg.com; Thu, 18 Oct 2001 23:12:18 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15uStF-0002DE-00 for namedroppers@ops.ietf.org; Thu, 18 Oct 2001 23:12:17 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15uStF-000Dgw-00 for namedroppers@ops.ietf.org; Thu, 18 Oct 2001 23:12:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <001101c15844$1358c650$0a0aa8c0@labs.ntrg.com> From: "Eric A. Hall" Cc: References: <5.1.0.14.2.20011018101713.03a83008@dcrocker.net> <5.1.0.14.2.20011018091703.01eacf10@dcrocker.net> <5.1.0.14.2.20011016143043.00afad90@localhost> <5.1.0.14.2.20011018091703.01eacf10@dcrocker.net> <5.1.0.14.2.20011018101713.03a83008@dcrocker.net> <5.1.0.14.2.20011018105030.03be5e20@dcrocker.net> Subject: Re: same protocol, different ports Date: Thu, 18 Oct 2001 21:16:34 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit From: "Dave Crocker" > First reaction, to the specific point you raise: Using the same > namespace lookup sequence -- ie, only making the leaf query be on a > different port -- ensures that the namespace administration -- and > operation -- is consistent and shared. If the namespace is the same, why do you need another port? to unsubscribe send a message to 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 Oct 19 12:11:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22369 for ; Fri, 19 Oct 2001 12:11:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15ubqH-000NNT-00 for namedroppers-data@psg.com; Fri, 19 Oct 2001 08:45:49 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15ubqH-000NNH-00 for namedroppers@ops.ietf.org; Fri, 19 Oct 2001 08:45:49 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15ubqH-0004Pn-00 for namedroppers@ops.ietf.org; Fri, 19 Oct 2001 08:45:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 19 Oct 2001 08:58:32 -0400 From: Michael Mealling To: "Eric A. Hall" Cc: namedroppers@ops.ietf.org Subject: Re: same protocol, different ports Message-ID: <20011019085832.O5336@bailey.dscga.com> References: <5.1.0.14.2.20011018101713.03a83008@dcrocker.net> <5.1.0.14.2.20011018091703.01eacf10@dcrocker.net> <5.1.0.14.2.20011016143043.00afad90@localhost> <5.1.0.14.2.20011018091703.01eacf10@dcrocker.net> <5.1.0.14.2.20011018101713.03a83008@dcrocker.net> <5.1.0.14.2.20011018105030.03be5e20@dcrocker.net> <001101c15844$1358c650$0a0aa8c0@labs.ntrg.com> In-Reply-To: <001101c15844$1358c650$0a0aa8c0@labs.ntrg.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, Oct 18, 2001 at 09:16:34PM -0500, Eric A. Hall wrote: > From: "Dave Crocker" > > > First reaction, to the specific point you raise: Using the same > > namespace lookup sequence -- ie, only making the leaf query be on a > > different port -- ensures that the namespace administration -- and > > operation -- is consistent and shared. > > If the namespace is the same, why do you need another port? Think of the new port as a protocol version number on the entire DNS system itself. By moving stuff to another port you can effectively say that DNS as we know it right now is frozen. In order to use the current delegation system on port 53 you'd need some way to tell a client where along the path the break to the other port is going to be. Sort of like an NS record but add a port number... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Oct 19 12:50:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24049 for ; Fri, 19 Oct 2001 12:50:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15ucbs-000PRf-00 for namedroppers-data@psg.com; Fri, 19 Oct 2001 09:35:00 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15ucbr-000PRZ-00 for namedroppers@ops.ietf.org; Fri, 19 Oct 2001 09:34:59 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15ucbr-0005uY-00 for namedroppers@ops.ietf.org; Fri, 19 Oct 2001 09:34:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869810@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Dave Crocker'" , Michael Mealling Cc: namedroppers@ops.ietf.org Subject: RE: same protocol, different ports Date: Fri, 19 Oct 2001 09:32:00 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think folk are porbably unerestimating the extent to which corporate firewalls have closed down the scope for establishing new ports. In most organizations the security officer running the firewall has no incentive to allow new protocols to be supported and a pretty big disincentive. What people are trying to do by attaching their barnacles to DNS is to bypass the problem of building critical mass by leveraging an exisiting network. Such people will have no interest in any procedure that denies them ready made critical mass. Port numbers have the additional disadvantage that the IESG have to exercise some prudence to avoid falling victim to port number exhaustion. There may well have to be a cull of little used protocols on well known ports in any case. But the IESG have been very negative to using duplicate ports for the same protocol. There are several types of barnacle being attached to DNS 1) Internationalization. Support for international character sets in the DNS system is an obvious and useful improvement. 2) Attempts to provide security to DNS This should not be regarded as scope creep, it should be considered to be correcting a serious flaw in the original DNS protocol. 3) Attempts to add in additional information These should all be directed towards appropriate use of the existing SRV record, including those that involve certificates. It is not a good idea to attempt to merege application certificates with DNS. The administrative responsibilities of DNS are different to those of any appication PKI. I can't see why 1 or 2 should justify a new port. Type 3 barnicles are almost certain to involve changes to DNS that would be much better managed using another protocol, either an existing one (LDAP, CNRP) or something new that will probably end up running over port 80. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Dave Crocker [mailto:dhc@dcrocker.net] > Sent: Thursday, October 18, 2001 1:57 PM > To: Michael Mealling > Cc: namedroppers@ops.ietf.org > Subject: Re: same protocol, different ports > > > At 10:30 AM 10/18/2001, Michael Mealling wrote: > > > given that it would be new applications (given that we > are talking about > > > new uses of the DNS) then having to make that small a > change to an API > > > seems... a small matter. > > > >It depends on how you deploy it. Do you setup a whole new set of root > >nameservers on another port or do you use the existing port 53 > >delegation process and then only switch ports when you get to the > >'last' nameserver? > > This is a really excellent point for discussion, as would be > others about > making the idea practical. > > First reaction, to the specific point you raise: Using the > same namespace > lookup sequence -- ie, only making the leaf query be on a > different port -- > ensures that the namespace administration -- and operation -- > is consistent > and shared. > > > >I've looked at just about every single DNS client side implementation > >and for about 80% of the machines on today's internet it would be > >a hard thing to deploy. I'm not saying its a show stopper, just that > >if you do decide you want to do it you should make it clear to > >client developers how they should deal with it. > > My simplistic view is that having the DNS client module > switch ports based > on the RR being sought would be sufficient. And there is > nothing wrong > with having the responding "value-add DNS" server continue > the friendly > pattern of including additional, related-but-unrequested RRs, > including > relevant ones from the core DNS. > > d/ > > ---------- > Dave Crocker > Brandenburg InternetWorking > tel +1.408.246.8253; fax +1.408.273.6464 to unsubscribe send a message to 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 Oct 19 12:54:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24273 for ; Fri, 19 Oct 2001 12:54:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15ucjs-000PoC-00 for namedroppers-data@psg.com; Fri, 19 Oct 2001 09:43:16 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15ucjr-000Po5-00 for namedroppers@ops.ietf.org; Fri, 19 Oct 2001 09:43:15 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15ucjr-0006AO-00 for namedroppers@ops.ietf.org; Fri, 19 Oct 2001 09:43:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 19 Oct 2001 12:42:39 -0400 From: Andrew Brown To: Michael Mealling Cc: "Eric A. Hall" , namedroppers@ops.ietf.org Subject: Re: same protocol, different ports Message-ID: <20011019124239.A2497@noc.untraceable.net> References: <5.1.0.14.2.20011018101713.03a83008@dcrocker.net> <5.1.0.14.2.20011018091703.01eacf10@dcrocker.net> <5.1.0.14.2.20011016143043.00afad90@localhost> <5.1.0.14.2.20011018091703.01eacf10@dcrocker.net> <5.1.0.14.2.20011018101713.03a83008@dcrocker.net> <5.1.0.14.2.20011018105030.03be5e20@dcrocker.net> <001101c15844$1358c650$0a0aa8c0@labs.ntrg.com> <20011019085832.O5336@bailey.dscga.com> In-Reply-To: <20011019085832.O5336@bailey.dscga.com>; from michael@neonym.net on Fri, Oct 19, 2001 at 08:58:32AM -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> If the namespace is the same, why do you need another port? > >Think of the new port as a protocol version number on the entire DNS >system itself. By moving stuff to another port you can effectively say >that DNS as we know it right now is frozen. > >In order to use the current delegation system on port 53 you'd need >some way to tell a client where along the path the break to the other >port is going to be. Sort of like an NS record but add a port number... sounds like an srv record to me. :) -- |-----< "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 Oct 19 13:00:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24463 for ; Fri, 19 Oct 2001 13:00:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15ucpO-000059-00 for namedroppers-data@psg.com; Fri, 19 Oct 2001 09:48:58 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15ucpN-000052-00 for namedroppers@ops.ietf.org; Fri, 19 Oct 2001 09:48:57 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15ucpN-0006M1-00 for namedroppers@ops.ietf.org; Fri, 19 Oct 2001 09:48:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 19 Oct 2001 12:44:55 -0400 From: Michael Mealling To: Andrew Brown Cc: Michael Mealling , "Eric A. Hall" , namedroppers@ops.ietf.org Subject: Re: same protocol, different ports Message-ID: <20011019124455.G21201@bailey.dscga.com> References: <5.1.0.14.2.20011018101713.03a83008@dcrocker.net> <5.1.0.14.2.20011018091703.01eacf10@dcrocker.net> <5.1.0.14.2.20011016143043.00afad90@localhost> <5.1.0.14.2.20011018091703.01eacf10@dcrocker.net> <5.1.0.14.2.20011018101713.03a83008@dcrocker.net> <5.1.0.14.2.20011018105030.03be5e20@dcrocker.net> <001101c15844$1358c650$0a0aa8c0@labs.ntrg.com> <20011019085832.O5336@bailey.dscga.com> <20011019124239.A2497@noc.untraceable.net> In-Reply-To: <20011019124239.A2497@noc.untraceable.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, Oct 19, 2001 at 12:42:39PM -0400, Andrew Brown wrote: > >> If the namespace is the same, why do you need another port? > > > >Think of the new port as a protocol version number on the entire DNS > >system itself. By moving stuff to another port you can effectively say > >that DNS as we know it right now is frozen. > > > >In order to use the current delegation system on port 53 you'd need > >some way to tell a client where along the path the break to the other > >port is going to be. Sort of like an NS record but add a port number... > > sounds like an srv record to me. :) Yea, but an SRV in the middle of the delegation path. I guess it would be a cross between DNAME and SRV. And you really wouldn't want the weight and preference part of the SRV here either.... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Oct 19 16:41:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00871 for ; Fri, 19 Oct 2001 16:41:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15ugCo-0009eg-00 for namedroppers-data@psg.com; Fri, 19 Oct 2001 13:25:22 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15ugCn-0009ea-00 for namedroppers@ops.ietf.org; Fri, 19 Oct 2001 13:25:21 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15ugCn-000D8N-00 for namedroppers@ops.ietf.org; Fri, 19 Oct 2001 13:25:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F405869810@vhqpostal.verisign.com> Date: Fri, 19 Oct 2001 16:09:16 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: RE: same protocol, different ports Cc: lewis@tislabs.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 12:32 PM -0400 10/19/01, Hallam-Baker, Phillip wrote: >3) Attempts to add in additional information I'm trying hard to understand the rationale behind the desire to limit the scope of data held in DNS. These are the following reasons I can come up with: 1) New data types engender more lookups and hence heavier load on the root servers. Regardless of the lookup, in a situation without cached data, the root will be asked first. The use of the srv record to fend off some kinds of data won't reduce the load on the root servers (or others on the way down the tree) becuase whether I am looking for the data (eg FOO) or a reference to the data (SRV), I still hit the root first. 2) New data types might require additional processing of the name server. E.g., when I ask for data with the DNSSEC OK bit on, the new SIG records are added to the answer (if available). This is an example of special processing. (This issue is also germain to the handling of unknown-to-the-server types.) If a new type does not require any additional processing, how is one of it more or less harmful than one of the traditional types? 3) New data may expand the scope of DNS beyond what its core protocol was defined to support. After spending many hours blindly poking at the elephant that is DNS, my take on DNS is that it is a simple lookup service. Meaning that directory searching, fuzzy matches, etc. are beyond the scope. So what is the damage of putting a FOO record at a domain name instead of an A record? The core of the protocol doesn't seem to care what the value of the type is, nor the internal wire format of the RDATA. 4) New data types deplete the type number's 16-bit space. This I can understand, but how quickly are we chewing through this space? Perhaps I am underestimating the concern here. (Wouldn't IPv6 solve this? Just kidding folks.) What technical reason am I missing? What of the above am I misinterpreting? What would be the big problem if I wanted to suggest a BRAND RR, which stored a base64 encoding of the UTF-8 version of the computer's retailer? (Kinda like a screwed up version of HINFO.) Signed, confounded in Glenwood... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com You fly too often when ... the airport taxi is on speed-dial. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Oct 19 17:28:48 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02270 for ; Fri, 19 Oct 2001 17:28:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15ugwq-000Boj-00 for namedroppers-data@psg.com; Fri, 19 Oct 2001 14:12:56 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15ugwp-000Bod-00 for namedroppers@ops.ietf.org; Fri, 19 Oct 2001 14:12:55 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15ugwp-000Eel-00 for namedroppers@ops.ietf.org; Fri, 19 Oct 2001 14:12:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: RE: same protocol, different ports References: <2F3EC696EAEED311BB2D009027C3F4F405869810@vhqpostal.verisign.com> Message-Id: Date: Fri, 19 Oct 2001 14:11:41 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I'm trying hard to understand the rationale behind the desire to limit the > scope of data held in DNS. It's perfectly appropriate to be upset. I thought of it in a slightly different way--like a space that we were exploring and, in the early days, we figured out this consistent path through the space: IP, TCP, and so on. What's been happening over the last few years is that the IETF is filling the rest of the space with every alternative approach, not necessarily any better. Every possible alternative is now being written down. And it's not useful. -- Jon Postel to unsubscribe send a message to 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 Oct 19 17:36:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02391 for ; Fri, 19 Oct 2001 17:36:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15uh8P-000CM3-00 for namedroppers-data@psg.com; Fri, 19 Oct 2001 14:24:53 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15uh8O-000CLx-00 for namedroppers@ops.ietf.org; Fri, 19 Oct 2001 14:24:52 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15uh8O-000F1v-00 for namedroppers@ops.ietf.org; Fri, 19 Oct 2001 14:24:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200110192124.f9JLOAH54164@as.vix.com> To: namedroppers@ops.ietf.org Subject: Re: same protocol, different ports In-Reply-To: Message from "Hallam-Baker, Phillip" of "Fri, 19 Oct 2001 09:32:00 PDT." <2F3EC696EAEED311BB2D009027C3F4F405869810@vhqpostal.verisign.com> Date: Fri, 19 Oct 2001 14:24:10 -0700 From: Paul A Vixie Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > 3) Attempts to add in additional information > These should all be directed towards appropriate use of the existing > SRV record, including those that involve certificates. It is not a good idea > to attempt to merege application certificates with DNS. The administrative > responsibilities of DNS are different to those of any appication PKI. i'm not in full agreement here. dns as a carrier for certain forms of PKI could work very well IF DNS WAS SECURE. for example i'd be very happy if i could put my uuencode/base64/whatever PGP public key into a TXT RR at paul.vix.com (assuming a '@' -> '.' mapping similar to that in SOA ANAME or in an RP RR). imagine if PGP didn't have to make an http or ftp connection to retrieve my key! i guess what i mean is, there's more than one kind of PKI and it would be unwise to characterize DNS as unsuitable for all PKI when in fact at least one known kind of key would fit into DNS just fine. on the more general topic of adding random gibberish to DNS, i seem to recall a recommendation by mike schwartz maybe 10 years ago when he was doing harvest which would "tag" TXT RR's. assuming that RFC6565 were the document that specified an encoding, i'd expect to see $ORIGIN vix.com. paul IN TXT RFC6565 PGP KEY 2.6.2 ( "mQCNAzAK1x4AAAEEANkrzStNGbzzqskxspacnGdfxmxbhxrXl+pnGte5wGM8l70m" "jqSExbbgsqSEPDuXvv/ClYmQBleCgvI3XTLo1yAIgSzL9MVtGKuOICV90/JYlt2Z" "vtSturqKzEqcCaMWZPqyOkfpXRv6hYUTh0YTTeZ2G+e5651dQ3cdkq6JcsfBAAUR" "tBlQYXVsIFZpeGllIDxwYXVsQHZpeC5jb20+" "=2A+R" ) note the disturbing but intentional absense of outer quote (") marks. TXT has a segmented RDATA, so if you don't surround the whole RDATA in quotes in the master file, BIND (at least; one assumes that other implementations also do it this way) will preserve the field boundaries in the wire format. also note that the word PGP in this example would be reserved with IANA when this particular TXT encoding was RFC'd, and such RFC would specify (in this example) that the next word was the version number the key required, and the rest of the words ("TXT RDATA segments") were the key itself, in ascii armor format. this wouldn't work well with large values. even assuming that TCP was used, there's a limit of ~64K per RDATA. but it should have been used in lieu of "rwhois" and maybe LDAP as well. new transports need better justification than "adding new RR types to the DNS is too difficult." of course, i am not volunteering to write RFC6565 (the container protocol in the above example.) "let's you and him fight." to unsubscribe send a message to 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 Oct 19 17:49:03 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02552 for ; Fri, 19 Oct 2001 17:49:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15uhKk-000CxU-00 for namedroppers-data@psg.com; Fri, 19 Oct 2001 14:37:38 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15uhKj-000CxO-00 for namedroppers@ops.ietf.org; Fri, 19 Oct 2001 14:37:37 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15uhKi-000FRE-00 for namedroppers@ops.ietf.org; Fri, 19 Oct 2001 14:37:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Mark Stapp Cc: mellon@nominum.com, gson@nominum.com, namedroppers Subject: Re: wg last call for draft-ietf-dnsext-dhcid-rr-03.txt to ps References: Message-Id: Date: Fri, 19 Oct 2001 14:37:12 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > May I make that change and resubmit the -04 rev? Do you then submit that > to the iesg, or do I need to do something to move it there? there seem to be folk too tired to speak for themselves on the mailing list, so they send this stuff to me in email. as 2026 does not specify that one has the right to confront one's accusors, i will forward anonymously :-) 1. Canonical format redefined instead of being inherited. 2. Does not define that this type is only allowed in class IN 3. Does not explicitly state if this is a singleton type or multiple DHCID RR can be in a set. 4. Section 3.4 should be structured something like: "digest is calculated over |