From owner-namedroppers@ops.ietf.org Fri Mar 1 02:26:27 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15557 for ; Fri, 1 Mar 2002 02:26:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16gh1X-0003q1-00 for namedroppers-data@psg.com; Thu, 28 Feb 2002 23:00:11 -0800 Received: from 208-59-114-172.c3-0.129-ubr1.lnh-129.md.cable.rcn.com ([208.59.114.172] helo=ogud.com) by psg.com with esmtp (Exim 3.35 #1) id 16gh1W-0003ps-00 for namedroppers@ops.ietf.org; Thu, 28 Feb 2002 23:00:10 -0800 Received: from oemcomputer.ogud.com (ns.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id g2170Kk02333 for ; Fri, 1 Mar 2002 02:00:20 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <5.1.0.14.2.20020301015340.02831740@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 01 Mar 2002 01:57:16 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: DNSEXT WGLC Summary: AXFR-02.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This last call concluded a long time ago, it is this chairs fault for not posting the consensus sooner, Sorry everyone. The working group rough consensus is to advance the document with minor changes as outlined below. There has been strong objection from certain well respected member of the working group. The main objections can be summarized in two major points: 1. He objects to the restriction that all data go in answer section, he wants section agnostic rules. There is no technical reason why one is better or worse than the other. All implementations but ONE, put all AXFR data in ANSWER section, thus that is less disruptive to formalize. 2. He objects to the restriction that AXFR MUST contain exactly the data that the master server loaded from zone file. Most early implementations did not comply with this rule, but some did, the old implementation that became the de-facto standard for DNS allowed data to leak between zones. This has certain beneficial behavior for delegations if data from children is better than parent, but has the following drawbacks a. AXFR of the same version of a zone from two servers may differ. b. IXFR updates may fail due to preconditions not being true, this was not explained in IXFR document. c. Dynamic Update may fail due to preconditions (not explained in Dynamic Update RFC). d. Diagnosing problem is harder as answers differ between Authorative servers. Since the AXFR last call concluded the working group had extensive discussion on similar issue: if DNSSEC servers could drop expired signatures. The working group expressed a strong and clear consensus on this issue: Authorative Servers MUST not change or discard any zone data, even if the server can determine data is wrong/bad. This counters objection #2. The Author has made all changes to the document that are needed, but the document has expired, Andreas please resubmit before deadline. Optional change in document before advancing to IESG: 1. Add an appendix listing the versions of name servers that are not compliant with "zone data integrity" rule and allow "zone data leakage". Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 1 03:57:13 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01640 for ; Fri, 1 Mar 2002 03:57:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16gief-00056s-00 for namedroppers-data@psg.com; Fri, 01 Mar 2002 00:44:41 -0800 Received: from 96-1.nat.psu.ac.th ([202.28.96.1] helo=brandenburg.cs.mu.OZ.AU) by psg.com with esmtp (Exim 3.35 #1) id 16gied-00056k-00 for namedroppers@ops.ietf.org; Fri, 01 Mar 2002 00:44:40 -0800 Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g218mAD02137; Fri, 1 Mar 2002 15:48:14 +0700 (ICT) From: Robert Elz To: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC Summary: AXFR-02.txt In-Reply-To: <5.1.0.14.2.20020301015340.02831740@localhost> References: <5.1.0.14.2.20020301015340.02831740@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 01 Mar 2002 15:48:10 +0700 Message-ID: <2135.1014972490@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Fri, 01 Mar 2002 01:57:16 -0500 From: Message-ID: <5.1.0.14.2.20020301015340.02831740@localhost> | All implementations but ONE, put all AXFR data in ANSWER section, I think all do. One doesn't bother checking that the data is in the answer section before processing it. | Optional change in document before advancing to IESG: | 1. Add an appendix listing the versions of name servers that are | not compliant with "zone data integrity" rule and allow "zone data | leakage". Please don't. This kind of thing has no use in stds track RFCs. That is, even if it were possible to come up with a comprehensive list, which I very much doubt. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 1 06:39:37 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11212 for ; Fri, 1 Mar 2002 06:39:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16gkld-0006V6-00 for namedroppers-data@psg.com; Fri, 01 Mar 2002 03:00:01 -0800 Received: from randy by psg.com with local (Exim 3.35 #1) id 16gklc-0006V0-00 for namedroppers@ops.ietf.org; Fri, 01 Mar 2002 03:00:00 -0800 To: namedroppers@ops.ietf.org Subject: list policy Message-Id: From: Randy Bush Date: Fri, 01 Mar 2002 03:00:00 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk namedroppers@ops.ietf.org is the mailing list for the ietf dnsext wg. see for the wg charter. messages should be on topics appropriate to the dnsext wg, which are various discussion of the dns protocols or administrivia of the wg itself. 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 poised@lists.tislabs.com --- NOTE WELL: All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 1 07:11:35 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16089 for ; Fri, 1 Mar 2002 07:11:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16glkB-0007A1-00 for namedroppers-data@psg.com; Fri, 01 Mar 2002 04:02:35 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.35 #1) id 16glk9-00079u-00 for namedroppers@ops.ietf.org; Fri, 01 Mar 2002 04:02:34 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12854; Fri, 1 Mar 2002 07:02:29 -0500 (EST) Message-Id: <200203011202.HAA12854@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-09.txt Date: Fri, 01 Mar 2002 07:02:29 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Link-Local Multicast Name Resolution (LLMNR) Author(s) : L. Esibov, B. Aboba, D. Thaler Filename : draft-ietf-dnsext-mdns-09.txt Pages : 16 Date : 28-Feb-02 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 name resolution in such environments, Link-Local Multicast Name Resolution (LLMNR) is proposed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-09.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-09.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-09.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: <20020228134259.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020228134259.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 1 07:11:46 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16141 for ; Fri, 1 Mar 2002 07:11:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16glkF-0007AN-00 for namedroppers-data@psg.com; Fri, 01 Mar 2002 04:02:39 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.35 #1) id 16glkE-0007AE-00 for namedroppers@ops.ietf.org; Fri, 01 Mar 2002 04:02:38 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12887; Fri, 1 Mar 2002 07:02:34 -0500 (EST) Message-Id: <200203011202.HAA12887@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-dns-threats-01.txt Date: Fri, 01 Mar 2002 07:02:33 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Threat Analysis Of The Domain Name System Author(s) : D. Atkins, R. Austein Filename : draft-ietf-dnsext-dns-threats-01.txt Pages : 12 Date : 28-Feb-02 Although the DNS Security Extensions (DNSSEC) have been under development for most of the last decade, the IETF has never written down the specific set of threats against which DNSSEC is designed to protect. Among other drawbacks, this cart-before-the-horse situation has made it difficult to determine whether DNSSEC meets its design goals, since its design goals are not well specified. This note attempts to document some of the known threats to the DNS, and, in doing so, attempts to measure to what extent (if any) DNSSEC is a useful tool in defending against these threats. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-threats-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dns-threats-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dns-threats-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020228134315.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dns-threats-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dns-threats-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020228134315.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 5 06:38:58 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24703 for ; Tue, 5 Mar 2002 06:38:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16iCyX-0003n0-00 for namedroppers-data@psg.com; Tue, 05 Mar 2002 03:19:21 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.35 #1) id 16iCyV-0003mY-00 for namedroppers@ops.ietf.org; Tue, 05 Mar 2002 03:19:20 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23276; Tue, 5 Mar 2002 06:19:15 -0500 (EST) Message-Id: <200203051119.GAA23276@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-delegation-signer-06.txt Date: Tue, 05 Mar 2002 06:19:14 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Delegation Signer Resource Record Author(s) : O. Gudmundsson Filename : draft-ietf-dnsext-delegation-signer-06.txt Pages : 14 Date : 04-Mar-02 The delegation signer (DS) resource record is inserted at a zone cut (i.e., a delegation point) to indicate that the delegated zone is digitally signed and that the delegated zone recognizes the indicated key as a valid zone key for the delegated zone. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-delegation-signer-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-delegation-signer-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-delegation-signer-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: <20020304133251.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-delegation-signer-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-delegation-signer-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020304133251.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 5 07:04:33 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25416 for ; Tue, 5 Mar 2002 07:04:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16iDVW-0005bs-00 for namedroppers-data@psg.com; Tue, 05 Mar 2002 03:53:26 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.35 #1) id 16iDVV-0005bV-00 for namedroppers@ops.ietf.org; Tue, 05 Mar 2002 03:53:25 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25136; Tue, 5 Mar 2002 06:53:23 -0500 (EST) Message-Id: <200203051153.GAA25136@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-kitamura-ipv6-name-auto-reg-01.txt Date: Tue, 05 Mar 2002 06:53:23 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Domain Name Auto-Registration for Plugged-in IPv6 Nodes Author(s) : H. Kitamura Filename : draft-kitamura-ipv6-name-auto-reg-01.txt Pages : 19 Date : 04-Mar-02 This document describes a scheme of 'Domain Name Auto-Registration for Plugged-in IPv6 Nodes' mechanism that makes it possible to register both regular and inverse domain name information of plugged- in IPv6 nodes to DNS servers automatically. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kitamura-ipv6-name-auto-reg-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-kitamura-ipv6-name-auto-reg-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-kitamura-ipv6-name-auto-reg-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020304140931.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kitamura-ipv6-name-auto-reg-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-kitamura-ipv6-name-auto-reg-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020304140931.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 5 09:11:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00620 for ; Tue, 5 Mar 2002 09:11:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16iFVQ-000Ciw-00 for namedroppers-data@psg.com; Tue, 05 Mar 2002 06:01:28 -0800 Received: from is1-50.antd.nist.gov ([129.6.50.251]) by psg.com with esmtp (Exim 3.35 #1) id 16iFVP-000Cif-00 for namedroppers@ops.ietf.org; Tue, 05 Mar 2002 06:01:27 -0800 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by is1-50.antd.nist.gov (8.9.3/8.9.3) with SMTP id JAA27109; Tue, 5 Mar 2002 09:01:24 -0500 (EST) Message-ID: <005b01c1c44d$81ab5620$b9370681@antd.nist.gov> From: "Scott Rose" To: "DNSEXT WG Mailing list" , "Olafur Gudmundsson" Subject: DS key digest question Date: Tue, 5 Mar 2002 08:56:10 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I was reading over the new Delegation Signer RR draft, and I like the inclusion of how explicit query for DS is handled by the parent delegator. I have a question about how the digest is computed. From Section 2.4.1, it says the KEY name and key data are used as the input to the hash function. Are these the only fields to be used? And how is the digest computed? I am assuming: digest = hash (KEY_RR_name | public_key_material ) where "|" is concatenation. It might be a good idea to pull this out and put it as a paragraph on its own for clarity. Scott =============================================================== Scott Rose Advanced Network Technologies Division NIST ph: 301-975-8439 fax: 301-590-0932 http://www.antd.nist.gov/proj/dnssec =============================================================== -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 5 15:22:59 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25711 for ; Tue, 5 Mar 2002 15:22:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16iL82-000BPk-00 for namedroppers-data@psg.com; Tue, 05 Mar 2002 12:01:42 -0800 Received: from spratly.wl.nominum.com ([128.177.195.135] helo=spratly.nominum.com) by psg.com with esmtp (Exim 3.35 #1) id 16iL81-000BPK-00 for namedroppers@ops.ietf.org; Tue, 05 Mar 2002 12:01:42 -0800 Received: from localhost (bwelling@localhost) by spratly.nominum.com (8.11.6/8.11.6) with ESMTP id g25K1g625435 for ; Tue, 5 Mar 2002 12:01:43 -0800 X-Authentication-Warning: spratly.nominum.com: bwelling owned process doing -bs Date: Tue, 5 Mar 2002 12:01:42 -0800 (PST) From: Brian Wellington X-X-Sender: To: Subject: new DS draft question Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The new draft contains the following text: An authoritative server queried for type DS MUST return the DS RRset in the answer section along with the corresponding NXT RRset in the authority section. If the server is authoritative for both parent and child zones, the answer MUST be from the parent. A caching server MUST behave the same way, returning the DS RRset and the parent's NXT RRset, if records are available. I don't understand why the NXT record is returned on a successful query. The querying server needs only the DS record and its signatures to continue on the validation process, and including an NXT record in the authority section makes this look confusingly like a negative response. Is there a reason for doing this? I also don't fully understand why the NXT needs to be present in referrals to secure zones (the DS is already there, and all that's needed), but that's another story. Brian -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 5 22:55:27 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14818 for ; Tue, 5 Mar 2002 22:55:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16iSFn-000EzC-00 for namedroppers-data@psg.com; Tue, 05 Mar 2002 19:38:11 -0800 Received: from 208-59-114-172.c3-0.129-ubr1.lnh-129.md.cable.rcn.com ([208.59.114.172] helo=ogud.com) by psg.com with esmtp (Exim 3.35 #1) id 16iSFm-000Ez6-00 for namedroppers@ops.ietf.org; Tue, 05 Mar 2002 19:38:10 -0800 Received: from oemcomputer.ogud.com (mail.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id g263bgk20184; Tue, 5 Mar 2002 22:37:42 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <5.1.0.14.2.20020305221329.02cab100@localhost> X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 05 Mar 2002 22:32:11 -0500 To: Brian Wellington , From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: new DS draft question In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 03:01 PM 3/5/2002, Brian Wellington wrote: >The new draft contains the following text: > > An authoritative server queried for type DS MUST return the DS RRset > in the answer section along with the corresponding NXT RRset in the > authority section. If the server is authoritative for both parent > and child zones, the answer MUST be from the parent. A caching > server MUST behave the same way, returning the DS RRset and the > parent's NXT RRset, if records are available. > >I don't understand why the NXT record is returned on a successful query. >The querying server needs only the DS record and its signatures to >continue on the validation process, and including an NXT record in the >authority section makes this look confusingly like a negative response. >Is there a reason for doing this? This was covered on the namedroppers mailing list thread "DS design questions" stared on January 2. This was question 3. The people that commented on this question (including yourself) all said/implied send back both. The main reason DS is specified this was: Provide a paranoid resolver with everything it needs in the first answer. DS can only reside at a delegation, the only way to prove this is a delegation is to check the bits in the upper NXT. I agree, this is confusing to resolvers (as a matter of fact one resolver that I have been playing with takes the upper NXT and uses it to prove that the name/type requested does not exist). Do we need some rules on when NXT is to be considered negative answer and when it is supplied to assist in security proofs ? >I also don't fully understand why the NXT needs to be present in referrals >to secure zones (the DS is already there, and all that's needed), but >that's another story. See above about paranoid security aware resolvers. The WG needs feedback from resolver writers if this is help- or harmful. I personally have no problem changing the ID to reflect what is best for the protocol. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 5 22:55:39 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14837 for ; Tue, 5 Mar 2002 22:55:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16iSFv-000EzL-00 for namedroppers-data@psg.com; Tue, 05 Mar 2002 19:38:19 -0800 Received: from 208-59-114-172.c3-0.129-ubr1.lnh-129.md.cable.rcn.com ([208.59.114.172] helo=ogud.com) by psg.com with esmtp (Exim 3.35 #1) id 16iSFu-000EzF-00 for namedroppers@ops.ietf.org; Tue, 05 Mar 2002 19:38:18 -0800 Received: from oemcomputer.ogud.com (mail.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id g263bik20187; Tue, 5 Mar 2002 22:37:52 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <5.1.0.14.2.20020305223222.02c84040@localhost> X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 05 Mar 2002 22:35:15 -0500 To: "Scott Rose" , "DNSEXT WG Mailing list" From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: DS key digest question In-Reply-To: <005b01c1c44d$81ab5620$b9370681@antd.nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 08:56 AM 3/5/2002, Scott Rose wrote: >I was reading over the new Delegation Signer RR draft, and I like the >inclusion of how explicit query for DS is handled by the parent delegator. >I have a question about how the digest is computed. From Section 2.4.1, it >says the KEY name and key data are used as the input to the hash function. >Are these the only fields to be used? > >And how is the digest computed? I am assuming: > >digest = hash (KEY_RR_name | public_key_material ) where "|" is >concatenation. > >It might be a good idea to pull this out and put it as a paragraph on its >own for clarity. Thanks for the comment, the data to be digested is canonical domain name | KEY_RR rdata the rdata consists of flags, alg, protocol and public key Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 6 06:33:31 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01908 for ; Wed, 6 Mar 2002 06:33:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16iZS7-0003ay-00 for namedroppers-data@psg.com; Wed, 06 Mar 2002 03:19:23 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.35 #1) id 16iZS6-0003as-00 for namedroppers@ops.ietf.org; Wed, 06 Mar 2002 03:19:22 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01248; Wed, 6 Mar 2002 06:19:16 -0500 (EST) Message-Id: <200203061119.GAA01248@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-axfr-clarify-04.txt Date: Wed, 06 Mar 2002 06:19:16 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNS Zone Transfer Protocol Clarifications Author(s) : A. Gustafsson Filename : draft-ietf-dnsext-axfr-clarify-04.txt Pages : 7 Date : 05-Mar-02 In the Domain Name System, zone data is replicated among authoritative DNS servers by means of the 'zone transfer' protocol, also known as the 'AXFR' protocol. This memo clarifies, updates, and adds missing detail to the original AXFR protocol specification in RFC1034. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-axfr-clarify-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-axfr-clarify-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-axfr-clarify-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020305134057.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-axfr-clarify-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-axfr-clarify-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020305134057.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 6 07:25:10 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01909 for ; Wed, 6 Mar 2002 06:33:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16iZS2-0003aq-00 for namedroppers-data@psg.com; Wed, 06 Mar 2002 03:19:18 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.35 #1) id 16iZS1-0003ak-00 for namedroppers@ops.ietf.org; Wed, 06 Mar 2002 03:19:17 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01236; Wed, 6 Mar 2002 06:19:12 -0500 (EST) Message-Id: <200203061119.GAA01236@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-intro-01.txt Date: Wed, 06 Mar 2002 06:19:12 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNS Security Introduction and Requirements Author(s) : R. Arends, M. Larson, D. Massey, S. Rose Filename : draft-ietf-dnsext-dnssec-intro-01.txt Pages : 21 Date : 05-Mar-02 The Domain Name System Security Extensions (DNSSEC) provide data origin authentication and data integrity. This document introduces these extensions and describes their capabilities and limitations. The services that the security extensions provide and do not provide are discussed. Lastly, the group of documents that describe the DNS security extensions and their interrelationships is discussed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-intro-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-intro-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-intro-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020305134044.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-intro-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-intro-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020305134044.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 6 21:49:16 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24017 for ; Wed, 6 Mar 2002 21:49:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16ina4-000GFW-00 for namedroppers-data@psg.com; Wed, 06 Mar 2002 18:24:32 -0800 Received: from spratly.wl.nominum.com ([128.177.195.135] helo=spratly.nominum.com) by psg.com with esmtp (Exim 3.35 #1) id 16ina3-000GFQ-00 for namedroppers@ops.ietf.org; Wed, 06 Mar 2002 18:24:31 -0800 Received: from localhost (bwelling@localhost) by spratly.nominum.com (8.11.6/8.11.6) with ESMTP id g272OMZ08705; Wed, 6 Mar 2002 18:24:23 -0800 X-Authentication-Warning: spratly.nominum.com: bwelling owned process doing -bs Date: Wed, 6 Mar 2002 18:24:22 -0800 (PST) From: Brian Wellington X-X-Sender: To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= cc: Subject: Re: new DS draft question In-Reply-To: <5.1.0.14.2.20020305221329.02cab100@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8BIT On Tue, 5 Mar 2002, Ólafur Guðmundsson wrote: > At 03:01 PM 3/5/2002, Brian Wellington wrote: > >The new draft contains the following text: > > > > An authoritative server queried for type DS MUST return the DS RRset > > in the answer section along with the corresponding NXT RRset in the > > authority section. If the server is authoritative for both parent > > and child zones, the answer MUST be from the parent. A caching > > server MUST behave the same way, returning the DS RRset and the > > parent's NXT RRset, if records are available. > > > >I don't understand why the NXT record is returned on a successful query. > >The querying server needs only the DS record and its signatures to > >continue on the validation process, and including an NXT record in the > >authority section makes this look confusingly like a negative response. > >Is there a reason for doing this? > > This was covered on the namedroppers mailing list thread "DS design > questions" stared on January 2. This was question 3. The people that > commented on this question (including yourself) all said/implied send > back both. Hmm. I don't remember intending to say that, but looking back, I was not all that clear. I was trying to say that if DS/NXT records are returned, they should be in the authority section. I remember wondering why the NXT was needed in a secure referral, but not caring enough to ask. > The main reason DS is specified this was: > Provide a paranoid resolver with everything it needs in the first answer. Seems reasonable for referrals. I don't think adding the NXT in answers is useful, though. > DS can only reside at a delegation, the only way to prove this is a > delegation is to check the bits in the upper NXT. I guess this is true, but it seems unimportant. If the DS validates, it should be an indication that the name is a delegation. Otherwise, the parent zone is confused, and things won't work anyway. To prove that it's an insecure delegation involves the NXT, but to prove that it's a secure delegation only needs the DS. > I agree, this is confusing to resolvers (as a matter of fact one resolver that > I have been playing with takes the upper NXT and uses it to prove that > the name/type requested does not exist). > > Do we need some rules on when NXT is to be considered negative answer and > when it is supplied to assist in security proofs ? Maybe. Adding NXTs to non-negative answers is already dangerous, and this might make non-answer processing even closer to impossible. > >I also don't fully understand why the NXT needs to be present in referrals > >to secure zones (the DS is already there, and all that's needed), but > >that's another story. > > See above about paranoid security aware resolvers. > The WG needs feedback from resolver writers if this is help- or harmful. > I personally have no problem changing the ID to reflect what is best > for the protocol. This seriously breaks at least one resolver (BIND 9), which treats DS-enabled referrals as negative answers. It's unclear whether this is a bug or a case of reasonable behavior that no longer works. Brian -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 7 06:39:53 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17675 for ; Thu, 7 Mar 2002 06:39:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16ivwd-000Bxg-00 for namedroppers-data@psg.com; Thu, 07 Mar 2002 03:20:23 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.35 #1) id 16ivwb-000Bxa-00 for namedroppers@ops.ietf.org; Thu, 07 Mar 2002 03:20:22 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16905; Thu, 7 Mar 2002 06:20:16 -0500 (EST) Message-Id: <200203071120.GAA16905@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-ipv6-addresses-01.txt Date: Thu, 07 Mar 2002 06:20:16 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Representing IPv6 addresses in DNS Author(s) : R. Bush, A. Durand, B. Fink, O. Gudmundsson, T. Hain Filename : draft-ietf-dnsext-ipv6-addresses-01.txt Pages : 6 Date : 06-Mar-02 This document clarifies and updates the standards status of RFCs that define direct and reverse map of IPv6 addresses in DNS. This document moves the A6 and Bit label specifications to experimental status. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ipv6-addresses-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-ipv6-addresses-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-ipv6-addresses-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020306142107.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-ipv6-addresses-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-ipv6-addresses-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020306142107.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 7 07:36:13 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20293 for ; Thu, 7 Mar 2002 07:36:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16iwyC-000Efq-00 for namedroppers-data@psg.com; Thu, 07 Mar 2002 04:26:04 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.35 #1) id 16iwyB-000Efc-00 for namedroppers@ops.ietf.org; Thu, 07 Mar 2002 04:26:03 -0800 Received: from localhost (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id E4AFD3190E for ; Thu, 7 Mar 2002 04:26:01 -0800 (PST) Date: Thu, 7 Mar 2002 13:28:36 +0100 (CET) From: Roy Arends X-X-Sender: To: Subject: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-01.txt In-Reply-To: <200203071120.GAA16905@ietf.org> Message-ID: <20020307125951.J2674-100000@node10c4d.a2000.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > 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. Either move 2672 (DNAME) to experimental or not. Deprecating DNAME RR usage in the reverse tree implies that forward/reverse are technically different. They are not. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 7 09:07:35 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25062 for ; Thu, 7 Mar 2002 09:07:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16iyP6-000IW5-00 for namedroppers-data@psg.com; Thu, 07 Mar 2002 05:57:56 -0800 Received: from 208-59-114-172.c3-0.129-ubr1.lnh-129.md.cable.rcn.com ([208.59.114.172] helo=ogud.com) by psg.com with esmtp (Exim 3.35 #1) id 16iyP5-000IVp-00 for namedroppers@ops.ietf.org; Thu, 07 Mar 2002 05:57:55 -0800 Received: from localhost (ogud@localhost) by ogud.com (8.11.6/8.11.6) with ESMTP id g27DvIf24210; Thu, 7 Mar 2002 08:57:18 -0500 (EST) (envelope-from ogud@ogud.com) Date: Thu, 7 Mar 2002 08:57:18 -0500 (EST) From: Olafur Gudmundsson X-X-Sender: ogud@hlid.dc.ogud.com To: Roy Arends cc: DNSEXT mailing list Subject: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-01.txt In-Reply-To: <20020307125951.J2674-100000@node10c4d.a2000.nl> Message-ID: <20020307085522.C24205-100000@hlid.dc.ogud.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 7 Mar 2002, Roy Arends wrote: > > 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. > > Either move 2672 (DNAME) to experimental or not. Deprecating DNAME RR > usage in the reverse tree implies that forward/reverse are technically > different. They are not. > The reason for not changing the status of DNAME is that there might be other uses for DNAME than just supporting the reverse lookup. Thus moving DNAME off the standards track is a larger question than just for IPv6 addresses. Lets do one thing at the time. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 7 09:58:26 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28098 for ; Thu, 7 Mar 2002 09:58:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16izC4-000KjL-00 for namedroppers-data@psg.com; Thu, 07 Mar 2002 06:48:32 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.35 #1) id 16izC4-000KjF-00 for namedroppers@ops.ietf.org; Thu, 07 Mar 2002 06:48:32 -0800 Received: from localhost (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 7D1B53190E; Thu, 7 Mar 2002 06:48:30 -0800 (PST) Date: Thu, 7 Mar 2002 15:51:06 +0100 (CET) From: Roy Arends X-X-Sender: To: Olafur Gudmundsson Cc: Roy Arends , DNSEXT mailing list Subject: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-01.txt In-Reply-To: <20020307085522.C24205-100000@hlid.dc.ogud.com> Message-ID: <20020307151737.I2674-100000@node10c4d.a2000.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 7 Mar 2002, Olafur Gudmundsson wrote: > On Thu, 7 Mar 2002, Roy Arends wrote: > > > > 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. > > > > Either move 2672 (DNAME) to experimental or not. Deprecating DNAME RR > > usage in the reverse tree implies that forward/reverse are technically > > different. They are not. > > > > The reason for not changing the status of DNAME is that there might > be other uses for DNAME than just supporting the reverse lookup. > Thus moving DNAME off the standards track is a larger question than > just for IPv6 addresses. Then please rephrase that part. The draft currently states that "the intent of the document is that use of DNAME RRs in the reverse tree be deprecated." which is IMHO not the same as "just for IPv6 addresses". > Lets do one thing at the time. Then please remove the disputatious premature suggestion. Regards, Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 7 11:16:13 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03766 for ; Thu, 7 Mar 2002 11:16:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16j0Mi-000Lzj-00 for namedroppers-data@psg.com; Thu, 07 Mar 2002 08:03:36 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.35 #1) id 16j0Mh-000Lzd-00 for namedroppers@ops.ietf.org; Thu, 07 Mar 2002 08:03:35 -0800 Received: from randy by rip.psg.com with local (Exim 4.00) id 16j0Mh-000AaE-00; Thu, 07 Mar 2002 08:03:35 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Olafur Gudmundsson Cc: DNSEXT mailing list Subject: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-01.txt References: <20020307125951.J2674-100000@node10c4d.a2000.nl> <20020307085522.C24205-100000@hlid.dc.ogud.com> Message-Id: Date: Thu, 07 Mar 2002 08:03:35 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The reason for not changing the status of DNAME is that there might > be other uses for DNAME than just supporting the reverse lookup. there *might* be reasons to keep nuclear weapons in your home. there *might* be reasons to eat broccoli. YAGNI and randy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 8 12:41:21 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19615 for ; Fri, 8 Mar 2002 12:41:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16jNs0-0005hT-00 for namedroppers-data@psg.com; Fri, 08 Mar 2002 09:09:28 -0800 Received: from 208-59-114-172.c3-0.129-ubr1.lnh-129.md.cable.rcn.com ([208.59.114.172] helo=ogud.com) by psg.com with esmtp (Exim 3.35 #1) id 16jNrz-0005hM-00 for namedroppers@ops.ietf.org; Fri, 08 Mar 2002 09:09:27 -0800 Received: from oemcomputer.ogud.com (ns.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id g28H9ee02818; Fri, 8 Mar 2002 12:09:40 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <5.1.0.14.2.20020308100621.00a5d7b0@localhost> X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 08 Mar 2002 11:40:26 -0500 To: Brian Wellington From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: new DS draft question Cc: In-Reply-To: References: <5.1.0.14.2.20020305221329.02cab100@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA19615 At 09:24 PM 3/6/2002, Brian Wellington wrote: >On Tue, 5 Mar 2002, Ólafur Guðmundsson wrote: > > > This was covered on the namedroppers mailing list thread "DS design > > questions" stared on January 2. This was question 3. The people that > > commented on this question (including yourself) all said/implied send > > back both. > >Hmm. I don't remember intending to say that, but looking back, I was not >all that clear. I was trying to say that if DS/NXT records are returned, >they should be in the authority section. I remember wondering why the NXT >was needed in a secure referral, but not caring enough to ask. > > > The main reason DS is specified this was: > > Provide a paranoid resolver with everything it needs in the first answer. > >Seems reasonable for referrals. I don't think adding the NXT in answers >is useful, though. > > > DS can only reside at a delegation, the only way to prove this is a > > delegation is to check the bits in the upper NXT. > >I guess this is true, but it seems unimportant. If the DS validates, it >should be an indication that the name is a delegation. Otherwise, the >parent zone is confused, and things won't work anyway. To prove that it's >an insecure delegation involves the NXT, but to prove that it's a secure >delegation only needs the DS. Correct. > > I agree, this is confusing to resolvers (as a matter of fact one > resolver that > > I have been playing with takes the upper NXT and uses it to prove that > > the name/type requested does not exist). > > > > Do we need some rules on when NXT is to be considered negative answer and > > when it is supplied to assist in security proofs ? > >Maybe. Adding NXTs to non-negative answers is already dangerous, and this >might make non-answer processing even closer to impossible. After looking through RFC2535 (and RFC2065) there is nothing said that server [MAY, SHOULD, MUST] NOT put NXT in positive answer so it was only a question of time before someone did this :-). Q1: Is there any practical use for NXT in any positive answer ? Possible Answer: For any signed data there is no need for resolver to check NXT unless signature FAILS crypto check, thus NXT should never be sent with positive answer where the data in answer section is signed. This leaves the case of referral as the NS at delegation is unsigned, the presence of the NS bit in the NXT and the absence of the SOA bit proves there is a delegation at this name. (given how hard it can be for resolvers to get the parent NXT). Q: Is there need to formalize that NXT MUST/SHOULD NOT be returned when there are signed records in the answer or authority section? Q2: Does this affect Opt-in ? > >I also don't fully understand why the NXT needs to be present in referrals > > See above about paranoid security aware resolvers. > > The WG needs feedback from resolver writers if this is help- or harmful. > > I personally have no problem changing the ID to reflect what is best > > for the protocol. > >This seriously breaks at least one resolver (BIND 9), which treats >DS-enabled referrals as negative answers. It's unclear whether this is a >bug or a case of reasonable behavior that no longer works. DS breaks it already, so what is little bit more of breakage :-) But this behavior is a bug, if the resolver deducts from the upper NXT that no answer is possible. All resolvers must be able to determine if the NXT is material and relevant, and ignore NXT records that are not. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 8 13:33:52 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23048 for ; Fri, 8 Mar 2002 13:33:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16jOv9-0006sM-00 for namedroppers-data@psg.com; Fri, 08 Mar 2002 10:16:47 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.35 #1) id 16jOv9-0006sG-00 for namedroppers@ops.ietf.org; Fri, 08 Mar 2002 10:16:47 -0800 Received: from randy by rip.psg.com with local (Exim 4.00) id 16jOv8-000LOR-00 for namedroppers@ops.ietf.org; Fri, 08 Mar 2002 10:16:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200203081752.JAA11706@gulag.araneus.fi> In-Reply-To: <5.1.0.14.2.20020308100621.00a5d7b0@localhost> References: <5.1.0.14.2.20020305221329.02cab100@localhost> <5.1.0.14.2.20020308100621.00a5d7b0@localhost> Date: Fri, 8 Mar 2002 09:52:54 -0800 (PST) To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Cc: Brian Wellington , Subject: Re: new DS draft question From: gson@nominum.com (Andreas Gustafsson) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber ] ogud@ogud.com writes: > Q1: Is there any practical use for NXT in any positive answer ? There is not only a use, but a requirement. RFC2535 section 5.3 says that wildcard expansions (which are positive answers) MUST have NXTs: 5.3 Additional Complexity Due to Wildcards [...] Furthermore, if a wildcard expansion is returned in a response, in general one or more NXTs needs to also be returned in the authority section to prove that no more specific name (including possibly more specific wildcards in the zone) existed on which the response should have been based. -- Andreas Gustafsson, gson@nominum.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 11 05:06:13 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03080 for ; Mon, 11 Mar 2002 05:06:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16kMPD-00097u-00 for namedroppers-data@psg.com; Mon, 11 Mar 2002 01:47:47 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.35 #1) id 16kMPC-00097o-00 for namedroppers@ops.ietf.org; Mon, 11 Mar 2002 01:47:46 -0800 Received: from x50 (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.11.6/8.11.6) with SMTP id g2B9lg016752; Mon, 11 Mar 2002 10:47:42 +0100 Date: Mon, 11 Mar 2002 10:47:42 +0100 From: "Olaf M. Kolkman" To: Roy Arends Cc: namedroppers@ops.ietf.org Subject: Re: Another NEW technical argument for Opt-In. Message-Id: <20020311104742.77122eee.olaf@ripe.net> In-Reply-To: <20020227112239.P37547-100000@node10c4d.a2000.nl> References: <20020227112239.P37547-100000@node10c4d.a2000.nl> Organization: RIPE NCC X-Mailer: Sylpheed version 0.7.0 (GTK+ 1.2.9; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 27 Feb 2002 11:39:44 +0100 (CET) Roy Arends wrote: > The current requirements and complexity due to wildcards are: > > (1) If the response is to be a NXDOMAIN response, the current requirement > is to include authenticated denial (NXT) of wildcards for every > intermediate label level. > > (2) If the response is to be an expanded wildcard, the current requirement > is to include authenticated denial for a "closer wildcard match" and > authenticated denial of QNAME. > I have always interpreted thing different, could you give me a reference on how you came to this conclussion. I would like to confirm that my thinking is wrong. > Opt-In can be used as a method to satisfy both sides of the wildcard > issue. Opt-In allows for unsigned nodes in a secured zone, and in this > particular case, wildcards can be left unsigned in a secure zone, and the > requirement (1) and (2) can optionally be dropped by means of a new > proposal. Hmmm (again :-) ) Is that not the wrong solution to the problem. If you want to secure wildcards in the DNS you should not just exclude them. In another message you wrote: > We (opt-in authors) expressed individually, separately on this list > our thoughts about "only allow opting out of ns delegations" which > generated no comments from the wg. IMHO only allow opting out of > _unsecure_ ns delegations (instead of allowing any RRset to opt > out), has still not seen a _technical_ argument _for_ it. The 'restrict opt-in to delegations only' is an _operational_ argument; _operational_ arguments are as valid as _technical_ arguments. Besides silence should not be mistaken with consensus. --Olaf --------------------------------------------| Olaf M. Kolkman | www.ripe.net/disi -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 11 06:23:16 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04764 for ; Mon, 11 Mar 2002 06:23:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16kNkn-000AQi-00 for namedroppers-data@psg.com; Mon, 11 Mar 2002 03:14:09 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.35 #1) id 16kNkm-000AQb-00 for namedroppers@ops.ietf.org; Mon, 11 Mar 2002 03:14:08 -0800 Received: from localhost (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id C97273190D; Mon, 11 Mar 2002 03:14:06 -0800 (PST) Date: Mon, 11 Mar 2002 12:17:40 +0100 (CET) From: Roy Arends X-X-Sender: To: "Olaf M. Kolkman" Cc: Subject: Re: Another NEW technical argument for Opt-In. In-Reply-To: <20020311104742.77122eee.olaf@ripe.net> Message-ID: <20020311105901.N9362-100000@node10c4d.a2000.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 11 Mar 2002, Olaf M. Kolkman wrote: > On Wed, 27 Feb 2002 11:39:44 +0100 (CET) > Roy Arends wrote: > > > > The current requirements and complexity due to wildcards are: > > > > (1) If the response is to be a NXDOMAIN response, the current requirement > > is to include authenticated denial (NXT) of wildcards for every > > intermediate label level. > > > > (2) If the response is to be an expanded wildcard, the current requirement > > is to include authenticated denial for a "closer wildcard match" and > > authenticated denial of QNAME. > > > > > I have always interpreted thing different, could you give me a > reference on how you came to this conclussion. I would like to confirm > that my thinking is wrong. RFC2535: 5.3 Additional Complexity Due to Wildcards Proving that a non-existent name response is correct or that a wildcard expansion response is correct makes things a little more complex. In particular, when a non-existent name response is returned, an NXT must be returned showing that the exact name queried did not exist and, in general, one or more additional NXT's need to be returned to also prove that there wasn't a wildcard whose expansion should have been returned. (There is no need to return multiple copies of the same NXT.) These NXTs, if any, are returned in the authority section of the response. Furthermore, if a wildcard expansion is returned in a response, in general one or more NXTs needs to also be returned in the authority section to prove that no more specific name (including possibly more specific wildcards in the zone) existed on which the response should have been based. This was where my interpretation was based upon. Since I don't know what your interpretation is, I can not confirm your current thinking is wrong. > > Opt-In can be used as a method to satisfy both sides of the wildcard > > issue. Opt-In allows for unsigned nodes in a secured zone, and in this > > particular case, wildcards can be left unsigned in a secure zone, and the > > requirement (1) and (2) can optionally be dropped by means of a new > > proposal. > > Hmmm (again :-) ) Is that not the wrong solution to the problem. If > you want to secure wildcards in the DNS you should not just exclude > them. There was some discussion on the additional complexity due to wildcards. In short: much work, little gain, which lead me to another case where Opt-In is useful: leave cruft unsigned while using DNSSEC. In this case: wildcards. Now, if you want to _secure_ wildcards in the DNS, this is obviously not a solution you want. Nor is there an implementation that supports it yet. If you want to use wildcards in DNSSEC, opt-in allows you to do that. > In another message you wrote: > > We (opt-in authors) expressed individually, separately on this list > > our thoughts about "only allow opting out of ns delegations" which > > generated no comments from the wg. IMHO only allow opting out of > > _unsecure_ ns delegations (instead of allowing any RRset to opt > > out), has still not seen a _technical_ argument _for_ it. > > The 'restrict opt-in to delegations only' is an _operational_ > argument; _operational_ arguments are as valid as _technical_ > arguments. Can you state the _operational_ arguments for 'restrict opt-in to delagations only' ? That was I was looking for ! > Besides silence should not be mistaken with consensus. I'm not subjected to false consensus bias or conjecture by the mere absence of valid arguments on restricting opt-in, I simply noted the absence of arguments. As said before, lets not throw mud. Roy Arends Nominum -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 11 06:54:51 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05325 for ; Mon, 11 Mar 2002 06:54:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16kOFi-000At3-00 for namedroppers-data@psg.com; Mon, 11 Mar 2002 03:46:06 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.35 #1) id 16kOFg-000Asw-00 for namedroppers@ops.ietf.org; Mon, 11 Mar 2002 03:46:05 -0800 Received: from x50 (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.11.6/8.11.6) with SMTP id g2BBk0021644; Mon, 11 Mar 2002 12:46:00 +0100 Date: Mon, 11 Mar 2002 12:46:00 +0100 From: "Olaf M. Kolkman" To: Roy Arends Cc: namedroppers@ops.ietf.org Subject: Re: Another NEW technical argument for Opt-In. Message-Id: <20020311124600.5dccf8b0.olaf@ripe.net> In-Reply-To: <20020311105901.N9362-100000@node10c4d.a2000.nl> References: <20020311104742.77122eee.olaf@ripe.net> <20020311105901.N9362-100000@node10c4d.a2000.nl> Organization: RIPE NCC X-Mailer: Sylpheed version 0.7.0 (GTK+ 1.2.9; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 11 Mar 2002 12:17:40 +0100 (CET) Roy Arends wrote: > Can you state the _operational_ arguments for 'restrict opt-in to > delagations only' ? That was I was looking for ! http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg00104.html and other messages. Abstract: Introducing granularity of security will make troubleshooting verifiers harder. One moves the burden away from the servers to the clients. I am afraid that we will follow a path where end users cannot be bothered to set up verifying resolvers since only the www.bla.foos in the world are signed and the costs of maintaining is just to high. I realize these are not the strongest argument so I do not want to be orthodox about them. However, I still wonder why the original designers choose to work with the concept of secure zones instead of secure names. --------------------------------------------| Olaf M. Kolkman | www.ripe.net/disi -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 12 00:08:26 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07146 for ; Tue, 12 Mar 2002 00:08:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16keBy-0001Lg-00 for namedroppers-data@psg.com; Mon, 11 Mar 2002 20:47:18 -0800 Received: from 208-59-114-172.c3-0.129-ubr1.lnh-129.md.cable.rcn.com ([208.59.114.172] helo=ogud.com) by psg.com with esmtp (Exim 3.35 #1) id 16keBx-0001La-00 for namedroppers@ops.ietf.org; Mon, 11 Mar 2002 20:47:17 -0800 Received: from localhost (ogud@localhost) by ogud.com (8.11.6/8.11.6) with ESMTP id g2C4l9d22684; Mon, 11 Mar 2002 23:47:09 -0500 (EST) (envelope-from ogud@ogud.com) Date: Mon, 11 Mar 2002 23:47:09 -0500 (EST) From: Olafur Gudmundsson X-X-Sender: ogud@hlid.dc.ogud.com To: DNSEXT mailing list cc: agenda@ietf.org Subject: DNSEXT IETF-53 Agenda Message-ID: <20020311234608.P22678-100000@hlid.dc.ogud.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk DNS Extensions WG (dnsext) @ IETF-53 Monday, 2002/March/18 at 9:00-11:30 ================================ Chairs: Randy Bush Olafur Gudmundsson Agenda bashing Olafur Gudmundsson WG status Olafur Gudmundsson Dynamic update workshop report Jakob Schlyter http://ops.ietf.org/dns/dynupd/secure-ddns-howto.html DNSSEC rewrite o description of document set Scott Rose http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-threats-01.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-intro-01.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-records-00.txt o any protocol issues with agreed dnssec items - ds status Olafur Gudmundsson http://www.ietf.org/internet-drafts/draft-ietf-dnsext-delegation-signer-06.txt - restrict key Dan Massey http://www.ietf.org/internet-drafts/draft-ietf-dnsext-restrict-key-for-dnssec-01.txt - ad is secure Brian Wellington http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ad-is-secure-04.txt - KEY alg documents Donald Eastlake http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2536bis-dsa-01.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2539bis-dhk-01.txt IPv6 topics and DNS configuration: IPv6 addresses last call issues discussion: Randy Bush http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ipv6-addresses-01.txt 6to4 and DNS Keith More http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-6to4-dns-00.txt Using DHCPv6 for DNS configuration in Hosts Ralph Droms http://www.ietf.org/internet-drafts/draft-droms-dnsconfig-dhcpv6-01.txt Domain Name Auto-Registration for Plugged-in IPv6 Nodes H. Kitamura http://www.ietf.org/internet-drafts/draft-kitamura-ipv6-name-auto-reg-01.txt MDNS update Levon Esibov http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-09.txt DNSSEC open o Opt-in Roy Arends http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-opt-in-01.txt WG charter and future ? Randy Bush http://www.ietf.org/html.charters/dnsext-charter.html Plug for the SPIKED BOF Jacob Schlyter http://www.ietf.org/ietf/02mar/siked.txt Plug for DNSSEC provreg document Scott Hollenbeck http://www.ietf.org/internet-drafts/draft-hollenbeck-epp-secdns-00.txt Plug for dnsop agenda Lars Johann-Liman/Ray Plzak -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 13 10:41:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08463 for ; Wed, 13 Mar 2002 10:41:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16lAVf-000DTx-00 for namedroppers-data@psg.com; Wed, 13 Mar 2002 07:17:47 -0800 Received: from 208-59-114-172.c3-0.129-ubr1.lnh-129.md.cable.rcn.com ([208.59.114.172] helo=ogud.com) by psg.com with esmtp (Exim 3.35 #1) id 16lAVe-000DTr-00 for namedroppers@ops.ietf.org; Wed, 13 Mar 2002 07:17:46 -0800 Received: from oemcomputer.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id g2DFHQe25858 for ; Wed, 13 Mar 2002 10:17:27 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <5.1.0.14.2.20020313100809.0224d100@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 13 Mar 2002 10:14:25 -0500 To: DNSEXT mailing list From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: Re: DNSEXT IETF-53 Agenda In-Reply-To: <20020311234608.P22678-100000@hlid.dc.ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:47 PM 3/11/2002, Olafur Gudmundsson wrote: > DNS Extensions WG (dnsext) @ IETF-53 > >Monday, 2002/March/18 at 9:00-11:30 >================================ minor corrections: >Plug for the SPIKED BOF Jacob Schlyter > http://www.ietf.org/ietf/02mar/siked.txt s/SPIKED/SIKED/ >Plug for DNSSEC provreg document Scott Hollenbeck > http://www.ietf.org/internet-drafts/draft-hollenbeck-epp-secdns-00.txt > >Plug for dnsop agenda Lars Johann-Liman/Ray Plzak Addition if there is time at the end: A Private DNS Namespace for Automatic Configuration Aidan Williams http://draft-williams-dnsext-private-namespace-00.txt -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 14 11:17:12 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21040 for ; Thu, 14 Mar 2002 11:17:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16lXYg-00062f-00 for namedroppers-data@psg.com; Thu, 14 Mar 2002 07:54:26 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.35 #1) id 16lXYg-00062Y-00 for namedroppers@ops.ietf.org; Thu, 14 Mar 2002 07:54:26 -0800 Received: from randy by rip.psg.com with local (Exim 4.00) id 16lXYg-0000ZQ-00 for namedroppers@ops.ietf.org; Thu, 14 Mar 2002 07:54:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200203141526.KAA19163@ietf.org> To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: The IESG SUBJECT: Last Call: Representing IPv6 addresses in DNS to Proposed Standard Date: Thu, 14 Mar 2002 10:26:24 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The IESG has received a request from the DNS Extensions Working Group to consider Representing IPv6 addresses in DNS as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by April 2, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ipv6-addresses-01.txt -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 14 13:34:03 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24976 for ; Thu, 14 Mar 2002 13:34:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16lZmS-00082x-00 for namedroppers-data@psg.com; Thu, 14 Mar 2002 10:16:48 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.35 #1) id 16lZmQ-00082i-00 for namedroppers@ops.ietf.org; Thu, 14 Mar 2002 10:16:47 -0800 Received: from ripe.net (penguin.ripe.net [193.0.1.232]) by birch.ripe.net (8.11.6/8.11.6) with ESMTP id g2EIGiE16430 for ; Thu, 14 Mar 2002 19:16:44 +0100 Date: Thu, 14 Mar 2002 08:43:25 +0100 From: "Olaf M. Kolkman" To: Roy Arends Subject: Re: Another NEW technical argument for Opt-In. Message-Id: <20020314084325.4bce84e3.olaf@ripe.net> In-Reply-To: <20020227112239.P37547-100000@node10c4d.a2000.nl> References: <20020227112239.P37547-100000@node10c4d.a2000.nl> Organization: RIPE NCC X-Mailer: Sylpheed version 0.7.0 (GTK+ 1.2.9; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think I understand the argument. > Opt-In can be used as a method to satisfy both sides of the wildcard > issue. Opt-In allows for unsigned nodes in a secured zone, and in this > particular case, wildcards can be left unsigned in a secure zone, and the > requirement (1) and (2) can optionally be dropped by means of a new > proposal. So in other words: If we _require_ the use of opt-in over wildcards we loose the complexity; wildcard's MUST not be accompanied by SIG and NXT records. If the working group requires signatures over wildcard record this argument looses it's validity as an argument for OPT-IN. --Olaf --------------------------------------------| Olaf M. Kolkman | www.ripe.net/disi -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 14 14:04:28 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26334 for ; Thu, 14 Mar 2002 14:04:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16laLq-0008ds-00 for namedroppers-data@psg.com; Thu, 14 Mar 2002 10:53:22 -0800 Received: from e22.nc.us.ibm.com ([32.97.136.228]) by psg.com with esmtp (Exim 3.35 #1) id 16laLp-0008dm-00 for namedroppers@ops.ietf.org; Thu, 14 Mar 2002 10:53:21 -0800 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e22.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA24848 for ; Thu, 14 Mar 2002 12:49:56 -0600 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g2EIrEo55650 for ; Thu, 14 Mar 2002 13:53:14 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g2EIopi26776 for ; Thu, 14 Mar 2002 13:50:51 -0500 Message-Id: <200203141850.g2EIopi26776@rotala.raleigh.ibm.com> To: namedroppers Subject: FWD: Re: Last Call: Representing IPv6 addresses in DNS to Proposed Standard Date: Thu, 14 Mar 2002 13:50:51 -0500 From: Thomas Narten Sender: owner-namedroppers@ops.ietf.org Precedence: bulk FYI ------- Forwarded Message From: Paul Vixie To: The IESG Date: Thu, 14 Mar 2002 10:24:13 -0800 Subject: Re: Last Call: Representing IPv6 addresses in DNS to Proposed Standard Re: draft-ietf-dnsext-ipv6-addresses-01.txt i object. i consider this document, and the process which has led to it, to be anticompetitive in the extreme. it will also relegate IPv6 to mobile data applications and will cement NAT as the main way for enterprises of all sizes to connect to "the internet." the process which led up to it involved secret meetings and the decisions were never ratified by any working group. consider that IPv6 allows far larger enterprise networks to use globally _unique_ address space than IPv4. now consider that no such enterprise will have globally _routable_ address space except for a few large ISP's. this disconnect between eligibility for globally _unique_ vs globally _routable_ address space must inevitably lead to higher customer stiction by these few large ISP's. the "renumbering penality" for an enterprise with its own globally unique (but not globally routable) /64 is much higher than for an enterprise with its own globally unique /27 and its own internal RFC1918 cloud. this document leads to a scenario where multihoming can only be practical for a small number of "externally visible" hosts, but never for the whole enterprise. the artificially high "renumbering penalty" of a pure-AAAA solution will either drive enterprises to continue using NAT and RFC1918, or will drive them to remain customers of the ISP who owns their address space regardless of market pressures to move elsewhere. crawford's A6/DNAME proposal has some warts but it has none of THESE warts. i am researching the appropriate federal agency to lodge a complaint about anticompetitive activity, since the IETF's membership (including some of the authors of this draft) are employees or agents of the large ISP's who will benefit from a market stranglehold if this standard is approved. meanwhile, i urge that this document be shredded and its authors chastised. re: > To: IETF-Announce: ; > Cc: namedroppers@ops.ietf.org > From: The IESG > SUBJECT: Last Call: Representing IPv6 addresses in DNS to Proposed > Standard > Date: Thu, 14 Mar 2002 10:26:24 -0500 > > The IESG has received a request from the DNS Extensions Working Group > to consider Representing IPv6 addresses in DNS > as a Proposed Standard. > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by April 2, 2002. > > Files can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ipv6-addresses-01.txt ------- 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. archive: From owner-namedroppers@ops.ietf.org Thu Mar 14 14:46:24 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28011 for ; Thu, 14 Mar 2002 14:46:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16lay1-0009Gl-00 for namedroppers-data@psg.com; Thu, 14 Mar 2002 11:32:49 -0800 Received: from 208-59-114-172.c3-0.129-ubr1.lnh-129.md.cable.rcn.com ([208.59.114.172] helo=ogud.com) by psg.com with esmtp (Exim 3.35 #1) id 16lay0-0009Gf-00 for namedroppers@ops.ietf.org; Thu, 14 Mar 2002 11:32:48 -0800 Received: from oemcomputer.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id g2EJWJe28532 for ; Thu, 14 Mar 2002 14:32:19 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <5.1.0.14.2.20020314125515.02b8e820@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 14 Mar 2002 13:04:29 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: DNSSEC editing process (Monthly posting) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA28011 The DNSEXT working group has started a rewrite of the DNSSEC specification into a documents that better reflect the protocol and allow a test plan to be constructed from the specification. To accomplish this, a team of volunteers has been formed to generate the documents. The document editing team is tasked with documenting the protocol as specified in RFC's generated by this group and id's that have been passed on by the working group to the IESG. The editors are NOT ALLOWED to make ANY changes in the protocol. If clarifications are needed due to conflicting definitions, imprecise specification, omission or other reason, the editors MUST bring these issues to the attention of the working group on the namedroppers mailing list. To assist the editors, a small group of people with good understanding of DNSSEC have been recruited to review document drafts and answer questions that the editors have. For simplified communication a mailing list has been created, anyone can send messages to the editors via this mailing list DNSSEC-editors@east.isi.edu. Archive of this mailing list will be made available. Please send minor corrections, comments, suggestions about the DNSSECbis documents to dnssec-editors@east.isi.edu. All major issues should be brought up on namedroppers, editors MAY forward any correspondence to namedroppers, without asking permission, if they deem the issues raised require wider attention. DNSEXT co-chair Ólafur Guðmundsson approves new members on the dnssec-editors malling list. DNSSEC-editors is NOT a design group, it is a document maintenance group. The current members of the mailing list are: Editors: Dan Massey Scott Rose Matt Larson Roy Arends Advisors: Donald Eastlake Brian Wellington Edward Lewis Randy Bush Olafur Gudmundsson The current set of documents produced by dnssec-editors is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-intro-01.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-records-00.txt A document on the DNSSEC protocol is scheduled to be released in April. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 14 17:00:48 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02371 for ; Thu, 14 Mar 2002 17:00:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16lcvs-000BC8-00 for namedroppers-data@psg.com; Thu, 14 Mar 2002 13:38:44 -0800 Received: from citation.av8.net ([130.105.12.3]) by psg.com with esmtp (Exim 3.35 #1) id 16lcvr-000BC2-00 for namedroppers@ops.ietf.org; Thu, 14 Mar 2002 13:38:43 -0800 Received: from news.av8.net (news.av8.net [198.3.136.138]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id QAA06616; Thu, 14 Mar 2002 16:38:11 -0500 Date: Thu, 14 Mar 2002 16:38:34 -0500 (EST) From: Dean Anderson X-X-Sender: To: Thomas Narten cc: namedroppers Subject: Re: FWD: Re: Last Call: Representing IPv6 addresses in DNS to Proposed Standard In-Reply-To: <200203141850.g2EIopi26776@rotala.raleigh.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk How does anything in DNS affect routability? DNS is just a protocol for associating names with addresses, or more generally, names with "information". It doesn't have to be the only protocol that does that. I am further amused that Paul would call anyone (else) anticompetitive, and was rofl at the (his in particular) charge of "secret meetings" and "unratified decisions". Perhaps Paul should be chastised. --Dean On Thu, 14 Mar 2002, Thomas Narten wrote: > FYI > > ------- Forwarded Message > > From: Paul Vixie > To: The IESG > Date: Thu, 14 Mar 2002 10:24:13 -0800 > Subject: Re: Last Call: Representing IPv6 addresses in DNS to Proposed Standard > > Re: draft-ietf-dnsext-ipv6-addresses-01.txt > > i object. i consider this document, and the process which has led to it, > to be anticompetitive in the extreme. it will also relegate IPv6 to mobile > data applications and will cement NAT as the main way for enterprises of all > sizes to connect to "the internet." the process which led up to it involved > secret meetings and the decisions were never ratified by any working group. > > consider that IPv6 allows far larger enterprise networks to use globally > _unique_ address space than IPv4. now consider that no such enterprise will > have globally _routable_ address space except for a few large ISP's. this > disconnect between eligibility for globally _unique_ vs globally _routable_ > address space must inevitably lead to higher customer stiction by these few > large ISP's. the "renumbering penality" for an enterprise with its own > globally unique (but not globally routable) /64 is much higher than for an > enterprise with its own globally unique /27 and its own internal RFC1918 > cloud. > > this document leads to a scenario where multihoming can only be practical > for a small number of "externally visible" hosts, but never for the whole > enterprise. the artificially high "renumbering penalty" of a pure-AAAA > solution will either drive enterprises to continue using NAT and RFC1918, > or will drive them to remain customers of the ISP who owns their address > space regardless of market pressures to move elsewhere. > > crawford's A6/DNAME proposal has some warts but it has none of THESE warts. > > i am researching the appropriate federal agency to lodge a complaint about > anticompetitive activity, since the IETF's membership (including some of > the authors of this draft) are employees or agents of the large ISP's who > will benefit from a market stranglehold if this standard is approved. > > meanwhile, i urge that this document be shredded and its authors chastised. > > re: > > > To: IETF-Announce: ; > > Cc: namedroppers@ops.ietf.org > > From: The IESG > > SUBJECT: Last Call: Representing IPv6 addresses in DNS to Proposed > > Standard > > Date: Thu, 14 Mar 2002 10:26:24 -0500 > > > > The IESG has received a request from the DNS Extensions Working Group > > to consider Representing IPv6 addresses in DNS > > as a Proposed Standard. > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send any comments to the > > iesg@ietf.org or ietf@ietf.org mailing lists by April 2, 2002. > > > > Files can be obtained via > > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ipv6-addresses-01.txt > > > ------- 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. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 14 17:20:32 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02888 for ; Thu, 14 Mar 2002 17:20:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16ldLn-000ByQ-00 for namedroppers-data@psg.com; Thu, 14 Mar 2002 14:05:31 -0800 Received: from h236.s231.netsol.com ([216.168.231.236]) by psg.com with esmtp (Exim 3.35 #1) id 16ldLm-000ByJ-00 for namedroppers@ops.ietf.org; Thu, 14 Mar 2002 14:05:30 -0800 Received: (from markk@localhost) by h236.s231.netsol.com (8.11.0/8.11.0) id g2EM5Q610066 for namedroppers@ops.ietf.org; Thu, 14 Mar 2002 17:05:26 -0500 (EST) Date: Thu, 14 Mar 2002 17:05:26 -0500 From: Mark Kosters To: namedroppers@ops.ietf.org Subject: numbers for 2535, ds, and ds+opt-in Message-ID: <20020314220526.GA10034@slam.admin.cto.netsol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.25i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hi After a couple of very painful months dealing with hardware issues, software bugs, and slow turn arounds on tests, I have some numbers that compare 2535, ds, and ds+opt-in. These numbers were used to look at worst-case scenarios doing full zone signings with 2 1024 bit RSA keys. I've used 2 keys since: 1) we may have to support RSA and DSA. 2) I did some tests with two RSA keys already. Baseline Machines: IBM 4-way M80 with 500MHZ cpus running AIX with 16GB of RAM A prerelease IA64 4-way with 800MHZ cpus running Linux with 16GB of RAM Baseline Data: To decrease the turnaround time, I've ran a partial zone that consisted of 8,921,477 delegations. The current com zone is approximately 22,000,000+ delegations. Baseline Software: Olafur's DS hack to bind 9.2.0rc8 for DS. 9.2.0 for the 2535 and unsigned tests. Both machines were quiet as I was doing the testing so the results would not be skewed in anyway. I did not use any accelerator cards in the test. The things we looked at were: zone signing times (just so people see what it is really like) zone file size (affects propagation to the remote sites) zone loading time (down time on the machine on reload) zone image size (affects machine sizing) zone serving performance (once loaded, how much work has to be done) 1) zone signing times IBM M80 Intel IA64 2535 1,275,421 secs 171,816 secs DS (with 0 delegations) 695,232 secs 93,661 secs What this shows is that an IBM M80 is not too swift doing RSA sigs :^). There are a number of crypto accelerator cards out there that would increase performance. Some claim to do 3K 1024 bit RSA sigs a second that will speed this up. Signing is stuff that can be improved on but I wanted to give some numbers anyhow. 2) zone file size (affects propagation) unsigned 904 MB 2535 10,932 MB DS (0 delegations signed) 5,955 MB 3) zone loading time IBM M80 Intel IA64 unsigned 1,767 secs 855 secs 2535 28,531 secs 7,109 secs DS (0 delegations signed) 8,563 secs 3,934 secs 4) zone image size IBM M80 Intel IA64 unsigned 1.9 GB 1.7 GB 2535 10.1 GB 8.8 GB DS (0 delegations signed) 6.1 GB 5.5 GB 5) serving performance This affect cpu performance on busy machines on lookup for a non-existant domain. A non-trivial number of queries turn out to non-existant domains. With 2535 and DS, the NXT need to be found and returned after searching a tree the size of the delegation space. On opt-in, the search tree is the size of the number of secured delegations. 2535 or DS: log2n where n = number of delegations Opt-in log2m where m = number of secured delegations and where m << n Now on to the forecasting. As # of delegations grow in DS, it approaches the signing, filesize, load time, and image size of 2535. Actually, the secured delegation will be a bit bigger than 2535 since the DS RR will be 20 bytes larger than the NULL key RR. So, with that in mind, here are some #'s between opt-in with ds and ds only using IA64 numbers on a zone with 8,921K delegations. 00% Delegations Secured Image Size File Size opt-in 1.7GB 904 MB ds only 5.5GB 5,955 MB 25% Delegations Secured opt-in 3.5GB 3,587 MB ds only 6.5GB 7,375 MB 50% Delegations Secured opt-in 5.3GB 6,269 MB ds only 7.5GB 8,795 MB 75% Delegations Secured opt-in 7.0GB 8,952 MB ds only 8.4GB 10,215 MB 100% Delegations Secured opt-in 8.9GB 11,634 MB ds only 8.9GB 11,634 MB As the number of domains grows, opt-in has a steeper curve since it starts out with a much smaller memory base than ds but grows faster given it adds the NXT that DS has as part of the base. It looks to me that if the percentage of delegations that "opt" to use DNSSEC stay small, opt-in is a reasonable enhancement. Thanks, Mark -- Mark Kosters markk@netsol.com Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 14 17:36:07 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03166 for ; Thu, 14 Mar 2002 17:36:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16ldPQ-000C78-00 for namedroppers-data@psg.com; Thu, 14 Mar 2002 14:09:16 -0800 Received: from porter.east.isi.edu ([65.114.168.20] helo=east.east.isi.edu) by psg.com with esmtp (Exim 3.35 #1) id 16ldPP-000C72-00 for namedroppers@ops.ietf.org; Thu, 14 Mar 2002 14:09:15 -0800 Received: from isi.edu (remote35.east.isi.edu [65.114.168.35]) by east.east.isi.edu (8.11.3/8.11.3) with ESMTP id g2EM9As20240; Thu, 14 Mar 2002 17:09:10 -0500 (EST) Message-ID: <3C912018.13802F19@isi.edu> Date: Thu, 14 Mar 2002 17:11:36 -0500 From: Daniel Massey Organization: USC/ISI X-Mailer: Mozilla 4.73 [en]C-CCK-MCD BA45DSL (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Simon Josefsson CC: namedroppers@ops.ietf.org, dnssec-editors@east.isi.edu Subject: Re: DNSSEC editing process (Monthly posting) References: <5.1.0.14.2.20020314125515.02b8e820@localhost> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Hi, There are some differences between the rewrite and RFC 2535, but none of these changes are new to the rewrite. The rewrite attempts to incorporate RFC 2535 and all the subsequent updates/changes. The KEY record usage is different from that found in RFC 2535 and many of the flags/protocol octet values in the KEY record are gone. But this change is not new to the rewrite and can be found in: draft-ietf-dnsext-restrict-key-for-dnssec-01.txt Note also the key chaining mechanism (storing SIGs from the parent in the child) will not be in the rewrite and the rewrite will use only the DS key chaining method. Since both of these drafts are currently in last call, they are included in the rewrite. Dan Simon Josefsson wrote: > > Ólafur Gudmundsson/DNSEXT co-chair writes: > > > The editors are NOT ALLOWED to make ANY changes in the protocol. > > Section 2 of draft-ietf-dnsext-dnssec-records-00 and section 3.2 of > draft-ietf-dnsext-dnssec-intro-01 is one major change. > > It changes both high level issues -- the intended usage of DNSSEC as a > whole -- and low level issues -- the interpretation of the KEY RR > protocol syntax. > > Perhaps either the change should be reverted, or it should be made > clear that this effort is targetting a DNSSECv2 that will be > incompatible and lack major features present in RFC 2535. IMHO the > editorial rewrite has forbidden the single most important feature of > RFC 2535. > > As a memory jog, re-read the abstract of RFC 2535 and compare it with > the current drafts: > > ... > The extensions provide for the storage of authenticated public keys > in the DNS. This storage of keys can support general public key > distribution services as well as DNS security. The stored keys > enable security aware resolvers to learn the authenticating key of > zones in addition to those for which they are initially configured. > Keys associated with DNS names can be retrieved to support other > protocols. Provision is made for a variety of key types and > algorithms. > ... > > It is clear that the goal of RFC 2535 included a general public key > distribution mechanism. > > If the goal of DNSSEC has changed, which one could understand since > time has passed, that should be documented together with the reasons > for that change. Changing the goal of DNSSEC in a editorial rewrite > smells fishy to me. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 14 18:03:25 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03768 for ; Thu, 14 Mar 2002 18:03:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16le12-000DPF-00 for namedroppers-data@psg.com; Thu, 14 Mar 2002 14:48:08 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.35 #1) id 16le11-000DP9-00 for namedroppers@ops.ietf.org; Thu, 14 Mar 2002 14:48:07 -0800 Received: from randy by rip.psg.com with local (Exim 4.00) id 16le11-0000TT-00 for namedroppers@ops.ietf.org; Thu, 14 Mar 2002 14:48:07 -0800 References: <5.1.0.14.2.20020314125515.02b8e820@localhost> In-Reply-To: <5.1.0.14.2.20020314125515.02b8e820@localhost> =?iso-8859-1?q?(=D3lafur?= Gudmundsson/DNSEXT co-chair's message of "Thu, 14 Mar 2002 13:04:29 -0500") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: namedroppers@ops.ietf.org Cc: dnssec-editors@east.isi.edu Subject: Re: DNSSEC editing process (Monthly posting) From: Simon Josefsson Date: Thu, 14 Mar 2002 22:13:58 +0100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit [ post by non-subscriber ] Ólafur Gudmundsson/DNSEXT co-chair writes: > The editors are NOT ALLOWED to make ANY changes in the protocol. Section 2 of draft-ietf-dnsext-dnssec-records-00 and section 3.2 of draft-ietf-dnsext-dnssec-intro-01 is one major change. It changes both high level issues -- the intended usage of DNSSEC as a whole -- and low level issues -- the interpretation of the KEY RR protocol syntax. Perhaps either the change should be reverted, or it should be made clear that this effort is targetting a DNSSECv2 that will be incompatible and lack major features present in RFC 2535. IMHO the editorial rewrite has forbidden the single most important feature of RFC 2535. As a memory jog, re-read the abstract of RFC 2535 and compare it with the current drafts: ... The extensions provide for the storage of authenticated public keys in the DNS. This storage of keys can support general public key distribution services as well as DNS security. The stored keys enable security aware resolvers to learn the authenticating key of zones in addition to those for which they are initially configured. Keys associated with DNS names can be retrieved to support other protocols. Provision is made for a variety of key types and algorithms. ... It is clear that the goal of RFC 2535 included a general public key distribution mechanism. If the goal of DNSSEC has changed, which one could understand since time has passed, that should be documented together with the reasons for that change. Changing the goal of DNSSEC in a editorial rewrite smells fishy to me. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 14 19:44:54 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06176 for ; Thu, 14 Mar 2002 19:44:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16lfdM-000EuW-00 for namedroppers-data@psg.com; Thu, 14 Mar 2002 16:31:48 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.35 #1) id 16lfdL-000EuQ-00 for namedroppers@ops.ietf.org; Thu, 14 Mar 2002 16:31:47 -0800 Received: from randy by rip.psg.com with local (Exim 4.00) id 16lfdH-0003ah-00; Thu, 14 Mar 2002 16:31:43 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Simon Josefsson Cc: namedroppers@ops.ietf.org Subject: Re: DNSSEC editing process (Monthly posting) References: <5.1.0.14.2.20020314125515.02b8e820@localhost> Message-Id: Date: Thu, 14 Mar 2002 16:31:43 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > If the goal of DNSSEC has changed, which one could understand since > time has passed, that should be documented together with the reasons > for that change. the change became official when the wg reached consensus on draft-ietf-dnsext-restrict-key-for-dnssec-01.txt randy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 15 04:09:45 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24083 for ; Fri, 15 Mar 2002 04:09:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16lnP3-000L8O-00 for namedroppers-data@psg.com; Fri, 15 Mar 2002 00:49:33 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.35 #1) id 16lnP2-000L8I-00 for namedroppers@ops.ietf.org; Fri, 15 Mar 2002 00:49:33 -0800 Received: from localhost (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 35A1E3190C for ; Fri, 15 Mar 2002 00:49:31 -0800 (PST) X-Received: from localhost (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 588B731917; Fri, 15 Mar 2002 00:46:41 -0800 (PST) Date: Fri, 15 Mar 2002 09:51:12 +0100 (CET) From: Roy Arends X-X-Sender: To: "Olaf M. Kolkman" Cc: Roy Arends Subject: Re: Another NEW technical argument for Opt-In. In-Reply-To: <20020314084325.4bce84e3.olaf@ripe.net> Message-ID: <20020315095030.H21014-100000@node10c4d.a2000.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 14 Mar 2002, Olaf M. Kolkman wrote: > I think I understand the argument. > > > Opt-In can be used as a method to satisfy both sides of the wildcard > > issue. Opt-In allows for unsigned nodes in a secured zone, and in this > > particular case, wildcards can be left unsigned in a secure zone, and the > > requirement (1) and (2) can optionally be dropped by means of a new > > proposal. > > So in other words: If we _require_ the use of opt-in over wildcards we > loose the complexity; wildcard's MUST not be accompanied by SIG and NXT > records. Yes. > If the working group requires signatures over wildcard record this > argument looses it's validity as an argument for OPT-IN. Yes. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 15 10:20:45 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01334 for ; Fri, 15 Mar 2002 10:20:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16ltE1-000OlB-00 for namedroppers-data@psg.com; Fri, 15 Mar 2002 07:02:33 -0800 Received: from h150n1fls31o887.telia.com ([213.66.164.150] helo=snout.autonomica.se) by psg.com with esmtp (Exim 3.35 #1) id 16ltE0-000Ol5-00 for namedroppers@ops.ietf.org; Fri, 15 Mar 2002 07:02:32 -0800 Received: by snout.autonomica.se (Postfix, from userid 1211) id B7023F8E; Fri, 15 Mar 2002 16:02:29 +0100 (CET) To: Cc: Roy Arends Subject: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-01.txt References: <20020307125951.J2674-100000@node10c4d.a2000.nl> From: Johan Ihren Date: 15 Mar 2002 16:02:29 +0100 In-Reply-To: <20020307125951.J2674-100000@node10c4d.a2000.nl> Message-ID: <2cy9gt7u2i.fsf@snout.autonomica.se> Lines: 35 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.3 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Roy Arends writes: > > 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. > > Either move 2672 (DNAME) to experimental or not. Deprecating DNAME > RR usage in the reverse tree implies that forward/reverse are > technically different. They are not. Also, the following statement: "The issues for DNAME chaining in the reverse tree are substantially identical to the issues for A6 chaining in the forward tree." is plain wrong. In the forward tree without A6 the delegation hierarchy stays intact while the RRs have to change. In the reverse tree without DNAME the entire delegation hierarchy breaks apart since the names of the delegation points change recursively all the way down the tree. To call that "substantially identical" is, even to a very stretchable imagination, still a mindboggling statement. If you're determined to kill DNAME you should at least not use broken justification for the deed. Johan Ihrén Autonomica -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 15 11:07:00 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02710 for ; Fri, 15 Mar 2002 11:07:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16lu1C-000PSw-00 for namedroppers-data@psg.com; Fri, 15 Mar 2002 07:53:22 -0800 Received: from h150n1fls31o887.telia.com ([213.66.164.150] helo=snout.autonomica.se) by psg.com with esmtp (Exim 3.35 #1) id 16lu1B-000PSm-00 for namedroppers@ops.ietf.org; Fri, 15 Mar 2002 07:53:21 -0800 Received: by snout.autonomica.se (Postfix, from userid 1211) id F2163F8E; Fri, 15 Mar 2002 16:53:19 +0100 (CET) To: Randy Bush Cc: Olafur Gudmundsson , DNSEXT mailing list Subject: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-01.txt References: <20020307125951.J2674-100000@node10c4d.a2000.nl> <20020307085522.C24205-100000@hlid.dc.ogud.com> From: Johan Ihren Date: 15 Mar 2002 16:53:19 +0100 In-Reply-To: Message-ID: <2cpu257rps.fsf@snout.autonomica.se> Lines: 41 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Randy Bush writes: > > The reason for not changing the status of DNAME is that there might > > be other uses for DNAME than just supporting the reverse lookup. > > there *might* be reasons to keep nuclear weapons in your home. there > *might* be reasons to eat broccoli. > > YAGNI and > Another well known design rule is "Make it as simple as possible -- but not simpler" My (still active) objection to your referral to YAGNI and similar quips [when debating DNS support for renumbering] is that we're not talking about unneeded functionality that can be retrofitted if and when we decide that it indeed was needed. We're talking about functionality that we basically already have, since the deployed base is so small, but which will be impossible to retrofit afterwards because of the deployment time once the base is large. I seem to remember that Olafur made a guesstimate of 16 years for new DNS functionality (he was talking about some other functionality, but that doesn't matter to the timeline) to propagate to a sufficiently large fraction of the hosts that it could be said to be "deployed". Once v6 takes off this will get worse, due to all kinds of embedded devices and other non-computer thingies that will never get updated. It may well be that A6 and DNAME were mistakes, although I don't think so, but I really object to you trying to make light of the issue by referring to it as a KISS(*)-problem. This is *not* simple. It should not be treated as if it was simple. Johan (*) Keep It Simple Stupid. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 15 12:49:44 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05843 for ; Fri, 15 Mar 2002 12:49:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16lvan-0000u6-00 for namedroppers-data@psg.com; Fri, 15 Mar 2002 09:34:13 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.35 #1) id 16lvam-0000u0-00 for namedroppers@ops.ietf.org; Fri, 15 Mar 2002 09:34:12 -0800 Received: from localhost (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 7A1243190C for ; Fri, 15 Mar 2002 09:34:11 -0800 (PST) X-Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by shell.nominum.com (Postfix) with ESMTP id 7AAF331917 for ; Fri, 15 Mar 2002 07:47:52 -0800 (PST) X-Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id KAA03041; Fri, 15 Mar 2002 10:47:50 -0500 (EST) X-Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA16084; Fri, 15 Mar 2002 10:43:03 -0500 (EST) X-Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id KAA26372; Fri, 15 Mar 2002 10:43:03 -0500 (EST) X-Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id KAA21268; Fri, 15 Mar 2002 10:43:02 -0500 (EST) To: Roy Arends Cc: "Olaf M. Kolkman" Subject: Re: Another NEW technical argument for Opt-In. References: <20020315095030.H21014-100000@node10c4d.a2000.nl> From: Derek Atkins Date: 15 Mar 2002 10:43:02 -0500 In-Reply-To: <20020315095030.H21014-100000@node10c4d.a2000.nl> Message-ID: Lines: 57 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk If this is the case then an attacker can always force the recipient to believe a wildcard by replacing any response with an unauthenticated wildcard response. I think this is a bad idea. Eg: Query: www.foo.com. A? Response: *.foo.com A 1.2.3.4 How is a client supposed to know that this is an authentic response? If the server MUST NOT reply with a SIG or NXT, then what's to stop someone from _creating_ this record and sending it in response to any query? -derek Roy Arends writes: > On Thu, 14 Mar 2002, Olaf M. Kolkman wrote: > > > I think I understand the argument. > > > > > Opt-In can be used as a method to satisfy both sides of the wildcard > > > issue. Opt-In allows for unsigned nodes in a secured zone, and in this > > > particular case, wildcards can be left unsigned in a secure zone, and the > > > requirement (1) and (2) can optionally be dropped by means of a new > > > proposal. > > > > So in other words: If we _require_ the use of opt-in over wildcards we > > loose the complexity; wildcard's MUST not be accompanied by SIG and NXT > > records. > > Yes. > > > If the working group requires signatures over wildcard record this > > argument looses it's validity as an argument for OPT-IN. > > Yes. > > Roy > > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- 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. archive: From owner-namedroppers@ops.ietf.org Fri Mar 15 12:49:44 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05844 for ; Fri, 15 Mar 2002 12:49:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16lvb4-0000ua-00 for namedroppers-data@psg.com; Fri, 15 Mar 2002 09:34:30 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.35 #1) id 16lvb3-0000uU-00 for namedroppers@ops.ietf.org; Fri, 15 Mar 2002 09:34:29 -0800 Received: from localhost (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 8085F3190C for ; Fri, 15 Mar 2002 09:34:28 -0800 (PST) X-Received: from localhost (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 4039231917; Fri, 15 Mar 2002 08:05:56 -0800 (PST) Date: Fri, 15 Mar 2002 17:10:31 +0100 (CET) From: Roy Arends X-X-Sender: To: Derek Atkins Cc: Roy Arends , "Olaf M. Kolkman" Subject: Re: Another NEW technical argument for Opt-In. In-Reply-To: Message-ID: <20020315165643.C21014-100000@node10c4d.a2000.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On 15 Mar 2002, Derek Atkins wrote: > If this is the case then an attacker can always force the recipient > to believe a wildcard by replacing any response with an unauthenticated > wildcard response. I think this is a bad idea. > > Eg: > > Query: > www.foo.com. A? > > Response: > *.foo.com A 1.2.3.4 > > > How is a client supposed to know that this is an authentic response? > If the server MUST NOT reply with a SIG or NXT, then what's to stop > someone from _creating_ this record and sending it in response to any > query? Security aware resolver asks "www.foo.com. A" and expects a signed statement (since parent previously claimed foo is secured). If www.foo.com does not exist, client will receive either vvv.foo.com NXT xxx.foo.com NXT SIG vvv.foo.com SIG NXT (NXT bit set-> not opt-in -> www.foo.com does not exist) or, with wildcards: www.foo.com A vvv.foo.com NXT xxx.foo.com SIG vvv.foo.com SIG NXT (NXT bit clear -> opt-in -> might be some unsigned RRset between vvv and xxx) In my previous answer to Olaf Kolkman, I ment to acknowledge that when you drop the requirements (1) and (2), wildcards do not exist in the DNSSEC realm (i.e. unexpanded wildcards do not have a SIG or NXT associated with them), and you can still use them by means of opt-in, since they may exist in the unsecure realm. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 15 13:36:56 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06883 for ; Fri, 15 Mar 2002 13:36:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16lwKO-0001mb-00 for namedroppers-data@psg.com; Fri, 15 Mar 2002 10:21:20 -0800 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.35 #1) id 16lwKN-0001mU-00 for namedroppers@ops.ietf.org; Fri, 15 Mar 2002 10:21:19 -0800 Received: from thangorodrim.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id 42BA51BFA for ; Fri, 15 Mar 2002 13:21:18 -0500 (EST) Received: from thangorodrim.hactrn.net (localhost [127.0.0.1]) by thangorodrim.hactrn.net (Postfix) with ESMTP id 958EA46B for ; Fri, 15 Mar 2002 18:21:14 +0000 (GMT) Date: Fri, 15 Mar 2002 13:21:13 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Reply-To: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-01.txt In-Reply-To: <2cy9gt7u2i.fsf@snout.autonomica.se> References: <20020307125951.J2674-100000@node10c4d.a2000.nl> <2cy9gt7u2i.fsf@snout.autonomica.se> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (Unebigoryòmae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020315182114.958EA46B@thangorodrim.hactrn.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 15 Mar 2002 16:02:29 +0100, Johan Ihren wrote: > In the forward tree without A6 the delegation hierarchy stays intact > while the RRs have to change. In the reverse tree without DNAME the > entire delegation hierarchy breaks apart since the names of the > delegation points change recursively all the way down the tree. This is why we have last calls. The intent of the statement in the draft (derived from something I wrote) was that the issues with DNAME chaining were substantially similar to the issues with A6 chaining from the point of view of how much work a resolver would have to do to chase down an answer. As far as I can recall, this is the first time that the distinction Johan raised has come up, so I'd ask Johan to please suggest improved text to the draft authors. I'm pretty sure that the draft authors never intended to comment on more general issues involving DNAME, only on use of DNAME as A6's counterpart in the reverse tree, but given that this apparently is not clear to all readers, the draft probably ought to say so explictly. None of the above should be taken to indicate that I (or, I assume, the ADs, or the WG chairs) are ignoring all the other discussion. It's just that Johan's point is one on which I think there's some chance of achieving consensus on rational engineering grounds, whereas the larger discussion is starting to make me think that it's time for me to re-read Danny Cohen's "On Holy Wars And A Plea For Peace". --Rob -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 15 17:16:08 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12045 for ; Fri, 15 Mar 2002 17:16:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16lzfH-0004WS-00 for namedroppers-data@psg.com; Fri, 15 Mar 2002 13:55:07 -0800 Received: from h150n1fls31o887.telia.com ([213.66.164.150] helo=snout.autonomica.se) by psg.com with esmtp (Exim 3.35 #1) id 16lzfG-0004WM-00 for namedroppers@ops.ietf.org; Fri, 15 Mar 2002 13:55:06 -0800 Received: by snout.autonomica.se (Postfix, from userid 1211) id 7FE7EF8E; Fri, 15 Mar 2002 22:55:03 +0100 (CET) To: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-01.txt References: <20020307125951.J2674-100000@node10c4d.a2000.nl> <2cy9gt7u2i.fsf@snout.autonomica.se> <20020315182114.958EA46B@thangorodrim.hactrn.net> From: Johan Ihren Date: 15 Mar 2002 22:55:03 +0100 In-Reply-To: <20020315182114.958EA46B@thangorodrim.hactrn.net> Message-ID: <2cadt9zebs.fsf@snout.autonomica.se> Lines: 68 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Rob Austein writes: Hi Rob, > At 15 Mar 2002 16:02:29 +0100, Johan Ihren wrote: > > In the forward tree without A6 the delegation hierarchy stays intact > > while the RRs have to change. In the reverse tree without DNAME the > > entire delegation hierarchy breaks apart since the names of the > > delegation points change recursively all the way down the tree. > > This is why we have last calls. > > The intent of the statement in the draft (derived from something I > wrote) was that the issues with DNAME chaining were substantially > similar to the issues with A6 chaining from the point of view of how > much work a resolver would have to do to chase down an answer. As far > as I can recall, this is the first time that the distinction Johan > raised has come up, so I'd ask Johan to please suggest improved text > to the draft authors. There was a long exchange on this on namedroppers in the beginning of october last year, subject line is "DNAME (was: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-00.txt)", i.e. it started when I responded to the previous version of this draft. As to improved text I am really at a loss. As I see this deprecating DNAME for the reverse tree will either lead to "don't renumber" or "lose the reverse tree when you renumber". I'm not trying to be provocative here but if the authors want text to justify deprecation they clearly cannot use things like "the reverse tree is not important enough" or "it is so unlikely that renumbering will happen anyhow", so instead I would suggest that they add some text on exactly why DNAME is considered so dangerous in general and in the reverse tree in particular. But that will not work either, according to your next paragraph... Well, then the only thing that remains is some text that details the bad consequences of this choice without going into justification (which will look kind of strange). If that is what is wanted I'll try to write up something concise on my the to the IETF tomorrow. > I'm pretty sure that the draft authors never intended to comment on > more general issues involving DNAME, only on use of DNAME as A6's > counterpart in the reverse tree, but given that this apparently is not > clear to all readers, the draft probably ought to say so explictly. I admit that it was clear to me, but that doesn't make it less important the the consequenses of deprecation of DNAME limited to the reverse tree are clear, and judging from the draft it wasn't at all clear that they were. > None of the above should be taken to indicate that I (or, I assume, > the ADs, or the WG chairs) are ignoring all the other discussion. > It's just that Johan's point is one on which I think there's some > chance of achieving consensus on rational engineering grounds, whereas > the larger discussion is starting to make me think that it's time for > me to re-read Danny Cohen's "On Holy Wars And A Plea For Peace". I agree with this, and I did think before responding. But since my point from last year apparently had been lost I think it was right to reopen this for the umpteenth time. And I simply had to respond when Randy waved a broccoli as his weapon of choice in the battle against the A6/DNAME proponents... He really has to modernize his weaponry ;-) Johan -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 15 19:09:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14456 for ; Fri, 15 Mar 2002 19:09:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16m0ta-0005Uy-00 for namedroppers-data@psg.com; Fri, 15 Mar 2002 15:13:58 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.35 #1) id 16m0ta-0005Us-00 for namedroppers@ops.ietf.org; Fri, 15 Mar 2002 15:13:58 -0800 Received: from randy by rip.psg.com with local (Exim 4.00) id 16m0tZ-000GPI-00; Fri, 15 Mar 2002 15:13:57 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Johan Ihren Cc: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-01.txt References: <20020307125951.J2674-100000@node10c4d.a2000.nl> <2cy9gt7u2i.fsf@snout.autonomica.se> <20020315182114.958EA46B@thangorodrim.hactrn.net> <2cadt9zebs.fsf@snout.autonomica.se> Message-Id: Date: Fri, 15 Mar 2002 15:13:57 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit indeed, we've been here before. the essense is o ipv6 does not actually support rapid or frequent renumbering, it would be nice if it did, but it doesn't. ask steve deering. o hence, adding mechanisms to the dns to support something that isn't there is kinda strange. o and the possibility that some strange dns hacks would then have to be an architectural constraint on ipv6 renumbering work ("no, you can't do that because that's not the way DNAME works") is actual damage, not just wasted work. o dname itself is quite prone to ill use and abuse, as we have seen in a lot of wgs who see it and get oh so clever ideas, e.g. enum. so o we do not have a constructive immediate or visible use for it o it is dangerous o we have enough features and complexity already randy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Mar 16 02:41:09 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29863 for ; Sat, 16 Mar 2002 02:41:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16m8QL-000364-00 for namedroppers-data@psg.com; Fri, 15 Mar 2002 23:16:17 -0800 Received: from 96-1.nat.psu.ac.th ([202.28.96.1] helo=brandenburg.cs.mu.OZ.AU) by psg.com with esmtp (Exim 3.35 #1) id 16m8QI-00035y-00 for namedroppers@ops.ietf.org; Fri, 15 Mar 2002 23:16:16 -0800 Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g2FEfEG01064; Fri, 15 Mar 2002 21:41:14 +0700 (ICT) From: Robert Elz To: Thomas Narten cc: namedroppers , iesg@ietf.org Subject: Re: Last Call: Representing IPv6 addresses in DNS to Proposed Standard In-Reply-To: <200203141850.g2EIopi26776@rotala.raleigh.ibm.com> References: <200203141850.g2EIopi26776@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 15 Mar 2002 21:41:14 +0700 Message-ID: <1062.1016203274@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I also object. The rational for deprecating A6 (more on that in a bit) is largely based upon fear and guesswork. There has been no actual study of the use of A6 records that shows that it has any of the problems claimed. Nor has there ever been any WG consensus on this - there have been discussions over and over again, which never achieved anything, until everyone simply tired of re-iterating the same points over and over again. The supposed intent is to make A6 "experimental", which gives the impression that people could continue to play with it, and if it is found to work OK, it could be moved back to standards track. Procedurally, of course, it could. Practically, don't be absurd. Just consider if someone were to suggest changing the format of the IPv4 A record. How would that ever be achieved? A document for a new format is easy - actually getting it deployed would be impossible. Servers have to return A records, because that's all that clients currently look up. Clients will only ever look up A records - the previous point guarantees that servers will return them, so bothering looking for something new n the off chance that the server may support it is just wasting time and packets. No way to break out of that. The same would happen were AAAA to be the standard for some period of actual use (it is already almost entrenched enough - but fortunately, usage currently is still low enough that it is still possible to make changes). Were this doc to be progressed, A6 would be dead forever for all practical purposes. There's no question but that A6 adds useful functionality to the DNS lookups of names - if there wasn't, it never would have received consensus and been published as a PS in the first place. Dropping that functionality just because some people are scared that it might be improperly used would be absurd. Discard this doc. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Mar 16 03:05:03 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00138 for ; Sat, 16 Mar 2002 03:05:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16m8yC-0003Sj-00 for namedroppers-data@psg.com; Fri, 15 Mar 2002 23:51:16 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.35 #1) id 16m8yB-0003Sc-00 for namedroppers@ops.ietf.org; Fri, 15 Mar 2002 23:51:15 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id D09CA28F54; Fri, 15 Mar 2002 23:50:59 -0800 (PST) (envelope-from vixie@as.vix.com) From: Paul Vixie To: iesg@ietf.org Cc: namedroppers Subject: Re: Last Call: Representing IPv6 addresses in DNS to Proposed Standard In-Reply-To: Message from Robert Elz of "Fri, 15 Mar 2002 21:41:14 +0700." <1062.1016203274@brandenburg.cs.mu.OZ.AU> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Fri, 15 Mar 2002 23:50:59 -0800 Message-Id: <20020316075059.D09CA28F54@as.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > The same would happen were AAAA to be the standard for some period of > actual use (it is already almost entrenched enough - but fortunately, usage > currently is still low enough that it is still possible to make changes). it's already too late to recall the clients who look up AAAA's. it is not yet too late to recall the servers who don't do some form of AAAA synthesis, which means practically speaking it is not too late to require A6/DNAME and deprecate AAAA other than in synthesis or grandfather mode. > Were this doc to be progressed, A6 would be dead forever for all > practical purposes. yes, if this doc is progressed, A6 is dead, no possibility of revival, not even via AAAA synthesis. > Discard this doc. since the doc is not a WG product i'm not sure how it could have any other fate. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Mar 16 03:46:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00531 for ; Sat, 16 Mar 2002 03:46:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16m9cj-0004iM-00 for namedroppers-data@psg.com; Sat, 16 Mar 2002 00:33:09 -0800 Received: from 96-1.nat.psu.ac.th ([202.28.96.1] helo=brandenburg.cs.mu.OZ.AU) by psg.com with esmtp (Exim 3.35 #1) id 16m9ci-0004iG-00; Sat, 16 Mar 2002 00:33:08 -0800 Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g2G8dBH02432; Sat, 16 Mar 2002 15:39:11 +0700 (ICT) From: Robert Elz To: Randy Bush cc: Johan Ihren , namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-01.txt In-Reply-To: References: <20020307125951.J2674-100000@node10c4d.a2000.nl> <2cy9gt7u2i.fsf@snout.autonomica.se> <20020315182114.958EA46B@thangorodrim.hactrn.net> <2cadt9zebs.fsf@snout.autonomica.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 16 Mar 2002 15:39:11 +0700 Message-ID: <2430.1016267951@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Fri, 15 Mar 2002 15:13:57 -0800 From: Randy Bush Message-ID: | o ipv6 does not actually support rapid or frequent renumbering, it | would be nice if it did, but it doesn't. ask steve deering. It doesn't matter whether renumbering is rapid or frequent (terms with no definitions anyway, so what is "frequent" to one person is amazingly stable to another). The point is that A6 makes renumbering easier. There is simply no doubt about that. Whether you end up taking advantage every week, or only once in your life - (or even never, but just use it to make the zone file look cleaner, with less repeated information), it's added complexity enables things to be simpler. Like anything powerful, use it badly, and it can most likely cause harm. The real opposition to A6 seems to have largely been summed up in Rob Austein's recent message (relating to the DNAME part): similar to the issues with A6 chaining from the point of view of how much work a resolver would have to do to chase down an answer That is, it is harder for the resolver. No question about that. But the resolvers get written once, there may be a hundred of them through the life of IPv6 (just as likely merely a half dozen recycled over and over). To make it easier for the resolver, we're going to make the administrators lives harder. This doc shouldn't exist. What should exist are some guidelines for how to use A6 (and DNAME too probably) well, and avoid causing the kinds of problems that potentially might occur if they're badly configured. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Mar 16 08:49:05 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03330 for ; Sat, 16 Mar 2002 08:49:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mEOI-0007dZ-00 for namedroppers-data@psg.com; Sat, 16 Mar 2002 05:38:34 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.35 #1) id 16mEOH-0007dT-00 for namedroppers@ops.ietf.org; Sat, 16 Mar 2002 05:38:33 -0800 Received: from randy by rip.psg.com with local (Exim 4.00) id 16mEOH-0009zk-00 for namedroppers@ops.ietf.org; Sat, 16 Mar 2002 05:38:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20020316100633.13581.qmail@cr.yp.to> References: <20020307125951.J2674-100000@node10c4d.a2000.nl> <2cy9gt7u2i.fsf@snout.autonomica.se> <20020315182114.958EA46B@thangorodrim.hactrn.net> <2cadt9zebs.fsf@snout.autonomica.se> <2430.1016267951@brandenburg.cs.mu.OZ.AU> Date: 16 Mar 2002 10:06:33 -0000 From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-01.txt Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber ] Robert Elz writes: > we're going to make the administrators lives harder No. The administrator remains perfectly free to tell his server ``My address is the address of math.uic.edu but ending with 181.'' A6 and DNAME delay this indirection until the last possible moment, inserting it into the critical path in DNS lookups. That's a serious mistake. That's what we're fixing. But indirection is still allowed. The server can automatically watch the math.uic.edu address. Perhaps the phrases ``synchronous indirection'' and ``asynchronous indirection'' will make the issue more clear than my previous ``client-side indirection'' and ``server-side indirection.'' Aynchronous indirection has to be on the server side, of course, but what's really important is that it's happening in the background. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Mar 16 09:56:41 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03331 for ; Sat, 16 Mar 2002 08:49:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mEJB-0007Zw-00 for namedroppers-data@psg.com; Sat, 16 Mar 2002 05:33:17 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.35 #1) id 16mEJA-0007Zq-00 for namedroppers@ops.ietf.org; Sat, 16 Mar 2002 05:33:16 -0800 Received: from randy by rip.psg.com with local (Exim 4.00) id 16mEJA-0009p9-00 for namedroppers@ops.ietf.org; Sat, 16 Mar 2002 05:33:16 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20020316081107.4333.qmail@cr.yp.to> References: <20020307125951.J2674-100000@node10c4d.a2000.nl> <2cy9gt7u2i.fsf@snout.autonomica.se> Date: 16 Mar 2002 08:11:07 -0000 From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-01.txt Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber ] Johan Ihren writes: > In the forward tree without A6 the delegation hierarchy stays intact > while the RRs have to change. In the reverse tree without DNAME the > entire delegation hierarchy breaks apart since the names of the > delegation points change recursively all the way down the tree. As I said in October: 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. ... 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. I also summarized in that message why I object to DNAME---not just its primary intended application, but _any_ use of it. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Mar 16 15:41:07 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09106 for ; Sat, 16 Mar 2002 15:41:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mKPZ-000CD4-00 for namedroppers-data@psg.com; Sat, 16 Mar 2002 12:04:17 -0800 Received: from citation.av8.net ([130.105.12.3]) by psg.com with esmtp (Exim 3.35 #1) id 16mKPY-000CCC-00 for namedroppers@ops.ietf.org; Sat, 16 Mar 2002 12:04:16 -0800 Received: from news.av8.net (news.av8.net [198.3.136.138]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id PAA07887; Sat, 16 Mar 2002 15:00:10 -0500 Date: Sat, 16 Mar 2002 15:00:36 -0500 (EST) From: Dean Anderson X-X-Sender: To: Robert Elz cc: Johan Ihren , Subject: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-01.txt In-Reply-To: <2430.1016267951@brandenburg.cs.mu.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The tasks of DNS administrators is usually something handled by scripts and automation. So whether something is "easier" for an administrator depends on whether it can be automatically produced by a script or a program. A corporate renumbering is likely to be performed using a computer with relatively unlimited resources, its very likely to be handled with the help of automation tools and scripts, and is not very likely something done by "hand", except perhaps in the smallest and most trivial cases. Even with IPv4, it is very common to see much of DNS administration automated. Why should we expect that trend to change? However, making the resolver more complex severely affects the ability of small devices to use IPV6 due to severe resource limitations on small devices. Protocols are written for devices and users of those devices, not for administators. It is very clear that this issue basically divides along the lines of which set of priorities is more important. I think that administration takes a back seat to operation. Especially when the administration part is likely to be automated anyway. I think it is important to have our priorities set properly, and that we should have a simpler resolver, rather than simpler administration files. --Dean On Sat, 16 Mar 2002, Robert Elz wrote: > Date: Fri, 15 Mar 2002 15:13:57 -0800 > From: Randy Bush > Message-ID: > > | o ipv6 does not actually support rapid or frequent renumbering, it > | would be nice if it did, but it doesn't. ask steve deering. > > It doesn't matter whether renumbering is rapid or frequent (terms with > no definitions anyway, so what is "frequent" to one person is amazingly > stable to another). > > The point is that A6 makes renumbering easier. There is simply no doubt > about that. Whether you end up taking advantage every week, or only > once in your life - (or even never, but just use it to make the zone > file look cleaner, with less repeated information), it's added complexity > enables things to be simpler. Like anything powerful, use it badly, and > it can most likely cause harm. > > The real opposition to A6 seems to have largely been summed up in > Rob Austein's recent message (relating to the DNAME part): > > similar to the issues with A6 chaining from the point of view of how > much work a resolver would have to do to chase down an answer > > That is, it is harder for the resolver. No question about that. But the > resolvers get written once, there may be a hundred of them through the life > of IPv6 (just as likely merely a half dozen recycled over and over). > To make it easier for the resolver, we're going to make the administrators > lives harder. > > This doc shouldn't exist. What should exist are some guidelines for how > to use A6 (and DNAME too probably) well, and avoid causing the kinds of > problems that potentially might occur if they're badly configured. > > kre > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Mar 17 10:02:37 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02003 for ; Sun, 17 Mar 2002 10:02:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mbik-000PRn-00 for namedroppers-data@psg.com; Sun, 17 Mar 2002 06:33:14 -0800 Received: from 96-1.nat.psu.ac.th ([202.28.96.1] helo=brandenburg.cs.mu.OZ.AU) by psg.com with esmtp (Exim 3.35 #1) id 16mbij-000PRh-00 for namedroppers@ops.ietf.org; Sun, 17 Mar 2002 06:33:14 -0800 Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g2H7TBp00390; Sun, 17 Mar 2002 14:29:11 +0700 (ICT) From: Robert Elz To: "D. J. Bernstein" cc: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-01.txt In-Reply-To: <20020316100633.13581.qmail@cr.yp.to> References: <20020316100633.13581.qmail@cr.yp.to> <20020307125951.J2674-100000@node10c4d.a2000.nl> <2cy9gt7u2i.fsf@snout.autonomica.se> <20020315182114.958EA46B@thangorodrim.hactrn.net> <2cadt9zebs.fsf@snout.autonomica.se> <2430.1016267951@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 17 Mar 2002 14:29:11 +0700 Message-ID: <388.1016350151@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: 16 Mar 2002 10:06:33 -0000 From: "D. J. Bernstein" Message-ID: <20020316100633.13581.qmail@cr.yp.to> | No. The administrator remains perfectly free to tell his server ``My | address is the address of math.uic.edu but ending with 181.'' That's sufficient sometimes. But it isn't adequate for all cases. The simple case where this fails is for the end user organisation, that would currently be using NAT and a PPP - where their NAT is configured to simply map into whatever address the provider's PPP happens to allocate. That kind of organisation mostly simply doesn't know, or care, what address they're being given. We need to keep things this simple, for those who want it, while also providing extra functionality - including the ability for the org to manage their own DNS (which the provider would usually do now) and certainly without NAT. But the org will still want to simply use whatever prefix the provider gives it, and not care at all when it changes. That much can be done with the DNS server doing the creation of AAAA addresses (which means continually polling the provider to see when a change might happen). But if the org also wants DNS security, and isn't prepared to have its key left on line, then with AAAA there's simply no way. On the other hand with A6 it is simple. my-node IN A6 48 my-org-name.isp.net. IN SIG stuff and in the provider's zone my-org-name IN A6 0 IN SIG stuff Nothing in my zone file changes when my prefix changes, nothing needs to be re-signed, unless I decide to make a change to some internal addressing. When my provider needs to change my prefix, they just do it, and re sign it (which uses their key of course) - most likely allocating me two prefixes for the transition period (and perhaps using router renumbering, or something similar to advise my router to start advertising the new prefix and deprecate the old - that part isn't a part of the DNS so isn't relevant here). Everything just works... without A6 it cannot. There are times when deferring the resolution of the address provides advantages that doing it early cannot Of course, the DNS as a whole gains a bunch of smaller advantages this way as well - the TTL on my-node (nor any of the other hundred similar ones) doesn't need to be made any smaller than usual - since I keep my addresses stable I can easily have that set to a week or so. The only TTL that might need to be reduced (depending upon how long the transition period is to be) is that of my-org-name in the provider's zone. When that's low, and times out in someone else's cache, all they need to is a query for that one RR (and its sig) and all the addresses that relate to my domain can be re-calculated. Not everyone is going to want to operate this way - some won't trust their provider to manage the name properly (though they have no option but to trust the provider to make their prefix route correctly, this extra bit isn't so much extra) - and that's OK, no-one is going to force anyone to run their zone like this - it just needs to be available as an option for those who want it. We need to keep A6 to retain it as a possibility - if not, as soon as someone in IPng, or some security WG, or wherever else work is needed to make all this possible, starts to make a proposal, some DNS person will stans up and say "you're wasting your time, it can't work, as the DNS can't support that". kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Mar 17 10:29:52 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02608 for ; Sun, 17 Mar 2002 10:29:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mcPB-00002c-00 for namedroppers-data@psg.com; Sun, 17 Mar 2002 07:17:05 -0800 Received: from [166.63.185.232] (helo=wifi-dhcp-190-241.ietf53.cw.net) by psg.com with esmtp (Exim 3.35 #1) id 16mcPA-00002W-00 for namedroppers@ops.ietf.org; Sun, 17 Mar 2002 07:17:04 -0800 Received: from randy by wifi-dhcp-190-241.ietf53.cw.net with local (Exim 4.00) id 16mcKD-0000n8-00 for namedroppers@ops.ietf.org; Sun, 17 Mar 2002 09:11:57 -0600 In-Reply-To: <2430.1016267951@brandenburg.cs.mu.OZ.AU> References: <20020307125951.J2674-100000@node10c4d.a2000.nl> <2cy9gt7u2i.fsf@snout.autonomica.se> <20020315182114.958EA46B@thangorodrim.hactrn.net> <2cadt9zebs.fsf@snout.autonomica.se> <2430.1016267951@brandenburg.cs.mu.OZ.AU> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1016377253.1356.30.camel@error-messages.mit.edu> Mime-Version: 1.0 Subject: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-01.txt From: Greg Hudson To: Robert Elz Cc: namedroppers@ops.ietf.org Date: 17 Mar 2002 10:00:53 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber ] On Sat, 2002-03-16 at 03:39, Robert Elz wrote: > That is, it is harder for the resolver. No question about that. But the > resolvers get written once, there may be a hundred of them through the life > of IPv6 (just as likely merely a half dozen recycled over and over). > To make it easier for the resolver, we're going to make the administrators > lives harder. A more complicated DNS makes administrators' lives harder, because they have to understand more about DNS to do their work. A6/NS loops, if they ever happen (and I can't imagine that they won't happen at least occasionally) make DNS administrators' lives harder. More complicated resolvers make system administrators' lives harder, because they fail more often and behave unpredictably more often. I can give an example with the current DNS: BIND 8 regularly fails to resolve a name the first time and succeeds the second time. I understand why because I've carefully followed this and other lists and understand how BIND 8 deals with out-of-domain glue. How many administrators understand? If DNS's NS indirection were a simpler process, then this would never have become an issue. The job of a caching resolver is already way too complicated; unlike a mail server, a web server, or an IMAP server, I cannot hope to understand the internal workings of a caching resolver in a reasonable amount of time, because the job being done is too Byzantine for easy human comprehension. (And I speak as someone who has written and released a stub resolver.) If you want to make this situation worse, you are not an administrator's friend. Against this we have the claim that A6 makes renumbering easier. Contrary to what you say, I think this claim falls apart under scrutiny. If only used within a zone, the benefit becomes an implementation issue. If used across zones, A6 means a party can renumber a zone without changing its zone file; I am skeptical that there are cases where you don't have the means to change a zone file but do have the means to renumber all the machines it provides DNS information for. Maybe in a world with the fantasy of automatic IPv6 renumbering, A6 would make sense as the last piece of the puzzle, but it doesn't make sense in today's world. Moreover, when I think about being able to renumber a large, heterogeneous organization like MIT, I think about being able to have both prefixes for some period of time (ideally on the order of months) and being able to renumber machines incrementally. A6 doesn't make this process any harder, but it doesn't make it any easier either; it only helps me if I want to renumber in one fell swoop. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Mar 17 11:03:08 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03496 for ; Sun, 17 Mar 2002 11:03:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mcz8-0000dw-00 for namedroppers-data@psg.com; Sun, 17 Mar 2002 07:54:14 -0800 Received: from 96-1.nat.psu.ac.th ([202.28.96.1] helo=brandenburg.cs.mu.OZ.AU) by psg.com with esmtp (Exim 3.35 #1) id 16mcz6-0000dq-00 for namedroppers@ops.ietf.org; Sun, 17 Mar 2002 07:54:13 -0800 Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g2HFxnv01921; Sun, 17 Mar 2002 22:59:53 +0700 (ICT) From: Robert Elz To: Dean Anderson cc: Johan Ihren , namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-01.txt In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 17 Mar 2002 22:59:49 +0700 Message-ID: <1919.1016380789@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Sat, 16 Mar 2002 15:00:36 -0500 (EST) From: Dean Anderson Message-ID: | However, making the | resolver more complex severely affects the ability of small devices to use | IPV6 due to severe resource limitations on small devices. Since we have lots of deployed clients now using AAAA lookups, there's no way we can ever undo that - so for A6 to be used at all, it is going to have to be via the back end cache doing A6 lookups, and sending back the answers as if they were an AAAA record. (Resolvers can generate A6 queries if they prefer of course, but now can never be required to). So, that argument is irrelevant - small devices will be able to use AAAA queries whether we put A6 or AAAA in the servers. | Protocols are written for devices and users of those devices, not for | administators. The biggest direct user of DNS data are the administrators. Everyone else uses it only indirectly. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Mar 17 11:23:52 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04360 for ; Sun, 17 Mar 2002 11:23:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mdFT-0000u3-00 for namedroppers-data@psg.com; Sun, 17 Mar 2002 08:11:07 -0800 Received: from 96-1.nat.psu.ac.th ([202.28.96.1] helo=brandenburg.cs.mu.OZ.AU) by psg.com with esmtp (Exim 3.35 #1) id 16mdFS-0000tw-00 for namedroppers@ops.ietf.org; Sun, 17 Mar 2002 08:11:06 -0800 Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g2HGHQv01941; Sun, 17 Mar 2002 23:17:29 +0700 (ICT) From: Robert Elz To: Greg Hudson cc: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-01.txt In-Reply-To: <1016377253.1356.30.camel@error-messages.mit.edu> References: <1016377253.1356.30.camel@error-messages.mit.edu> <20020307125951.J2674-100000@node10c4d.a2000.nl> <2cy9gt7u2i.fsf@snout.autonomica.se> <20020315182114.958EA46B@thangorodrim.hactrn.net> <2cadt9zebs.fsf@snout.autonomica.se> <2430.1016267951@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 17 Mar 2002 23:17:26 +0700 Message-ID: <1939.1016381846@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: 17 Mar 2002 10:00:53 -0500 From: Greg Hudson Message-ID: <1016377253.1356.30.camel@error-messages.mit.edu> | Maybe in a world with the fantasy of automatic IPv6 | renumbering, A6 would make sense as the last piece of the puzzle, but it | doesn't make sense in today's world. I think this is the crucial point of this whole debate. Those opposed to A6 see it as unnecessary, and useless for anything we do today (and more complicated, ...). And they're most likely correct. Those who support A6 want it there now, because if it isn't deployed now, it can never be deployed. It will simply be too late. So, if we decide to discard A6 now, that "world with the fantasy of automatic IPv6 renumbering" will never be more than a fantasy - and 50 years from now, you'd be able to look back and say "see, we were right." But that very well may be only because of this decision. If we want to retain even the possibility that one day we might get to a state of fully automated renumbering, with nothing at all done at the site being renumbered, then we must make sure we don't build any walls now that will need to be worked around (or simply block progress) in the future. Discarding A6 is building that kind of wall. | Moreover, when I think about being able to renumber a large, | heterogeneous organization like MIT, I don't care much about MIT and similar organisations. There are only perhaps a few thousand of those (maybe just a few hundred) globally, and the rate of their increase isn't very fast. The organisations that matter are all the small businesses, with no staff that are even computer literate, let alone DNS experts. | I think about being able to have | both prefixes for some period of time (ideally on the order of months) MIT might get months, most other organisations may perhaps get a week. But that's OK, a week is plenty of time, or should be, if we have done our jobs properly. | and being able to renumber machines incrementally. A6 doesn't make this | process any harder, but it doesn't make it any easier either; it only | helps me if I want to renumber in one fell swoop. You're thinking in the IPv4 world. It makes no sense to incrementally renumber nets in IPv6, the only sane way is "one fell swoop" - at the very least for each subnet, but it may as well be for everything. Routers are advertising the prefixes for the nodes - all the nodes see the new prefix at the same instant (give or take the odd RA interval, if some node happens to miss one for some reason). All IPv6 nodes deal with multiple prefixes without drame, they all know about decrepated addresses, and what those mean, and how to deal with them. Doing the basic renumbering (for a prefix swap, as opposed to an internal network redesign) is dead trivial with IPv6. It is only all the surrounding baggage that complicates the issue. That's what we need to keep working away at eliminating. Regardless of whether or not renumering ever becomes "frequent" by any random person's definition of the term, there's no justification at all for not making it easy. Again, what we should be doing is explaining how to use A6 safely. If, in the near term, that means that servers should only be configured with A6 0, that's OK. A6 0 is isomorphic with AAAA (just a one byte longer RR), so any argument that applies to AAAA is equally true of A6 0 - except that the flexibility isn't lost with the latter. If you want, we could even ask servers to accept AAAA, and treat that as A6 0, so all those (tens...) of admins who have become accustomed to building zone files with AAAA records can just keep on doing that. What's needed is that the back end resolvers start using A6 queries to satisfy AAAA requests, and that servers process A6 queries and return the answers. As long as we get that much working soon, and retain it, then we have a path forward. Otherwise stagnation. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Mar 17 12:04:20 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06312 for ; Sun, 17 Mar 2002 12:04:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mdxo-0001X1-00 for namedroppers-data@psg.com; Sun, 17 Mar 2002 08:56:56 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.35 #1) id 16mdxn-0001Wu-00 for namedroppers@ops.ietf.org; Sun, 17 Mar 2002 08:56:55 -0800 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 0F0993190C; Sun, 17 Mar 2002 08:56:55 -0800 (PST) To: Robert Elz Cc: Greg Hudson , namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-01.txt In-Reply-To: Message from Robert Elz of "Sun, 17 Mar 2002 23:17:26 +0700." <1939.1016381846@brandenburg.cs.mu.OZ.AU> Date: Sun, 17 Mar 2002 08:56:55 -0800 Message-ID: <30156.1016384215@shell.nominum.com> From: Jim Reid Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "kre" == Robert Elz writes: kre> You're thinking in the IPv4 world. It makes no sense to kre> incrementally renumber nets in IPv6, the only sane way is kre> "one fell swoop" - at the very least for each subnet, but it kre> may as well be for everything. This may well be the sane way to renumber. However the real world isn't necessarily like that. In many large corporate nets, IP address allocation is a mess. For example a /20 (say) gets allocated to some location and then there are sub-allocations within that subnet to departments or product divisions at that site. Renumbering in "one fell swoop" can be impossible because each of those organisational units decides -- usually for its own business reasons -- when its resources can be renumbered. And that's before we enter the quagmires caused departments (de)merging or when they're acquired or divested from the company. Having A6 deployed would help with those sorts of practical renumbering problems. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Mar 17 12:51:53 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07572 for ; Sun, 17 Mar 2002 12:51:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16meg0-0002CD-00 for namedroppers-data@psg.com; Sun, 17 Mar 2002 09:42:36 -0800 Received: from 96-1.nat.psu.ac.th ([202.28.96.1] helo=brandenburg.cs.mu.OZ.AU) by psg.com with esmtp (Exim 3.35 #1) id 16mefz-0002C5-00 for namedroppers@ops.ietf.org; Sun, 17 Mar 2002 09:42:35 -0800 Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g2HHmqv02402; Mon, 18 Mar 2002 00:48:53 +0700 (ICT) From: Robert Elz To: Jim Reid cc: Greg Hudson , namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-01.txt In-Reply-To: <30156.1016384215@shell.nominum.com> References: <30156.1016384215@shell.nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 18 Mar 2002 00:48:52 +0700 Message-ID: <2400.1016387332@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Sun, 17 Mar 2002 08:56:55 -0800 From: Jim Reid Message-ID: <30156.1016384215@shell.nominum.com> While you seem to be agreeing with me that A6 is good to keep, you also are stuck in the mentality of an IPv4 user. | Renumbering in "one | fell swoop" can be impossible because each of those organisational | units decides -- usually for its own business reasons -- when its | resources can be renumbered. This makes no sense for IPv6 - both addresses (old and new) can be deployed together, both can work together, there's no reason to defer starting to use the new one - the old one keeps on working during the transition period. And if this large corporate net (which again is not where I see the biggest A6 benefit - it will help there, but it will be a real winner in the much smaller enterprise nets) needs to arrange an extended overlap because for some reason some segment of its organisation can't give up the old addresses for some time - then it needs to do that. In that case, the old addresses may just as well continue to be valid for the rest of the organisation for the same period. I know it is hard to see that IPv6 is not just like IPv4 with more bits, especially when it is sometimes advertised that way (which avoids scaring off those afraid of any change, I suppose). But in this area, IPv6 is just nothing like IPv4 at all - node configuration was one aspect of IPv4 that everyone agreed was horrid, and IPv6 has added all kinds of stuff to make most of that horror vanish. A6 can (in the future, we're not there yet) be a part of making another horror vanish. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 18 09:07:40 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05592 for ; Mon, 18 Mar 2002 09:07:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16mxPP-000PN3-00 for namedroppers-data@psg.com; Mon, 18 Mar 2002 05:42:43 -0800 Received: from roam.psg.com.ietf53.cw.net ([166.63.185.232] helo=roam.psg.com) by psg.com with esmtp (Exim 3.35 #1) id 16mxPO-000PMx-00 for namedroppers@ops.ietf.org; Mon, 18 Mar 2002 05:42:43 -0800 Received: from randy by roam.psg.com with local (Exim 4.00) id 16mxPO-0002Kl-00 for namedroppers@ops.ietf.org; Mon, 18 Mar 2002 07:42:42 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20020317233134.7934.qmail@cr.yp.to> References: <20020316100633.13581.qmail@cr.yp.to> <20020307125951.J2674-100000@node10c4d.a2000.nl> <2cy9gt7u2i.fsf@snout.autonomica.se> <20020315182114.958EA46B@thangorodrim.hactrn.net> <2cadt9zebs.fsf@snout.autonomica.se> <2430.1016267951@brandenburg.cs.mu.OZ.AU> <20020316100633.13581.qmail@cr.yp.to> <388.1016350151@brandenburg.cs.mu.OZ.AU> Date: 17 Mar 2002 23:31:34 -0000 From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-01.txt Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber ] It is essential for security that every record be signed frequently, at least once every day or two. The reason for this is explained in detail in http://cr.yp.to/djbdns/killa6.html. Robert Elz writes: > But if the org also wants DNS security, and isn't prepared to have its > key left on line, then with AAAA there's simply no way. False. The automatic update takes effect the next morning, when the key is brought online again. All of this has been amply discussed on the mailing list before. The fact that you're bringing up the same bogus argument, having forgotten the fundamental flaw in the argument, reflects a fundamental deficiency in the IETF procedures. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 18 22:53:06 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03187 for ; Mon, 18 Mar 2002 22:53:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nAPq-000EsA-00 for namedroppers-data@psg.com; Mon, 18 Mar 2002 19:36:02 -0800 Received: from padda.telia.net ([195.198.164.130]) by psg.com with esmtp (Exim 3.35 #1) id 16nAPp-000Es4-00 for namedroppers@ops.ietf.org; Mon, 18 Mar 2002 19:36:01 -0800 Received: from localhost (dufberg@localhost) by padda.telia.net (8.11.6/8.11.6) with ESMTP id g2J3Zre31484; Tue, 19 Mar 2002 04:35:53 +0100 (CET) (envelope-from dufberg@telia.net) X-Authentication-Warning: padda.telia.net: dufberg owned process doing -bs Date: Tue, 19 Mar 2002 04:35:53 +0100 (CET) From: Mats Dufberg To: Olafur Gudmundsson cc: Roy Arends , DNSEXT mailing list Subject: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-01.txt In-Reply-To: <20020307085522.C24205-100000@hlid.dc.ogud.com> Message-ID: <20020319042617.I31460-100000@padda.telia.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mar 7, 2002, 08:57 (-0500) Olafur Gudmundsson wrote: > > > 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. > > > > Either move 2672 (DNAME) to experimental or not. Deprecating DNAME RR > > usage in the reverse tree implies that forward/reverse are technically > > different. They are not. > > > > The reason for not changing the status of DNAME is that there might > be other uses for DNAME than just supporting the reverse lookup. > Thus moving DNAME off the standards track is a larger question than > just for IPv6 addresses. I'm sorry, I don't understand the reasoning. Either DNAME is too complex to be used (more risks than expected benefits) so that we should not use it in "normal" DNS, or it is OK to use it. We just have one DNS tree, and things behave the same in ip6.arpa as in the other subtrees. What is so special about ip6.arpa that we should not use DNAME there, but anywhere else? Mats ---------------------------------------------------------------------- Mats Dufberg Registry TeliaNet dufberg@telia.net Skanova/AO Networks +46 8 456 7274 Box 10707 +46 70 258 2588 SE-121 29 Stockholm ---------------------------------------------------------------------- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 19 07:19:12 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20201 for ; Tue, 19 Mar 2002 07:19:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nIKw-000OfJ-00 for namedroppers-data@psg.com; Tue, 19 Mar 2002 04:03:30 -0800 Received: from 96-1.nat.psu.ac.th ([202.28.96.1] helo=brandenburg.cs.mu.OZ.AU) by psg.com with esmtp (Exim 3.35 #1) id 16nIKv-000Of4-00 for namedroppers@ops.ietf.org; Tue, 19 Mar 2002 04:03:30 -0800 Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g2JC9Xq03714; Tue, 19 Mar 2002 19:09:35 +0700 (ICT) From: Robert Elz To: "D. J. Bernstein" cc: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-01.txt In-Reply-To: <20020317233134.7934.qmail@cr.yp.to> References: <20020317233134.7934.qmail@cr.yp.to> <20020316100633.13581.qmail@cr.yp.to> <20020307125951.J2674-100000@node10c4d.a2000.nl> <2cy9gt7u2i.fsf@snout.autonomica.se> <20020315182114.958EA46B@thangorodrim.hactrn.net> <2cadt9zebs.fsf@snout.autonomica.se> <2430.1016267951@brandenburg.cs.mu.OZ.AU> <20020316100633.13581.qmail@cr.yp.to> <388.1016350151@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Mar 2002 19:09:33 +0700 Message-ID: <3712.1016539773@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: 17 Mar 2002 23:31:34 -0000 From: "D. J. Bernstein" Message-ID: <20020317233134.7934.qmail@cr.yp.to> | It is essential for security that ... since what different people require from security differs, there is almost nothing that is essential for everyone. | False. The automatic update takes effect the next morning, when the key | is brought online again. No, the key is never on line. And in any case this is just one example. What's important here is that there is no demonstrated actual flaw with A6, beyond that it is possible to configure it so as to create problems. As it is with almost anything. (Believe there's no way to misconfigure BGP to create problems? Or even as trivial as SMTP ?) That is, it isn't a flaw, it is a side effect of the flexibility. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 19 10:47:32 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24803 for ; Tue, 19 Mar 2002 10:47:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nLWm-0009mt-00 for namedroppers-data@psg.com; Tue, 19 Mar 2002 07:27:56 -0800 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.35 #1) id 16nLWl-0009mn-00 for namedroppers@ops.ietf.org; Tue, 19 Mar 2002 07:27:55 -0800 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id KAA08028; Tue, 19 Mar 2002 10:27:53 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA07084; Tue, 19 Mar 2002 10:27:52 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id KAA08771; Tue, 19 Mar 2002 10:27:52 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id KAA11803; Tue, 19 Mar 2002 10:27:52 -0500 (EST) To: Robert Elz Cc: "D. J. Bernstein" , namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-01.txt References: <20020317233134.7934.qmail@cr.yp.to> <20020316100633.13581.qmail@cr.yp.to> <20020307125951.J2674-100000@node10c4d.a2000.nl> <2cy9gt7u2i.fsf@snout.autonomica.se> <20020315182114.958EA46B@thangorodrim.hactrn.net> <2cadt9zebs.fsf@snout.autonomica.se> <2430.1016267951@brandenburg.cs.mu.OZ.AU> <20020316100633.13581.qmail@cr.yp.to> <388.1016350151@brandenburg.cs.mu.OZ.AU> <3712.1016539773@brandenburg.cs.mu.OZ.AU> From: Derek Atkins Date: 19 Mar 2002 10:27:51 -0500 In-Reply-To: <3712.1016539773@brandenburg.cs.mu.OZ.AU> Message-ID: Lines: 24 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Robert Elz writes: > | False. The automatic update takes effect the next morning, when the key > | is brought online again. > > No, the key is never on line. I believe that by "online" Mr. Bernstein meant that the key was available to sign the zone. Whether that means the zone was copied to a dedicated non-networked server that contains the key, or perhaps the smart-card was inserted into a reader, or whatever, is unimportant. The point was that the zone gets resigned frequently. Even better, if your zone is being pushed out from a database, you are in great shape! The database push can include the signing operation. Or if you prefer the data can be signed as it enters the database. -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. archive: From owner-namedroppers@ops.ietf.org Tue Mar 19 23:52:35 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15129 for ; Tue, 19 Mar 2002 23:52:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nXgl-000L83-00 for namedroppers-data@psg.com; Tue, 19 Mar 2002 20:27:03 -0800 Received: from porter.east.isi.edu ([65.114.168.20] helo=east.east.isi.edu) by psg.com with esmtp (Exim 3.35 #1) id 16nXgk-000L7v-00 for namedroppers@ops.ietf.org; Tue, 19 Mar 2002 20:27:02 -0800 Received: from isi.edu (dial170.east.isi.edu [65.114.169.170]) by east.east.isi.edu (8.11.3/8.11.3) with ESMTP id g2K4Qts16476; Tue, 19 Mar 2002 23:26:56 -0500 (EST) Message-ID: <3C98102E.A29BF688@isi.edu> Date: Tue, 19 Mar 2002 23:29:34 -0500 From: Daniel Massey Organization: USC/ISI X-Mailer: Mozilla 4.73 [en]C-CCK-MCD BA45DSL (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Eliminating KEY Algorithms Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, draft-ietf-dnsext-restrict-key-for-dnssec-01.txt, which has passed WG last call, did not change any KEY algorithm types. In hindsight, it would have been nice to eliminate types 252, 253, and 254. Type 252 is an "indirect key". Type 253 is "private - domain name". Type 254 is "private - OID". After eliminating these types, the KEY Algorithm Table would be: VALUE Algorithm Defining RFC 0 Reserved - 1 RSA/MD5 RFC 2536 2 Diffie-Hellman RFC 2539 3 DSA RFC 2536 4 Elliptic Curve - 5 RSA/SHA1 RFC 3110 6-254 available for assignment - 255 reserved - This was discussed in Minneapolis, and there were no objections. Any list objections are requested by 5pm GMT on Sat Mar 23. If there are no objections, this will be added to the restrict-key draft without restarting the WG last call. 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. archive: From owner-namedroppers@ops.ietf.org Wed Mar 20 00:19:15 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15644 for ; Wed, 20 Mar 2002 00:19:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nYEJ-000LiQ-00 for namedroppers-data@psg.com; Tue, 19 Mar 2002 21:01:43 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.35 #1) id 16nYEI-000LiK-00 for namedroppers@ops.ietf.org; Tue, 19 Mar 2002 21:01:42 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id BE00428F50 for ; Tue, 19 Mar 2002 21:01:41 -0800 (PST) (envelope-from vixie@as.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: notes from my conversation with keith moore concerning a6/dname X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Tue, 19 Mar 2002 21:01:41 -0800 Message-Id: <20020320050141.BE00428F50@as.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk these are not my views, but rather represent my understanding of keith's position regarding A6/DNAME. > given that we cannot recall or deprecate the clients who are now making > AAAA queries, or the caching nameservers who are able to forward and/or > cache AAAA queries, we therefore cannot legislate the existence of A6 RR's > or the use of A6 queries at this late date. IPv6 is considered to be > "partly deployed" in this sense. > > A6 could still be specified as an authority server issue, such that an > authority server who heard a AAAA query but had only A6 data could do some > kind of "AAAA synthesis". DNSSEC complicates this since synthesized RR's > probably will not have covering SIG's nor be present in the NXT bitmaps. > > DNAME and bitstring labels would require changes to the deployed base of > caching/forwarding name servers, and is likewise considered beyond reach > at this "partly deployed" stage of IPv6. > > renumbering, either for A RR's or AAAA RR's, could be aided as much by > a zone preprocessor running on the primary, as it would be by A6. those are my words, and keith claims that he would use different words, but he approved the above summary. keith also reminded me that he's been out of the IESG for a couple of years and his views are now entirely personal. i note that to avoid the SIG problem on synthesized AAAA's, these AAAA's would have to be sent as additional data, which places them outside DNSSEC and therefore subject to replay attacks. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 20 04:18:37 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26828 for ; Wed, 20 Mar 2002 04:18:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nbn5-000PXw-00 for namedroppers-data@psg.com; Wed, 20 Mar 2002 00:49:51 -0800 Received: from 96-1.nat.psu.ac.th ([202.28.96.1] helo=brandenburg.cs.mu.OZ.AU) by psg.com with esmtp (Exim 3.35 #1) id 16nbn3-000PXq-00 for namedroppers@ops.ietf.org; Wed, 20 Mar 2002 00:49:50 -0800 Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g2K8uLR03066; Wed, 20 Mar 2002 15:56:24 +0700 (ICT) From: Robert Elz To: Derek Atkins cc: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-01.txt In-Reply-To: References: <20020317233134.7934.qmail@cr.yp.to> <20020316100633.13581.qmail@cr.yp.to> <20020307125951.J2674-100000@node10c4d.a2000.nl> <2cy9gt7u2i.fsf@snout.autonomica.se> <20020315182114.958EA46B@thangorodrim.hactrn.net> <2cadt9zebs.fsf@snout.autonomica.se> <2430.1016267951@brandenburg.cs.mu.OZ.AU> <20020316100633.13581.qmail@cr.yp.to> <388.1016350151@brandenburg.cs.mu.OZ.AU> <3712.1016539773@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 Mar 2002 15:56:21 +0700 Message-ID: <3064.1016614581@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: 19 Mar 2002 10:27:51 -0500 From: Derek Atkins Message-ID: | The point was that the zone gets resigned frequently. No it doesn't. That's just a theory of operation which is not required at all (and is required even less for zones that contain only the tail end of A6 records). Signing the zone once a month, and perhaps less frequently, is likely to be just fine for many sites. Please stop telling me ways that it is possible to operate that happen to fit with your theory of how the world should work. Allow sites to operate in ways that meet their own needs - even if that's something that you would never personally do. And don't cut off options just because they're not useful to your way of operating - only if you can show that they actually don't work. Once again, no-one has done that for A6 (it would be kind of difficult, as it is trivially easy to show that it does work in simple cases). kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 20 04:24:29 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26887 for ; Wed, 20 Mar 2002 04:24:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nc1L-000PlK-00 for namedroppers-data@psg.com; Wed, 20 Mar 2002 01:04:35 -0800 Received: from 96-1.nat.psu.ac.th ([202.28.96.1] helo=brandenburg.cs.mu.OZ.AU) by psg.com with esmtp (Exim 3.35 #1) id 16nc1I-000PlD-00 for namedroppers@ops.ietf.org; Wed, 20 Mar 2002 01:04:34 -0800 Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g2K9B7R03088; Wed, 20 Mar 2002 16:11:11 +0700 (ICT) From: Robert Elz To: Paul Vixie cc: namedroppers@ops.ietf.org Subject: Re: notes from my conversation with keith moore concerning a6/dname In-Reply-To: <20020320050141.BE00428F50@as.vix.com> References: <20020320050141.BE00428F50@as.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 Mar 2002 16:11:07 +0700 Message-ID: <3086.1016615467@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Tue, 19 Mar 2002 21:01:41 -0800 From: Paul Vixie Message-ID: <20020320050141.BE00428F50@as.vix.com> | these are not my views, but rather represent my understanding of keith's | position regarding A6/DNAME. Keith is usually not shy about sending his own e-mail ?? But in response to (the modified but approved version of) Keith's words... | > A6 could still be specified as an authority server issue, such that an | > authority server who heard a AAAA query but had only A6 data could do some | > kind of "AAAA synthesis". DNSSEC complicates this since synthesized RR's | > probably will not have covering SIG's nor be present in the NXT bitmaps. We discussed this option ages ago, and concluded it simply doesn't work. On the other hand, doing the synthesis near the client works just fine A client is likely going to use some simpler, probably configured, security mechanism (TSIG perhaps) to communicate with its back end resolver - so doesn't really need to know (in many cases) that the actual signatures verify - it is often just going to trust that the back end resolver has verified things, and its local security to know that it is the trusted back end resolver who is sending the reply. | > DNAME and bitstring labels would require changes to the deployed base of | > caching/forwarding name servers, and is likewise considered beyond reach | > at this "partly deployed" stage of IPv6. There is currently ~0 deployed IPv6 nameservers in any real use - it will remain that way until there are IPv6 reachable root (and COM etc) servers. We could easily make the transition to A6 happen at the same time servers start sending queries using IPv6 transport (the number of those that exist now - in use - is miniscule). | > renumbering, either for A RR's or AAAA RR's, could be aided as much by | > a zone preprocessor running on the primary, as it would be by A6. No, that's simply wrong. Aside from the previous discussion on this list in the past few days, this requires the renumbered site to know it has been renumbered. While many of you simply can't conceive of a renumbering where the affected site never knows it happened - I certainly can, and it is something I would like to work toward making possible. To do this we need to make it possible for a site to manage their own DNS, without ever having to know what their prefix is. This is not too hard for reverse lookups (the delegated zone is the same whatever its delegation point, provided it occurs at the same depth in the tree and as long as it doesn't try and include RR values that are inside the domain) but for the forward zone, A6 is the only current answer. Once again, no requirement that anyone actually do things this way - it is just an option for sites that really don't want to care about details like address prefixes (meaningless random strings of bits with no inherent meaning - other than to the routing system, which is none of their business) kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 20 09:25:04 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00240 for ; Wed, 20 Mar 2002 09:25:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16ngjL-0004Ib-00 for namedroppers-data@psg.com; Wed, 20 Mar 2002 06:06:19 -0800 Received: from sentry.gw.tislabs.com ([192.94.214.100]) by psg.com with esmtp (Exim 3.35 #1) id 16ngjK-0004IU-00 for namedroppers@ops.ietf.org; Wed, 20 Mar 2002 06:06:18 -0800 Received: by sentry.gw.tislabs.com; id JAA10665; Wed, 20 Mar 2002 09:11:54 -0500 (EST) Received: from test.netsec.tislabs.com(199.171.39.2) by sentry.gw.tislabs.com via smap (V5.5) id xma010657; Wed, 20 Mar 02 09:11:27 -0500 X-Sender: lewis@166.63.190.161 Message-Id: In-Reply-To: <3C98102E.A29BF688@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 20 Mar 2002 09:06:06 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: Eliminating KEY Algorithms Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:29 PM -0500 3/19/02, Daniel Massey wrote: >draft-ietf-dnsext-restrict-key-for-dnssec-01.txt, which has >passed WG last call, did not change any KEY algorithm types. >In hindsight, it would have been nice to eliminate types >252, 253, and 254. > > Type 252 is an "indirect key". > Type 253 is "private - domain name". > Type 254 is "private - OID". Since indirect keys are not useful within DNSSEC, removing that type of key is allowable. The other two algorithms do have utility in a just-DNSSEC realm. (There is no sense throwing away functionality unless it causes operational or functional problems.) While there are changes afoot, can an algorithm number be reserved for testing - such as for an algorithm that hasn't been developed enough to warrant an IANA assigned number? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com 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. archive: From owner-namedroppers@ops.ietf.org Wed Mar 20 10:14:26 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01797 for ; Wed, 20 Mar 2002 10:14:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nhaj-0005Ey-00 for namedroppers-data@psg.com; Wed, 20 Mar 2002 07:01:29 -0800 Received: from noc-e.ietf53.cw.net ([166.63.177.40]) by psg.com with esmtp (Exim 3.35 #1) id 16nhai-0005Es-00 for namedroppers@ops.ietf.org; Wed, 20 Mar 2002 07:01:28 -0800 Received: from antd.nist.gov (wireless-dhcp-191-16.ietf53.cw.net [166.63.191.16]) by noc-e.ietf53.cw.net (Postfix) with ESMTP id BA4DB6A922; Wed, 20 Mar 2002 09:01:27 -0600 (CST) Message-ID: <3C98A439.6AB1AD2E@antd.nist.gov> Date: Wed, 20 Mar 2002 10:01:13 -0500 From: Scott Rose Organization: NIST X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: Eliminating KEY Algorithms References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward Lewis wrote: > At 11:29 PM -0500 3/19/02, Daniel Massey wrote: > >draft-ietf-dnsext-restrict-key-for-dnssec-01.txt, which has > >passed WG last call, did not change any KEY algorithm types. > >In hindsight, it would have been nice to eliminate types > >252, 253, and 254. > > > > Type 252 is an "indirect key". > > Type 253 is "private - domain name". > > Type 254 is "private - OID". > > Since indirect keys are not useful within DNSSEC, removing that type of key > is allowable. The other two algorithms do have utility in a just-DNSSEC > realm. (There is no sense throwing away functionality unless it causes > operational or functional problems.) > I agree with Ed here. 252 could be obseleted and freed up, but there is still some use to 253 and 254. I don't know if anyone actually is using them, but there isn't any harm in keeping them in, is there? > > While there are changes afoot, can an algorithm number be reserved for > testing - such as for an algorithm that hasn't been developed enough to > warrant an IANA assigned number? > Maybe redefinition of the 253 number? for "private" instead of "private - domain name"? either way, private is private. Most servers would not understand experimental algorithms anyway. Scott -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 20 11:02:53 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03337 for ; Wed, 20 Mar 2002 11:02:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16niFS-0005zv-00 for namedroppers-data@psg.com; Wed, 20 Mar 2002 07:43:34 -0800 Received: from virgo.cus.cam.ac.uk ([131.111.8.20]) by psg.com with esmtp (Exim 3.35 #1) id 16niFR-0005zp-00 for namedroppers@ops.ietf.org; Wed, 20 Mar 2002 07:43:34 -0800 Received: from cet1 by virgo.cus.cam.ac.uk with local (Exim 4.01) id 16niFA-0005eP-00; Wed, 20 Mar 2002 15:43:16 +0000 Subject: Re: Eliminating KEY Algorithms To: scottr@antd.nist.gov (Scott Rose) Date: Wed, 20 Mar 2002 15:43:16 +0000 (GMT) Cc: lewis@tislabs.com, namedroppers@ops.ietf.org In-Reply-To: <3C98A439.6AB1AD2E@antd.nist.gov> from "Scott Rose" at Mar 20, 2 10:01:13 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: From: Chris Thompson Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit scottr@antd.nist.gov (Scott Rose) writes > > Edward Lewis wrote: [...] > > While there are changes afoot, can an algorithm number be reserved for > > testing - such as for an algorithm that hasn't been developed enough to > > warrant an IANA assigned number? > > > > Maybe redefinition of the 253 number? for "private" instead of "private - > domain name"? either way, private is private. Most servers would not > understand experimental algorithms anyway. This is how I read RFC 2535 section 3.2 in the first place. The "domain name" is just there to (maybe) ensure uniqueness, and has no other semantic content. To use test42.bizarre-ideas.cet1.ucs.cam.ac.uk for this purpose, I just have to persuade those responsible for ucs.cam.ac.uk that they will tell other people to use somthing not under cet1.ucs.cam.ac.uk for such a purpose. Or if I am lazy, maybe I don't actually bother to do that negotiation, and just hope for the best: it's only for testing ... :) Perhaps the really slovenly can just use the root domain "." ? Chris Thompson Email: cet1@cam.ac.uk -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 20 11:13:25 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03683 for ; Wed, 20 Mar 2002 11:13:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16niYR-0006KX-00 for namedroppers-data@psg.com; Wed, 20 Mar 2002 08:03:11 -0800 Received: from roam.psg.com ([166.63.190.213]) by psg.com with esmtp (Exim 3.35 #1) id 16niYQ-0006KR-00 for namedroppers@ops.ietf.org; Wed, 20 Mar 2002 08:03:10 -0800 Received: from randy by roam.psg.com with local (Exim 4.00) id 16niYP-0006H3-00; Wed, 20 Mar 2002 10:03:09 -0600 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: Eliminating KEY Algorithms References: <3C98102E.A29BF688@isi.edu> Message-Id: Date: Wed, 20 Mar 2002 10:03:09 -0600 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> Type 252 is an "indirect key". >> Type 253 is "private - domain name". >> Type 254 is "private - OID". > Since indirect keys are not useful within DNSSEC, removing that type of key > is allowable. The other two algorithms do have utility in a just-DNSSEC > realm. (There is no sense throwing away functionality unless it causes > operational or functional problems.) for we the uneducated, you might enumerate the specific utility they have. > While there are changes afoot, can an algorithm number be reserved for > testing - such as for an algorithm that hasn't been developed enough to > warrant an IANA assigned number? there is a generic draft afoot to address this issue in many of the iana number spaces. so per-space solutions might not be useful and might confuse folk down the pike. randy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 20 11:49:51 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04964 for ; Wed, 20 Mar 2002 11:49:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nj6G-00074c-00 for namedroppers-data@psg.com; Wed, 20 Mar 2002 08:38:08 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.35 #1) id 16nj6F-00074V-00 for namedroppers@ops.ietf.org; Wed, 20 Mar 2002 08:38:07 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 2E7BF28F51 for ; Wed, 20 Mar 2002 08:38:07 -0800 (PST) (envelope-from vixie@as.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-01.txt In-Reply-To: Message from Robert Elz of "Wed, 20 Mar 2002 15:56:21 +0700." <3064.1016614581@brandenburg.cs.mu.OZ.AU> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Wed, 20 Mar 2002 08:38:07 -0800 Message-Id: <20020320163807.2E7BF28F51@as.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Once again, no-one has done that for A6 (it would be kind of difficult, > as it is trivially easy to show that it does work in simple cases). indeed. A6 and DNAME work. BIND9 implements the whole shebang, and it's been tested in some labs hereabouts. however, bitstring labels slow BIND9 down by quite a lot -- there were fundamental architecture choices that had to be made "expensively" due to properties of bitstring. it would probably be worth 25% to 50% on benchmark results to take them out. we're doing "make" all over again. ("the next morning i realized that i'd restricted leading whitespace to have to be tab characters, but by that time i couldn't change it to allow spaces as well, because five other sites had downloaded it and i didn't want to break compatibility.") recalling the embedded devices that do AAAA lookups seems to not be possible. even though we've got some flag days coming up for the authority servers who want to run IPv6 (EDNS and DNSSEC come to mind), the existing installed base of AAAA queriers, while of size ~0, is of size >0. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 20 11:50:20 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04999 for ; Wed, 20 Mar 2002 11:50:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nj5q-00073m-00 for namedroppers-data@psg.com; Wed, 20 Mar 2002 08:37:42 -0800 Received: from sentry.gw.tislabs.com ([192.94.214.100]) by psg.com with esmtp (Exim 3.35 #1) id 16nj5p-00073f-00; Wed, 20 Mar 2002 08:37:41 -0800 Received: by sentry.gw.tislabs.com; id LAA13286; Wed, 20 Mar 2002 11:43:19 -0500 (EST) Received: from test.netsec.tislabs.com(199.171.39.2) by sentry.gw.tislabs.com via smap (V5.5) id xma013266; Wed, 20 Mar 02 11:43:08 -0500 X-Sender: lewis@166.63.190.161 Message-Id: In-Reply-To: References: <3C98102E.A29BF688@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 20 Mar 2002 11:37:42 -0500 To: Randy Bush From: Edward Lewis Subject: Re: Eliminating KEY Algorithms Cc: Edward Lewis , namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:03 AM -0500 3/20/02, Randy Bush wrote: >> Since indirect keys are not useful within DNSSEC, removing that type of key >> is allowable. The other two algorithms do have utility in a just-DNSSEC >> realm. (There is no sense throwing away functionality unless it causes >> operational or functional problems.) > >for we the uneducated, you might enumerate the specific utility they >have. talk about needing to dust off old memories... Back in the DNSSEC WG days I seem to recall (but haven't had time to research the archives) that we wrote off indirect keys as not being usable for the on-line problem of protecting zone data. Because of that, I paid no more attention to the indirect keys. Donald or Olafur probably have a clearer understanding of what the indirect keys were for. As I say, this is a recollection. I need to find out if this is documented somewhere. It isn't in the 2535-2540 or so RFCs, nor 3008. PS, 2535 contains this passage at the bottom of page 43: >Algorithm code point 252 is designated to indicate "indirect" keys, to be > defined in a separate document, where the actual key is elsewhere. Elsewhere is not defined anywhere, making tracking of this difficult. Not to pick on Donald, but this is an example of why I pound on documents for inclusion of (detailed) rationale, and if a topic is "out of scope" at least indicate where the topic might be found. BTW, the DNSSEC WG archives are still on-line: ftp client (not web) to ftp.tislabs.com cd /pub/lists/dns-security -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com 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. archive: From owner-namedroppers@ops.ietf.org Wed Mar 20 11:51:39 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05039 for ; Wed, 20 Mar 2002 11:51:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nj9Z-00079W-00 for namedroppers-data@psg.com; Wed, 20 Mar 2002 08:41:33 -0800 Received: from roam.psg.com ([166.63.190.213]) by psg.com with esmtp (Exim 3.35 #1) id 16nj9Z-00079P-00 for namedroppers@ops.ietf.org; Wed, 20 Mar 2002 08:41:33 -0800 Received: from randy by roam.psg.com with local (Exim 4.00) id 16nj9Y-0006Jv-00; Wed, 20 Mar 2002 10:41:32 -0600 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: Eliminating KEY Algorithms References: <3C98102E.A29BF688@isi.edu> Message-Id: Date: Wed, 20 Mar 2002 10:41:32 -0600 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>> Since indirect keys are not useful within DNSSEC, removing that type of key >>> is allowable. The other two algorithms do have utility in a just-DNSSEC >>> realm. (There is no sense throwing away functionality unless it causes >>> operational or functional problems.) >> >> for we the uneducated, you might enumerate the specific utility they >> have. > > talk about needing to dust off old memories... > > Back in the DNSSEC WG days I seem to recall (but haven't had time to > research the archives) that we wrote off indirect keys as not being usable > for the on-line problem of protecting zone data. Because of that, I paid > no more attention to the indirect keys. Donald or Olafur probably have a > clearer understanding of what the indirect keys were for. > > As I say, this is a recollection. I need to find out if this is documented > somewhere. It isn't in the 2535-2540 or so RFCs, nor 3008. > > PS, 2535 contains this passage at the bottom of page 43: > > >Algorithm code point 252 is designated to indicate "indirect" keys, to be > > defined in a separate document, where the actual key is elsewhere. > > Elsewhere is not defined anywhere, making tracking of this difficult. Not > to pick on Donald, but this is an example of why I pound on documents for > inclusion of (detailed) rationale, and if a topic is "out of scope" at > least indicate where the topic might be found. sounds to me like it would be a good test of the iana key alg number allocation process when we find the justification and need. randy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 20 12:03:44 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05604 for ; Wed, 20 Mar 2002 12:03:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16njIU-0007Ou-00 for namedroppers-data@psg.com; Wed, 20 Mar 2002 08:50:46 -0800 Received: from sentry.gw.tislabs.com ([192.94.214.100]) by psg.com with esmtp (Exim 3.35 #1) id 16njIT-0007Oh-00; Wed, 20 Mar 2002 08:50:45 -0800 Received: by sentry.gw.tislabs.com; id LAA13582; Wed, 20 Mar 2002 11:56:23 -0500 (EST) Received: from test.netsec.tislabs.com(199.171.39.2) by sentry.gw.tislabs.com via smap (V5.5) id xma013567; Wed, 20 Mar 02 11:56:17 -0500 X-Sender: lewis@166.63.190.161 Message-Id: In-Reply-To: References: <3C98102E.A29BF688@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 20 Mar 2002 11:44:54 -0500 To: Randy Bush From: Edward Lewis Subject: Re: Eliminating KEY Algorithms Cc: Edward Lewis , namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:41 AM -0500 3/20/02, Randy Bush wrote: >sounds to me like it would be a good test of the iana key alg number >allocation process when we find the justification and need. I agree. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com 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. archive: From owner-namedroppers@ops.ietf.org Wed Mar 20 12:04:59 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05736 for ; Wed, 20 Mar 2002 12:04:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16njLb-0007Vf-00 for namedroppers-data@psg.com; Wed, 20 Mar 2002 08:53:59 -0800 Received: from funnel.cisco.com ([161.44.168.79]) by psg.com with esmtp (Exim 3.35 #1) id 16njLa-0007VU-00 for namedroppers@ops.ietf.org; Wed, 20 Mar 2002 08:53:58 -0800 Received: from cisco.com (che-vpn1-27.cisco.com [10.86.240.27]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA02087; Wed, 20 Mar 2002 11:53:56 -0500 (EST) Message-ID: <3C98BE83.3EBF55D2@cisco.com> Date: Wed, 20 Mar 2002 11:53:23 -0500 From: Josh Littlefield Organization: Cisco Systems X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Edward Lewis CC: namedroppers@ops.ietf.org Subject: Re: Eliminating KEY Algorithms References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I would think that indirect keys might have utility for SIG(0). SIG(0) is the only remaining use of keys aside from zone signing, but it has requirements somewhat different from zone signing. I would think indirect keys could be useful for key management of keys used for secure updates and other transactions. Perhaps private algorithms would also be useful for this, in some tightly controlled deployments. Edward Lewis wrote: > > At 11:29 PM -0500 3/19/02, Daniel Massey wrote: > >draft-ietf-dnsext-restrict-key-for-dnssec-01.txt, which has > >passed WG last call, did not change any KEY algorithm types. > >In hindsight, it would have been nice to eliminate types > >252, 253, and 254. > > > > Type 252 is an "indirect key". > > Type 253 is "private - domain name". > > Type 254 is "private - OID". > > Since indirect keys are not useful within DNSSEC, removing that type of key > is allowable. The other two algorithms do have utility in a just-DNSSEC > realm. (There is no sense throwing away functionality unless it causes > operational or functional problems.) > > While there are changes afoot, can an algorithm number be reserved for > testing - such as for an algorithm that hasn't been developed enough to > warrant an IANA assigned number? > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis NAI Labs > Phone: +1 443-259-2352 Email: lewis@tislabs.com > > 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. > archive: -- ===================================================================== Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 250 Apollo Drive tel: 978-497-8378 fax: same Chelmsford, MA 01824-3627 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 20 12:10:01 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05907 for ; Wed, 20 Mar 2002 12:10:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16njPe-0007cr-00 for namedroppers-data@psg.com; Wed, 20 Mar 2002 08:58:10 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.35 #1) id 16njPd-0007ck-00 for namedroppers@ops.ietf.org; Wed, 20 Mar 2002 08:58:09 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 412B628F50 for ; Wed, 20 Mar 2002 08:58:09 -0800 (PST) (envelope-from vixie@as.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: notes from my conversation with keith moore concerning a6/dname In-Reply-To: Message from Robert Elz of "Wed, 20 Mar 2002 16:11:07 +0700." <3086.1016615467@brandenburg.cs.mu.OZ.AU> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Wed, 20 Mar 2002 08:58:09 -0800 Message-Id: <20020320165809.412B628F50@as.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > We could easily make the transition to A6 happen at the same time servers > start sending queries using IPv6 transport (the number of those that exist > now - in use - is miniscule). that's an interesting possibility, it would let us declare a flag day for the recursive/forwarding servers. my hunch is that it would complicate life for the 6to4 people to say that pre-V6 recursive/forwarding servers could not be used to serve V6 islands. it bugs me that there was and remains no architecture or plan for this stuff. > | > renumbering, either for A RR's or AAAA RR's, could be aided as much by > | > a zone preprocessor running on the primary, as it would be by A6. > > No, that's simply wrong. Aside from the previous discussion on this list > in the past few days, this requires the renumbered site to know it has been > renumbered. While many of you simply can't conceive of a renumbering > where the affected site never knows it happened - I certainly can, and it > is something I would like to work toward making possible. as long as i'm still hard coding addresses for things like master name servers for AXFR purposes and other similar uses, blind renumbering will not be possible. i agree that A6 leaves this door open but i do not believe that the IETF leadership cares about quick or nimble renumbering for IPv6, and absent such care, they are going to put A6/DNAME into the field of weeds called "experimental." the two saving graces, should this occur, are (1) we can rip most of the "go slow" code out of BIND9, and (2) the whole TLA/subTLA "address as path" addressing architecture seems to have collapsed, and nonaggregatable /35's and maybe even /32's are getting handed out by the V6 RIR's, which means the whole mess is back to BGP filtering for guidance, just like V4 is now. raw/pure AAAA alongside the TLA/subTLA "address as path" architecture would have been anticompetitive in the extreme, and would have restricted IPv6 to small networks or the edges of large (NAT'ed) networks. but pure/raw AAAA alongside "anything goes" V6 allocation is just a routing problem and will probably drive the router economy but that's presumably acceptable (or else the IETF leadership would care more about quick/nimble renumbering.) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 20 12:22:38 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06456 for ; Wed, 20 Mar 2002 12:22:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16njZO-0007uk-00 for namedroppers-data@psg.com; Wed, 20 Mar 2002 09:08:14 -0800 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.35 #1) id 16njZN-0007uQ-00 for namedroppers@ops.ietf.org; Wed, 20 Mar 2002 09:08:13 -0800 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA13108; Wed, 20 Mar 2002 12:08:07 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA11455; Wed, 20 Mar 2002 12:08:05 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id MAA25731; Wed, 20 Mar 2002 12:08:03 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id MAA29328; Wed, 20 Mar 2002 12:08:02 -0500 (EST) To: Robert Elz Cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: notes from my conversation with keith moore concerning a6/dname References: <20020320050141.BE00428F50@as.vix.com> <3086.1016615467@brandenburg.cs.mu.OZ.AU> From: Derek Atkins Date: 20 Mar 2002 12:08:02 -0500 In-Reply-To: <3086.1016615467@brandenburg.cs.mu.OZ.AU> Message-ID: Lines: 34 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Robert Elz writes: > ever having to know what their prefix is. This is not too hard for > reverse lookups (the delegated zone is the same whatever its > delegation point, provided it occurs at the same depth in the tree > and as long as it doesn't try and include RR values that are inside > the domain) but for the forward zone, A6 is the only current answer. I disagree. The reverse tree needs to know where in the tree it is, because it needs to know the full zone that is is serving. A DNS request is not made for a partial domain name (even in the reverse tree). Therefore, if a request is made for an ipv6 address, we have the problem that the request is made for: 1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.ip6.arpa. Assume that you were delegated a /64, so your dns configuration is: @ IN SOA () 1.2.3.4.5.6.7.8 IN PTR my-host.my.domain. The problem is that you need to know what your domain should be! If you get renumbered, then you need to know so you can change your dns configuration from .ip6.arpa to .ip6.arpa. This cannot be automated -- it requires user intervention. -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. archive: From owner-namedroppers@ops.ietf.org Wed Mar 20 12:26:17 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06619 for ; Wed, 20 Mar 2002 12:26:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16njbY-0007zr-00 for namedroppers-data@psg.com; Wed, 20 Mar 2002 09:10:28 -0800 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.35 #1) id 16njbX-0007zj-00 for namedroppers@ops.ietf.org; Wed, 20 Mar 2002 09:10:28 -0800 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id MAA08295; Wed, 20 Mar 2002 12:10:26 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA29275; Wed, 20 Mar 2002 12:10:25 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id MAA13988; Wed, 20 Mar 2002 12:10:24 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id MAA29331; Wed, 20 Mar 2002 12:10:24 -0500 (EST) To: Robert Elz Cc: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-01.txt References: <20020317233134.7934.qmail@cr.yp.to> <20020316100633.13581.qmail@cr.yp.to> <20020307125951.J2674-100000@node10c4d.a2000.nl> <2cy9gt7u2i.fsf@snout.autonomica.se> <20020315182114.958EA46B@thangorodrim.hactrn.net> <2cadt9zebs.fsf@snout.autonomica.se> <2430.1016267951@brandenburg.cs.mu.OZ.AU> <20020316100633.13581.qmail@cr.yp.to> <388.1016350151@brandenburg.cs.mu.OZ.AU> <3712.1016539773@brandenburg.cs.mu.OZ.AU> <3064.1016614581@brandenburg.cs.mu.OZ.AU> From: Derek Atkins Date: 20 Mar 2002 12:10:24 -0500 In-Reply-To: <3064.1016614581@brandenburg.cs.mu.OZ.AU> Message-ID: Lines: 39 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Frequency of signature is directly related to frequency of changes. If you sign a zone once a month (say on the 1st), but then add (or remove) records on, say, day 2 of the month, then there is an attack where your added (or removed) records can be replayed without detection. -derek Robert Elz writes: > Date: 19 Mar 2002 10:27:51 -0500 > From: Derek Atkins > Message-ID: > > | The point was that the zone gets resigned frequently. > > No it doesn't. That's just a theory of operation which is not > required at all (and is required even less for zones that contain > only the tail end of A6 records). Signing the zone once a month, > and perhaps less frequently, is likely to be just fine for many sites. > > Please stop telling me ways that it is possible to operate that happen > to fit with your theory of how the world should work. Allow sites to > operate in ways that meet their own needs - even if that's something that > you would never personally do. And don't cut off options just because > they're not useful to your way of operating - only if you can show that > they actually don't work. > > Once again, no-one has done that for A6 (it would be kind of difficult, > as it is trivially easy to show that it does work in simple cases). > > kre > -- 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. archive: From owner-namedroppers@ops.ietf.org Wed Mar 20 12:42:19 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07259 for ; Wed, 20 Mar 2002 12:42:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16njtg-0008aY-00 for namedroppers-data@psg.com; Wed, 20 Mar 2002 09:29:12 -0800 Received: from sentry.gw.tislabs.com ([192.94.214.100]) by psg.com with esmtp (Exim 3.35 #1) id 16njte-0008aR-00; Wed, 20 Mar 2002 09:29:11 -0800 Received: by sentry.gw.tislabs.com; id MAA14722; Wed, 20 Mar 2002 12:34:48 -0500 (EST) Received: from test.netsec.tislabs.com(199.171.39.2) by sentry.gw.tislabs.com via smap (V5.5) id xma014711; Wed, 20 Mar 02 12:34:46 -0500 X-Sender: lewis@166.63.190.161 Message-Id: In-Reply-To: References: <3C98102E.A29BF688@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 20 Mar 2002 12:29:28 -0500 To: Randy Bush From: Edward Lewis Subject: Re: Eliminating KEY Algorithms Cc: Edward Lewis , namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:41 AM -0500 3/20/02, Randy Bush wrote: >>>> Since indirect keys are not useful within DNSSEC, removing that type >>>>of key >>>> is allowable. The other two algorithms do have utility in a just-DNSSEC >>>> realm. (There is no sense throwing away functionality unless it causes >>>> operational or functional problems.) >>> >>> for we the uneducated, you might enumerate the specific utility they >>> have. Culled from the archives. indirect-key is mentioned off and on until the agenda for the Oslo meeting, but then disappears from the archives, although I didn't locate the minutes of that meeting, "indirect" does not appear in any greps after that. (dns-security was shut down in Spring 2000.) >Date: Wed, 10 Dec 1997 22:51:51 -0500 (EST) >From: "Donald E. Eastlake 3rd" >To: dns-security@ex.tis.com >Subject: Re: WG Last Call: draft-ietf-dnssec-indirect-key-01.txt > >On Sun, 7 Dec 1997, John Gilmore wrote: > >> Date: Sun, 07 Dec 1997 21:10:02 -0800 >> From: John Gilmore >> To: dns-security@ex.tis.com, gnu@toad.com >> Subject: Re: WG Last Call: draft-ietf-dnssec-indirect-key-01.txt >> >> It is not clear what problem this draft is trying to solve. > >This draft is based on the assumption that key distribution via DNS >becomes reasonably common. At least common enough that people go look >first in the DNS for user/host keys. Then it seems like there would be a >number of cases where you would want to use this because they have a >bunch of keys/certificates elsewhere and want to tell the people looking >in DNS to go use their existing key/certificate server. > The impetus for writing the draft came from an actual large ISP that >indicated it didn't want to have to put a bunch of user keys into the DNS >and keep them updated there but would find it much easier to just have >DNS entries pointing to its key server. > >> The "target type" field seems to be encoding numerous separate kinds >> of information (e.g. the format of the location data (URL or domain >> name); the format of the data to be retrieved there (KEY RDATA, >> CERT RDATA, PKCS #1, etc); and the "type" of certificate that might >> be found there (PKIX, PGP, etc). Rather than encode various >> combinations of these, wouldn't separate fields be better? > >The -00 draft had this more orthogonal. But the total number of >combinations just doesn't seem that high and if you make these things >orthogonal, there are number of combinations that don't make sense. I >guess I'd be willing to change back if people want. > >> John > >Donald -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com 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. archive: From owner-namedroppers@ops.ietf.org Wed Mar 20 15:28:34 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13764 for ; Wed, 20 Mar 2002 15:28:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16nmPT-000C7S-00 for namedroppers-data@psg.com; Wed, 20 Mar 2002 12:10:11 -0800 Received: from sentry.gw.tislabs.com ([192.94.214.100]) by psg.com with esmtp (Exim 3.35 #1) id 16nmPS-000C7M-00 for namedroppers@ops.ietf.org; Wed, 20 Mar 2002 12:10:10 -0800 Received: by sentry.gw.tislabs.com; id PAA18313; Wed, 20 Mar 2002 15:15:47 -0500 (EST) Received: from test.netsec.tislabs.com(199.171.39.2) by sentry.gw.tislabs.com via smap (V5.5) id xma018303; Wed, 20 Mar 02 15:15:17 -0500 X-Sender: lewis@166.63.185.5 (Unverified) Message-Id: In-Reply-To: <3C98BE83.3EBF55D2@cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 20 Mar 2002 15:09:58 -0500 To: Josh Littlefield From: Edward Lewis Subject: Re: Eliminating KEY Algorithms Cc: Edward Lewis , namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:53 AM -0500 3/20/02, Josh Littlefield wrote: >I would think that indirect keys might have utility for SIG(0). My later posting of the archived rationale isn't meant to dispute that...perhaps you have something here, I just haven't spent enough time on SIG(0). -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com 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. archive: From owner-namedroppers@ops.ietf.org Thu Mar 21 05:59:18 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08581 for ; Thu, 21 Mar 2002 05:59:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16o02P-0006EN-00 for namedroppers-data@psg.com; Thu, 21 Mar 2002 02:43:17 -0800 Received: from 96-1.nat.psu.ac.th ([202.28.96.1] helo=brandenburg.cs.mu.OZ.AU) by psg.com with esmtp (Exim 3.35 #1) id 16o02O-0006EA-00 for namedroppers@ops.ietf.org; Thu, 21 Mar 2002 02:43:16 -0800 Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g2LAnlJ02497; Thu, 21 Mar 2002 17:49:49 +0700 (ICT) From: Robert Elz To: Paul Vixie cc: namedroppers@ops.ietf.org Subject: Re: notes from my conversation with keith moore concerning a6/dname In-Reply-To: <20020320165809.412B628F50@as.vix.com> References: <20020320165809.412B628F50@as.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Mar 2002 17:49:47 +0700 Message-ID: <2495.1016707787@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Wed, 20 Mar 2002 08:58:09 -0800 From: Paul Vixie Message-ID: <20020320165809.412B628F50@as.vix.com> | as long as i'm still hard coding addresses for things like master name | servers for AXFR purposes and other similar uses, blind renumbering will | not be possible. You mean it won't be possible for some. Certainly, though when it gets needed, ways around this can probably be found (I can generate a named.conf from a script/program if I need to, and I can do that every 10 minutes if that's required). But even without that, small sites, serving only their own domain, don't need any addresses in any named.conf (other than the reverse zone I mostly botched yesterday) that will be subject to renumbering. The primary server just has the name of the file containing the zone, and the zone contains A6 records for addresses. The secondary server has the primary server's site local address configured into it. resolv.conf files either get built dynamically, or have site local addresses configured in them. Even with current technology, it certainly is possible. But for the things where there are problems in current implementations (an off site secondary would have the site's global address currently configured into it's config, and so have to be updated) fixes, corrections, improvements, can be made as the need arises - and need only be installed by those who need them. That's the difference with A6 - it can't be installed just by those who need it - it is an internet wide decision - what RR type is requested in lookup messages, and what is the form of the responses. It is something everyone needs to agree on, so can never really be adjusted once it has been significantly deployed. | "go slow" code out of BIND9, and (2) the whole TLA/subTLA "address as path" | addressing architecture seems to have collapsed, Yes, it seems that people have gone back to believing that aggregation can be ignored. Whether that's correct or not doesn't matter too much, as we can always fix aggregation later if it turns out to be necessary, by just renumbering lots of places (one at a time, as needed). There are plausible fixes for almost everything that might be a mistake that's being made now. Except for failure to adopt A6 - that decision would put us into a corner that there's simply no way out of. Even if the worst nightmares of bad A6 configs come true, we could fix that - servers that simply refuse to process A6 other than in the cases deemed safe (worst case, A6 0 only, or whole A6 chain in the packet, or whatever else was deemed necessary at the time) could be deployed at enough important sites around the net, that the operators of servers would soon learn that they have to follow the new rules, or their names simply don't work at lots of places (just as a whole bunch of people managed to be convinced that _ wasn't legal in domain names by deploying software that told them that...) A6, with some guidelines on how people should actually configure it most likely, is the only sane way to progress. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 21 06:08:33 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08721 for ; Thu, 21 Mar 2002 06:08:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16o0I0-0006dp-00 for namedroppers-data@psg.com; Thu, 21 Mar 2002 02:59:24 -0800 Received: from 96-1.nat.psu.ac.th ([202.28.96.1] helo=brandenburg.cs.mu.OZ.AU) by psg.com with esmtp (Exim 3.35 #1) id 16o0Hz-0006di-00 for namedroppers@ops.ietf.org; Thu, 21 Mar 2002 02:59:23 -0800 Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g2LB5xJ02521; Thu, 21 Mar 2002 18:06:02 +0700 (ICT) From: Robert Elz To: Derek Atkins cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: notes from my conversation with keith moore concerning a6/dname In-Reply-To: References: <20020320050141.BE00428F50@as.vix.com> <3086.1016615467@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Mar 2002 18:05:59 +0700 Message-ID: <2519.1016708759@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: 20 Mar 2002 12:08:02 -0500 From: Derek Atkins Message-ID: | The reverse tree needs to know where in the tree it is, Ah yes, of course, that part of my brain must have been switched off yesterday. But ... | If you | get renumbered, then you need to know so you can change your dns | configuration from .ip6.arpa to .ip6.arpa. | This cannot be automated -- it requires user intervention. No, not at all. It currently requires user intervention. This doesn't have to be true for ever, this is server config info, the server has to find out the info from somewhere, but it could easily be implemented by having something like zone $REV_A6(my-name.my-isp.net).IP6.INT { } in named.conf (or equiv for other servers). That is, look up the A6 0 record that your ISP provides for you, take the address from that and reverse it, to form the zone name, which is what tells you where you are in the tree. This is just a SMOP (including dealing with remembering the TTL, refreshing the lookup as requried, doing the equivalent of "ndc reconfig" whenever the A6 record changes, ... - so perhaps not so S, but still just a MOP). I also thought that this was what DNAME was supposed to allow to work. But even without any of that, the kind of simple organisation that I'm concerned about can, if they want, have automatic renumbering, forward and backward, today, with just A6. The forward is easy, that was yesterday's message. The reverse just uses the rfc2317 technique. That is, the ISP actually runs the IP6.INT domain for the client (the natural one) but then has CNAME records for the client's forward addresses, that refer to names in some (constant) zone that the client manages for themselves. When the client adds new systems they need to contact the ISP to get new CNAME records added (doing CNAMEs for a whole IPv6 /64 isn't the same as doing it for an IPv4 /27...), but that's possible (and can be automated - even just using DynDNS at the ISP today) and is done only when the client knows they're making a change. WHen the client gets renumbered, they really don't have to know about it at all - the only queries sent to them (A6 or PTR, or anything else) are all inside their known domain name. In any case, the message is not to give up on A6 just because it seems like that some of the problems it is useful to help with,look like they have difficulties in other areas. All those other difficulties (that I can think of now anyway) can be solved by local incremental upgrades. A6 cannot be. It needs to remain, not be farmed out to experimental (ie: dead). kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 21 06:08:52 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08738 for ; Thu, 21 Mar 2002 06:08:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16o0Jy-0006iO-00 for namedroppers-data@psg.com; Thu, 21 Mar 2002 03:01:26 -0800 Received: from 96-1.nat.psu.ac.th ([202.28.96.1] helo=brandenburg.cs.mu.OZ.AU) by psg.com with esmtp (Exim 3.35 #1) id 16o0Jx-0006hc-00 for namedroppers@ops.ietf.org; Thu, 21 Mar 2002 03:01:26 -0800 Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g2LB8FJ02534; Thu, 21 Mar 2002 18:08:15 +0700 (ICT) From: Robert Elz To: Derek Atkins cc: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-01.txt In-Reply-To: References: <20020317233134.7934.qmail@cr.yp.to> <20020316100633.13581.qmail@cr.yp.to> <20020307125951.J2674-100000@node10c4d.a2000.nl> <2cy9gt7u2i.fsf@snout.autonomica.se> <20020315182114.958EA46B@thangorodrim.hactrn.net> <2cadt9zebs.fsf@snout.autonomica.se> <2430.1016267951@brandenburg.cs.mu.OZ.AU> <20020316100633.13581.qmail@cr.yp.to> <388.1016350151@brandenburg.cs.mu.OZ.AU> <3712.1016539773@brandenburg.cs.mu.OZ.AU> <3064.1016614581@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Mar 2002 18:08:15 +0700 Message-ID: <2532.1016708895@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: 20 Mar 2002 12:10:24 -0500 From: Derek Atkins Message-ID: | Frequency of signature is directly related to frequency of changes. Yes, of course. But some zones never change. Literally never change. The signatures (and the TTLs) still shouldn't last forever, but expecting things that never change to be resigned every day or week, just because some other zone which might be subject to sudden changes needs that, is absurd. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 21 08:20:40 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10081 for ; Thu, 21 Mar 2002 08:20:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16o2Mp-000AKZ-00 for namedroppers-data@psg.com; Thu, 21 Mar 2002 05:12:31 -0800 Received: from citadel.cequrux.com ([192.96.22.18]) by psg.com with esmtp (Exim 3.35 #1) id 16o2Mn-000AJC-00 for namedroppers@ops.ietf.org; Thu, 21 Mar 2002 05:12:29 -0800 Received: (from nobody@localhost) by citadel.cequrux.com (8.8.8/8.6.9) id PAA01231 for ; Thu, 21 Mar 2002 15:12:21 +0200 (SAST) Received: by citadel.cequrux.com via recvmail id 1229; Thu Mar 21 15:11:35 2002 Date: Thu, 21 Mar 2002 15:11:35 +0200 From: Alan Barrett To: namedroppers@ops.ietf.org Subject: Re: notes from my conversation with keith moore concerning a6/dname Message-ID: <20020321131135.GL371@apb.cequrux.com> References: <20020320050141.BE00428F50@as.vix.com> <3086.1016615467@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 20 Mar 2002, Derek Atkins wrote: > The reverse tree needs to know where in the tree it is, > because it needs to know the full zone that is is serving. Yes, but DNAME would allow the zone that is bing served to have a name that's very different from the name that the client originally asked for. > if a request is made for an ipv6 address, we have the problem that the > request is made for: > > 1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.ip6.arpa. > > Assume that you were delegated a /64 [...] In a world with DNAME, your upstream could say something like 9.10.11.12.13.14.15.16.ip6.arpa. DNAME \ reverse-tree.your-forward-domain.example. > so your dns configuration is: > > @ IN SOA () > > 1.2.3.4.5.6.7.8 IN PTR my-host.my.domain. > > The problem is that you need to know what your domain should be! No problem in a world with DNAME. The origin for that zone is "reverse-tree.your-forward-domain.example." > If you get renumbered, then you need to know so you can change your > dns configuration from .ip6.arpa to .ip6.arpa. > This cannot be automated -- it requires user intervention. It could be automated. Not in today's world, but I would like to see a future in which an upstream ISP could renumber their customers without the customers having to do anything by hand. Deprecating A6 and DNAME will make that future much more difficult to reach. I agree with KRE that if we deprecate A6 now, we will probably never have an opportunity to put it back, but if we deprecate DNAME now, we will have another chance later. --apb (Alan Barrett) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 21 09:37:56 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12060 for ; Thu, 21 Mar 2002 09:37:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16o3Pg-000CEu-00 for namedroppers-data@psg.com; Thu, 21 Mar 2002 06:19:32 -0800 Received: from roam.psg.com ([166.63.186.128]) by psg.com with esmtp (Exim 3.35 #1) id 16o3Pg-000CEn-00 for namedroppers@ops.ietf.org; Thu, 21 Mar 2002 06:19:32 -0800 Received: from randy by roam.psg.com with local (Exim 4.00) id 16o3Pf-0000CI-00 for namedroppers@ops.ietf.org; Thu, 21 Mar 2002 08:19:31 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20020320114739.23997.qmail@cr.yp.to> References: <2cy9gt7u2i.fsf@snout.autonomica.se> <20020315182114.958EA46B@thangorodrim.hactrn.net> <2cadt9zebs.fsf@snout.autonomica.se> <2430.1016267951@brandenburg.cs.mu.OZ.AU> <20020316100633.13581.qmail@cr.yp.to> <388.1016350151@brandenburg.cs.mu.OZ.AU> <3712.1016539773@brandenburg.cs.mu.OZ.AU> <3064.1016614581@brandenburg.cs.mu.OZ.AU> Date: 20 Mar 2002 11:47:39 -0000 From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-01.txt Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber ] Robert Elz writes: > Signing the zone once a month, and perhaps less frequently, > is likely to be just fine for many sites. No! If you're signing only once a month (plus unscheduled changes), then you're using expiration dates at least a month away, so an attacker can block a change until the end of the month. This is a security violation at every site I've seen; changes have to take effect much more quickly than that. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 21 10:27:10 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13688 for ; Thu, 21 Mar 2002 10:27:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16o4HD-000Dqo-00 for namedroppers-data@psg.com; Thu, 21 Mar 2002 07:14:51 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.35 #1) id 16o4HD-000Dqi-00 for namedroppers@ops.ietf.org; Thu, 21 Mar 2002 07:14:51 -0800 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 85BAD3190C; Thu, 21 Mar 2002 07:14:50 -0800 (PST) To: Robert Elz Cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: notes from my conversation with keith moore concerning a6/dname In-Reply-To: Message from Robert Elz of "Thu, 21 Mar 2002 17:49:47 +0700." <2495.1016707787@brandenburg.cs.mu.OZ.AU> Date: Thu, 21 Mar 2002 07:14:50 -0800 Message-ID: <9327.1016723690@shell.nominum.com> From: Jim Reid Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Robert" == Robert Elz writes: Robert> A6, with some guidelines on how people should actually Robert> configure it most likely, is the only sane way to progress. You may be right, up to a point. Tools for checking A6 configuration would help too. However the thought of stub resolvers having to deal with A6 or bit-string labels is too horrifying for words. I'm not sure it's a Good Thing to require that complexity in the firmware of (say) a domestic appliance or if it would even be feasible. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 21 11:09:26 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14970 for ; Thu, 21 Mar 2002 11:09:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16o4tK-000F6o-00 for namedroppers-data@psg.com; Thu, 21 Mar 2002 07:54:14 -0800 Received: from 96-1.nat.psu.ac.th ([202.28.96.1] helo=brandenburg.cs.mu.OZ.AU) by psg.com with esmtp (Exim 3.35 #1) id 16o4tJ-000F6i-00 for namedroppers@ops.ietf.org; Thu, 21 Mar 2002 07:54:13 -0800 Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g2LG11J03337; Thu, 21 Mar 2002 23:01:01 +0700 (ICT) From: Robert Elz To: Jim Reid cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: notes from my conversation with keith moore concerning a6/dname In-Reply-To: <9327.1016723690@shell.nominum.com> References: <9327.1016723690@shell.nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Mar 2002 23:01:01 +0700 Message-ID: <3335.1016726461@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Thu, 21 Mar 2002 07:14:50 -0800 From: Jim Reid Message-ID: <9327.1016723690@shell.nominum.com> | However the thought of stub resolvers having to deal | with A6 or bit-string labels is too horrifying for words. We have been through this before. Even if we wanted to make that happen it is too late now anyway. We simply have to support AAAA queries from dumb resolvers (the things that send with RD on and have no way to cope with getting an answer with RA off). I must say that the appeal of bitstrings was never as clear to me, I'd not be nearly as upset to see them silently vanish. But perhaps that's just because I'm ignorant of their potential, so no-one should consider killing them just because I'm not sure what they're good for. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 21 11:09:31 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14983 for ; Thu, 21 Mar 2002 11:09:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16o4sB-000F4t-00 for namedroppers-data@psg.com; Thu, 21 Mar 2002 07:53:03 -0800 Received: from citadel.cequrux.com ([192.96.22.18]) by psg.com with esmtp (Exim 3.35 #1) id 16o4sA-000F4n-00 for namedroppers@ops.ietf.org; Thu, 21 Mar 2002 07:53:02 -0800 Received: (from nobody@localhost) by citadel.cequrux.com (8.8.8/8.6.9) id RAA14900 for ; Thu, 21 Mar 2002 17:52:59 +0200 (SAST) Received: by citadel.cequrux.com via recvmail id 14898; Thu Mar 21 17:52:44 2002 Date: Thu, 21 Mar 2002 17:52:43 +0200 From: Alan Barrett To: namedroppers@ops.ietf.org Subject: Re: notes from my conversation with keith moore concerning a6/dname Message-ID: <20020321155243.GA27370@apb.cequrux.com> References: <2495.1016707787@brandenburg.cs.mu.OZ.AU> <9327.1016723690@shell.nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9327.1016723690@shell.nominum.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 21 Mar 2002, Jim Reid wrote: > Robert> A6, with some guidelines on how people should actually > Robert> configure it most likely, is the only sane way to progress. > > You may be right, up to a point. Tools for checking A6 configuration > would help too. However the thought of stub resolvers having to deal > with A6 or bit-string labels is too horrifying for words. I'm not sure > it's a Good Thing to require that complexity in the firmware of (say) > a domestic appliance or if it would even be feasible. That's why people have proposed putting AAAA synthesis in the recursive resolvers, leaving the stub resolvers on less capable devices to make AAAA queries as before, but allowing the zone administrators to publish A6 records. I thought that there was broad agreement to deprecate bitstring labels. --apb (Alan Barrett) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 21 11:20:58 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15545 for ; Thu, 21 Mar 2002 11:20:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16o4pU-000EzX-00 for namedroppers-data@psg.com; Thu, 21 Mar 2002 07:50:16 -0800 Received: from 96-1.nat.psu.ac.th ([202.28.96.1] helo=brandenburg.cs.mu.OZ.AU) by psg.com with esmtp (Exim 3.35 #1) id 16o4pT-000EzR-00 for namedroppers@ops.ietf.org; Thu, 21 Mar 2002 07:50:16 -0800 Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g2LFu4J03321; Thu, 21 Mar 2002 22:56:10 +0700 (ICT) From: Robert Elz To: "D. J. Bernstein" cc: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-01.txt In-Reply-To: <20020320114739.23997.qmail@cr.yp.to> References: <20020320114739.23997.qmail@cr.yp.to> <2cy9gt7u2i.fsf@snout.autonomica.se> <20020315182114.958EA46B@thangorodrim.hactrn.net> <2cadt9zebs.fsf@snout.autonomica.se> <2430.1016267951@brandenburg.cs.mu.OZ.AU> <20020316100633.13581.qmail@cr.yp.to> <388.1016350151@brandenburg.cs.mu.OZ.AU> <3712.1016539773@brandenburg.cs.mu.OZ.AU> <3064.1016614581@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Mar 2002 22:56:04 +0700 Message-ID: <3319.1016726164@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: 20 Mar 2002 11:47:39 -0000 From: "D. J. Bernstein" Message-ID: <20020320114739.23997.qmail@cr.yp.to> | No! If you're signing only once a month (plus unscheduled changes), then | you're using expiration dates at least a month away, so an attacker can | block a change until the end of the month. Yes. | This is a security violation | at every site I've seen; changes have to take effect much more quickly | than that. Sometimes they do, sometimes they don't. In any case, this is for the site concerned to decide. They need to be informed, and make their own decisions. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 21 19:39:56 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01262 for ; Thu, 21 Mar 2002 19:39:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oCjq-000D6W-00 for namedroppers-data@psg.com; Thu, 21 Mar 2002 16:16:58 -0800 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.35 #1) id 16oCjq-000D6P-00 for namedroppers@ops.ietf.org; Thu, 21 Mar 2002 16:16:58 -0800 Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g2M0Gqm20948; Thu, 21 Mar 2002 16:16:52 -0800 (PST) From: Bill Manning Message-Id: <200203220016.g2M0Gqm20948@boreas.isi.edu> Subject: DS vetting & rollout To: keydist@cafax.se, dnssec@cafax.se Date: Thu, 21 Mar 2002 16:16:51 -0800 (PST) Cc: bmanning@ISI.EDU (Bill Manning), namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit A list has been set up to discuss the vetting of DS code and propose rollout options. I expect there will be at least two workshops that will focus specifically on DS issues. One might be as soon as the end of April/early May, either in the WDC area or Northern Europe. There appear to be three varients either done or nearly done that could be tested: Olafurs code: patches to Bind9 Olafs code: patches to Net::DNS Brians code: Bind9-EFT (pre9.3.0) If interested, please subscribe at: http://mailman.isi.edu/mailman/listinfo/dnssec -- --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. archive: From owner-namedroppers@ops.ietf.org Thu Mar 21 20:09:07 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01816 for ; Thu, 21 Mar 2002 20:09:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oDEs-000FeW-00 for namedroppers-data@psg.com; Thu, 21 Mar 2002 16:49:02 -0800 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.35 #1) id 16oDEr-000FeM-00 for namedroppers@ops.ietf.org; Thu, 21 Mar 2002 16:49:01 -0800 Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g2M0mvD10600; Thu, 21 Mar 2002 16:48:57 -0800 (PST) From: Bill Manning Message-Id: <200203220048.g2M0mvD10600@boreas.isi.edu> Subject: mis-information To: dnssec@cafax.se, keydist@cafax.se, namedroppers@ops.ietf.org Date: Thu, 21 Mar 2002 16:48:57 -0800 (PST) Cc: bmanning@ISI.EDU (Bill Manning) X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I have make (yet another) mistake. I was lead to believe that there are or would be three varients of DS code in the near future and it would be reasonable to start talking about testing plans. I have been informed that while there are plans and and potential for multiple sources, only a single implementation is currently available (Olafurs code) and it has some known anomolies. When fully functional DS code becomes available, then is the time to begin discussion on testing and rollout plans. I am sorry to waste you time. -- --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. archive: From owner-namedroppers@ops.ietf.org Thu Mar 21 22:13:43 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05484 for ; Thu, 21 Mar 2002 22:13:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oFHy-000Pzu-00 for namedroppers-data@psg.com; Thu, 21 Mar 2002 19:00:22 -0800 Received: from postman.ripe.net ([193.0.0.199]) by psg.com with smtp (Exim 3.35 #1) id 16oFHw-000Pzb-00 for namedroppers@ops.ietf.org; Thu, 21 Mar 2002 19:00:21 -0800 Received: (qmail 6595 invoked by uid 0); 22 Mar 2002 03:00:19 -0000 Received: from x22.ripe.net (HELO x22.ripe.net.ripe.net) (193.0.1.22) by postman.ripe.net with SMTP; 22 Mar 2002 03:00:19 -0000 Date: Fri, 22 Mar 2002 04:00:18 +0100 (CET) From: Bruce Campbell X-X-Sender: bc@x22.ripe.net To: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-01.txt In-Reply-To: <20020320114739.23997.qmail@cr.yp.to> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On 20 Mar 2002, D. J. Bernstein wrote: > Robert Elz writes: > > Signing the zone once a month, and perhaps less frequently, > > is likely to be just fine for many sites. > > No! If you're signing only once a month (plus unscheduled changes), then > you're using expiration dates at least a month away, so an attacker can > block a change until the end of the month. This is a security violation > at every site I've seen; changes have to take effect much more quickly > than that. That is correct, however a lot of sites will operate with long intervals between key signing until an attacker (or other failure) causes them to rethink their site-specific policies. We can recommend 'reasonable' intervals that allow sites to recover quickly from their mishaps, but we will find that some people will enjoy having a long length of rope. Next topic please? -- Bruce Campbell RIPE Systems/Network Engineer NCC www.ripe.net - PGP562C8B1B Operations -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 22 09:36:45 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22600 for ; Fri, 22 Mar 2002 09:36:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oKJP-000KZB-00 for namedroppers-data@psg.com; Fri, 22 Mar 2002 00:22:11 -0800 Received: from [12.162.212.188] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.35 #1) id 16oKJO-000KZ1-00 for namedroppers@ops.ietf.org; Fri, 22 Mar 2002 00:22:10 -0800 Received: from randy by roam.psg.com with local (Exim 4.00) id 16oKJO-000162-00 for namedroppers@ops.ietf.org; Fri, 22 Mar 2002 02:22:10 -0600 Message-Id: <200203220447.g2M4lb4F031928@lin2.andrew.cmu.edu> In-reply-to: <200202082038.PAA24020@ietf.org> References: <200202082038.PAA24020@ietf.org> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Date: Thu, 21 Mar 2002 23:47:37 -0500 From: Lawrence Greenfield To: iesg@ietf.org Cc: namedroppers@ops.ietf.org Subject: Re: Last Call: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber ] [better late than never for the last call] Section 9 on this draft addresses "Conformance". I am confused by the requirements of this section. It starts by saying that "DNS clients and servers SHOULD specify SPNEGO mech_type in their GSS API calls" and then says "it is required that" - DNS servers specify SPNEGO mech_type - GSS APIs called by DNS client support Kerberos v5 - GSS APIs called by DNS server support SPNEGO [RFC2478] and Kerberos v5. Does the client need to use SPNEGO or merely Kerberos v5? Does the client need to use Kerberos v5 under SPNEGO? What do I need to implement to actually interoperate? (I think the text is trying to tell me but I just can't tell.) Also, the OID for the Kerberos v5 GSS mechanism was mistated in some documents; several members of the kerberos wg seemed to be fuzzy on what was correct when I asked them; it would probably be worthwhile to state explicitly what is meant by the Kerberos v5 GSS mechanism. thanks, Larry -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 22 13:00:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27511 for ; Fri, 22 Mar 2002 13:00:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oT0J-0006Ce-00 for namedroppers-data@psg.com; Fri, 22 Mar 2002 09:39:03 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.35 #1) id 16oT0I-0006CW-00 for namedroppers@ops.ietf.org; Fri, 22 Mar 2002 09:39:02 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 1F8D128F50 for ; Fri, 22 Mar 2002 09:39:02 -0800 (PST) (envelope-from paul@vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: notes from my conversation with keith moore concerning a6/dname In-Reply-To: Message from Robert Elz of "Thu, 21 Mar 2002 17:49:47 +0700." <2495.1016707787@brandenburg.cs.mu.OZ.AU> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Fri, 22 Mar 2002 09:39:02 -0800 Message-Id: <20020322173902.1F8D128F50@as.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > A6, with some guidelines on how people should actually configure it > most likely, is the only sane way to progress. > > kre for the record, i still believe this. however, i have stopped believing that the current IETF leadership is convincable about any part of it, so i am declaring defeat. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Mar 23 01:07:27 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09823 for ; Sat, 23 Mar 2002 01:07:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oePq-000EnN-00 for namedroppers-data@psg.com; Fri, 22 Mar 2002 21:50:10 -0800 Received: from [38.138.52.132] (helo=torque.pothole.com) by psg.com with esmtp (Exim 3.35 #1) id 16oePo-000EnA-00 for namedroppers@ops.ietf.org; Fri, 22 Mar 2002 21:50:09 -0800 Received: from localhost by torque.pothole.com (8.9.3/1.1.29.3/02Aug01-1031PM) id AAA0000001954; Sat, 23 Mar 2002 00:47:00 -0500 (EST) Message-Id: <200203230547.AAA0000001954@torque.pothole.com> To: namedroppers@ops.ietf.org Subject: Re: Eliminating KEY Algorithms In-reply-to: Your message of "Wed, 20 Mar 2002 12:29:28 EST." Date: Sat, 23 Mar 2002 00:47:00 -0500 From: "Donald E. Eastlake 3rd" X-Mts: smtp Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hi, If I recall correctly there were a couple of drafts related to indirect keys. Or at least an initial draft and then later some other ideas that someone IBMer other than myself had while I was at IBM and which were presented to some *dns* WG. But given that all such drafts have timed out and been garbage collected without protest and, as far as I know, no one ever used indirect keys and would not be justified in depending on something from a work in progress, it's OK with me if you want to free up algorithm coee 252. Thanks, Donadl From: Edward Lewis Message-Id: In-Reply-To: References: <3C98102E.A29BF688@isi.edu> Content-Type: text/plain; charset="us-ascii" Date: Wed, 20 Mar 2002 12:29:28 -0500 To: Randy Bush Cc: Edward Lewis , namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org >At 11:41 AM -0500 3/20/02, Randy Bush wrote: >>>>> Since indirect keys are not useful within DNSSEC, removing that type >>>>>of key >>>>> is allowable. The other two algorithms do have utility in a just-DNSSEC >>>>> realm. (There is no sense throwing away functionality unless it causes >>>>> operational or functional problems.) >>>> >>>> for we the uneducated, you might enumerate the specific utility they >>>> have. > >Culled from the archives. indirect-key is mentioned off and on until the >agenda for the Oslo meeting, but then disappears from the archives, >although I didn't locate the minutes of that meeting, "indirect" does not >appear in any greps after that. (dns-security was shut down in Spring >2000.) > >>Date: Wed, 10 Dec 1997 22:51:51 -0500 (EST) >>From: "Donald E. Eastlake 3rd" >>To: dns-security@ex.tis.com >>Subject: Re: WG Last Call: draft-ietf-dnssec-indirect-key-01.txt >> >>On Sun, 7 Dec 1997, John Gilmore wrote: >> >>> Date: Sun, 07 Dec 1997 21:10:02 -0800 >>> From: John Gilmore >>> To: dns-security@ex.tis.com, gnu@toad.com >>> Subject: Re: WG Last Call: draft-ietf-dnssec-indirect-key-01.txt >>> >>> It is not clear what problem this draft is trying to solve. >> >>This draft is based on the assumption that key distribution via DNS >>becomes reasonably common. At least common enough that people go look >>first in the DNS for user/host keys. Then it seems like there would be a >>number of cases where you would want to use this because they have a >>bunch of keys/certificates elsewhere and want to tell the people looking >>in DNS to go use their existing key/certificate server. >> The impetus for writing the draft came from an actual large ISP that >>indicated it didn't want to have to put a bunch of user keys into the DNS >>and keep them updated there but would find it much easier to just have >>DNS entries pointing to its key server. >> >>> The "target type" field seems to be encoding numerous separate kinds >>> of information (e.g. the format of the location data (URL or domain >>> name); the format of the data to be retrieved there (KEY RDATA, >>> CERT RDATA, PKCS #1, etc); and the "type" of certificate that might >>> be found there (PKIX, PGP, etc). Rather than encode various >>> combinations of these, wouldn't separate fields be better? >> >>The -00 draft had this more orthogonal. But the total number of >>combinations just doesn't seem that high and if you make these things >>orthogonal, there are number of combinations that don't make sense. I >>guess I'd be willing to change back if people want. >> >>> John >> >>Donald > >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >Edward Lewis NAI Labs >Phone: +1 443-259-2352 Email: lewis@tislabs.com > >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. >archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Mar 23 01:09:27 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09843 for ; Sat, 23 Mar 2002 01:09:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16oePb-000Ekb-00 for namedroppers-data@psg.com; Fri, 22 Mar 2002 21:49:55 -0800 Received: from [38.138.52.132] (helo=torque.pothole.com) by psg.com with esmtp (Exim 3.35 #1) id 16oePZ-000EjY-00 for namedroppers@ops.ietf.org; Fri, 22 Mar 2002 21:49:54 -0800 Received: from localhost by torque.pothole.com (8.9.3/1.1.29.3/02Aug01-1031PM) id AAA0000001943; Sat, 23 Mar 2002 00:46:45 -0500 (EST) Message-Id: <200203230546.AAA0000001943@torque.pothole.com> To: namedroppers@ops.ietf.org Subject: Re: Eliminating KEY Algorithms In-reply-to: Your message of "Wed, 20 Mar 2002 15:43:16 GMT." Date: Sat, 23 Mar 2002 00:46:45 -0500 From: "Donald E. Eastlake 3rd" X-Mts: smtp Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Exactly. These algorithm codes, 253 and 254, are intended for any use that doesn't care about interoperability. The requirement to put in an OID or domain name is just to guarantee non-collision of different private/experimental/test uses. No semantic content is implied by the OID or domain name other than that whoever allocates the domain name or OID for this purpose have adequate control over that OID or domain name. I think these codes should be retained. Who knows who may be depending on their currently documented natures? Admittedly, at the glacial pace algorithm codes are being used, it might be a long time before a conflicting use was assigned to 253 or 254 but for the same reason there is very little benefit to freeing them up. While the current specification is only a Proposed Standard, there is clearly some desire for such codes for experimental or test use so why take them away to just have to give them back? Thanks, Donald From: Chris Thompson To: scottr@antd.nist.gov (Scott Rose) Date: Wed, 20 Mar 2002 15:43:16 +0000 (GMT) Cc: lewis@tislabs.com, namedroppers@ops.ietf.org In-Reply-To: <3C98A439.6AB1AD2E@antd.nist.gov> from "Scott Rose" at Mar 20, 2 10:01:13 am Message-Id: >scottr@antd.nist.gov (Scott Rose) writes >> >> Edward Lewis wrote: >[...] >> > While there are changes afoot, can an algorithm number be reserved for >> > testing - such as for an algorithm that hasn't been developed enough to >> > warrant an IANA assigned number? >> > >> >> Maybe redefinition of the 253 number? for "private" instead of "private - >> domain name"? either way, private is private. Most servers would not >> understand experimental algorithms anyway. > >This is how I read RFC 2535 section 3.2 in the first place. The "domain >name" is just there to (maybe) ensure uniqueness, and has no other semantic >content. To use > > test42.bizarre-ideas.cet1.ucs.cam.ac.uk > >for this purpose, I just have to persuade those responsible for >ucs.cam.ac.uk that they will tell other people to use somthing >not under cet1.ucs.cam.ac.uk for such a purpose. Or if I am lazy, >maybe I don't actually bother to do that negotiation, and just >hope for the best: it's only for testing ... :) > >Perhaps the really slovenly can just use the root domain "." ? > >Chris Thompson >Email: cet1@cam.ac.uk > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Mar 23 12:53:23 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23559 for ; Sat, 23 Mar 2002 12:53:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16opQi-0006vO-00 for namedroppers-data@psg.com; Sat, 23 Mar 2002 09:35:48 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.35 #1) id 16opQi-0006vI-00 for namedroppers@ops.ietf.org; Sat, 23 Mar 2002 09:35:48 -0800 Received: from randy by rip.psg.com with local (Exim 4.00) id 16opQi-000C9o-00 for namedroppers@ops.ietf.org; Sat, 23 Mar 2002 09:35:48 -0800 Message-ID: <20020321121736.2223.qmail@cr.yp.to> References: <20020320050141.BE00428F50@as.vix.com> <3086.1016615467@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: 21 Mar 2002 12:17:36 -0000 Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: notes from my conversation with keith moore concerning a6/dname Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber ] Robert Elz writes: > A6 is the only current answer A6 is an IPv6-specific record requiring support from every DNS cache on the Internet. That wouldn't be a reasonable use of the word ``current'' even if A6 actually solved the stated problem---which it doesn't, never mind all the other flaws. Here's the _current_ answer, what actually happens in the real world. DNS service for these dinky zones is provided by a much larger DNS hosting service, often the ISP. The occasional updates are handled through a local protocol. The DNS host can, of course, allow indirection in the local protocol. This doesn't require support from DNS software at other sites. As for security: Someone who can change the leading bits of your IP address might as well sign the whole thing. It's up to the security protocol to allow sufficiently specific signing-authority delegations. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Mar 24 09:57:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14129 for ; Sun, 24 Mar 2002 09:57:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16p8yh-0001kU-00 for namedroppers-data@psg.com; Sun, 24 Mar 2002 06:28:11 -0800 Received: from [192.150.250.54] (helo=jade.coe.psu.ac.th) by psg.com with esmtp (Exim 3.35 #1) id 16p8yg-0001kO-00 for namedroppers@ops.ietf.org; Sun, 24 Mar 2002 06:28:10 -0800 Received: from brandenburg.cs.mu.OZ.AU (brandenburg.cs.mu.OZ.AU [172.30.0.77]) by jade.coe.psu.ac.th (8.11.3/8.11.3) with ESMTP id g2OETOe08631; Sun, 24 Mar 2002 21:29:24 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g2OESSp01805; Sun, 24 Mar 2002 21:28:30 +0700 (ICT) From: Robert Elz To: "D. J. Bernstein" cc: namedroppers@ops.ietf.org Subject: Re: notes from my conversation with keith moore concerning a6/dname In-Reply-To: <20020321121736.2223.qmail@cr.yp.to> References: <20020321121736.2223.qmail@cr.yp.to> <20020320050141.BE00428F50@as.vix.com> <3086.1016615467@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 24 Mar 2002 21:28:28 +0700 Message-ID: <1803.1016980108@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: 21 Mar 2002 12:17:36 -0000 From: "D. J. Bernstein" Message-ID: <20020321121736.2223.qmail@cr.yp.to> | [ post by non-subscriber ] This time I am not going to go through the song & dance to get the reply back to the author of this message... If he doesn't want to see replies, so be it. | A6 is an IPv6-specific record requiring support from every DNS cache on | the Internet. While we're still using IPv4 for transport (and for all IPv4 only DNS caches), no more than any other random RR that gets introduced, that is, support means "cache the bits, and return them when asked". There's no name compression for A6 records, however nice it would be to have it. | Here's the _current_ answer, what actually happens in the real world. | DNS service for these dinky zones is provided by a much larger DNS | hosting service, often the ISP. The occasional updates are handled | through a local protocol. Once again, you're providing a solution that happens to meet your particular view of how the world should work. No doubt many organisations will do just that - but there's no reason to force them too. If we can make it so that sites don't have to go fiddling their DNS all the time, more of them will run it for themselves. | As for security: Someone who can change the leading bits of your IP | address might as well sign the whole thing. It's up to the security | protocol to allow sufficiently specific signing-authority delegations. No thanks. The ISP has to be trusted to deal with the prefix - they provide routing to it, if they want to screw their customers, they don't need to go fiddling the DNS for the prefix for that. But they know nothing about the internals of the site, what addresses exist, and what should exist. I see no reason to create an industry for ISPs (we charge $10 per name per year top put your names in our DNS...) that sites could be coerced into using by an ISP that changed their address, forcing them to chase the DNS updates. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 25 11:02:59 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16494 for ; Mon, 25 Mar 2002 11:02:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16pWcs-000FsC-00 for namedroppers-data@psg.com; Mon, 25 Mar 2002 07:43:14 -0800 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.35 #1) id 16pWcr-000Fs6-00 for namedroppers@ops.ietf.org; Mon, 25 Mar 2002 07:43:13 -0800 Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by peacock.verisign.com (8.11.3/BCH1.7.5) with ESMTP id g2PFdMO02984; Mon, 25 Mar 2002 07:39:22 -0800 (PST) Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Mar 2002 07:44:17 -0800 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869A2C@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Donald E. Eastlake 3rd'" , namedroppers@ops.ietf.org Subject: RE: Eliminating KEY Algorithms Date: Mon, 25 Mar 2002 07:43:59 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1D413.E1464330" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1D413.E1464330 Content-Type: text/plain; charset="iso-8859-1" One point to consider is that although the signature algorithm in ubiquitous use has been RSA for 20 odd years the RSA spec has changed a couple of times to take account of changes in packaging technology and it is quite possible that yet another packaging format will be proposed in the future. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Donald E. Eastlake 3rd [mailto:dee3@torque.pothole.com] > Sent: Saturday, March 23, 2002 12:47 AM > To: namedroppers@ops.ietf.org > Subject: Re: Eliminating KEY Algorithms > > > > Exactly. These algorithm codes, 253 and 254, are intended for any use > that doesn't care about interoperability. The requirement to put in an > OID or domain name is just to guarantee non-collision of different > private/experimental/test uses. No semantic content is implied by the > OID or domain name other than that whoever allocates the domain name > or OID for this purpose have adequate control over that OID or domain > name. > > I think these codes should be retained. Who knows who may be depending > on their currently documented natures? Admittedly, at the glacial pace > algorithm codes are being used, it might be a long time before a > conflicting use was assigned to 253 or 254 but for the same reason > there is very little benefit to freeing them up. > > While the current specification is only a Proposed Standard, there is > clearly some desire for such codes for experimental or test use so why > take them away to just have to give them back? > > Thanks, > Donald > > From: Chris Thompson > To: scottr@antd.nist.gov (Scott Rose) > Date: Wed, 20 Mar 2002 15:43:16 +0000 (GMT) > Cc: lewis@tislabs.com, namedroppers@ops.ietf.org > In-Reply-To: <3C98A439.6AB1AD2E@antd.nist.gov> from "Scott > Rose" at Mar 20, 2 10:01:13 am > Message-Id: > > >scottr@antd.nist.gov (Scott Rose) writes > >> > >> Edward Lewis wrote: > >[...] > >> > While there are changes afoot, can an algorithm number > be reserved for > >> > testing - such as for an algorithm that hasn't been > developed enough to > >> > warrant an IANA assigned number? > >> > > >> > >> Maybe redefinition of the 253 number? for "private" > instead of "private - > >> domain name"? either way, private is private. Most > servers would not > >> understand experimental algorithms anyway. > > > >This is how I read RFC 2535 section 3.2 in the first place. > The "domain > >name" is just there to (maybe) ensure uniqueness, and has no > other semantic > >content. To use > > > > test42.bizarre-ideas.cet1.ucs.cam.ac.uk > > > >for this purpose, I just have to persuade those responsible for > >ucs.cam.ac.uk that they will tell other people to use somthing > >not under cet1.ucs.cam.ac.uk for such a purpose. Or if I am lazy, > >maybe I don't actually bother to do that negotiation, and just > >hope for the best: it's only for testing ... :) > > > >Perhaps the really slovenly can just use the root domain "." ? > > > >Chris Thompson > >Email: cet1@cam.ac.uk > > > >-- > >to unsubscribe send a message to > namedroppers-request@ops.ietf.org with > >the word 'unsubscribe' in a single line as the message text body. > >archive: > > -- > to unsubscribe send a message to > namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > ------_=_NextPart_000_01C1D413.E1464330 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1D413.E1464330-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 25 16:37:35 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04589 for ; Mon, 25 Mar 2002 16:37:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16pbu7-000KcA-00 for namedroppers-data@psg.com; Mon, 25 Mar 2002 13:21:23 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.35 #1) id 16pbu7-000Kc4-00 for namedroppers@ops.ietf.org; Mon, 25 Mar 2002 13:21:23 -0800 Received: from randy by rip.psg.com with local (Exim 4.00) id 16pbu7-00072U-00 for namedroppers@ops.ietf.org; Mon, 25 Mar 2002 13:21:23 -0800 MIME-Version: 1.0 Message-Id: From: Olafur Gudmundsson , Randy Bush To: namedroppers Subject: Opt-in wg last call Date: Mon, 25 Mar 2002 13:13:31 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This message starts a two week last call on Opt-In limited to NS delagtions. From discussion on the mailing list, we believe that this compromise position is somewhat more accepted than either of the 'no opt-in' and 'unlimited opt-in' alternatives. If you feel that you can not live with this compromise, then and only then, please explain why to the list. Thanks, Randy & Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 25 20:30:34 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10533 for ; Mon, 25 Mar 2002 20:30:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16pfcJ-000OB6-00 for namedroppers-data@psg.com; Mon, 25 Mar 2002 17:19:15 -0800 Received: from mail4.microsoft.com ([131.107.3.122]) by psg.com with esmtp (Exim 3.35 #1) id 16pfcI-000OAw-00 for namedroppers@ops.ietf.org; Mon, 25 Mar 2002 17:19:14 -0800 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.154]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 25 Mar 2002 17:19:13 -0800 Received: from 157.54.5.25 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 25 Mar 2002 17:19:13 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 25 Mar 2002 17:19:11 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 25 Mar 2002 17:19:04 -0800 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Mon, 25 Mar 2002 17:15:42 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Last Call: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard Date: Mon, 25 Mar 2002 17:15:43 -0800 Message-ID: <4AEE3169443CDD4796CA8A00B02191CD0537D59F@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Last Call: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard Thread-Index: AcHRewzcRmyTSHz9Tj2gnjN53DbSgwC3vl1Q From: "Levon Esibov" To: "Lawrence Greenfield" , Cc: X-OriginalArrivalTime: 26 Mar 2002 01:15:42.0320 (UTC) FILETIME=[BF868700:01C1D463] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA10533 > Section 9 on this draft addresses "Conformance". I am confused by the > requirements of this section. It starts by saying that "DNS clients > and servers SHOULD specify SPNEGO mech_type in their GSS API calls" > and then says "it is required that" > > - DNS servers specify SPNEGO mech_type > - GSS APIs called by DNS client support Kerberos v5 > - GSS APIs called by DNS server support SPNEGO [RFC2478] and > Kerberos v5. > > Does the client need to use SPNEGO or merely Kerberos v5? Does the > client need to use Kerberos v5 under SPNEGO? What do I need to > implement to actually interoperate? (I think the text is trying to > tell me but I just can't tell.) You've got it right: client can use Kerberos v5 or SPNEGO (as long as Kerberos v5 is supported on the client and SPNEGO can choose it as underlying security mechanism). > Also, the OID for the Kerberos v5 GSS mechanism was mistated in some > documents; several members of the kerberos wg seemed to be fuzzy on > what was correct when I asked them; it would probably be worthwhile to > state explicitly what is meant by the Kerberos v5 GSS mechanism. This draft points to the RFC 1964 as the authoritative document specifying "Kerberos Version 5 GSS-API Mechanism" and OID specified in RFC 1964 must be used. Thanks, Levon. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 27 05:47:16 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22044 for ; Wed, 27 Mar 2002 05:47:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qAf1-0005yA-00 for namedroppers-data@psg.com; Wed, 27 Mar 2002 02:28:07 -0800 Received: from nara.off.connect.com.au ([192.94.41.40]) by psg.com with esmtp (Exim 3.35 #1) id 16qAez-0005y4-00 for namedroppers@ops.ietf.org; Wed, 27 Mar 2002 02:28:06 -0800 Received: (from njones@localhost) by nara.off.connect.com.au id VAA09911 (8.8.8/IDA-1.7); Wed, 27 Mar 2002 21:27:28 +1100 (EST) Message-ID: <20020327212727.B23106@connect.com.au> Date: Wed, 27 Mar 2002 21:27:27 +1100 From: Nathan Jones To: iesg@ietf.org Cc: namedroppers@ops.ietf.org Subject: Re: Last Call: Representing IPv6 addresses in DNS to Proposed Standard References: <200203141526.KAA19163@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <200203141526.KAA19163@ietf.org>; from The IESG on Thu, Mar 14, 2002 at 10:26:24AM -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Having been away from the list for a while, the arguments against this draft have already been discussed. I'm sending this message to note that I also object to draft-ietf-dnsext-ipv6-addresses-01.txt. As I see it, the role of the IETF is to provide flexible standards that enable people to do things, not to tell people that they can't use certain functionality by deprecating the specification. It cannot be said that there is consensus to progress this draft. It can be said that is insufficient technical argument to deprecate A6 and DNAME. Most of the anti-A6 argument appears to say "we don't think you need easier renumbering, etc. so we'll take away the RR types and tell you to find a work around". In terms of administration, I believe A6 is only a little more complex than AAAA, and that administrators will cope just fine if there are guidelines available. Has anyone yet started work on a draft to document guidelines for the usage of DNS with IPv6? (eg. recommended limits on A6 chains, etc.) -- Nathan Jones nathanj@optimo.com.au On Thu, Mar 14, 2002 at 10:26:24AM -0500, The IESG wrote: >The IESG has received a request from the DNS Extensions Working Group >to consider Representing IPv6 addresses in DNS > as a Proposed Standard. > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send any comments to the >iesg@ietf.org or ietf@ietf.org mailing lists by April 2, 2002. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 27 07:21:34 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24466 for ; Wed, 27 Mar 2002 07:21:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qCJv-0007cg-00 for namedroppers-data@psg.com; Wed, 27 Mar 2002 04:14:27 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.35 #1) id 16qCJu-0007ca-00 for namedroppers@ops.ietf.org; Wed, 27 Mar 2002 04:14:26 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23677; Wed, 27 Mar 2002 07:14:24 -0500 (EST) Message-Id: <200203271214.HAA23677@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-song-dnsext-mci-ssm-support-00.txt Date: Wed, 27 Mar 2002 07:14:23 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MCI(Multicast Channel Identifier) DNS RR type for the support of SSM(Source Specific Multicast) Author(s) : J. Song Filename : draft-song-dnsext-mci-ssm-support-00.txt Pages : 6 Date : 26-Mar-02 This document proposes the use of the new DNS RR type MCI (Multicast Channel Identifier), as it is specifying SSM (Source Specific Multicast) multicast channel [SSM] as a DNS Resource Record. It shall allow the advance multicast session advertisement by providing the dynamic mapping between SSM multicast channel and MCI. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-song-dnsext-mci-ssm-support-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-song-dnsext-mci-ssm-support-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-song-dnsext-mci-ssm-support-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020326114228.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-song-dnsext-mci-ssm-support-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-song-dnsext-mci-ssm-support-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020326114228.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 27 07:24:17 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24579 for ; Wed, 27 Mar 2002 07:24:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qCE8-0007W2-00 for namedroppers-data@psg.com; Wed, 27 Mar 2002 04:08:28 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.35 #1) id 16qCE7-0007Vw-00 for namedroppers@ops.ietf.org; Wed, 27 Mar 2002 04:08:27 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23247; Wed, 27 Mar 2002 07:08:25 -0500 (EST) Message-Id: <200203271208.HAA23247@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-ad-is-secure-05.txt Date: Wed, 27 Mar 2002 07:08:25 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Redefinition of DNS AD bit Author(s) : B. Wellington, O. Gudmundsson Filename : draft-ietf-dnsext-ad-is-secure-05.txt Pages : 5 Date : 26-Mar-02 Based on implementation experience, the current definition of the AD bit in the DNS header is not useful. This draft changes the specification so that the AD bit is only set on answers where signatures have been cryptographically verified or the server is authoritative for the data and is allowed to set the bit by policy. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ad-is-secure-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-ad-is-secure-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-ad-is-secure-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020326114017.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-ad-is-secure-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-ad-is-secure-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020326114017.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 27 07:26:30 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24683 for ; Wed, 27 Mar 2002 07:26:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qCE4-0007VP-00 for namedroppers-data@psg.com; Wed, 27 Mar 2002 04:08:24 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.35 #1) id 16qCE3-0007V3-00 for namedroppers@ops.ietf.org; Wed, 27 Mar 2002 04:08:23 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23222; Wed, 27 Mar 2002 07:08:20 -0500 (EST) Message-Id: <200203271208.HAA23222@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-10.txt Date: Wed, 27 Mar 2002 07:08:20 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Link-Local Multicast Name Resolution (LLMNR) Author(s) : L. Esibov, B. Aboba, D. Thaler Filename : draft-ietf-dnsext-mdns-10.txt Pages : 19 Date : 26-Mar-02 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 name resolution in such environments, Link-Local Multicast Name Resolution (LLMNR) is proposed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-10.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-10.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-10.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: <20020326114004.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020326114004.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 27 09:25:56 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29567 for ; Wed, 27 Mar 2002 09:25:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qE0y-0009bV-00 for namedroppers-data@psg.com; Wed, 27 Mar 2002 06:03:00 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.35 #1) id 16qE0x-0009bP-00 for namedroppers@ops.ietf.org; Wed, 27 Mar 2002 06:02:59 -0800 Received: from randy by rip.psg.com with local (Exim 4.00) id 16qE0x-0002hg-00 for namedroppers@ops.ietf.org; Wed, 27 Mar 2002 06:02:59 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: namedroppers Subject: draft-song-dnsext-mci-ssm-support-00.txt Message-Id: Date: Wed, 27 Mar 2002 06:02:59 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit be aware of draft-song-dnsext-mci-ssm-support-00.txt -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 27 13:26:20 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14164 for ; Wed, 27 Mar 2002 13:26:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qHrK-000DXW-00 for namedroppers-data@psg.com; Wed, 27 Mar 2002 10:09:18 -0800 Received: from snout.autonomica.se ([192.71.80.82]) by psg.com with esmtp (Exim 3.35 #1) id 16qHrJ-000DXQ-00 for namedroppers@ops.ietf.org; Wed, 27 Mar 2002 10:09:17 -0800 Received: by snout.autonomica.se (Postfix, from userid 1211) id C7E8CF92; Wed, 27 Mar 2002 19:08:11 +0100 (CET) To: Nathan Jones Cc: iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: Last Call: Representing IPv6 addresses in DNS to Proposed Standard References: <200203141526.KAA19163@ietf.org> <20020327212727.B23106@connect.com.au> From: Johan Ihren Date: 27 Mar 2002 19:08:11 +0100 In-Reply-To: <20020327212727.B23106@connect.com.au> Message-ID: <2cu1r1lw8k.fsf@snout.autonomica.net> Lines: 46 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.3 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Nathan Jones writes: > Having been away from the list for a while, the arguments against this > draft have already been discussed. I'm sending this message to note > that I also object to draft-ietf-dnsext-ipv6-addresses-01.txt. As do I (i.e. I've been away from the list and *do* object). But I think that by now the reasons that some of us want to keep A6 have been iterated by kre and Paul that there is really no need for me to take the arguments through the hoops again. In this mess we have at one end basically two DNS camps shouting at each other while at another end we have (at least I think we have) the v6 community silently watching (in horror?). And the sad thing is that the v6 community (with a few notable exceptions) doesn't seem to care about this debate, and this by itself is used as an argument to kill A6/DNAME. And the question that will never get answered is whether all of the v6 community that helped vote against A6/DNAME realize how little impact keeping A6/DNAME would have on their deployment plans, written software, etc, etc. In hindsight I think that the A6/DNAME camp made a long series of tactical mistakes: The first was the bitstrings. That one wasn't a real winner. I can remember few things that have confused me as much as working with bitstrings. The second was (possibly) DNAME, since that particular rope seems to be regarded as more dangerous than all the other ropes available out there. The third was pushing for AAAA synthesis as a *transition* mechanism when it should have been described as an A6 core vs AAAA edge strategy (thereby alleviating worries among all the people who've already used AAAA in all kinds of software). And at the end A6 was lost, the most crucial piece, and one that cannot be replaced. Ever. Johan Ihrén Autonomica -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 27 15:50:33 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22151 for ; Wed, 27 Mar 2002 15:50:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qKBu-000FyL-00 for namedroppers-data@psg.com; Wed, 27 Mar 2002 12:38:42 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.35 #1) id 16qKBt-000FyF-00 for namedroppers@ops.ietf.org; Wed, 27 Mar 2002 12:38:41 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21531; Wed, 27 Mar 2002 15:38:35 -0500 (EST) Message-Id: <200203272038.PAA21531@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , namedroppers@ops.ietf.org From: The IESG Subject: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard Date: Wed, 27 Mar 2002 15:38:35 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The IESG has approved the Internet-Draft 'GSS Algorithm for TSIG (GSS-TSIG)' as a Proposed Standard. This document is the product of the DNS Extensions Working Group. The IESG contact persons are Erik Nordmark and Thomas Narten. Technical Summary The TSIG protocol provides transaction level authentication for DNS. TSIG is extensible through the definition of new algorithms. This document specifies an algorithm based on the Generic Security Service Application Program Interface (GSS-API) (RFC2743). Working Group Summary The WG initially wanted to progress this as informational since there was concern that it couldn't be implemented from the specification. The WG chairs have been informed that there are at least two independent interoperable implementations. Based on this feedback the WG came to consensus about advancing this as a proposed standard. Protocol Quality This document was reviewed for the IESG by Erik Nordmark. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 27 19:12:58 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00394 for ; Wed, 27 Mar 2002 19:12:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qNLM-000JDy-00 for namedroppers-data@psg.com; Wed, 27 Mar 2002 16:00:40 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.35 #1) id 16qNLM-000JDs-00 for namedroppers@ops.ietf.org; Wed, 27 Mar 2002 16:00:40 -0800 Received: from randy by rip.psg.com with local (Exim 4.00) id 16qNLL-000K12-00 for namedroppers@ops.ietf.org; Wed, 27 Mar 2002 16:00:39 -0800 Message-ID: <20020328094454.A5859@connect.com.au> References: <200203141526.KAA19163@ietf.org> <20020327212727.B23106@connect.com.au> <2cu1r1lw8k.fsf@snout.autonomica.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <2cu1r1lw8k.fsf@snout.autonomica.net>; from Johan Ihren on Wed, Mar 27, 2002 at 07:08:11PM +0100 Date: Thu, 28 Mar 2002 09:44:54 +1100 From: Nathan Jones To: Johan Ihren Cc: iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: Last Call: Representing IPv6 addresses in DNS to Proposed Standard Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber ] On Wed, Mar 27, 2002 at 07:08:11PM +0100, Johan Ihren wrote: >The third was pushing for AAAA synthesis as a *transition* mechanism >when it should have been described as an A6 core vs AAAA edge strategy >(thereby alleviating worries among all the people who've already used >AAAA in all kinds of software). It was originally intended as a transition method, but after some discussion it became clear that it would be an important fixture. Now that we know this, it could be incorporated into an "A6 guidelines and clarification" document. I'll see if I can put aside some time to draft up something. -- nathanj@optimo.com.au -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 27 19:50:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00974 for ; Wed, 27 Mar 2002 19:50:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qNzo-000JvI-00 for namedroppers-data@psg.com; Wed, 27 Mar 2002 16:42:28 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.35 #1) id 16qNzn-000JvC-00 for namedroppers@ops.ietf.org; Wed, 27 Mar 2002 16:42:27 -0800 Received: by as.vix.com (Postfix, from userid 716) id 10B6328DC4; Wed, 27 Mar 2002 16:42:27 -0800 (PST) To: namedroppers@ops.ietf.org Cc: Nathan Jones Subject: Re: Last Call: Representing IPv6 addresses in DNS to Proposed Standard References: <200203141526.KAA19163@ietf.org> <20020327212727.B23106@connect.com.au> <2cu1r1lw8k.fsf@snout.autonomica.net> <20020328094454.A5859@connect.com.au> From: Paul Vixie Date: 27 Mar 2002 16:42:26 -0800 In-Reply-To: <20020328094454.A5859@connect.com.au> Message-ID: Lines: 34 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > >The third was pushing for AAAA synthesis as a *transition* mechanism > >when it should have been described as an A6 core vs AAAA edge strategy > >(thereby alleviating worries among all the people who've already used > >AAAA in all kinds of software). > > It was originally intended as a transition method, but after some > discussion it became clear that it would be an important fixture. Now > that we know this, it could be incorporated into an "A6 guidelines and > clarification" document. I'll see if I can put aside some time to > draft up something. Tick tock, tick tock, gentlemen. There are a couple thousand V6 hosts around the world already. Admitting A6/DNAME at this late date means declaring that either all those hosts will have to be rototilled before they can join the future production V6 network, or that all of their recursive nameservers will have to be rototilled to participate in the future production V6 network. To the hardy-souled early adopters who have "deployed" using AAAA, rototilling their crops because they used outdated seeds just feels like the opposite of progress. And those are the people who are making the decision re: AAAA vs A6/DNAME. I think that as an architectural quality matter, we're about to make a pessimal design choice. A6/DNAME would have carried V6 deeper into the enterprise and would have doubled V6's useful lifetime. But the decision isn't going to be made on the grounds of architectural quality, it'll be made on what amounts to a time-to-market basis. On _that_ basis, the game is over. Unless one wishes to dispute the decision process rather than the decision's outcome, it's time to move onward to the limited deployment AAAA will ever permit. It's odd to see some of the commercial interests who have combined in favour of "now, limited" rather than "later, full" deployment. Sign of the times, maybe? "Long live NAT." -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 27 19:51:58 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01033 for ; Wed, 27 Mar 2002 19:51:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qNzx-000Jvx-00 for namedroppers-data@psg.com; Wed, 27 Mar 2002 16:42:37 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.35 #1) id 16qNzw-000Jvr-00 for namedroppers@ops.ietf.org; Wed, 27 Mar 2002 16:42:36 -0800 Received: by as.vix.com (Postfix, from userid 716) id 107B928E19; Wed, 27 Mar 2002 16:42:36 -0800 (PST) To: namedroppers@ops.ietf.org Cc: Nathan Jones Subject: Re: Last Call: Representing IPv6 addresses in DNS to Proposed Standard References: <200203141526.KAA19163@ietf.org> <20020327212727.B23106@connect.com.au> <2cu1r1lw8k.fsf@snout.autonomica.net> <20020328094454.A5859@connect.com.au> From: Paul Vixie In-Reply-To: <20020328094454.A5859@connect.com.au> User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 Date: 27 Mar 2002 16:42:35 -0800 Message-ID: Lines: 34 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > >The third was pushing for AAAA synthesis as a *transition* mechanism > >when it should have been described as an A6 core vs AAAA edge strategy > >(thereby alleviating worries among all the people who've already used > >AAAA in all kinds of software). > > It was originally intended as a transition method, but after some > discussion it became clear that it would be an important fixture. Now > that we know this, it could be incorporated into an "A6 guidelines and > clarification" document. I'll see if I can put aside some time to > draft up something. Tick tock, tick tock, gentlemen. There are a couple thousand V6 hosts around the world already. Admitting A6/DNAME at this late date means declaring that either all those hosts will have to be rototilled before they can join the future production V6 network, or that all of their recursive nameservers will have to be rototilled to participate in the future production V6 network. To the hardy-souled early adopters who have "deployed" using AAAA, rototilling their crops because they used outdated seeds just feels like the opposite of progress. And those are the people who are making the decision re: AAAA vs A6/DNAME. I think that as an architectural quality matter, we're about to make a pessimal design choice. A6/DNAME would have carried V6 deeper into the enterprise and would have doubled V6's useful lifetime. But the decision isn't going to be made on the grounds of architectural quality, it'll be made on what amounts to a time-to-market basis. On _that_ basis, the game is over. Unless one wishes to dispute the decision process rather than the decision's outcome, it's time to move onward to the limited deployment AAAA will ever permit. It's odd to see some of the commercial interests who have combined in favour of "now, limited" rather than "later, full" deployment. Sign of the times, maybe? "Long live NAT." -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 28 07:28:38 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23136 for ; Thu, 28 Mar 2002 07:28:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qYgE-0005Ts-00 for namedroppers-data@psg.com; Thu, 28 Mar 2002 04:06:58 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.35 #1) id 16qYgC-0005Tm-00 for namedroppers@ops.ietf.org; Thu, 28 Mar 2002 04:06:57 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22110; Thu, 28 Mar 2002 07:06:53 -0500 (EST) Message-Id: <200203281206.HAA22110@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-delegation-signer-07.txt Date: Thu, 28 Mar 2002 07:06:53 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Delegation Signer Resource Record Author(s) : O. Gudmundsson Filename : draft-ietf-dnsext-delegation-signer-07.txt Pages : 14 Date : 27-Mar-02 The delegation signer (DS) resource record is inserted at a zone cut (i.e., a delegation point) to indicate that the delegated zone is digitally signed and that the delegated zone recognizes the indicated key as a valid zone key for the delegated zone. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-delegation-signer-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-delegation-signer-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-delegation-signer-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020327152019.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-delegation-signer-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-delegation-signer-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020327152019.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 28 07:28:41 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23150 for ; Thu, 28 Mar 2002 07:28:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qYgJ-0005U3-00 for namedroppers-data@psg.com; Thu, 28 Mar 2002 04:07:03 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.35 #1) id 16qYgI-0005Tw-00 for namedroppers@ops.ietf.org; Thu, 28 Mar 2002 04:07:02 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22127; Thu, 28 Mar 2002 07:06:59 -0500 (EST) Message-Id: <200203281206.HAA22127@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-restrict-key-for-dnssec-02.txt Date: Thu, 28 Mar 2002 07:06:59 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Limiting the Scope of the KEY Resource Record Author(s) : D. Massey, S. Rose Filename : draft-ietf-dnsext-restrict-key-for-dnssec-02.txt Pages : 10 Date : 27-Mar-02 This document limits the Domain Name System KEY resource record to only keys used by the Domain Name System Security Extensions (DNSSEC). The original KEY resource record used sub-typing to store both DNSSEC keys and arbitrary application keys. Storing both DNSSEC and application keys in one record was a mistake. This document removes application keys from the KEY record by redefining the Protocol Octet field in the KEY Resource Record Data. As a result of removing application keys, all but one of the flags in the KEY record become unnecessary and are removed. Three existing application key sub-types are changed to reserved, but the format of the KEY record is not changed. This document updates RFC 2535. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-restrict-key-for-dnssec-02.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-restrict-key-for-dnssec-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-restrict-key-for-dnssec-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020327152029.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-restrict-key-for-dnssec-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-restrict-key-for-dnssec-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020327152029.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 28 10:00:59 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29179 for ; Thu, 28 Mar 2002 10:00:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qbHo-0008tm-00 for namedroppers-data@psg.com; Thu, 28 Mar 2002 06:53:56 -0800 Received: from 208-59-114-172.c3-0.129-ubr1.lnh-129.md.cable.rcn.com ([208.59.114.172] helo=ogud.com) by psg.com with esmtp (Exim 3.35 #1) id 16qbHn-0008tg-00 for namedroppers@ops.ietf.org; Thu, 28 Mar 2002 06:53:55 -0800 Received: from localhost (ogud@localhost) by ogud.com (8.11.6/8.11.6) with ESMTP id g2SEphk86015 for ; Thu, 28 Mar 2002 09:51:43 -0500 (EST) (envelope-from ogud@ogud.com) Date: Thu, 28 Mar 2002 09:51:43 -0500 (EST) From: Olafur Gudmundsson X-X-Sender: ogud@hlid.dc.ogud.com To: DNSEXT mailing list Subject: DNSEXT WGLC Summary: Restrict KEY Message-ID: <20020328095108.R85801-100000@hlid.dc.ogud.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Restrict KEY The DNSEXT working group has concluded a last call on this document and there is consensus on advancing it. Authors have updated the document, for readability and updated the IANA consideration section to better reflect what is requred of IANA. http://www.ietf.org/internet-drafts/draft-ietf-dnsext-restict-key-for-dnssec-02.txt Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 28 10:02:03 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29309 for ; Thu, 28 Mar 2002 10:01:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qbGG-0008sO-00 for namedroppers-data@psg.com; Thu, 28 Mar 2002 06:52:20 -0800 Received: from 208-59-114-172.c3-0.129-ubr1.lnh-129.md.cable.rcn.com ([208.59.114.172] helo=ogud.com) by psg.com with esmtp (Exim 3.35 #1) id 16qbGF-0008sH-00 for namedroppers@ops.ietf.org; Thu, 28 Mar 2002 06:52:19 -0800 Received: from localhost (ogud@localhost) by ogud.com (8.11.6/8.11.6) with ESMTP id g2SEo6P86003 for ; Thu, 28 Mar 2002 09:50:06 -0500 (EST) (envelope-from ogud@ogud.com) Date: Thu, 28 Mar 2002 09:50:06 -0500 (EST) From: Olafur Gudmundsson X-X-Sender: ogud@hlid.dc.ogud.com To: DNSEXT mailing list Subject: DNSEXT WGLC Summary AD secure Message-ID: <20020328094846.I85801-100000@hlid.dc.ogud.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk AD secure The DNSEXT working group has concluded a last call on this document and there is consensus on advancing it. Authors have updated the document to fix few typo's and remove redundant text. http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ad-secure-05.txt Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 28 10:02:08 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29330 for ; Thu, 28 Mar 2002 10:02:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qbHC-0008tC-00 for namedroppers-data@psg.com; Thu, 28 Mar 2002 06:53:18 -0800 Received: from 208-59-114-172.c3-0.129-ubr1.lnh-129.md.cable.rcn.com ([208.59.114.172] helo=ogud.com) by psg.com with esmtp (Exim 3.35 #1) id 16qbHB-0008t6-00 for namedroppers@ops.ietf.org; Thu, 28 Mar 2002 06:53:17 -0800 Received: from localhost (ogud@localhost) by ogud.com (8.11.6/8.11.6) with ESMTP id g2SEp5c86007 for ; Thu, 28 Mar 2002 09:51:05 -0500 (EST) (envelope-from ogud@ogud.com) Date: Thu, 28 Mar 2002 09:51:05 -0500 (EST) From: Olafur Gudmundsson X-X-Sender: ogud@hlid.dc.ogud.com To: DNSEXT mailing list Subject: DNSEXT WGLC Summary: Delegation signer Message-ID: <20020328095011.O85801-100000@hlid.dc.ogud.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The DNSEXT working group has concluded a last call on this document and there is consensus on advancing it. Author has updated the document, based on comments received during last call. http://www.ietf.org/internet-drafts/draft-ietf-dnsext-restict-key-delegation-signer-06.txt Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 28 10:34:19 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00859 for ; Thu, 28 Mar 2002 10:34:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qbpU-0009uT-00 for namedroppers-data@psg.com; Thu, 28 Mar 2002 07:28:44 -0800 Received: from 208-59-114-172.c3-0.129-ubr1.lnh-129.md.cable.rcn.com ([208.59.114.172] helo=ogud.com) by psg.com with esmtp (Exim 3.35 #1) id 16qbpT-0009u3-00 for namedroppers@ops.ietf.org; Thu, 28 Mar 2002 07:28:43 -0800 Received: from localhost (ogud@localhost) by ogud.com (8.11.6/8.11.6) with ESMTP id g2SFQUH86133 for ; Thu, 28 Mar 2002 10:26:30 -0500 (EST) (envelope-from ogud@ogud.com) Date: Thu, 28 Mar 2002 10:26:30 -0500 (EST) From: Olafur Gudmundsson X-X-Sender: ogud@hlid.dc.ogud.com To: DNSEXT mailing list Subject: Re: DNSEXT WGLC Summary: Restrict KEY In-Reply-To: <20020328095108.R85801-100000@hlid.dc.ogud.com> Message-ID: <20020328102331.S85801-100000@hlid.dc.ogud.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 28 Mar 2002, Olafur Gudmundsson wrote: > > Restrict KEY > The DNSEXT working group has concluded a last call on this document > and there is consensus on advancing it. > > Authors have updated the document, for readability and updated the > IANA consideration section to better reflect what is requred of IANA. > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-restict-key-for-dnssec-02.txt another correction: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-restrict-key-for-dnssec-02.txt Sorry the errors, my laptop with the fancy email setup with automated spell cheking, died at the IETF. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 28 10:38:55 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00970 for ; Thu, 28 Mar 2002 10:38:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qbkw-0009lR-00 for namedroppers-data@psg.com; Thu, 28 Mar 2002 07:24:02 -0800 Received: from 208-59-114-172.c3-0.129-ubr1.lnh-129.md.cable.rcn.com ([208.59.114.172] helo=ogud.com) by psg.com with esmtp (Exim 3.35 #1) id 16qbkv-0009lL-00 for namedroppers@ops.ietf.org; Thu, 28 Mar 2002 07:24:01 -0800 Received: from localhost (ogud@localhost) by ogud.com (8.11.6/8.11.6) with ESMTP id g2SFLn586110 for ; Thu, 28 Mar 2002 10:21:49 -0500 (EST) (envelope-from ogud@ogud.com) Date: Thu, 28 Mar 2002 10:21:48 -0500 (EST) From: Olafur Gudmundsson X-X-Sender: ogud@hlid.dc.ogud.com To: DNSEXT mailing list Subject: Re: DNSEXT WGLC Summary: Delegation signer In-Reply-To: <20020328095011.O85801-100000@hlid.dc.ogud.com> Message-ID: <20020328102121.N85801-100000@hlid.dc.ogud.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 28 Mar 2002, Olafur Gudmundsson wrote: > > The DNSEXT working group has concluded a last call on this document > and there is consensus on advancing it. > Author has updated the document, based on comments received during > last call. > > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-restict-key-delegation-signer-06.txt correction: s/06/07 Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 28 10:44:08 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01177 for ; Thu, 28 Mar 2002 10:44:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qbuI-000A3x-00 for namedroppers-data@psg.com; Thu, 28 Mar 2002 07:33:42 -0800 Received: from 208-59-114-172.c3-0.129-ubr1.lnh-129.md.cable.rcn.com ([208.59.114.172] helo=ogud.com) by psg.com with esmtp (Exim 3.35 #1) id 16qbuH-000A3e-00 for namedroppers@ops.ietf.org; Thu, 28 Mar 2002 07:33:41 -0800 Received: from localhost (ogud@localhost) by ogud.com (8.11.6/8.11.6) with ESMTP id g2SFVRC86141; Thu, 28 Mar 2002 10:31:27 -0500 (EST) (envelope-from ogud@ogud.com) Date: Thu, 28 Mar 2002 10:31:27 -0500 (EST) From: Olafur Gudmundsson X-X-Sender: ogud@hlid.dc.ogud.com To: Erik Nordmark cc: DNSEXT mailing list , Subject: DNSEXT requests IETF last call on following DNSSEC documents Message-ID: <20020328093013.F85801-100000@hlid.dc.ogud.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Erik, Please start IETF last call on following DNSEXT working group documents as soon as possible. AD secure: The DNSEXT working group has concluded a last call on this document and there is consensus on advancing it. Authors have updated the document to fix few typos and redundant text. http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ad-secure-05.txt Summary: This document clarifies when a Nameserver can set this bit. The only case when a resolver can set it is after cryptographically verifying the data, this is a change from RFC2535 where resolver was allowed to set the bit if data was provably from an unsecure zone. An authorative nameserver is allowed to be configured on a zone by zone bases to set the AD on answers. The document strongly recommends that resolvers ignore the bit if the message is not from a trusted server/resolver and is protected by message authentication. Restrict KEY: The DNSEXT working group has concluded a last call on this document and there is consensus on advancing it. Authors have updated the document, for readability and updated the IANA consideration section to better reflect what is required of IANA. http://www.ietf.org/internet-drafts/draft-ietf-dnsext-restrict-key-for-dnssec-02.txt Summary: This document redefines the use of the KEY record to be used by DNS only. The consequence of this change is that KEY RR flags can be greatly simplified, protocol field IANA registry can be closed. The document does not specify how other application can use DNS to distribute public keys. The main reason for this change is to simplify DNS operation and avoid packet overflows when DNSSEC keys are passed around. Delegation Signer: The DNSEXT working group has concluded a last call on this document and there is consensus on advancing it. Author has updated the document, based on comments received during last call. http://www.ietf.org/internet-drafts/draft-ietf-dnsext-restrict-key-delegation-signer-07.txt Summary: This document is a major non backwards compatible change in how chain of trust is established in DNSSEC. This document defines a new parent only record DS that announces what child KEY(s) are allowed to sign child's KEY RRset. This change is a result of operational experience. The Opt-in document is currently in WG last call. There will be one more small DNSSEC related document that updates the KEY RR algorithm registry rules coming out but that is not a big deal. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 28 12:01:19 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05723 for ; Thu, 28 Mar 2002 12:01:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qcxe-000BrZ-00 for namedroppers-data@psg.com; Thu, 28 Mar 2002 08:41:14 -0800 Received: from 208-59-114-172.c3-0.129-ubr1.lnh-129.md.cable.rcn.com ([208.59.114.172] helo=ogud.com) by psg.com with esmtp (Exim 3.35 #1) id 16qcxd-000BrP-00 for namedroppers@ops.ietf.org; Thu, 28 Mar 2002 08:41:13 -0800 Received: from localhost (ogud@localhost) by ogud.com (8.11.6/8.11.6) with ESMTP id g2SGd0M86391 for ; Thu, 28 Mar 2002 11:39:00 -0500 (EST) (envelope-from ogud@ogud.com) Date: Thu, 28 Mar 2002 11:39:00 -0500 (EST) From: Olafur Gudmundsson X-X-Sender: ogud@hlid.dc.ogud.com To: DNSEXT mailing list Subject: Re: DNSEXT WGLC Summary: Delegation signer In-Reply-To: <20020328095011.O85801-100000@hlid.dc.ogud.com> Message-ID: <20020328113743.E86292-100000@hlid.dc.ogud.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 28 Mar 2002, Olafur Gudmundsson wrote: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-restict-key-delegation-signer-06.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-delegation-signer-07.txt Today is a bad spelling day. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 28 15:03:24 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13082 for ; Thu, 28 Mar 2002 15:03:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qftV-000GCJ-00 for namedroppers-data@psg.com; Thu, 28 Mar 2002 11:49:09 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.35 #1) id 16qftU-000GC9-00 for namedroppers@ops.ietf.org; Thu, 28 Mar 2002 11:49:08 -0800 Received: from localhost (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id DF6B03190E; Thu, 28 Mar 2002 11:49:06 -0800 (PST) Date: Thu, 28 Mar 2002 20:56:56 +0100 (CET) From: Roy Arends X-X-Sender: To: Olafur Gudmundsson , Randy Bush Cc: namedroppers Subject: Re: Opt-in wg last call Message-ID: <20020328203913.I52203-100000@node10c4d.a2000.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 25 Mar 2002, Olafur Gudmundsson and Randy Bush wrote: > This message starts a two week last call on Opt-In limited to NS > delagtions. From discussion on the mailing list, we believe that > this compromise position is somewhat more accepted than either of > the 'no opt-in' and 'unlimited opt-in' alternatives. > > If you feel that you can not live with this compromise, then and > only then, please explain why to the list. > > Thanks, > > Randy & Olafur A few weeks ago there was a discussion on Opt-In or Non Opt-In. A compromise (Opt-In for NS only) was posted which seems acceptable to some without even one (1) technical argument. That compromise was based on a moral argument. Here is a list of some technical arguments _for_ full Opt-in: With full Opt-In the road is open to allow: o Unsigned Wildcards. (Down the road we have the ability to restrict signed wildcards) o Unsigned synthesized RRsets. (DNAME>CNAME, A6>AAAA) o Aggregated signing of Secure Dynamic Updates. o Allow Unsigned Classless IN-ADDR.ARPA delegations (Allow unsigned cnames) Or in other words, allow smooth transition from DNS to DNSSEC. Restricting Opt-In to NS is useless, since we then get emulated full Opt-In (error prone, more complicated, more traffic) by delegating the unsigned Record Sets to an unsigned zone. Folk will simply route around the restriction. As said on this list before is that "DNSSEC should have been designed as Opt-In". I agree, one should be able to make a choice on which name to sign. After all, the "zone administrative border" is only in the server part, a resolver asks for Record Sets, not for Zones. DNSSEC should have been designed with "authenticated denial of security". To illustrate that, an application, or secure resolver decides even before issuing a single query, if it expects a signed answer. The verifiable response it gets with Opt-In is either "This record is signed" or "This record is not signed". From a security perspective, "not signed" is effectively the same as "not existent". From a logical perspective, authenticated denial of existence is a subset of authenticated denial of security (if it does not exist, it is not signed). With full Opt-In out there as part of the protocol, we do not away with "authenticated denial of existence". The administrator has the choice between 2535/DS or 2535/DS/Opt-In. With regards to the "change to the security model" argument: As long as you understand and address the threat model, this change is acceptable. A request to the wg chairs: Before we abandon full opt-in, I'd like to be more clear on the working group's sense of the two. To do that, before we last call opt-in, can we have an explicit call for consensus on full Opt-in vs. restricted Opt-in ? Roy Arends Nominum -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 29 07:11:35 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09628 for ; Fri, 29 Mar 2002 07:11:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qutx-000BrL-00 for namedroppers-data@psg.com; Fri, 29 Mar 2002 03:50:37 -0800 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.35 #1) id 16qutw-000BrF-00 for namedroppers@ops.ietf.org; Fri, 29 Mar 2002 03:50:36 -0800 Received: from hawk.ecs.soton.ac.uk (hawk.ecs.soton.ac.uk [152.78.68.142]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id LAA00735; Fri, 29 Mar 2002 11:48:45 GMT Received: from login.ecs.soton.ac.uk (IDENT:tjc@login.ecs.soton.ac.uk [152.78.68.149]) by hawk.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id LAA16892; Fri, 29 Mar 2002 11:48:45 GMT Date: Fri, 29 Mar 2002 11:48:43 +0000 (GMT) From: Tim Chown To: Paul Vixie cc: namedroppers@ops.ietf.org, Nathan Jones Subject: Re: Last Call: Representing IPv6 addresses in DNS to Proposed Standard In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On 27 Mar 2002, Paul Vixie wrote: > Tick tock, tick tock, gentlemen. There are a couple thousand V6 hosts > around the world already. I think there's a few more than that. That just covers Japanese taxis. Tim -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 29 07:24:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09837 for ; Fri, 29 Mar 2002 07:24:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qvBo-000CLl-00 for namedroppers-data@psg.com; Fri, 29 Mar 2002 04:09:04 -0800 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by psg.com with esmtp (Exim 3.35 #1) id 16qvBn-000CLX-00 for namedroppers@ops.ietf.org; Fri, 29 Mar 2002 04:09:03 -0800 Received: from localhost ([3ffe:501:4819:2000:200:39ff:fed9:21d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g2TC8ao66031; Fri, 29 Mar 2002 21:08:39 +0900 (JST) Date: Fri, 29 Mar 2002 21:08:38 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: Last Call: Representing IPv6 addresses in DNS to Proposed Standard In-Reply-To: References: <200203141526.KAA19163@ietf.org> <20020327212727.B23106@connect.com.au> <2cu1r1lw8k.fsf@snout.autonomica.net> <20020328094454.A5859@connect.com.au> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 55 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> On 27 Mar 2002 16:42:26 -0800, >>>>> Paul Vixie said: > Tick tock, tick tock, gentlemen. There are a couple thousand V6 hosts > around the world already. Admitting A6/DNAME at this late date means > declaring that either all those hosts will have to be rototilled before > they can join the future production V6 network, or that all of their > recursive nameservers will have to be rototilled to participate in the > future production V6 network. To the hardy-souled early adopters who > have "deployed" using AAAA, rototilling their crops because they used > outdated seeds just feels like the opposite of progress. > And those are the people who are making the decision re: AAAA vs A6/DNAME. I have the same view for this issue. Through the discussion fo far, I agree that we could not reach a technical consensus. So, I admit that those who support A6 are saying "we cannot make a decision before experiencing A6 actually." have some valid points. However, from a deployment point of view, we're running out of time, at least here in Japan. We've already deployed AAAA-based implementations and configurations, and have operated IPv6 network over the environment. Based on the experiments, some large ISPs in Japan will deploy nation-wide IPv6 service within this year (some has already started the service), and they (and their customers) need mature standards. From this standpoint, the only choice between AAAA and A6 is the former -I don't think it feasible to require customers to use BIND 9 as name servers, to configure A6 as much as possible, and to use BIND 9.2 with A6 synthesis as cache servers-. So, I must say we should begin with AAAA. As far as I understand, this is the reason for changing A6 as "experimental". As repeatedly pointed out, "experimental" actually means the end of life, once we deploy AAAA widely in the commercial services. So I agree that the word "experimental" is an excuse; we're killing A6 and (possible) benefits in the future. But I'd like to start deploying IPv6 *now*, and can give up the benefits that A6 can provide. I'm not sure if my opinion above can convince DNS experts in this list...but I belive some amount of v6 community, especially those who're deploying IPv6, share the opinion. In any case, it would be sure that we need some compromise here. How can we make it? > It's odd to see some of the commercial interests who have combined in favour > of "now, limited" rather than "later, full" deployment. Sign of the times, > maybe? "Long live NAT." Perhaps we'll develop a perfect world with IPv32 and A32 someday... JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 29 07:58:32 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09629 for ; Fri, 29 Mar 2002 07:11:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qv5T-000CAX-00 for namedroppers-data@psg.com; Fri, 29 Mar 2002 04:02:31 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.35 #1) id 16qv5S-000CAJ-00 for namedroppers@ops.ietf.org; Fri, 29 Mar 2002 04:02:30 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09087; Fri, 29 Mar 2002 07:02:26 -0500 (EST) Message-Id: <200203291202.HAA09087@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-song-dnsext-nai-support-01.txt Date: Fri, 29 Mar 2002 07:02:26 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : DNS RR type for NAI Author(s) : J. Song Filename : draft-song-dnsext-nai-support-01.txt Pages : 7 Date : 28-Mar-02 This document proposes the use of the new DNS RR type 'NAI' (Network Access Identifier) [RFC2486] to specify dynamically assigned IP address A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-song-dnsext-nai-support-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-song-dnsext-nai-support-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-song-dnsext-nai-support-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020328141241.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-song-dnsext-nai-support-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-song-dnsext-nai-support-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020328141241.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 29 08:51:54 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13259 for ; Fri, 29 Mar 2002 08:51:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qwbk-000Evj-00 for namedroppers-data@psg.com; Fri, 29 Mar 2002 05:39:56 -0800 Received: from [202.96.136.222] (helo=public.szptt.net.cn) by psg.com with smtp (Exim 3.35 #1) id 16qwbg-000EvB-00 for namedroppers@ops.ietf.org; Fri, 29 Mar 2002 05:39:54 -0800 Received: from public.szptt.net.cn([202.96.136.222]) by public.szptt.net.cn(JetMail 2.5.3.0) with SMTP id jm43ca4e28f; Fri, 29 Mar 2002 13:39:24 -0000 Received: from loki.ietf.org([132.151.1.177]) by public.szptt.net.cn(JetMail 2.5.3.0) with SMTP id jm83ca20f5d; Wed, 27 Mar 2002 13:38:47 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA25650 for ietf-123-outbound.01@ietf.org; Wed, 27 Mar 2002 07:25:00 -0500 (EST) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA25305 for ; Wed, 27 Mar 2002 07:08:23 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23222; Wed, 27 Mar 2002 07:08:20 -0500 (EST) Message-Id: <200203271208.HAA23222@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-10.txt Date: Wed, 27 Mar 2002 07:08:20 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Link-Local Multicast Name Resolution (LLMNR) Author(s) : L. Esibov, B. Aboba, D. Thaler Filename : draft-ietf-dnsext-mdns-10.txt Pages : 19 Date : 26-Mar-02 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 name resolution in such environments, Link-Local Multicast Name Resolution (LLMNR) is proposed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-10.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-10.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-10.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: <20020326114004.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020326114004.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 29 11:44:41 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21995 for ; Fri, 29 Mar 2002 11:44:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16qzF9-000Jf0-00 for namedroppers-data@psg.com; Fri, 29 Mar 2002 08:28:47 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.35 #1) id 16qzF8-000Jeu-00 for namedroppers@ops.ietf.org; Fri, 29 Mar 2002 08:28:46 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 044D428DC4 for ; Fri, 29 Mar 2002 08:28:46 -0800 (PST) (envelope-from paul@vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Last Call: Representing IPv6 addresses in DNS to Proposed Standard In-Reply-To: Message from JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= of "Fri, 29 Mar 2002 21:08:38 +0900." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Fri, 29 Mar 2002 08:28:46 -0800 Message-Id: <20020329162846.044D428DC4@as.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > As repeatedly pointed out, "experimental" actually means the end > of life, once we deploy AAAA widely in the commercial services. So I > agree that the word "experimental" is an excuse; we're killing A6 and > (possible) benefits in the future. But I'd like to start deploying > IPv6 *now*, and can give up the benefits that A6 can provide. "long live nat" -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 29 15:57:20 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03368 for ; Fri, 29 Mar 2002 15:57:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16r3ET-0000tn-00 for namedroppers-data@psg.com; Fri, 29 Mar 2002 12:44:21 -0800 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.35 #1) id 16r3ES-0000th-00 for namedroppers@ops.ietf.org; Fri, 29 Mar 2002 12:44:20 -0800 Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id 2A23A1C11 for ; Fri, 29 Mar 2002 15:44:19 -0500 (EST) Date: Fri, 29 Mar 2002 15:44:18 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Reply-To: namedroppers@ops.ietf.org Subject: Re: Last Call: Representing IPv6 addresses in DNS to Proposed Standard In-Reply-To: References: <200203141526.KAA19163@ietf.org> <20020327212727.B23106@connect.com.au> <2cu1r1lw8k.fsf@snout.autonomica.net> <20020328094454.A5859@connect.com.au> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020329204419.2A23A1C11@thrintun.hactrn.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Fri, 29 Mar 2002 21:08:38 +0900, JINMEI Tatuya wrote: > > I'm not sure if my opinion above can convince DNS experts in this > list...but I belive some amount of v6 community, especially those > who're deploying IPv6, share the opinion. Some of the "DNS experts" (if that's what we are) already agree with you on this. As I see it, the fundamental issue is that most of the people trying to deploy IPv6 believe (1) that they have more urgent concerns than this little DNS issue and (2) that they are more likely to accomplish their main purpose by going with AAAA. We could debate whether this view is correct or not until the proverbial cows come home, but I see little to be gained by doing so. > In any case, it would be sure that we need some compromise here. How > can we make it? The options that I can see are: a) Accept the course of action recommended by the draft currently in last call, and with the understanding that this is and will remain at best a very rough consensus; or b) Flip a coin, if everyone involved would be willing to abide by the result (probability of which left as an exercise for the reader); or c) Sign the horse up for another year of singing lessons. --Rob References: "Recommendations" section of draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt (disclaimer: I wrote it, YMMV); "Conclusion" section of IEN 137 ("On Holy Wars and a Plea For Peace"). Fable sometimes referred to by the tag line "And Maybe The Horse Will Sing", attributed to Herodotus. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Mar 31 18:54:24 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00513 for ; Sun, 31 Mar 2002 18:54:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16ropR-0009mx-00 for namedroppers-data@psg.com; Sun, 31 Mar 2002 15:33:41 -0800 Received: from padda.telia.net ([195.198.164.130]) by psg.com with esmtp (Exim 3.35 #1) id 16ropP-0009mq-00 for namedroppers@ops.ietf.org; Sun, 31 Mar 2002 15:33:40 -0800 Received: from localhost (dufberg@localhost) by padda.telia.net (8.11.6/8.11.6) with ESMTP id g2VNXbu24425 for ; Mon, 1 Apr 2002 01:33:38 +0200 (CEST) (envelope-from dufberg@telia.net) X-Authentication-Warning: padda.telia.net: dufberg owned process doing -bs Date: Mon, 1 Apr 2002 01:33:37 +0200 (CEST) From: Mats Dufberg To: namedroppers Subject: Re: Opt-in wg last call In-Reply-To: Message-ID: <20020401012215.M7955-100000@padda.telia.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mar 25, 2002, 13:13 (-0800) Olafur Gudmundsson and Randy Bush...: > This message starts a two week last call on Opt-In limited to NS > delagtions. From discussion on the mailing list, we believe that > this compromise position is somewhat more accepted than either of > the 'no opt-in' and 'unlimited opt-in' alternatives. The only arguments in favor of limited opt-in I have seen have been on some kind of moral ground. Are there any technical arguments that I cannot see in favor of limiting opt-in? When administrating DNS you are focused on the zone as a unit. DNSsec has also focused on that unit. But queries are not based on zone, and they can happily skip zones when parent and child resides on the same server, or some server happens to do resolving. Queries are based on names and its data, and opt-in refocus on names as being secured or not. > If you feel that you can not live with this compromise, then and > only then, please explain why to the list. I think I'll survive any decision taken in this matter. :-) But until I see good technical grounds for limiting opt-in, I propose full opt-in. Mats ---------------------------------------------------------------------- Mats Dufberg Registry TeliaNet dufberg@telia.net Skanova/AO Networks +46 8 456 7274 Box 10707 +46 70 258 2588 SE-121 29 Stockholm ---------------------------------------------------------------------- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: