From owner-namedroppers@ops.ietf.org Sat Mar 1 06:11:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02939 for ; Sat, 1 Mar 2003 06:11:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18p4ip-000Pfb-00 for namedroppers-data@psg.com; Sat, 01 Mar 2003 03:00:03 -0800 Received: from randy by psg.com with local (Exim 3.36 #1) id 18p4im-000PfB-00 for namedroppers@ops.ietf.org; Sat, 01 Mar 2003 03:00:00 -0800 To: namedroppers@ops.ietf.org Subject: list policy Message-Id: From: Randy Bush Date: Sat, 01 Mar 2003 03:00:00 -0800 X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_02_03,SUBJECT_IS_LIST version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk namedroppers@ops.ietf.org is the mailing list for the ietf dnsext wg. see for the wg charter. messages should be on topics appropriate to the dnsext wg, which are various discussion of the dns protocols or administrivia of the wg itself. calls for papers, announcements of events not directly relevant to the dns protocols, etc. are not appropriate. discussion of problems with particular implementations, announcements of releases, sites' misconfigurations, etc. should be done on mailing lists for the particular implementations. posts are only accepted from subscribers. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to namedroppers-owner@ops.ietf.org and ask to have your alternate address added to the list of addresses from which submissions are automatically accepted. there is a wg for dns operational practice, dnsop, whose charter can be found at . there is a mailing list for discussion of whose implementation is better, and why someone else's is broken. it is weenie-war@ops.ietf.org. all discussions of such nature should occur there or on /dev/null. unlike the namedroppers list, weenie-war@ops.ietf.org is not archived. questions or concerns related to the acceptance or rejection of specific messages to the namedroppers mailing list should first be discussed with the wg chairs, with followup appeals using the normal appeals process of rfc 2026 (i.e., follup with area directors, then iesg, etc.). there is a mailing list for the discussion of ietf processes, which includes any general discussion of the moderation of ietf mailing lists. it is poised@lists.tislabs.com --- NOTE WELL: All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Mar 2 10:34:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13173 for ; Sun, 2 Mar 2003 10:34:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18pVI4-000LP8-00 for namedroppers-data@psg.com; Sun, 02 Mar 2003 07:22:12 -0800 Received: from one.elistx.com ([209.116.252.130]) by psg.com with esmtp (Exim 3.36 #1) id 18pVHr-000LOX-00 for namedroppers@ops.ietf.org; Sun, 02 Mar 2003 07:21:59 -0800 Received: from ogud.com (pcp816081pcs.nrockv01.md.comcast.net [68.49.60.118]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HB400M3YO1ONQ@eListX.com> for namedroppers@ops.ietf.org; Sun, 02 Mar 2003 10:22:36 -0500 (EST) Received: from ENGILL.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.3/8.12.3) with ESMTP id h22FM2Xs029036 for ; Sun, 02 Mar 2003 10:22:02 -0500 (EST envelope-from ogud@ogud.com) Date: Sun, 02 Mar 2003 10:20:41 -0500 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: DNSEXT draft of revised charter X-Sender: (Unverified) To: namedroppers@ops.ietf.org Message-id: <5.1.1.6.2.20030302101933.01687118@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=us-ascii X-Spam-Status: No, hits=4.6 required=5.0 tests=OPT_IN,RCVD_IN_RFCI,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: **** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Send in comments before Randy and I send this one to the IESG. DNSEXT DNS Extensions Working group --------------------------------------------------- Charter Last Modified: 28-February-2003 Current Status: Active Working Group (being rechartered) Chair(s): Randy Bush Olafur Gudmundsson Internet Area Director(s): Thomas Narten Erik Nordmark Internet Area Advisor: Erik Nordmark Mailing Lists: General Discussion: namedroppers@ops.ietf.org To Subscribe: namedroppers-request@ops.ietf.org Archive: Description of Working Group: DNS is originally specified in RFC's 1034 and 1035, with subsequent updates. Within the scope of this WG are protocol issues, including message formats, message handling, and data formats. New work items and milestones may be added from time-to-time with the approval of the Working Group and the IESG. Issues surrounding the operation of DNS, recommendations concerning the configuration of DNS servers, and other issues with the use of the protocol are out of this Working Group's charter. These issues are considered in other venues, such as operational issues in the DNS Operations Working Group. Broad topics under consideration in DNSEXT are dynamic update, notify, zone transfers, security and support for IPv6 DNS deployment. The current task within this Working Group is to advance several documents describing proposed extensions to DNS. Specific work items are: o Protocol clarifications and corrections for DNSSEC, initially these clarifications will be done as separate RFCs which will later be folded into a revised RFC 2535 etc. These include plans and changes that simplify the operation of DNSSEC. o Complete the documents that update the DNSSEC protocol, this include DS, Restrict-Key, AD-is-secure, Opt-in, etc. Generate new specification documents of DNSSEC that includes all changes to RFC2535, this includes the documents above, as well as following RFCs 2931, 3007, 3008, 3090 and 3226. o DNS clarification and extensions o IPv6 support in DNS records and IPv6 DNS services o Investigate how protocol changes, use of multicast, etc. might support zeroconf environments, the possible approaches include: LLMNR and Discover Goals and Milestones: Where there is no milestone for a work item mentioned above, the working group has not yet decided upon the priority for the item, or, in some cases, whether active work will be undertaken, and no target milestone has yet been set. Feb 03 Forward TKEY renewal mode to IESG for Experimental Standard. Mar 03 Forward IPv6 auto-registration to IESG for Experimental Mar 03 Submit to IESG RFC1886bis (AAAA) to Draft standard. Mar 03 Submit to IESG Publish DNS Discover as Experimental. Mar 03 Submit to IESG DHCID RR for Proposed Standard. Mar 03 Forward LLMNR IESG for Draft Standard. Mar 03 Determine whether to forward "DNSSEC Opt-in" IESG. Mar 03 Submit to IESG Delegation Signer for Proposed Standard. Mar 03 Submit to IESG Threat model for DNS as informational RFC. Apr 03 First WG last call on DNSSEC (RFC2535-bis). Jun 03 Issue final Last call of DNSSEC rewrite. Jul 03 Submit RFC1996 (Notify) to IESG for Draft Standard. Jul 03 Submit to IESG KEY algorithm documents RFC253[69] and RFC3110 to IESG. Aug 03 Forward RFC2535-bis to IESG for to IESG for Proposed standard. Aug 03 RFC1995 (IXFR) advanced to Draft standard. Aug 03 Submit to IESG RFC2136bis (Dynamic Update) to Draft Standard. Aug 03 Submit to IESG RFC2308 (Neg Caching) to Draft Standard. Aug 03 Submit to IESG RFC2671 (EDNS0) to Draft Standard. Oct 03 Submit to IESG AXFR clarify to Draft Standard. Nov 03 Submit to IESG RFC2835 (TSIG)to Draft standard. Nov 03 Submit to IESG RFC3007 (Secure Update) to Draft standard. Dec 03 Submit to IESG RFC2930 (TKEY) to Draft standard. Feb 04 Submit RFC2181 (Clarify) to IESG for advancement to Draft Standard. Apr 04 Submit RFC2535-bis to IESG for Draft standard. -- to unsubscribe send a message to namedroppers-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 2 11:11:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13733 for ; Sun, 2 Mar 2003 11:11:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18pVtB-000MIv-00 for namedroppers-data@psg.com; Sun, 02 Mar 2003 08:00:33 -0800 Received: from sentry.gw.tislabs.com ([192.94.214.100]) by psg.com with esmtp (Exim 3.36 #1) id 18pVt5-000MIj-00 for namedroppers@ops.ietf.org; Sun, 02 Mar 2003 08:00:27 -0800 Received: by sentry.gw.tislabs.com; id LAA04523; Sun, 2 Mar 2003 11:01:13 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma004515; Sun, 2 Mar 03 11:00:55 -0500 Received: from localhost (weiler@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) with ESMTP id h22G08W12456 for ; Sun, 2 Mar 2003 11:00:08 -0500 (EST) Date: Sun, 2 Mar 2003 11:00:08 -0500 (EST) From: Sam Weiler X-X-Sender: To: Subject: draft-weiler-dnsext-dnssec-2535-compat-00.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: X-Spam-Status: No, hits=3.5 required=5.0 tests=OPT_IN,SEARCH_ENGINE_PROMO,SPAM_PHRASE_01_02, USER_AGENT_PINE version=2.43 X-Spam-Level: *** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This document describes a solution to a backwards incompatibility problem between DS and resolvers that understand RFC2535. The proposed solution of rolling the DNSSEC RR type codes has been implemented and received some testing at the opt-in workshop at RIPE in January (see Olaf's message of 5 Feburary and the ensuing discussion). The same problem may be triggered when legacy resolvers see proofs of delegations being in insecure spans using opt-in, but this has not been tested. This problem was diagnosed by Jakob Schlyter and Mark Andrews earlier this year, though it probably caused some of the misbehavior seen on testbeds and in workshops last year. -- Sam ---------- Forwarded message ---------- Date: Thu, 27 Feb 2003 07:43:48 -0500 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Subject: I-D ACTION:draft-weiler-dnsext-dnssec-2535-compat-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Legacy Resolver Compatibility for Delegation Signer Author(s) : S. Weiler Filename : draft-weiler-dnsext-dnssec-2535-compat-00.txt Pages : 0 Date : 2003-2-26 As the DNS Security (DNSSEC) specifications have evolved, the syntax and semantics of the DNSSEC resource records have changed. Many deployed nameservers understand variants of these semantics. To avoid dangerous interactions when a resolver that understands an earlier version of these semantics queries an authoritative server that understands the new delegation signer semantics, this document proposes changing the type codes and mnemonics of the previous DNSSEC resource records (SIG, KEY, and NXT). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-weiler-dnsext-dnssec-2535-compat-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-weiler-dnsext-dnssec-2535-compat-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-weiler-dnsext-dnssec-2535-compat-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Mar 2 11:44:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14236 for ; Sun, 2 Mar 2003 11:44:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18pWSy-000NJG-00 for namedroppers-data@psg.com; Sun, 02 Mar 2003 08:37:32 -0800 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 18pWSv-000NJ4-00 for namedroppers@ops.ietf.org; Sun, 02 Mar 2003 08:37:29 -0800 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.6/8.12.6/Debian-7) with ESMTP id h22GbN0N017902; Sun, 2 Mar 2003 17:37:24 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.6/8.12.6/Debian-7) with ESMTP id h22GbNUf017899; Sun, 2 Mar 2003 17:37:23 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Sun, 2 Mar 2003 17:37:23 +0100 (CET) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: Sam Weiler cc: namedroppers@ops.ietf.org Subject: Re: draft-weiler-dnsext-dnssec-2535-compat-00.txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-2.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT, REFERENCES,SPAM_PHRASE_00_01,USER_AGENT_PINE,X_AUTH_WARNING version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sun, 2 Mar 2003, Sam Weiler wrote: > This document describes a solution to a backwards incompatibility > problem between DS and resolvers that understand RFC2535. The > proposed solution of rolling the DNSSEC RR type codes has been > implemented and received some testing at the opt-in workshop at RIPE > in January (see Olaf's message of 5 Feburary and the ensuing > discussion). The same problem may be triggered when legacy resolvers > see proofs of delegations being in insecure spans using opt-in, > but this has not been tested. > > This problem was diagnosed by Jakob Schlyter and Mark Andrews earlier > this year, though it probably caused some of the misbehavior seen on > testbeds and in workshops last year. Sam, Proposing new DNSSEC RR type codes implies upgrading resolvers, which seems to be exactly what you wanted to avoid. 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 Sun Mar 2 23:48:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26724 for ; Sun, 2 Mar 2003 23:48:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18phhD-000GZi-00 for namedroppers-data@psg.com; Sun, 02 Mar 2003 20:36:59 -0800 Received: from sentry.gw.tislabs.com ([192.94.214.100]) by psg.com with esmtp (Exim 3.36 #1) id 18phhB-000GZW-00 for namedroppers@ops.ietf.org; Sun, 02 Mar 2003 20:36:57 -0800 Received: by sentry.gw.tislabs.com; id XAA13767; Sun, 2 Mar 2003 23:37:43 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma013734; Sun, 2 Mar 03 23:36:47 -0500 Received: from localhost (weiler@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) with ESMTP id h234Zxt02170; Sun, 2 Mar 2003 23:35:59 -0500 (EST) Date: Sun, 2 Mar 2003 23:35:59 -0500 (EST) From: Sam Weiler X-X-Sender: To: Roy Arends cc: Subject: Re: draft-weiler-dnsext-dnssec-2535-compat-00.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sun, 2 Mar 2003, Roy Arends wrote: > > Proposing new DNSSEC RR type codes implies upgrading resolvers, > which seems to be exactly what you wanted to avoid. DS already forces resolvers to upgrade if they want DNSSEC validation. I'm trying to make sure that resolvers that don't understand DS at least get (and don't discard) insecure answers. The problem described causes legacy resolvers to discard good data from signed zones. If that were likely to happen, some zones (cnn.com. being my favorite example) would REALLY not want their parent to be signed. I don't want to see the CNN's of the world lobbying to keep .com from being signed. -- Sam -- to unsubscribe send a message to namedroppers-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 3 06:31:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17356 for ; Mon, 3 Mar 2003 06:31:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18pnvv-0001JC-00 for namedroppers-data@psg.com; Mon, 03 Mar 2003 03:16:35 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #1) id 18pnvs-0001Iz-00 for namedroppers@ops.ietf.org; Mon, 03 Mar 2003 03:16:32 -0800 Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.5/8.11.6) with SMTP id h23BGRUm011854; Mon, 3 Mar 2003 12:16:28 +0100 Date: Mon, 3 Mar 2003 12:16:27 +0100 From: "Olaf M. Kolkman" To: Brian Wellington Cc: sra+namedroppers@hactrn.net, namedroppers@ops.ietf.org Subject: Re: Q-6: May security-aware resolvers cache "Bad" data? Message-Id: <20030303121627.229a85de.olaf@ripe.net> In-Reply-To: References: <20030228201606.BCF9018EC@thrintun.hactrn.net> <20030301002842.A696E18EC@thrintun.hactrn.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_02_03,SUBJECT_MONTH version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > If that's what you mean, I'd suggest not using the term "negative > caching", which is well defined (the caching of a negative response, > where negative means either the host or type doesn't exist). I'd use a > new term, like "failure caching". > > While forbidding failure caching might be going a bit far, caching > failures is really not a good idea. It means that if a server receives > a spoofed response, it will cache the data, and use the cached failure > as an indication to not try again. This leads to obvious DoS attacks. > Not caching failures has other problems (bandwidth amplification > attacks), but the ability to spoof a server into caching failure is much > worse. Just one comment: There are two reasons for failure: Crypto failure and Expiration. You may want to treat them differently. If you do failure caching (I am not quite convinced you want to) you want to do that based on local policy and use TTLs that are relatively short (order 10s of seconds). --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 3 06:31:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17375 for ; Mon, 3 Mar 2003 06:31:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18po3j-0001XC-00 for namedroppers-data@psg.com; Mon, 03 Mar 2003 03:24:39 -0800 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 18po3g-0001Wk-00 for namedroppers@ops.ietf.org; Mon, 03 Mar 2003 03:24:37 -0800 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.6/8.12.6/Debian-7) with ESMTP id h23BOTY1014755; Mon, 3 Mar 2003 12:24:29 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.6/8.12.6/Debian-7) with ESMTP id h23BOSEi014747; Mon, 3 Mar 2003 12:24:28 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Mon, 3 Mar 2003 12:24:28 +0100 (CET) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: Sam Weiler cc: namedroppers@ops.ietf.org Subject: Re: draft-weiler-dnsext-dnssec-2535-compat-00.txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-2.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT, REFERENCES,SPAM_PHRASE_00_01,USER_AGENT_PINE,X_AUTH_WARNING version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sun, 2 Mar 2003, Sam Weiler wrote: > On Sun, 2 Mar 2003, Roy Arends wrote: > > > > Proposing new DNSSEC RR type codes implies upgrading resolvers, > > which seems to be exactly what you wanted to avoid. > > DS already forces resolvers to upgrade if they want DNSSEC validation. > > I'm trying to make sure that resolvers that don't understand DS at > least get (and don't discard) insecure answers. The problem described > causes legacy resolvers to discard good data from signed zones. If > that were likely to happen, some zones (cnn.com. being my favorite > example) would REALLY not want their parent to be signed. I don't > want to see the CNN's of the world lobbying to keep .com from being > signed. Yes, I understand the problem involved. I also understand what your draft is trying to accomplish. The problem is caused by false negatives. Both DS, Opt-In and Wildcard processing introduce false negatives (NXT!=NXDOMAIN) for legacy DNSSEC resolvers. The underlying issue is that a Flag Day was introduced while 'Flagging' is currently done by implicit assertion instead of explicit notification. Implicit assertions may lead to false negatives, higher bandwith use (retransmits), and delay in processing messages (multiple transmissions before an assertion can be made). Without proper implicit assertions or explicit notifications (DO/DA bit), a flag day is no flag day. I'd like to see some stats which 2535 legacy resolver brands and versions have this false negative issue. I'd also like to see the exact problem space documented (at least touch the problem in the abstract), _before_ wild (and _very_ expensive, in both time & money) solutions are given. Anykey, just my opinion, Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 3 06:53:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18966 for ; Mon, 3 Mar 2003 06:53:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18poQk-00026y-00 for namedroppers-data@psg.com; Mon, 03 Mar 2003 03:48:26 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 18poQi-00026m-00 for namedroppers@ops.ietf.org; Mon, 03 Mar 2003 03:48:24 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18001; Mon, 3 Mar 2003 06:46:21 -0500 (EST) Message-Id: <200303031146.GAA18001@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-insensitive-02.txt Date: Mon, 03 Mar 2003 06:46:21 -0500 X-Spam-Status: No, hits=4.6 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.43 X-Spam-Level: **** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Domain Name System (DNS) Case Insensitivity Clarification Author(s) : D. Eastlake Filename : draft-ietf-dnsext-insensitive-02.txt Pages : 10 Date : 2003-2-28 Domain Name System (DNS) names are 'case insensitive'. This document explains exactly what that means and provides a clear specification of the rules. This clarification should not have any interoperability consequences. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-insensitive-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-insensitive-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-insensitive-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: <2003-2-28125107.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-insensitive-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-insensitive-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-28125107.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 Mon Mar 3 14:24:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08643 for ; Mon, 3 Mar 2003 14:23:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18pvEt-000H7v-00 for namedroppers-data@psg.com; Mon, 03 Mar 2003 11:04:39 -0800 Received: from [2002:425c:4242:0:250:daff:fe82:1c39] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 18pvEq-000H6J-00 for namedroppers@ops.ietf.org; Mon, 03 Mar 2003 11:04:37 -0800 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id DD7A118EF for ; Mon, 3 Mar 2003 14:04:03 -0500 (EST) Date: Mon, 03 Mar 2003 14:04:03 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: draft-ietf-dnsext-dnssec-protocol-01.txt References: <20030215014807.C29F218EC@thrintun.hactrn.net> User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030303190403.DD7A118EF@thrintun.hactrn.net> X-Spam-Status: No, hits=-0.2 required=5.0 tests=REFERENCES,SPAM_PHRASE_00_01,USER_AGENT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I sent draft-ietf-dnsext-dnssec-protocol-01.txt to the Internet-Drafts administrator last night on behalf of the DNSSEC document editing team. Since we were still working on it until a few hours before the cut-off, this draft is presumably somewhere near the tail of the I-D queue, and won't be posted to the public directory for a while yet. In the meantime, here's the URL for what I sent: http://www.hactrn.net/ietf/dns/dnssec-editors/draft-ietf-dnsext-dnssec-protocol-01.txt Comments actively solicited, the sooner the better. See the WG chairs' periodic posting to this list on "DNSSEC editing process" for details on where to send feedback. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 4 07:43:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15961 for ; Tue, 4 Mar 2003 07:43:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18qBXW-000Iu1-00 for namedroppers-data@psg.com; Tue, 04 Mar 2003 04:28:58 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 18qBXT-000Itp-00 for namedroppers@ops.ietf.org; Tue, 04 Mar 2003 04:28:55 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14200; Tue, 4 Mar 2003 07:26:52 -0500 (EST) Message-Id: <200303041226.HAA14200@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-13.txt Date: Tue, 04 Mar 2003 07:26:52 -0500 X-Spam-Status: No, hits=4.6 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.43 X-Spam-Level: **** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Delegation Signer Resource Record Author(s) : O. Gudmundsson Filename : draft-ietf-dnsext-delegation-signer-13.txt Pages : 16 Date : 2003-3-3 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. The DS RR is a modification to the DNS Security Extensions definition, motivated by operational considerations. The intent is to use this resource record as an explicit statement about the delegation, rather than relying on inference. This document defines the DS RR, gives examples of how it is used and the implications of this record on resolvers. This change is not backwards compatible with RFC 2535. This document updates RFC1035, RFC2535, RFC3008 and RFC3090. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-delegation-signer-13.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-13.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-13.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-3144453.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-delegation-signer-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-delegation-signer-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-3144453.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 4 12:31:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02728 for ; Tue, 4 Mar 2003 12:31:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18qG35-000BE3-00 for namedroppers-data@psg.com; Tue, 04 Mar 2003 09:17:51 -0800 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by psg.com with esmtp (Exim 3.36 #1) id 18qG33-000BDq-00 for namedroppers@ops.ietf.org; Tue, 04 Mar 2003 09:17:49 -0800 Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h24HHk57021295; Tue, 4 Mar 2003 09:17:47 -0800 (PST) Date: Tue, 4 Mar 2003 12:17:46 -0500 (EST) From: Ralph Droms To: dhcwg@ietf.org, , Subject: Results of WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.2 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt: Accept with editorial changes, as summarized in previous e-mail http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg01827.html; draft-ietf-dhc-dhcpv6-opt-dnsconfig-03.txt has been submitted for publication and will be ready for IESG review (there is a minor issue remaining concerning the naming of the "DNS resolver" option) -- to unsubscribe send a message to namedroppers-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 5 06:53:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27742 for ; Wed, 5 Mar 2003 06:53:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18qX6I-00052y-00 for namedroppers-data@psg.com; Wed, 05 Mar 2003 03:30:18 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 18qX6F-00052j-00 for namedroppers@ops.ietf.org; Wed, 05 Mar 2003 03:30:15 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25420; Wed, 5 Mar 2003 06:28:08 -0500 (EST) Message-Id: <200303051128.GAA25420@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-gss-tsig-06.txt Date: Wed, 05 Mar 2003 06:28:08 -0500 X-Spam-Status: No, hits=4.6 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.43 X-Spam-Level: **** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : GSS Algorithm for TSIG (GSS-TSIG) Author(s) : S. Kwan, P. Garg, J. Gilroy, L. Esibov, J. Westhead, R. Hall Filename : draft-ietf-dnsext-gss-tsig-06.txt Pages : 22 Date : 2003-3-4 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). This document updates RFC 2845. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-gss-tsig-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-gss-tsig-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-gss-tsig-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-4173735.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-gss-tsig-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-gss-tsig-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-4173735.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 5 06:53:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27775 for ; Wed, 5 Mar 2003 06:53:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18qX6D-00052h-00 for namedroppers-data@psg.com; Wed, 05 Mar 2003 03:30:13 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 18qX6A-00052U-00 for namedroppers@ops.ietf.org; Wed, 05 Mar 2003 03:30:10 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25401; Wed, 5 Mar 2003 06:28:04 -0500 (EST) Message-Id: <200303051128.GAA25401@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-rfc1886bis-02.txt Date: Wed, 05 Mar 2003 06:28:04 -0500 X-Spam-Status: No, hits=4.6 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.43 X-Spam-Level: **** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNS Extensions to support IP version 6 Author(s) : S. Thomson, C. Huitema et al. Filename : draft-ietf-dnsext-rfc1886bis-02.txt Pages : 7 Date : 2003-3-4 This document defines the changes that need to be made to the Domain Name System to support hosts running IP version 6 (IPv6). The changes include a resource record type to store an IPv6 address, a domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves. This Document combines RFC1886 and changes to RFC 1886 made by RFC 3152, obsoleting both. Changes mainly consist in replacing the IP6.INT domain by IP6.ARPA as defined in RFC 3152. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc1886bis-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-rfc1886bis-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-rfc1886bis-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: <2003-3-4173726.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-rfc1886bis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-rfc1886bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-4173726.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 5 08:19:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29567 for ; Wed, 5 Mar 2003 08:19:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18qYhF-0009yI-00 for namedroppers-data@psg.com; Wed, 05 Mar 2003 05:12:33 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 18qYhB-0009xs-00 for namedroppers@ops.ietf.org; Wed, 05 Mar 2003 05:12:29 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h25DCRJW075520; Wed, 5 Mar 2003 08:12:27 -0500 (EST) Received: from [192.149.252.108] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id IAA07954; Wed, 5 Mar 2003 08:12:24 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 (Unverified) Message-Id: In-Reply-To: <20030228201606.BCF9018EC@thrintun.hactrn.net> References: <20030228201606.BCF9018EC@thrintun.hactrn.net> Date: Wed, 5 Mar 2003 08:12:21 -0500 To: Rob Austein From: Edward Lewis Subject: Re: Q-6: May security-aware resolvers cache "Bad" data? Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-2.1 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,SUBJECT_MONTH version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk There's one more case - an RRset for which a SIG RR should exist but the cache has none. I.e., someone (ye olde cache?) stripped out the SIG's from the message. At 15:16 -0500 2/28/03, Rob Austein wrote: >Q: Is a security-aware resolver allowed to cache RRsets for which one > or more SIG RRs exist but none of them validate? > >Discussion: > >Excerpt from RFC 2535, section 6: > > Data stored at a security aware server needs to be internally > categorized as Authenticated, Pending, or Insecure. There is also a > fourth transient state of Bad which indicates that all SIG checks > have explicitly failed on the data. Such Bad data is not retained at > a security aware server. > >This appears to rule out any form of caching for RRsets with >signatures which do not validate, including any form of negative >caching. Given the demonstrated need for negative response caching in >insecure DNS, this prohibition seems ill-advised. > >Please also note that this appears to be dictating implementation >details than just describing externally visible behavior, and that the >RFC 2535 rule may require a security-aware recursive name server to >leave itself open to denial of CPU-time attacks by requiring the >server to repeat the same signature checks over and over again. > >Should we remove this prohibition? Pro removal: the crypto equivalent of neg caching is possible. OTOH: an attack of sending bad SIG's can "starve" a cache Pro removal: local policy can be to return data only if the cd bit is set (i.e., saves cache from requerying itself on repeated queries) OTOH: not caching it makes the requester try to get it from source (i.e., will return it anyway on +cd, but won't remember) I think removing the restriction places the power back into the hands of local policy, which is good, but am not sure if this makes the caches more or less "middle-boxy." How about a requirement that a recursive server, in response to a query with the CD bit set to 1, returns the requested data regardless of local policy. I.e., the recursive could answer from local (unverified) cache or could reissue a recursive query becuase it won't admit unverified data sets to the cache. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 5 09:51:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02068 for ; Wed, 5 Mar 2003 09:51:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18qa7m-000Ee9-00 for namedroppers-data@psg.com; Wed, 05 Mar 2003 06:44:02 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 18qa7k-000Edw-00 for namedroppers@ops.ietf.org; Wed, 05 Mar 2003 06:44:00 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h25EhvJW077644; Wed, 5 Mar 2003 09:43:58 -0500 (EST) Received: from [192.149.252.108] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id JAA22480; Wed, 5 Mar 2003 09:43:57 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <003a01c2d2c6$3d53e0e0$b9370681@barnacle> References: <003a01c2d2c6$3d53e0e0$b9370681@barnacle> Date: Wed, 5 Mar 2003 09:43:56 -0500 To: "Scott Rose" From: Edward Lewis Subject: Re: Q1 followup - arguements against "MUST NOT" language Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-1.2 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,TO_BE_REMOVED_REPLY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Also, what do you mean by "use" ;) I'm leaning towards "MUST NOT compress domain names in the RDATA sections when assembling and transmitting a message." (Includes dynamic update request messages when using this wording.) 1) Bytes compressed away in a SIG message are miniscule compared to the signature. 2) A response won't have many NXT's anyway (unlike NS records which may be numerous in a referral). 3) Assuming EDNS0 is going to enlarge the minimum maximum message size from 512, what's a few extra bytes. At 13:40 -0500 2/12/03, Scott Rose wrote: >The general consensus is that name compression in RDATA is A Bad Thing (tm), >but there are some differences on the wording for the spec: > >Sub-Question: What are the arguments against using the terms (1)"MUST NOT >use name compression on DNS names in the RDATA on sending over the wire" >(paraphrasing here) over (2)"SHOULD NOT use name compression on DNS names in >the RDATA..."? > >Notes: > A. (1) is the strength of the wording used in the unknown-rrs draft. >There would be consistency. > > > >Scott > > > > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 5 10:49:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07403 for ; Wed, 5 Mar 2003 10:49:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18qb40-000I8r-00 for namedroppers-data@psg.com; Wed, 05 Mar 2003 07:44:12 -0800 Received: from pushme.nist.gov ([129.6.16.92] helo=postmark.nist.gov) by psg.com with esmtp (Exim 3.36 #1) id 18qb3n-000I7b-00 for namedroppers@ops.ietf.org; Wed, 05 Mar 2003 07:44:00 -0800 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h25FhkVd014616 for ; Wed, 5 Mar 2003 10:43:46 -0500 (EST) Message-ID: <00d701c2e32e$03c10f60$b9370681@barnacle> From: "Scott Rose" To: References: <003a01c2d2c6$3d53e0e0$b9370681@barnacle> Subject: Re: Q1 followup - arguements against "MUST NOT" language Date: Wed, 5 Mar 2003 10:43:48 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=0.1 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, TO_BE_REMOVED_REPLY,USER_AGENT_OE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit That seems to be the prevailing winds - MUST NOT compress DNS names in the RDATA (paraphrase). Basically, change the DNSSEC specs to keep in line with the unknown-rrs draft and namedroppers discussion. Scott ----- Original Message ----- From: "Edward Lewis" To: "Scott Rose" Cc: Sent: Wednesday, March 05, 2003 9:43 AM Subject: Re: Q1 followup - arguements against "MUST NOT" language > Also, what do you mean by "use" ;) > > I'm leaning towards "MUST NOT compress domain names in the RDATA > sections when assembling and transmitting a message." (Includes > dynamic update request messages when using this wording.) > > 1) Bytes compressed away in a SIG message are miniscule compared to > the signature. > > 2) A response won't have many NXT's anyway (unlike NS records which > may be numerous in a referral). > > 3) Assuming EDNS0 is going to enlarge the minimum maximum message > size from 512, what's a few extra bytes. > > > At 13:40 -0500 2/12/03, Scott Rose wrote: > >The general consensus is that name compression in RDATA is A Bad Thing (tm), > >but there are some differences on the wording for the spec: > > > >Sub-Question: What are the arguments against using the terms (1)"MUST NOT > >use name compression on DNS names in the RDATA on sending over the wire" > >(paraphrasing here) over (2)"SHOULD NOT use name compression on DNS names in > >the RDATA..."? > > > >Notes: > > A. (1) is the strength of the wording used in the unknown-rrs draft. > >There would be consistency. > > > > > > > >Scott > > > > > > > > > >-- > >to unsubscribe send a message to namedroppers-request@ops.ietf.org with > >the word 'unsubscribe' in a single line as the message text body. > >archive: > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 5 10:51:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07674 for ; Wed, 5 Mar 2003 10:51:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18qb2b-000I4m-00 for namedroppers-data@psg.com; Wed, 05 Mar 2003 07:42:45 -0800 Received: from [2001:6e0:206:1:250:daff:fe3d:1d6] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 3.36 #1) id 18qb2T-000I49-00 for namedroppers@ops.ietf.org; Wed, 05 Mar 2003 07:42:37 -0800 Received: from open.nlnetlabs.nl (localhost [IPv6:::1]) by open.nlnetlabs.nl (8.12.6/8.12.6) with ESMTP id h25FgVec079628; Wed, 5 Mar 2003 16:42:31 +0100 (CET) (envelope-from alexis@open.nlnetlabs.nl) Received: (from alexis@localhost) by open.nlnetlabs.nl (8.12.6/8.12.6/Submit) id h25FgUWE079627; Wed, 5 Mar 2003 16:42:30 +0100 (CET) Message-Id: <200303051542.h25FgUWE079627@open.nlnetlabs.nl> Subject: Re: Q1 followup - arguements against "MUST NOT" language In-Reply-To: To: Edward Lewis Date: Wed, 5 Mar 2003 16:42:30 +0100 (CET) From: Alexis Yushin CC: Scott Rose , namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, hits=-0.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, TO_BE_REMOVED_REPLY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think that we should try to keep the standards as uniform as possible. Making million exceptions to the rules is the ultimate Bad Thing (tm). I dont see why name compression in RDATA is necessary a bad thing, I do see that making different rules for different RR RDATA complicates the standards, implementation and definitely introduces more potentional interoperability issues. Alexis Once Edward Lewis wrote: >Also, what do you mean by "use" ;) > >I'm leaning towards "MUST NOT compress domain names in the RDATA >sections when assembling and transmitting a message." (Includes >dynamic update request messages when using this wording.) > >1) Bytes compressed away in a SIG message are miniscule compared to >the signature. > >2) A response won't have many NXT's anyway (unlike NS records which >may be numerous in a referral). > >3) Assuming EDNS0 is going to enlarge the minimum maximum message >size from 512, what's a few extra bytes. > > >At 13:40 -0500 2/12/03, Scott Rose wrote: >>The general consensus is that name compression in RDATA is A Bad Thing (tm), >>but there are some differences on the wording for the spec: >> >>Sub-Question: What are the arguments against using the terms (1)"MUST NOT >>use name compression on DNS names in the RDATA on sending over the wire" >>(paraphrasing here) over (2)"SHOULD NOT use name compression on DNS names in >>the RDATA..."? >> >>Notes: >> A. (1) is the strength of the wording used in the unknown-rrs draft. >>There would be consistency. >> >> >> >>Scott >> >> >> >> >>-- >>to unsubscribe send a message to namedroppers-request@ops.ietf.org with >>the word 'unsubscribe' in a single line as the message text body. >>archive: > >-- >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >Edward Lewis +1-703-227-9854 >ARIN Research Engineer > > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: > -- to unsubscribe send a message to namedroppers-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 5 11:06:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09273 for ; Wed, 5 Mar 2003 11:06:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18qbIY-000JIi-00 for namedroppers-data@psg.com; Wed, 05 Mar 2003 07:59:14 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 18qbIV-000JIW-00 for namedroppers@ops.ietf.org; Wed, 05 Mar 2003 07:59:11 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h25Fx5JW080825; Wed, 5 Mar 2003 10:59:05 -0500 (EST) Received: from [192.149.252.108] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id KAA05825; Wed, 5 Mar 2003 10:59:05 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <200303051542.h25FgUWE079627@open.nlnetlabs.nl> References: <200303051542.h25FgUWE079627@open.nlnetlabs.nl> Date: Wed, 5 Mar 2003 10:59:05 -0500 To: Alexis Yushin From: Edward Lewis Subject: Re: Q1 followup - arguements against "MUST NOT" language Cc: Edward Lewis , Scott Rose , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-1.2 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,TO_BE_REMOVED_REPLY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The "bad thing" is that each RR becomes some form of a special case. I.e., you have to know (upon receipt) where a domain name sits in the RDATA. Having written resolver code and DNSSEC verification code, it's a pain. Not only do you have to know where to find the possible compression, you have to write to a new buffer that is expanded, possibly in the middle. If you compress in a RR than is unknown to a receiver, then the receiver stands no chance at achieving any DNSSEC validation of the data. 'Course, once again, validation oughta be end-to-end, so maybe that's a non-issue. At 16:42 +0100 3/5/03, Alexis Yushin wrote: >I think that we should try to keep the standards as uniform as possible. >Making million exceptions to the rules is the ultimate Bad Thing (tm). > >I dont see why name compression in RDATA is necessary a bad thing, I do >see that making different rules for different RR RDATA complicates the >standards, implementation and definitely introduces more potentional >interoperability issues. > >Alexis > > >Once Edward Lewis wrote: >>Also, what do you mean by "use" ;) >> >>I'm leaning towards "MUST NOT compress domain names in the RDATA >>sections when assembling and transmitting a message." (Includes >>dynamic update request messages when using this wording.) >> >>1) Bytes compressed away in a SIG message are miniscule compared to >>the signature. >> >>2) A response won't have many NXT's anyway (unlike NS records which >>may be numerous in a referral). >> >>3) Assuming EDNS0 is going to enlarge the minimum maximum message >>size from 512, what's a few extra bytes. >> >> >>At 13:40 -0500 2/12/03, Scott Rose wrote: >>>The general consensus is that name compression in RDATA is A Bad Thing (tm), >>>but there are some differences on the wording for the spec: >>> >>>Sub-Question: What are the arguments against using the terms (1)"MUST NOT >>>use name compression on DNS names in the RDATA on sending over the wire" >>>(paraphrasing here) over (2)"SHOULD NOT use name compression on DNS names in >>>the RDATA..."? >>> >>>Notes: >>> A. (1) is the strength of the wording used in the unknown-rrs draft. >>>There would be consistency. >>> >>> >>> >>>Scott >>> >>> >>> >>> >>>-- >>>to unsubscribe send a message to namedroppers-request@ops.ietf.org with >>>the word 'unsubscribe' in a single line as the message text body. >>>archive: >> >>-- >>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >>Edward Lewis +1-703-227-9854 >>ARIN Research Engineer >> >> >>-- >>to unsubscribe send a message to namedroppers-request@ops.ietf.org with >>the word 'unsubscribe' in a single line as the message text body. >>archive: >> -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 5 11:11:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09546 for ; Wed, 5 Mar 2003 11:11:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18qbMa-000JaJ-00 for namedroppers-data@psg.com; Wed, 05 Mar 2003 08:03:24 -0800 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 18qbMY-000Ja5-00 for namedroppers@ops.ietf.org; Wed, 05 Mar 2003 08:03:22 -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 LAA10247; Wed, 5 Mar 2003 11:03:21 -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 LAA05131; Wed, 5 Mar 2003 11:00:58 -0500 (EST) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h25FvS6g023012; Wed, 5 Mar 2003 10:57:29 -0500 (EST) Received: (from ghudson@localhost) by error-messages.mit.edu (8.9.3) id KAA25452; Wed, 5 Mar 2003 10:57:27 -0500 Subject: Re: Q1 followup - arguements against "MUST NOT" language From: Greg Hudson To: Alexis Yushin Cc: namedroppers@ops.ietf.org In-Reply-To: <200303051542.h25FgUWE079627@open.nlnetlabs.nl> References: <200303051542.h25FgUWE079627@open.nlnetlabs.nl> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 05 Mar 2003 10:57:27 -0500 Message-Id: <1046879847.10259.122.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Spam-Status: No, hits=2.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM, RCVD_IN_RELAYS_ORDB_ORG,REFERENCES,SPAM_PHRASE_02_03, X_OSIRU_OPEN_RELAY version=2.43 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2003-03-05 at 10:42, Alexis Yushin wrote: > I dont see why name compression in RDATA is necessary a bad thing, I do > see that making different rules for different RR RDATA complicates the > standards, implementation and definitely introduces more potentional > interoperability issues. Allowing name compression in a new RDATA type breaks old caches, because you can no longer treat the RDATA as an opaque value. You have to know its structure so that you can uncompress the name before you cache it and return it to a future client. We can't retroactively disallow compression in old RDATA types, or at least, it wouldn't help much; old DNS software sticks around for a long time, so software would still have to handle it essentially forever. So we're stuck with different rules for different RR types. (There was a proposal for inventing a new type of self-contained, "local compression" for use in new RR types, but that was nixed by the working group as too complicated for such a small gain. Bernstein has suggested that we would do better to use a simple generic compression algorithm on DNS packets, but short of a full protocol rev, the transition issues associated with that approach are probably too difficult. Plus, I haven't seen any measurements backing up the claim.) -- to unsubscribe send a message to namedroppers-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 5 11:18:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10049 for ; Wed, 5 Mar 2003 11:18:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18qbSM-000K1G-00 for namedroppers-data@psg.com; Wed, 05 Mar 2003 08:09:22 -0800 Received: from [2001:6e0:206:1:250:daff:fe3d:1d6] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 3.36 #1) id 18qbSJ-000K12-00 for namedroppers@ops.ietf.org; Wed, 05 Mar 2003 08:09:19 -0800 Received: from open.nlnetlabs.nl (localhost [IPv6:::1]) by open.nlnetlabs.nl (8.12.6/8.12.6) with ESMTP id h25G9Eec079737; Wed, 5 Mar 2003 17:09:14 +0100 (CET) (envelope-from alexis@open.nlnetlabs.nl) Received: (from alexis@localhost) by open.nlnetlabs.nl (8.12.6/8.12.6/Submit) id h25G9Ems079736; Wed, 5 Mar 2003 17:09:14 +0100 (CET) Message-Id: <200303051609.h25G9Ems079736@open.nlnetlabs.nl> Subject: Re: Q1 followup - arguements against "MUST NOT" language In-Reply-To: To: Edward Lewis Date: Wed, 5 Mar 2003 17:09:14 +0100 (CET) From: Alexis Yushin CC: Alexis Yushin , Scott Rose , namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, hits=-0.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, TO_BE_REMOVED_REPLY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Once Edward Lewis wrote: >The "bad thing" is that each RR becomes some form of a special case. >I.e., you have to know (upon receipt) where a domain name sits in the >RDATA. Having written resolver code and DNSSEC verification code, >it's a pain. Not only do you have to know where to find the possible >compression, you have to write to a new buffer that is expanded, >possibly in the middle. Yes, I understand this sort of a bad thing, but that's a bit too late to fix it if we dont want to introduce an entirely new protocol. Now you basically suggest to introduce *additional* special rules (and I could live with it if it would solve the historical issues in the protocol) to help particular implementation. I strongly believe we should stay uniform on handling domain names, either forbid domain name compression at all (since the connectivity improved over years and we're not saving anything with it) or leave it as is. I think that clear standard has priority over implementation simplicity. Alexis >If you compress in a RR than is unknown to a receiver, then the >receiver stands no chance at achieving any DNSSEC validation of the >data. 'Course, once again, validation oughta be end-to-end, so maybe >that's a non-issue. > >At 16:42 +0100 3/5/03, Alexis Yushin wrote: >>I think that we should try to keep the standards as uniform as possible. >>Making million exceptions to the rules is the ultimate Bad Thing (tm). >> >>I dont see why name compression in RDATA is necessary a bad thing, I do >>see that making different rules for different RR RDATA complicates the >>standards, implementation and definitely introduces more potentional >>interoperability issues. >> >>Alexis >> >> >>Once Edward Lewis wrote: >>>Also, what do you mean by "use" ;) >>> >>>I'm leaning towards "MUST NOT compress domain names in the RDATA >>>sections when assembling and transmitting a message." (Includes >>>dynamic update request messages when using this wording.) >>> >>>1) Bytes compressed away in a SIG message are miniscule compared to >>>the signature. >>> >>>2) A response won't have many NXT's anyway (unlike NS records which >>>may be numerous in a referral). >>> >>>3) Assuming EDNS0 is going to enlarge the minimum maximum message >>>size from 512, what's a few extra bytes. >>> >>> >>>At 13:40 -0500 2/12/03, Scott Rose wrote: >>>>The general consensus is that name compression in RDATA is A Bad Thing (tm), >>>>but there are some differences on the wording for the spec: >>>> >>>>Sub-Question: What are the arguments against using the terms (1)"MUST NOT >>>>use name compression on DNS names in the RDATA on sending over the wire" >>>>(paraphrasing here) over (2)"SHOULD NOT use name compression on DNS names in >>>>the RDATA..."? >>>> >>>>Notes: >>>> A. (1) is the strength of the wording used in the unknown-rrs draft. >>>>There would be consistency. >>>> >>>> >>>> >>>>Scott >>>> >>>> >>>> >>>> >>>>-- >>>>to unsubscribe send a message to namedroppers-request@ops.ietf.org with >>>>the word 'unsubscribe' in a single line as the message text body. >>>>archive: >>> >>>-- >>>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >>>Edward Lewis +1-703-227-9854 >>>ARIN Research Engineer >>> >>> >>>-- >>>to unsubscribe send a message to namedroppers-request@ops.ietf.org with >>>the word 'unsubscribe' in a single line as the message text body. >>>archive: >>> > >-- >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >Edward Lewis +1-703-227-9854 >ARIN Research Engineer > > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 5 11:19:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10090 for ; Wed, 5 Mar 2003 11:19:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18qbTB-000K4E-00 for namedroppers-data@psg.com; Wed, 05 Mar 2003 08:10:13 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 18qbT4-000K3r-00 for namedroppers@ops.ietf.org; Wed, 05 Mar 2003 08:10:06 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h25GA5JW081270 for ; Wed, 5 Mar 2003 11:10:05 -0500 (EST) Received: from [192.149.252.108] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA07771; Wed, 5 Mar 2003 11:10:05 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: Date: Wed, 5 Mar 2003 11:10:07 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: archives Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=0.5 required=5.0 tests=SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk http://ops.ietf.org/lists/namedroppers/namedroppers.2003/ ...seems to be missing an index.html-type file. This makes finding messages by content rather hard. Is there a possibility that the "Date Index" can show the date of the message? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 5 11:26:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10714 for ; Wed, 5 Mar 2003 11:26:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18qbYy-000KTv-00 for namedroppers-data@psg.com; Wed, 05 Mar 2003 08:16:12 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 18qbYw-000KTa-00 for namedroppers@ops.ietf.org; Wed, 05 Mar 2003 08:16:10 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h25GG5JW081412; Wed, 5 Mar 2003 11:16:05 -0500 (EST) Received: from [192.149.252.108] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA08872; Wed, 5 Mar 2003 11:16:04 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <200303051609.h25G9Ems079736@open.nlnetlabs.nl> References: <200303051609.h25G9Ems079736@open.nlnetlabs.nl> Date: Wed, 5 Mar 2003 11:15:53 -0500 To: Alexis Yushin From: Edward Lewis Subject: Re: Q1 followup - arguements against "MUST NOT" language Cc: Edward Lewis , Alexis Yushin , Scott Rose , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 17:09 +0100 3/5/03, Alexis Yushin wrote: >Yes, I understand this sort of a bad thing, but that's a bit too late >to fix it if we dont want to introduce an entirely new protocol. Now you >basically suggest to introduce *additional* special rules (and I could live >with it if it would solve the historical issues in the protocol) to help >particular implementation. I think I don't understand. I'm advocating a return to what 1035 said, not any additional rules. RFC 1035 says that just a few types are subject to compression. The DNSSEC specs overstepped their bounds in saying that the new RRs were also subject to compression. >I strongly believe we should stay uniform on handling domain names, >either forbid domain name compression at all (since the connectivity >improved over years and we're not saving anything with it) or leave it >as is. The problem is that "as it is" is 'broken and inconsistent.' ;) >I think that clear standard has priority over implementation simplicity. The problem is that the standards are not clear, they are self-conflicting. That's the issue, not really the implementation thing. 2535 should not break 1035 in any way, okay, not in this way. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 5 12:26:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14981 for ; Wed, 5 Mar 2003 12:26:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18qcOw-000O7w-00 for namedroppers-data@psg.com; Wed, 05 Mar 2003 09:09:54 -0800 Received: from gusto.araneus.fi ([204.152.186.164]) by psg.com with esmtp (Exim 3.36 #1) id 18qcOs-000O7k-00 for namedroppers@ops.ietf.org; Wed, 05 Mar 2003 09:09:50 -0800 Received: from guava.araneus.fi (adsl-63-197-0-204.dsl.snfc21.pacbell.net [63.197.0.204]) by gusto.araneus.fi (8.12.6/8.11.6) with ESMTP id h25H9VN0017615; Wed, 5 Mar 2003 09:09:31 -0800 (PST) Received: from guava.araneus.fi (localhost [127.0.0.1]) by guava.araneus.fi (8.12.8/8.11.6) with ESMTP id h25H9Uvv004079; Wed, 5 Mar 2003 09:09:30 -0800 (PST) Received: (from gson@localhost) by guava.araneus.fi (8.12.8/8.12.6/Submit) id h25H9Mtx004076; Wed, 5 Mar 2003 09:09:22 -0800 (PST) Date: Wed, 5 Mar 2003 09:09:22 -0800 (PST) Message-Id: <200303051709.h25H9Mtx004076@guava.araneus.fi> To: Edward Lewis Cc: Alexis Yushin , Scott Rose , namedroppers@ops.ietf.org Subject: Re: Q1 followup - arguements against "MUST NOT" language In-Reply-To: References: <200303051542.h25FgUWE079627@open.nlnetlabs.nl> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=0.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward Lewis writes: > If you compress in a RR than is unknown to a receiver, then the > receiver stands no chance at achieving any DNSSEC validation of the > data. 'Course, once again, validation oughta be end-to-end, so maybe > that's a non-issue. It is an issue even assuming end-to-end validation. If you compress in a RR than is unknown to a receiver, and that receiver in turn sends the compressed RR to a final receiver as part of a newly constructed DNS message, the compressed names are corrupted because the locations the compression pointers point to are now part of different DNS message and contain different data. This is not just a question of breaking DNSSEC validation, but of the interoperability of the basic DNS protocol. -- Andreas Gustafsson, gson@nominum.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 5 12:33:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15425 for ; Wed, 5 Mar 2003 12:33:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18qcbC-000Oxc-00 for namedroppers-data@psg.com; Wed, 05 Mar 2003 09:22:34 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18qcb9-000OxP-00; Wed, 05 Mar 2003 09:22:31 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18qcb9-0001yS-00; Wed, 05 Mar 2003 09:22:31 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 5 Mar 2003 09:22:29 -0800 To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: archives References: Message-Id: X-Spam-Status: No, hits=0.0 required=5.0 tests=REFERENCES,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > http://ops.ietf.org/lists/namedroppers/namedroppers.2003/ > ...seems to be missing an index.html-type file. whoops! should be working now. thanks for catching it. you neglected to cc the ietf@ietf.org list with your bug report :-) 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 5 16:08:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28762 for ; Wed, 5 Mar 2003 16:08:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18qfzw-000ElU-00 for namedroppers-data@psg.com; Wed, 05 Mar 2003 13:00:20 -0800 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with smtp (Exim 3.36 #1) id 18qfzr-000ElA-00 for namedroppers@ops.ietf.org; Wed, 05 Mar 2003 13:00:16 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.8/8.12.7) with ESMTP id h25L00ip033090; Thu, 6 Mar 2003 08:00:01 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200303052100.h25L00ip033090@drugs.dv.isc.org> To: "Scott Rose" Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: Q1 followup - arguements against "MUST NOT" language In-reply-to: Your message of "Wed, 05 Mar 2003 10:43:48 CDT." <00d701c2e32e$03c10f60$b9370681@barnacle> Date: Thu, 06 Mar 2003 08:00:00 +1100 X-Spam-Status: No, hits=0.9 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, TO_BE_REMOVED_REPLY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > That seems to be the prevailing winds - MUST NOT compress DNS names in the > RDATA (paraphrase). Basically, change the DNSSEC specs to keep in line with > the unknown-rrs draft and namedroppers discussion. The MUST NOT is to prevent the case of the letters in the label being changed and thereby causing signature comparision to fail. Potentially it could be compressed if you added additional restrictions to the current compression algorithim to also check the case of labels when looking for compression pointer targets. The actual requirement is that the case of the labels be preserved. Not compressing domain names in the rdata is a way to achieve that. > Scott > ----- Original Message ----- > From: "Edward Lewis" > To: "Scott Rose" > Cc: > Sent: Wednesday, March 05, 2003 9:43 AM > Subject: Re: Q1 followup - arguements against "MUST NOT" language > > > > Also, what do you mean by "use" ;) > > > > I'm leaning towards "MUST NOT compress domain names in the RDATA > > sections when assembling and transmitting a message." (Includes > > dynamic update request messages when using this wording.) > > > > 1) Bytes compressed away in a SIG message are miniscule compared to > > the signature. > > > > 2) A response won't have many NXT's anyway (unlike NS records which > > may be numerous in a referral). > > > > 3) Assuming EDNS0 is going to enlarge the minimum maximum message > > size from 512, what's a few extra bytes. > > > > > > At 13:40 -0500 2/12/03, Scott Rose wrote: > > >The general consensus is that name compression in RDATA is A Bad Thing > (tm), > > >but there are some differences on the wording for the spec: > > > > > >Sub-Question: What are the arguments against using the terms (1)"MUST > NOT > > >use name compression on DNS names in the RDATA on sending over the wire" > > >(paraphrasing here) over (2)"SHOULD NOT use name compression on DNS names > in > > >the RDATA..."? > > > > > >Notes: > > > A. (1) is the strength of the wording used in the unknown-rrs > draft. > > >There would be consistency. > > > > > > > > > > > >Scott > > > > > > > > > > > > > > >-- > > >to unsubscribe send a message to namedroppers-request@ops.ietf.org with > > >the word 'unsubscribe' in a single line as the message text body. > > >archive: > > > > -- > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > Edward Lewis +1-703-227-9854 > > ARIN Research Engineer > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 5 16:11:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28857 for ; Wed, 5 Mar 2003 16:11:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18qg5R-000FJa-00 for namedroppers-data@psg.com; Wed, 05 Mar 2003 13:06:01 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 18qg5N-000FJB-00 for namedroppers@ops.ietf.org; Wed, 05 Mar 2003 13:05:57 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h25L5mJW094019; Wed, 5 Mar 2003 16:05:48 -0500 (EST) Received: from [192.149.252.108] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id QAA08328; Wed, 5 Mar 2003 16:05:47 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 (Unverified) Message-Id: In-Reply-To: <200303051709.h25H9Mtx004076@guava.araneus.fi> References: <200303051542.h25FgUWE079627@open.nlnetlabs.nl> <200303051709.h25H9Mtx004076@guava.araneus.fi> Date: Wed, 5 Mar 2003 16:00:58 -0500 To: gson@nominum.com (Andreas Gustafsson) From: Edward Lewis Subject: Re: Q1 followup - arguements against "MUST NOT" language Cc: Edward Lewis , Alexis Yushin , Scott Rose , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-1.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Ah. At 9:09 -0800 3/5/03, Andreas Gustafsson wrote: >Edward Lewis writes: >> If you compress in a RR than is unknown to a receiver, then the >> receiver stands no chance at achieving any DNSSEC validation of the >> data. 'Course, once again, validation oughta be end-to-end, so maybe >> that's a non-issue. > >It is an issue even assuming end-to-end validation. If you compress >in a RR than is unknown to a receiver, and that receiver in turn sends >the compressed RR to a final receiver as part of a newly constructed >DNS message, the compressed names are corrupted because the locations >the compression pointers point to are now part of different DNS >message and contain different data. > >This is not just a question of breaking DNSSEC validation, but of >the interoperability of the basic DNS protocol. >-- >Andreas Gustafsson, gson@nominum.com -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 5 16:52:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01530 for ; Wed, 5 Mar 2003 16:52:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18qgja-000Ivs-00 for namedroppers-data@psg.com; Wed, 05 Mar 2003 13:47:30 -0800 Received: from gusto.araneus.fi ([204.152.186.164]) by psg.com with esmtp (Exim 3.36 #1) id 18qgjX-000IvW-00 for namedroppers@ops.ietf.org; Wed, 05 Mar 2003 13:47:27 -0800 Received: from guava.araneus.fi (adsl-63-197-0-204.dsl.snfc21.pacbell.net [63.197.0.204]) by gusto.araneus.fi (8.12.6/8.11.6) with ESMTP id h25LlHN0018347; Wed, 5 Mar 2003 13:47:17 -0800 (PST) Received: from guava.araneus.fi (localhost [127.0.0.1]) by guava.araneus.fi (8.12.8/8.11.6) with ESMTP id h25LlFvv004358; Wed, 5 Mar 2003 13:47:15 -0800 (PST) Received: (from gson@localhost) by guava.araneus.fi (8.12.8/8.12.6/Submit) id h25LlEfW004355; Wed, 5 Mar 2003 13:47:14 -0800 (PST) Date: Wed, 5 Mar 2003 13:47:14 -0800 (PST) Message-Id: <200303052147.h25LlEfW004355@guava.araneus.fi> To: Mark.Andrews@isc.org Cc: "Scott Rose" , namedroppers@ops.ietf.org Subject: Re: Q1 followup - arguements against "MUST NOT" language In-Reply-To: <200303052100.h25L00ip033090@drugs.dv.isc.org> References: <00d701c2e32e$03c10f60$b9370681@barnacle> <200303052100.h25L00ip033090@drugs.dv.isc.org> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=0.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mark.Andrews@isc.org writes: > The MUST NOT is to prevent the case of the letters in the label > being changed and thereby causing signature comparision to fail. No, the canonicalization specified in RFC2535 section 8.1 (and revised in unknown-rrs section 7) will keep that from happening. The real problem is that the record would be corrupted by servers that attempt to treat it transparently, as I just explained in my message to Edward Lewis. -- Andreas Gustafsson, gson@nominum.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 5 17:57:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04229 for ; Wed, 5 Mar 2003 17:57:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18qhbf-000O93-00 for namedroppers-data@psg.com; Wed, 05 Mar 2003 14:43:24 -0800 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with smtp (Exim 3.36 #1) id 18qhbb-000O8r-00 for namedroppers@ops.ietf.org; Wed, 05 Mar 2003 14:43:19 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.8/8.12.7) with ESMTP id h25Mh5ip033616; Thu, 6 Mar 2003 09:43:06 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200303052243.h25Mh5ip033616@drugs.dv.isc.org> To: gson@nominum.com (Andreas Gustafsson) Cc: "Scott Rose" , namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: Q1 followup - arguements against "MUST NOT" language In-reply-to: Your message of "Wed, 05 Mar 2003 13:47:14 -0800." <200303052147.h25LlEfW004355@guava.araneus.fi> Date: Thu, 06 Mar 2003 09:43:05 +1100 X-Spam-Status: No, hits=0.5 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Mark.Andrews@isc.org writes: > > The MUST NOT is to prevent the case of the letters in the label > > being changed and thereby causing signature comparision to fail. > > No, the canonicalization specified in RFC2535 section 8.1 (and revised > in unknown-rrs section 7) will keep that from happening. > > The real problem is that the record would be corrupted by servers that > attempt to treat it transparently, as I just explained in my message > to Edward Lewis. > -- > Andreas Gustafsson, gson@nominum.com There are multiple issues. With old clients that don't under the RR format you have to preserve case and not compress. This allows the records to be treated as a opaque blob for cache and verification. With new clients that understand the RR format you still have to preserve the case but you could, if wanted to provide signaling to the server, use a compression pointer if the suffix pointes to had the *same* case as the original suffix. The records in this case are not treated as opaque blobs and verification works. The requirement is that the case be preserved. How you achieve that is a secondary matter. Outlawing compression is one way. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 6 06:41:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04918 for ; Thu, 6 Mar 2003 06:41:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18qtWb-000D9x-00 for namedroppers-data@psg.com; Thu, 06 Mar 2003 03:26:57 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 18qtWY-000D9X-00 for namedroppers@ops.ietf.org; Thu, 06 Mar 2003 03:26:54 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02296; Thu, 6 Mar 2003 06:24:46 -0500 (EST) Message-Id: <200303061124.GAA02296@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-tkey-renewal-mode-03.txt Date: Thu, 06 Mar 2003 06:24:46 -0500 X-Spam-Status: No, hits=4.6 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.43 X-Spam-Level: **** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : TKEY Secret Key Renewal Mode Author(s) : Y. Kamite, M. Nakayama Filename : draft-ietf-dnsext-tkey-renewal-mode-03.txt Pages : 22 Date : 2003-3-5 This document defines a new mode in TKEY [RFC2930] and proposes an atomic method for changing secret keys used for TSIG [RFC2845] periodically. Originally, TKEY provides methods of setting up shared secrets other than manual exchange, but it cannot control timing of key renewal very well though it can add or delete shared keys separately. This proposal is a systematical key renewal procedure intended for preventing signing DNS messages with old and non-safe keys permanently. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tkey-renewal-mode-03.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-tkey-renewal-mode-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-tkey-renewal-mode-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-5140232.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-tkey-renewal-mode-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-tkey-renewal-mode-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-5140232.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 6 11:02:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22633 for ; Thu, 6 Mar 2003 11:02:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18qxY5-000Nde-00 for namedroppers-data@psg.com; Thu, 06 Mar 2003 07:44:45 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 18qxY1-000NdR-00 for namedroppers@ops.ietf.org; Thu, 06 Mar 2003 07:44: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 KAA21160; Thu, 6 Mar 2003 10:42:36 -0500 (EST) Message-Id: <200303061542.KAA21160@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-protocol-01.txt Date: Thu, 06 Mar 2003 10:42:36 -0500 X-Spam-Status: No, hits=4.6 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.43 X-Spam-Level: **** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Protocol Modifications for the DNS Security Extensions Author(s) : R. Arends et. al. Filename : draft-ietf-dnsext-dnssec-protocol-01.txt Pages : 41 Date : 2003-3-5 This document is part of a family of documents which describes the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications which add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-protocol-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-protocol-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-protocol-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-5172147.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-protocol-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-protocol-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-5172147.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 7 21:09:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01429 for ; Fri, 7 Mar 2003 21:09:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18rTZs-0001cm-00 for namedroppers-data@psg.com; Fri, 07 Mar 2003 17:56:44 -0800 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 18rTZq-0001cZ-00 for namedroppers@ops.ietf.org; Fri, 07 Mar 2003 17:56:42 -0800 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h280g8u19287 for ; Fri, 7 Mar 2003 16:42:08 -0800 Date: Fri, 7 Mar 2003 16:42:08 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: LLMNR Issues List Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests=SPAM_PHRASE_00_01,SUBJECT_IS_LIST,USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In order to better track LLMNR issues, and ready the LLMNR draft for DNSEXT WG last call, we have created an LLMNR issues list: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html The LLMNR editors would like to encourage participants in the DNSEXT WG who have not yet read the LLMNR draft to do so ASAP, and email your issues in the format described on the Issues list, to namedroppers@ops.ietf.org, with a CC: to lmnr-editors@internaut.com. The latest LLMNR draft is available at: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-13.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 Sat Mar 8 00:52:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08881 for ; Sat, 8 Mar 2003 00:52:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18rX6z-000BlM-00 for namedroppers-data@psg.com; Fri, 07 Mar 2003 21:43:09 -0800 Received: from [2001:4f8:3:bb:2e0:81ff:fe23:7b5a] (helo=as.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 18rX6r-000BkV-00 for namedroppers@ops.ietf.org; Fri, 07 Mar 2003 21:43:01 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 30D5C379E40 for ; Sat, 8 Mar 2003 05:42:48 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: let's talk about RFC2136bis X-Mailer: MH-E 7.2; nmh 1.0.4; GNU Emacs 21.2.1 Date: Sat, 08 Mar 2003 05:42:48 +0000 Message-Id: <20030308054248.30D5C379E40@as.vix.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk the process used by dnssec-editors@ has appeared to be somewhat successful, so let's see if we can get some agreement on various upgrade issues between RFC2136 and its inevitable "bis" version. olafur, if we could have a few minutes to discuss this in san francisco, it might help to get a new document out immediately thereafter. -------- #1 -- scope of changes i'm hoping that we can do minimal changes, basically just editorial (for clarity) or because of some kind of error or inconsistency. there's no reason to revisit it at a deeper level nor to reconsider the basic approach. (however, it's stuck at proposed standard until we get some things fixed.) -------- #2 -- rr comparison 1.1.1. Two RRs are considered equal if their NAME, CLASS, TYPE, RDLENGTH and RDATA fields are equal. Note that the time-to-live (TTL) field is explicitly excluded from the comparison. does this need to mention the whole uppercase/lowercase issue? noting that the RRs are compared in their virtual state not their wire state, there's no compression issue as with dnssec. but do we need a sentence to the effect that "if the rdata contains domain names, then domain name comparison rules are in effect, for example the MXs of (10 internet.net) and (10 INTERNET.NET) are to be considered equivilent" ? -------- #3 -- rr type restrictions 1.1.5. The following RR types cannot be appended to an RRset. If the following comparison rules are met, then an attempt to add the new RR will result in the replacement of the previous RR: SOA compare only NAME, CLASS and TYPE -- it is not possible to have more than one SOA per zone, even if any of the data fields differ. WKS compare only NAME, CLASS, TYPE, ADDRESS, and PROTOCOL -- only one WKS RR is possible for this tuple, even if the services masks differ. CNAME compare only NAME, CLASS, and TYPE -- it is not possible to have more than one CNAME RR, even if their data fields differ. do we need to disallow updates of the dnssec types, or cause logical OR'ing if an NXT is appended, or anything like that? -------- #4 -- clarification of domain owner naming 1.2 - Glue RRs For the purpose of determining whether a domain name used in the UPDATE protocol is contained within a specified zone, a domain name is ``in'' a zone if it is owned by that zone's domain name. See section 7.18 for details. a number of people have said that "owned by" is hard to read. therefore perhaps we should expand it to say "at or below the zone apex". the reason this is here is that it's possible to add data to a zone which is below a zone "bottom cut" (see section 7.18, i guess) even though that data will not be visible to opcode QUERY. i think "owned by" is the right term but i am willing to expand it if others think differently. -------- #5 -- edns size issues 2.1 - Transport Issues An update transaction may be carried in a UDP datagram, if the request fits, or in a TCP connection (at the discretion of the requestor). When TCP is used, the message is in the format described in [RFC1035 4.2.2]. it rather seems to me that in an edns world, there's no easy way for an initiator to learn the buffer size of a responder other than by sending a QUERY first. (this wasn't an oversight in edns -- we knew what we were leaving out but believed, correctly i still feel, that time to market was more important than an expansive feature set.) should 2136bis mention that an edns QUERY could be sent first, to discover the responder's buffer size, and that a subsequent edns UPDATE can take advantage of that buffer size? -------- #6 -- edns request-id field 2.2 - Message Header ... ID A 16-bit identifier assigned by the entity that generates any kind of request. This identifier is copied in the corresponding reply and can be used by the requestor to match replies to outstanding requests, or by the server to detect duplicated requests from some requestor. allow me to curse myself for not suggesting an edns OPTion for extended request-id. i daresay that a 128-bit cryptorandom cookie would be pretty hard to guess. this point has nothing to do with 2136bis, i just hope somebody sees this and writes up an edns OPTion for extended request-id. -------- #7 -- order of permission checking 3.3 - Check Requestor's Permissions ... 3.3.2. While the exact processing is implementation defined, if these verification activities are to be performed, this is the point in the server's processing where such performance should take place, since if a REFUSED condition is encountered after an update has been partially applied, it will be necessary to undo the partial update and restore the zone to its original state before answering the requestor. this is in the wrong place. the question is, should it come before 3.2 (before checking prerequisites) or before 3.1 (before checking the zone section)? i think i'm ready to argue for "before 3.1" since this is an instance of local policy and it can examine any other part of the request that it wants to in order to make its decision. it should also be run as early as possible in order to catch a DDoS before having done any work on behalf of the attacker. -------- #8 -- clarifying server selection 4.3. If the requestor has reasonable cause to believe that all of a zone's servers will be equally reachable, then it should arrange to try the primary master server (as given by the SOA MNAME field if matched by some NS NSDNAME) first to avoid unnecessary forwarding inside the slave servers. (Note that the primary master will in some cases not be reachable by all requestors, due to firewalls or network partitioning.) some microsoft-generated updates were/are sent to the SOA MNAME regardless of whether it is also listed in an NS NSDNAME. (see www.as112.net for fun.) additionally, there's someone out there who searches "up the tree" looking for a receptive zone server if they get back a timeout or error from a more appropriate (closer enclosing) zone's server. do we need to clarify the text to say that once a zone apex has been found, all updates must be done within that zone, and that searching upward looking for "more receptive" zone servers for parent or grandparent zones will probably lead to hostility ("and a sense of futility" --t.l.)? -------- #9 -- forwarding, threat or menace? 3.1.1. ... If the server is a zone slave, the request will be forwarded toward the primary master. ... 5.2. Multiple UPDATE requests or responses in transit might be delivered in any order, due ... to multipath forwarding graphs wherein several slave servers all forward to the primary master. ... 6 - Forwarding When a zone slave forwards an UPDATE message upward toward the zone's primary master server, it must allocate a new ID and prepare to enter the role of ``forwarding server,'' which is a requestor with respect to the forward server. update forwarding has been singled out for much ridicule amongst those who have implemented 2136. there were valid operational reasons for it... 6.1. The set of forward servers will be same as the set of servers this zone slave would use as the source of AXFR or IXFR data. So, while the original requestor might have used the zone's NS RRset to locate its update server, a forwarder always forwards toward its designated zone master servers. ...but tcp forwarding, in particular, creates a synchronous "hold state" condition for the forwarders, and is thus ripe for all manner of DDoS... 6.2. If the original requestor used TCP, then the TCP connection from the requestor is still open and the forwarder must use TCP to forward the message. If the original requestor used UDP, the forwarder may use either UDP or TCP to forward the message, at the whim of the implementor. i won't go into it further or make any specific proposals since i'm hoping that nominum and ultradns will both comment extensively on updates. it's possible that the right answer is "remove forwarding from the design" and just demand that updates be receivable by the server named in the SOA RR. -------- #10 -- security improvements 8 - Security Considerations 8.1. In the absence of [SECUPD] or equivilent technology, the protocol described by this document makes it possible for anyone who can reach an authoritative name server to alter the contents of any zones on that server. This is a serious increase in vulnerability from the current technology. Therefore it is very strongly recommended that the protocols described in this document not be used without [SECUPD] or other equivalently strong security measures, e.g. IPsec. i think that we should require TSIG or SIG(0), and disallow ip source address verification unless TCP is used. i also think that we should recommend that if TCP is used, an implicit ip source address access control rule should allow "that host" (the initiator) to update its own PTR RR (either in in-addr.arpa or ip6.arpa.) -------- #11 -- misc issues from an unnamed party > explicity specify the atomicity rule (whole update is atomic) how much more explicit can we be than: 3.7 - Atomicity During the processing of an UPDATE transaction, the server must ensure atomicity with respect to other (concurrent) UPDATE or QUERY transactions. No two transactions can be processed concurrently if either depends on the final results of the other; in particular, a QUERY should not be able to retrieve RRsets which have been partially modified by a concurrent UPDATE, and an UPDATE should not be able to start from prerequisites that might not still hold at the completion of some other concurrent UPDATE. Finally, if two UPDATE transactions would modify the same names, RRs or RRsets, then such UPDATE transactions must be serialized. > clarify if precondtion can appear anywhere in update message or not no, it pretty much has to be in the third section, as defined in section 2: The overall format of an UPDATE message is, following [ibid]: +---------------------+ | Header | +---------------------+ | Zone | specifies the zone to be updated +---------------------+ | Prerequisite | RRs or RRsets which must (not) preexist +---------------------+ | Update | RRs or RRsets to be added or deleted +---------------------+ | Additional Data | additional data +---------------------+ > clarify rules on singleton, delete MUST occur before add this one bears heavily upon the next: > clarify the NS rules, zone may be temporarily invalid but must > be valid at end of update eg > DEL NS * > ADD ns 1 > ADD ns 2 > is a valid sequence. the intent when 2136 was written was that the zone state had to be correct at the end of the atomicity period, but could be wildly wrong (SOA missing, last NS RR deleted, etc) inside the atomicity period. the order of update operations was as specified in the update message and created virtual (but unchecked) state: if you put the delete first, it deletes first, if you put it last, it deletes last. before we think about where in the document this should be described, let's hear from some implementors and users as to what they actually do and what they actually expect and/or require. -------- #12 -- issues from another unnamed party > I stumbled across this doing some background work. Apparently 2136 is > sitting at PS. I had a comment about it in Sept of last year, and a little > while ago I came across a wording change I'd recommend: > > # RCODE Response code - this four bit field is undefined in requests > ... > # Mneumonic Value Description > > Mnemonic is misspelled so noted. > ... > # NXDOMAIN 3 Some name that ought to exist, > # does not exist. > > I'd change this to "The QNAME sought does not exist" that doesn't work in the context of an UPDATE operation, where there is no QNAME, and in fact any "name must exist" or "rrset must exist" or even "rr must exist" in the prerequisites section can cause an rcode of NXDOMAIN to be sent back to an UPDATE requestor. it's apparently going to be necessary for the rcodes to be unique to each opcode. at least the definition of each rcode has to vary per opcode, and maybe we ought to consider reusing the rcode numbers themselves per opcode. > I'm wondering if the definition of mnemonics are meant to add to the > standard specifications. In RFC 1034, the error is an "authoritative > name error," and the name NXDOMAIN is from one implementation > (BIND). [This was brought to my attention by Paul, so this is not > news.] The issue is whether a DS version of dynamic update should be > written more cleanly wrt to bias towards an implementation. see above. -------- th-th-that's all folks. what else has anybody got against 2136 that they'd like to see fixed in 2136bis? -- to unsubscribe send a message to namedroppers-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 8 06:40:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20874 for ; Sat, 8 Mar 2003 06:40:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18rcRA-000Nbt-00 for namedroppers-data@psg.com; Sat, 08 Mar 2003 03:24:20 -0800 Received: from [3ffe:b80:2:a90::2] (helo=devil.pp.htv.fi) by psg.com with esmtp (Exim 3.36 #1) id 18rcR7-000Nbg-00 for namedroppers@ops.ietf.org; Sat, 08 Mar 2003 03:24:18 -0800 Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h28BOxaj010657; Sat, 8 Mar 2003 13:24:59 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h28BOtZl010648; Sat, 8 Mar 2003 13:24:55 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: [LLMNR] Use of IPv6 link-local multicast addresses [Potential new issue] From: Mika Liljeberg To: namedroppers@ops.ietf.org Cc: lmnr-editors@internaut.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1047122694.2472.77.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 08 Mar 2003 13:24:55 +0200 X-Spam-Status: No, hits=-1.1 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, TO_BE_REMOVED_REPLY,X_AUTH_WARNING version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Reading the draft I get the understanding that, in order to respond to reverse queries for IPv6 addresses, the host has to configure the following sixteen multicast addresses on each of its interfaces: FF02:0:0:0:0:2:MD5("0") .. FF02:0:0:0:0:2:MD5("F") In addition, a host may have multiple aliases (especially if it is multihomed), so the number of multicast groups that need to be configured per inteface could be close to twenty. This is clearly a waste of multicast filters. It is unlikely (correct me if I'm wrong) that a NIC will support this many multicast filters in hardware, which means that the NIC will have to be configured to receive all multicasts and the filtering must be done in software. That pretty much defeats the purpose of having the hash based solicited name multicast addresses in the first place. It would seem much better to just have a single well-known IPv6 link-local multicast address for reverse lookups. The alternative would seem to be to not support PTR queries at all for IPv6 addresses. I leave it to the discretion of the editors to decide whether this should be formulated as an issue. MikaL On Sat, 2003-03-08 at 02:42, Bernard Aboba wrote: > In order to better track LLMNR issues, and ready the LLMNR draft for > DNSEXT WG last call, we have created an LLMNR issues list: > > http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html > > The LLMNR editors would like to encourage participants in the DNSEXT WG > who have not yet read the LLMNR draft to do so ASAP, and email your issues > in the format described on the Issues list, to namedroppers@ops.ietf.org, > with a CC: to lmnr-editors@internaut.com. > > The latest LLMNR draft is available at: > > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-13.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: -- to unsubscribe send a message to namedroppers-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 8 15:02:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26102 for ; Sat, 8 Mar 2003 15:02:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18rkNX-000FAG-00 for namedroppers-data@psg.com; Sat, 08 Mar 2003 11:53:07 -0800 Received: from portal.hamachi.org ([140.239.227.17]) by psg.com with esmtp (Exim 3.36 #1) id 18rkNV-000FA4-00 for namedroppers@ops.ietf.org; Sat, 08 Mar 2003 11:53:05 -0800 Received: from syn.hamachi.org (localhost [127.0.0.1]) by portal.hamachi.org (Postfix) with ESMTP id 44BCA17939; Sat, 8 Mar 2003 14:53:04 -0500 (EST) Received: from syn.hamachi.org (sommerfeld@localhost) by syn.hamachi.org (8.12.7+Sun/8.8.8) with ESMTP id h28Jqu2P010379; Sat, 8 Mar 2003 14:52:56 -0500 (EST) Message-Id: <200303081952.h28Jqu2P010379@syn.hamachi.org> From: Bill Sommerfeld To: Mika Liljeberg Cc: namedroppers@ops.ietf.org, lmnr-editors@internaut.com Subject: Re: [LLMNR] Use of IPv6 link-local multicast addresses [Potential new issue] In-Reply-To: Your message of "08 Mar 2003 13:24:55 +0200." <1047122694.2472.77.camel@devil> Reply-To: sommerfeld@orchard.arlington.ma.us Date: Sat, 08 Mar 2003 14:52:56 -0500 X-Spam-Status: No, hits=0.1 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_3,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > It is unlikely (correct me if I'm wrong) that a NIC will support this > many multicast filters in hardware. I just took a look at drivers for a few commonly used fast ethernet chipsets, and found the following limits: - 80 literal multicast addresses - 64-entry hash. - 128-entry hash. - 256-entry hash. - 512-entry hash. The "N-entry hash" variety maintain a N-bit vector, and run the recieved multicast address through a hash function with N possible outputs; if the corresponding bit in the vector is set, the packet is received, so you get more graceful degradation as the number of groups increases at the cost of slightly more false positives received. One 802.11 card I looked at has a lower limits (16 literal addresses). Another 802.11 card seems to have no multicast filtering at all! (though that may be an inadequate driver rather than a deficiency in the hardware/firmware). - 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 Sat Mar 8 16:48:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16613 for ; Sat, 8 Mar 2003 16:48:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18rlzz-000K3A-00 for namedroppers-data@psg.com; Sat, 08 Mar 2003 13:36:55 -0800 Received: from [3ffe:b80:2:a90::2] (helo=devil.pp.htv.fi) by psg.com with esmtp (Exim 3.36 #1) id 18rlzs-000K2q-00 for namedroppers@ops.ietf.org; Sat, 08 Mar 2003 13:36:52 -0800 Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) with ESMTP id h28LbSwY023380; Sat, 8 Mar 2003 23:37:29 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) id h28LbR19023373; Sat, 8 Mar 2003 23:37:27 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: [LLMNR] Use of IPv6 link-local multicast addresses [Potential new issue] From: Mika Liljeberg To: sommerfeld@orchard.arlington.ma.us Cc: namedroppers@ops.ietf.org, lmnr-editors@internaut.com In-Reply-To: <200303081952.h28Jqu2P010379@syn.hamachi.org> References: <200303081952.h28Jqu2P010379@syn.hamachi.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1047159446.2473.171.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 08 Mar 2003 23:37:27 +0200 X-Spam-Status: No, hits=-1.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, X_AUTH_WARNING version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sat, 2003-03-08 at 21:52, Bill Sommerfeld wrote: > > It is unlikely (correct me if I'm wrong) that a NIC will support this > > many multicast filters in hardware. > > I just took a look at drivers for a few commonly used fast ethernet > chipsets, and found the following limits: > > - 80 literal multicast addresses > - 64-entry hash. > - 128-entry hash. > - 256-entry hash. > - 512-entry hash. > > The "N-entry hash" variety maintain a N-bit vector, and run the > recieved multicast address through a hash function with N possible > outputs; if the corresponding bit in the vector is set, the packet is > received, so you get more graceful degradation as the number of groups > increases at the cost of slightly more false positives received. That's a pretty neat approach. The longer bit vectors sound good enough, although I still can't say that I like the idea of having to listen to 16 different multicast groups just for doing PTR queries. [It would be possible to optimize this, of course, but that would force the LLMNR responder to actively monitor all changes in interface configuration.] > One 802.11 card I looked at has a lower limits (16 literal addresses). > Another 802.11 card seems to have no multicast filtering at all! > (though that may be an inadequate driver rather than a deficiency in > the hardware/firmware). Needless to say, 802.11 and other wireless interfaces would be a major use case for LLMNR. MikaL -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Mar 9 17:24:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17819 for ; Sun, 9 Mar 2003 17:24:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18s8w4-000CvI-00 for namedroppers-data@psg.com; Sun, 09 Mar 2003 14:06:24 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 18s8vy-000Cux-00 for namedroppers@ops.ietf.org; Sun, 09 Mar 2003 14:06:18 -0800 From: Masataka Ohta Message-Id: <200303092152.GAA02617@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id GAA02617; Mon, 10 Mar 2003 06:52:35 +0900 Subject: Re: [LLMNR] Use of IPv6 link-local multicast addresses [Potential new issue] In-Reply-To: <1047122694.2472.77.camel@devil> from Mika Liljeberg at "Mar 8, 2003 01:24:55 pm" To: Mika Liljeberg Date: Mon, 10 Mar 2003 06:52:35 +0859 () CC: namedroppers@ops.ietf.org, lmnr-editors@internaut.com X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-0.7 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mika; > It would seem much better to just have a single well-known IPv6 > link-local multicast address for reverse lookups. The alternative would > seem to be to not support PTR queries at all for IPv6 addresses. It is enough to have a few (link local or global) anycast addresses for any DNS lookups. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 10 10:18:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28791 for ; Mon, 10 Mar 2003 10:18:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sOpu-000Htk-00 for namedroppers-data@psg.com; Mon, 10 Mar 2003 07:05:06 -0800 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #1) id 18sOpn-000Hsm-00; Mon, 10 Mar 2003 07:04:59 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA27353; Mon, 10 Mar 2003 08:04:56 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2AF4pP00204; Mon, 10 Mar 2003 16:04:51 +0100 (MET) Date: Mon, 10 Mar 2003 16:00:57 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: draft-ietf-dnsext-unknown-rrs-04.txt To: Andreas Gustafsson Cc: Erik Nordmark , Andreas Gustafsson , ogud@ogud.com, randy@psg.com, namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" <200302260137.h1Q1b0i00665@guava.araneus.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > 7. DNSSEC Canonical Form and Ordering > > DNSSEC defines a canonical form and ordering for RRs [RFC2535, section > 8.1]. In that canonical form, domain names embedded in the RDATA are > converted to lower case. > > The downcasing is necessary to ensure the correctness of DNSSEC > signatures when case distinctions in domain names are lost due to > compression, but since it requires knowledge of the presence and > position of embedded domain names, it cannot be applied to unknown > types. > > To ensure continued consistency of the canonical form of RR types > where compression is allowed, and for continued interoperability > with existing implementations that already implement the RFC2535 > canonical form and apply it to their known RR types, the canonical > form remains unchanged for all RR types whose whose initial > publication as an RFC was prior to the initial publication of this > specification as an RFC (RFC TBD). > > As a courtesy to implementors, it is hereby noted that the complete > set of such previously published RR types that contain embedded > domain names, and whose DNSSEC canonical form therefore involves > downcasing according to the DNS rules for character comparisons, > consists of the RR types NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, > HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, > SRV, DNAME, and A6. > > This document specifies that for all other RR types (whether > treated as unknown types or treated as known types according to an > RR type definition RFC more recent than than RFC TBD), the > canonical form is such that no downcasing of embedded domain names > takes place, and otherwise identical to the canonical form > specified in RFC2535 section 8.1. > > Note that the owner name is always set to lower case according to the > DNS rules for character comparisons, regardless of the RR type. > > The DNSSEC canonical RR ordering is as specified in RFC2535 section > 8.3, where the octet sequence is the canonical form as revised by this > specification. > > > Would this text be acceptable? works for me. Thanks, Erik -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 10 10:41:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29758 for ; Mon, 10 Mar 2003 10:41:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sPGD-000J6z-00 for namedroppers-data@psg.com; Mon, 10 Mar 2003 07:32:17 -0800 Received: from [2001:418:1::39] (helo=rip.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18sPFu-000J44-00 for namedroppers@ops.ietf.org; Mon, 10 Mar 2003 07:31:58 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com) by rip.psg.com with esmtp (Exim 4.12) id 18sPFu-0005RE-00 for namedroppers@ops.ietf.org; Mon, 10 Mar 2003 07:31:58 -0800 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Mon, 10 Mar 2003 14:10:45 +0100 (MET) From: Paul Wouters To: dnssec@sidn.nl, cc: dnssec@verisignlabs.com, , Subject: DNSSEC (and secure .nl) mini HOWTO X-Spam-Status: No, hits=0.8 required=5.0 tests=RESENT_TO,SPAM_PHRASE_05_08,USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Hi people, For c't magazine (www.ct.nl) I have written an article on DNSSEC and the Dutch SECREG (secreg.nlnetlabs.nl) experiment. An English translation has been put online at: http://www.xtdnet.nl/paul/dnssec/ The article briefly explains dnssec, how to create secure domains, and how to submit them to the Dutch SECREG experiment. The article is aimed at the enduser, not the IETF experts, and was meant to try and push some extra momentum in the .nl dnssec experiment. The original Dutch article will appear on March 14 in printed form (issue 04/2003). Another reason for me to push dnssec is FreeS/WAN, the Linux IPsec implementation, that features "Opportunistic Encryption". OE is a method for securing all IP traffic using IPsec without prior configuration. Ideally, it will rely on dnssec for the neccesary key material. For more information, see: http://www.freeswan.org/freeswan_snaps/CURRENT-SNAP/doc/quickstart.html If you do not own any .nl domain, but wish to play with dnssec in the secure .nl tree, you can contact me for either a .nl (secure) subdomain delegation, or I can assist you in registering your own .nl. (With a subdomain delegation you obviously cannot experiment with SECREG directly). Regards, Paul Wouters Xtended Internet -- Broerdijk 27 Postbus 170 Tel: 31-24-360 39 19 6523 GM Nijmegen 6500 AD Nijmegen Fax: 31-24-360 19 99 The Netherlands The Netherlands info@xtdnet.nl -- to unsubscribe send a message to namedroppers-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 10 13:03:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05918 for ; Mon, 10 Mar 2003 13:03:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sRTg-000Otg-00 for namedroppers-data@psg.com; Mon, 10 Mar 2003 09:54:20 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 18sRTd-000OtT-00 for namedroppers@ops.ietf.org; Mon, 10 Mar 2003 09:54:17 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h2AHsGJW001419; Mon, 10 Mar 2003 12:54:16 -0500 (EST) Received: from [204.152.189.42] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id MAA19656; Mon, 10 Mar 2003 12:54:15 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 (Unverified) Message-Id: In-Reply-To: <20030308054248.30D5C379E40@as.vix.com> References: <20030308054248.30D5C379E40@as.vix.com> Date: Mon, 10 Mar 2003 09:21:44 -0800 To: Paul Vixie From: Edward Lewis Subject: Re: let's talk about RFC2136bis Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 5:42 +0000 3/8/03, Paul Vixie wrote: >the process used by dnssec-editors@ has appeared to be somewhat successful, >so let's see if we can get some agreement on various upgrade issues between >RFC2136 and its inevitable "bis" version. olafur, if we could have a few >minutes to discuss this in san francisco, it might help to get a new document >out immediately thereafter. > >-------- > >#1 -- scope of changes > >i'm hoping that we can do minimal changes, basically just editorial (for >clarity) or because of some kind of error or inconsistency. there's no >reason to revisit it at a deeper level nor to reconsider the basic approach. >(however, it's stuck at proposed standard until we get some things fixed.) > I agree with that. Pragmatically, no one is screaming about the protocol. I'll only answer to some issues. >#3 -- rr type restrictions > >do we need to disallow updates of the dnssec types, or cause logical OR'ing >if an NXT is appended, or anything like that? I would recommend that the dynamic update server do no action whatsoever on an NXT in a request. A dynamic update client must never include an NXT in any section of the request. As far as KEY RR - the server MAY refuse to accept (act upon) a request to add/alter a key that does not meet the key-restrict RFC requirements. As far as SIG SS - the server MAY refuse to accept (act upon) a request which contains a explicitly cryptographically invalid signature or a signature whose expiration is in the past (according to the master server's clock). Note: nothing requires that the public key component of the key generating the SIG RR be available to the master server - that's why 'explicitly' is mentioned. (Details, details...) > >-------- > >#4 -- clarification of domain owner naming > > 1.2 - Glue RRs > > For the purpose of determining whether a domain name used in the UPDATE > protocol is contained within a specified zone, a domain name is ``in'' a > zone if it is owned by that zone's domain name. See section 7.18 for > details. > >a number of people have said that "owned by" is hard to read. therefore >perhaps we should expand it to say "at or below the zone apex". the reason >this is here is that it's possible to add data to a zone which is below a >zone "bottom cut" (see section 7.18, i guess) even though that data will >not be visible to opcode QUERY. i think "owned by" is the right term but >i am willing to expand it if others think differently. I think there's a terminology problem in the doc. I'd try this: 1.2 - Glue RRs For the purpose of determining whether an name used in the UPDATE is contained within a specified zone, an name is ``in'' a zone if the zone's domain name. See section 7.18 for details. I put the significant changes in angle brackets. The point is that only only the "owner names" in RR's within the dynamic update request are at issue. The other point is that whether A is a subdomain of B is a question that ignores zone cuts. >#6 -- edns request-id field >allow me to curse myself permission granted ;) >#7 -- order of permission checking > >that it wants to in order to make its decision. it should also be run as >early as possible in order to catch a DDoS before having done any work on >behalf of the attacker. I agree, if for that reason alone. >#10 -- security improvements > >i think that we should require TSIG or SIG(0), and disallow ip source >address verification unless TCP is used. ack >i also think that we should recommend that if TCP is used, an implicit >ip source address access control rule should allow "that host" (the >initiator) to update its own PTR RR (either in in-addr.arpa or ip6.arpa.) Sounds reasonable. Perhaps this should be tested at a conference though. >#12 -- issues from another unnamed party > >> ... >> # NXDOMAIN 3 Some name that ought to exist, >> # does not exist. >> >> I'd change this to "The QNAME sought does not exist" > >that doesn't work in the context of an UPDATE operation, where there is no >QNAME, and in fact any "name must exist" or "rrset must exist" or even "rr >must exist" in the prerequisites section can cause an rcode of NXDOMAIN to >be sent back to an UPDATE requestor. > >it's apparently going to be necessary for the rcodes to be unique to each >opcode. at least the definition of each rcode has to vary per opcode, and >maybe we ought to consider reusing the rcode numbers themselves per opcode. Okay, but then how about not using NXDOMAIN here. The problem is that in RFC 1034 the authoritative name error has morphed in the documents to NXDOMAIN via the use of NXDOMAIN in BIND code. Here, though, is an RFC defining NXDOMAIN to mean something other than 'authorative name error.' I guess that's the rub here...probably needs more hashing out. >th-th-that's all folks. what else has anybody got against 2136 that they'd >like to see fixed in 2136bis? Yeah. Two issues arose as a result of a tutorial given last September at RIPE. In a nutshell: 1) When a zone is frozen (in one implementation: temporarily suspending dynamic updates), is it worthwhile sending out an error message that says: dynamic update is suspended? This was discussed on namedroppers, I'll have to find the archives when I'm back on net. 2) The error returned when a bad TSIG key is used: Below is a part of a message to bind-bugs on this. I don't dispute Mark's answer, but it points to something that we might want to clarify: that the error is generated in TSIG processing and not the dynamic update processing. >> I just noticed this: >> >> >Outgoing update query: >> >;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 32593 >> >;; flags: ; ZONE: 1, PREREQ: 0, UPDATE: 1, ADDITIONAL: 1 >> >;; ZONE SECTION: >> >;dynamic.myzone.example. IN SOA >> > >> >;; UPDATE SECTION: >> >a.dynamic.myzone.example. 9000 IN TXT "ksjlksjdfjsdklf" >> > >> >;; TSIG PSEUDOSECTION: >> >four. 0 ANY TSIG hmac-md5.sig-alg.reg.int. \ >> > 10318 37255 300 16 R52twrMFLZfk+jYlYs6qBA== 32593 NOERROR >> 0 >> > >> >> My print statement... >> >nsupdate : Result code is 65575 >> >> >; TSIG error with server: tsig indicates error >> > >> >Reply from update query: >> >;; ->>HEADER<<- opcode: UPDATE, status: NOTAUTH, id: 32593 >> >;; flags: qr ; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1 >> >;; TSIG PSEUDOSECTION: >> >four. 0 ANY TSIG hmac-md5.sig-alg.reg.int. \ >> > 10318 37255 300 0 32593 BADKEY 0 >> >> NOTAUTH should apply to the "a.dynamic.myzone.example." and not the >> tsig name. True, the TSIG name is bad (it was part of a test of bad >> updates), but that should mean the error code is REFUSED here. >> > > The answer looks correct according to RFC 2845. > > Mark -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 10 13:25:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06742 for ; Mon, 10 Mar 2003 13:25:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sRkE-000PYs-00 for namedroppers-data@psg.com; Mon, 10 Mar 2003 10:11:26 -0800 Received: from fxodpr13.extra.daimlerchrysler.com ([129.9.82.74]) by psg.com with esmtp (Exim 3.36 #1) id 18sRkB-000PYg-00 for namedroppers@ops.ietf.org; Mon, 10 Mar 2003 10:11:24 -0800 Received: (from uucp@localhost) by fxodpr13.extra.daimlerchrysler.com (8.12.8/8.9.0) id h2AIBMTl022142 for ; Mon, 10 Mar 2003 13:11:22 -0500 (EST) Received: from unknown(53.231.71.237) by fxodpr13.extra.daimlerchrysler.com via csmap (V6.0) id srcAAAaXaOpR; Mon, 10 Mar 03 13:11:22 -0500 Received: from odmrspr2-hme0.oddc.chrysler.com ([53.231.2.113]) by odconpr2-hme0.oddc.chrysler.com (Mail-Gear 2.0.0 bld 58) with SMTP id M2003031013112232310 for ; Mon, 10 Mar 2003 13:11:22 -0500 Received: from daimlerchrysler.com ([53.231.58.205]) by odmrspr2-hme0.oddc.chrysler.com (8.12.8/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id h2AIBKY7005754 for ; Mon, 10 Mar 2003 13:11:22 -0500 (EST) Message-ID: <3E6CD59B.5000506@daimlerchrysler.com> Date: Mon, 10 Mar 2003 13:12:43 -0500 From: Kevin Darcy User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: namedroppers@ops.ietf.org Subject: Re: let's talk about RFC2136bis References: <20030308054248.30D5C379E40@as.vix.com> In-Reply-To: <20030308054248.30D5C379E40@as.vix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,MISSING_HEADERS,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: >the process used by dnssec-editors@ has appeared to be somewhat successful, >so let's see if we can get some agreement on various upgrade issues between >RFC2136 and its inevitable "bis" version. olafur, if we could have a few >minutes to discuss this in san francisco, it might help to get a new document >out immediately thereafter. > >-------- > >#1 -- scope of changes > >[snip] > >#2 -- rr comparison > >[snip] > >#3 -- rr type restrictions > >[snip] > >#4 -- clarification of domain owner naming > >[snip] > >#5 -- edns size issues > >[snip] > >#6 -- edns request-id field > >[snip] > >#7 -- order of permission checking > >[snip] > >#8 -- clarifying server selection > >[snip] > >#9 -- forwarding, threat or menace? > >[snip] > >#10 -- security improvements > >[snip] > >#11 -- misc issues from an unnamed party > >[snip] > >#12 -- issues from another unnamed party > > [snip] >th-th-that's all folks. what else has anybody got against 2136 that they'd >like to see fixed in 2136bis? > Remove the more-or-less arbitrary restriction on dynamic addition or deletion of SOA RRs. The "security improvements" changes you've proposed above would seem to moot the security-based objections to this, and the only other objections of which I'm aware -- concerns (one might say FUD) over how dynamic zone-creation/removal would work in practice -- confuse (IMO) implementation issues with protocol ones. - Kevin -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 10 13:41:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07430 for ; Mon, 10 Mar 2003 13:41:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sS00-0000DK-00 for namedroppers-data@psg.com; Mon, 10 Mar 2003 10:27:44 -0800 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 18sRzv-0000D2-00 for namedroppers@ops.ietf.org; Mon, 10 Mar 2003 10:27:39 -0800 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id NAA03822; Mon, 10 Mar 2003 13:27:06 -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 NAA27633; Mon, 10 Mar 2003 13:27:00 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h2AIQx0x017540; Mon, 10 Mar 2003 13:26:59 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id NAA12879; Mon, 10 Mar 2003 13:26:58 -0500 (EST) To: Paul Wouters Cc: dnssec@sidn.nl, , dnssec@verisignlabs.com, , From: Derek Atkins Subject: Re: DNSSEC (and secure .nl) mini HOWTO References: Date: 10 Mar 2003 13:26:58 -0500 In-Reply-To: Message-ID: Lines: 16 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-1.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,RCVD_IN_RELAYS_ORDB_ORG,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_GNUS_UA,X_OSIRU_OPEN_RELAY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul Wouters writes: > Another reason for me to push dnssec is FreeS/WAN, the Linux IPsec > implementation, that features "Opportunistic Encryption". OE is Just to be pedantic, FreeS/WAN is _a_ Linux IPsec implementation. It is NOT the only one. Indeed, Linux-2.5 has an embedded IPsec implementation that is decidedly NOT FreeS/WAN. There is also the USAGI implementation. -derek, trying to prevent the spread of false information -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 10 13:47:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07735 for ; Mon, 10 Mar 2003 13:47:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sS9Y-0000cy-00 for namedroppers-data@psg.com; Mon, 10 Mar 2003 10:37:36 -0800 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 18sS9R-0000cm-00 for namedroppers@ops.ietf.org; Mon, 10 Mar 2003 10:37:29 -0800 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id NAA03822; Mon, 10 Mar 2003 13:27:06 -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 NAA27633; Mon, 10 Mar 2003 13:27:00 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h2AIQx0x017540; Mon, 10 Mar 2003 13:26:59 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id NAA12879; Mon, 10 Mar 2003 13:26:58 -0500 (EST) To: Paul Wouters Cc: dnssec@sidn.nl, , dnssec@verisignlabs.com, , From: Derek Atkins Subject: Re: DNSSEC (and secure .nl) mini HOWTO References: Date: 10 Mar 2003 13:26:58 -0500 In-Reply-To: Message-ID: Lines: 16 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-1.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,RCVD_IN_RELAYS_ORDB_ORG,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_GNUS_UA,X_OSIRU_OPEN_RELAY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul Wouters writes: > Another reason for me to push dnssec is FreeS/WAN, the Linux IPsec > implementation, that features "Opportunistic Encryption". OE is Just to be pedantic, FreeS/WAN is _a_ Linux IPsec implementation. It is NOT the only one. Indeed, Linux-2.5 has an embedded IPsec implementation that is decidedly NOT FreeS/WAN. There is also the USAGI implementation. -derek, trying to prevent the spread of false information -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 10 14:08:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08631 for ; Mon, 10 Mar 2003 14:08:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sSWW-0001ig-00 for namedroppers-data@psg.com; Mon, 10 Mar 2003 11:01:20 -0800 Received: from maya20.nic.fr ([192.134.4.152]) by psg.com with esmtp (Exim 3.36 #1) id 18sSWS-0001iG-00 for namedroppers@ops.ietf.org; Mon, 10 Mar 2003 11:01:16 -0800 Received: from kerkenna.nic.fr (kerkenna.nic.fr [192.134.4.98]) by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id h2AJ1CZL1081770; Mon, 10 Mar 2003 20:01:12 +0100 (CET) Received: (from souissi@localhost) by kerkenna.nic.fr (8.11.6/8.9.3) id h2AJ1AB24779; Mon, 10 Mar 2003 20:01:10 +0100 Date: Mon, 10 Mar 2003 20:01:10 +0100 From: Mohsen Souissi To: namedroppers@ops.ietf.org Cc: Vladimir Ksinant Subject: Update of RFC1886 Interop Report Message-ID: <20030310200110.B1441@kerkenna.nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Spam-Status: No, hits=-0.6 required=5.0 tests=SPAM_PHRASE_03_05,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hi, RFC1886 Interop Report was reviewed and comments sent after the last call related to draft-ietf-dnsext-rfc1886bis-01.txt were taken into account. An updated version of the report is now available on : http://w6.afnic.fr/RFC1886/testRFC1886.html (dual-stack) This report corresponds to draft-ietf-dnsext-rfc1886bis-02.txt announced on the mailing-list on March 5th. Please note that the previous report (http://www.6wind.com/RFC1886/testRFC1886.html) is outdated and will be synchronised as soon as www.6wind.com web server is rebuilt. Thank you for your understanding, Vladimir & Mohsen. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 10 16:51:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16173 for ; Mon, 10 Mar 2003 16:51:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sUzp-0009Vw-00 for namedroppers-data@psg.com; Mon, 10 Mar 2003 13:39:45 -0800 Received: from mailrtr1.mailzone.edeltacom.com ([216.248.176.137]) by psg.com with esmtp (Exim 3.36 #1) id 18sUzm-0009Vk-00 for namedroppers@ops.ietf.org; Mon, 10 Mar 2003 13:39:42 -0800 Received: from dbothamlptp ([216.248.176.30]) by mailrtr1.mailzone.edeltacom.com (Mirapoint Messaging Server MOS 3.3.2-CR) with ESMTP id ALH02618; Mon, 10 Mar 2003 16:39:40 -0500 (EST) From: "David Botham" To: Subject: Looking for Dan Date: Mon, 10 Mar 2003 16:39:27 -0500 Message-ID: <000401c2e74d$866ccad0$3e641dac@dbothamlptp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=0.5 required=5.0 tests=SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello All, I am looking for Dan from the ARIN. We met at the 55th IETF. He was looking for a little web/ftp space for one of the projects dnsext is working on. I offered up some space. He sent me an email to follow up and I responded, then nothing... Dan, if you are out there... and you still need the space... Please drop me a line. Thanks, Dave... -- to unsubscribe send a message to namedroppers-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 10 16:52:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16191 for ; Mon, 10 Mar 2003 16:52:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sV3M-0009kh-00 for namedroppers-data@psg.com; Mon, 10 Mar 2003 13:43:24 -0800 Received: from [2001:4f8:3:bb:2e0:81ff:fe23:7b5a] (helo=as.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 18sV3K-0009iN-00 for namedroppers@ops.ietf.org; Mon, 10 Mar 2003 13:43:22 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id C05BB379FC7 for ; Mon, 10 Mar 2003 21:43:08 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: let's talk about RFC2136bis In-Reply-To: Message from Kevin Darcy of "Mon, 10 Mar 2003 13:12:43 EST." <3E6CD59B.5000506@daimlerchrysler.com> X-Mailer: MH-E 7.2; nmh 1.0.4; GNU Emacs 21.2.1 Date: Mon, 10 Mar 2003 21:43:08 +0000 Message-Id: <20030310214308.C05BB379FC7@as.vix.com> X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > >... what else has anybody got against 2136 that they'd like to see > >fixed in 2136bis? > Remove the more-or-less arbitrary restriction on dynamic addition or > deletion of SOA RRs. The "security improvements" changes you've proposed > above would seem to moot the security-based objections to this, and the > only other objections of which I'm aware -- concerns (one might say FUD) > over how dynamic zone-creation/removal would work in practice -- confuse > (IMO) implementation issues with protocol ones. the restriction isn't arbitrary. at the moment, data needed for a zone to exist has to be transmitted out of band, since there is no defined format in any standard protocol for carrying things like zone data source (file name, sql table name, etc) or if it's a slave server, the list of axfr targets, or etc. then there's the problem of the zone section -- an soa by definition does not go into an existing zone, so the zone section would have to specify the new zone, which would not exist at the time of [rfc2136 3.1]. adding soa creation/deletion in 2136bis would not be a case of removing a restriction (arbitrary or not), it would be a fundamental change to the data model. i don't think we should attempt this in a "bis" document since we're really just trying to fix the things that implementors have found unclear or misleading or inconsistent or just plain wrong. i think a zone management protocol is badly needed, but 2136 (or 2136bis) is not it. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 10 17:47:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18107 for ; Mon, 10 Mar 2003 17:47:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sVv2-000CZ3-00 for namedroppers-data@psg.com; Mon, 10 Mar 2003 14:38:52 -0800 Received: from fxshpr08.extra.daimlerchrysler.com ([129.9.80.165] helo=fxshpr06.extra.daimlerchrysler.com) by psg.com with esmtp (Exim 3.36 #1) id 18sVuz-000CYr-00 for namedroppers@ops.ietf.org; Mon, 10 Mar 2003 14:38:49 -0800 Received: (from uucp@localhost) by fxshpr06.extra.daimlerchrysler.com (8.12.8/8.9.0) id h2AMarEM026206 for ; Mon, 10 Mar 2003 17:36:53 -0500 (EST) Received: from nodnsquery(129.9.147.104) by fxshpr08.extra.daimlerchrysler.com via csmap (V6.0) id srcAAAkfaOlZ; Mon, 10 Mar 03 17:36:53 -0500 Received: from odmrspr2-hme0.oddc.chrysler.com ([53.231.2.113]) by shconpr2-hme0.shdc.chrysler.com (Mail-Gear 2.0.0 bld 58) with SMTP id M2003031017384525872 for ; Mon, 10 Mar 2003 17:38:45 -0500 Received: from daimlerchrysler.com ([53.231.58.205]) by odmrspr2-hme0.oddc.chrysler.com (8.12.8/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id h2AMciY7017736 for ; Mon, 10 Mar 2003 17:38:45 -0500 (EST) Message-ID: <3E6D1446.6050906@daimlerchrysler.com> Date: Mon, 10 Mar 2003 17:40:06 -0500 From: Kevin Darcy User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: let's talk about RFC2136bis References: <20030310214308.C05BB379FC7@as.vix.com> In-Reply-To: <20030310214308.C05BB379FC7@as.vix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-3.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: >>>... what else has anybody got against 2136 that they'd like to see >>>fixed in 2136bis? >>> >>> > > > >>Remove the more-or-less arbitrary restriction on dynamic addition or >>deletion of SOA RRs. The "security improvements" changes you've proposed >>above would seem to moot the security-based objections to this, and the >>only other objections of which I'm aware -- concerns (one might say FUD) >>over how dynamic zone-creation/removal would work in practice -- confuse >>(IMO) implementation issues with protocol ones. >> >> > >the restriction isn't arbitrary. at the moment, data needed for a zone >to exist has to be transmitted out of band, since there is no defined >format in any standard protocol for carrying things like zone data source >(file name, sql table name, etc) > Which is an implementation detail, IMO. >or if it's a slave server, the list of >axfr targets, or etc. > I'm only considering master servers. >then there's the problem of the zone section -- an >soa by definition does not go into an existing zone, so the zone section >would have to specify the new zone, which would not exist at the time of >[rfc2136 3.1]. > Agreed. The algorithm would need to be tweaked slightly. Addition of an SOA RR would need to be a special case that bypasses (or inverts?) the usual "does this zone already exist?" checks. This doesn't seem major to me. >adding soa creation/deletion in 2136bis would not be a case of removing >a restriction (arbitrary or not), it would be a fundamental change to the >data model. i don't think we should attempt this in a "bis" document since >we're really just trying to fix the things that implementors have found >unclear or misleading or inconsistent or just plain wrong. > I disagree with "fundamental". Nothing really changes as far as the wire format is concerned, nor the initial parsing of the request packet, nor the response from the server. As mentioned above, a small tweak would need to be made to the processing algorithm, and only in the case of an SOA add (deletes would still need to check for the existence of the zone, as per normal). Perhaps you forgot to mention it, but there would also have to be some explicit language to the effect that the NS records for the child zone would need to be added in the same update request as the SOA "add" (since an SOA without NS records does not make for a legal zone). >i think a zone management protocol is badly needed, but 2136 (or 2136bis) >is not it. > And I'm not proposing a whole zone management protocol, only the lifting of one restriction in Dynamic Update that could be *part* of a zone management subsystem. This is not an all-or-nothing scenario. I see nothing wrong with part of the zone management subsystem using Dynamic Update, and the rest being done out-of-band. It doesn't have to all be done with a single protocol. Perhaps I should mention that my homegrown DNS maintenance system is based almost *entirely* on Dynamic Update. About the only part that isn't possible to do via Dynamic Update is zone creation and deletion. So, while it may seem "natural" to you that SOA addition and deletion should remain a special case for Dynamic Update, for me (and potentially others evolving in parallel or following my example) Dynamic Update is the "rule", and the prohibition against SOA adds or deletes is the "exception". And one which appears to have no solid justification, once the security issue is resolved. - Kevin -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 10 20:02:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22866 for ; Mon, 10 Mar 2003 20:02:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sY0q-000K7L-00 for namedroppers-data@psg.com; Mon, 10 Mar 2003 16:53:00 -0800 Received: from gusto.araneus.fi ([204.152.186.164]) by psg.com with esmtp (Exim 3.36 #1) id 18sY0n-000K78-00 for namedroppers@ops.ietf.org; Mon, 10 Mar 2003 16:52:57 -0800 Received: from guava.araneus.fi (adsl-63-197-0-204.dsl.snfc21.pacbell.net [63.197.0.204]) by gusto.araneus.fi (8.12.6/8.11.6) with ESMTP id h2B0qoN0006047; Mon, 10 Mar 2003 16:52:50 -0800 (PST) Received: from guava.araneus.fi (localhost [127.0.0.1]) by guava.araneus.fi (8.12.8/8.11.6) with ESMTP id h2B0qoha006309; Mon, 10 Mar 2003 16:52:50 -0800 (PST) Received: (from gson@localhost) by guava.araneus.fi (8.12.8/8.12.6/Submit) id h2B0ql3F006306; Mon, 10 Mar 2003 16:52:47 -0800 (PST) Date: Mon, 10 Mar 2003 16:52:47 -0800 (PST) Message-Id: <200303110052.h2B0ql3F006306@guava.araneus.fi> To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: let's talk about RFC2136bis In-Reply-To: <20030308054248.30D5C379E40@as.vix.com> References: <20030308054248.30D5C379E40@as.vix.com> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=1.5 required=5.0 tests=IN_REP_TO,RCVD_IN_RFCI,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Before I comment on the RFC2136 issues you mentioned, I'd like to add two more... #13 -- contradiction in section 3.4.2.2 3.4.2.2. Any Update RR whose CLASS is the same as ZCLASS is added to the zone. In case of duplicate RDATAs (which for SOA RRs is always the case, and for WKS RRs is the case if the ADDRESS and PROTOCOL fields both match), the Zone RR is replaced by Update RR. If the TYPE is SOA and there is no Zone SOA RR, or the new SOA.SERIAL is lower (according to [RFC1982]) than or equal to the current Zone SOA RR's SOA.SERIAL, the Update RR is ignored. In the case of a CNAME Update RR and a non-CNAME Zone RRset or vice versa, ignore the CNAME Update RR, otherwise replace the CNAME Zone RR with the CNAME Update RR. The last sentence contains a contradiction. If we have a non-CNAME Update RR and a CNAME Zone RRset (that's the "vice versa" case), it says we should "ignore the CNAME Update RR" even though the Update RR is not a CNAME. Also, strictly speaking the "otherwise" condition means "either both the Update RR and Zone RRset are CNAMEs, or neither one is", but the text following the "otherwise" only applies to the former case. I propose replacing the last sentence with the following two sentences: In the case of a CNAME Update RR and a non-CNAME Zone RRset or vice versa, ignore the Update RR. In the case of a CNAME Update RR and a CNAME Zone RR, replace the CNAME Zone RR with the CNAME Update RR. #14 -- conflict between section 3.4.2.4 and pseudocode The text of RFC2136 says: 3.4.2.4. For any Update RR whose class is NONE, any Zone RR whose NAME, TYPE, RDATA and RDLENGTH are equal to the Update RR is deleted, unless the NAME is the same as ZNAME and either the TYPE is SOA or the TYPE is NS and the matching Zone RR is the only NS remaining in the RRset, in which case this Update RR is ignored. The corresponding pseudocode in section 3.4.2.7 says: elsif (rr.class == NONE) if (rr.type == SOA) next [rr] if (rr.type == NS && zone_rrset == rr) next [rr] zone_rr = Nil The text and the pseudocode are in conflict in the case where the last NS RR of an NS RR set in a place other than the zone apex (i.e., in a delegation) is being deleted. The text allows this deletion, but the pseudocode would cause it to be ignored. Since the text takes precendence over the pseudocode, the pseudocode should be changed to say elsif (rr.class == NONE) if (rr.type == SOA) next [rr] if (rr.type == NS && rr.name == zname && zone_rrset == rr) next [rr] zone_rr = Nil -- 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 10 22:50:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26150 for ; Mon, 10 Mar 2003 22:50:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sad7-0003b3-00 for namedroppers-data@psg.com; Mon, 10 Mar 2003 19:40:41 -0800 Received: from mailrtr1.mailzone.edeltacom.com ([216.248.176.137]) by psg.com with esmtp (Exim 3.36 #1) id 18sad4-0003ar-00 for namedroppers@ops.ietf.org; Mon, 10 Mar 2003 19:40:38 -0800 Received: from mailsvr2.mailzone.edeltacom.com ([216.248.176.147]) by mailrtr1.mailzone.edeltacom.com (Mirapoint Messaging Server MOS 3.3.2-CR) with ESMTP id ALH30358; Mon, 10 Mar 2003 22:40:37 -0500 (EST) Received: from mailsvr2.mailzone.edeltacom.com (localhost.mailzone.edeltacom.com [127.0.0.1]) by mailsvr2.mailzone.edeltacom.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AHI45653; Mon, 10 Mar 2003 22:40:36 -0500 (EST) From: Message-Id: <200303110340.AHI45653@mailsvr2.mailzone.edeltacom.com> Received: from 68.114.2.142 by mailsvr2.mailzone.edeltacom.com (Mirapoint Messaging Server MOS 3.2.1-GA) with HTTP/1.1; Mon, 10 Mar 2003 22:40:36 -0500 Date: Mon, 10 Mar 2003 22:40:36 -0500 Subject: Re: let's talk about RFC2136bis To: namedroppers@ops.ietf.org X-Mailer: Webmail Mirapoint Direct 3.2.1-GA MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.8 required=5.0 tests=MSG_ID_ADDED_BY_MTA_2,NO_REAL_NAME,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,TO_BE_REMOVED_REPLY version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ---- Original message ---- >Date: Mon, 10 Mar 2003 21:43:08 +0000 >From: Paul Vixie >Subject: Re: let's talk about RFC2136bis >To: namedroppers@ops.ietf.org > >> >... what else has anybody got against 2136 that they'd like to see >> >fixed in 2136bis? > >> Remove the more-or-less arbitrary restriction on dynamic addition or >> deletion of SOA RRs. The "security improvements" changes you've proposed >> above would seem to moot the security-based objections to this, and the >> only other objections of which I'm aware -- concerns (one might say FUD) >> over how dynamic zone-creation/removal would work in practice -- confuse >> (IMO) implementation issues with protocol ones. > >the restriction isn't arbitrary. at the moment, data needed for a zone >to exist has to be transmitted out of band, since there is no defined >format in any standard protocol for carrying things like zone data source >(file name, sql table name, etc) or if it's a slave server, the list of >axfr targets, or etc. then there's the problem of the zone section -- an >soa by definition does not go into an existing zone, so the zone section >would have to specify the new zone, which would not exist at the time of >[rfc2136 3.1]. > >adding soa creation/deletion in 2136bis would not be a case of removing >a restriction (arbitrary or not), it would be a fundamental change to the >data model. i don't think we should attempt this in a "bis" document since >we're really just trying to fix the things that implementors have found >unclear or misleading or inconsistent or just plain wrong. > >i think a zone management protocol is badly needed, but 2136 (or 2136bis) >is not it. If I could comment, If "zone management" is restricted to the implementation independent tasks of adding or dropping of zones, then could we develop a draft that goes something like: For an add: Master loads zone and sends a "zone add" directive to the slaves. Slaves receive the "zone add" and add the zone via a zone tranfer (provided the human has decided to trust the master) For a drop: Master drops a zone and sends a "zone drop" directive to the slaves. Slaves receive the "zone drop" and drop the zone. I realize that there are many other tasks associated with zone management depending on the implementatin. The protocol could set part of the packet(s) aside for implementation specific data that can be safely ignored by servers that may not understand things like views or acl's, for example. I know this is way over simplified, but, would that be the bulk of it? Dave... > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 11 02:39:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11918 for ; Tue, 11 Mar 2003 02:39:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18seEz-000J1O-00 for namedroppers-data@psg.com; Mon, 10 Mar 2003 23:32:01 -0800 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 18seEw-000J0e-00 for namedroppers@ops.ietf.org; Mon, 10 Mar 2003 23:31:58 -0800 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h2B7UXb21672; Tue, 11 Mar 2003 14:30:37 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h2B7U5O18308; Tue, 11 Mar 2003 14:30:06 +0700 (ICT) From: Robert Elz To: Mohsen Souissi cc: namedroppers@ops.ietf.org, Vladimir Ksinant Subject: Re: Update of RFC1886 Interop Report In-Reply-To: <20030310200110.B1441@kerkenna.nic.fr> References: <20030310200110.B1441@kerkenna.nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Mar 2003 14:30:05 +0700 Message-ID: <18306.1047367805@munnari.OZ.AU> X-Spam-Status: No, hits=-0.5 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_02_03 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Mon, 10 Mar 2003 20:01:10 +0100 From: Mohsen Souissi Message-ID: <20030310200110.B1441@kerkenna.nic.fr> | RFC1886 Interop Report was reviewed and comments sent after the last | call related to draft-ietf-dnsext-rfc1886bis-01.txt were taken into | account. An updated version of the report is now available on : | | http://w6.afnic.fr/RFC1886/testRFC1886.html (dual-stack) I'm sorry to have to say that you still don't have that right. First, it is not "necessary" to test additional section processing of SOA records, as none of that is required. That is, it doesn't matter in the slightest what happens when a SOA query is done, whether NS's are put in the auth section or not, nor whether A/AAAA are then added to the additional section for those NS's. There's nothing wrong with noting that many servers do this, and thus you decided to test it, and even to note the results, but please update the interop report to stop it pretending that SOA testing is required for 1886bis to go forward. In other words, change this text from the new report: So, the additional section processing of authority section must be tested. It is necessary to test the following records: MX, NS, SRV and SOA. into something like: So, additional section processing of the authority section was also tested to see what implementors have done there. It is necessary to test the MX NS and SRV records, SOA was also tested. You do however need to test the additional section processing in a referral, as distinct from an explicit NS lookup - those two should be noted separately in the results. Second, when a server fails the tests (which you report server Z as having done for some) you should find out why, and include that information. It may be that from reading 1886 the authors of that server came to different conclusions about what was required than others have. In that case, whatever was unclear about 1886 would need to be fixed in 1886bis so that future implementors don't get trapped the same way. On the other hand, there may just be admitted implementation shortfalls or bugs in implementation Z, along the lines of "oh yes, I didn't get to that yet" or "oops, I see what happened" or even "I don't think that's the right thing to do so I won't do it" from the implementor, indicating that the text in 1886 was fine, but there were implementation errors (in which case no revisions are needed to the doc, and the buggy implementation is irrelevant, as there are still X and Y around, and only 2 are required.) This is particularly true when there are just 3 implementations tested (if there were 10 tested, and 9 did it the right way, and one didn't, it might be reasonable to just assume "implementation bug", but with 1 out of 3 getting it wrong that's a much bigger risk). [Aside: I'd love to know how an implementation can possibly fail to support a particular domain name (as a server) ... but that's not really relevant here - but are you sure that the particular one you tested just wasn't "not configured for IP6.ARPA" ?] For the successful tests, you need to explicitly say what worked, just "everything worked" isn't clear enough. You should have a list of tests vs implementations, with an explicit "ok/fail" marker for each. There are many ways of setting out that info, and which is used doesn't matter, but for just 3 implementations a sensible way would be a list of things tested down the page, with columns to the right for each of the 3 servers. The resolvers (which should be more than just dig & nslookup I suggest) should also be tested to see that they actually use the additional info provided in the additional info section, and don't just ignore it. That is, if a server returns maildomain. IN MX 0 mailserver. mailserver. IN AAAA does a mailer using the resolver actually successfully look up maildomain. and then connect to its server (IPv6) without an additional query ? Similarly, some random clients that call gethostbyaddr() (or its newer equivalent that I'm too lazy to look for) should be tested to see that they do the correct PTR lookup. Having servers support the PTR lookups for IP6 addresses isn't very interesting (about the only thing that's tested there is that the server can handle domain names with a very deep domain tree - nothing else is even vaguely IP6 specific at the server end) - what matters really is whether clients generate the correct domain name for the PTR lookup (of course, we know they do, many of us use this every day - but it needs to be documented in the interop report). How that handles IP6.INT vs IP6.ARPA should be noted, though for 1886bis all that really matters is that IP6.ARPA gets looked up (handling IP6.INT is just an implementation requirement for transition, 1886bis doesn't require anything at all about IP6.INT). 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 11 10:28:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23577 for ; Tue, 11 Mar 2003 10:28:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18slTs-0009CV-00 for namedroppers-data@psg.com; Tue, 11 Mar 2003 07:15:52 -0800 Received: from [2001:4f8:3:bb:2e0:81ff:fe23:7b5a] (helo=as.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 18slTp-0009Bq-00 for namedroppers@ops.ietf.org; Tue, 11 Mar 2003 07:15:49 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 36048379E40 for ; Tue, 11 Mar 2003 15:15:31 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: zone management (Re: let's talk about RFC2136bis ) In-Reply-To: Message from of "Mon, 10 Mar 2003 22:40:36 EST." <200303110340.AHI45653@mailsvr2.mailzone.edeltacom.com> X-Mailer: MH-E 7.2; nmh 1.0.4; GNU Emacs 21.2.1 Date: Tue, 11 Mar 2003 15:15:31 +0000 Message-Id: <20030311151531.36048379E40@as.vix.com> X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > >i think a zone management protocol is badly needed, but 2136 (or 2136bis) > >is not it. > > If I could comment, it's ietf, everybody can comment. however, knowing only that your first name is "dave" and that your e-mail address is namedroppers@botham.net does not exactly fill me with the kind of warmth i'd like to experience when evaluating a proposal. (can maybe you spruce up your .signature a bit?) > If "zone management" is restricted to the implementation independent > tasks of adding or dropping of zones, then could we develop a draft > that goes something like: > > For an add: > > Master loads zone and sends a "zone add" directive to the slaves. > Slaves receive the "zone add" and add the zone via a zone tranfer > (provided the human has decided to trust the master) > > For a drop: > > Master drops a zone and sends a "zone drop" directive to the slaves. > Slaves receive the "zone drop" and drop the zone. > > I realize that there are many other tasks associated with zone > management depending on the implementatin. The protocol could set part > of the packet(s) aside for implementation specific data that can be > safely ignored by servers that may not understand things like views or > acl's, for example. > > I know this is way over simplified, but, would that be the bulk of it? in my opinion, no. there are implementation-dependent zone metadata elements (such as backing store or data source... zone file or sql table name or whatever) which, when unspecified, leave the zone in an error state (all queries would be answered SERVFAIL). i don't think a protocol which is only reliably capable of creating an error state is a good idea. therefore a zone management protocol, in order to be worthy of a standard, would have to enumerate some common forms of implementation-dependent data, like "master file name" and "slave file name" and "sql table name" and "active directory domain name" and so on. implementors from mydns, nominum, ultradns, isc/bind, and so on would all have to contribute. the nonimplementors in the crowd would have to participate in order to ensure that the result was both complete and extensible. it's a big effort. the minimal size of the effort is larger than what you proposed, in my opinion.) (and 2136bis will NOT address this area at all, since the lack of zone management features in 2136 is not due to editorial error or oversight, and has not led any implementor to scratch their head wondering what the document means.) -- to unsubscribe send a message to namedroppers-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 11 12:46:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29396 for ; Tue, 11 Mar 2003 12:46:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18snhG-000GG7-00 for namedroppers-data@psg.com; Tue, 11 Mar 2003 09:37:50 -0800 Received: from sentry.gw.tislabs.com ([192.94.214.100]) by psg.com with esmtp (Exim 3.36 #1) id 18snh0-000GFU-00 for namedroppers@ops.ietf.org; Tue, 11 Mar 2003 09:37:34 -0800 Received: by sentry.gw.tislabs.com; id MAA17570; Tue, 11 Mar 2003 12:38:24 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma017551; Tue, 11 Mar 03 12:38:21 -0500 Received: from localhost (weiler@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) with ESMTP id h2BHbUr06633 for ; Tue, 11 Mar 2003 12:37:30 -0500 (EST) Date: Tue, 11 Mar 2003 12:37:30 -0500 (EST) From: Sam Weiler X-X-Sender: To: Subject: DS-13: record ordering Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.2 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk DS-13 section 2.2 says "...MUST include the following RRsets ... in this order..." Does the order really matter? Is there something that will break if they're reordered? Should the "in this order" be dropped? -- Sam -- to unsubscribe send a message to namedroppers-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 11 12:47:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29456 for ; Tue, 11 Mar 2003 12:47:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18snjk-000GPL-00 for namedroppers-data@psg.com; Tue, 11 Mar 2003 09:40:24 -0800 Received: from mailrtr1.mailzone.edeltacom.com ([216.248.176.137]) by psg.com with esmtp (Exim 3.36 #1) id 18snji-000GP9-00 for namedroppers@ops.ietf.org; Tue, 11 Mar 2003 09:40:22 -0800 Received: from dbothamlptp ([216.248.176.30]) by mailrtr1.mailzone.edeltacom.com (Mirapoint Messaging Server MOS 3.3.2-CR) with ESMTP id ALI03486; Tue, 11 Mar 2003 12:40:20 -0500 (EST) From: "David Botham" To: Subject: Introducing Myself (RE: zone management (Re: let's talk about RFC2136bis )) Date: Tue, 11 Mar 2003 12:40:05 -0500 Message-ID: <000001c2e7f5$4137b990$3e641dac@dbothamlptp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <20030311151531.36048379E40@as.vix.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [clip...] Paul Vixie wrote: > > it's ietf, everybody can comment. however, knowing only that your first > name is "dave" and that your e-mail address is namedroppers@botham.net > does > not exactly fill me with the kind of warmth i'd like to experience when > evaluating a proposal. (can maybe you spruce up your .signature a bit?) Yes, perhaps a small introduction would be a good thing. Sorry about that. My name is David Botham. I work for a VAR/Consulting firm in Atlanta, GA, e^deltacom. One of the areas I specialize in is the DNS. I once thought I knew a lot about the DNS, until I subscribed to a couple DNS related mailing lists. Now I know that the real DNS gurus have forgotten more about DNS that I will probably ever learn. Most of my implementation experience is with BIND4, 8, 9 on Solaris and Linux. I have also worked with NT's DNS, W2K's DNS, MetaIP, and Network Registrar (when it was American Internet). I have read the RFC's and continue to put the pieces together as I go. Is that helpful? Dave... > [clip...] -- to unsubscribe send a message to namedroppers-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 11 12:48:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29504 for ; Tue, 11 Mar 2003 12:48:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sniN-000GHy-00 for namedroppers-data@psg.com; Tue, 11 Mar 2003 09:38:59 -0800 Received: from [3ffe:b80:2:a90::2] (helo=devil.pp.htv.fi) by psg.com with esmtp (Exim 3.36 #1) id 18sniG-000GHb-00 for namedroppers@ops.ietf.org; Tue, 11 Mar 2003 09:38:56 -0800 Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) with ESMTP id h2BHdZwY017652; Tue, 11 Mar 2003 19:39:36 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) id h2BHdY09017648; Tue, 11 Mar 2003 19:39:34 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: [LLMNR] Conflict resolution From: Mika Liljeberg To: Bernard Aboba Cc: namedroppers@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1047404373.2473.1764.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 11 Mar 2003 19:39:34 +0200 X-Spam-Status: No, hits=-1.1 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, TO_BE_REMOVED_REPLY,X_AUTH_WARNING version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Section 5 states: Every responder that responds to a LLMNR query and/or dynamic update request AND includes a UNIQUE record in the response: 1. MUST verify that there is no other host within the scope of the LLMNR query propagation that can return a resource record for the same name, type and class. 2. MUST NOT include a UNIQUE resource record in the response without having verified its uniqueness. How does a responder know whether a particular RR that it owns is UNIQUE or not? Looks like this attribute has to be manually configured for every RR on every authoritative responder. Is this interpretation correct? I suppose an implementation can simply choose to not support cluster names and just assert that every RR it owns is UNIQUE. MikaL On Sat, 2003-03-08 at 02:42, Bernard Aboba wrote: > In order to better track LLMNR issues, and ready the LLMNR draft for > DNSEXT WG last call, we have created an LLMNR issues list: > > http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html > > The LLMNR editors would like to encourage participants in the DNSEXT WG > who have not yet read the LLMNR draft to do so ASAP, and email your issues > in the format described on the Issues list, to namedroppers@ops.ietf.org, > with a CC: to lmnr-editors@internaut.com. > > The latest LLMNR draft is available at: > > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-13.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: -- to unsubscribe send a message to namedroppers-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 11 13:04:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29889 for ; Tue, 11 Mar 2003 13:04:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18so0p-000HLQ-00 for namedroppers-data@psg.com; Tue, 11 Mar 2003 09:58:03 -0800 Received: from [2001:4f8:3:bb:2e0:81ff:fe23:7b5a] (helo=as.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 18so0l-000HKk-00 for namedroppers@ops.ietf.org; Tue, 11 Mar 2003 09:57:59 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id C0D55379E40 for ; Tue, 11 Mar 2003 17:57:46 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: comments on ds-13 X-Mailer: MH-E 7.2; nmh 1.0.4; GNU Emacs 21.2.1 Date: Tue, 11 Mar 2003 17:57:46 +0000 Message-Id: <20030311175746.C0D55379E40@as.vix.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk olafur, you wrote (in draft-ietf-dnsext-delegation-signer-13.txt), >> DS RRsets MUST NOT appear at non-delegation points or at a zone's apex. why not? i think you can say they are irrelevant elsewhere, but i don't think there's a way to show that they are in any way harmful elsewhere. as a simple document quality issue, there is no way to enforce this requirement and no reliable way to even know when it has been violated. so at best it would be a SHOULD not a MUST. however, even as a SHOULD, it overreaches. the proper attitude of a document toward its protocol is to specify things which, if left unspecified, will lead to loss of interoperability or functionality. there is no such argument to be made for restricting the placement of DS RRs (or for restricting the use of KEYs for that matter.) paul -- to unsubscribe send a message to namedroppers-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 11 15:21:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10577 for ; Tue, 11 Mar 2003 15:21:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sq1M-000Og2-00 for namedroppers-data@psg.com; Tue, 11 Mar 2003 12:06:44 -0800 Received: from one.elistx.com ([209.116.252.130]) by psg.com with esmtp (Exim 3.36 #1) id 18sq1I-000Ofk-00 for namedroppers@ops.ietf.org; Tue, 11 Mar 2003 12:06:40 -0800 Received: from ogud.com (pcp816081pcs.nrockv01.md.comcast.net [68.49.60.118]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HBL00ILKP89IY@eListX.com> for namedroppers@ops.ietf.org; Tue, 11 Mar 2003 15:07:21 -0500 (EST) Received: from ENGILL.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.3/8.12.3) with ESMTP id h2BK7HbZ009618; Tue, 11 Mar 2003 15:07:18 -0500 (EST envelope-from ogud@ogud.com) Date: Tue, 11 Mar 2003 15:04:38 -0500 From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: comments on ds-13 In-reply-to: <20030311175746.C0D55379E40@as.vix.com> X-Sender: post@localhost To: Paul Vixie , namedroppers@ops.ietf.org Message-id: <5.1.1.6.2.20030311144427.032c2cc0@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=us-ascii X-Spam-Status: No, hits=2.3 required=5.0 tests=IN_REP_TO,RCVD_IN_RFCI,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 12:57 2003-03-11, Paul Vixie wrote: >olafur, you wrote (in draft-ietf-dnsext-delegation-signer-13.txt), > > >> DS RRsets MUST NOT appear at non-delegation points or at a zone's apex. > >why not? i think you can say they are irrelevant elsewhere, but i don't >think there's a way to show that they are in any way harmful elsewhere. Well the record is called "Delegation Signer". IMHO this is a record for DNS consumption, and only for DNS, it makes limited sense to have DS record at non delegation points within the context of current DNSSEC specification. In addition there are DS rules specify that it resides on the upper side of delegation. Does allowing DS to reside at normal node require more special cases? If someone figures out other uses for the DS concept that is not related to standard DNSSEC, lets define a new record for that. If the new usage is to somehow improve/add on DNSSEC then the use of DS should be considered. >as a simple document quality issue, there is no way to enforce this >requirement and no reliable way to even know when it has been violated. >so at best it would be a SHOULD not a MUST. This is a real good argument, and I would be happy to make the change base on this, if the working group says so. >however, even as a SHOULD, it overreaches. the proper attitude of a >document toward its protocol is to specify things which, if left >unspecified, will lead to loss of interoperability or functionality. >there is no such argument to be made for restricting the placement of >DS RRs (or for restricting the use of KEYs for that matter.) Remember the name and purpose of the record. Key on the other hand can be assigned to hosts for dynamic update purposes thus KEY is not restricted to APEX only. IFF KEY was restricted to DNSSEC zone signing only then restricting it to the apex would make sense. 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 11 16:24:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12805 for ; Tue, 11 Mar 2003 16:24:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sr5p-0002Ov-00 for namedroppers-data@psg.com; Tue, 11 Mar 2003 13:15:25 -0800 Received: from [2001:4f8:3:bb:2e0:81ff:fe23:7b5a] (helo=as.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 18sr5j-0002MH-00 for namedroppers@ops.ietf.org; Tue, 11 Mar 2003 13:15:19 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 86270379E40 for ; Tue, 11 Mar 2003 21:15:06 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: comments on ds-13 In-Reply-To: Message from =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= of "Tue, 11 Mar 2003 15:04:38 EST." <5.1.1.6.2.20030311144427.032c2cc0@localhost> X-Mailer: MH-E 7.2; nmh 1.0.4; GNU Emacs 21.2.1 Date: Tue, 11 Mar 2003 21:15:06 +0000 Message-Id: <20030311211506.86270379E40@as.vix.com> X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > >> DS RRsets MUST NOT appear at non-delegation points or at a zone's apex. > > > >why not? i think you can say they are irrelevant elsewhere, but i don't > >think there's a way to show that they are in any way harmful elsewhere. > > Well the record is called "Delegation Signer". IMHO this is a record > for DNS consumption, and only for DNS, it makes limited sense to have > DS record at non delegation points within the context of current > DNSSEC specification. that's all true but does not mention the harm in allowing them to exist at other than zone boundaries. > In addition there are DS rules specify that it resides on the upper > side of delegation. Does allowing DS to reside at normal node require > more special cases? nope. it's just data unless the delegation logic is being invoked. > If someone figures out other uses for the DS concept that is not > related to standard DNSSEC, lets define a new record for that. If the > new usage is to somehow improve/add on DNSSEC then the use of DS > should be considered. you have not yet shown any possible harm in letting DS RR's exist at places other than zone boundaries. > >as a simple document quality issue, there is no way to enforce this > >requirement and no reliable way to even know when it has been violated. > >so at best it would be a SHOULD not a MUST. > > This is a real good argument, and I would be happy to make the change > base on this, if the working group says so. i hope it's the default unless the working group decides to make a change like "it's ok to specify nonenforceable requirements in a standards doc." -- to unsubscribe send a message to namedroppers-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 11 18:43:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19010 for ; Tue, 11 Mar 2003 18:43:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18stFh-000AQF-00 for namedroppers-data@psg.com; Tue, 11 Mar 2003 15:33:45 -0800 Received: from mailrtr1.mailzone.edeltacom.com ([216.248.176.137]) by psg.com with esmtp (Exim 3.36 #1) id 18stFd-000AQ0-00 for namedroppers@ops.ietf.org; Tue, 11 Mar 2003 15:33:41 -0800 Received: from dbothamlptp ([216.248.176.30]) by mailrtr1.mailzone.edeltacom.com (Mirapoint Messaging Server MOS 3.3.2-CR) with ESMTP id ALI68887; Tue, 11 Mar 2003 18:33:39 -0500 (EST) From: "David Botham" To: Subject: RE: zone management (Re: let's talk about RFC2136bis ) Date: Tue, 11 Mar 2003 18:33:27 -0500 Message-ID: <000001c2e826$9de950f0$3e641dac@dbothamlptp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <20030311151531.36048379E40@as.vix.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=-0.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02, TO_BE_REMOVED_REPLY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-namedroppers@ops.ietf.org [mailto:owner- > namedroppers@ops.ietf.org] On Behalf Of Paul Vixie > Sent: Tuesday, March 11, 2003 10:16 AM > To: namedroppers@ops.ietf.org > Subject: zone management (Re: let's talk about RFC2136bis ) > > > >i think a zone management protocol is badly needed, but 2136 (or > 2136bis) > > >is not it. > > > > If I could comment, > > it's ietf, everybody can comment. however, knowing only that your first > name is "dave" and that your e-mail address is namedroppers@botham.net > does > not exactly fill me with the kind of warmth i'd like to experience when > evaluating a proposal. (can maybe you spruce up your .signature a bit?) > > > If "zone management" is restricted to the implementation independent > > tasks of adding or dropping of zones, then could we develop a draft > > that goes something like: > > > > For an add: > > > > Master loads zone and sends a "zone add" directive to the slaves. > > Slaves receive the "zone add" and add the zone via a zone tranfer > > (provided the human has decided to trust the master) > > > > For a drop: > > > > Master drops a zone and sends a "zone drop" directive to the slaves. > > Slaves receive the "zone drop" and drop the zone. > > > > I realize that there are many other tasks associated with zone > > management depending on the implementatin. The protocol could set part > > of the packet(s) aside for implementation specific data that can be > > safely ignored by servers that may not understand things like views or > > acl's, for example. > > > > I know this is way over simplified, but, would that be the bulk of it? > > in my opinion, no. there are implementation-dependent zone metadata > elements (such as backing store or data source... zone file or sql table > name or whatever) which, when unspecified, leave the zone in an error > state (all queries would be answered SERVFAIL). i don't think a protocol > which is only reliably capable of creating an error state is a good idea. Well, maybe zone management was the wrong term for what I was suggesting. After reading your comments, I agree that zone management would necessarily have implementation-dependent components. Maybe Zone Provisioning is better choice of words. This topic goes back to a discussion on the bindusers list starting back in sep-2002. It was suggested that Notify could be used for the purpose of auto provisioning of zones on slaves. If this topic has already been pummeled here, please let me know. If not, and it seems like something worth pursuing, I would be interested in working on the development. > > therefore a zone management protocol, in order to be worthy of a standard, > would have to enumerate some common forms of implementation-dependent > data, Yes, but, would a zone provisioning protocol be worth pursuing? > like "master file name" and "slave file name" and "sql table name" and > "active directory domain name" and so on. implementors from mydns, > nominum, ultradns, isc/bind, and so on would all have to contribute. the > nonimplementors in the crowd would have to participate in order to ensure > that the result was both complete and extensible. > > it's a big effort. the minimal size of the effort is larger than what you > proposed, in my opinion.) > > (and 2136bis will NOT address this area at all, since the lack of zone > management features in 2136 is not due to editorial error or oversight, > and has not led any implementor to scratch their head wondering what the > document means.) > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 11 19:55:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21336 for ; Tue, 11 Mar 2003 19:55:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18suRk-000Eyb-00 for namedroppers-data@psg.com; Tue, 11 Mar 2003 16:50:16 -0800 Received: from cyphermail.sandelman.ottawa.on.ca ([192.139.46.78] helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 3.36 #1) id 18suRh-000EyH-00 for namedroppers@ops.ietf.org; Tue, 11 Mar 2003 16:50:13 -0800 Received: from sandelman.ottawa.on.ca ([66.114.232.182]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h2C0mUD13030 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Tue, 11 Mar 2003 19:48:50 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h2C0mMWi022867 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Tue, 11 Mar 2003 16:48:25 -0800 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h2C0mKRh022864 for ; Tue, 11 Mar 2003 16:48:22 -0800 Message-Id: <200303120048.h2C0mKRh022864@marajade.sandelman.ottawa.on.ca> To: namedroppers@ops.ietf.org Subject: Re: comments on ds-13 In-reply-to: Your message of "Tue, 11 Mar 2003 15:04:38 EST." <5.1.1.6.2.20030311144427.032c2cc0@localhost> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 11 Mar 2003 16:48:20 -0800 From: Michael Richardson X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,LINES_OF_YELLING,PGP_SIGNATURE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "mundsson" == mundsson writes: mundsson> delegation. Does allowing DS to reside at normal node require mundsson> more special cases? No. If there is any issue, you have to code for that case anyway, since you can rely upon the network or software to behave properly. >> as a simple document quality issue, there is no way to enforce this >> requirement and no reliable way to even know when it has been >> violated. so at best it would be a SHOULD not a MUST. mundsson> This is a real good argument, and I would be happy to make the mundsson> change base on this, if the working group says so. I'd agree with Paul. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPm6D0oqHRg3pndX9AQHMGwP/V79/h/oH6vq6U1GnILz7rWv4tl1xg/pB cctDNKXg8gRgvf/zkr8B/YAhiSlzC1q4CUeY9T28iRMQedja16RPeilaw7OOBCuA Qxf9ZoU3meB64a+/UhsNWuBtslgK5zJPJqMJdGvT9J+d3ZGk40o8wnlUmGQPomNj 2+Xeuz+jdis= =eVBP -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 11 23:30:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25671 for ; Tue, 11 Mar 2003 23:30:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sxi8-000NHZ-00 for namedroppers-data@psg.com; Tue, 11 Mar 2003 20:19:24 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18sxi5-000NHD-00; Tue, 11 Mar 2003 20:19:21 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18sxhv-0009N4-00; Tue, 11 Mar 2003 20:19:11 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 11 Mar 2003 23:19:11 -0500 To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: comments on ds-13 References: <5.1.1.6.2.20030311144427.032c2cc0@localhost> <20030311211506.86270379E40@as.vix.com> Message-Id: X-Spam-Status: No, hits=-0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> If someone figures out other uses for the DS concept that is not >> related to standard DNSSEC, lets define a new record for that. If the >> new usage is to somehow improve/add on DNSSEC then the use of DS >> should be considered. > you have not yet shown any possible harm in letting DS RR's exist at > places other than zone boundaries. and no one has shown the benefit. so why add bangles to an already complex world for unknown uses? simplicity, please. 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 12 10:27:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07819 for ; Wed, 12 Mar 2003 10:27:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18t7w5-000K9M-00 for namedroppers-data@psg.com; Wed, 12 Mar 2003 07:14:29 -0800 Received: from [2001:4f8:3:bb:2e0:81ff:fe23:7b5a] (helo=as.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 18t7w1-000K8g-00 for namedroppers@ops.ietf.org; Wed, 12 Mar 2003 07:14:25 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id B6A78379E40 for ; Wed, 12 Mar 2003 15:14:09 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: zone management (Re: let's talk about RFC2136bis ) In-Reply-To: Message from "David Botham" of "Tue, 11 Mar 2003 18:33:27 EST." <000001c2e826$9de950f0$3e641dac@dbothamlptp> X-Mailer: MH-E 7.2; nmh 1.0.4; GNU Emacs 21.2.1 Date: Wed, 12 Mar 2003 15:14:09 +0000 Message-Id: <20030312151409.B6A78379E40@as.vix.com> X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Well, maybe zone management was the wrong term for what I was > suggesting. After reading your comments, I agree that zone management > would necessarily have implementation-dependent components. > > Maybe Zone Provisioning is better choice of words. This topic goes back > to a discussion on the bindusers list starting back in sep-2002. It was > suggested that Notify could be used for the purpose of auto provisioning > of zones on slaves. > > If this topic has already been pummeled here, please let me know. If > not, and it seems like something worth pursuing, I would be interested > in working on the development. > > ... > ..., would a zone provisioning protocol be worth pursuing? i think so, yes. it would be better to base it on update than on notify, in my opinion. -- to unsubscribe send a message to namedroppers-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 12 11:10:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09634 for ; Wed, 12 Mar 2003 11:10:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18t8i3-000Lxe-00 for namedroppers-data@psg.com; Wed, 12 Mar 2003 08:04:03 -0800 Received: from outpost.ds9a.nl ([213.244.168.210]) by psg.com with esmtp (Exim 3.36 #1) id 18t8i0-000LxO-00 for namedroppers@ops.ietf.org; Wed, 12 Mar 2003 08:04:00 -0800 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 5A47E44E2; Wed, 12 Mar 2003 17:03:57 +0100 (CET) Date: Wed, 12 Mar 2003 17:03:57 +0100 From: bert hubert To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: zone management (Re: let's talk about RFC2136bis ) Message-ID: <20030312160357.GB32668@outpost.ds9a.nl> References: <000001c2e826$9de950f0$3e641dac@dbothamlptp> <20030312151409.B6A78379E40@as.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030312151409.B6A78379E40@as.vix.com> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-4.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MUTT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, Mar 12, 2003 at 03:14:09PM +0000, Paul Vixie wrote: > > ..., would a zone provisioning protocol be worth pursuing? > > i think so, yes. it would be better to base it on update than on notify, > in my opinion. Many PowerDNS users use our 'supermaster' feature as poor man's zone provisioning, even though it does not provide for any deprovisioning support and has other major problems. So it appears that there is a real desire for a zone provisioning protocol. I'm willing to commit resources towards helping create such a spec and implement an implementation in PowerDNS while hopefully interoperating with other servers out there. Supermaster is described on: http://doc.powerdns.com/slave.html#SUPERMASTER Regards, bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing & Traffic Control HOWTO http://netherlabs.nl Consulting -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 12 14:13:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16695 for ; Wed, 12 Mar 2003 14:13:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tBJS-0001Fz-00 for namedroppers-data@psg.com; Wed, 12 Mar 2003 10:50:50 -0800 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 18tBJP-0001FV-00 for namedroppers@ops.ietf.org; Wed, 12 Mar 2003 10:50:47 -0800 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 6957218ED for ; Wed, 12 Mar 2003 13:50:16 -0500 (EST) Date: Wed, 12 Mar 2003 13:50:16 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: comments on ds-13 In-Reply-To: <200303120048.h2C0mKRh022864@marajade.sandelman.ottawa.on.ca> References: <5.1.1.6.2.20030311144427.032c2cc0@localhost> <200303120048.h2C0mKRh022864@marajade.sandelman.ottawa.on.ca> User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030312185016.6957218ED@thrintun.hactrn.net> X-Spam-Status: No, hits=-1.0 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The robustness principal probably applies here. DS is a DNS infrastructure RR type, we know of no useful purpose that DS RRs anywhere other than at delegation points would serve, and at least some of us think that reusing existing RR types for fundamentally different purposes is a risky thing to do, therefore: a) Zones either SHOULD NOT or MUST NOT include DS RRs anywhere but at delegation points; b) Software MUST cope if a zone violates (a). I tend to think that (a) should be MUST NOT, on the grounds that it probably simplifies the implementation of (b) slightly (software must not fall on its face, full stop, but don't expect an implementation to do anything useful with a non-delegation DS RR). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 12 14:48:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18123 for ; Wed, 12 Mar 2003 14:48:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tC38-0002wW-00 for namedroppers-data@psg.com; Wed, 12 Mar 2003 11:38:02 -0800 Received: from [2001:4f8:3:bb:2e0:81ff:fe23:7b5a] (helo=as.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 18tC36-0002vu-00 for namedroppers@ops.ietf.org; Wed, 12 Mar 2003 11:38:00 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id C6ECF379EF4 for ; Wed, 12 Mar 2003 19:37:46 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: comments on ds-13 In-Reply-To: Message from Rob Austein of "Wed, 12 Mar 2003 13:50:16 EST." <20030312185016.6957218ED@thrintun.hactrn.net> X-Mailer: MH-E 7.2; nmh 1.0.4; GNU Emacs 21.2.1 Date: Wed, 12 Mar 2003 19:37:46 +0000 Message-Id: <20030312193746.C6ECF379EF4@as.vix.com> X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > The robustness principal probably applies here. i'm sure it does but i think i interpret it in the opposite way. > DS is a DNS infrastructure RR type, we know of no useful purpose that > DS RRs anywhere other than at delegation points would serve, and at > least some of us think that reusing existing RR types for > fundamentally different purposes is a risky thing to do others of us think that putting in feel-good restrictions whose implementation status is unlikely to be rigourously tested (either for operability reasons or interoperability reasons) ultimately does no good (ever) and some harm (often). > ... therefore: > > a) Zones either SHOULD NOT or MUST NOT include DS RRs anywhere but at > delegation points; > > b) Software MUST cope if a zone violates (a). > > I tend to think that (a) should be MUST NOT, on the grounds that it > probably simplifies the implementation of (b) slightly (software must > not fall on its face, full stop, but don't expect an implementation to > do anything useful with a non-delegation DS RR). i humbly disagree. we should define what we mean and say that other uses are undefined. if we some day think of a reason to use these at non-delegation points, it'll be wonderful to know that authority servers (both master and slave) and caching forwarders are willing to pass the data through even though they have reason to believe that it wasn't at a delegation point. -- to unsubscribe send a message to namedroppers-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 12 23:17:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07133 for ; Wed, 12 Mar 2003 23:17:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tJvz-000Lq6-00 for namedroppers-data@psg.com; Wed, 12 Mar 2003 20:03:11 -0800 Received: from one.elistx.com ([209.116.252.130]) by psg.com with esmtp (Exim 3.36 #1) id 18tJvg-000LpD-00 for namedroppers@ops.ietf.org; Wed, 12 Mar 2003 20:02:53 -0800 Received: from ogud.com (pcp816081pcs.nrockv01.md.comcast.net [68.49.60.118]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HBO005AA5XVT6@eListX.com> for namedroppers@ops.ietf.org; Wed, 12 Mar 2003 23:03:32 -0500 (EST) Received: from ENGILL.ogud.com (ns.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.3/8.12.3) with ESMTP id h2D43EbZ018251 for ; Wed, 12 Mar 2003 23:03:17 -0500 (EST envelope-from ogud@ogud.com) Date: Wed, 12 Mar 2003 23:01:05 -0500 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: DNSEXT WGLC: To OPT_IN or not to OPT-IN X-Sender: (Unverified) To: namedroppers@ops.ietf.org Message-id: <5.1.1.6.2.20030312221746.022ed848@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=us-ascii X-Spam-Status: No, hits=4.3 required=5.0 tests=OPT_IN,RCVD_IN_RFCI,SPAM_PHRASE_01_02 version=2.43 X-Spam-Level: **** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This starts a two week working group last call, concluding on March 28'th 2003. Q: Is there consensus by the WG, to allow Opt-in zones? The document to base this discussion on is http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-opt-in-05.txt Please send explicit statements of support or disagreement. Note this is not a last call on the technical issues in the document, if any such issues exist they should be assumed to be fixable and not affect the judgment on the question above. The document is on the standards track. If this document is advanced by the working group, it will be integrated into the DNSSECbis documents. Silence during this working group last call will be taken as support for opt-in based on comments made during the technical last call on OPT-IN. 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 12 23:18:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07151 for ; Wed, 12 Mar 2003 23:18:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tJvj-000LpZ-00 for namedroppers-data@psg.com; Wed, 12 Mar 2003 20:02:55 -0800 Received: from one.elistx.com ([209.116.252.130]) by psg.com with esmtp (Exim 3.36 #1) id 18tJvg-000LpE-00 for namedroppers@ops.ietf.org; Wed, 12 Mar 2003 20:02:53 -0800 Received: from ogud.com (pcp816081pcs.nrockv01.md.comcast.net [68.49.60.118]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HBO0068W5XW3B@eListX.com> for namedroppers@ops.ietf.org; Wed, 12 Mar 2003 23:03:32 -0500 (EST) Received: from ENGILL.ogud.com (ns.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.3/8.12.3) with ESMTP id h2D43Ebb018251 for ; Wed, 12 Mar 2003 23:03:17 -0500 (EST envelope-from ogud@ogud.com) Date: Wed, 12 Mar 2003 22:59:30 -0500 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: DNSEXT WGLC: Key-Signing Key (KSK) Flag X-Sender: (Unverified) To: namedroppers@ops.ietf.org Message-id: <5.1.1.6.2.20030312221126.01629e78@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=us-ascii X-Spam-Status: No, hits=3.1 required=5.0 tests=RCVD_IN_RFCI,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: *** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This starts a 2 week Working Group last call on this document, concluding on March 28'th 2003. This document defines a new KEY RR flag that is used to identify keys that are used to sign KEY RRset. The flag is not used by the DNSSEC resolution process. The main purpose of this flag is to ease administration of DNSSEC signed zones. This document is on standards track and is available via following URL: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-06.txt Silence on this document during the last call will interpreted by chairs as instruction to drop this document. 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 12 23:19:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07193 for ; Wed, 12 Mar 2003 23:19:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tJvr-000Lpq-00 for namedroppers-data@psg.com; Wed, 12 Mar 2003 20:03:03 -0800 Received: from one.elistx.com ([209.116.252.130]) by psg.com with esmtp (Exim 3.36 #1) id 18tJvg-000LpF-00 for namedroppers@ops.ietf.org; Wed, 12 Mar 2003 20:02:53 -0800 Received: from ogud.com (pcp816081pcs.nrockv01.md.comcast.net [68.49.60.118]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HBO0069R5XW3F@eListX.com> for namedroppers@ops.ietf.org; Wed, 12 Mar 2003 23:03:32 -0500 (EST) Received: from ENGILL.ogud.com (ns.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.3/8.12.3) with ESMTP id h2D43Ebd018251 for ; Wed, 12 Mar 2003 23:03:18 -0500 (EST envelope-from ogud@ogud.com) Date: Wed, 12 Mar 2003 23:00:26 -0500 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: DNSEXT WGLC: DNS Threats X-Sender: (Unverified) To: namedroppers@ops.ietf.org Message-id: <5.1.1.6.2.20030312222622.022df350@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=us-ascii X-Spam-Status: No, hits=3.1 required=5.0 tests=RCVD_IN_RFCI,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: *** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This starts a 2 week Working Group last call on this document, concluding on March 28'th 2003. 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. http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-threats-02.txt This document is to be published as Informational. Note DNSSECbis documents refer to this document. Silence on this document will be taken as instruction to chairs to drop the document. 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 13 00:00:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08312 for ; Thu, 13 Mar 2003 00:00:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tKhb-000NWZ-00 for namedroppers-data@psg.com; Wed, 12 Mar 2003 20:52:23 -0800 Received: from one.elistx.com ([209.116.252.130]) by psg.com with esmtp (Exim 3.36 #1) id 18tKhQ-000NVv-00 for namedroppers@ops.ietf.org; Wed, 12 Mar 2003 20:52:12 -0800 Received: from ogud.com (pcp816081pcs.nrockv01.md.comcast.net [68.49.60.118]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HBO006DS8883D@eListX.com> for namedroppers@ops.ietf.org; Wed, 12 Mar 2003 23:52:57 -0500 (EST) Received: from ENGILL.ogud.com (ns.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.3/8.12.3) with ESMTP id h2D4qfbZ018401; Wed, 12 Mar 2003 23:52:41 -0500 (EST envelope-from ogud@ogud.com) Date: Wed, 12 Mar 2003 23:42:54 -0500 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: DNSEXT WG Agenda: IETF-56 X-Sender: (Unverified) To: namedroppers@ops.ietf.org Cc: agenda@ietf.org Message-id: <5.1.1.6.2.20030312233910.022df350@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=us-ascii X-Spam-Status: No, hits=4.6 required=5.0 tests=OPT_IN,RCVD_IN_RFCI,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: **** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk IETF-56 DNSEXT WG agenda Date: Tuesday 2003/03/18 Time: 9:00-11:30 Room: Continental 5 Chair(s): Randy Bush randy@psg.com Olafur Gudmundsson ogud@ogud.com Agenda Bashing Olafur Gudmundsson 3 min appointing scribes Status of Documents that have completed WG Last Call: Olafur 5 min DNSSEC Roadmap RFC Editors queue (???) GSSAPI Updated doc forwared to RFC editor AD secure IESG black hole AXFR-clarify Completed IETF last call Unknown Types AD nits before IETF last call DS IETF last call pending OK from chair's that all changes are done. Discover waiting on chair RFC1886-bis (AAAA) for DS: Minor nits in interoperabilty report need addressing. TKEY Renewal (Experimental) Pending chair consensus declaration IPv6 Address Registration (experimental) Pending chair consensus declaration Documents in WG last call: 10 min DNSSEC Opt-In http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-opt-in-05.txt DNSSEC KSK flag http://www.ietf.org/internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-06.txt DNS Threats http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-threats-02.txt DNSEXT revised charter Randy Bush 15 min http://psg.com/lists/namedroppers/namedroppers.2003/msg00507.html DNSEXT non DNSSEC documents: LLMNAR Bernard Aboda 15 min http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-13.txt http://psg.com/lists/namedroppers/namedroppers.2003/msg00536.html Case insensitive clarify Donald Eastlake 5 min http://www.ietf.org/internet-drafts/draft-ietf-dnsext-insensitive-02.txt Wild card clarify Edward Lewis 10 min http://www.ietf.org/internet-drafts/draft-lewis-dns-wildcard-clarify-00.txt Out of scope documents asking for Feedback: DNSEXT-ACL T Baba 5 min http://www.ietf.org/internet-drafts/draft-baba-dnsext-acl-reqts-00.txt 6DNAR Soohong Daniel Park 5 min http://www.ietf.org/internet-drafts/draft-jeong-hmipv6-dns-optimization-00.txt DNSSEC documents and discussion 90 min DNSSECbis Intro 10 min DNSSECbis Records DNSSECbis Protocol http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-intro-05.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-records-02.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-protocol-01.txt Opt-in David Blacka 5 min http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-opt-in-05.txt DS changes Olafur Gudmundsson 5 min http://www.ietf.org/internet-drafts/draft-ietf-dnsext-delegation-signer-13.txt DNSSEC Type code rolling Sam Weiler 7 min http://www.ietf.org/internet-drafts/draft-weiler-dnsext-dnssec-2535-compat-00.txt Open DNSSEC discussion: sample open issues: Opt-in decision How many ALG required (possibly add ECC) Editors open questions http://psg.com/lists/namedroppers/namedroppers.2003/msg00191.html http://psg.com/lists/namedroppers/namedroppers.2003/msg00192.html http://psg.com/lists/namedroppers/namedroppers.2003/msg00233.html http://psg.com/lists/namedroppers/namedroppers.2003/msg00235.html http://psg.com/lists/namedroppers/namedroppers.2003/msg00256.html http://psg.com/lists/namedroppers/namedroppers.2003/msg00498.html Type code roll or other solutions AD is [not] secure bit -- to unsubscribe send a message to namedroppers-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 13 01:18:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10086 for ; Thu, 13 Mar 2003 01:18:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tLvo-0000Od-00 for namedroppers-data@psg.com; Wed, 12 Mar 2003 22:11:08 -0800 Received: from [2001:4f8:3:bb:2e0:81ff:fe23:7b5a] (helo=as.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 18tLvl-0000O5-00 for namedroppers@ops.ietf.org; Wed, 12 Mar 2003 22:11:05 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id A2A4B379EF5 for ; Thu, 13 Mar 2003 06:10:51 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: Key-Signing Key (KSK) Flag In-Reply-To: Message from =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair of "Wed, 12 Mar 2003 22:59:30 EST." <5.1.1.6.2.20030312221126.01629e78@localhost> X-Mailer: MH-E 7.2; nmh 1.0.4; GNU Emacs 21.2.1 Date: Thu, 13 Mar 2003 06:10:51 +0000 Message-Id: <20030313061051.A2A4B379EF5@as.vix.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > This document defines a new KEY RR flag that is used to identify keys that > are used to sign KEY RRset. The flag is not used by the DNSSEC resolution > process. The main purpose of this flag is to ease administration of DNSSEC > signed zones. i support this. -- to unsubscribe send a message to namedroppers-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 13 01:18:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10100 for ; Thu, 13 Mar 2003 01:18:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tLuo-0000M5-00 for namedroppers-data@psg.com; Wed, 12 Mar 2003 22:10:06 -0800 Received: from [2001:4f8:3:bb:2e0:81ff:fe23:7b5a] (helo=as.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 18tLuk-0000Kx-00 for namedroppers@ops.ietf.org; Wed, 12 Mar 2003 22:10:03 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id B354D379E40 for ; Thu, 13 Mar 2003 06:09:49 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN In-Reply-To: Message from =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair of "Wed, 12 Mar 2003 23:01:05 EST." <5.1.1.6.2.20030312221746.022ed848@localhost> X-Mailer: MH-E 7.2; nmh 1.0.4; GNU Emacs 21.2.1 Date: Thu, 13 Mar 2003 06:09:49 +0000 Message-Id: <20030313060949.B354D379E40@as.vix.com> X-Spam-Status: No, hits=1.5 required=5.0 tests=IN_REP_TO,OPT_IN,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Q: Is there consensus by the WG, to allow Opt-in zones? > > Please send explicit statements of support or disagreement. as an individual, i support this. if organizational support matters, isc supports this too. -- to unsubscribe send a message to namedroppers-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 13 06:25:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26890 for ; Thu, 13 Mar 2003 06:25:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tQcp-0009H3-00 for namedroppers-data@psg.com; Thu, 13 Mar 2003 03:11:51 -0800 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 18tQcm-0009Gg-00 for namedroppers@ops.ietf.org; Thu, 13 Mar 2003 03:11:49 -0800 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.3/8.12.3/Debian-5) with ESMTP id h2DBBdwh008951; Thu, 13 Mar 2003 12:11:41 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.3/8.12.3/Debian-5) with ESMTP id h2DBBcw2008948; Thu, 13 Mar 2003 12:11:38 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Thu, 13 Mar 2003 12:11:38 +0100 (CET) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN In-Reply-To: <5.1.1.6.2.20030312221746.022ed848@localhost> Message-ID: References: <5.1.1.6.2.20030312221746.022ed848@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-1.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT_PINE,X_AUTH_WARNING version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id GAA26890 On Wed, 12 Mar 2003, Ólafur Gudmundsson/DNSEXT co-chair wrote: > > This starts a two week working group last call, > concluding on March 28'th 2003. > > Q: Is there consensus by the WG, to allow Opt-in zones? > > The document to base this discussion on is > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-opt-in-05.txt > > Please send explicit statements of support or disagreement. I support opt-in. 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 13 07:11:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27905 for ; Thu, 13 Mar 2003 07:11:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tRTY-000Ata-00 for namedroppers-data@psg.com; Thu, 13 Mar 2003 04:06:20 -0800 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 18tRTV-000AtK-00 for namedroppers@ops.ietf.org; Thu, 13 Mar 2003 04:06:17 -0800 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.3/8.12.3/Debian-5) with ESMTP id h2DC6Bwh010366; Thu, 13 Mar 2003 13:06:11 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.3/8.12.3/Debian-5) with ESMTP id h2DC6BvL010363; Thu, 13 Mar 2003 13:06:11 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Thu, 13 Mar 2003 13:06:11 +0100 (CET) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: DNS Threats In-Reply-To: <5.1.1.6.2.20030312222622.022df350@localhost> Message-ID: References: <5.1.1.6.2.20030312222622.022df350@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-3.7 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT_PINE,X_AUTH_WARNING version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id HAA27905 On Wed, 12 Mar 2003, Ólafur Gudmundsson/DNSEXT co-chair wrote: > This starts a 2 week Working Group last call on this document, > concluding on March 28'th 2003. > > 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. > > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-threats-02.txt > > This document is to be published as Informational. Note DNSSECbis > documents refer to this document. > > > Silence on this document will be taken as instruction to chairs > to drop the document. I support this draft. Thank you Derek and Rob for drafting the threats up, its a good read. DNSSEC is now 10 years old. Lets celebrate its birthday with a stable doc set. I invite everyone to read and comment on 2535bis!! Roy ps. you can find 2535-bis at http://www.logmess.com/~roy/2535bis.html (until all drafts pass the editors queue) -- to unsubscribe send a message to namedroppers-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 13 07:12:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27925 for ; Thu, 13 Mar 2003 07:12:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tRVa-000AyG-00 for namedroppers-data@psg.com; Thu, 13 Mar 2003 04:08:26 -0800 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 18tRVX-000Ay3-00 for namedroppers@ops.ietf.org; Thu, 13 Mar 2003 04:08:24 -0800 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.3/8.12.3/Debian-5) with ESMTP id h2DC8Hwh010419; Thu, 13 Mar 2003 13:08:18 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.3/8.12.3/Debian-5) with ESMTP id h2DC8H2a010416; Thu, 13 Mar 2003 13:08:17 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Thu, 13 Mar 2003 13:08:17 +0100 (CET) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: Key-Signing Key (KSK) Flag In-Reply-To: <5.1.1.6.2.20030312221126.01629e78@localhost> Message-ID: References: <5.1.1.6.2.20030312221126.01629e78@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-3.7 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT_PINE,X_AUTH_WARNING version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id HAA27925 On Wed, 12 Mar 2003, Ólafur Gudmundsson/DNSEXT co-chair wrote: > This starts a 2 week Working Group last call on this document, > concluding on March 28'th 2003. > > This document defines a new KEY RR flag that is used to identify keys that > are used to sign KEY RRset. The flag is not used by the DNSSEC resolution > process. The main purpose of this flag is to ease administration of DNSSEC > signed zones. > > This document is on standards track and is available via following URL: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-06.txt > > > Silence on this document during the last call will interpreted by chairs > as instruction to drop this document. I support this draft 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 13 08:10:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29170 for ; Thu, 13 Mar 2003 08:10:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tSMb-000D5l-00 for namedroppers-data@psg.com; Thu, 13 Mar 2003 05:03:13 -0800 Received: from pushme.nist.gov ([129.6.16.92] helo=postmark.nist.gov) by psg.com with esmtp (Exim 3.36 #1) id 18tSMX-000D5U-00 for namedroppers@ops.ietf.org; Thu, 13 Mar 2003 05:03:09 -0800 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h2DD2oCZ026414 for ; Thu, 13 Mar 2003 08:02:50 -0500 (EST) Message-ID: <007501c2e960$dc0ff240$b9370681@barnacle> From: "Scott Rose" To: References: <5.1.1.6.2.20030312221126.01629e78@localhost> Subject: Re: DNSEXT WGLC: Key-Signing Key (KSK) Flag Date: Thu, 13 Mar 2003 08:02:53 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=0.1 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, TO_BE_REMOVED_REPLY,USER_AGENT_OE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit I support this document. Scott ----- Original Message ----- From: "Ólafur Gudmundsson/DNSEXT co-chair" To: Sent: Wednesday, March 12, 2003 10:59 PM Subject: DNSEXT WGLC: Key-Signing Key (KSK) Flag > This starts a 2 week Working Group last call on this document, > concluding on March 28'th 2003. > > This document defines a new KEY RR flag that is used to identify keys that > are used to sign KEY RRset. The flag is not used by the DNSSEC resolution > process. The main purpose of this flag is to ease administration of DNSSEC > signed zones. > > This document is on standards track and is available via following URL: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag -06.txt > > > Silence on this document during the last call will interpreted by chairs > as instruction to drop this document. > > Olafur > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 13 08:11:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29226 for ; Thu, 13 Mar 2003 08:11:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tSP7-000DGF-00 for namedroppers-data@psg.com; Thu, 13 Mar 2003 05:05:49 -0800 Received: from pushme.nist.gov ([129.6.16.92] helo=postmark.nist.gov) by psg.com with esmtp (Exim 3.36 #1) id 18tSP4-000DG0-00 for namedroppers@ops.ietf.org; Thu, 13 Mar 2003 05:05:46 -0800 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h2DD5gCZ027404 for ; Thu, 13 Mar 2003 08:05:42 -0500 (EST) Message-ID: <007e01c2e961$42598de0$b9370681@barnacle> From: "Scott Rose" To: References: <5.1.1.6.2.20030312222622.022df350@localhost> Subject: Re: DNSEXT WGLC: DNS Threats Date: Thu, 13 Mar 2003 08:05:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=0.1 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, TO_BE_REMOVED_REPLY,USER_AGENT_OE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit I support this document as is. Scott ----- Original Message ----- From: "Ólafur Gudmundsson/DNSEXT co-chair" To: Sent: Wednesday, March 12, 2003 11:00 PM Subject: DNSEXT WGLC: DNS Threats > > This starts a 2 week Working Group last call on this document, > concluding on March 28'th 2003. > > 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. > > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-threats-02.txt > > This document is to be published as Informational. Note DNSSECbis > documents refer to this document. > > > Silence on this document will be taken as instruction to chairs > to drop the document. > > Olafur > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 13 08:15:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29392 for ; Thu, 13 Mar 2003 08:15:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tSMR-000D5H-00 for namedroppers-data@psg.com; Thu, 13 Mar 2003 05:03:03 -0800 Received: from h87.s239.netsol.com ([216.168.239.87] helo=chinook.rgy.netsol.com) by psg.com with esmtp (Exim 3.36 #1) id 18tSMP-000D52-00 for namedroppers@ops.ietf.org; Thu, 13 Mar 2003 05:03:01 -0800 Received: by chinook.rgy.netsol.com (Postfix, from userid 500) id AA1FE10FD12; Thu, 13 Mar 2003 07:52:03 -0500 (EST) Date: Thu, 13 Mar 2003 07:52:03 -0500 From: Matt Larson To: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN Message-ID: <20030313125203.GG24292@chinook.rgy.netsol.com> References: <5.1.1.6.2.20030312221746.022ed848@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.1.6.2.20030312221746.022ed848@localhost> User-Agent: Mutt/1.5.3i X-Spam-Status: No, hits=-0.7 required=5.0 tests=IN_REP_TO,OPT_IN,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MUTT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 12 Mar 2003, ?lafur Gudmundsson/DNSEXT co-chair wrote: > This starts a two week working group last call, > concluding on March 28'th 2003. > > Q: Is there consensus by the WG, to allow Opt-in zones? > > The document to base this discussion on is > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-opt-in-05.txt > > Please send explicit statements of support or disagreement. I support Opt-In. Matt -- to unsubscribe send a message to namedroppers-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 13 08:16:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29485 for ; Thu, 13 Mar 2003 08:16:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tSKY-000D1u-00 for namedroppers-data@psg.com; Thu, 13 Mar 2003 05:01:06 -0800 Received: from h87.s239.netsol.com ([216.168.239.87] helo=chinook.rgy.netsol.com) by psg.com with esmtp (Exim 3.36 #1) id 18tSKN-000D1J-00 for namedroppers@ops.ietf.org; Thu, 13 Mar 2003 05:00:55 -0800 Received: by chinook.rgy.netsol.com (Postfix, from userid 500) id D6BD710FD12; Thu, 13 Mar 2003 07:49:56 -0500 (EST) Date: Thu, 13 Mar 2003 07:49:56 -0500 From: Matt Larson To: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: Key-Signing Key (KSK) Flag Message-ID: <20030313124956.GF24292@chinook.rgy.netsol.com> References: <5.1.1.6.2.20030312221126.01629e78@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.1.6.2.20030312221126.01629e78@localhost> User-Agent: Mutt/1.5.3i X-Spam-Status: No, hits=-3.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 12 Mar 2003, ?lafur Gudmundsson/DNSEXT co-chair wrote: > This starts a 2 week Working Group last call on this document, > concluding on March 28'th 2003. > > This document defines a new KEY RR flag that is used to identify keys that > are used to sign KEY RRset. The flag is not used by the DNSSEC resolution > process. The main purpose of this flag is to ease administration of DNSSEC > signed zones. I support this document. Matt -- to unsubscribe send a message to namedroppers-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 13 09:16:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01220 for ; Thu, 13 Mar 2003 09:16:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tTOh-000GIE-00 for namedroppers-data@psg.com; Thu, 13 Mar 2003 06:09:27 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #1) id 18tTOd-000GHm-00 for namedroppers@ops.ietf.org; Thu, 13 Mar 2003 06:09:23 -0800 Received: from ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.8/8.11.6) with ESMTP id h2DE9F12026000; Thu, 13 Mar 2003 15:09:15 +0100 Message-Id: <200303131409.h2DE9F12026000@birch.ripe.net> To: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN In-Reply-To: Message from =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair of "Wed, 12 Mar 2003 23:01:05 EST." <5.1.1.6.2.20030312221746.022ed848@localhost> Date: Thu, 13 Mar 2003 15:09:14 +0100 From: Olaf Kolkman X-Spam-Status: No, hits=1.5 required=5.0 tests=IN_REP_TO,OPT_IN,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk * Q: Is there consensus by the WG, to allow Opt-in zones? Although I would advise against its use in all other cases but the huge zones out there, I do support the draft. --Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 13 09:29:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01703 for ; Thu, 13 Mar 2003 09:29:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tTad-000Gwb-00 for namedroppers-data@psg.com; Thu, 13 Mar 2003 06:21:47 -0800 Received: from mclmx.mail.saic.com ([149.8.64.10]) by psg.com with esmtp (Exim 3.36 #1) id 18tTab-000Gvn-00 for namedroppers@ops.ietf.org; Thu, 13 Mar 2003 06:21:45 -0800 Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for namedroppers@ops.ietf.org; Thu, 13 Mar 2003 09:20:21 -0500 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.2.17) with SMTP id M2003031309212520963 ; Thu, 13 Mar 2003 09:21:25 -0500 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Mar 2003 09:23:33 -0500 Message-Id: <4E25ECBBC03F874CBAD03399254ADFDE104AE5@US-Columbia-CIST.mail.saic.com> From: "Loomis, Rip" To: "'derek@ihtfp.com'" , "'sra@hactrn.net'" Cc: namedroppers@ops.ietf.org Subject: RE: DNSEXT WGLC: DNS Threats Date: Thu, 13 Mar 2003 09:21:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.7 required=5.0 tests=EXCHANGE_SERVER,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Derek/Rob-- Really an excellent document overall. I support this document but I have a few minor editorial nits. Perhaps I'm being anal- retentive, so do with these what ye will. Last paragraph in section 1 should read "...and refers to TKEY and..." for proper subject/verb agreement (earlier in that sentence, you say "this note uses".) Near the bottom of section 2.1 I think you only need one "all" in - Perform all all of the DNSSEC signature checking on its own Other than those _incredibly_ minor points, the document looks great and is now required reading for the folks here working on DNS Security. For the WG Chairs: I support the publication of this document as an Informational RFC. -- Rip Loomis Senior Systems Security Engineer SAIC Enterprise Security Solutions Group www.saic.com/securebiz Center for Information Security Technology www.cist-east.saic.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 13 10:14:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04675 for ; Thu, 13 Mar 2003 10:14:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tUJ8-000J4D-00 for namedroppers-data@psg.com; Thu, 13 Mar 2003 07:07:46 -0800 Received: from h87.s239.netsol.com ([216.168.239.87] helo=localhost.localdomain) by psg.com with esmtp (Exim 3.36 #1) id 18tUJ5-000J3w-00 for namedroppers@ops.ietf.org; Thu, 13 Mar 2003 07:07:43 -0800 Received: (from markk@localhost) by localhost.localdomain (8.11.6/8.11.6) id h2DF7Xp02433; Thu, 13 Mar 2003 10:07:33 -0500 Date: Thu, 13 Mar 2003 10:07:33 -0500 From: Mark Kosters To: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN Message-ID: <20030313150733.GA1653@verisignlabs.com> References: <5.1.1.6.2.20030312221746.022ed848@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5.1.1.6.2.20030312221746.022ed848@localhost> User-Agent: Mutt/1.3.25i X-Spam-Status: No, hits=-1.0 required=5.0 tests=IN_REP_TO,OPT_IN,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit On Wed, Mar 12, 2003 at 11:01:05PM -0500, Ólafur Gudmundsson/DNSEXT co-chair wrote: > > This starts a two week working group last call, > concluding on March 28'th 2003. > > Q: Is there consensus by the WG, to allow Opt-in zones? > > The document to base this discussion on is > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-opt-in-05.txt > > Please send explicit statements of support or disagreement. I support opt-in. Mark -- Mark Kosters markk@verisignlabs.com Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 13 10:43:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06032 for ; Thu, 13 Mar 2003 10:43:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tUhB-000K9p-00 for namedroppers-data@psg.com; Thu, 13 Mar 2003 07:32:37 -0800 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 18tUh5-000K9Y-00 for namedroppers@ops.ietf.org; Thu, 13 Mar 2003 07:32:31 -0800 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id KAA05412; Thu, 13 Mar 2003 10:32:27 -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 KAA01331; Thu, 13 Mar 2003 10:32:24 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h2DFWNV3013411; Thu, 13 Mar 2003 10:32:23 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id KAA20328; Thu, 13 Mar 2003 10:32:23 -0500 (EST) To: "Loomis, Rip" Cc: "'sra@hactrn.net'" , namedroppers@ops.ietf.org From: Derek Atkins Subject: Re: DNSEXT WGLC: DNS Threats References: <4E25ECBBC03F874CBAD03399254ADFDE104AE5@US-Columbia-CIST.mail.saic.com> Date: 13 Mar 2003 10:32:23 -0500 In-Reply-To: <4E25ECBBC03F874CBAD03399254ADFDE104AE5@US-Columbia-CIST.mail.saic.com> Message-ID: Lines: 37 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-1.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,RCVD_IN_RELAYS_ORDB_ORG,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_GNUS_UA,X_OSIRU_OPEN_RELAY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I have no objection to these changes. Rob, do you have the editing token? (I don't think I have a current copy of the source). -derek "Loomis, Rip" writes: > Derek/Rob-- > > Really an excellent document overall. I support this document > but I have a few minor editorial nits. Perhaps I'm being anal- > retentive, so do with these what ye will. > > Last paragraph in section 1 should read "...and refers to TKEY and..." > for proper subject/verb agreement (earlier in that sentence, you > say "this note uses".) > > Near the bottom of section 2.1 I think you only need one "all" in > - Perform all all of the DNSSEC signature checking on its own > > Other than those _incredibly_ minor points, the document looks > great and is now required reading for the folks here working on > DNS Security. > > For the WG Chairs: > I support the publication of this document as an Informational RFC. > > -- > Rip Loomis Senior Systems Security Engineer > SAIC Enterprise Security Solutions Group www.saic.com/securebiz > Center for Information Security Technology www.cist-east.saic.com > -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 13 10:57:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06571 for ; Thu, 13 Mar 2003 10:57:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tUvW-000Kqe-00 for namedroppers-data@psg.com; Thu, 13 Mar 2003 07:47:26 -0800 Received: from pushme.nist.gov ([129.6.16.92] helo=postmark.nist.gov) by psg.com with esmtp (Exim 3.36 #1) id 18tUvP-000KqL-00 for namedroppers@ops.ietf.org; Thu, 13 Mar 2003 07:47:19 -0800 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h2DFl7CZ016427 for ; Thu, 13 Mar 2003 10:47:07 -0500 (EST) Message-ID: <007701c2e977$cdc169a0$b9370681@barnacle> From: "Scott Rose" To: References: <5.1.1.6.2.20030312221746.022ed848@localhost> Subject: Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN Date: Thu, 13 Mar 2003 10:47:08 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=1.6 required=5.0 tests=OPT_IN,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03, TO_BE_REMOVED_REPLY,USER_AGENT_OE version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit As per Olaf's comment - I support the draft with the last round of comments. And wish there was a good way of recommending OPT-IN for "huge zones" only. However, I know what makes a zone "huge" would be a rathole debate. Scott ----- Original Message ----- From: "Ólafur Gudmundsson/DNSEXT co-chair" To: Sent: Wednesday, March 12, 2003 11:01 PM Subject: DNSEXT WGLC: To OPT_IN or not to OPT-IN > > This starts a two week working group last call, > concluding on March 28'th 2003. > > Q: Is there consensus by the WG, to allow Opt-in zones? > > The document to base this discussion on is > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-opt-in-05.txt > > Please send explicit statements of support or disagreement. > > Note this is not a last call on the technical issues in the document, > if any such issues exist they should be assumed to be fixable and not > affect the judgment on the question above. > > The document is on the standards track. If this document is advanced by > the working group, it will be integrated into the DNSSECbis documents. > > Silence during this working group last call will be taken as support > for opt-in based on comments made during the technical last call on > OPT-IN. > > Olafur > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 13 11:50:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08527 for ; Thu, 13 Mar 2003 11:50:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tVhc-000N9d-00 for namedroppers-data@psg.com; Thu, 13 Mar 2003 08:37:08 -0800 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 18tVhV-000N8n-00 for namedroppers@ops.ietf.org; Thu, 13 Mar 2003 08:37:03 -0800 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id CC77A18ED; Thu, 13 Mar 2003 11:36:17 -0500 (EST) Date: Thu, 13 Mar 2003 11:36:17 -0500 From: Rob Austein To: Derek Atkins Cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: DNS Threats In-Reply-To: References: <4E25ECBBC03F874CBAD03399254ADFDE104AE5@US-Columbia-CIST.mail.saic.com> User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030313163617.CC77A18ED@thrintun.hactrn.net> X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 13 Mar 2003 10:32:23 -0500, Derek Atkins wrote: > > I have no objection to these changes. Rob, do you have the editing > token? (I don't think I have a current copy of the source). I have the source, I have the editing token, I have no objection to the changes, and, oh yeah, I support the draft :). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 13 12:07:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08901 for ; Thu, 13 Mar 2003 12:07:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tVyN-000O21-00 for namedroppers-data@psg.com; Thu, 13 Mar 2003 08:54:27 -0800 Received: from numenor.qualcomm.com ([129.46.51.58]) by psg.com with esmtp (Exim 3.36 #1) id 18tVyL-000O1R-00 for namedroppers@ops.ietf.org; Thu, 13 Mar 2003 08:54:25 -0800 Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by numenor.qualcomm.com (8.12.8/8.12.5/1.0) with ESMTP id h2DGs3Kn004072; Thu, 13 Mar 2003 08:54:04 -0800 (PST) Received: from mage.qualcomm.com (localhost [127.0.0.1]) by mage.qualcomm.com (8.12.8/8.12.3/1.0) with ESMTP id h2DGs1cj017703; Thu, 13 Mar 2003 08:54:02 -0800 (PST) Received: (from hardie@localhost) by mage.qualcomm.com (8.12.8/8.12.1/Submit) id h2DGs1QC017698; Thu, 13 Mar 2003 08:54:01 -0800 (PST) From: Ted Hardie Message-Id: <200303131654.h2DGs1QC017698@mage.qualcomm.com> Subject: Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN To: ogud@ogud.com (=?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair) Date: Thu, 13 Mar 2003 08:54:01 -0800 (PST) Cc: namedroppers@ops.ietf.org In-Reply-To: <5.1.1.6.2.20030312221746.022ed848@localhost> from "=?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair" at Mar 12, 2003 11:01:05 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.8 required=5.0 tests=IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02, TO_BE_REMOVED_REPLY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I oppose OPT-IN going forward as a proposed standard. It is very clear that there are some engineering trade-offs here, and I'm very glad that we've taken the time to explore them. In this case, I would summarize a bunch of trade offs by saying "ease of zone management for large zones" vs. "complexity (both of code path, and, more generally, the understanding of the states DNSSEC will imply)". In a case where there are trade-offs of this type, I think it is important to look both at where we are today and where we are likely to be later. My take is that the deployment of DS for large zones today _is_ a problem, but a tractable one given today's hardware and software either present or far along the pipeline; more importantly, I believe it will only get easier as the maturity of those products increase. The "complexity" side of the equation doesn't seem to me to get much better as time goes on. Based on that, I believe we would be making the wrong choice to advance OPT-IN; if we allow it, it will be part of the standard for a very long time, and we will be living with its complexity well past the time horizon that the problems it addresses have ceased to be an issue. regards, Ted Hardie > This starts a two week working group last call, > concluding on March 28'th 2003. > > Q: Is there consensus by the WG, to allow Opt-in zones? > > The document to base this discussion on is > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-opt-in-05.txt > > Please send explicit statements of support or disagreement. > > Note this is not a last call on the technical issues in the document, > if any such issues exist they should be assumed to be fixable and not > affect the judgment on the question above. > > The document is on the standards track. If this document is advanced by > the working group, it will be integrated into the DNSSECbis documents. > > Silence during this working group last call will be taken as support > for opt-in based on comments made during the technical last call on > OPT-IN. > > Olafur > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 13 12:26:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09565 for ; Thu, 13 Mar 2003 12:26:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tWLO-000P7C-00 for namedroppers-data@psg.com; Thu, 13 Mar 2003 09:18:14 -0800 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.36 #1) id 18tWLL-000P6g-00 for namedroppers@ops.ietf.org; Thu, 13 Mar 2003 09:18:11 -0800 Received: from isi.edu (wireless202.east.isi.edu [65.123.202.202]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id h2DHI4v08744; Thu, 13 Mar 2003 09:18:04 -0800 (PST) Date: Thu, 13 Mar 2003 12:18:04 -0500 Subject: Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Daniel Massey , To: namedroppers@ops.ietf.org From: Daniel Massey In-Reply-To: <007701c2e977$cdc169a0$b9370681@barnacle> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.7 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thursday, March 13, 2003, at 10:47 AM, Scott Rose wrote: > As per Olaf's comment - I support the draft with the last round of > comments. > And wish there was a good way of recommending OPT-IN for "huge zones" > only. > However, I know what makes a zone "huge" would be a rathole debate. > > Scott > same as above. support for the draft with the last round of comments. 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 Thu Mar 13 13:15:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11316 for ; Thu, 13 Mar 2003 13:15:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tX8s-0001qN-00 for namedroppers-data@psg.com; Thu, 13 Mar 2003 10:09:22 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18tX8p-0001q4-00; Thu, 13 Mar 2003 10:09:20 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18tX8o-0000EF-00; Thu, 13 Mar 2003 13:09:18 -0500 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 13 Mar 2003 13:09:17 -0500 To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN References: <5.1.1.6.2.20030312221746.022ed848@localhost> <20030313060949.B354D379E40@as.vix.com> Message-Id: X-Spam-Status: No, hits=1.8 required=5.0 tests=OPT_IN,REFERENCES,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > if organizational support matters in the ietf it doesn't. sorry to do this publicly, but we need to be very clear on this. such assertions are inappropriate and damage one's position. randy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 13 13:53:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12623 for ; Thu, 13 Mar 2003 13:53:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tXhy-0003jx-00 for namedroppers-data@psg.com; Thu, 13 Mar 2003 10:45:38 -0800 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 18tXhw-0003jk-00 for namedroppers@ops.ietf.org; Thu, 13 Mar 2003 10:45:36 -0800 Received: from nominum.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id A56461B20E5 for ; Thu, 13 Mar 2003 11:54:37 -0600 (CST) Date: Thu, 13 Mar 2003 12:45:33 -0600 Subject: Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Ted Lemon To: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: <20030313060949.B354D379E40@as.vix.com> Message-Id: X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,OPT_IN,SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I support opt-in. We've been playing around with DNSSEC for a long time, and we will still be playing with it (or have abandoned it) ten years from now if we don't adopt opt-in. -- to unsubscribe send a message to namedroppers-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 13 14:03:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12988 for ; Thu, 13 Mar 2003 14:03:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tXt0-0004aq-00 for namedroppers-data@psg.com; Thu, 13 Mar 2003 10:57:02 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 18tXsx-0004a5-00 for namedroppers@ops.ietf.org; Thu, 13 Mar 2003 10:56:59 -0800 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id A09A0137F06; Thu, 13 Mar 2003 10:56:58 -0800 (PST) Date: Thu, 13 Mar 2003 10:56:58 -0800 Subject: Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: namedroppers@ops.ietf.org To: Daniel Massey From: David Conrad In-Reply-To: Message-Id: <916F54A8-5585-11D7-8B65-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-1.1 required=5.0 tests=IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Sigh. I've said I don't care what decision is made as long as a decision is made and I still feel that way, however this is a bit over the top. So, let me get this straight: On Thursday, March 13, 2003, at 06:09 AM, Olaf Kolkman wrote: > Although I would advise against its use in all other cases but the huge > zones out there, I do support the draft. On Thursday, March 13, 2003, at 10:47 AM, Scott Rose wrote: > As per Olaf's comment - I support the draft with the last round of > comments. > And wish there was a good way of recommending OPT-IN for "huge zones" > only. > However, I know what makes a zone "huge" would be a rathole debate. On Thursday, March 13, 2003, at 09:18 AM, Daniel Massey wrote: > same as above. support for the draft with the last round of comments. You all appear to be arguing that we should yet again modify DNSSEC, increasing complexity and changing the security model, to include functionality to address a temporary transition issue that only a handful of folks will ever need and that many who have looked at the problem believe is solvable in other arguably better ways? If you want to support pushing opt-in forward, I believe it should be done so with the belief that it is necessary, generally useful, and improves the protocol, not a hack for a small set of outliers or "well, it doesn't look like it will do any harm". Rgds, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 13 14:24:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13845 for ; Thu, 13 Mar 2003 14:24:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tYDR-0005pX-00 for namedroppers-data@psg.com; Thu, 13 Mar 2003 11:18:09 -0800 Received: from spratly.wl.nominum.com ([128.177.195.135]) by psg.com with esmtp (Exim 3.36 #1) id 18tYDO-0005pK-00 for namedroppers@ops.ietf.org; Thu, 13 Mar 2003 11:18:06 -0800 Received: from spratly.wl.nominum.com (spratly [127.0.0.1]) by spratly.wl.nominum.com (8.12.8/8.12.8) with ESMTP id h2DJI3dE006199 for ; Thu, 13 Mar 2003 11:18:03 -0800 Received: from localhost (bwelling@localhost) by spratly.wl.nominum.com (8.12.8/8.12.8/Submit) with ESMTP id h2DJI3DV006196 for ; Thu, 13 Mar 2003 11:18:03 -0800 X-Authentication-Warning: spratly.wl.nominum.com: bwelling owned process doing -bs Date: Thu, 13 Mar 2003 11:18:03 -0800 (PST) From: Brian Wellington X-X-Sender: bwelling@spratly.wl.nominum.com To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN In-Reply-To: <916F54A8-5585-11D7-8B65-000393DB42B2@nominum.com> Message-ID: References: <916F54A8-5585-11D7-8B65-000393DB42B2@nominum.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT, REFERENCES,SPAM_PHRASE_00_01,USER_AGENT_PINE,X_AUTH_WARNING version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 13 Mar 2003, David Conrad wrote: > You all appear to be arguing that we should yet again modify DNSSEC, > increasing complexity and changing the security model, to include > functionality to address a temporary transition issue that only a > handful of folks will ever need and that many who have looked at the > problem believe is solvable in other arguably better ways? I completely agree. Furthermore, the main argument for opt-in has historically been that full DNSSEC would require too many resources. Since this argument was originally used, probably 2 years ago, every conceivable resource has become both cheaper and faster, and the size of excessively large zones has more or less stayed the same. This means that even if it had been a good argument in the past, it's days are over. > If you want to support pushing opt-in forward, I believe it should be > done so with the belief that it is necessary, generally useful, and > improves the protocol, not a hack for a small set of outliers or "well, > it doesn't look like it will do any harm". Exactly. 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 13 15:12:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16707 for ; Thu, 13 Mar 2003 15:12:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tYqa-0008XC-00 for namedroppers-data@psg.com; Thu, 13 Mar 2003 11:58:36 -0800 Received: from h87.s239.netsol.com ([216.168.239.87] helo=localhost.localdomain) by psg.com with esmtp (Exim 3.36 #1) id 18tYqX-0008Wz-00 for namedroppers@ops.ietf.org; Thu, 13 Mar 2003 11:58:33 -0800 Received: (from markk@localhost) by localhost.localdomain (8.11.6/8.11.6) id h2DJwMQ04333; Thu, 13 Mar 2003 14:58:22 -0500 Date: Thu, 13 Mar 2003 14:58:22 -0500 From: Mark Kosters To: Ted Hardie Cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN Message-ID: <20030313195822.GS1653@verisignlabs.com> References: <5.1.1.6.2.20030312221746.022ed848@localhost> <200303131654.h2DGs1QC017698@mage.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200303131654.h2DGs1QC017698@mage.qualcomm.com> User-Agent: Mutt/1.3.25i X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_01_02,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I would prefer to see some hard numbers before I would agree with this conjecture. There is at least one recursive implementation of opt-in that has been completed. And we have had some experience that it interoperates correctly with at least two authoritative opt-in servers. So with this knowledge of actual running code, perhaps we should ask ISC and/or Nominum to comment on how much more "complex" it is to add opt-in support. Mark On Thu, Mar 13, 2003 at 08:54:01AM -0800, Ted Hardie wrote: > I oppose OPT-IN going forward as a proposed standard. > > It is very clear that there are some engineering trade-offs > here, and I'm very glad that we've taken the time to explore > them. In this case, I would summarize a bunch of trade offs > by saying "ease of zone management for large zones" vs. > "complexity (both of code path, and, more generally, > the understanding of the states DNSSEC will imply)". > In a case where there are trade-offs of this type, I > think it is important to look both at where we are today > and where we are likely to be later. My take is that > the deployment of DS for large zones today _is_ a > problem, but a tractable one given today's hardware and software > either present or far along the pipeline; more importantly, > I believe it will only get easier as the maturity of > those products increase. The "complexity" side of the equation > doesn't seem to me to get much better as time goes on. > > Based on that, I believe we would be making the wrong choice > to advance OPT-IN; if we allow it, it will be part of > the standard for a very long time, and we will be living > with its complexity well past the time horizon that the problems > it addresses have ceased to be an issue. > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 13 16:33:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19991 for ; Thu, 13 Mar 2003 16:33:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ta9s-000Evh-00 for namedroppers-data@psg.com; Thu, 13 Mar 2003 13:22:36 -0800 Received: from [2001:4f8:3:bb:2e0:81ff:fe23:7b5a] (helo=as.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 18ta9m-000Ev3-00 for namedroppers@ops.ietf.org; Thu, 13 Mar 2003 13:22:30 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 0D664379E40 for ; Thu, 13 Mar 2003 21:22:17 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN In-Reply-To: Message from Ted Hardie of "Thu, 13 Mar 2003 08:54:01 PST." <200303131654.h2DGs1QC017698@mage.qualcomm.com> X-Mailer: MH-E 7.2; nmh 1.0.4; GNU Emacs 21.2.1 Date: Thu, 13 Mar 2003 21:22:17 +0000 Message-Id: <20030313212217.0D664379E40@as.vix.com> X-Spam-Status: No, hits=0.7 required=5.0 tests=IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I oppose OPT-IN going forward as a proposed standard. > > It is very clear that there are some engineering trade-offs here, ... that's not as clear to me as it seems to be to you. opt-in adds another knob for zone managers, some of whom will twist it for engineering reasons (such as difficulty in signing and publishing large zones with current technology) but some of whom will twist it for non-engineering reasons (such as a desire to limit the public exposure of complete NXT chains, either for business or privacy reasons.) > Based on that, I believe we would be making the wrong choice to > advance OPT-IN; if we allow it, it will be part of the standard for a > very long time, and we will be living with its complexity well past > the time horizon that the problems it addresses have ceased to be an > issue. because there are reasons for the knob which existing zone managers consider valid, some of which are engineering related and of those some appear to be temporary, but others of which are not engineering related, i believe that the tradeoff is between complexity and autonomy, and that autonomy has to win since the complexity has already been shown to be quite manageable (witness various recent workshops and bind9 snapshots.) it is not up to us as protocol developers to tell zone managers how they ought to "run their businesses." that would be paternalism at its offensive worst, worse even than the "restrict key" silliness. -- to unsubscribe send a message to namedroppers-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 13 16:35:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20043 for ; Thu, 13 Mar 2003 16:35:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ta9i-000EvM-00 for namedroppers-data@psg.com; Thu, 13 Mar 2003 13:22:26 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18ta9d-000Ev8-00 for namedroppers@ops.ietf.org; Thu, 13 Mar 2003 13:22:23 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18ta9c-0000MC-00 for namedroppers@ops.ietf.org; Thu, 13 Mar 2003 16:22:20 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Message-Id: <200303131352.40522.davidb@verisignlabs.com> From: David Blacka , (by way of David Blacka ) Subject: Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN Date: Thu, 13 Mar 2003 13:52:40 -0500 To: namedroppers@ops.ietf.org X-Spam-Status: No, hits=2.1 required=5.0 tests=OPT_IN,RESENT_TO,SPAM_PHRASE_02_03 version=2.43 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA20043 [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] On Wednesday 12 March 2003 11:01 pm, Ólafur Gudmundsson/DNSEXT co-chair wrote: > This starts a two week working group last call, > concluding on March 28'th 2003. > > Q: Is there consensus by the WG, to allow Opt-in zones? > > The document to base this discussion on is > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-opt-in-05.txt > > Please send explicit statements of support or disagreement. I support Opt-In. -- David Blacka Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 13 16:46:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20454 for ; Thu, 13 Mar 2003 16:46:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18taIU-000Flm-00 for namedroppers-data@psg.com; Thu, 13 Mar 2003 13:31:30 -0800 Received: from [2001:4f8:3:bb:2e0:81ff:fe23:7b5a] (helo=as.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 18taIR-000FlR-00 for namedroppers@ops.ietf.org; Thu, 13 Mar 2003 13:31:28 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id B2643379E40 for ; Thu, 13 Mar 2003 21:31:12 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN In-Reply-To: Message from Mark Kosters of "Thu, 13 Mar 2003 14:58:22 EST." <20030313195822.GS1653@verisignlabs.com> X-Mailer: MH-E 7.2; nmh 1.0.4; GNU Emacs 21.2.1 Date: Thu, 13 Mar 2003 21:31:12 +0000 Message-Id: <20030313213112.B2643379E40@as.vix.com> X-Spam-Status: No, hits=0.4 required=5.0 tests=IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > There is at least one recursive implementation of opt-in that has been > completed. And we have had some experience that it interoperates > correctly with at least two authoritative opt-in servers. So with this > knowledge of actual running code, perhaps we should ask ISC and/or > Nominum to comment on how much more "complex" it is to add opt-in > support. > > Mark the complexity arguments are a tempest in a teapot, as silly as verisign's whining about memory footprints and bandwidth requirements. any argument based on either basis is just pure FUD. this is a tradeoff between complexity and autonomy. the complexity part has been shown to be manageable; opt-in validators exist and have been tested by people other than their authors. let's move on. -- to unsubscribe send a message to namedroppers-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 13 17:13:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21549 for ; Thu, 13 Mar 2003 17:13:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18taog-000ITR-00 for namedroppers-data@psg.com; Thu, 13 Mar 2003 14:04:46 -0800 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.36 #1) id 18taoc-000ISx-00 for namedroppers@ops.ietf.org; Thu, 13 Mar 2003 14:04:42 -0800 Received: from isi.edu (wireless210.east.isi.edu [65.123.202.210]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id h2DM4av16118; Thu, 13 Mar 2003 14:04:36 -0800 (PST) Date: Thu, 13 Mar 2003 17:04:35 -0500 Subject: Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Daniel Massey , namedroppers@ops.ietf.org To: David Conrad From: Daniel Massey In-Reply-To: <916F54A8-5585-11D7-8B65-000393DB42B2@nominum.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.7 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thursday, March 13, 2003, at 01:56 PM, David Conrad wrote: > Sigh. I've said I don't care what decision is made as long as a > decision is made and I still feel that way, yes, there are no new technical issues being raised. we need to make a decision. > however this is a bit over the top. > No, to me it reflects that is trade-off rather than a clearly right or clearly wrong issue. we are long past the time we should have decided on this trade-off. as you suggest below, there may be "other arguably better ways" to address this "temporary transition issue". But a decade from now, there will still be "other arguably better ways" that are better in some ways and worse in others. I'm also not sure what is really "temporary", but in any event, this is a permanent change to the protocol. It adds some complexity and that is bad, but the draft authors have convinced me much of the complexity I initially attributed to opt-in is actually inherent in DNSSEC. I don't see anything more that authors could present and I think all the issues are on the table. At some point, it has to come down to a decision. my decision is I support the draft. I can live with whatever the working group decides as long it decides. Dan > So, let me get this straight: > > On Thursday, March 13, 2003, at 06:09 AM, Olaf Kolkman wrote: >> Although I would advise against its use in all other cases but the >> huge >> zones out there, I do support the draft. > > On Thursday, March 13, 2003, at 10:47 AM, Scott Rose wrote: >> As per Olaf's comment - I support the draft with the last round of >> comments. >> And wish there was a good way of recommending OPT-IN for "huge zones" >> only. >> However, I know what makes a zone "huge" would be a rathole debate. > > On Thursday, March 13, 2003, at 09:18 AM, Daniel Massey wrote: >> same as above. support for the draft with the last round of comments. > > You all appear to be arguing that we should yet again modify DNSSEC, > increasing complexity and changing the security model, to include > functionality to address a temporary transition issue that only a > handful of folks will ever need and that many who have looked at the > problem believe is solvable in other arguably better ways? > > If you want to support pushing opt-in forward, I believe it should be > done so with the belief that it is necessary, generally useful, and > improves the protocol, not a hack for a small set of outliers or > "well, it doesn't look like it will do any harm". > > Rgds, > -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 13 17:35:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22205 for ; Thu, 13 Mar 2003 17:35:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tbCb-000KWa-00 for namedroppers-data@psg.com; Thu, 13 Mar 2003 14:29:29 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18tbCZ-000KW5-00; Thu, 13 Mar 2003 14:29:27 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18tbCX-0000Nk-00; Thu, 13 Mar 2003 17:29:25 -0500 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 13 Mar 2003 17:29:24 -0500 To: Mark Kosters Cc: Ted Hardie , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN References: <5.1.1.6.2.20030312221746.022ed848@localhost> <200303131654.h2DGs1QC017698@mage.qualcomm.com> <20030313195822.GS1653@verisignlabs.com> Message-Id: X-Spam-Status: No, hits=1.0 required=5.0 tests=OPT_IN,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03 version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I would prefer to see some hard numbers before I would agree with > this conjecture. just a sec. years ago, we asked you for hard numbers on the problem of large zones. what you provided did not make your point. you are asking for a change to acommodate your needs. the onus is on you to justify that need, not vice versa. randy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 13 18:26:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25090 for ; Thu, 13 Mar 2003 18:26:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tbz0-000Oyq-00 for namedroppers-data@psg.com; Thu, 13 Mar 2003 15:19:30 -0800 Received: from h87.s239.netsol.com ([216.168.239.87] helo=localhost.localdomain) by psg.com with esmtp (Exim 3.36 #1) id 18tbyy-000OyZ-00 for namedroppers@ops.ietf.org; Thu, 13 Mar 2003 15:19:28 -0800 Received: (from markk@localhost) by localhost.localdomain (8.11.6/8.11.6) id h2DNJL305495; Thu, 13 Mar 2003 18:19:21 -0500 Date: Thu, 13 Mar 2003 18:19:21 -0500 From: Mark Kosters To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN Message-ID: <20030313231921.GC1653@verisignlabs.com> References: <20030313195822.GS1653@verisignlabs.com> <20030313213112.B2643379E40@as.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030313213112.B2643379E40@as.vix.com> User-Agent: Mutt/1.3.25i X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MUTT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, Mar 13, 2003 at 09:31:12PM +0000, Paul Vixie wrote: > the complexity arguments are a tempest in a teapot, as silly as verisign's > whining about memory footprints and bandwidth requirements. any argument > based on either basis is just pure FUD. I agree that the complexity args on one side and additional operational requirements on the other can be colored by the type of glasses worn. > this is a tradeoff between complexity and autonomy. the complexity part > has been shown to be manageable; opt-in validators exist and have been > tested by people other than their authors. Is this a reasonable answer for Ted? Mark -- Mark Kosters markk@verisignlabs.com Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 13 18:57:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25817 for ; Thu, 13 Mar 2003 18:57:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tcQn-0001b3-00 for namedroppers-data@psg.com; Thu, 13 Mar 2003 15:48:13 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 18tcQk-0001ao-00 for namedroppers@ops.ietf.org; Thu, 13 Mar 2003 15:48:10 -0800 Received: by shell.nominum.com (Postfix, from userid 1411) id EFD0B137F07; Thu, 13 Mar 2003 15:48:09 -0800 (PST) To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN References: <20030313213112.B2643379E40@as.vix.com> From: Bob Halley Date: 13 Mar 2003 15:48:09 -0800 In-Reply-To: <20030313213112.B2643379E40@as.vix.com> Message-ID: Lines: 25 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-2.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_GNUS_UA version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul Vixie writes: > the complexity arguments are a tempest in a teapot, as silly as verisign's > whining about memory footprints and bandwidth requirements. any argument > based on either basis is just pure FUD. I don't see how either can be written of as "pure FUD". The OPT-IN draft describes itself as a way to make a cost-benefit adjustment for certain classes of zones. It does not justify itself on the grounds of zone administrators needing more knobs. If the resource and operational issues are significant, then they are fair game and not FUD. If they are not, then why do we have OPT-IN at all? Likewise, complexity is a fair argument that isn't just FUD. Just because implementations can, and have, been made does not mean that we should impose the complexity of OPT-IN on every subsequent implementation, or on the system as a whole. We also had multiple implementations that did A6 records and bitstring labels, yet that technology is no longer progressing (and rightfully so!). Also, because this is an area involving security, any increases in complexity of validation must be taken seriously. Complexity is often the enemy of good security, making implementation errors more likely, and more difficult to find. /Bob -- to unsubscribe send a message to namedroppers-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 13 20:45:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28724 for ; Thu, 13 Mar 2003 20:45:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18te7m-000BWU-00 for namedroppers-data@psg.com; Thu, 13 Mar 2003 17:36:42 -0800 Received: from [2001:4f8:3:e:208:74ff:fe9f:eeae] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 18te7k-000BVr-00 for namedroppers@ops.ietf.org; Thu, 13 Mar 2003 17:36:40 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.8/8.12.7) with ESMTP id h2E1a5MC006264; Fri, 14 Mar 2003 12:36:05 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200303140136.h2E1a5MC006264@drugs.dv.isc.org> To: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: DNSEXT WGLC: Key-Signing Key (KSK) Flag In-reply-to: Your message of "Wed, 12 Mar 2003 22:59:30 CDT." <5.1.1.6.2.20030312221126.01629e78@localhost> Date: Fri, 14 Mar 2003 12:36:05 +1100 X-Spam-Status: No, hits=0.9 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, TO_BE_REMOVED_REPLY version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > This starts a 2 week Working Group last call on this document, > concluding on March 28'th 2003. > > This document defines a new KEY RR flag that is used to identify keys that > are used to sign KEY RRset. The flag is not used by the DNSSEC resolution > process. The main purpose of this flag is to ease administration of DNSSEC > signed zones. > > This document is on standards track and is available via following URL: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag- > 06.txt > > > Silence on this document during the last call will interpreted by chairs > as instruction to drop this document. > > Olafur As currently specified this is going to result in operational problems. We really need to specify key functionality at key creation time. This way signer and DS key generation can be well defined. I propose two bits: DSK (DS Key) ZSK (Zone Signing Key) I'm discussing this with Olaf face to face. Mark > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 13 20:46:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28738 for ; Thu, 13 Mar 2003 20:46:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18te8q-000BZF-00 for namedroppers-data@psg.com; Thu, 13 Mar 2003 17:37:48 -0800 Received: from ithilien.qualcomm.com ([129.46.51.59]) by psg.com with esmtp (Exim 3.36 #1) id 18te8k-000BYs-00 for namedroppers@ops.ietf.org; Thu, 13 Mar 2003 17:37:43 -0800 Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by ithilien.qualcomm.com (8.12.8/8.12.5/1.0) with ESMTP id h2E1belb015250; Thu, 13 Mar 2003 17:37:40 -0800 (PST) Received: from mage.qualcomm.com (localhost [127.0.0.1]) by mage.qualcomm.com (8.12.8/8.12.3/1.0) with ESMTP id h2E1bbcj007651; Thu, 13 Mar 2003 17:37:38 -0800 (PST) Received: (from hardie@localhost) by mage.qualcomm.com (8.12.8/8.12.1/Submit) id h2E1bbpQ007648; Thu, 13 Mar 2003 17:37:37 -0800 (PST) From: Ted Hardie Message-Id: <200303140137.h2E1bbpQ007648@mage.qualcomm.com> Subject: Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN To: paul@vix.com (Paul Vixie) Date: Thu, 13 Mar 2003 17:37:37 -0800 (PST) Cc: namedroppers@ops.ietf.org In-Reply-To: <20030313212217.0D664379E40@as.vix.com> from "Paul Vixie" at Mar 13, 2003 09:22:17 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.4 required=5.0 tests=IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie writes: > because there are reasons for the knob which existing zone managers > consider valid, some of which are engineering related and of those some > appear to be temporary, but others of which are not engineering related, > i believe that the tradeoff is between complexity and autonomy, and that > autonomy has to win since the complexity has already been shown to be > quite manageable (witness various recent workshops and bind9 snapshots.) > > it is not up to us as protocol developers to tell zone managers how they > ought to "run their businesses." that would be paternalism at its offensive > worst, worse even than the "restrict key" silliness. This point of view, that the OPT-IN mechanism is there primarily to provide a knob for zone managers to use in running their businesses, does not seem to me well laid out in the draft. If the justification is based on this, then I would say making clear which new knobs are needed to do what would be a very useful thing. This is not "paternalism", but a way of making clear to everyone what the benefit of a change is going to be. It's important for all of us to remember that zone managers are not the only ones concerned in the operation of the DNS; those who run recursive resolvers and manage applications relying on data stored in the DNS are concerned as well. This mechanism has implications for them, and considering those implications in the protocol design is appropriate. regards, Ted Hardie -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 13 20:49:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28843 for ; Thu, 13 Mar 2003 20:49:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18teG3-000CLv-00 for namedroppers-data@psg.com; Thu, 13 Mar 2003 17:45:15 -0800 Received: from numenor.qualcomm.com ([129.46.51.58]) by psg.com with esmtp (Exim 3.36 #1) id 18teFt-000CJG-00 for namedroppers@ops.ietf.org; Thu, 13 Mar 2003 17:45:05 -0800 Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by numenor.qualcomm.com (8.12.8/8.12.5/1.0) with ESMTP id h2E1j2Kn002649; Thu, 13 Mar 2003 17:45:02 -0800 (PST) Received: from mage.qualcomm.com (localhost [127.0.0.1]) by mage.qualcomm.com (8.12.8/8.12.3/1.0) with ESMTP id h2E1ixcj009858; Thu, 13 Mar 2003 17:45:00 -0800 (PST) Received: (from hardie@localhost) by mage.qualcomm.com (8.12.8/8.12.1/Submit) id h2E1ixYR009855; Thu, 13 Mar 2003 17:44:59 -0800 (PST) From: Ted Hardie Message-Id: <200303140144.h2E1ixYR009855@mage.qualcomm.com> Subject: Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN To: markk@verisignlabs.com (Mark Kosters) Date: Thu, 13 Mar 2003 17:44:59 -0800 (PST) Cc: paul@vix.com (Paul Vixie), namedroppers@ops.ietf.org In-Reply-To: <20030313231921.GC1653@verisignlabs.com> from "Mark Kosters" at Mar 13, 2003 06:19:21 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.7 required=5.0 tests=IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mark writes, quoting Paul Vixie: > > this is a tradeoff between complexity and autonomy. the complexity part > > has been shown to be manageable; opt-in validators exist and have been > > tested by people other than their authors. > > Is this a reasonable answer for Ted? > > Mark I was afraid when I tried to boil down two sets of trade-offs to a simple statement that I would boil it down too far. It seems I have, and I'm sorry. No, the existence proof of the code is not sufficient to prove that complexity isn't an issue. If the draft couldn't be implemented, we would have a different discussion. I have elsewhere answered Paul's comment on autonomy, regards, Ted -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 13 22:13:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00772 for ; Thu, 13 Mar 2003 22:13:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tfRD-000Ham-00 for namedroppers-data@psg.com; Thu, 13 Mar 2003 19:00:51 -0800 Received: from [2001:4f8:3:bb:2e0:81ff:fe23:7b5a] (helo=as.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 18tfRB-000HZv-00 for namedroppers@ops.ietf.org; Thu, 13 Mar 2003 19:00:49 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id DA9E2379E40 for ; Fri, 14 Mar 2003 03:00:35 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN In-Reply-To: Message from Ted Hardie of "Thu, 13 Mar 2003 17:37:37 PST." <200303140137.h2E1bbpQ007648@mage.qualcomm.com> X-Mailer: MH-E 7.2; nmh 1.0.4; GNU Emacs 21.2.1 Date: Fri, 14 Mar 2003 03:00:35 +0000 Message-Id: <20030314030035.DA9E2379E40@as.vix.com> X-Spam-Status: No, hits=0.4 required=5.0 tests=IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > This point of view, that the OPT-IN mechanism is there primarily to > provide a knob for zone managers to use in running their businesses, i don't think i said "primarily". here, let's look: > > it is not up to us as protocol developers to tell zone managers how > > they ought to "run their businesses." that would be paternalism at > > its offensive worst, worse even than the "restrict key" silliness. it's an aspect of what ought not be done, that's all. > does not seem to me well laid out in the draft. If the justification > is based on this, then I would say making clear which new knobs are > needed to do what would be a very useful thing. the justification is not based on this. however, some zone managers have said that they want this and have put the onus on the standards community to say why they can't have it. i don't think there's a reasonable basis for denying the request for this feature. dnssec is such a step upward in complexity and brittleness from basic dns, that the incremental complexity from opt-in is pretty much lost in the noise. > This is not "paternalism", but a way of making clear to everyone what > the benefit of a change is going to be. It's important for all of us > to remember that zone managers are not the only ones concerned in the > operation of the DNS; those who run recursive resolvers and manage > applications relying on data stored in the DNS are concerned as well. > This mechanism has implications for them, and considering those > implications in the protocol design is appropriate. i believe i have, since opt-in vs. not has been shown to be an early deployment issue, and early deployment is going to affect the quality of the "protocol experience" by recursive server operators and application managers more than either elegance or any real or imagined incremental difference in complexity. it is in other words far more likely that a given application manager or recursive server operator will avoid dnssec altogether than that they will face any noticable complexity penalty due to opt-in. -- to unsubscribe send a message to namedroppers-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 14 01:01:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04587 for ; Fri, 14 Mar 2003 01:01:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ti42-000Oc4-00 for namedroppers-data@psg.com; Thu, 13 Mar 2003 21:49:06 -0800 Received: from numenor.qualcomm.com ([129.46.51.58]) by psg.com with esmtp (Exim 3.36 #1) id 18ti3u-000Oba-00 for namedroppers@ops.ietf.org; Thu, 13 Mar 2003 21:48:58 -0800 Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by numenor.qualcomm.com (8.12.8/8.12.5/1.0) with ESMTP id h2E5mtKn009753; Thu, 13 Mar 2003 21:48:55 -0800 (PST) Received: from mage.qualcomm.com (localhost [127.0.0.1]) by mage.qualcomm.com (8.12.8/8.12.3/1.0) with ESMTP id h2E5mrcj025974; Thu, 13 Mar 2003 21:48:53 -0800 (PST) Received: (from hardie@localhost) by mage.qualcomm.com (8.12.8/8.12.1/Submit) id h2E5mqto025971; Thu, 13 Mar 2003 21:48:52 -0800 (PST) From: Ted Hardie Message-Id: <200303140548.h2E5mqto025971@mage.qualcomm.com> Subject: Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN To: paul@vix.com (Paul Vixie) Date: Thu, 13 Mar 2003 21:48:52 -0800 (PST) Cc: namedroppers@ops.ietf.org In-Reply-To: <20030314030035.DA9E2379E40@as.vix.com> from "Paul Vixie" at Mar 14, 2003 03:00:35 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.4 required=5.0 tests=IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul writes: > > This point of view, that the OPT-IN mechanism is there primarily to > > provide a knob for zone managers to use in running their businesses, > > i don't think i said "primarily". here, let's look: > > > > it is not up to us as protocol developers to tell zone managers how > > > they ought to "run their businesses." that would be paternalism at > > > its offensive worst, worse even than the "restrict key" silliness. > Point taken; you did not say "primarily". > it's an aspect of what ought not be done, that's all. > > > does not seem to me well laid out in the draft. If the justification > > is based on this, then I would say making clear which new knobs are > > needed to do what would be a very useful thing. > > the justification is not based on this. And we seem to agree that the draft does not make this argument. > however, some zone managers > have said that they want this and have put the onus on the standards > community to say why they can't have it. i don't think there's a > reasonable basis for denying the request for this feature. dnssec is > such a step upward in complexity and brittleness from basic dns, that > the incremental complexity from opt-in is pretty much lost in the noise. We disagree. You believe that the trade-off in value for this feature is worth the incremental complexity. I do not. The primary point made in favor of this approach has been that it will be easier to deploy for very large, flat zones. I do not disagree that it is problem. I believe, however, that the barriers that they face are smaller now and continue to recede. The complexity will not recede. You have made a second point that this provides a knob for zone managers. I believe that if that is even part of the reason for this approach, a clear statement of its value belongs in the draft, so that the community can better understand who this benefits (and what the knob will be turned for). As other messages in this thread have made clear, there are real costs to this approach. > it is in other words far more likely that a > given application manager or recursive server operator will avoid dnssec > altogether than that they will face any noticable complexity penalty due > to opt-in. It is moderately obvious that you and I see the protocol from different points of view, and I suppose that it is not surprising that we see the likely deployment curve differently as well. Rather than the debate the merits of either of our conjectures, let us leave it that deployment must be taken into account with the other factors, and let others put the emphasis on it that they think appropriate. regards, Ted Hardie -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 14 01:24:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05407 for ; Fri, 14 Mar 2003 01:24:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tiUr-00006v-00 for namedroppers-data@psg.com; Thu, 13 Mar 2003 22:16:49 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 18tiUo-00006j-00 for namedroppers@ops.ietf.org; Thu, 13 Mar 2003 22:16:46 -0800 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 1AC68137F06; Thu, 13 Mar 2003 22:16:45 -0800 (PST) Date: Thu, 13 Mar 2003 22:16:44 -0800 Subject: Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Ted Hardie , namedroppers@ops.ietf.org To: Mark Kosters From: David Conrad In-Reply-To: <20030313195822.GS1653@verisignlabs.com> Message-Id: <8791B591-55E4-11D7-85A7-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-1.4 required=5.0 tests=IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mark, On Thursday, March 13, 2003, at 11:58 AM, Mark Kosters wrote: > I would prefer to see some hard numbers before I would agree with > this conjecture. > > There is at least one recursive implementation of opt-in that has been > completed. I know of one implementation of a recursive server that does _delegation only_ opt-in. I would, of course, be interested in hearing of another. > And we have had some experience that it interoperates > correctly with at least two authoritative opt-in servers. So with this > knowledge of actual running code, perhaps we should ask ISC and/or > Nominum to > comment on how much more "complex" it is to add opt-in support. I'm told that - implementation of the validator turns out to be easy - implementation of the authoritative side is harder - figuring out what needs to be cached is the hard bit Different server architectures make coming up with a consistent answer regarding complexity difficult. Rgds, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 14 01:34:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05708 for ; Fri, 14 Mar 2003 01:34:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tifz-0000fM-00 for namedroppers-data@psg.com; Thu, 13 Mar 2003 22:28:19 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 18tifw-0000f7-00 for namedroppers@ops.ietf.org; Thu, 13 Mar 2003 22:28:16 -0800 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 2B22C137F06; Thu, 13 Mar 2003 22:28:13 -0800 (PST) Date: Thu, 13 Mar 2003 22:28:12 -0800 Subject: Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: namedroppers@ops.ietf.org To: Paul Vixie From: David Conrad In-Reply-To: <20030313212217.0D664379E40@as.vix.com> Message-Id: <21727DD2-55E6-11D7-85A7-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-1.1 required=5.0 tests=IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul, On Thursday, March 13, 2003, at 01:22 PM, Paul Vixie wrote: > opt-in adds another > knob for zone managers, some of whom will twist it for engineering > reasons > (such as difficulty in signing and publishing large zones with current > technology) As has been pointed out, there is some argument whether this difficulty is an engineering issue. > but some of whom will twist it for non-engineering reasons > (such as a desire to limit the public exposure of complete NXT chains, > either for business or privacy reasons.) I (still) don't buy this. This says you have a choice: either names that can be (arguably) hidden OR the data fetched from the names can be can be verified, but NOT both. We have already shot down a proposal to address the zone traversal via NXT chain issue. Using opt-in as a hack to partially get the same thing is silly. If it is an issue, lets resurrect NO (which I'm not actually advocating this as you know -- if people want to hide DNS data, they should use "views" (or equivalent) and get over it) instead of pretending a side effect is a solution. > i believe that the tradeoff is between complexity and autonomy, Huh? Rgds, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 14 01:57:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06022 for ; Fri, 14 Mar 2003 01:57:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tj38-0001sa-00 for namedroppers-data@psg.com; Thu, 13 Mar 2003 22:52:14 -0800 Received: from [203.254.224.33] (helo=mailout3.samsung.com) by psg.com with esmtp (Exim 3.36 #1) id 18tj35-0001rp-00 for namedroppers@ops.ietf.org; Thu, 13 Mar 2003 22:52:11 -0800 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HBQ00EFV8EXKX@mailout3.samsung.com> for namedroppers@ops.ietf.org; Fri, 14 Mar 2003 15:52:09 +0900 (KST) Received: from ep_mmp1 (localhost [127.0.0.1]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HBQ00CEN85YX3@mailout3.samsung.com> for namedroppers@ops.ietf.org; Fri, 14 Mar 2003 15:46:46 +0900 (KST) Received: from daniel7209 ([168.219.203.183]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0HBQ00IF18N7AC@mmp1.samsung.com> for namedroppers@ops.ietf.org; Fri, 14 Mar 2003 15:57:07 +0900 (KST) Date: Fri, 14 Mar 2003 15:45:31 +0900 From: Soohong Daniel Park Subject: FW: Requesting timeslot To: ogud@ogud.com, randy@psg.com, namedroppers@ops.ietf.org Message-id: <010c01c2e9f5$4e9b11c0$b7cbdba8@daniel7209> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Status: No, hits=0.7 required=5.0 tests=OUTLOOK_FW_MSG,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT I verified DNSEXT charter right now, but something is wrong. Out of scope documents asking for Feedback: DNSEXT-ACL T Baba 5 min http://www.ietf.org/internet-drafts/draft-baba-dnsext-acl-reqts-00.txt 6DNAR Soohong Daniel Park 5 min http://www.ietf.org/internet-drafts/draft-jeong-hmipv6-dns-optimization- 00.txt 6DNAR is my draft but linked is not mine. what is it ? Daniel -----Original Message----- From: ?afur Gu?undsson [mailto:ogud@ogud.com] Sent: Friday, February 28, 2003 10:02 PM To: Soohong Daniel Park; ogud@ogud.com; randy@psg.com Subject: Re: Requesting timeslot At 19:47 2003-02-27, Soohong Daniel Park wrote: >Dear chair > >As I sent before, I have revised my draft "IPv6 Domain Name >Auto-Registration" This draft is focusing on auto resigtration on DAD >processing, and will add auto generation of IPv6 node domain name. Request noted, we have not made up the agenda yet, 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 14 02:14:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17325 for ; Fri, 14 Mar 2003 02:14:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tjKZ-0002mb-00 for namedroppers-data@psg.com; Thu, 13 Mar 2003 23:10:15 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 18tjKT-0002mO-00 for namedroppers@ops.ietf.org; Thu, 13 Mar 2003 23:10:09 -0800 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id D240E137F08; Thu, 13 Mar 2003 23:10:07 -0800 (PST) Date: Thu, 13 Mar 2003 23:10:06 -0800 Subject: Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: namedroppers@ops.ietf.org To: Daniel Massey From: David Conrad In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-1.1 required=5.0 tests=IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dan, On Thursday, March 13, 2003, at 02:04 PM, Daniel Massey wrote: >> however this is a bit over the top. > No, to me it reflects that is trade-off rather than a clearly right or > clearly wrong issue. we are long past the time we should have decided > on this trade-off. Agreed on both counts. What I was complaining about was that the arguments raised by Olaf and Scott to which you were agreeing were adding the proviso that opt-in should only be used for "huge" zones. This is, I believe, not an appropriate constraint to add. There aren't a whole lot of "huge" zones (and it has often been argued that given their size, they should have sufficient resources to deal with this issue without spreading the cost over every secure DNS server implementation) and opt-in _only_ has value if you assume only a portion of the full zone is signed (thus my 'temporary transition issue' statement). If the protocol modification is not generally useful but instead is intended to address non-technical requirements for a limited set of users, then I personally do not believe it should be added. Rgds, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 14 02:31:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18172 for ; Fri, 14 Mar 2003 02:31:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tjYj-0003UJ-00 for namedroppers-data@psg.com; Thu, 13 Mar 2003 23:24:53 -0800 Received: from [203.254.224.25] (helo=mailout2.samsung.com) by psg.com with esmtp (Exim 3.36 #1) id 18tjYe-0003Ti-00 for namedroppers@ops.ietf.org; Thu, 13 Mar 2003 23:24:48 -0800 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HBQ0061A9XA38@mailout2.samsung.com> for namedroppers@ops.ietf.org; Fri, 14 Mar 2003 16:24:46 +0900 (KST) Received: from ep_mmp1 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HBQ00HBA9FOU9@mailout2.samsung.com> for namedroppers@ops.ietf.org; Fri, 14 Mar 2003 16:14:12 +0900 (KST) Received: from daniel7209 ([168.219.203.183]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0HBQ000QS9WWNC@mmp1.samsung.com> for namedroppers@ops.ietf.org; Fri, 14 Mar 2003 16:24:33 +0900 (KST) Date: Fri, 14 Mar 2003 16:12:56 +0900 From: Soohong Daniel Park Subject: Domain Name Dynamic Update for IPv6 Mobile Node while away from home. To: namedroppers@ops.ietf.org Cc: randy@psg.com, ogud@ogud.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: multipart/mixed; boundary="Boundary_(ID_hOBZ+JnGdlgRiBtnadZkJw)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Status: No, hits=2.2 required=5.0 tests=MSGID_CHARS_SPAM,MSGID_CHARS_WEIRD,SPAM_PHRASE_01_02 version=2.43 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_hOBZ+JnGdlgRiBtnadZkJw) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hi folks I'd like to discuss this document which is still rough and not submitted yet. Most of all, I want to listen to DNS folks' opinion. Could you look into it and response to me ? If I missed an important point, let me know it. I attach this document. Daniel Abstract While a mobile node is attached to some foreign link away from home, it is addressable at one or more care-of addresses. But the address in DNS file is not care-of address but home address. Therefore, whenever new correspondent nodes are trying to connect to a mobile node, these packets are still gone through a Home Agent by reverse tunneling. This document suggests Domain Name Dynamic Update for IPv6 Mobile Node while away from home. ============================================== Soohong Daniel Park Researcher Mobile Platform Lab, Samsung electronics TEL:+82-31-200-3728 FAX:+82-31-200-3147 mailto:Soohong.Park@samsung.com --Boundary_(ID_hOBZ+JnGdlgRiBtnadZkJw) Content-type: text/plain; name="Domain Name Dynamic Update for IPv6 MN while away from home.txt" Content-disposition: attachment; filename="Domain Name Dynamic Update for IPv6 MN while away from home.txt" Content-Transfer-Encoding: 7BIT INTERNET-DRAFT Soohong Daniel Park Expires: September 2003 SAMSUNG Electronics March 2003 Domain Name Dynamic Update for IPv6 Mobile Node while away from home. < draft-park-dndu-ipv6-mobile-node-00.txt > Status of This Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract While a mobile node is attached to some foreign link away from home, it is addressable at one or more care-of addresses. But the address in DNS file is not care-of address but home address. Therefore, whenever new correspondent nodes are trying to connect to a mobile node, these packets are still gone through a Home Agent by reverse tunneling. This document suggests Domain Name Dynamic Update for IPv6 Mobile Node while away from home. Table of Contents 1. Introduction .............................................. 2 2. Operation Procedure ....................................... 2 2.1 RR Considerations ......................................... 3 2.2 BU Considerations ......................................... 4 2.3 Nonce Indices option for DNDU ............................. 4 3. 6DNDU Requirements ........................................ 4 4. Using DAD message ......................................... 5 4.1 New option for Domain Name ................................ 5 5. Security Considerations ................................... 5 6. Normative References ...................................... 6 7. Informative References .................................... 6 8. Author' Address ........................................... 6 Park Expires September 2003 [Page 1] INTERNET-DRAFT DNDU for IPv6 MN while away from home March 2003 1. Introduction While a mobile node is attached to some foreign link away from home, it is addressable at one or more care-of addresses. But the address in DNS file is not care-of address but home address. Therefore, whenever new correspondent nodes are trying to connect to a mobile node, these packets are still gone through a Home Agent by reverse tunneling. Moreover, a lot of new correspondent node initiate a mobile node, a lot of traffics must be gone through a Home Agent by reverse tunneling. This document suggests Domain Name Dynamic Update (DNDU) procedure for registering the Domain Name and IPv6 addresses with the DNS Server automatically while core-of address is performing the DAD procedure for detecting duplication in new link. Also, the NS message for the DAD has a new care-of address in the target field and original domain name in the new option field. In order to use this mechanism, there should be a minimum functions implemented on node and server. 2. Operation Procedure When a mobile node is moving to another link but still reachable at the previous link, the mobile node must perform a Binding Update. It is described in [MIPv6]. This section is focusing on one that new CNs initiate the first connection to a MN which was moved to another link. Home Link [AR1] | away from home-----> | /----------------------------------------------| | / | |------[MN] **************** | | * DNSv6 Server * | | *******/******** | | /\ / | [CN1]--| / \/ | | / | | / | -----|--------|-------/---|-----|---------------------|--- | | | | | V | | | | V [CN2] | [CNn] |------[MN] | | | | ********** | ********** | * 6DNDU *----------| * 6DNDU *---------| * server * * server * | ********** | ********** | | | | | CN:Correspondent Node | | MN:Mobile Node [ARn] [AR2] AR:Access Router Foreign Link
Park Expires September 2003 [Page 2] INTERNET-DRAFT DNDU for IPv6 MN while away from home March 2003 e.g. AR1 prefix : 2001::1/64 AR2 prefix : 2001::2/64 MN home address : 2001::1:aaaa MN domain name : daniel.example.com MN care-of address : 2001::2:aaaa DNSv6 file : daniel.example.com IN AAAA 2001::1:aaaa DNSv6 Updated file : daniel.example.com IN AAAA 2001::2:aaaa o The MN is moving to a foreign link while communicating with the CN1 The MN is received a new prefix from the AR2 The MN has a new care-of address The MN performs the DAD processing (target : 2001::2:aaaa option : daniel.example.com) o The 6DNDU server receives a NS message from the MN The server is caching the DAD information and waiting until the DAD is completed (1~2 sec) If the server receives all-node multicast address, the care-of address is duplicated The server is verifying the option type (Domain Name, TBD) update DNS file in the DNSv6 server (DNSv6 Updated file) o The CN2 initiates a new connection to the MN The CN2 sends a DNS query message to the DNSv6 server query name : daniel.example.com The CN2 receives a DNS reply message from the DNSv6 server rdata : 2001::2:aaaa o RR processing between MN and CN2 The MN sends CoTI to the CN2 (with X flag in Reserved field of the CoTI) The CN2 sends CoT to the MN o Binding Update between MN and CN2 The MN sends BU to the CN2 (with X flag in Reserved field of the BU) The CN2 send BA to the CN2 Note: The new X flag is a temporary value. 2.1 RR Considerations When the new CN initiates to the MN away from home, Return Routability must be performed. Originally RR procedure is done by testing whether packets addressed to the two claimed addresses are routed to the MN. But when the new CN initiates to the MN away from home, it don't need to be done by home testing as HoTI and HoT. Therefore, the CoTI message is sent to the new CN with a new flag. This flag announces to the CN that is not required to be HoTI and HoT processing. Also, the CoT is sent in response to the CoTI message to the MN. When the MN has received the CoT message, the return routability procedure is complete. As a result of the procedure, the MN has the data it needs to send a Binding Update to the CN. The MN generates the binding management key as follows Kbm = SHA1 (care-of keygen token Park Expires September 2003 [Page 3] INTERNET-DRAFT DNDU for IPv6 MN while away from home March 2003 2.2 BU Considerations After the MN has created the Kbm, it can supply a verifiable Binding Update to the CN with new flag to announce that the CN is not required to be HoTI and HoT processing. o Binding Update message source address = care-of address destination address = correspondent parameters: - home address (within the Home Address destination option) - sequence number (within the BU message header) - care-of address index (within the Nonce Indices option for DNDU) - HMAC_SHA1 (Kbm, (care-of address | CN address | BU)) Once the CN has verified the X flag and the MAC, it can create a Binding Cache entry for the mobile. Note that the CN should create the home address field by the BU message. o Binding Acknowledgement It is the same as [MIPv6] 2.3 Nonce Indices option for DNDU In order to skip over the Home Nonce Index value, the new option can be used to perform Domain Name Dynamic Update. The Nonce Indices option for DNDU has an alignment requirement of 2n. Its format is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = TBD | Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care-of Nonce Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3. 6DNDU Requirements In order to use this mechanism, the 6DNDU node and 6DNDU server. must support the following requirements. 6DNDU node Requirements 6DNDU node must insert Domain Name to new option field in the NS when a 6DNDU node is going on DAD processing. 6DNDU node don't require to be performed home testing by RR. So X flag must be set in Reserved field of CoTI. When 6DNDU node sends the BU message, home nonce index parameter should be omitted and the new option must be used to announce only care-of address index with X flag in Reserved field of BU. Park Expires September 2003 [Page 4] INTERNET-DRAFT DNDU for IPv6 MN while away from home March 2003 6DNDU server Requirements 6DNDU server must perform general DAD processing, and DNS function for domain name update [2136]. 4. Using DAD message DAD must take place on all unicast addresses, regardless of whether they are obtained through stateful, stateless or manual configuration. When a MN is attached to a foreign link which has another prefix information, in order to use a new core-of address, it must perform DAD processing. 6DNDU uses the DAD messages with new option (for carrying the Domain Name) for Dynamic Update Domain Name. 4.1 New option for Domain Name In order to announce Domain Name simultaneously with the address, this document defines new option called "Domain Name" (the Type value will be defined later). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ Domain Name ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Name Type Source Link-Layer Address 1 Target Link-Layer Address 2 Prefix Information 3 Redirected Header 4 MTU 5 . . . . Domain Name (TBD)
5. Security Considerations If someone wants to hijack correct Domain Name registration, they could send a NS message with incorrect or same Domain Name to the 6DNDU server repeatedly and server would start the Domain Name registration through above mechanism, which is a security hole. As ND message is described in [2461], a host can check validity of message. If ND message includes an IP Authentication Header, the message authenticates correctly. For DNS UPDATE processing, secure DNS Dynamic Update is illustrated in [3007]. Park Expires September 2003 [Page 5] INTERNET-DRAFT DNDU for IPv6 MN while away from home March 2003 6. Normative References [2373] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [2460] Deering, S. abd R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [1034] P. Mockapetris, "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC 1034, November 1987. [1035] P. Mockapetris, "Domain Names - Implementation and Specification" RFC 1035, November 1987. 7. Informative References [2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP version 6(IPv6)", RFC 2461, December 1998. [2136] P. Vixie et al., "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC2136, April 1997. [3007] B. Wellington, "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000. [6DNAR] S. Park, "IPv6 Domain Name Auto Registration", draft- park-6dnar-01.txt, work in progress. [MIPv6] D. Johnson, C. Perkins, and J. Arkko. "Mobility Support in IPv6, draft-ietf-mobileip-ipv6-21.txt, work in progress. 8. Author' Address Soohong Daniel Park SAMSUNG Electronics Digital Media R&D Center 416, Maetan-3Dong,Paldal-Gu, Suwon City, Gyeonggi-Do,Korea Phone: +82-31-200-3728 Email:soohong.park@samsung.com Park Expires September 2003 [Page 6] --Boundary_(ID_hOBZ+JnGdlgRiBtnadZkJw)-- -- to unsubscribe send a message to namedroppers-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 14 04:23:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19979 for ; Fri, 14 Mar 2003 04:23:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tlGd-0008XM-00 for namedroppers-data@psg.com; Fri, 14 Mar 2003 01:14:19 -0800 Received: from [203.254.224.24] (helo=mailout1.samsung.com) by psg.com with esmtp (Exim 3.36 #1) id 18tlGa-0008XA-00 for namedroppers@ops.ietf.org; Fri, 14 Mar 2003 01:14:16 -0800 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HBQ005OFEZQT7@mailout1.samsung.com> for namedroppers@ops.ietf.org; Fri, 14 Mar 2003 18:14:14 +0900 (KST) Received: from ep_mmp1 ([127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HBQ004YZEPX1J@mailout1.samsung.com> for namedroppers@ops.ietf.org; Fri, 14 Mar 2003 18:08:22 +0900 (KST) Received: from daniel7209 ([168.219.203.183]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0HBQ00KO0F77JB@mmp1.samsung.com> for namedroppers@ops.ietf.org; Fri, 14 Mar 2003 18:18:43 +0900 (KST) Date: Fri, 14 Mar 2003 18:07:06 +0900 From: Soohong Daniel Park Subject: Re:[mobile-ip] Domain Name Dynamic Update for IPv6 Mobile Node while away from home. To: namedroppers@ops.ietf.org, dnsop@cafax.se Message-id: <014701c2ea09$1628e7e0$b7cbdba8@daniel7209> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT inline... -----Original Message----- From: Bryan Wang [mailto:xwang@elmic.com] Sent: Friday, March 14, 2003 10:25 AM To: Soohong Daniel Park; mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Domain Name Dynamic Update for IPv6 Mobile Node while away from home. Soohong - I think you missed an important point, it is called Mobile IPv6 Route Optimization. The mobile node will detect that a correspondent node's packets are being tunneled to it by the home agent, and may initiate the return routability procedure. If return routability is successful, next the mobile node creates a binding in the correspondent node that maps the mobile node's home address to its current care-of address. At this point, the correspondent node can send directly to the mobile node at that care-of address. Mobile IPv6 accomplishes this all transparently at the network layer, below the application. The application on the correspondent node is unaware that the mobile node's home address has changed. ==> I see, it's a general processing in MIPv6. There is no need to do any update in the DNS server. ==>um... because of above sentence, all new CN are initiating to the MN must be gone through reverse tunneling. In fact, what you are proposing is pretty error-prone: what if the mobile node moves again, and if the application was aware of the mobile node's old care-of address (per your dynamic DNS update), the application will be trying to reach the mobile node at the wrong address. ==>I don't see what you say. As I said previous mail, this document concentrates on the new CN is initiating. When the MN is moving another link, the MN performs route optimization as well, so the CN will update binding using new care-of address. You'd better be more careful that if the CN is connecting to MN away to another link, the CN don't need any other DNS query. Mobile IPv6 does not handle redirection of packets sent to the mobile node's old care-of address to route them to its new care-of address, so any packets the correspondent node sends to the old care-of address will be lost. ==>above action is not happened, since the CN sends all packets to new care-of address as well. Daniel Thanks, Bryan Wang Elmic Systems, USA ----- Original Message ----- From: "Soohong Daniel Park" To: Sent: Thursday, March 13, 2003 4:16 AM Subject: [mobile-ip] Domain Name Dynamic Update for IPv6 Mobile Node while away from home. > Hi all > > I'd like to discuss this document which is still rough. > Most of all, I want to listen to mobileip folks' opinion. > Could you look into it and response to me ? > If I missed an important point, let me know it. > I attach this document. > > Daniel > > > > Abstract > > While a mobile node is attached to some foreign link away from home, > it is addressable at one or more care-of addresses. But the address in > DNS file is not care-of address but home address. Therefore, whenever > new correspondent nodes are trying to connect to a mobile node, these > packets are still gone through a Home Agent by reverse tunneling. > This document suggests Domain Name Dynamic Update for IPv6 Mobile Node > while away from home. > > ============================================== > Soohong Daniel Park > Researcher > Mobile Platform Lab, Samsung electronics > TEL:+82-31-200-3728 FAX:+82-31-200-3147 > mailto:Soohong.Park@samsung.com > > > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 14 08:40:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25047 for ; Fri, 14 Mar 2003 08:40:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tp8l-000K36-00 for namedroppers-data@psg.com; Fri, 14 Mar 2003 05:22:27 -0800 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 18tp8i-000K2u-00 for namedroppers@ops.ietf.org; Fri, 14 Mar 2003 05:22:24 -0800 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.3/8.12.3/Debian-5) with ESMTP id h2EDMI5U010297 for ; Fri, 14 Mar 2003 14:22:19 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.3/8.12.3/Debian-5) with ESMTP id h2EDMHoh010294 for ; Fri, 14 Mar 2003 14:22:18 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Fri, 14 Mar 2003 14:22:17 +0100 (CET) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: To OPT-IN or not to OPT_IN Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=1.5 required=5.0 tests=OPT_IN,SPAM_PHRASE_00_01,USER_AGENT_PINE,X_AUTH_WARNING version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id IAA25047 Some of my views re: opt-in and this whole last call process: Re: The Security Model: Opt-in does not alter the security model, since there is no static security model defined. Some form of trust model may be implied by 2535, but this asserted model has already been altered numerous times by subsequent documents. Re: Layer 8 Arguments. The cost to manage a signed zone is substantial. Deploying DNSSEC on large delegation centric zones is substantial. Using Opt-In on the latter does ease deployment costs. The cost of adding and mainting Yet Another Code Path is also substantial. What I've seen is that there exist code in the field to handle opt-in for delegations only on all sides of the query/resonse end. It is hard to quantify and compare all costs. Downplaying concerns by bluntly comparing cost are layer 9 tactics. Re: Again Changing the Specs: This document originated in 2000, the current suggested changes to dnssec originated in 2001. We saw numerous updates to 2535 since 2000: Key- restrict, DNSSEC-OK, delegation signer, ad-bit, so on and so on. I do not suggest changing specs Ad-Hoc is a good thing. This proposed change to the spec originated some time ago, and is not some last moment hack. As I see it, this change to the spec is minor. Opt-In is not rocket science. Re: Opt-in for Delegations Only. One cryptographically signs that a subzone is not cryptographically signed. Opt-In for delegations requires all authoritative data in a zone signed. Glue records and delegation NS records are not authoritative data, and possibly signed elsewhere. Proving a subdomain exist can be done by signing the subdomain. Pushing the burdon of proof up the tree without signing the subtree does not scale well. Simply signing stuff because 'We Dit It On A Laptop' does not scale well either. Re: This Last Call Process. The authors of this document have tried to address the concerns and alledged technical problems. The draft has been changed a few times to reflect and constrain the 'damage' that is perceived. There have been several last calls. The last last call [sic] on technical matter showed consensus (see below). I perceive the current last call as inapropriate. I see yet another last call coming with the question "Are we really really really sure ?" ;-) Sadly we've come to the point that integrity of people publicly supporting the draft is questioned by those who so passionately do not care what decision is made. That is deliberately polarising the discussion. Roy Date: Fri, 28 Feb 2003 09:10:14 -0500 From: Ólafur Gudmundsson/DNSEXT co-chair To: namedroppers@ops.ietf.org Subject: DNSEXT WGLC summary: OPT-in This last call has completed. The result of the last call was that there is consensus the technical specification was almost ready. Authors have worked with this chair to create a new version of the document that addresses the issues raised in the last call and have submitted a new version. The message below contains the list of changes to the document: http://psg.com/lists/namedroppers/namedroppers.2003/msg00489.html Due to the expected delay in posting the new version as a ID here is a pointer to the new version: http://www.logmess.com/~roy/draft-ietf-dnsext-dnssec-opt-in-05.txt The chair would like to thank the working group members that responded to the message below and engaged in one of the better technical debates the mailing list has seen. Olafur -- to unsubscribe send a message to namedroppers-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 14 10:38:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29815 for ; Fri, 14 Mar 2003 10:38:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tqvr-000Nj4-00 for namedroppers-data@psg.com; Fri, 14 Mar 2003 07:17:15 -0800 Received: from one.elistx.com ([209.116.252.130]) by psg.com with esmtp (Exim 3.36 #1) id 18tqvo-000Nic-00 for namedroppers@ops.ietf.org; Fri, 14 Mar 2003 07:17:12 -0800 Received: from ogud.com (pcp816081pcs.nrockv01.md.comcast.net [68.49.60.118]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HBQ00JJ6VTXUN@eListX.com> for namedroppers@ops.ietf.org; Fri, 14 Mar 2003 10:17:58 -0500 (EST) Received: from ENGILL.ogud.com (ns.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.3/8.12.3) with ESMTP id h2EFHUbZ023915; Fri, 14 Mar 2003 10:17:30 -0500 (EST envelope-from ogud@ogud.com) Date: Fri, 14 Mar 2003 10:15:56 -0500 From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: FW: Requesting timeslot In-reply-to: <010c01c2e9f5$4e9b11c0$b7cbdba8@daniel7209> X-Sender: post@localhost To: Soohong Daniel Park , ogud@ogud.com, randy@psg.com, namedroppers@ops.ietf.org Message-id: <5.1.1.6.2.20030314101347.01f485f8@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=us-ascii X-Spam-Status: No, hits=-0.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,OUTLOOK_FW_MSG, QUOTED_EMAIL_TEXT,RCVD_IN_RFCI,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 01:45 2003-03-14, Soohong Daniel Park wrote: >I verified DNSEXT charter right now, but something is wrong. > >Out of scope documents asking for Feedback: > > 6DNAR Soohong Daniel Park 5 >min > >http://www.ietf.org/internet-drafts/draft-jeong-hmipv6-dns-optimization- >00.txt > >6DNAR is my draft but linked is not mine. what is it ? > I posted the wrong link, sorry. Your draft (posted to namedroppers) will get a short time slot to solicit feedback. 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 14 11:55:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02554 for ; Fri, 14 Mar 2003 11:55:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tsBj-0000dW-00 for namedroppers-data@psg.com; Fri, 14 Mar 2003 08:37:43 -0800 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 18tsBh-0000dC-00 for namedroppers@ops.ietf.org; Fri, 14 Mar 2003 08:37:41 -0800 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA08145; Fri, 14 Mar 2003 11:37:39 -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 LAA05331; Fri, 14 Mar 2003 11:37:39 -0500 (EST) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h2EGbbV3022036; Fri, 14 Mar 2003 11:37:37 -0500 (EST) Received: (from ghudson@localhost) by error-messages.mit.edu (8.9.3) id LAA01926; Fri, 14 Mar 2003 11:37:36 -0500 Subject: Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN From: Greg Hudson To: David Conrad Cc: namedroppers@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 14 Mar 2003 11:37:36 -0500 Message-Id: <1047659856.21854.108.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Spam-Status: No, hits=3.9 required=5.0 tests=IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM, RCVD_IN_RELAYS_ORDB_ORG,REFERENCES,SPAM_PHRASE_00_01, X_OSIRU_OPEN_RELAY version=2.43 X-Spam-Level: *** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 2003-03-14 at 02:10, David Conrad wrote: > If the protocol modification > is not generally useful but instead is intended to address > non-technical requirements for a limited set of users, then I > personally do not believe it should be added. I'm not sure what "non-technical" requirements you believe opt-in addresses. If Verisign wants to charge extra for a secure delegation, they can do that without opt-in. As to the "limited set of users" argument: almost every DNSSEC user is expected to make use of opt-in from the client side. It's important to distinguish asymmetric features like this--used by only a few people on the server side, but still affecting lots of users--from features which will impact almost nobody. -- to unsubscribe send a message to namedroppers-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 14 13:40:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06318 for ; Fri, 14 Mar 2003 13:40:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ttqg-0004sv-00 for namedroppers-data@psg.com; Fri, 14 Mar 2003 10:24:06 -0800 Received: from fbca.iij-america.com ([216.98.98.238] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 18ttqd-0004se-00 for namedroppers@ops.ietf.org; Fri, 14 Mar 2003 10:24:03 -0800 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 39CA0791; Sat, 15 Mar 2003 03:23:26 +0900 (JST) To: Soohong Daniel Park Cc: namedroppers@ops.ietf.org, randy@psg.com, ogud@ogud.com In-reply-to: soohong.park's message of Fri, 14 Mar 2003 16:12:56 +0900. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Domain Name Dynamic Update for IPv6 Mobile Node while away from home. From: Jun-ichiro itojun Hagino Date: Sat, 15 Mar 2003 03:23:26 +0900 Message-Id: <20030314182326.39CA0791@starfruit.itojun.org> X-Spam-Status: No, hits=-1.1 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >I'd like to discuss this document which is still rough and not submitted >yet. >Most of all, I want to listen to DNS folks' opinion. >Could you look into it and response to me ? >If I missed an important point, let me know it. >I attach this document. > > Daniel > > > Abstract > > While a mobile node is attached to some foreign link away from home, > it is addressable at one or more care-of addresses. But the address in > DNS file is not care-of address but home address. Therefore, whenever > new correspondent nodes are trying to connect to a mobile node, these > packets are still gone through a Home Agent by reverse tunneling. > This document suggests Domain Name Dynamic Update for IPv6 Mobile Node > while away from home. err.... what is the purpose of "home address" and its associated domain name? your proposal basically says "we no longer need mobile-ip6, we just need to update DNS". itojun -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 14 13:45:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06924 for ; Fri, 14 Mar 2003 13:45:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ttyp-0005C8-00 for namedroppers-data@psg.com; Fri, 14 Mar 2003 10:32:31 -0800 Received: from [2001:4f8:3:bb:2e0:81ff:fe10:67ab] (helo=as.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 18ttyn-0005Be-00 for namedroppers@ops.ietf.org; Fri, 14 Mar 2003 10:32:29 -0800 Received: by as.vix.com (Postfix, from userid 716) id 79B36379F94; Fri, 14 Mar 2003 18:32:16 +0000 (GMT) To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN References: From: Paul Vixie Date: 14 Mar 2003 18:32:16 +0000 In-Reply-To: Message-ID: Lines: 35 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-3.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT, REFERENCES,SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_GNUS_UA version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk David Conrad writes: > ... > What I was complaining about was that the arguments raised by Olaf and > Scott to which you were agreeing were adding the proviso that opt-in > should only be used for "huge" zones. This is, I believe, not an > appropriate constraint to add. i agree. > There aren't a whole lot of "huge" zones (and it has often been argued > that given their size, they should have sufficient resources to deal with > this issue without spreading the cost over every secure DNS server > implementation) and opt-in _only_ has value if you assume only a portion > of the full zone is signed (thus my 'temporary transition issue' > statement). If the protocol modification is not generally useful but > instead is intended to address non-technical requirements for a limited > set of users, then I personally do not believe it should be added. the opt-in protocol enhancement is generally useful, and increases the control that administrators have over their zone data, at the marginal cost of some kind of purported but unmeasured implementation difficulty. arguments against opt-in have taken one of two forms, so far. (1) "zone autonomy is bad, and we the people demand our right to force administrators of foreign/distant zones to sign it all or sign nothing." or (2) "there's some kind of nonzero incremental complexity, which could be harmful, so we shouldn't do it." arguments in favour of opt-in have taken one of two forms, so far. (1) ".XYZ needs this." or (2) "it improves the design." has anybody got a new argument to offer, on either side? -- Paul Vixie -- to unsubscribe send a message to namedroppers-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 14 14:06:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08641 for ; Fri, 14 Mar 2003 14:06:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tuJZ-00069S-00 for namedroppers-data@psg.com; Fri, 14 Mar 2003 10:53:57 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 18tuJW-000698-00 for namedroppers@ops.ietf.org; Fri, 14 Mar 2003 10:53:54 -0800 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id C3FBD137F06; Fri, 14 Mar 2003 10:53:53 -0800 (PST) Date: Fri, 14 Mar 2003 10:53:53 -0800 Subject: Re: DNSEXT WGLC: To OPT-IN or not to OPT_IN Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: namedroppers@ops.ietf.org To: Roy Arends From: David Conrad In-Reply-To: Message-Id: <4D4B8AFC-564E-11D7-85A7-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Roy, On Friday, March 14, 2003, at 05:22 AM, Roy Arends wrote: > Re: The Security Model: > Opt-in does not alter the security model, since there is no static > security model defined. Perhaps I am mistaken, but in 2535, or at least as it has commonly been interpreted, without opt-in, all names within a zone can be authenticated or they can't. There is no middle ground, i.e., the name does exist but it isn't authenticatable. With opt-in, individual names within a zone may or may not be authenticatable, depending on whether the name has opted in. It is hard for me to see this not being a change in the security model. I have no comment on whether this change is good or bad, I am merely stating that it exists and has implications. > Re: Layer 8 Arguments. > What I've seen is that there exist code in > the field to handle opt-in for delegations only on all sides of the > query/resonse end. What I've seen is a pre-release, not generally available, of code that has had some preliminary testing in a lab setting. Perhaps you have seen something else. Regardless, at this stage of protocol development, this is not unexpected. > As I see it, this change to the spec is minor. People who have implemented opt-in appear to differ with this assertion, but such evaluations are, of course, subjective. > Re: This Last Call Process. > The last last call [sic] on technical matter showed > consensus (see below). I perceive the current last call as > inapropriate. I also will admit some surprise that this issue has yet again come up. Perhaps the chairs can provide details on the process they are following here? > Sadly we've come to the point that integrity of people publicly > supporting > the draft is questioned by those who so passionately do not care what > decision is made. Presumably, given my stated position on the issue, this was directed at me. I would be interested to see where I have questioned _anyone's_ integrity in this discussion (I have, on the other hand, seen suggestions that anyone claiming complexity is a concern is spreading FUD). In any event I certainly intended no questions of integrity and if such were perceived, I apologize. Rgds, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 14 15:04:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11260 for ; Fri, 14 Mar 2003 15:04:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tvEG-0008Ry-00 for namedroppers-data@psg.com; Fri, 14 Mar 2003 11:52:32 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 18tvE9-0008Qx-00 for namedroppers@ops.ietf.org; Fri, 14 Mar 2003 11:52:25 -0800 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 64FB1137F06; Fri, 14 Mar 2003 11:52:22 -0800 (PST) Date: Fri, 14 Mar 2003 11:52:21 -0800 Subject: Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: namedroppers@ops.ietf.org To: Greg Hudson From: David Conrad In-Reply-To: <1047659856.21854.108.camel@error-messages.mit.edu> Message-Id: <7863B17E-5656-11D7-85A7-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-1.1 required=5.0 tests=IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Greg, On Friday, March 14, 2003, at 08:37 AM, Greg Hudson wrote: > I'm not sure what "non-technical" requirements you believe opt-in > addresses. To be explicit, this isn't a Verisign-only issue. In today's Internet, you typically need a business case to justify doing something new to pretty much any infrastructure. Given the vast majority of zone owners won't be interested in DNSSEC when it is first (finally) released, it is unlikely they'd be happy about paying more to get what DNSSEC provides. Given it is unlikely people will want to pay more, it is hard to come up with a business case that would justify the additional costs necessary to deploy the DNSSEC infrastructure if those costs are significant which was thought to be the case for very large zones. Opt-in addresses this problem by allowing only those interested in DNSSEC to choose (and pay) to have their zones and delegations secured. This is not a technical requirement, it is a means by which a business case can be made. However, others have pointed out that Moore's law has caught up and passed this problem. Signing a huge zone (say 33 million delegations, for example) has been demonstrated to take less than 2 hours on a $10K box (or rather, $10K a year and a half ago) and could be done faster. Propagation and loading the data is indeed an issue, but this issue is addressable in a variety of fashions (e.g., only propagate/load changes) using existing technology, albeit perhaps with changes to existing business processes. My point was that opt-in should be included or not based on its general applicability, not because a small number of zones have decided for non-technical reasons to not fully sign the zone (and hence opt-in should be limited to those zones). As Paul V. states, there may be intrinsic benefits that opt-in provides that justify its inclusion and the decision should be made by analyzing the costs of those benefits. > As to the "limited set of users" argument: almost every DNSSEC user is > expected to make use of opt-in from the client side. I am unsure whether the vast majority of zone owners will bother with not signing their entire zones. I guess it depends on the signing tools. Rgds, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 14 18:28:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19445 for ; Fri, 14 Mar 2003 18:28:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tyN2-000HLf-00 for namedroppers-data@psg.com; Fri, 14 Mar 2003 15:13:48 -0800 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 18tyMy-000HLJ-00 for namedroppers@ops.ietf.org; Fri, 14 Mar 2003 15:13:45 -0800 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.3/8.12.3/Debian-5) with ESMTP id h2ENDZ5U021042; Sat, 15 Mar 2003 00:13:36 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.3/8.12.3/Debian-5) with ESMTP id h2ENDZZd021039; Sat, 15 Mar 2003 00:13:35 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Sat, 15 Mar 2003 00:13:35 +0100 (CET) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: David Conrad cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: To OPT-IN or not to OPT_IN In-Reply-To: <4D4B8AFC-564E-11D7-85A7-000393DB42B2@nominum.com> Message-ID: References: <4D4B8AFC-564E-11D7-85A7-000393DB42B2@nominum.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-1.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT, REFERENCES,SPAM_PHRASE_03_05,USER_AGENT_PINE,X_AUTH_WARNING version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 14 Mar 2003, David Conrad wrote: > Roy, > > On Friday, March 14, 2003, at 05:22 AM, Roy Arends wrote: > > Re: The Security Model: > > Opt-in does not alter the security model, since there is no static > > security model defined. > > Perhaps I am mistaken, but in 2535, or at least as it has commonly been > interpreted, without opt-in, all names within a zone can be > authenticated or they can't. Authenticated as in sig(ownername+class+type+ttl+rdlen+rdata), yes, the same is true with opt-in. 2535 does not sign delegation point NS record and does not sign glue, same with opt-in. > There is no middle ground, i.e., the name does exist but it isn't > authenticatable. With opt-in, individual names within a zone may or may > not be authenticatable, depending on whether the name has opted in. > > It is hard for me to see this not being a change in the security model. What "the security model" ? If there exist a static model I'd like to know. As with any security model, it's a defense against some form of threat. Merely defining a set of rules and following them blindly is not enough to form a security model. > I have no comment on whether this change is good or bad, I am merely > stating that it exists and has implications. Sure, opt-in changes the spec. But that change should not be overrated. The change is marginal in code-path. I am not downplaying implications of this change. I've spent a considerable amount of time researching corner-cases, and they turn out the be part of the general DNSSEC case. > > Re: Layer 8 Arguments. > > What I've seen is that there exist code in > > the field to handle opt-in for delegations only on all sides of the > > query/resonse end. > > What I've seen is a pre-release, not generally available, of code that > has had some preliminary testing in a lab setting. Same here. I've seen the pre-release stuff. Pre-release code testing was not the main goal, but the change to the protocol was what was tested. > Regardless, at this stage of protocol development, this is not > unexpected. > > > As I see it, this change to the spec is minor. > > People who have implemented opt-in appear to differ with this > assertion, but such evaluations are, of course, subjective. The change to the spec is minor. I did not talk about code. It is not rocket-science, though. > > Re: This Last Call Process. > > The last last call [sic] on technical matter showed > > consensus (see below). I perceive the current last call as > > inapropriate. > > I also will admit some surprise that this issue has yet again come up. > Perhaps the chairs can provide details on the process they are > following here? > > > Sadly we've come to the point that integrity of people publicly > > supporting the draft is questioned by those who so passionately do not > > care what decision is made. > > Presumably, given my stated position on the issue, this was directed at > me. I would be interested to see where I have questioned _anyone's_ > integrity in this discussion (I have, on the other hand, seen > suggestions that anyone claiming complexity is a concern is spreading > FUD). My 'integrity' wording was too strong. You at least 'challenged' others in a way that i interpreted as ad hominem, which was at least odd given that you 'did not care what decision' in the same message. I do care. 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 14 23:40:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28456 for ; Fri, 14 Mar 2003 23:40:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18u3Cw-00084W-00 for namedroppers-data@psg.com; Fri, 14 Mar 2003 20:23:42 -0800 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.36 #1) id 18u3Cs-00084F-00 for namedroppers@ops.ietf.org; Fri, 14 Mar 2003 20:23:38 -0800 Received: from isi.edu (pool-138-88-78-174.res.east.verizon.net [138.88.78.174]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id h2F4NVv25714; Fri, 14 Mar 2003 20:23:31 -0800 (PST) Date: Fri, 14 Mar 2003 23:23:25 -0500 Subject: Re: DNSEXT WGLC: To OPT-IN or not to OPT_IN Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Daniel Massey , David Conrad , namedroppers@ops.ietf.org To: Roy Arends From: Daniel Massey In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-1.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL,X_OSIRU_DUL,X_OSIRU_DUL_FH version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, March 14, 2003, at 06:13 PM, Roy Arends wrote: > >> I have no comment on whether this change is good or bad, I am merely >> stating that it exists and has implications. > > Sure, opt-in changes the spec. But that change should not be overrated. > The change is marginal in code-path. I am not downplaying implications > of > this change. I've spent a considerable amount of time researching > corner-cases, and they turn out the be part of the general DNSSEC case. > I think this is a key point. I was also one of the people concerned about the security model impact of opt-in, but in my view this was addressed. Paraphrasing what I learned from Roy and others is that the DNS really deals with signed RRsets. A model of signed zones quickly starts to lose meaning from the perspective of a resolver, cache, etc, and not an even authoritative server really must check that a zone is properly signed. In terms of security model, for reasons other than opt-in we should focus on signed RRsets and not signed zones. Although I will not go as far as saying opt-in has no impact on complexity and security model, it seems much of the added complexity and security model is really due to DNSSEC itself and opt-in has a small impact at most in that regard. 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 Sat Mar 15 23:47:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05543 for ; Sat, 15 Mar 2003 23:47:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uPq6-000GNE-00 for namedroppers-data@psg.com; Sat, 15 Mar 2003 20:33:38 -0800 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #1) id 18uPq4-000GN2-00 for namedroppers@ops.ietf.org; Sat, 15 Mar 2003 20:33:36 -0800 Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54] (may be forged)) by peacock.verisign.com (8.12.8/) with ESMTP id h2G4XXwL007205; Sat, 15 Mar 2003 20:33:34 -0800 (PST) Received: by mou1wnexc02.verisign.com with Internet Mail Service (5.5.2653.19) id ; Sat, 15 Mar 2003 20:33:33 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: =?iso-8859-1?Q?=D3lafur_Gudmundsson/DNSEXT_co-chair?= , namedroppers@ops.ietf.org Subject: RE: DNSEXT WGLC: To OPT_IN or not to OPT-IN Date: Sat, 15 Mar 2003 20:33:32 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=1.8 required=5.0 tests=EXCHANGE_SERVER,MAY_BE_FORGED,OPT_IN,QUOTED_EMAIL_TEXT, SPAM_PHRASE_02_03,TO_BE_REMOVED_REPLY version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA05543 I support OPT-In Zones. I believe there has been consensus on the need for opt-in for over a year. Phill > -----Original Message----- > From: Ólafur Gudmundsson/DNSEXT co-chair [mailto:ogud@ogud.com] > Sent: Wednesday, March 12, 2003 11:01 PM > To: namedroppers@ops.ietf.org > Subject: DNSEXT WGLC: To OPT_IN or not to OPT-IN > > > > This starts a two week working group last call, > concluding on March 28'th 2003. > > Q: Is there consensus by the WG, to allow Opt-in zones? > > The document to base this discussion on is > > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-o pt-in-05.txt Please send explicit statements of support or disagreement. Note this is not a last call on the technical issues in the document, if any such issues exist they should be assumed to be fixable and not affect the judgment on the question above. The document is on the standards track. If this document is advanced by the working group, it will be integrated into the DNSSECbis documents. Silence during this working group last call will be taken as support for opt-in based on comments made during the technical last call on OPT-IN. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Mar 16 00:55:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06463 for ; Sun, 16 Mar 2003 00:55:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uQzr-000Na2-00 for namedroppers-data@psg.com; Sat, 15 Mar 2003 21:47:47 -0800 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #1) id 18uQzp-000NZo-00 for namedroppers@ops.ietf.org; Sat, 15 Mar 2003 21:47:45 -0800 Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57] (may be forged)) by peacock.verisign.com (8.12.8/) with ESMTP id h2G5liwL020214 for ; Sat, 15 Mar 2003 21:47:44 -0800 (PST) Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id ; Sat, 15 Mar 2003 21:47:44 -0800 Message-ID: From: "Hallam-Baker, Phillip" Cc: namedroppers@ops.ietf.org Subject: RE: DNSEXT WGLC: To OPT_IN or not to OPT-IN Date: Sat, 15 Mar 2003 21:47:44 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=2.6 required=5.0 tests=EXCHANGE_SERVER,MAY_BE_FORGED,MISSING_HEADERS,OPT_IN, QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01,TO_EMPTY version=2.43 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > However, others have pointed out that Moore's law has caught up and > passed this problem. Signing a huge zone (say 33 million > delegations, > for example) has been demonstrated to take less than 2 hours > on a $10K > box (or rather, $10K a year and a half ago) and could be done > faster. Not if you want to use FIPS certified hardware you can't. The FIPS 140 boxes VeriSign currently buys cost $35K list (I would expect we get a discount but I doubt that even we can buy one for $10K). They do not perform at speeds remotely comparable to workstation or server class hardware. The killer operational issue is the data volume, not the signing time. Phill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Mar 16 10:32:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27687 for ; Sun, 16 Mar 2003 10:32:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uZwC-0006AJ-00 for namedroppers-data@psg.com; Sun, 16 Mar 2003 07:20:36 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18uZw8-00067g-00 for namedroppers@ops.ietf.org; Sun, 16 Mar 2003 07:20:32 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18uZw8-0001DC-00 for namedroppers@ops.ietf.org; Sun, 16 Mar 2003 10:20:32 -0500 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Sun, 16 Mar 2003 14:20:12 +0200 (EET) From: Pekka Savola To: soohong.park@samsung.com cc: namedroppers@ops.ietf.org Subject: park-6dnar-01 comments X-Spam-Status: No, hits=-0.6 required=5.0 tests=RESENT_TO,SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02, USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Hi, The draft park-6dnar-01 is on the agenda for comments, so I thought I'd take a look. Btw, the URL is wrong, I don't know which is supposed to be correct: 6DNAR Soohong Daniel Park 5 min http://www.ietf.org/internet-drafts/draft-jeong-hmipv6-dns-optimization-00.txt Two issues: 1) there are like 2-3 similar mechanisms already. What I want is each proposal compare the drafts, or start from scratch process-wise (problem scoping, etc.etc.). 2) the editioal quality is on the fringe of unreadable, so stopped after two sections :-( editos in those below. ... Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. ==> take the typical boilerplate, empty lines missing etc.? Neighbor Discovery Protocol [2461] will be used. Moreover, 6DNAR don't change any existing DNS system. ==> s/do/does/ 13. Author' address ==> s/Author'/Author's/ Park Expires September, 2003 [Page 1] ==> pages are too long and formatted inproperly; the maximum is 58 lines, recommendation 55. 1. Introduction Todays most networks use DNS[1034][1035] for convenience. ==> s/Todays/Today's/ In case of IPv6, DNS is more important element because of IPv6 long addresses which are difficult to remember. In addition, small ==> reword "IPv6 long addresses" networks like home networks using IPv6, should be able to make network easily without manual configuration and required systems such ==> s/networks like/networks, like/ ==> reword "make network easily" as DNS server or DHCP server and so on. This document discusses IPv6 Domain Name Auto-Registration(6DNAR) procedure for registering ==> s/(/ (/ the Domain Name and IPv6 addresses with the DNS Server automatically. In order to use 6DNAR, there should be a minumun functions implemented on 6DNAR node and server easily. Additionally, 6DNAR ==> reword "minumum (sic) functions implemented on 6DNAR node and server easily" 6DNAR can be applied to defined IPv6 addresses, Site-local and Global address not Link-local address. ==> reword all of it Whenever DAD is performed, 6DNAR uses Neighbor Discovery Protocol [2461] with new additions(defined in section 4.1 and 6) for ==> s/(/ (/ Note that the generation of unique Domain Name will be discussed on another document. ==> s/on/in/ 2. Terminology NS - Neighbor Solicitation message (is defined [2461]) ==> s/is defined //g "D" flag - D flag is defined newly for acknowledgement of duplicate Domain Name (temporarily defined) ==> reword around "newly". 6DNAR server - An 6DNAR node that can registrate Domain Name and ==> s/An/A/ -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 17 12:57:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22743 for ; Mon, 17 Mar 2003 12:57:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uyTX-0001Ti-00 for namedroppers-data@psg.com; Mon, 17 Mar 2003 09:32:39 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #1) id 18uyTQ-0001T5-00 for namedroppers@ops.ietf.org; Mon, 17 Mar 2003 09:32:32 -0800 Received: from ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.8/8.11.6) with ESMTP id h2HHWR12027276; Mon, 17 Mar 2003 18:32:27 +0100 Message-Id: <200303171732.h2HHWR12027276@birch.ripe.net> To: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: Key-Signing Key (KSK) Flag In-Reply-To: Message from Mark.Andrews@isc.org of "Fri, 14 Mar 2003 12:36:05 +1100." <200303140136.h2E1a5MC006264@drugs.dv.isc.org> Date: Mon, 17 Mar 2003 18:32:27 +0100 From: Olaf Kolkman X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In response to * > This starts a 2 week Working Group last call on this document, * > concluding on March 28'th 2003. Mark.Andrews@isc.org writes: * As currently specified this is going to result in operational * problems. * * We really need to specify key functionality at key creation time. * This way signer and DS key generation can be well defined. * * I propose two bits (...) In somewhat more detail: Based on experiences during the recent workshop we came to the conclusion that a signer (either the off-line or the on-line, in the case of dynamically updated signer) needs to know which key is to be used for signing the zone data. This can be done by using a second bit. With this bit and some definition on the behaviour of the signer based on the settings of the bit signers can do their work automatically. The behaviour of the signers given the states of the bit needs to be clearly specified. KSK ZSK 0 0 Signers treat this as an undefined state. 1 0 The Key is used to sign the apex key set only. 0 1 The Key is used to sign all zone date except the apex key set. 1 1 The Key is used to sign all zone and apex key data. As in the current version of the draft the bit provide operational hints and MUST not be used in resolving and verification. If during the working group meeting on Tuesday supports this idea I'd like to modify the draft to incorporate these ideas and push a new version in order 1-2 weeks. -- to unsubscribe send a message to namedroppers-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 17 14:03:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25157 for ; Mon, 17 Mar 2003 14:03:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uzlJ-000735-00 for namedroppers-data@psg.com; Mon, 17 Mar 2003 10:55:05 -0800 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 18uzlE-00071o-00 for namedroppers@ops.ietf.org; Mon, 17 Mar 2003 10:55:00 -0800 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h2HHdVv07235 for ; Mon, 17 Mar 2003 09:39:31 -0800 Date: Mon, 17 Mar 2003 09:39:31 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed Resolution to LLMNR Issue #3 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.1 required=5.0 tests=SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Issue 3: Use of LLMNR? Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: March 7, 2003 Reference: Document: LLMNR-13 Comment type: T Priority: S Section: Rationale/Explanation of issue: It seems unwise to send an LLMNR query for any name and RR if the DNS server does not respond or responds with NXRRSET. In practice, no response or NXRRSET will occur quite often, even if the DNS server is functioning. This is was shown by Jung, et al. "DNS Performance and Effectiveness of Caching", IEEE/ACM Transactions on Networking, October 2002, Volume 10, Number 5, pp. 589-603. For example, in the study 23 percent of all client lookups were not answered in an MIT data set collected in December 2000. 13 percent of lookups result in an answer that indicates an error. Most of these errors indicate that the desired name does not exist (NXDOMAIN). Inverse lookups often cause errors, as do NS records that point to nonexistent servers. As a result, it seems unwise to fallback to an LLMNR query for any query, just because the DNS server doesn't answer, or answers with NXRRSET. My proposal is not to fallback to LLMNR in the following cases: a. A PTR RR query for an address that does not exist on the local link (either a LL address or a routable address on the local link). In this case, the query won't be resolved via LLMNR so there is no point in sending it. So PTR RR queries should only be sent when the address is a local prefix. b. Any RR query for a name that has a "." and is not in the default domain. In this case we aren't talking about a local machine name, or even a hostname that is reasonably familiar. It could be a name of an arbitrary host on the Internet. We don't want to send LLMNR queries for those names, since LLMNR Responses are so easily spoofed. So only fallback to LLMNR if the name has no "." or is in the default domain. Change Section 3 to the following: "3. Usage model LLMNR is a peer-to-peer name resolution protocol that is not intended as a replacement for DNS. By default, LLMNR requests SHOULD be sent only when no manual or automatic DNS configuration has been performed, when DNS servers do not respond, or when they respond to a query with an RCODE set to NXRRSET. As noted in [DNSPerf], even when DNS servers are configured, a significant fraction of DNS queries do not receive a response, or result in a negative responses due to missing inverse mappings or NS records that point to nonexistent or inappropriate hosts. Given this, support for LLMNR as a secondary name resolution mechanism has the potential to result in a large number of inappropriate queries without the following additional restrictions: [1] Prior to falling back to LLMNR, a DNS query SHOULD be retransmitted at least once. As noted in [DNSPerf] additional retransmissions do not significantly increase the probability of receiving a response. [2] A sender SHOULD send LLMNR queries only for names that are either unqualified or exist within the default domain. [3] A sender SHOULD NOT send LLMNR queries for PTR RRs that correspond to addresses known not to exist on the local link. Since legitimate responses to LLMNR queries can only come from hosts on the local link, an LLMNR query for an address not on the local link cannot elicit a legitimate response. [4] A responder with both linklocal and routable addresses SHOULD respond only to LLMNR queries for A/AAAA RRs for the routable address. This encourages use of the routable address for establishment of new connections." -- to unsubscribe send a message to namedroppers-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 17 14:05:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25188 for ; Mon, 17 Mar 2003 14:05:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uzmE-00077S-00 for namedroppers-data@psg.com; Mon, 17 Mar 2003 10:56:02 -0800 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 18uzm9-00076n-00 for namedroppers@ops.ietf.org; Mon, 17 Mar 2003 10:55:58 -0800 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h2HHeTp07287 for ; Mon, 17 Mar 2003 09:40:29 -0800 Date: Mon, 17 Mar 2003 09:40:29 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed resolution to LLMNR Issue #4 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.2 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Issue 4: Introduction Unclear Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: March 7, 2003 Reference: Document: LLMNR-13 Comment type: T Priority: S Section: Rationale/Explanation of issue: The introduction is unclear that LLMNR is not a replacement for DNS. Having the text explicitly say that LLMNR cannot be used for communication outside a single link would make sense. Replace Section 1 with the following: "1. Introduction This document discusses Link-Local Multicast Name Resolution (LLMNR), which operates on a separate port from DNS, with a distinct resolver cache, but does not change the format of DNS packets. LLMNR supports all current and future DNS formats, types and classes. However, since LLMNR only operates on the local link, it cannot be considered a substitute for DNS. The goal of LLMNR is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. These include scenarios in which hosts are not configured with the address of a DNS server, where configured DNS servers do not reply to a query, or where they respond with RCODE set to NXRRSET. LLMNR queries are sent to and received on port TBD using a LINKLOCAL address as specified in "Administratively Scoped IP Multicast" [RFC2365] for IPv4 and the "solicited name" LINKLOCAL multicast addresses for IPv6, and using a unicast address as described in Section 2.3. The LLMNR LINKLOCAL address to be used for IPv4 is 224.0.0.251. LINKLOCAL addresses are used to prevent propagation of LLMNR traffic across routers, potentially flooding the network. Propagation of LLMNR packets on the local link is considered sufficient to enable name resolution in small networks. The assumption is that if a network has a home gateway, then the network either has a DNS server or the home gateway can function as a DNS proxy. By implementing DHCPv4 as well as a DNS proxy and dynamic DNS, home gateways can provide name resolution for the names of hosts over IPv4 on the local network. For small IPv6 networks, equivalent functionality can be provided by a home gateway implementing DHCPv6 for DNS configuration [DHCPv6DNS], as well as a DNS proxy supporting AAAA RRs and dynamic DNS, providing name resolution for the names of hosts over IPv6 on the local network. This should be adequate as long as home gateways implementing DNS configuration also support dynamic DNS in some form. In the future, LLMNR may be defined to support greater than LINKLOCAL multicast scope. This would occur if LLMNR deployment is successful, the assumption that LLMNR is not needed on multiple links proves incorrect, and multicast routing becomes ubiquitous. For example, it is not clear that this assumption will be valid in large adhoc networking scenarios. Once we have experience in LLMNR deployment in terms of administrative issues, usability and impact on the network it will be possible reevaluate which multicast scopes are appropriate for use with multicast name resolution mechanisms. Service discovery in general, as well as discovery of DNS servers using LLMNR in particular is outside of the scope of this document, as is name resolution over non-multicast capable media." -- to unsubscribe send a message to namedroppers-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 17 14:05:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25226 for ; Mon, 17 Mar 2003 14:05:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uzig-0006vZ-00 for namedroppers-data@psg.com; Mon, 17 Mar 2003 10:52:22 -0800 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 18uzia-0006vB-00 for namedroppers@ops.ietf.org; Mon, 17 Mar 2003 10:52:17 -0800 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h2HHalh07108 for ; Mon, 17 Mar 2003 09:36:47 -0800 Date: Mon, 17 Mar 2003 09:36:47 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed Resolution to LLMNR Issue #1 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.6 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Issue 1: Multihomed hosts Submitter: Joshua Graessley Submitter email address: jgraessley@apple.com Date first submitted: November 1, 2002 Reference: Document: LLMNR-12 Comment type: T Priority: S Section: 6.2 Rationale/Explanation of issue: In section 6.2, Usage Restrictions: > As noted in Section 3.1, LLMNR is intended for usage in scenarios where > a DNS server is not configured. If an interface has been configured > for > a given protocol via any automatic configuration mechanism which is > able > to supply DNS configuration information, then LLMNR SHOULD NOT be used > on that interface for that protocol unless it has been explicitly > enabled, whether via that mechanism or any other. This ensures that > upgraded hosts do not change their default behavior, without requiring > the source of the configuration information to be simultaneously > updated. This implies that on the interface, the host will neither > listen on the LINKLOCAL multicast address, nor will it send queries to > that address. If a multi-homed host is connected to a configured network and an unconfigured network, it may want to perform LLMNR to find hosts on the unconfigured network. This conflicts with the security concerns that suggest LLMNR should not be used. It is unclear if LLMNR could be used in this case, but only for unqualified names. If LLMNR is supposed to be used only for unqualified names, how does one resolve conflicts between an unqualified name resolved via LLMNR and the fully qualified name created by appending the "current domain". This limits, in very difficult to guess ways, the names that could be used with LLMNR on the unconfigured link. Example: My laptop has a wireless interface and an ethernet jack. I may have my ethernet jack connected to a network with a global IPv4 address and a DNS server both of which I received from a DHCP server. The DHCP server also told me that my current domain is "graessley.net". My wireless interface may be used only to connect to an 802.11 printer nearby. My printer may have a LLMNR name of "printer". Since I have a configured DNS server and a current domain, my resolver library will probably query "printer.graessley.net" before trying "printer". This makes it impossible to find my printer by name. It is unclear what names I could use for the printer. Any host that connects wirelessly to my printer may search any number of other domains if the host is also connected to another network. What am I overlooking? -josh [BA] I agree that the situation you present is problematic. Below is a proposed resolution. Change section 3.1 to the following: "3.1. Unqualified names The same host MAY use LLMNR queries for the resolution of unqualified host names, and conventional DNS queries for resolution of other DNS names. If a name is not qualified and does not end in a trailing dot, for the purposes of LLMNR, the implicit search order is as follows: [1] Request the name with the current domain appended. [2] Request just the name. This is the behavior suggested by [RFC1536]. LLMNR uses this technique to resolve unqualified host names." -- to unsubscribe send a message to namedroppers-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 17 14:05:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25244 for ; Mon, 17 Mar 2003 14:05:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uzk4-0006yS-00 for namedroppers-data@psg.com; Mon, 17 Mar 2003 10:53:48 -0800 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 18uzk1-0006y7-00 for namedroppers@ops.ietf.org; Mon, 17 Mar 2003 10:53:46 -0800 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h2HHcGY07183 for ; Mon, 17 Mar 2003 09:38:16 -0800 Date: Mon, 17 Mar 2003 09:38:16 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed (partial) resolution to LLMNR Issue #2 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.1 required=5.0 tests=SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Issue 2: TTL=255 on Send, Check on Receive? Submitter: Christian Huitema Submitter email address: huitema@microsoft.com Date first submitted: March 7, 2003 Reference: Document: LLMNR-13 Comment type: T Priority: S Section: Rationale/Explanation of issue: Why is it necessary to set TTL=255 on Sending an LLMNR Response, and then to check this on receipt? All you really care about is that the responder is on the same link. So check that the Request is sent to the LLMNR multicast address, rather than to a unicast address. That is enough. [BA] -- There are cases when LLMNR requests need to be sent via unicast so this cannot be prohibited. With respect to the TTL=255 check, the question is how to limit LLMNR responses to hosts on the local link. Do you have a suggestion? Here is a proposed changes to clarify the use of unicast queries as well as use of IP and DNS TTL: "2.3. Unicast queries A sender MUST NOT send a unicast LLMNR query except when: a. A sender repeats a query after it received a response to the previous LLMNR query with the TC bit set, or b. The sender's LLMNR cache contains an NS resource record that enables the sender to send a query directly to the hosts authoritative for the name in the query. If a TC (truncation) bit is set in the response, then the sender MAY use the response if it contains all necessary information, or the sender MAY discard the response and resend the query over TCP or using EDNS0 with larger window using the unicast address of the responder. The RA (Recursion Available) bit in the header of the response MUST NOT be set. If the RA bit is set in the response header, the sender MUST ignore it. 2.4. Addressing For IPv4 LINKLOCAL addressing, section 2.4 of "Dynamic Configuration of IPv4 Link-Local Addresses" [IPV4Link] lays out the rules with respect to source address selection, TTL settings, and acceptable source/destination address combinations. IPv6 is described in [RFC2460]; IPv6 LINKLOCAL addressing is described in [RFC2373]. LLMNR queries and responses MUST obey the rules laid out in these documents. In composing an LLMNR response, the responder MUST set the Hop Limit field in the IPv6 header and the TTL field in IPv4 header of the LLMNR response to 255. The sender MUST verify that the Hop Limit field in IPv6 header and TTL field in IPv4 header of each response to the LLMNR query is set to 255. If it is not, then sender MUST ignore the response. Implementation note: In the sockets API for IPv4, the IP_TTL and IP_MULTICAST_TTL socket options are used to set the TTL of outgoing unicast and multicast packets. The IP_RECVTTL socket option is available on some platforms to retrieve the IPv4 TTL of received packets with recvmsg(). [RFC2292] specifies similar options for setting and retrieving the IPv6 Hop Limit. 2.5. DNS TTL The responder should use a pre-configured TTL value in the records returned in the LLMNR query response. Due to the TTL minimalization necessary when caching an RRset, all TTLs in an RRset MUST be set to the same value. In the additional and authority section of the response the responder includes the same records as a DNS server would insert in the response to the unicast DNS query." -- to unsubscribe send a message to namedroppers-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 17 14:06:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25306 for ; Mon, 17 Mar 2003 14:06:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uzms-0007BT-00 for namedroppers-data@psg.com; Mon, 17 Mar 2003 10:56:42 -0800 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 18uzmo-0007BG-00 for namedroppers@ops.ietf.org; Mon, 17 Mar 2003 10:56:39 -0800 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h2HHfA807318 for ; Mon, 17 Mar 2003 09:41:10 -0800 Date: Mon, 17 Mar 2003 09:41:10 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed resolution to LLMNR Issue #5 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.1 required=5.0 tests=SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Issue 5: Jittering Submitter: Christian Huitema Submitter email address: huitema@microsoft.com Date first submitted: March 7, 2003 Reference: Document: LLMNR-13 Comment type: T Priority: S Section: 2 Rationale/Explanation of issue: The specification does not require jittering of LLMNR Requests, and is vague on jittering of LLMNR Responses. This is can cause synchronization problems. Insert the following text in Section 2: "In order to avoid synchronization of LLMNR queries and Responses, LLMNR Requests and Responses are delayed by a time uniformly distributed between 0 and 200 ms." -- to unsubscribe send a message to namedroppers-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 17 14:06:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25329 for ; Mon, 17 Mar 2003 14:06:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uzob-0007Km-00 for namedroppers-data@psg.com; Mon, 17 Mar 2003 10:58:29 -0800 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 18uzoX-0007KE-00 for namedroppers@ops.ietf.org; Mon, 17 Mar 2003 10:58:25 -0800 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h2HHguh07416 for ; Mon, 17 Mar 2003 09:42:56 -0800 Date: Mon, 17 Mar 2003 09:42:56 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: LLMNR Issue 6: Multicast groups Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.2 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The overall question arising from this issue is whether the IPv6 multicast group usage advocated in LLMNR-13 is viable or not. I don't have any opinions either way. Comments solicited. Issue 6: IPv6 Multicast Groups Submitter: Mika Liljeberg Submitter email address: mika.liljeberg@welho.com Date first submitted: March 8, 2003 Reference: Document: LLMNR-13 Comment type: T Priority: S Section: Rationale/Explanation of issue: Reading the draft I get the understanding that, in order to respond to reverse queries for IPv6 addresses, the host has to configure the following sixteen multicast addresses on each of its interfaces: FF02:0:0:0:0:2:MD5("0") .. FF02:0:0:0:0:2:MD5("F") In addition, a host may have multiple aliases (especially if it is multihomed), so the number of multicast groups that need to be configured per inteface could be close to twenty. This is clearly a waste of multicast filters. It is unlikely (correct me if I'm wrong) that a NIC will support this many multicast filters in hardware, which means that the NIC will have to be configured to receive all multicasts and the filtering must be done in software. That pretty much defeats the purpose of having the hash based solicited name multicast addresses in the first place. It would seem much better to just have a single well-known IPv6 link-local multicast address for reverse lookups. The alternative would seem to be to not support PTR queries at all for IPv6 addresses. I leave it to the discretion of the editors to decide whether this should be formulated as an issue. MikaL Comment from Bill Sommerfeld : I just took a look at drivers for a few commonly used fast ethernet chipsets, and found the following limits: - 80 literal multicast addresses - 64-entry hash. - 128-entry hash. - 256-entry hash. - 512-entry hash. The "N-entry hash" variety maintain a N-bit vector, and run the recieved multicast address through a hash function with N possible outputs; if the corresponding bit in the vector is set, the packet is received, so you get more graceful degradation as the number of groups increases at the cost of slightly more false positives received. MikaL: That's a pretty neat approach. The longer bit vectors sound good enough, although I still can't say that I like the idea of having to listen to 16 different multicast groups just for doing PTR queries. [It would be possible to optimize this, of course, but that would force the LLMNR responder to actively monitor all changes in interface configuration.] One 802.11 card I looked at has a lower limits (16 literal addresses). Another 802.11 card seems to have no multicast filtering at all! (though that may be an inadequate driver rather than a deficiency in the hardware/firmware). MikaL: Needless to say, 802.11 and other wireless interfaces would be a major use case for LLMNR. [BA] -- Based on its addresses and names, a host only need listen on the multicast groups corresponding to these. So it performs the hash on the name or variants of it ("foobar", "foobar.example.com"), and the addresses ("4.137.57.204.in-addr.arpa") and listens only on those groups. This may be inconvenient in that there may be several variants of the name, so that an implementation may end up listening on most of the multicast groups anyway. Also, the use of multiple multicast addresses means that a legacy host cannot easily be configured to send an LLMNR query, just be adding a multicast address to the resolver configuration. Overall, I'm not sure that the multicast group usage is really defensible, but I'd like to hear other people's opinion. Note that the "ease of configuration" issue may not be that crucial since a host configured that way would not easily be able to limit LLMNR queries as suggested in Section 3, nor would they be able to handle queries over TCP as suggested in Section 2.3. -- to unsubscribe send a message to namedroppers-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 17 14:16:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25760 for ; Mon, 17 Mar 2003 14:16:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uztX-0007kO-00 for namedroppers-data@psg.com; Mon, 17 Mar 2003 11:03:35 -0800 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 18uztU-0007k8-00 for namedroppers@ops.ietf.org; Mon, 17 Mar 2003 11:03:32 -0800 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h2HHm2Q07766 for ; Mon, 17 Mar 2003 09:48:02 -0800 Date: Mon, 17 Mar 2003 09:48:02 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed resolution of LLMNR Issue 7 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.9 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk For a list of LLMNR issues, please see: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html Issue 7: Advertisement of LL addresses Submitter: Erik Nordmark Submitter email address: erik.nordmark@eng.sun.com Date first submitted: November 4, 2002 Reference: Document: LLMNR-12 Comment type: T Priority: S Section: Rationale/Explanation of issue: > Since automatic IPv6 DNS configuration mechanisms such as [DHCPv6DNS] > and [DNSDisc] are not yet widely deployed, and not all DNS servers > support IPv6, "partial configuration" may be common in the short > term, and LLMNR may prove useful in enabling linklocal name resolution > over IPv6. However, in the long term, IPv6 DNS configuration, and DNS > support over IPv6 will become more common so that LLMNR usage will > typically be > restricted to adhoc networks in which neither IPv4 nor IPv6 DNS servers > are configured, and situations in which DNS servers do not respond to > queries." The above doesn't speculate about a future where names to global addresses can be resolved using DNS, but names to link-local addresses can only be resolved using LLMNR. The high-order question is whether the LLMNR spec should speculate about this future or not. [BA Comment]: Currently, the draft doesn't state what addresses an LLMNR responder will include in its A/AAAA RR query response. Are you suggesting that it should respond *only* with a linklocal address? [Erik Nordmark Comment]: I'm suggesting that we don't know the answer to that question yet. And the draft, by saying that the applicability is likely to be limited to adhoc networks, says that we do know the answer to the question. So leaving the applicability a bit more open-ended might be useful. Note that ideally we'd use global addresses for all application use, since limited scope addresses can cause problems for applications. But the thing I don't know is whether this will always be sufficient or whether there will be cases where it makes sense to use LLMNR to get a link-local address back even in cases when the network is connected to the Internet. Erik [BA comment]: It seems unwise to advertise a LL address (IPv4 or IPv6) in an LLMNR Response if a routable address is available. This will only encourage the querier to contact the responder on the LL address. Add the following text to section 4: "[4] A responder with both linklocal and routable addresses SHOULD respond only to LLMNR queries for A/AAAA RRs for the routable address. This encourages use of the routable address for establishment of new connections." -- to unsubscribe send a message to namedroppers-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 17 14:17:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25786 for ; Mon, 17 Mar 2003 14:17:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uzvk-0007xs-00 for namedroppers-data@psg.com; Mon, 17 Mar 2003 11:05:52 -0800 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 18uzvg-0007ww-00 for namedroppers@ops.ietf.org; Mon, 17 Mar 2003 11:05:48 -0800 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h2HHoJk07888 for ; Mon, 17 Mar 2003 09:50:19 -0800 Date: Mon, 17 Mar 2003 09:50:19 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed resolution to LLMNR Issue 8 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.1 required=5.0 tests=SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Issue 8: Conflict resolution Submitter: Mika Liljeberg Submitter email address: mika.liljeberg@welho.com Date first submitted: March 11, 2003 Document: LLMNR-13 Comment type: T Priority: S Section: 5 Rationale/Explanation of issue: Section 5 states: Every responder that responds to a LLMNR query and/or dynamic update request AND includes a UNIQUE record in the response: 1. MUST verify that there is no other host within the scope of the LLMNR query propagation that can return a resource record for the same name, type and class. 2. MUST NOT include a UNIQUE resource record in the response without having verified its uniqueness. How does a responder know whether a particular RR that it owns is UNIQUE or not? Looks like this attribute has to be manually configured for every RR on every authoritative responder. Is this interpretation correct? I suppose an implementation can simply choose to not support cluster names and just assert that every RR it owns is UNIQUE. MikaL [BA] - I believe that the default assumption is that the RR is UNIQUE unless it is configured otherwise. Add the following to Section 4: "By default, a host SHOULD be configured to behave as though all RRs are UNIQUE." -- to unsubscribe send a message to namedroppers-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 17 14:21:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25895 for ; Mon, 17 Mar 2003 14:21:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18v02e-0008Yq-00 for namedroppers-data@psg.com; Mon, 17 Mar 2003 11:13:00 -0800 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 18v02Y-0008XN-00 for namedroppers@ops.ietf.org; Mon, 17 Mar 2003 11:12:54 -0800 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h2HHvPP08222 for ; Mon, 17 Mar 2003 09:57:25 -0800 Date: Mon, 17 Mar 2003 09:57:25 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed resolution to LLMNR Issue 21 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.5 required=5.0 tests=SPAM_PHRASE_03_05,USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Issue 21: PTR queries Submitter: Markku Savela Submitter email address: msa@burp.tkv.asdf.org Date first submitted: November 4, 2002 Reference: <200211041445.QAA12218@burp.tkv.asdf.org> Document: LLMNR-12 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: I assume that if you end up doing a address (fe80::1) to name query for IPv6, you end up sending a query to IPv6 multicast address generated from the hash of "1.0.0. ... 0.0.8.e.f.ip6.int" and because the hash is taken from the first label, this will be MD5 from "1"? (basically only 16 different hashes are possible). IPv4 side you have for example "1.2.254.169.in-addr.arpa". Am I right assuming the "resolvers" on nodes have to deal also with these for link local name resolution? [BA] Yes, it is expected that senders will send PTR queries, and that receivers will respond to them. However, it probably doesn't make sense to send a PTR query for an address that isn't on the local link. Here's the proposed resolution: Add the following text to Section 3: "[3] A sender SHOULD NOT send LLMNR queries for PTR RRs that correspond to addresses known not to exist on the local link. Since legitimate responses to LLMNR queries can only come from hosts on the local link, an LLMNR query for an address not on the local link cannot elicit a legitimate response." -- to unsubscribe send a message to namedroppers-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 17 14:26:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26180 for ; Mon, 17 Mar 2003 14:26:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18v04P-0008hb-00 for namedroppers-data@psg.com; Mon, 17 Mar 2003 11:14:49 -0800 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 18v04L-0008gm-00 for namedroppers@ops.ietf.org; Mon, 17 Mar 2003 11:14:46 -0800 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.3/8.12.3/Debian-5) with ESMTP id h2HJEcI1016454; Mon, 17 Mar 2003 20:14:38 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.3/8.12.3/Debian-5) with ESMTP id h2HJEbkk016451; Mon, 17 Mar 2003 20:14:37 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Mon, 17 Mar 2003 20:14:37 +0100 (CET) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: Olaf Kolkman cc: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: Key-Signing Key (KSK) Flag In-Reply-To: <200303171732.h2HHWR12027276@birch.ripe.net> Message-ID: References: <200303171732.h2HHWR12027276@birch.ripe.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-3.7 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT_PINE,X_AUTH_WARNING version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 17 Mar 2003, Olaf Kolkman wrote: > In somewhat more detail: > > Based on experiences during the recent workshop we came to the > conclusion that a signer (either the off-line or the on-line, in the > case of dynamically updated signer) needs to know which key is to be > used for signing the zone data. This can be done by using a second > bit. Just curious, but why not use the key with KSK bit = 0 ? Or maybe the signer can use the set of private keys available online in case of dynupd ? (I assume hygiene insists private ksk and the private zsk are not in the same room). Also, imho a ZSK is a subset of the KEY RRset, which in itself is a subset of zone data. The ZSK bit does the trick of making the KEY distinct from other keys in the apex RRset. The distinction is that the KSK is typically used for authentication of other keys. Anykey, just mey .02 euros. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 17 15:11:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28870 for ; Mon, 17 Mar 2003 15:11:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18v0hy-000Bdc-00 for namedroppers-data@psg.com; Mon, 17 Mar 2003 11:55:42 -0800 Received: from [3ffe:b80:2:a90::2] (helo=devil.pp.htv.fi) by psg.com with esmtp (Exim 3.36 #1) id 18v0hs-000BdD-00 for namedroppers@ops.ietf.org; Mon, 17 Mar 2003 11:55:37 -0800 Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) with ESMTP id h2HJuHwY029523; Mon, 17 Mar 2003 21:56:18 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) id h2HJuEjn029519; Mon, 17 Mar 2003 21:56:15 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LLMNR Issue 6: Multicast groups From: Mika Liljeberg To: Bernard Aboba Cc: namedroppers@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1047930974.28498.7.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 17 Mar 2003 21:56:14 +0200 X-Spam-Status: No, hits=-1.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, X_AUTH_WARNING version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Based on its addresses and names, a host only > need listen on the multicast groups corresponding to these. So it > performs the hash on the name or variants of it > ("foobar", "foobar.example.com"), and the > addresses ("4.137.57.204.in-addr.arpa") and listens only on those > groups. I'll just add that the addresses configured to an interface may change while the LLMNR responder is running (esp. with IPv6). This means that, either the responder has to begin by joining all multicast groups required for all possible reverse queries, or it must constantly monitor the configuration of every network interface while running, in order to notice any changes in the configured addresses. MikaL -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 17 16:22:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01862 for ; Mon, 17 Mar 2003 16:22:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18v1hQ-000G3V-00 for namedroppers-data@psg.com; Mon, 17 Mar 2003 12:59:12 -0800 Received: from burp.tkv.asdf.org ([212.16.99.49]) by psg.com with esmtp (Exim 3.36 #1) id 18v1hM-000G3D-00 for namedroppers@ops.ietf.org; Mon, 17 Mar 2003 12:59:09 -0800 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-5) with ESMTP id h2HKwoYR016059; Mon, 17 Mar 2003 22:58:50 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-5) id h2HKwofx016055; Mon, 17 Mar 2003 22:58:50 +0200 Date: Mon, 17 Mar 2003 22:58:50 +0200 Message-Id: <200303172058.h2HKwofx016055@burp.tkv.asdf.org> From: Markku Savela To: aboba@internaut.com CC: namedroppers@ops.ietf.org In-reply-to: (message from Bernard Aboba on Mon, 17 Mar 2003 09:57:25 -0800 (PST)) Subject: Re: Proposed resolution to LLMNR Issue 21 (and 7) References: X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Add the following text to Section 3: > > "[3] A sender SHOULD NOT send LLMNR queries for PTR RRs that > correspond to addresses known not to exist on the local link. > Since legitimate responses to LLMNR queries can only come from > hosts on the local link, an LLMNR query for an address not > on the local link cannot elicit a legitimate response." How is LLMNR supposed to find out whether an address is on link or not? I think this is getting really complex. I suggest that LLMNR only deals with link local addresses. Which brings me to the Issue 7 > Add the following text to section 4: > "[4] A responder with both linklocal and routable addresses > SHOULD respond only to LLMNR queries for A/AAAA RRs for > the routable address. This encourages use of the routable > address for establishment of new connections." I would go the other way: LLMNR should only return link local addresses, never routable address. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 17 17:26:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04842 for ; Mon, 17 Mar 2003 17:26:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18v2uE-000Lsl-00 for namedroppers-data@psg.com; Mon, 17 Mar 2003 14:16:30 -0800 Received: from gro.dd.org ([209.198.103.200]) by psg.com with esmtp (Exim 3.36 #1) id 18v2uA-000Lrm-00 for namedroppers@ops.ietf.org; Mon, 17 Mar 2003 14:16:26 -0800 Received: by gro.dd.org (Postfix, from userid 102) id 50A09319; Mon, 17 Mar 2003 17:16:25 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15990.18745.216034.218062@gro.dd.org> Date: Mon, 17 Mar 2003 17:16:25 -0500 From: tale@nominum.com (David C Lawrence) To: namedroppers@ops.ietf.org Subject: RE: DNSEXT WGLC: To OPT_IN or not to OPT-IN In-Reply-To: References: X-Spam-Status: No, hits=0.2 required=5.0 tests=IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hallam-Baker, Phillip writes: > I believe there has been consensus on the need for opt-in for > over a year. This belief is rooted in what? By what metric have you determined majority support for Opt-In with the ongoing arguments against it here? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 17 19:01:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08996 for ; Mon, 17 Mar 2003 19:01:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18v4MA-00034E-00 for namedroppers-data@psg.com; Mon, 17 Mar 2003 15:49:26 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18v4M8-00033k-00; Mon, 17 Mar 2003 15:49:24 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18v4M7-0002hB-00; Mon, 17 Mar 2003 18:49:23 -0500 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 17 Mar 2003 15:49:22 -0800 To: tale@nominum.com (David C Lawrence) Cc: namedroppers@ops.ietf.org Subject: RE: DNSEXT WGLC: To OPT_IN or not to OPT-IN References: <15990.18745.216034.218062@gro.dd.org> Message-Id: X-Spam-Status: No, hits=1.0 required=5.0 tests=OPT_IN,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> I believe there has been consensus on the need for opt-in for >> over a year. > This belief is rooted in what? By what metric have you determined > majority support for Opt-In with the ongoing arguments against it > here? let's not go down this rat-hole, as it is not phil's to decide/declare 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 Mon Mar 17 19:03:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09048 for ; Mon, 17 Mar 2003 19:03:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18v4RY-0003Xc-00 for namedroppers-data@psg.com; Mon, 17 Mar 2003 15:55:00 -0800 Received: from [2001:4f8:3:bb:2e0:81ff:fe10:67ab] (helo=as.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 18v4RV-0003Vx-00 for namedroppers@ops.ietf.org; Mon, 17 Mar 2003 15:54:58 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 879CD379EF8 for ; Mon, 17 Mar 2003 23:54:44 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN In-Reply-To: Message from tale@nominum.com (David C Lawrence) of "Mon, 17 Mar 2003 17:16:25 EST." <15990.18745.216034.218062@gro.dd.org> X-Mailer: MH-E 7.2; nmh 1.0.4; GNU Emacs 21.2.1 Date: Mon, 17 Mar 2003 23:54:44 +0000 Message-Id: <20030317235444.879CD379EF8@as.vix.com> X-Spam-Status: No, hits=0.7 required=5.0 tests=IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > I believe there has been consensus on the need for opt-in for over a year. > > This belief is rooted in what? By what metric have you determined > majority support for Opt-In with the ongoing arguments against it > here? "majority support" != "consensus". let's move on. -- to unsubscribe send a message to namedroppers-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 17 19:32:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10111 for ; Mon, 17 Mar 2003 19:32:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18v4wn-0006LV-00 for namedroppers-data@psg.com; Mon, 17 Mar 2003 16:27:17 -0800 Received: from thing.verisignlabs.com ([65.201.175.62] helo=cliffie.verisignlabs.com) by psg.com with esmtp (Exim 3.36 #1) id 18v4wk-0006KY-00 for namedroppers@ops.ietf.org; Mon, 17 Mar 2003 16:27:14 -0800 Received: from wl-130-243.wireless.ietf56.ietf.org (wl-130-243.wireless.ietf56.ietf.org [130.129.130.243]) (AUTH: LOGIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by cliffie.verisignlabs.com with esmtp; Mon, 17 Mar 2003 19:27:11 -0500 From: David Blacka Organization: Verisign, Inc. To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: Key-Signing Key (KSK) Flag Date: Mon, 17 Mar 2003 19:27:07 -0500 User-Agent: KMail/1.5 References: <200303171732.h2HHWR12027276@birch.ripe.net> In-Reply-To: <200303171732.h2HHWR12027276@birch.ripe.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200303171927.07388.davidb@verisignlabs.com> X-Spam-Status: No, hits=-4.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT, REFERENCES,SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02, USER_AGENT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday 17 March 2003 12:32 pm, Olaf Kolkman wrote: > Based on experiences during the recent workshop we came to the > conclusion that a signer (either the off-line or the on-line, in the > case of dynamically updated signer) needs to know which key is to be > used for signing the zone data. This can be done by using a second > bit. > > With this bit and some definition on the behaviour of the signer based > on the settings of the bit signers can do their work automatically. > > The behaviour of the signers given the states of the bit needs to be > clearly specified. > > KSK ZSK > 0 0 Signers treat this as an undefined state. > 1 0 The Key is used to sign the apex key set only. > 0 1 The Key is used to sign all zone date except the apex key set. > 1 1 The Key is used to sign all zone and apex key data. > > As in the current version of the draft the bit provide operational > hints and MUST not be used in resolving and verification. > > If during the working group meeting on Tuesday supports this idea I'd > like to modify the draft to incorporate these ideas and push a new > version in order 1-2 weeks. I don't think I agree with this. The reason why the KSK bit is a good idea is primarily that is has an on the wire use. Specifically, with the KSK bit, it is possible for the parent to query the child in-band to determine from which key(s) DS records should be calculated. The fact that it can also be used by the signer to automatically determine which keys are KSKs versus ZSKs might be a nice thing, but IMHO not the real reason for the bit. I agree that both humans and zone signing tools should be crystal clear about which keys are KSKs, ZSKs or both. But this can be done locally (for instance, by adding this information to the key file names). I cannot think of a wire use for the ZSK bit. -- David Blacka Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 17 20:08:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11457 for ; Mon, 17 Mar 2003 20:08:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18v5Va-0009yi-00 for namedroppers-data@psg.com; Mon, 17 Mar 2003 17:03:14 -0800 Received: from [2001:460:410:8128:202:2dff:fe0c:1097] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 18v5VW-0009v0-00 for namedroppers@ops.ietf.org; Mon, 17 Mar 2003 17:03:11 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.8/8.12.7) with ESMTP id h2I12bOe002394; Tue, 18 Mar 2003 12:02:37 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200303180102.h2I12bOe002394@drugs.dv.isc.org> To: David Blacka Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: DNSEXT WGLC: Key-Signing Key (KSK) Flag In-reply-to: Your message of "Mon, 17 Mar 2003 19:27:07 CDT." <200303171927.07388.davidb@verisignlabs.com> Date: Tue, 18 Mar 2003 12:02:37 +1100 X-Spam-Status: No, hits=0.2 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > On Monday 17 March 2003 12:32 pm, Olaf Kolkman wrote: > > > Based on experiences during the recent workshop we came to the > > conclusion that a signer (either the off-line or the on-line, in the > > case of dynamically updated signer) needs to know which key is to be > > used for signing the zone data. This can be done by using a second > > bit. > > > > With this bit and some definition on the behaviour of the signer based > > on the settings of the bit signers can do their work automatically. > > > > The behaviour of the signers given the states of the bit needs to be > > clearly specified. > > > > KSK ZSK > > 0 0 Signers treat this as an undefined state. > > 1 0 The Key is used to sign the apex key set only. > > 0 1 The Key is used to sign all zone date except the apex key > set. > > 1 1 The Key is used to sign all zone and apex key data. > > > > As in the current version of the draft the bit provide operational > > hints and MUST not be used in resolving and verification. > > > > If during the working group meeting on Tuesday supports this idea I'd > > like to modify the draft to incorporate these ideas and push a new > > version in order 1-2 weeks. > > I don't think I agree with this. > > The reason why the KSK bit is a good idea is primarily that is has an on the > wire use. Specifically, with the KSK bit, it is possible for the parent to > query the child in-band to determine from which key(s) DS records should be > calculated. The fact that it can also be used by the signer to > automatically determine which keys are KSKs versus ZSKs might be a nice > thing, but IMHO not the real reason for the bit. > > I agree that both humans and zone signing tools should be crystal clear > about which keys are KSKs, ZSKs or both. But this can be done locally (for > instance, by adding this information to the key file names). I cannot > think of a wire use for the ZSK bit. > > -- > David Blacka > Sr. Engineer Verisign Applied Research Remote debugging. If the intent of the key is clear/visble this is relatively easy. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 17 20:56:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12824 for ; Mon, 17 Mar 2003 20:56:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18v6El-000CC1-00 for namedroppers-data@psg.com; Mon, 17 Mar 2003 17:49:55 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #1) id 18v6Eh-000CBY-00 for namedroppers@ops.ietf.org; Mon, 17 Mar 2003 17:49:51 -0800 Received: from ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.8/8.11.6) with ESMTP id h2I1no12028083 for ; Tue, 18 Mar 2003 02:49:50 +0100 Message-Id: <200303180149.h2I1no12028083@birch.ripe.net> To: namedroppers@ops.ietf.org Subject: Workshop @ ISC report Date: Tue, 18 Mar 2003 02:49:50 +0100 From: Olaf Kolkman X-Spam-Status: No, hits=2.3 required=5.0 tests=OPT_IN,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk DNSSEC@ISI.EDU Testing Workshop Executive Summary. == Introduction ISC hosted a workshop to test new DNSSEC features between Wednesday March 12 and Friday March 14 2003. The workshop focused on issues that were currently added to the software and/or features that were not fully tested during previous workshops. One additional goal of this workshop was to record the complete testing infrastructure. Before the workshop a number of test issues were identified and test plans were written for these issues. During the first day of the workshop these test plans were finalized. This text serves as a summary of tests, discussions and feedback to the DNSEXT working group. A complete journal will be published on the ISC website shortly. The link is forthcoming. == Short description of tests and their results. What follows is a list of performed tests and their results and some general comments that the workshop had towards some of the issues currently on the table in the DNSEXT working group. Roughly following the agenda items on the DNSEXT agenda these are: * AD bit. No specific tests but in the workshop the bit seemed useful for first order trouble shooting. * Unknown RR types The type code rollover proposal depends on certain expected behavior in the presence of unknown RR types. Older resolvers should not choke on getting the new security records in any part of the answer. The old validators should not interpret the new records as security data. No specific tests were performed to trigger potential problems. While running code with new type code and mnemonics for DNSSEC RRs, no problems were seen during the workshop even in the presence of older resolvers. * DS version 13 draft A number of recursive servers (all older versions of bind) were queried to assess if problems occur when DS is returned in the additional section. No problems were found. Other corner cases that were identified and fixed in the specification were tested. No protocol specification bugs were found. * DNSSEC OPT-IN We tested OPT-IN. Some initial testing was done in Amsterdam in late January, so we revisited some of those tests and added some new ones. There is one issue with compliance of the current resolver with respect to the specs. It's noted that secure dynamic update and OPT-IN are not allowed but it was not tested if a dynamic server enforces this. One issue not covered in the previous version was implemented and tested. The issue is about an insecure delegation with an opt-in NXT at the same name. We configured for combinations - signed and unsigned zones in the OPT-IN span and in the signed span. No problems were found. Currently DS RRs are not allowed in OPT-IN (unsigned) spans, and this is probably a good thing. * KSK (Key Signing Key) Flag We came to the conclusion that for easier management we need more bits. A Signer (stand-alone and in a dynamically updated nameserver) needs to know more about the intended use of the keys, either 2 or 3 flags are needed. * Wildcard behavior. The BIND 9.3 private snapshot was tested for the behavior as specified in the clarification draft. - The server returned correct matches - The server returned correct denial of existence RRs - The verifier does not yet validate fully; it cannot tell if the correct wildcard match was applied by a server. - The behavior of wildcards in combination with CNAMEs needs more clarification. Additional items discussed during the workshop that are not part of the DNSEXT wg meeting but the group wanted to give feedback on. * IPv6 transport and DNSSEC Tests of DNSSEC over IPv4 and IPv6 transport (including mixed IPv4/IPv6 and IPv6 only at delegations) were concluded successfully. The group did not address the potential response packet size issues raised by IPv6 in combination with DNSSEC data and encourages considerations of the Paul Vixie/Akira Kato draft submitted to DNSOP on this subject. * Discussion of the Type code roll Type code rollover of the SIG, KEY and NEXT DNSSEC RRs was been tested during the workshop. It works as was expected. The workshop saw this is a workable solution and supports the proposal as a simple, direct path to production DNSSEC deployment. * Inclusion of KEYs in the additional section The code we ran during the workshop did not add the KEY RR set to the additional section. We experienced no operational problems but we noticed additional latency during first lookup per zone. * Key management 'BCP' With respect to operations we came up with a procedure to roll the ZSK (Zone Signing Key). We concluded that a key management BCP document is needed. A long-lived evolving draft is The Way(TM) to proceed. The workshop did not discuss, test or comment on the following DNSSEC related issues. + DNSSEC roadmap document + The GSS-TSIG proposal + DNS Thread document + The DNSSEC 2535bis document set = The Whole Setup Configuration, zone and log files are stored in a CVS repository, for which a link is forthcoming. It can be used to bootstrap the setup in future workshops. Finally the workshop found some minor bugs in the implementation. They were not due to problems with the protocol specs. The bugs were reported. The workshop participants: Ed Lewis Michael Graff David Blacka Mans Nilsson Michael Richardson Sam Weiler Mark Andrews Olaf Kolkman Kazuhori Fujiwara Tomohiro "Sho" Ishihara Yashuhiro "Orange" Morishita Dave Perodin Rob Payne David Lawrence -- to unsubscribe send a message to namedroppers-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 17 21:08:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13168 for ; Mon, 17 Mar 2003 21:08:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18v6S9-000Cye-00 for namedroppers-data@psg.com; Mon, 17 Mar 2003 18:03:45 -0800 Received: from spratly.wl.nominum.com ([128.177.195.135]) by psg.com with esmtp (Exim 3.36 #1) id 18v6S4-000CyS-00 for namedroppers@ops.ietf.org; Mon, 17 Mar 2003 18:03:40 -0800 Received: from spratly.wl.nominum.com (spratly [127.0.0.1]) by spratly.wl.nominum.com (8.12.8/8.12.8) with ESMTP id h2I23edE008382; Mon, 17 Mar 2003 18:03:40 -0800 Received: from localhost (bwelling@localhost) by spratly.wl.nominum.com (8.12.8/8.12.8/Submit) with ESMTP id h2I23dVA008379; Mon, 17 Mar 2003 18:03:39 -0800 X-Authentication-Warning: spratly.wl.nominum.com: bwelling owned process doing -bs Date: Mon, 17 Mar 2003 18:03:39 -0800 (PST) From: Brian Wellington X-X-Sender: bwelling@spratly.wl.nominum.com To: Paul Vixie cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN In-Reply-To: <20030317235444.879CD379EF8@as.vix.com> Message-ID: References: <20030317235444.879CD379EF8@as.vix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT, REFERENCES,SPAM_PHRASE_00_01,USER_AGENT_PINE,X_AUTH_WARNING version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 17 Mar 2003, Paul Vixie wrote: > > > I believe there has been consensus on the need for opt-in for over a year. > > > > This belief is rooted in what? By what metric have you determined > > majority support for Opt-In with the ongoing arguments against it > > here? > > "majority support" != "consensus". let's move on. (definition 1, "Consensus" from Webster's Revised Unabridged Dictionary (1913)) Consensus \Con*sen"sus\, n. [L. See {Consent}.] Agreement; accord; consent. (definition 2, "consensus" from WordNet (r) 1.7) consensus n : agreement of the majority in sentiment or belief [syn: {general agreement}] I'm not sure what definition of consensus you're using. Brian -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 17 22:20:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14929 for ; Mon, 17 Mar 2003 22:20:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18v7XW-000Fvy-00 for namedroppers-data@psg.com; Mon, 17 Mar 2003 19:13:22 -0800 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 18v7XU-000Fvm-00 for namedroppers@ops.ietf.org; Mon, 17 Mar 2003 19:13:20 -0800 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h2I1vna02165; Mon, 17 Mar 2003 17:57:49 -0800 Date: Mon, 17 Mar 2003 17:57:48 -0800 (PST) From: Bernard Aboba To: Mika Liljeberg cc: namedroppers@ops.ietf.org Subject: Re: LLMNR Issue 6: Multicast groups In-Reply-To: <1047930974.28498.7.camel@devil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I'll just add that the addresses configured to an interface may change > while the LLMNR responder is running (esp. with IPv6). This means that, > either the responder has to begin by joining all multicast groups > required for all possible reverse queries, or it must constantly monitor > the configuration of every network interface while running, in order to > notice any changes in the configured addresses. It seems like a lot of complexity for not much benefit, particularly since the host will be joining multiple multicast groups anyway. It does make it harder for someone to just type in a multicast group into /etc/resolv.conf and send an LLMNR query. But since the port has been changed, that won't work anyway. So I'm inclined to move to use of a single multicast address for IPv6. -- to unsubscribe send a message to namedroppers-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 17 22:20:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14950 for ; Mon, 17 Mar 2003 22:20:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18v7UR-000FmY-00 for namedroppers-data@psg.com; Mon, 17 Mar 2003 19:10:11 -0800 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 18v7UN-000FmI-00 for namedroppers@ops.ietf.org; Mon, 17 Mar 2003 19:10:08 -0800 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h2I1sZx02000; Mon, 17 Mar 2003 17:54:35 -0800 Date: Mon, 17 Mar 2003 17:54:35 -0800 (PST) From: Bernard Aboba To: Markku Savela cc: namedroppers@ops.ietf.org Subject: Re: Proposed resolution to LLMNR Issue 21 (and 7) In-Reply-To: <200303172058.h2HKwofx016055@burp.tkv.asdf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02, USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > How is LLMNR supposed to find out whether an address is on link or > not? Presumably it looks at the routing table. > I think this is getting really complex. I suggest that LLMNR only > deals with link local addresses. Which brings me to the Issue 7 We don't have that option for IPv4. Zeroconf WG has decided that for IPv4, a linklocal address isn't advertised if a routable address is available. > > Add the following text to section 4: > > > "[4] A responder with both linklocal and routable addresses > > SHOULD respond only to LLMNR queries for A/AAAA RRs for > > the routable address. This encourages use of the routable > > address for establishment of new connections." > > I would go the other way: LLMNR should only return link local > addresses, never routable address. Since for IPV4 we'll not be able to do that, the question is whether IPv6 should behave differently. -- to unsubscribe send a message to namedroppers-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 18 00:17:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18471 for ; Tue, 18 Mar 2003 00:17:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18v9Ln-000LQI-00 for namedroppers-data@psg.com; Mon, 17 Mar 2003 21:09:23 -0800 Received: from thing.verisignlabs.com ([65.201.175.62] helo=cliffie.verisignlabs.com) by psg.com with esmtp (Exim 3.36 #1) id 18v9Lj-000LPm-00 for namedroppers@ops.ietf.org; Mon, 17 Mar 2003 21:09:19 -0800 Received: from wl-130-243.wireless.ietf56.ietf.org (wl-130-243.wireless.ietf56.ietf.org [130.129.130.243]) (AUTH: LOGIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by cliffie.verisignlabs.com with esmtp; Tue, 18 Mar 2003 00:09:12 -0500 From: David Blacka Organization: Verisign, Inc. To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: Key-Signing Key (KSK) Flag Date: Tue, 18 Mar 2003 00:09:08 -0500 User-Agent: KMail/1.5 References: <200303180102.h2I12bOe002394@drugs.dv.isc.org> In-Reply-To: <200303180102.h2I12bOe002394@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200303180009.08881.davidb@verisignlabs.com> X-Spam-Status: No, hits=-3.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT, REFERENCES,SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01, USER_AGENT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday 17 March 2003 08:02 pm, Mark.Andrews@isc.org wrote: > > I agree that both humans and zone signing tools should be crystal clear > > about which keys are KSKs, ZSKs or both. But this can be done locally (for > > instance, by adding this information to the key file names). I cannot > > think of a wire use for the ZSK bit. > Remote debugging. If the intent of the key is clear/visble > this is relatively easy. Remote debugging of what, exactly? Trying to figure out what the zone signing key is has never been an issue in any of the workshops that I've attended, AFAIK. Trying to figure out which key is the secure entry point HAS been an issue. -- David Blacka Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 18 00:52:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19794 for ; Tue, 18 Mar 2003 00:52:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18v9vV-000NGh-00 for namedroppers-data@psg.com; Mon, 17 Mar 2003 21:46:17 -0800 Received: from gro.dd.org ([209.198.103.200]) by psg.com with esmtp (Exim 3.36 #1) id 18v9vT-000NGD-00 for namedroppers@ops.ietf.org; Mon, 17 Mar 2003 21:46:15 -0800 Received: by gro.dd.org (Postfix, from userid 102) id 2EA8B33A; Tue, 18 Mar 2003 00:46:14 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15990.45734.93271.103063@gro.dd.org> Date: Tue, 18 Mar 2003 00:46:14 -0500 From: tale@nominum.com (David C Lawrence) To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN In-Reply-To: <20030317235444.879CD379EF8@as.vix.com> References: <15990.18745.216034.218062@gro.dd.org> <20030317235444.879CD379EF8@as.vix.com> X-Spam-Status: No, hits=1.0 required=5.0 tests=IN_REP_TO,OPT_IN,REFERENCES,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie writes: > "majority support" != "consensus". let's move on. Please forgive me if it is "support" you took exception with, when "majority" was meant to be my focus. Sorry for the sloppy language. The concept of majority does indeed occur in definitions of consensus, such as at m-w.com and the WordNet definition sent here. Even the Tao of the IETF says the following: The general rule on disputed topics is that the Working Group has to come to "rough consensus," meaning that a very large majority of those who care must agree. What I see here is that many of the people who care do NOT agree, and assertions to the contrary -- especially ones stating the belief that consensus was achieved a year ago -- should be substantiated. I'm unprepared to just "move on" at this point, particularly as I too am one of the people opposed to OPT-IN (on grounds that have all been presented by others here). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 18 00:55:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19842 for ; Tue, 18 Mar 2003 00:55:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vA08-000NXm-00 for namedroppers-data@psg.com; Mon, 17 Mar 2003 21:51:04 -0800 Received: from gro.dd.org ([209.198.103.200]) by psg.com with esmtp (Exim 3.36 #1) id 18vA04-000NXH-00 for namedroppers@ops.ietf.org; Mon, 17 Mar 2003 21:51:00 -0800 Received: by gro.dd.org (Postfix, from userid 102) id B8151325; Tue, 18 Mar 2003 00:50:59 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15990.46019.715482.78996@gro.dd.org> Date: Tue, 18 Mar 2003 00:50:59 -0500 From: tale@nominum.com (David C Lawrence) To: namedroppers@ops.ietf.org Subject: RE: DNSEXT WGLC: To OPT_IN or not to OPT-IN In-Reply-To: References: <15990.18745.216034.218062@gro.dd.org> X-Spam-Status: No, hits=0.2 required=5.0 tests=IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Randy Bush writes: > let's not go down this rat-hole, as it is not phil's to decide/declare Point taken. I'll be quiet about it now. (Messages came a little out of order.) -- to unsubscribe send a message to namedroppers-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 18 02:08:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00211 for ; Tue, 18 Mar 2003 02:08:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vB2i-00013u-00 for namedroppers-data@psg.com; Mon, 17 Mar 2003 22:57:48 -0800 Received: from burp.tkv.asdf.org ([212.16.99.49]) by psg.com with esmtp (Exim 3.36 #1) id 18vB2c-00013N-00 for namedroppers@ops.ietf.org; Mon, 17 Mar 2003 22:57:42 -0800 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-5) with ESMTP id h2I6vZYR020665; Tue, 18 Mar 2003 08:57:35 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-5) id h2I6vYxs020661; Tue, 18 Mar 2003 08:57:34 +0200 Date: Tue, 18 Mar 2003 08:57:34 +0200 Message-Id: <200303180657.h2I6vYxs020661@burp.tkv.asdf.org> From: Markku Savela To: aboba@internaut.com CC: namedroppers@ops.ietf.org In-reply-to: (message from Bernard Aboba on Mon, 17 Mar 2003 17:54:35 -0800 (PST)) Subject: Re: Proposed resolution to LLMNR Issue 21 (and 7) References: X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > From: Bernard Aboba > > I think this is getting really complex. I suggest that LLMNR only > > deals with link local addresses. Which brings me to the Issue 7 > > We don't have that option for IPv4. Zeroconf WG has decided that for IPv4, > a linklocal address isn't advertised if a routable address is available. ..and you know my opinion: Zeroconf WG made wrong decision. In my view the opinions of people whose agenda was to cripple LL4, won. -- to unsubscribe send a message to namedroppers-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 18 02:56:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03777 for ; Tue, 18 Mar 2003 02:56:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vBrT-0003dx-00 for namedroppers-data@psg.com; Mon, 17 Mar 2003 23:50:15 -0800 Received: from [3ffe:b80:2:a90::2] (helo=devil.pp.htv.fi) by psg.com with esmtp (Exim 3.36 #1) id 18vBrP-0003dD-00 for namedroppers@ops.ietf.org; Mon, 17 Mar 2003 23:50:12 -0800 Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) with ESMTP id h2I7oqwY032726; Tue, 18 Mar 2003 09:50:52 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) id h2I7op0k032724; Tue, 18 Mar 2003 09:50:51 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: Proposed resolution to LLMNR Issue 21 (and 7) From: Mika Liljeberg To: Bernard Aboba Cc: Markku Savela , namedroppers@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1047973850.28501.25.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 18 Mar 2003 09:50:50 +0200 X-Spam-Status: No, hits=-1.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, X_AUTH_WARNING version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 2003-03-18 at 03:54, Bernard Aboba wrote: > > How is LLMNR supposed to find out whether an address is on link or > > not? > > Presumably it looks at the routing table. > > > I think this is getting really complex. I suggest that LLMNR only > > deals with link local addresses. Which brings me to the Issue 7 > > We don't have that option for IPv4. Zeroconf WG has decided that for IPv4, > a linklocal address isn't advertised if a routable address is available. That decision has problems that zeroconf has not yet been able to solve. In a nutshell: two nodes with different configured netmasks are unable to communicate on the local link, unless they also have link-local addresses. [There are ad-hoc scenarios where this can easily happen.] At this point, it would be prudent to advertise all IPv4 addresses a node has and leave it to the client node to choose an appropriate address. > > > Add the following text to section 4: > > > > > "[4] A responder with both linklocal and routable addresses > > > SHOULD respond only to LLMNR queries for A/AAAA RRs for > > > the routable address. This encourages use of the routable > > > address for establishment of new connections." > > > > I would go the other way: LLMNR should only return link local > > addresses, never routable address. > > Since for IPV4 we'll not be able to do that, the question is whether IPv6 > should behave differently. With IPv6 the right thing, in my opinion, is to advertise link-local addresses only. All IPv6 nodes have link-local addresses and on-link routes for them, so link-locals will always work. However, as with IPv4, configured addresses are not guaranteed to work for link-local communication unless all nodes happen to have the same on-link prefixes. MikaL -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 18 04:04:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04644 for ; Tue, 18 Mar 2003 04:04:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vCw6-0006Rw-00 for namedroppers-data@psg.com; Tue, 18 Mar 2003 00:59:06 -0800 Received: from mx1.nic.ad.jp ([202.12.30.137]) by psg.com with esmtp (Exim 3.36 #1) id 18vCw4-0006Rd-00 for namedroppers@ops.ietf.org; Tue, 18 Mar 2003 00:59:04 -0800 Received: from spool.nic.ad.jp ([192.168.10.252]) by mx1.nic.ad.jp (8.9.3+3.2W/3.7W) with ESMTP id RAA23696; Tue, 18 Mar 2003 17:58:59 +0900 (JST) (envelope-from fujiwara@jprs.co.jp) Received: from sv003.jprs.co.jp (sv003.jprs.co.jp [192.168.10.3]) by spool.nic.ad.jp (8.9.3+3.2W/3.7W/JPNIC-spool.def,v-1.14-2003011314) with ESMTP id RAA05605; Tue, 18 Mar 2003 17:58:59 +0900 (JST) (envelope-from fujiwara@jprs.co.jp) Received: from localhost (localhost [127.0.0.1]) by sv003.jprs.co.jp (8.8.8+Sun/3.7W/JPNIC-v7-private-nospool.def,v-99091722) with ESMTP id RAA11798; Tue, 18 Mar 2003 17:58:58 +0900 (JST) (envelope-from fujiwara@jprs.co.jp) To: olaf@ripe.net Cc: namedroppers@ops.ietf.org Subject: Re: Workshop @ ISC report From: Kazunori Fujiwara In-Reply-To: Your message of "Tue, 18 Mar 2003 02:49:50 +0100" <200303180149.h2I1no12028083@birch.ripe.net> References: <200303180149.h2I1no12028083@birch.ripe.net> X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20030318175858A.fujiwara@sv003.jprs.co.jp> Date: Tue, 18 Mar 2003 17:58:58 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 31 X-Spam-Status: No, hits=-0.5 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, nice summary. > From: Olaf Kolkman > DNSSEC@ISI.EDU Testing Workshop > Executive Summary. snip > The workshop participants: > > Ed Lewis > Michael Graff > David Blacka > Mans Nilsson > Michael Richardson > Sam Weiler > Mark Andrews > Olaf Kolkman > Kazuhori Fujiwara s/h/n/ please. > Tomohiro "Sho" Ishihara > Yashuhiro "Orange" Morishita > Dave Perodin > Rob Payne > David Lawrence -- Fujiwra, Kazunori JPRS -- to unsubscribe send a message to namedroppers-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 18 11:33:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16709 for ; Tue, 18 Mar 2003 11:33:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vJob-0001Ie-00 for namedroppers-data@psg.com; Tue, 18 Mar 2003 08:19:49 -0800 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 18vJoX-0001Gw-00 for namedroppers@ops.ietf.org; Tue, 18 Mar 2003 08:19:45 -0800 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h2IF46I13564; Tue, 18 Mar 2003 07:04:06 -0800 Date: Tue, 18 Mar 2003 07:04:06 -0800 (PST) From: Bernard Aboba To: Mika Liljeberg cc: Markku Savela , Subject: Re: Proposed resolution to LLMNR Issue 21 (and 7) In-Reply-To: <1047973850.28501.25.camel@devil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03, USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > That decision has problems that zeroconf has not yet been able to solve. > In a nutshell: two nodes with different configured netmasks are unable > to communicate on the local link, unless they also have link-local > addresses. [There are ad-hoc scenarios where this can easily happen.] If you disagree with the resolution of LLv4 Issue #23, I'd suggest that you bring that up on the Zeroconf WG mailing list. Here's the text as adopted: "Having addresses of multiple different scopes assigned to an interface with no adequate way to determine in what circumstances each address should be used leads to complexity for applications and confusion for users. A node with any address assigned for a link can communicate with all other devices on that link, whether those other devices use link-local addresses, or routable addresses. For this reason, a host that obtains, or is configured with, a routable address on an interface, SHOULD NOT attempt to configure a link-local address on the same interface. Where a link-local address has been configured on an interface, and a routable address is later configured on the same interface, the host MUST always use the routable address when initiating new communications, and MUST cease advertising the availability of the link-local address through whatever mechanisms that address had been made known to others. A host SHOULD continue to use the link-local address for communications underway when the routable address was configured, and MAY continue to accept new communications addressed to the link-local address." > At this point, it would be prudent to advertise all IPv4 addresses a > node has and leave it to the client node to choose an appropriate > address. Since the language says MUST cease, I don't believe that we have the option of continuing to advertise LLv4 addresses via LLMNR if a routable address is also available. Of course, there is no such mandate for IPv6, so we could take a different course there (although justification is required, for course). -- to unsubscribe send a message to namedroppers-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 18 12:54:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20560 for ; Tue, 18 Mar 2003 12:54:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vL6u-0005wD-00 for namedroppers-data@psg.com; Tue, 18 Mar 2003 09:42:48 -0800 Received: from cyphermail.sandelman.ottawa.on.ca ([192.139.46.78] helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 3.36 #1) id 18vL6r-0005vc-00 for namedroppers@ops.ietf.org; Tue, 18 Mar 2003 09:42:45 -0800 Received: from sandelman.ottawa.on.ca (wl-142-230.wireless.ietf56.ietf.org [130.129.142.230]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h2IHfKD10446 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Tue, 18 Mar 2003 12:41:23 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1] (may be forged)) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h2IHfHAR018710 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 18 Mar 2003 09:41:19 -0800 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-5) with ESMTP id h2IHfHGQ018706 for ; Tue, 18 Mar 2003 09:41:17 -0800 Message-Id: <200303181741.h2IHfHGQ018706@marajade.sandelman.ottawa.on.ca> To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: Key-Signing Key (KSK) Flag In-reply-to: Your message of "Mon, 17 Mar 2003 19:27:07 EST." <200303171927.07388.davidb@verisignlabs.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 18 Mar 2003 09:41:16 -0800 From: Michael Richardson X-Spam-Status: No, hits=0.3 required=5.0 tests=IN_REP_TO,LINES_OF_YELLING,MAY_BE_FORGED,PGP_SIGNATURE, SPAM_PHRASE_08_13 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "David" == David Blacka writes: David> I don't think I agree with this. I don't agree that you don't agree! Your later text explains that you do. I claim you do agree. We (the humans) need to identify which is KSK and which is ZSK. Sometimes humans will ask the computer to help them figure it out, such as when the parent wants to know which key to download for offline verification. It is also useful so that humans can more easily be told by the tools, "I think that you made a mistake, add --I-really-mean-it if you are sure". ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPndaOYqHRg3pndX9AQEGeAP9Ffs4RskL9JQmu+biF4DCk7OKa88i+pnK nfTDSNSlJhe4ktw0hyuH/BF8YWU8G2yltD0spHtg4Zv3OJ/fsviloX59HiFzoxxt iuMdj4qc56NZmSyfpkiIzzUOiizv/ZZU8AU3Ri3IVCRQU3Q+tpF5wWp3utfcJJjc z3w+WU7kS00= =D9lf -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 18 13:05:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21141 for ; Tue, 18 Mar 2003 13:05:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vLKr-0006Z5-00 for namedroppers-data@psg.com; Tue, 18 Mar 2003 09:57:13 -0800 Received: from [2001:4f8:3:bb:2e0:81ff:fe10:67ab] (helo=as.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 18vLKp-0006Y8-00 for namedroppers@ops.ietf.org; Tue, 18 Mar 2003 09:57:11 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 2390F379EEF for ; Tue, 18 Mar 2003 17:56:58 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: llmnr vs. alternatives X-Mailer: MH-E 7.2; nmh 1.0.4; GNU Emacs 21.2.1 Date: Tue, 18 Mar 2003 17:56:58 +0000 Message-Id: <20030318175658.2390F379EEF@as.vix.com> X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk i withdrew my support for DISCOVER out of respect for stuart cheshire who has made significant progress on multicast dns issues inside apple (and has built a respectable installed base.) the litany of llmnr issues presented on namedroppers@ and at the san francisco dnsext meeting include several that were design considerations in the manning/vixie/woodcock "DISCOVER" proposal. if stuart's approach isn't, for whatever reason, going to be considered the standard, and we're going to readdress the basic problem, then i still think the DISCOVER approach is worthy of consideration. bill, as the last holder of the editor token, could you repost the draft? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 18 13:18:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21928 for ; Tue, 18 Mar 2003 13:18:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vLa5-0007Eb-00 for namedroppers-data@psg.com; Tue, 18 Mar 2003 10:12:57 -0800 Received: from [3ffe:b00:c18:3::a] (helo=jazz.viagenie.qc.ca) by psg.com with esmtp (Exim 3.36 #1) id 18vLa2-0007CC-00 for namedroppers@ops.ietf.org; Tue, 18 Mar 2003 10:12:54 -0800 Received: from localhost (retro.viagenie.qc.ca [206.123.31.22]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id h2IIC7u19601; Tue, 18 Mar 2003 13:12:07 -0500 (EST) Date: Tue, 18 Mar 2003 13:11:47 -0500 From: Marc Blanchet To: Donald.Eastlake@motorola.com cc: namedroppers@ops.ietf.org Subject: draft-ietf-dnsext-insensitive-01.txt Message-ID: <115420000.1048011104@classic.viagenie.qc.ca> In-Reply-To: <200303181741.h2IHfHGQ018706@marajade.sandelman.ottawa.on.ca> References: <200303181741.h2IHfHGQ018706@marajade.sandelman.ottawa.on.ca> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-0.5 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I would like to suggest to add a section to this draft about how case insensitivity is handled in idn, in order to get some references to additional related work (idn) that have important impact on case insensitivity for the user point of view. Regards, Marc. -- to unsubscribe send a message to namedroppers-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 18 13:22:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22171 for ; Tue, 18 Mar 2003 13:22:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vLbj-0007IX-00 for namedroppers-data@psg.com; Tue, 18 Mar 2003 10:14:39 -0800 Received: from [2001:490:f002:128:202:2dff:fe0c:1097] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 18vLbg-0007HU-00 for namedroppers@ops.ietf.org; Tue, 18 Mar 2003 10:14:36 -0800 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.8/8.12.7) with ESMTP id h2IIE4m1001812 for ; Wed, 19 Mar 2003 05:14:04 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200303181814.h2IIE4m1001812@drugs.dv.isc.org> To: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: draft-lewis-dns-wildcard-clarify-00.txt Date: Wed, 19 Mar 2003 05:14:04 +1100 X-Spam-Status: No, hits=1.8 required=5.0 tests=NO_REAL_NAME,SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The wg should adopt this document. The wg should look to clarify CNAME and NS wildcard records. * make wildcard CNAMEs work in all calling sequences. * wildcard NS records should be banned. Emtpy node exist is a NXT span and result in a NOERROR response. -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 18 13:43:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23151 for ; Tue, 18 Mar 2003 13:43:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vLwN-0008Uz-00 for namedroppers-data@psg.com; Tue, 18 Mar 2003 10:35:59 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #1) id 18vLwA-0008U5-00 for namedroppers@ops.ietf.org; Tue, 18 Mar 2003 10:35:46 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA20356 for ; Tue, 18 Mar 2003 11:35:45 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2IIZcP24494 for ; Tue, 18 Mar 2003 19:35:39 +0100 (MET) Date: Tue, 18 Mar 2003 19:31:36 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: LLMNR issue 21: PTR queries To: namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk As requested by the chair here is what I said in the meeting: In IPv6 Neighbor discovery the routers might be configured to operate so that the hosts are not told which prefixes are on the link (or not told about all of them). This works by packets going to the router and it being able to redirect to the destination should the destination be on link. Due to this the hosts can not always determine when the PTR query target is on-link. Hence it makes sense to always send the PTR queries in LLMNR. Erik -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 18 13:45:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23294 for ; Tue, 18 Mar 2003 13:45:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vLyX-0008bu-00 for namedroppers-data@psg.com; Tue, 18 Mar 2003 10:38:13 -0800 Received: from wl-131-235.wireless.ietf56.ietf.org ([130.129.131.235] helo=wl-131-245.wireless.ietf56.ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 18vLyU-0008bJ-00 for namedroppers@ops.ietf.org; Tue, 18 Mar 2003 10:38:11 -0800 Received: (from ggm@localhost) by wl-131-245.wireless.ietf56.ietf.org (8.11.6/8.11.6) id h2IIc4w20178; Wed, 19 Mar 2003 04:38:04 +1000 (EST) Date: Wed, 19 Mar 2003 04:38:04 +1000 From: George Michaelson Cc: namedroppers@ops.ietf.org Subject: Re: draft-lewis-dns-wildcard-clarify-00.txt Message-Id: <20030319043804.3fb8ce7f.ggm@apnic.net> In-Reply-To: <200303181814.h2IIE4m1001812@drugs.dv.isc.org> References: <200303181814.h2IIE4m1001812@drugs.dv.isc.org> Organization: APNIC Pty Ltd X-Mailer: Sylpheed version 0.8.10claws101 (GTK+ 1.2.10; i386--netbsdelf) X-Fruit-Of-The-Month-Club: persimmon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.3 required=5.0 tests=IN_REP_TO,MISSING_HEADERS,NOSPAM_INC,REFERENCES, SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Alain Durand has draft out in V6 contexts mentioning use of wildcard to make V6 reverse DNS scale better with an autoconfig mechanism. It does say they are understood to be evil -George draft-ietf-dnsop-ipv6-dns-issues-02.txt 4. Automatic population of the Reverse path DNS Getting the reverse tree DNS populated correctly in IPv4 is not an easy exercise and very often the records are not really up to date or simply are just not there. As IPv6 addresses are much longer than IPv4 addresses, the situation of the reverse tree DNS will probably be even worse. A fairly common practice from IPv4 ISP is to generate PTR records for home customers automatically from the IPv4 address itself. Something like: 1.2.3.4.in-addr.arpa. IN PTR 4.3.2.1.local-ISP.net It is not clear today if something similar need to be done in IPv6, and, if yes, what is the best approach to this problem. As the number of possible PTR records would be huge (2^80) for a /48 prefix, a possible solution would be to use wildcards entries like: *.0.1.2.3.4.5.6.7.8.9.a.b.c.ip6.arpa. IN PTR customer-42.local- ISP.net However, the use of wildcard is generally discouraged and this may not be an acceptable solution. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 18 13:47:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23545 for ; Tue, 18 Mar 2003 13:47:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vLwF-0008Um-00 for namedroppers-data@psg.com; Tue, 18 Mar 2003 10:35:51 -0800 Received: from ztxmail03.ztx.compaq.com ([161.114.1.207]) by psg.com with esmtp (Exim 3.36 #1) id 18vLwA-0008Tw-00 for namedroppers@ops.ietf.org; Tue, 18 Mar 2003 10:35:46 -0800 Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id 6734173EF for ; Tue, 18 Mar 2003 12:35:43 -0600 (CST) Received: from lassie.ucx.lkg.dec.com (lassie.ucx.lkg.dec.com [16.20.208.100]) by mailrelay01.cce.cpqcorp.net (Postfix) with SMTP id 03DA118D1 for ; Tue, 18 Mar 2003 12:35:43 -0600 (CST) Received: from unknown.hostname (16.47.200.108) by lassie.ucx.lkg.dec.com (V5.3-18E, OpenVMS V7.2-2 Alpha); Tue, 18 Mar 2003 13:35:38 -0500 (EST) Message-ID: <0afd01c2ed7d$384f9630$b800a8c0@PORTABRAIN> From: "M. T. Hollinger" To: References: Subject: Re: Proposed Resolution to LLMNR Issue #3 Date: Tue, 18 Mar 2003 13:35:52 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_OE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > My proposal is not to fallback to LLMNR in the following > cases: > > a. A PTR RR query for an address that does not exist on the local link > (either a LL address > or a routable address on the local link). In this case, the query won't be > resolved via LLMNR > so there is no point in sending it. So PTR RR queries should only be sent > when the address is a local prefix. I support this proposal. Although it is true (as was just mentioned at the San Francisco meeting) that there may be multiple subnets or IPv6 prefixes on the same link, some of which are unknown to the host whose PTR query to any DNS servers has just failed or timed out, an LLMNR query for an apparantly non-local address will almost always fail. Let's not clutter the wire with such queries. The case of multiple configured prefixes on a link without a DNS server is unusual to begin with. Having some of those prefixes absent from a host's routing table yet still reachable is even more unusual. One could argue as to whether such an IPv6 configuration, where only the router knows what prefixes are local and can forward local packets back onto the same link, is properly in scope for LLMNR. (If the responder doesn't know that the querying host's prefix is on-link either, will the response still have TTL 255 by the time the router forwards it back onto the same link?) For security and operational reasons, it's nice to prevent LLMNR from flooding large, managed networks with queries every time the local DNS server becomes unreachable. If we can protect against such flooding, without keeping the dentist's office scenario from working well, we should do so. I don't think my dentist has multiple unadvertised global prefixes on his router, and if he does, he probably has a DNS server configured too. - Mark -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 18 13:51:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23683 for ; Tue, 18 Mar 2003 13:51:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vM1t-0008mm-00 for namedroppers-data@psg.com; Tue, 18 Mar 2003 10:41:41 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #1) id 18vM1r-0008mZ-00 for namedroppers@ops.ietf.org; Tue, 18 Mar 2003 10:41:39 -0800 Received: from esunmail ([129.147.58.120]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA25815 for ; Tue, 18 Mar 2003 11:41:38 -0700 (MST) Received: from xpa-fe1 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HBY00HYOJXEF2@edgemail1.Central.Sun.COM> for namedroppers@ops.ietf.org; Tue, 18 Mar 2003 11:41:38 -0700 (MST) Received: from sun.com ([130.129.135.206]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPSA id <0HBY00E9MJXC3F@mail.sun.net> for namedroppers@ops.ietf.org; Tue, 18 Mar 2003 11:41:38 -0700 (MST) Date: Tue, 18 Mar 2003 10:41:35 -0800 From: Alain Durand Subject: Re: Proposed (partial) resolution to LLMNR Issue #2 In-reply-to: To: Bernard Aboba Cc: namedroppers@ops.ietf.org Message-id: <3F58F93F-5971-11D7-91B6-00039358A080@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.551) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT I would like to post on the list the comment I made this morning on this issue (TTL=255 on send) IMHO, LLMNR should be SLMNR (Subnet Local and not Link local) as there is some ongoing work in IPv6 to define multi-link subnets and I believe *LMNR should work in that environment. In Multi-link subnets, the aTTL will be decremented by the routers and a check that the received TTL=255 will fail. - Alain. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 18 14:03:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24339 for ; Tue, 18 Mar 2003 14:03:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vMDc-0009Zr-00 for namedroppers-data@psg.com; Tue, 18 Mar 2003 10:53:48 -0800 Received: from cyphermail.sandelman.ottawa.on.ca ([192.139.46.78] helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 3.36 #1) id 18vMDY-0009ZV-00 for namedroppers@ops.ietf.org; Tue, 18 Mar 2003 10:53:44 -0800 Received: from sandelman.ottawa.on.ca (wl-193-246.wireless.ietf56.ietf.org [130.129.193.246] (may be forged)) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h2IIqQD10650 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Tue, 18 Mar 2003 13:52:28 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1] (may be forged)) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h2IIqPAR021190 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 18 Mar 2003 10:52:26 -0800 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-5) with ESMTP id h2IIqOSW021186 for ; Tue, 18 Mar 2003 10:52:24 -0800 Message-Id: <200303181852.h2IIqOSW021186@marajade.sandelman.ottawa.on.ca> To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: Key-Signing Key (KSK) Flag In-reply-to: Your message of "Tue, 18 Mar 2003 00:09:08 EST." <200303180009.08881.davidb@verisignlabs.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 18 Mar 2003 10:52:24 -0800 From: Michael Richardson X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,LINES_OF_YELLING,MAY_BE_FORGED,PGP_SIGNATURE, SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "David" == David Blacka writes: >> > instance, by adding this information to the key file names). I cannot >> > think of a wire use for the ZSK bit. >> Remote debugging. If the intent of the key is clear/visble >> this is relatively easy. David> Remote debugging of what, exactly? David> Trying to figure out what the zone signing key is has never been David> an issue in any of the workshops that I've attended, AFAIK. Have multiple keys been tested prior to last week? Certainly we did get the wrong keys sent to the parent. If we couldn't talk across the table, then we would have had a problem debugging. So, I want those bits there - they are for the CPU in my head? ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPndqS4qHRg3pndX9AQGghQP/SNt1gayvrerGaZcH80pkPmZNVTTdPdsM uQ3F5wBEEic2dtEr1mk2/4SfIh1SM9pNkyMSJQ3fpXQjHN1XQoxd8a/mSGLTqo/0 KQl44znwen9oFAjT5Jp7tmL2m0py5hcsoiWXm9XtKmUsD+vYLwjDPsGo1QxdsXdD f4MB0BgagE0= =bz1k -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 18 14:21:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25077 for ; Tue, 18 Mar 2003 14:21:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vMWS-000AjT-00 for namedroppers-data@psg.com; Tue, 18 Mar 2003 11:13:16 -0800 Received: from cyphermail.sandelman.ottawa.on.ca ([192.139.46.78] helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 3.36 #1) id 18vMWO-000Aig-00 for namedroppers@ops.ietf.org; Tue, 18 Mar 2003 11:13:12 -0800 Received: from sandelman.ottawa.on.ca (wl-193-246.wireless.ietf56.ietf.org [130.129.193.246] (may be forged)) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h2IJBqD10776 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Tue, 18 Mar 2003 14:11:54 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1] (may be forged)) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h2IJBpAR021647 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 18 Mar 2003 11:11:52 -0800 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-5) with ESMTP id h2IJBpvH021643 for ; Tue, 18 Mar 2003 11:11:51 -0800 Message-Id: <200303181911.h2IJBpvH021643@marajade.sandelman.ottawa.on.ca> To: namedroppers@ops.ietf.org Subject: 3rot13 Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 18 Mar 2003 11:11:50 -0800 From: Michael Richardson X-Spam-Status: No, hits=0.8 required=5.0 tests=MAY_BE_FORGED,SPAM_PHRASE_02_03 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Just for your amusement, never published when we wanted it to be (April 1): http://www.sandelman.ca/SSW/ietf/rfc-3rot13 -- to unsubscribe send a message to namedroppers-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 18 16:58:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02284 for ; Tue, 18 Mar 2003 16:58:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vOq8-000H8c-00 for namedroppers-data@psg.com; Tue, 18 Mar 2003 13:41:44 -0800 Received: from [3ffe:b80:2:a90::2] (helo=devil.pp.htv.fi) by psg.com with esmtp (Exim 3.36 #1) id 18vOq4-000H8L-00 for namedroppers@ops.ietf.org; Tue, 18 Mar 2003 13:41:41 -0800 Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) with ESMTP id h2ILgNwY003437; Tue, 18 Mar 2003 23:42:24 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) id h2ILgMBo003433; Tue, 18 Mar 2003 23:42:22 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: Proposed resolution to LLMNR Issue 21 (and 7) From: Mika Liljeberg To: Bernard Aboba Cc: Markku Savela , namedroppers@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1048023742.28501.34.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 18 Mar 2003 23:42:22 +0200 X-Spam-Status: No, hits=-1.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, X_AUTH_WARNING version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 2003-03-18 at 17:04, Bernard Aboba wrote: > > At this point, it would be prudent to advertise all IPv4 addresses a > > node has and leave it to the client node to choose an appropriate > > address. > > Since the language says MUST cease, I don't believe that we have the > option of continuing to advertise LLv4 addresses via LLMNR if a routable > address is also available. Of course, there is no such mandate for IPv6, > so we could take a different course there (although justification is > required, for course). Since LLMNR includes two parts: a responder and a resolver, I think we can meet the requirements of zeroconf by doing the following: the responder can advertise *all* addresses, however, the resolver must make a route check for the candidate address list and *only* return the highest scope reachable address(es) to the application. This, IMHO, is compliant with the zeroconf requirement. Incidentally, the above will also work correctly for IPv6. The route check in the resolver is also required by the rules laid out by IPv6 default address selection (RFC3484). MikaL -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 18 18:00:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03916 for ; Tue, 18 Mar 2003 18:00:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vPuV-000Koj-00 for namedroppers-data@psg.com; Tue, 18 Mar 2003 14:50:19 -0800 Received: from [2001:4f8:3:bb:2e0:81ff:fe10:67ab] (helo=as.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 18vPuT-000KnS-00 for namedroppers@ops.ietf.org; Tue, 18 Mar 2003 14:50:17 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id EFE2D379EEF for ; Tue, 18 Mar 2003 22:50:03 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: Key-Signing Key (KSK) Flag In-Reply-To: Message from Michael Richardson of "Tue, 18 Mar 2003 10:52:24 PST." <200303181852.h2IIqOSW021186@marajade.sandelman.ottawa.on.ca> X-Mailer: MH-E 7.2; nmh 1.0.4; GNU Emacs 21.2.1 Date: Tue, 18 Mar 2003 22:50:03 +0000 Message-Id: <20030318225003.EFE2D379EEF@as.vix.com> X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Have multiple keys been tested prior to last week? yes. > Certainly we did get the wrong keys sent to the parent. If we couldn't > talk across the table, then we would have had a problem debugging. > > So, I want those bits there - they are for the CPU in my head? i'm withdrawing my prior support for the KSK draft. KSK vs ZSK should either be two distinct RR types (possibly as part of a type code roll) or the "key type" bit (KSK vs ZSK) should be used by validators. this is because of Orr's principle (data which is not used will be wrong) and also because key management techniques such as rollover or parent signing of child zone keys or DS RR generation and insertion are not really practical as "operational sugar" and ought to be specified in the basic protocol. this does not bear on johani's "threshold validation", since there can still be more than one key of any type (KSK vs ZSK) which needs more than one key. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 18 18:01:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03939 for ; Tue, 18 Mar 2003 18:01:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vPwR-000LBR-00 for namedroppers-data@psg.com; Tue, 18 Mar 2003 14:52:19 -0800 Received: from thing.verisignlabs.com ([65.201.175.62] helo=cliffie.verisignlabs.com) by psg.com with esmtp (Exim 3.36 #1) id 18vPwL-000LB3-00 for namedroppers@ops.ietf.org; Tue, 18 Mar 2003 14:52:13 -0800 Received: from wl-130-243.wireless.ietf56.ietf.org (wl-130-243.wireless.ietf56.ietf.org [130.129.130.243]) (AUTH: LOGIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by cliffie.verisignlabs.com with esmtp; Tue, 18 Mar 2003 17:52:08 -0500 From: David Blacka Organization: Verisign, Inc. To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: Key-Signing Key (KSK) Flag Date: Tue, 18 Mar 2003 17:52:03 -0500 User-Agent: KMail/1.5 References: <200303181741.h2IHfHGQ018706@marajade.sandelman.ottawa.on.ca> In-Reply-To: <200303181741.h2IHfHGQ018706@marajade.sandelman.ottawa.on.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200303181752.03281.davidb@verisignlabs.com> X-Spam-Status: No, hits=-3.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT, REFERENCES,SIGNATURE_SHORT_DENSE,SPAM_PHRASE_08_13, USER_AGENT version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday 18 March 2003 12:41 pm, Michael Richardson wrote: > >>>>> "David" == David Blacka writes: > David> I don't think I agree with this. > > I don't agree that you don't agree! Your later text explains that > you do. > > I claim you do agree. We (the humans) need to identify which is KSK and > which is ZSK. Sometimes humans will ask the computer to help them > figure it out, such as when the parent wants to know which key to > download for offline verification. It is also useful so that humans > can more easily be told by the tools, "I think that you made a > mistake, add --I-really-mean-it if you are sure". I think that you have misunderstood my point. What I agree with is that it needs to be clear to the zone operator and the zone signing tools which keys are key signing keys and which keys are zone signing keys. What I disagree with is that this information needs to be in the KEY record itself. I strongly believe that if we are going to define a bit in the KEY RR (or any other field in any other RR for that matter), it should have an _on_the_wire_ use. I don't see one for the ZSK bit. This information is important to the zone signer and the human running the zone signer, which are both located at the same place. Thus this is tools issue, albeit an important one. -- David Blacka Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 18 18:10:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04980 for ; Tue, 18 Mar 2003 18:10:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vQ6Q-000LzL-00 for namedroppers-data@psg.com; Tue, 18 Mar 2003 15:02:38 -0800 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 18vQ6N-000Lyo-00 for namedroppers@ops.ietf.org; Tue, 18 Mar 2003 15:02:35 -0800 Received: from nominum.com (wl-130-224.wireless.ietf56.ietf.org [130.129.130.224]) by toccata.fugue.com (Postfix) with ESMTP id C86451B20E5; Tue, 18 Mar 2003 16:10:36 -0600 (CST) Date: Tue, 18 Mar 2003 15:02:32 -0800 Subject: A halfway solution to the multiple-ksk verification problem. Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: namedroppers To: Johan Ihren From: Ted Lemon Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-1.0 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit You suggested two degrees of paranoia that a resolver might use for validating the root key - allow one of five keys, and require three of five. The first is not so good because if a key is compromised, you can be spoofed. The second is not good because it requires three signatures for every response to an apex query. A possible intermediate solution would be to have resolvers that maintain stable state to try a different key with each apex query. If the resolver is unable to get the root to use all five ksk's in sequence, it means that thing that answered your apex query is probably an attacker that has one key but not all. So at *that* point you switch into the mode of requiring three keys. The resolver then periodically tries to re-validate its apex keys, using the stronger degree of validation. It stays in this mode until it has been able to successfully get a list of valid keys from the apex server signed with three known keys. -- to unsubscribe send a message to namedroppers-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 18 19:26:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07893 for ; Tue, 18 Mar 2003 19:26:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vRHE-000Pir-00 for namedroppers-data@psg.com; Tue, 18 Mar 2003 16:17:52 -0800 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 18vRH8-000PiR-00 for namedroppers@ops.ietf.org; Tue, 18 Mar 2003 16:17:47 -0800 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h2IN2CC07411 for ; Tue, 18 Mar 2003 15:02:12 -0800 Date: Tue, 18 Mar 2003 15:02:12 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: LLMNR Issue 26: Retransmission Timeouts Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.2 required=5.0 tests=SPAM_PHRASE_02_03,USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Issue 26: Retransmission timeouts Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: March 17, 2003 Reference: Document: LLMNR-13 Comment type: T Priority: S Section: 2.1 Rationale/Explanation of issue: Dynamically estimated timeout values are not supported. Change: "If the LLMNR query is not resolved during a limited amount of time (LLMNR_TIMEOUT), then a sender MAY repeat the transmission of a query in order to assure themselves that the query has been received by a host capable of responding to the query. The default value for LLMNR_TIMEOUT is 1 second. Since a sender cannot know beforehand whether it will receive no response, one response, or more than one response to a query, it SHOULD wait for LLMNR_TIMEOUT in order to collect all possible responses, rather than considering the query answered after the first response is received." To: "LLMNR implementations SHOULD dynamically estimate the timeout value (LLMNR_TIMEOUT) on a per-interface basis, using the algorithms described in [RFC2988], with a minimum timeout value of 300 ms. If the LLMNR query is not resolved by LLMNR_TIMEOUT, then a sender MAY repeat the transmission of a query in order to assure themselves that the query has been received by a host capable of responding to the query. Since a sender cannot know beforehand whether it will receive no response, one response, or more than one response to a query, it SHOULD wait for LLMNR_TIMEOUT in order to collect all possible responses, rather than considering the query answered after the first response is received." -- to unsubscribe send a message to namedroppers-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 18 19:33:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08524 for ; Tue, 18 Mar 2003 19:33:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vRPK-00005u-00 for namedroppers-data@psg.com; Tue, 18 Mar 2003 16:26:14 -0800 Received: from [2001:4f8:3:bb:2e0:81ff:fe10:67ab] (helo=as.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 18vRPE-00005E-00 for namedroppers@ops.ietf.org; Tue, 18 Mar 2003 16:26:09 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id E6CFB379F96 for ; Wed, 19 Mar 2003 00:25:55 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: Key-Signing Key (KSK) Flag In-Reply-To: Message from David Blacka of "Tue, 18 Mar 2003 17:52:03 EST." <200303181752.03281.davidb@verisignlabs.com> X-Mailer: MH-E 7.2; nmh 1.0.4; GNU Emacs 21.2.1 Date: Wed, 19 Mar 2003 00:25:55 +0000 Message-Id: <20030319002555.E6CFB379F96@as.vix.com> X-Spam-Status: No, hits=-1.1 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [david blacka] > I strongly believe that if we are going to define a bit in the KEY RR > (or any other field in any other RR for that matter), it should have > an _on_the_wire_ use. ... i agree with this, and it's a better way of putting it then i wrote earlier. but wait, there's a reference: > How can we control our data quality? > > Ken Orr, (Data Quality and Systems Theory, CACM 41,2) puts forward a > case that maintaining data quality is a "use based" issue and that, like > all engineering control systems, this involves a steady stream of > feedback in this case feedback from the data users. His exploration of > the subject has led him to deduce certain rules regarding data quality: > > o Unused Data cannot remain correct for very long. > o Data quality if a function of its use, not its collection > o Data quality will be no better than its most stringent use > o Data quality problems becomes worse as the system ages > o If some data element is unlikely to change, when it does > change it will be traumatic for the data user > o Data quality applies to data AND to metadata. so, far from removing the KSK bit, i'm in favour of using it in validation, so that it will be nonoptional, and there will be instant feedback when it is incorrect. -- to unsubscribe send a message to namedroppers-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 18 19:42:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08980 for ; Tue, 18 Mar 2003 19:42:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vRWp-0000Qn-00 for namedroppers-data@psg.com; Tue, 18 Mar 2003 16:33:59 -0800 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 18vRWl-0000QB-00 for namedroppers@ops.ietf.org; Tue, 18 Mar 2003 16:33:55 -0800 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h2INILr08301 for ; Tue, 18 Mar 2003 15:18:21 -0800 Date: Tue, 18 Mar 2003 15:18:21 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed resolution of Issue 6: IPv6 Multicast Groups Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.2 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I would like to propose that Mika's proposed change be accepted. Here's the issue and the proposed resolution: Issue 6: IPv6 Multicast Groups Submitter: Mika Liljeberg Submitter email address: mika.liljeberg@welho.com Date first submitted: March 8, 2003 Reference: Document: LLMNR-13 Comment type: T Priority: S Section: Rationale/Explanation of issue: Reading the draft I get the understanding that, in order to respond to reverse queries for IPv6 addresses, the host has to configure the following sixteen multicast addresses on each of its interfaces: FF02:0:0:0:0:2:MD5("0") .. FF02:0:0:0:0:2:MD5("F") In addition, a host may have multiple aliases (especially if it is multihomed), so the number of multicast groups that need to be configured per inteface could be close to twenty. This is clearly a waste of multicast filters. It is unlikely (correct me if I'm wrong) that a NIC will support this many multicast filters in hardware, which means that the NIC will have to be configured to receive all multicasts and the filtering must be done in software. That pretty much defeats the purpose of having the hash based solicited name multicast addresses in the first place. It would seem much better to just have a single well-known IPv6 link-local multicast address for reverse lookups. The alternative would seem to be to not support PTR queries at all for IPv6 addresses. I leave it to the discretion of the editors to decide whether this should be formulated as an issue. MikaL Comment from Bill Sommerfeld : I just took a look at drivers for a few commonly used fast ethernet chipsets, and found the following limits: - 80 literal multicast addresses - 64-entry hash. - 128-entry hash. - 256-entry hash. - 512-entry hash. The "N-entry hash" variety maintain a N-bit vector, and run the recieved multicast address through a hash function with N possible outputs; if the corresponding bit in the vector is set, the packet is received, so you get more graceful degradation as the number of groups increases at the cost of slightly more false positives received. MikaL: That's a pretty neat approach. The longer bit vectors sound good enough, although I still can't say that I like the idea of having to listen to 16 different multicast groups just for doing PTR queries. [It would be possible to optimize this, of course, but that would force the LLMNR responder to actively monitor all changes in interface configuration.] One 802.11 card I looked at has a lower limits (16 literal addresses). Another 802.11 card seems to have no multicast filtering at all! (though that may be an inadequate driver rather than a deficiency in the hardware/firmware). MikaL: Needless to say, 802.11 and other wireless interfaces would be a major use case for LLMNR. [BA] I would like to propose that Mika's suggestion be accepted: A single well-known multicast group for IPv6 queries other than A/AAAA. Change: "LLMNR queries are sent to and received on port TBD using a LINKLOCAL address as specified in "Administratively Scoped IP Multicast" [RFC2365] for IPv4 and the "solicited name" LINKLOCAL multicast addresses for IPv6, and using a unicast address as described in Section 2.3. The LLMNR LINKLOCAL address to be used for IPv4 is 224.0.0.251. LINKLOCAL addresses are used to prevent propagation of LLMNR traffic across routers, potentially flooding the network." To: "LLMNR queries are sent to and received on port TBD using a LINKLOCAL address as specified in "Administratively Scoped IP Multicast" [RFC2365] for IPv4. The LLMNR LINKLOCAL address to be used for IPv4 is 224.0.0.251. For IPv6, the "solicited name" LINKLOCAL multicast addresses are used for A/AAAA queries, and a separate multicast address TBD for all other queries. In addition, LLMNR queries can be sent to a unicast address as described in Section 2.3. LINKLOCAL addresses are used to prevent propagation of LLMNR traffic across routers, potentially flooding the network." -- to unsubscribe send a message to namedroppers-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 18 19:43:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09059 for ; Tue, 18 Mar 2003 19:43:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vRZ9-0000X4-00 for namedroppers-data@psg.com; Tue, 18 Mar 2003 16:36:23 -0800 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 18vRZ6-0000Wq-00 for namedroppers@ops.ietf.org; Tue, 18 Mar 2003 16:36:20 -0800 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h2INKkp08434 for ; Tue, 18 Mar 2003 15:20:46 -0800 Date: Tue, 18 Mar 2003 15:20:46 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed Resolution to LLMNR Issue #21: Reject Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.5 required=5.0 tests=SPAM_PHRASE_03_05,USER_AGENT_PINE version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk After the discussion in DNSEXT WG today, it appears that the proposed resolution to Issue 21 will not actually work and as a result, I would like to propose that we reject it. Any objections? --------------------------------------------------------------------- Issue 21: PTR queries Submitter: Markku Savela Submitter email address: msa@burp.tkv.asdf.org Date first submitted: November 4, 2002 Reference: <200211041445.QAA12218@burp.tkv.asdf.org> Document: LLMNR-12 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: I assume that if you end up doing a address (fe80::1) to name query for IPv6, you end up sending a query to IPv6 multicast address generated from the hash of "1.0.0. ... 0.0.8.e.f.ip6.int" and because the hash is taken from the first label, this will be MD5 from "1"? (basically only 16 different hashes are possible). IPv4 side you have for example "1.2.254.169.in-addr.arpa". Am I right assuming the "resolvers" on nodes have to deal also with these for link local name resolution? [BA] Yes, it is expected that senders will send PTR queries, and that receivers will respond to them. However, it probably doesn't make sense to send a PTR query for an address that isn't on the local link. Here's the proposed resolution: Add the following text to Section 3: "[3] A sender SHOULD NOT send LLMNR queries for PTR RRs that correspond to addresses known not to exist on the local link. Since legitimate responses to LLMNR queries can only come from hosts on the local link, an LLMNR query for an address not on the local link cannot elicit a legitimate response." [Erik Guttman and Erik Nordmark]: The problem is that in practice a host may not know the prefixes in use on a particular link. So this restriction can't work in practice. -- to unsubscribe send a message to namedroppers-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 18 23:29:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15114 for ; Tue, 18 Mar 2003 23:29:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vV40-000A1R-00 for namedroppers-data@psg.com; Tue, 18 Mar 2003 20:20:28 -0800 Received: from wl-130-206.wireless.ietf56.ietf.org ([130.129.130.206] helo=slimsixten.besserwisser.org) by psg.com with esmtp (Exim 3.36 #1) id 18vV3u-000A1A-00 for namedroppers@ops.ietf.org; Tue, 18 Mar 2003 20:20:22 -0800 Received: from localhost.besserwisser.org (mansaxel@localhost.besserwisser.org [127.0.0.1]) by slimsixten.besserwisser.org (8.12.6/8.12.2) with ESMTP id h2J4JvH6028397; Wed, 19 Mar 2003 05:19:57 +0100 (CET) Date: Wed, 19 Mar 2003 04:13:42 +0100 From: =?ISO-8859-1?Q?M=E5ns_Nilsson?= To: Tatsuya Baba , namedroppers@ops.ietf.org Subject: Re: I-D regarding access control in DNS Message-ID: <782650000.1048043622@localhost> In-Reply-To: <3E412A47.70607@nttdata.co.jp> References: <3E412A47.70607@nttdata.co.jp> X-Mailer: Mulberry/2.2.1 (OpenBSD/x86) X-PGP-KEY: http://vvv.besserwisser.org/key MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========1379346650==========" X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,PGP_SIGNATURE_2,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --==========1379346650========== Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable --On Thursday, February 06, 2003 00:14:15 +0900 Tatsuya Baba wrote: > Hi all, >=20 > I wrote an I-D regarding access control in DNS. >=20 > draft-baba-dnsext-acl-reqts-00.txt >=20 > I know that DNSSEC specification states "the DNS design philosophy calls > for all DNS data to be public." However, I also know that there are > many people who would like to control access to DNS data. >=20 > Is there anyone who is interested in this area? Having seen your presentation I would like to stand on the traditional side and argue that creating a data hiding mechanism in the public DNS is contradictional with both intention and perception of the DNS system; and most of the ACL mechanisms presently available are frequently breaking service, most often due to the administrator failing to comprehend the scope of his or her actions. So, we have all the foot-shot armament we could use.=20 Best regards,=20 --=20 M=E5ns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead. --==========1379346650========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (OpenBSD) iD8DBQE+d+Bm02/pMZDM1cURAgvSAJ9zPC8g+EReJjsVXQFi1BKSlkldVgCgknxn Bis1vY7Cmbm6K3xhuet1luE= =wF0/ -----END PGP SIGNATURE----- --==========1379346650==========-- -- to unsubscribe send a message to namedroppers-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 18 23:29:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15139 for ; Tue, 18 Mar 2003 23:29:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vV3f-000A0y-00 for namedroppers-data@psg.com; Tue, 18 Mar 2003 20:20:07 -0800 Received: from wl-130-206.wireless.ietf56.ietf.org ([130.129.130.206] helo=slimsixten.besserwisser.org) by psg.com with esmtp (Exim 3.36 #1) id 18vV3c-000A0c-00 for namedroppers@ops.ietf.org; Tue, 18 Mar 2003 20:20:04 -0800 Received: from localhost.besserwisser.org (mansaxel@localhost.besserwisser.org [127.0.0.1]) by slimsixten.besserwisser.org (8.12.6/8.12.2) with ESMTP id h2J4JvH8028397; Wed, 19 Mar 2003 05:19:58 +0100 (CET) Date: Wed, 19 Mar 2003 04:57:16 +0100 From: =?ISO-8859-1?Q?M=E5ns_Nilsson?= To: =?ISO-8859-1?Q?=D3lafur_Gudmundsson=2FDNSEXT_co-chair?= , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: DNS Threats Message-ID: <833540000.1048046236@localhost> In-Reply-To: <5.1.1.6.2.20030312222622.022df350@localhost> References: <5.1.1.6.2.20030312222622.022df350@localhost> X-Mailer: Mulberry/2.2.1 (OpenBSD/x86) X-PGP-KEY: http://vvv.besserwisser.org/key MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========2023381422==========" X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,PGP_SIGNATURE_2,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01 version=2.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --==========2023381422========== Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable --On Wednesday, March 12, 2003 23:00:26 -0500 "=D3lafur Gudmundsson/DNSEXT co-chair" wrote: >=20 > This starts a 2 week Working Group last call on this document, > concluding on March 28'th 2003. I support the document, with the following nitpicks, none believed to be more than minor edits: Section 1, last paragraph:=20 (introduction of a putatively simpler transaction model certain operations) changes to: (introduction of a putatively simpler transaction model for certain operations) Section 2.3: or some third party; in some the query itself may be unrelated to changes to (perhaps, this is a taste/style thing): or some third party; in some cases the query itself may be unrelated = to Section 3: topic for another document....) changes to: topic for another document...) And, this will be required reading for my students. Well done !=20 --=20 M=E5ns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead. --==========2023381422========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (OpenBSD) iD8DBQE+d+qc02/pMZDM1cURAkBzAJ9K8bUaPvYGZl0VSrBTGyX0C5fENwCgm1Y3 SJrA7Inf+0m3y7Xut+oNizU= =mQgx -----END PGP SIGNATURE----- --==========2023381422==========-- -- to unsubscribe send a message to namedroppers-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 19 13:23:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29125 for ; Wed, 19 Mar 2003 13:23:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vhtI-0000cV-00 for namedroppers-data@psg.com; Wed, 19 Mar 2003 10:02:16 -0800 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 18vhtD-0000c4-00 for namedroppers@ops.ietf.org; Wed, 19 Mar 2003 10:02:11 -0800 Received: from nominum.com (dhcp-167.wl.nominum.com [128.177.195.167]) by toccata.fugue.com (Postfix) with ESMTP id 88EC91B20E5; Wed, 19 Mar 2003 11:10:12 -0600 (CST) Date: Wed, 19 Mar 2003 10:02:20 -0800 Subject: Re: A halfway solution to the multiple-ksk verification problem. Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: namedroppers To: Michael Richardson From: Ted Lemon In-Reply-To: <200303191800.h2JI037e004829@marajade.sandelman.ottawa.on.ca> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03, USER_AGENT_APPLEMAIL version=2.44 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > they way that you talk about root servers responding, sounds like you > think > that the signatures are done online. Err, oops. I should stick to things I have in cache. :'} -- to unsubscribe send a message to namedroppers-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 19 14:06:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01225 for ; Wed, 19 Mar 2003 14:06:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vibm-0004m9-00 for namedroppers-data@psg.com; Wed, 19 Mar 2003 10:48:14 -0800 Received: from soyouz.netaktiv.com ([80.67.162.6] helo=mail-aubervilliers.netaktiv.com) by psg.com with esmtp (Exim 3.36 #1) id 18vibk-0004kx-00 for namedroppers@ops.ietf.org; Wed, 19 Mar 2003 10:48:12 -0800 Received: by mail-aubervilliers.netaktiv.com (Postfix, from userid 10) id A07E124364; Wed, 19 Mar 2003 15:15:34 +0100 (CET) Received: from sources.org (stephane@localhost [127.0.0.1]) by ludwigV.sources.org (8.12.3/8.12.3/Debian -4) with ESMTP id h2JEA6tF014184; Wed, 19 Mar 2003 15:10:06 +0100 Message-Id: <200303191410.h2JEA6tF014184@ludwigV.sources.org> X-Mailer: exmh version 2.5 07/13/2001 (debian 2.5-1) with nmh-1.0.4+dev From: Stephane Bortzmeyer To: namedroppers@ops.ietf.org Subject: Should a non-authoritative server put the NS records into Answer or into Authority? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 19 Mar 2003 15:10:06 +0100 X-Spam-Status: No, hits=1.4 required=5.0 tests=MSG_ID_ADDED_BY_MTA_3,SPAM_PHRASE_01_02 version=2.44 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Sorry to use an IETF WG for my training but this question puzzles me for a long time and, since we switched one of the nameservers of '.fr' to BIND9, it puzzles several of our registrars as well. When you query a server on data it is not authoritative about (typically a TLD server about a subzone, for which it only knows the NS records and some glue), where the NS should be when replying? In the Authority section or in the Answer one? Atlas, BIND9 and nsd put the NS records into the Authority section. The Answer section is empty (the Perl script of one of our registrars started to crash there: "Illegal division by zero" because of the empty section). BIND8 and PowerDNS put the NS records into the Answer section. You can check this on ns1.nic.fr (BIND8) vs. ns3.nic.fr (BIND9) or on a.root-servers.net (Atlas) vs. k.root-servers.net (nsd). What is legal? What is best practice? I'm still confused about what RFC 1034 says: If recursive service is not requested or is not available, the non- recursive response will be one of the following: [...] - Some combination of: RRs that answer the question, together with an indication whether the data comes from a zone or is cached. A referral to name servers which have zones which are closer ancestors to the name than the server sending the reply. IMHO, "some combination" without any details mean that all the programs quoted above are legally right, although different. -- to unsubscribe send a message to namedroppers-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 19 14:11:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29126 for ; Wed, 19 Mar 2003 13:23:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vi5a-0001oN-00 for namedroppers-data@psg.com; Wed, 19 Mar 2003 10:14:58 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18vi5Y-0001o4-00 for namedroppers@ops.ietf.org; Wed, 19 Mar 2003 10:14:56 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18vi5Y-0000a7-00 for namedroppers@ops.ietf.org; Wed, 19 Mar 2003 10:14:56 -0800 Content-return: prohibited Message-id: <0HBZ00I2BEH5KD@ms3.samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=euc-kr Content-transfer-encoding: 7BIT Date: Wed, 19 Mar 2003 14:46:40 +0900 From: =?EUC-KR?B?udq89sir?= Subject: IPv6 DNAR (Domain Name Auto Registration) To: namedroppers@ops.ietf.org, dnsop@cafax.se, soohong.park@samsung.com Msgkey: 20030319144640@soohong.park X-Spam-Status: No, hits=1.2 required=5.0 tests=DOMAIN_SUBJECT,RESENT_TO,SPAM_PHRASE_03_05 version=2.44 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Hi folks I spoke my document briefly in the DNSEXT WG today. But I didn't fully explain for my proposal, then I send this mail to dns guys. There are only two components as 6DNAR host and server in home area. When each host is processing DAD, unique domain name is included in the new option. After server receives NS message from host, both domain name and address will be registrated to DNS server automatically. Please look into it and response any comments to me http://www.ietf.org/internet-drafts/draft-park-6dnar-01.txt Thanks Daniel --------------------------------------------------------- Soohong Daniel Park Researcher Mobile Platform Lab. Samsung Electronics TEL:+82-31-200-3728 FAX:+82-31-200-3147 mailto:Soohong.Park@samsung.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 19 16:17:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08647 for ; Wed, 19 Mar 2003 16:17:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vkmD-000FEk-00 for namedroppers-data@psg.com; Wed, 19 Mar 2003 13:07:09 -0800 Received: from rwcrmhc51.attbi.com ([204.127.198.38]) by psg.com with esmtp (Exim 3.36 #1) id 18vkmA-000FDS-00 for namedroppers@ops.ietf.org; Wed, 19 Mar 2003 13:07:06 -0800 Received: from master.gorean.org (12-234-22-23.client.attbi.com[12.234.22.23]) by rwcrmhc51.attbi.com (rwcrmhc51) with SMTP id <2003031921070305100irnele>; Wed, 19 Mar 2003 21:07:03 +0000 Date: Wed, 19 Mar 2003 13:07:03 -0800 (PST) From: Doug Barton To: Stephane Bortzmeyer cc: namedroppers@ops.ietf.org Subject: Re: Should a non-authoritative server put the NS records into Answer or into Authority? In-Reply-To: <200303191410.h2JEA6tF014184@ludwigV.sources.org> Message-ID: <20030319130555.M677@znfgre.tberna.bet> References: <200303191410.h2JEA6tF014184@ludwigV.sources.org> Organization: Triborough Bridge & Tunnel Authority X-message-flag: Outlook -- Not just for spreading viruses anymore! MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT, RCVD_IN_MULTIHOP_DSBL,RCVD_IN_UNCONFIRMED_DSBL,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,TO_BE_REMOVED_REPLY version=2.44 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 19 Mar 2003, Stephane Bortzmeyer wrote: > Sorry to use an IETF WG for my training Don't be sorry, just don't do it. :) This question belongs on bind9-users@isc.org. The short answer to your question is that BIND 9 is right. I'll send you a longer answer in private mail. Doug > but this question puzzles me for a long time and, since we switched one > of the nameservers of '.fr' to BIND9, it puzzles several of our > registrars as well. > > When you query a server on data it is not authoritative about (typically a TLD > server about a subzone, for which it only knows the NS records and some glue), > where the NS should be when replying? In the Authority section or in the > Answer one? > > Atlas, BIND9 and nsd put the NS records into the Authority section. The Answer > section is empty (the Perl script of one of our registrars started to crash > there: "Illegal division by zero" because of the empty section). > > BIND8 and PowerDNS put the NS records into the Answer section. > > You can check this on ns1.nic.fr (BIND8) vs. ns3.nic.fr (BIND9) or on > a.root-servers.net (Atlas) vs. k.root-servers.net (nsd). > > What is legal? What is best practice? > > I'm still confused about what RFC 1034 says: > > If recursive service is not requested or is not available, the non- > recursive response will be one of the following: > > [...] > > - Some combination of: > > RRs that answer the question, together with an indication > whether the data comes from a zone or is cached. > > A referral to name servers which have zones which are closer > ancestors to the name than the server sending the reply. > > IMHO, "some combination" without any details mean that all the programs quoted > above are legally right, although different. > > > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- If it's moving, encrypt it. If it's not moving, encrypt it till it moves, then encrypt it some more. -- to unsubscribe send a message to namedroppers-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 19 17:14:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12018 for ; Wed, 19 Mar 2003 17:14:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vlbU-000JGf-00 for namedroppers-data@psg.com; Wed, 19 Mar 2003 14:00:08 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #1) id 18vlbR-000JFv-00 for namedroppers@ops.ietf.org; Wed, 19 Mar 2003 14:00:05 -0800 Received: from ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.8/8.11.6) with ESMTP id h2JM0112003832; Wed, 19 Mar 2003 23:00:01 +0100 Message-Id: <200303192200.h2JM0112003832@birch.ripe.net> To: Stephane Bortzmeyer cc: namedroppers@ops.ietf.org Subject: Re: Should a non-authoritative server put the NS records into Answer or into Authority? In-Reply-To: Message from Stephane Bortzmeyer of "Wed, 19 Mar 2003 15:10:06 +0100." <200303191410.h2JEA6tF014184@ludwigV.sources.org> Date: Wed, 19 Mar 2003 23:00:01 +0100 From: Olaf Kolkman X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.44 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Bonjour Stephane, (...) * where the NS should be when replying? In the Authority section or in the * Answer one? This behaviour stems from RFC1034 section 4.3.2. "Algorithm" In step 3b of the algorithm it is specifically state that at a delegation point the NS RRs are copied in the authority section. b. If a match would take us out of the authoritative data, we have a referral. This happens when we encounter a node with NS RRs marking cuts along the bottom of a zone. Copy the NS RRs for the subzone into the authority section of the reply. Put whatever addresses are available into the additional section, using glue RRs if the addresses are not available from authoritative data or the cache. Go to step -- to unsubscribe send a message to namedroppers-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 19 17:15:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12054 for ; Wed, 19 Mar 2003 17:15:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vle5-000JM4-00 for namedroppers-data@psg.com; Wed, 19 Mar 2003 14:02:49 -0800 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #1) id 18vle0-000JKL-00 for namedroppers@ops.ietf.org; Wed, 19 Mar 2003 14:02:45 -0800 Received: (qmail 21246 invoked by uid 1016); 19 Mar 2003 22:03:05 -0000 Date: 19 Mar 2003 22:03:05 -0000 Message-ID: <20030319220305.21245.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: Should a non-authoritative server put the NS records into Answer or into Authority? References: <200303191410.h2JEA6tF014184@ludwigV.sources.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.44 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Stephane Bortzmeyer writes: > When you query a server on data it is not authoritative about > (typically a TLD server about a subzone, for which it only knows the > NS records and some glue), where the NS should be when replying? In > the Authority section or in the Answer one? Both locations are possible. A referral has NS records in the authority section. An NS answer has NS records in the answer section. Of course, an NS answer isn't possible if the query type wasn't NS or *. Furthermore, many servers (the most popular being tinydns and BIND 9) choose to give referrals instead of answers when both are possible. > it puzzles several of our registrars People who don't understand DNS (such as the .fr registrars) shouldn't be writing DNS software (such as the broken .fr zone checkers). ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 19 18:19:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15302 for ; Wed, 19 Mar 2003 18:19:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vmh7-000Mym-00 for namedroppers-data@psg.com; Wed, 19 Mar 2003 15:10:01 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18vmh5-000MyO-00 for namedroppers@ops.ietf.org; Wed, 19 Mar 2003 15:09:59 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18vmh0-0000A8-00 for namedroppers@ops.ietf.org; Wed, 19 Mar 2003 15:09:54 -0800 Message-ID: <20030319223235.GA26580@outpost.ds9a.nl> References: <200303191410.h2JEA6tF014184@ludwigV.sources.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200303191410.h2JEA6tF014184@ludwigV.sources.org> Date: Wed, 19 Mar 2003 23:32:36 +0100 From: bert hubert To: Stephane Bortzmeyer Cc: namedroppers@ops.ietf.org Subject: Re: Should a non-authoritative server put the NS records into Answer or into Authority? X-Spam-Status: No, hits=-3.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, RESENT_TO,SIGNATURE_SHORT_DENSE,SPAM_PHRASE_02_03 version=2.44 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, Mar 19, 2003 at 03:10:06PM +0100, Stephane Bortzmeyer wrote: > When you query a server on data it is not authoritative about (typically a > TLD server about a subzone, for which it only knows the NS records and > some glue), where the NS should be when replying? In the Authority section > or in the Answer one? So when you query FR for the A record of www.yourdomain.fr? I don't really get your question. > BIND8 and PowerDNS put the NS records into the Answer section. PowerDNS answers with records in the Authority record when it hands out a referral. Check out: dig www.lame.ds9a.nl @213.244.168.210 But if you do dig NS lame.ds9a.nl @213.244.168.210 you get answers in the Answer section. Is this what you mean? Regards, bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing & Traffic Control HOWTO http://netherlabs.nl Consulting -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 19 18:45:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16321 for ; Wed, 19 Mar 2003 18:45:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vn8A-000OBW-00 for namedroppers-data@psg.com; Wed, 19 Mar 2003 15:37:58 -0800 Received: from smtp.denic.de ([194.246.96.22]) by psg.com with esmtp (Exim 3.36 #1) id 18vn87-000OB7-00 for namedroppers@ops.ietf.org; Wed, 19 Mar 2003 15:37:55 -0800 Received: from notes.denic.de (denics15.denic.de [194.246.96.18]) by smtp.denic.de with esmtp id 18vn84-0007bC-00; Thu, 20 Mar 2003 00:37:52 +0100 To: namedroppers@ops.ietf.org Cc: dolderer@denic.de, baess@denic.de Subject: Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: "=?iso-8859-1?Q?J=F6rg_Bauer=2FDenic?=" Message-ID: Date: Thu, 20 Mar 2003 00:37:48 +0100 X-MIMETrack: Serialize by Router on notes/Denic(Release 5.0.11 |July 24, 2002) at 20.03.2003 00:37:51, Serialize complete at 20.03.2003 00:37:51 Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Status: No, hits=2.3 required=5.0 tests=OPT_IN,SPAM_PHRASE_00_01 version=2.44 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA16321 On Wed, Mar 12, 2003 at 11:01:05PM -0500, Ólafur Gudmundsson/DNSEXT co-chair wrote: > > This starts a two week working group last call, > concluding on March 28'th 2003. > > Q: Is there consensus by the WG, to allow Opt-in zones? > > The document to base this discussion on is > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-opt-in-05.txt > > Please send explicit statements of support or disagreement. I (and also speaking in the name of the .de registry, which is one of the "huge" problematic registries) also prefer OPT-IN. Joerg -- -------------------------------------------- Joerg Bauer Denic eg bauer@denic.de Wiesenhuttenplatz 26 fon: +49.69.27235180 60329 Frankfurt Germany -------------------------------------------- -- to unsubscribe send a message to namedroppers-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 19 19:41:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18086 for ; Wed, 19 Mar 2003 19:41:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vo02-0000qZ-00 for namedroppers-data@psg.com; Wed, 19 Mar 2003 16:33:38 -0800 Received: from gusto.araneus.fi ([204.152.186.164]) by psg.com with esmtp (Exim 3.36 #1) id 18vnzy-0000qN-00 for namedroppers@ops.ietf.org; Wed, 19 Mar 2003 16:33:34 -0800 Received: from guava.araneus.fi (adsl-63-197-0-204.dsl.snfc21.pacbell.net [63.197.0.204]) by gusto.araneus.fi (8.12.6/8.11.6) with ESMTP id h2K0XQN0016210; Wed, 19 Mar 2003 16:33:26 -0800 (PST) Received: from guava.araneus.fi (localhost [127.0.0.1]) by guava.araneus.fi (8.12.8/8.11.6) with ESMTP id h2K0XRZ3010308; Wed, 19 Mar 2003 16:33:27 -0800 (PST) Received: (from gson@localhost) by guava.araneus.fi (8.12.8/8.12.6/Submit) id h2K0XQLA010305; Wed, 19 Mar 2003 16:33:26 -0800 (PST) Date: Wed, 19 Mar 2003 16:33:26 -0800 (PST) Message-Id: <200303200033.h2K0XQLA010305@guava.araneus.fi> To: namedroppers@ops.ietf.org CC: llmnr-editors@internaut.com Subject: LLMNR Issue: Inappropriate use of NXRRSET RCODE From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=2.8 required=5.0 tests=RCVD_IN_RFCI,SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.44 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Inappropriate use of NXRRSET RCODE Submitter name: Andreas Gustafsson Submitter email address: gson@nominum.com Date first submitted: March 19, 2003 Reference: Document: LLMNR-13 Comment type: T Priority: S Section: multiple Rationale/Explanation of issue: The mdns-13 draft makes several references to the NXRRSET RCODE. For example, section 3.1 says LLMNR may be used "when [DNS servers] respond to to a query with an RCODE set to NXRRSET". It seems there is some confusion here regarding the use of RCODE=NXRRSET versus RCODE=3 (Authoritative Name Error, sometimes referred to as NXDOMAIN) or RCODE=0/ANCOUNT=0. There is an RCODE called NXRRSET (with the assigned number 8), but it is defined as part of the DNS Dynamic Update protocol (RFC2136) and is used specifically to indicate the non-satisfaction of a dynamic update prerequisite - it is not used in responses to ordinary DNS queries. The standard way to indicate the nonexistence of an RRset (at an existing name) in the response to a DNS query is an RCODE of 0 and an empty answer section. The standard way to indicate the nonexistence of a name is RCODE=3 (Authoritative Name Error). The references to RCODE=NXRRSET should be changed to refer to either "RCODE=3 (Authoritative Name Error)" or "RCODE=0 with an empty answer section", as appropriate. The proposed text changes below represent my best guess as to which of the several references to NXRRSET in the text were intended as references to authoritative name errors (nonexistence of names) and which ones were intended to be RCODE=0/ANCOUNT=0 (nonexistence of an RRset at an existing name). Note that although the change I'm suggesting below would revert part of the changes made in response to Issue #10, the part of #10 that clarifies when the RRset nonexistence indication is sent (whatever its form may be) still applies. Requested change: 1. In the sentence If no positive response is received, a resolver treats it as a response that no records of the specified type and class for the specified name exist (NXRRSET). replace "(NXRRSET)" by "(that is, it is treated the same as a response with RCODE=0 and an empty answer section)". 2. Replace the text While the responder MUST NOT respond to queries for names it is not authoritative for, a responder MAY respond to a query for the name it is authoritative for, even if the type of query does not match a RR owned by the responder, with RCODE set to NXRRSET. For example, if the host has a AAAA RR, but no A RR, and an A RR query is received, the host would respond with an RCODE set to NXRRSET. by While the responder MUST NOT respond to queries for names it is not authoritative for, a responder MAY respond to a query for the name it is authoritative for, even if the type of query does not match a RR owned by the responder, with RCODE=0 and an empty answer section. For example, if the host has a AAAA RR, but no A RR, and an A RR query is received, the host would respond with RCODE=0 and an empty answer section. 3. In the text As a result, the DNS proxy will respond to AAAA RR queries sent over IPv4 or IPv6 with an RCODE of NXRRSET. replace "an RCODE of NXRRSET" by "an authoritative name error (RCODE=3)". 4. In each of the places where the draft talks about a DNS server not being configured, not replying to a query, or responding to a query with RCODE set to NXRRSET (using any of several different wordings), replace "[an] RCODE set to NXRRSET" with "an authoritative name error (RCODE=3)". -- Andreas Gustafsson, gson@nominum.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 19 20:56:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20635 for ; Wed, 19 Mar 2003 20:56:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vpAQ-000472-00 for namedroppers-data@psg.com; Wed, 19 Mar 2003 17:48:26 -0800 Received: from clone.registro.br ([200.160.2.4]) by psg.com with esmtp (Exim 3.36 #1) id 18vpAO-00046q-00 for namedroppers@ops.ietf.org; Wed, 19 Mar 2003 17:48:25 -0800 Received: by clone.registro.br (Postfix, from userid 1000) id B675D9266; Wed, 19 Mar 2003 22:48:23 -0300 (BRT) Date: Wed, 19 Mar 2003 22:48:23 -0300 From: Frederico A C Neves To: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN Message-ID: <20030320014823.GA208@registro.br> References: <5.1.1.6.2.20030312221746.022ed848@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5.1.1.6.2.20030312221746.022ed848@localhost> X-Spam-Status: No, hits=1.0 required=5.0 tests=IN_REP_TO,OPT_IN,REFERENCES,SPAM_PHRASE_00_01 version=2.44 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit On Wed, Mar 12, 2003 at 11:01:05PM -0500, Ólafur Gudmundsson/DNSEXT co-chair wrote: > > This starts a two week working group last call, > concluding on March 28'th 2003. > > Q: Is there consensus by the WG, to allow Opt-in zones? > > The document to base this discussion on is > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-opt-in-05.txt > > Please send explicit statements of support or disagreement. > We strongly support OPT-IN. Today as the "standard" is we can't deploy DNSSEC without OPT-IN. Fred -- to unsubscribe send a message to namedroppers-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 19 23:23:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23811 for ; Wed, 19 Mar 2003 23:23:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vrK8-000Apx-00 for namedroppers-data@psg.com; Wed, 19 Mar 2003 20:06:36 -0800 Received: from thing.verisignlabs.com ([65.201.175.62] helo=cliffie.verisignlabs.com) by psg.com with esmtp (Exim 3.36 #1) id 18vrK5-000Aph-00 for namedroppers@ops.ietf.org; Wed, 19 Mar 2003 20:06:33 -0800 Received: from wl-130-243.wireless.ietf56.ietf.org (wl-130-243.wireless.ietf56.ietf.org [130.129.130.243]) (AUTH: LOGIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by cliffie.verisignlabs.com with esmtp; Wed, 19 Mar 2003 23:06:29 -0500 From: David Blacka Organization: Verisign, Inc. To: namedroppers@ops.ietf.org Subject: KSK Flag could have a better name Date: Wed, 19 Mar 2003 23:06:21 -0500 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200303192306.21306.davidb@verisignlabs.com> X-Spam-Status: No, hits=-0.2 required=5.0 tests=NOSPAM_INC,SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01, USER_AGENT version=2.44 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I've been trying to come up with my reasoning on this issue for a few days, and this is what I have so far: There is evidence that the KSK flag causes confusion when it comes to zone signing. Specifically, the confusion occurs by trying to use the KSK flag as an indicator that the key in question is not a ZSK. The problem seems to be that the very name of the flag, KSK flag, implies that a zone is using the KSK/ZSK model (i.e., that there are separate keys for the KSK and ZSK roles). This may or may not be the case. What the flag really means is that the key is intended to be used as the secure entry point for a zone. It makes no statement about the key's status as a zone signing key. To be fair, the draft seems pretty clear on this issue. Since a key that is a secure entry key (that is, it has a corresponding DS in the zone's parent) pretty much MUST sign the zone apex keyset, it actually is, in the narrow sense, a Key Signing Key. My belief is that the confusion here is caused by the fact that the term "Key Signing Key" or KSK is used so heavily in discussion of a particular key management technique (i.e., a separate KSK and ZSK) that the use of the name in the flag implies (rightly or wrongly) that this technique is in use. So, I think we need a separate term for this flag and the keys that use it. Perhaps "Security Entry Point Key (Flag)", or "Introductory Key (Flag)". I might also be a good idea for the KSK flag draft to be a bit more explict about how a zone signer should and shouldn't use this flag. -- David Blacka Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 19 23:50:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25049 for ; Wed, 19 Mar 2003 23:50:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vrvr-000DCI-00 for namedroppers-data@psg.com; Wed, 19 Mar 2003 20:45:35 -0800 Received: from thing.verisignlabs.com ([65.201.175.62] helo=cliffie.verisignlabs.com) by psg.com with esmtp (Exim 3.36 #1) id 18vrvn-000DC1-00 for namedroppers@ops.ietf.org; Wed, 19 Mar 2003 20:45:31 -0800 Received: from wl-130-243.wireless.ietf56.ietf.org (wl-130-243.wireless.ietf56.ietf.org [130.129.130.243]) (AUTH: LOGIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by cliffie.verisignlabs.com with esmtp; Wed, 19 Mar 2003 23:45:24 -0500 From: David Blacka Organization: Verisign, Inc. To: namedroppers@ops.ietf.org Subject: Re: Q-03: inclusion of KEY records in additional records section Date: Wed, 19 Mar 2003 23:45:05 -0500 User-Agent: KMail/1.5 References: <5.1.1.6.2.20030212134348.0254be98@localhost> <200302121927.47595.davidb@verisignlabs.com> In-Reply-To: <200302121927.47595.davidb@verisignlabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200303192345.05600.davidb@verisignlabs.com> X-Spam-Status: No, hits=-3.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT, REFERENCES,SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01, USER_AGENT version=2.44 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday 12 February 2003 07:39 pm, David Blacka wrote: > It seems to me that with DS, this rule should be changed somehow. We can > either eliminate it or strengthen it. By "strengthen", I mean make it > return the zone KEY rrset in referral cases as well. > > Eliminating the rule (never returning KEY rrsets in the additional section) > optimizes for code complexity and message size at the expense of round > trips. > > Strengthing the rule does the opposite: optimizes for round trips at the > expense of code complexity and message size. > > I'm not sure which is right. At the moment I would probably vote to > eliminate the rule. Smaller messages and more predicable client behavior > seems better than fewer round trips at the moment. I've changed my mind. I now think that servers SHOULD attempt to send the KEY RRs in the additional section. That is, I think that we should strengthen the rule rather than eliminate it. My reasoning is that: * the code complexity of doing this is pretty minor, * optimizing for fewer round trips makes sense: bandwidth will increase over time, but we cannot exceed the speed of light, * since the client (via EDNS0) controls the max size of the response and the key RRs can be silently truncated, the extra size of the message should do no harm. -- David Blacka Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 20 00:59:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27007 for ; Thu, 20 Mar 2003 00:59:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vspN-000GaE-00 for namedroppers-data@psg.com; Wed, 19 Mar 2003 21:42:57 -0800 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 18vspL-000Ga2-00 for namedroppers@ops.ietf.org; Wed, 19 Mar 2003 21:42:55 -0800 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h2K4RET07328 for ; Wed, 19 Mar 2003 20:27:14 -0800 Date: Wed, 19 Mar 2003 20:27:13 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed resolution of Issue 27: Inappropriate use of NXRRSET RCODE Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.2 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.44 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I'd like to propose that this change be accepted. Any objections? ------------------------------------------- Issue 27: Inappropriate use of NXRRSET RCODE Submitter: Andreas Gustafsson Submitter email address: gson@nominum.com Date first submitted: March 19, 2003 Reference: Document: LLMNR-13 Comment type: T Priority: S Section: multiple Rationale/Explanation of issue: The mdns-13 draft makes several references to the NXRRSET RCODE. For example, section 3.1 says LLMNR may be used "when [DNS servers] respond to to a query with an RCODE set to NXRRSET". It seems there is some confusion here regarding the use of RCODE=NXRRSET versus RCODE=3 (Authoritative Name Error, sometimes referred to as NXDOMAIN) or RCODE=0/ANCOUNT=0. There is an RCODE called NXRRSET (with the assigned number 8), but it is defined as part of the DNS Dynamic Update protocol (RFC2136) and is used specifically to indicate the non-satisfaction of a dynamic update prerequisite - it is not used in responses to ordinary DNS queries. The standard way to indicate the nonexistence of an RRset (at an existing name) in the response to a DNS query is an RCODE of 0 and an empty answer section. The standard way to indicate the nonexistence of a name is RCODE=3 (Authoritative Name Error). The references to RCODE=NXRRSET should be changed to refer to either "RCODE=3 (Authoritative Name Error)" or "RCODE=0 with an empty answer section", as appropriate. The proposed text changes below represent my best guess as to which of the several references to NXRRSET in the text were intended as references to authoritative name errors (nonexistence of names) and which ones were intended to be RCODE=0/ANCOUNT=0 (nonexistence of an RRset at an existing name). Note that although the change I'm suggesting below would revert part of the changes made in response to Issue #10, the part of #10 that clarifies when the RRset nonexistence indication is sent (whatever its form may be) still applies. Requested change: 1. In the sentence If no positive response is received, a resolver treats it as a response that no records of the specified type and class for the specified name exist (NXRRSET). replace "(NXRRSET)" by "(that is, it is treated the same as a response with RCODE=0 and an empty answer section)". 2. Replace the text While the responder MUST NOT respond to queries for names it is not authoritative for, a responder MAY respond to a query for the name it is authoritative for, even if the type of query does not match a RR owned by the responder, with RCODE set to NXRRSET. For example, if the host has a AAAA RR, but no A RR, and an A RR query is received, the host would respond with an RCODE set to NXRRSET. by While the responder MUST NOT respond to queries for names it is not authoritative for, a responder MAY respond to a query for the name it is authoritative for, even if the type of query does not match a RR owned by the responder, with RCODE=0 and an empty answer section. For example, if the host has a AAAA RR, but no A RR, and an A RR query is received, the host would respond with RCODE=0 and an empty answer section. 3. In the text As a result, the DNS proxy will respond to AAAA RR queries sent over IPv4 or IPv6 with an RCODE of NXRRSET. replace "an RCODE of NXRRSET" by "an authoritative name error (RCODE=3)". 4. In each of the places where the draft talks about a DNS server not being configured, not replying to a query, or responding to a query with RCODE set to NXRRSET (using any of several different wordings), replace "[an] RCODE set to NXRRSET" with "an authoritative name error (RCODE=3)". -- to unsubscribe send a message to namedroppers-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 20 01:29:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27722 for ; Thu, 20 Mar 2003 01:29:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vtPT-000Izz-00 for namedroppers-data@psg.com; Wed, 19 Mar 2003 22:20:15 -0800 Received: from sentry.gw.tislabs.com ([192.94.214.100]) by psg.com with esmtp (Exim 3.36 #1) id 18vtPO-000Iz9-00 for namedroppers@ops.ietf.org; Wed, 19 Mar 2003 22:20:11 -0800 Received: by sentry.gw.tislabs.com; id BAA02302; Thu, 20 Mar 2003 01:21:02 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma002297; Thu, 20 Mar 03 01:20:59 -0500 Received: from localhost (weiler@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) with ESMTP id h2K6K4N26074 for ; Thu, 20 Mar 2003 01:20:04 -0500 (EST) Date: Thu, 20 Mar 2003 01:20:04 -0500 (EST) From: Sam Weiler X-X-Sender: To: Subject: A Plea for Restraint Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.2 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.44 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I want to see DNSSEC deployed in 2003. In recent days, several respectable people have suggested "minor" changes to the DNSSEC resource records, seeing the type code roll proposed in my draft as an opportunity to clean up past mistakes. All of these changes, every single one, are good ideas. All should have been made years ago. I want to see most of them made now. Unfortunately, protocol changes, no matter the magnitude, tend to cause delay. The work is not solely in implementation -- we need to do implementation and interoperability testing. We need to make sure we don't introduce more protocol bugs. This takes workshops. It takes testbeds. It takes time. It takes money. It requires the ongoing patience of our sponsors and employers. More importantly, exploration of these very sexy proposals will distract attention from the less sexy details that still need to be resolved before the protocol is done. The dnssec-editors have asked several questions that need our attention before the documents will be done. If we spend our time first on the additions, we won't get to the nits as quickly, and we will further draw out the DNSSEC process. I beg of everyone -- unless there's a showstopper to fix, let's bite our tongues, work through the editors' questions quickly, and let the imperfect protocol progress. As for my draft, I still think it describes a showstopper barrier to deployment, and I think the room agreed yesterday. I will, however, reissue the draft shortly with another possible resolution: do nothing. Just as I'm asking the WG to discard any proposal that is not absolutely necessary, it should use the same criteria to judge this one. -- Sam -- to unsubscribe send a message to namedroppers-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 20 01:37:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27960 for ; Thu, 20 Mar 2003 01:37:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vtWj-000Jcf-00 for namedroppers-data@psg.com; Wed, 19 Mar 2003 22:27:45 -0800 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 18vtWh-000JcR-00 for namedroppers@ops.ietf.org; Wed, 19 Mar 2003 22:27:44 -0800 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h2K5C1p09767 for ; Wed, 19 Mar 2003 21:12:02 -0800 Date: Wed, 19 Mar 2003 21:12:01 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Re: Issue 27: Inappropriate use of NXRRSET RCODE Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.2 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.44 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk A basic question about this issue. In going over the text changes, it occurs to me that it may not be an either/or -- we may want to go to LLMNR either for RCODE=3 *or* RCODE=0/ANCOUNT=0, or possible other error cases, too. So I'd like to raise the general issue and see what we come up with. One scenario which concerned us was a home gateway that had a DNS Proxy that holds only A RRs, dynamically registered via DHCPv4 (also implemented on the gateway). If we assume the gateway doesn't support dynamic client update or DHCPv6, then the question is how an IPv6-only host could resolve names on the home network dynamically, using LLMNR. So the question is what error one would receive from such a device on sending it a unicast DNS query for a AAAA RR for a host that it has other RRs for (A in this case). This would appear to be RCODE=0/ANCOUNT=0, not RCODE=3 (Authoritative Name Error). Another case is an ISP DNS server that doesn't do dynamic update, and therefore doesn't contain any RRs for the home network hosts. Here a query for an A/AAAA RR would return RCODE=3 (Authoritative Name Error), no? In this case it also seems like LLMNR might be useful. I'm curious if folks think there are other error codes that should trigger LLMNR, too. -- to unsubscribe send a message to namedroppers-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 20 02:08:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06244 for ; Thu, 20 Mar 2003 02:07:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vu0y-000LWL-00 for namedroppers-data@psg.com; Wed, 19 Mar 2003 22:59:00 -0800 Received: from cyphermail.sandelman.ottawa.on.ca ([192.139.46.78] helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 3.36 #1) id 18vu0s-000LW8-00 for namedroppers@ops.ietf.org; Wed, 19 Mar 2003 22:58:54 -0800 Received: from sandelman.ottawa.on.ca ([66.114.232.119]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h2K6v4D18015 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Thu, 20 Mar 2003 01:57:34 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1] (may be forged)) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h2K6v0YH014576 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 19 Mar 2003 22:57:02 -0800 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-5) with ESMTP id h2K6uxrY014572 for ; Wed, 19 Mar 2003 22:57:00 -0800 Message-Id: <200303200657.h2K6uxrY014572@marajade.sandelman.ottawa.on.ca> To: namedroppers@ops.ietf.org Subject: Re: KSK Flag could have a better name In-reply-to: Your message of "Wed, 19 Mar 2003 23:06:21 EST." <200303192306.21306.davidb@verisignlabs.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 19 Mar 2003 22:56:59 -0800 From: Michael Richardson X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,LINES_OF_YELLING,MAY_BE_FORGED,PGP_SIGNATURE, SPAM_PHRASE_00_01 version=2.44 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "David" == David Blacka writes: David> My belief is that the confusion here is caused by the fact that David> the term "Key Signing Key" or KSK is used so heavily in discussion David> of a particular key management technique (i.e., a separate KSK and David> ZSK) that the use of the name in the flag implies (rightly or David> wrongly) that this technique is in use. David> So, I think we need a separate term for this flag and the keys David> that use it. Perhaps "Security Entry Point Key (Flag)", or David> "Introductory Key (Flag)". I might also be a good idea for the David> KSK flag draft to be a bit more explict about how a zone signer David> should and shouldn't use this flag. okay, so this sounds like a fine idea to me. I *think* that part of the difficulty is: what does it mean when the flag is off? It was assumed by some software that if the "flag" was off, then it must be a ZSK. In fact, this isn't the case. Previously, it was believed that if: KSK = true key was Introductory key KSK = false key was zone signing key leaving no value for the person (me, in the workshop) who was too lazy to generate two keys on the first day. I wanted to use one key for both, but the tool tried to outsmart me. I am amenable to the concept that this is all a local matter. Particularly, to your view that bits on the wire that aren't important get set wrong. Except, as I said at the Mike, when I'm supposed to reverse engineer what my ISP, or worse, *YOUR* ISP has done wrong, while determining why we can not communicate/do DNS resolution. I *regularly* get calls from sites that complain I'm attacking them. Each time, it has turned out I'm *attacking* them either ICMP port unreachables, or DNS *replies*. I.e. they are soo clueless that they didn't notice they had a compromised/broken host which was initiating connections to me. This is state of the art. Getting remote debugging is really important to me. I need to write a draft that perhaps provides for more diagnostic options, cause "SERVFAIL" is just not enough when DNSSEC fails. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPnlmOIqHRg3pndX9AQGW5wQArEjBd/nxe38vMuzt2pbpSA3jVdqmirXA hxMETr+mINl5VMvyj6wpaXAy0nQy6mnecQ9J/fBQCojSv6M3q4FqBoxE9aeQ6gHF l1xJX9ERSgpRRPlEHwm30hwOCNKs7kgQScMYNrW5VSXs0GKZxwkRBIApRfXYN8Ng PH0c5x33Gw8= =1Rwn -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 20 04:25:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12495 for ; Thu, 20 Mar 2003 04:25:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vw6a-0002qz-00 for namedroppers-data@psg.com; Thu, 20 Mar 2003 01:12:56 -0800 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 18vw6X-0002qn-00 for namedroppers@ops.ietf.org; Thu, 20 Mar 2003 01:12:53 -0800 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.3/8.12.3/Debian-5) with ESMTP id h2K9ClKL029495; Thu, 20 Mar 2003 10:12:48 +0100 Received: (from miekg@localhost) by elektron.atoom.net (8.12.3/8.12.3/Debian-5) id h2K9Ckpp029494; Thu, 20 Mar 2003 10:12:46 +0100 Date: Thu, 20 Mar 2003 10:12:46 +0100 From: Miek Gieben To: David Blacka Cc: namedroppers@ops.ietf.org Subject: Re: KSK Flag could have a better name Message-ID: <20030320091246.GC29031@atoom.net> Mail-Followup-To: David Blacka , namedroppers@ops.ietf.org References: <200303192306.21306.davidb@verisignlabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200303192306.21306.davidb@verisignlabs.com> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT version=2.44 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 20 Mar, @05:06, David wrote in "KSK Flag could have a better n ..."] > My belief is that the confusion here is caused by the fact that the > term "Key Signing Key" or KSK is used so heavily in discussion of a > particular key management technique (i.e., a separate KSK and ZSK) > that the use of the name in the flag implies (rightly or wrongly) that > this technique is in use. maybe "DS key" is good name, because this is the key of which the parent has the corresponding DS, regards, Miek -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 20 08:05:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16137 for ; Thu, 20 Mar 2003 08:05:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vzb5-000EPo-00 for namedroppers-data@psg.com; Thu, 20 Mar 2003 04:56:39 -0800 Received: from maya20.nic.fr ([192.134.4.152]) by psg.com with esmtp (Exim 3.36 #1) id 18vzb2-000EPZ-00 for namedroppers@ops.ietf.org; Thu, 20 Mar 2003 04:56:36 -0800 Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id h2KCuVZL1133992; Thu, 20 Mar 2003 13:56:32 +0100 (CET) Received: by vespucci.nic.fr (Postfix, from userid 1055) id A8262110F0; Thu, 20 Mar 2003 13:56:34 +0100 (CET) Date: Thu, 20 Mar 2003 13:56:34 +0100 From: Stephane Bortzmeyer To: bert hubert Cc: Stephane Bortzmeyer , namedroppers@ops.ietf.org Subject: Re: Should a non-authoritative server put the NS records into Answer or into Authority? Message-ID: <20030320125634.GA12354@nic.fr> Reply-To: pdns-users@mailman.powerdns.com References: <200303191410.h2JEA6tF014184@ludwigV.sources.org> <20030319223235.GA26580@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030319223235.GA26580@outpost.ds9a.nl> User-Agent: Mutt/1.3.28i X-Operating-System: Debian GNU/Linux 3.0 X-Kernel: Linux 2.4.18-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ X-Spam-Status: No, hits=-3.5 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_01_02,USER_AGENT,USER_AGENT_MUTT version=2.44 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, Mar 19, 2003 at 11:32:36PM +0100, bert hubert wrote a message of 28 lines which said: > So when you query FR for the A record of www.yourdomain.fr? Non, when you query '.fr' nameservers for the NS records of yourdomain.fr. > > BIND8 and PowerDNS put the NS records into the Answer section. > > PowerDNS answers with records in the Authority record when it hands out a > referral. No. Here is an example. According the analysis of Olaf Kolkman, PowerDNS is wrong in that respect (hence the Reply-To the PowerDNS mailing list). ~ % dig @fr-powerdns-pgsql.dnsexp.eureg.org ns elysee.fr ; <<>> DiG 9.2.1 <<>> @fr-powerdns-pgsql.dnsexp.eureg.org ns elysee.fr ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25933 ;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 ;; QUESTION SECTION: ;elysee.fr. IN NS ;; ANSWER SECTION: elysee.fr. 345600 IN NS ns1.oleane.net. elysee.fr. 345600 IN NS ns0.oleane.net. elysee.fr. 345600 IN NS berlioz.elysee.fr. ;; ADDITIONAL SECTION: berlioz.elysee.fr. 345600 IN A 62.160.71.251 ;; Query time: 43 msec ;; SERVER: 192.134.7.253#53(fr-powerdns-pgsql.dnsexp.eureg.org) ;; WHEN: Thu Mar 20 13:55:56 2003 ;; MSG SIZE rcvd: 111 -- to unsubscribe send a message to namedroppers-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 20 08:16:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16267 for ; Thu, 20 Mar 2003 08:16:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vzmB-000FC9-00 for namedroppers-data@psg.com; Thu, 20 Mar 2003 05:08:07 -0800 Received: from maya20.nic.fr ([192.134.4.152]) by psg.com with esmtp (Exim 3.36 #1) id 18vzm5-000FBA-00 for namedroppers@ops.ietf.org; Thu, 20 Mar 2003 05:08:02 -0800 Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id h2KD7vZL1137005 for ; Thu, 20 Mar 2003 14:07:58 +0100 (CET) Received: by vespucci.nic.fr (Postfix, from userid 1055) id DA57D110F0; Thu, 20 Mar 2003 14:07:59 +0100 (CET) Date: Thu, 20 Mar 2003 14:07:59 +0100 From: Stephane Bortzmeyer To: namedroppers@ops.ietf.org Subject: Re: Should a non-authoritative server put the NS records into Answer or into Authority? Message-ID: <20030320130759.GD12354@nic.fr> References: <200303191410.h2JEA6tF014184@ludwigV.sources.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200303191410.h2JEA6tF014184@ludwigV.sources.org> User-Agent: Mutt/1.3.28i X-Operating-System: Debian GNU/Linux 3.0 X-Kernel: Linux 2.4.18-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ X-Spam-Status: No, hits=-2.4 required=5.0 tests=IN_REP_TO,NOSPAM_INC,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MUTT version=2.44 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, Mar 19, 2003 at 03:10:06PM +0100, Stephane Bortzmeyer wrote a message of 47 lines which said: > Sorry to use an IETF WG for my training but this question puzzles me for a > long time and, since we switched one of the nameservers of '.fr' to BIND9, it > puzzles several of our registrars as well. Someone told me that a known troll sent a message to the namedroppers mailing list mentioning "the broken .fr zone checkers". Since I filter this bozo because of the ad nominem attacks against people accused of being paid by the ISC, I missed this interesting logorrhea. I just wanted to say that, if someone has actual remarks (not name calling) or bug reports to do about ZoneCheck, he/she should direct them to zonecheck@nic.fr, which is currently completing the v2 (entirely rewritten from scratch) of the ZoneCheck tool. Advices, comments and other inputs from the community are welcome. Do note that, unlike v1, v2 separates coding from policy. The list of tests to perform, as well as their severity (warning, fatal, etc) is now in an external configuration file and can be tuned by each registry. The tool will be formally introduced by its author, Stephane d'Alu, at the next RIPE meeting in Barcelona. Version 1 is still the official one and is usable from . See by yourself. Version 2 can be tested here -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 20 08:44:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17500 for ; Thu, 20 Mar 2003 08:44:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18w0FR-000Gnu-00 for namedroppers-data@psg.com; Thu, 20 Mar 2003 05:38:21 -0800 Received: from outpost.ds9a.nl ([213.244.168.210]) by psg.com with esmtp (Exim 3.36 #1) id 18w0FO-000GnP-00 for namedroppers@ops.ietf.org; Thu, 20 Mar 2003 05:38:18 -0800 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 516844666; Thu, 20 Mar 2003 14:38:17 +0100 (CET) Date: Thu, 20 Mar 2003 14:38:17 +0100 From: bert hubert To: pdns-users@mailman.powerdns.com Cc: Stephane Bortzmeyer , namedroppers@ops.ietf.org Subject: Re: Should a non-authoritative server put the NS records into Answer or into Authority? Message-ID: <20030320133817.GA21947@outpost.ds9a.nl> References: <200303191410.h2JEA6tF014184@ludwigV.sources.org> <20030319223235.GA26580@outpost.ds9a.nl> <20030320125634.GA12354@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030320125634.GA12354@nic.fr> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-4.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MUTT version=2.44 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, Mar 20, 2003 at 01:56:34PM +0100, Stephane Bortzmeyer wrote: > No. Here is an example. According the analysis of Olaf Kolkman, > PowerDNS is wrong in that respect (hence the Reply-To the PowerDNS > mailing list). Ok, this is fixed in CVS. PowerDNS 2.9.7 was just released which incorporated the following based on your input: # PowerDNS set the 'aa' bit on serving NS records in a zone for which it was authoritative. Most implementations drop the 'aa' bit in this case and Stephane Bortzmeyer informed us of this. PowerDNS now also drops the 'aa' bit in this case. # PowerDNS can now perform AAAA additional processing optionally, turned on by setting do-ipv6-additional-processing. Thanks to Stephane Bortzmeyer for pointing out the need. In 2.9.8, PowerDNS gives this answer: $ dig NS lame.ds9a.nl @127.0.0.1 -p 5301 ; <<>> DiG 9.2.1 <<>> NS lame.ds9a.nl @127.0.0.1 -p 5301 ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25373 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;lame.ds9a.nl. IN NS ;; AUTHORITY SECTION: lame.ds9a.nl. 3600 IN NS ns1.xs4all.nl. lame.ds9a.nl. 3600 IN NS ns2.xs4all.nl. ;; Query time: 2 msec ;; SERVER: 127.0.0.1#5301(127.0.0.1) ;; WHEN: Thu Mar 20 14:37:21 2003 ;; MSG SIZE rcvd: 73 Thanks. -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing & Traffic Control HOWTO http://netherlabs.nl Consulting -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 20 08:55:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16138 for ; Thu, 20 Mar 2003 08:05:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vzcw-000EYr-00 for namedroppers-data@psg.com; Thu, 20 Mar 2003 04:58:34 -0800 Received: from maya20.nic.fr ([192.134.4.152]) by psg.com with esmtp (Exim 3.36 #1) id 18vzcu-000EYc-00 for namedroppers@ops.ietf.org; Thu, 20 Mar 2003 04:58:32 -0800 Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id h2KCwPZL1134595; Thu, 20 Mar 2003 13:58:25 +0100 (CET) Received: by vespucci.nic.fr (Postfix, from userid 1055) id D4387110F0; Thu, 20 Mar 2003 13:58:27 +0100 (CET) Date: Thu, 20 Mar 2003 13:58:27 +0100 From: Stephane Bortzmeyer To: Doug Barton Cc: Stephane Bortzmeyer , namedroppers@ops.ietf.org Subject: Re: Should a non-authoritative server put the NS records into Answer or into Authority? Message-ID: <20030320125827.GB12354@nic.fr> References: <200303191410.h2JEA6tF014184@ludwigV.sources.org> <20030319130555.M677@znfgre.tberna.bet> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030319130555.M677@znfgre.tberna.bet> User-Agent: Mutt/1.3.28i X-Operating-System: Debian GNU/Linux 3.0 X-Kernel: Linux 2.4.18-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ X-Spam-Status: No, hits=-3.2 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.44 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, Mar 19, 2003 at 01:07:03PM -0800, Doug Barton wrote a message of 65 lines which said: > > Sorry to use an IETF WG for my training > > Don't be sorry, just don't do it. :) This question belongs on > bind9-users@isc.org. Why? It has nothing to do with a given implementation. It is question of what is legal. > The short answer to your question is that BIND 9 is right. I'll send you a > longer answer in private mail. Well, thanks for the sample code (which I've forwarded to our registrars). I believe that Olaf's reply was the most precise, legally speaking. I have an opinion I can defend now :-) -- to unsubscribe send a message to namedroppers-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 20 13:22:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28095 for ; Thu, 20 Mar 2003 13:22:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18w4QT-00087F-00 for namedroppers-data@psg.com; Thu, 20 Mar 2003 10:06:01 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18w4QQ-00086X-02 for namedroppers@ops.ietf.org; Thu, 20 Mar 2003 10:05:58 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18w2zi-0001Mo-00 for namedroppers@ops.ietf.org; Thu, 20 Mar 2003 08:34:18 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 20 Mar 2003 08:34:18 -0800 To: namedroppers Subject: extend last calls in process Message-Id: X-Spam-Status: No, hits=2.0 required=5.0 tests=OPT_IN,SPAM_PHRASE_00_01,TO_LOCALPART_EQ_REAL version=2.44 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit three wg last calls were announced on 2003.03.12 opt-in threats ksk flag some folk are uncomfortable that this iesg week is in the middle of the last call period. so let's extend these three last calls one week to end on 2003.03.31. randy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 20 13:24:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28175 for ; Thu, 20 Mar 2003 13:24:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18w4U7-0008Rb-00 for namedroppers-data@psg.com; Thu, 20 Mar 2003 10:09:47 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18w4Qg-00086X-00 for namedroppers@ops.ietf.org; Thu, 20 Mar 2003 10:06:14 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18w1Ze-0000kO-00 for namedroppers@ops.ietf.org; Thu, 20 Mar 2003 07:03:18 -0800 Message-ID: <20030320130129.GC12354@nic.fr> References: <200303191410.h2JEA6tF014184@ludwigV.sources.org> <200303192200.h2JM0112003832@birch.ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200303192200.h2JM0112003832@birch.ripe.net> Date: Thu, 20 Mar 2003 14:01:29 +0100 From: Stephane Bortzmeyer To: Olaf Kolkman Cc: Stephane Bortzmeyer , namedroppers@ops.ietf.org Subject: Re: Should a non-authoritative server put the NS records into Answer or into Authority? X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO, SPAM_PHRASE_01_02 version=2.44 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] On Wed, Mar 19, 2003 at 11:00:01PM +0100, Olaf Kolkman wrote a message of 25 lines which said: > This behaviour stems from RFC1034 section 4.3.2. "Algorithm" Thanks, I believe it is reasonably clear and that settles the question. I now have a legal reference to show to my registrars. -- to unsubscribe send a message to namedroppers-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 20 14:42:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01774 for ; Thu, 20 Mar 2003 14:42:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18w5mj-000EbD-00 for namedroppers-data@psg.com; Thu, 20 Mar 2003 11:33:05 -0800 Received: from gusto.araneus.fi ([204.152.186.164]) by psg.com with esmtp (Exim 3.36 #1) id 18w5me-000Eb0-00 for namedroppers@ops.ietf.org; Thu, 20 Mar 2003 11:33:00 -0800 Received: from guava.araneus.fi (adsl-63-197-0-204.dsl.snfc21.pacbell.net [63.197.0.204]) by gusto.araneus.fi (8.12.6/8.11.6) with ESMTP id h2KJWpN0019342; Thu, 20 Mar 2003 11:32:52 -0800 (PST) Received: from guava.araneus.fi (localhost [127.0.0.1]) by guava.araneus.fi (8.12.8/8.11.6) with ESMTP id h2KJWpNl000592; Thu, 20 Mar 2003 11:32:51 -0800 (PST) Received: (from gson@localhost) by guava.araneus.fi (8.12.8/8.12.6/Submit) id h2KJWoji000589; Thu, 20 Mar 2003 11:32:50 -0800 (PST) Date: Thu, 20 Mar 2003 11:32:50 -0800 (PST) Message-Id: <200303201932.h2KJWoji000589@guava.araneus.fi> To: Bernard Aboba Cc: namedroppers@ops.ietf.org, llmnr-editors@internaut.com Subject: Re: Issue 27: Inappropriate use of NXRRSET RCODE In-Reply-To: References: X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=0.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.44 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Bernard Aboba writes: > One scenario which concerned us was a home gateway that had a DNS Proxy > that holds only A RRs, dynamically registered via DHCPv4 (also implemented > on the gateway). I am not familiar with this kind of "DNS proxy". Is there a standards document defining the functionality and behavior of such a device? Perhaps the draft's use of the term "DNS proxy" without definition should be raised as a separate Issue. > So the question is what error one would receive from such a device on > sending it a unicast DNS query for a AAAA RR for a host that it has other > RRs for (A in this case). This would appear to be RCODE=0/ANCOUNT=0, > not RCODE=3 (Authoritative Name Error). Since I don't know what kind of "DNS proxy" the text is referring to or how such a proxy is supposed to behave, I can't answer this question. > Another case is an ISP DNS server that doesn't do dynamic update, and > therefore doesn't contain any RRs for the home network hosts. Here a query > for an A/AAAA RR would return RCODE=3 (Authoritative Name Error), no? If the DNS servers authoritative for the name used by the home network host do not contain any RRs for it, they will return RCODE=3 (unless the name is an empty nonterminal). I would not use the term "an ISP DNS server" since depending on the home network host's choice of name, these servers may be completely unrelated to the home network's ISP. -- Andreas Gustafsson, gson@nominum.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 20 18:09:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12681 for ; Thu, 20 Mar 2003 18:09:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18w8tY-0002c5-00 for namedroppers-data@psg.com; Thu, 20 Mar 2003 14:52:20 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 18w8tU-0002bh-00 for namedroppers@ops.ietf.org; Thu, 20 Mar 2003 14:52:17 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h2KMqAtW036307; Thu, 20 Mar 2003 17:52:10 -0500 (EST) Received: from [130.129.133.242] ([192.136.136.26]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id RAA07105; Thu, 20 Mar 2003 17:52:09 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@ops (Unverified) Message-Id: In-Reply-To: <20030320091246.GC29031@atoom.net> References: <200303192306.21306.davidb@verisignlabs.com> <20030320091246.GC29031@atoom.net> Date: Thu, 20 Mar 2003 14:23:19 -0800 To: Miek Gieben From: Edward Lewis Subject: Re: KSK Flag could have a better name Cc: David Blacka , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-1.2 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,TO_BE_REMOVED_REPLY version=2.44 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I thimk [sic] that David is onto something. I have never liked 'SEP' though, and something close to Miek's is probably a better name - DSR (Delegation Signer Request[ed]). Or, perhaps SEP is the right one. There are two things that would make use of the bit: the gorp that sucks in keys from the child server to given them to the signing process of the parent zone the gorp that sucks in keys to prepare attestations that these are the genuine keys and that they ought to be configured in resolvers of interest At 10:12 +0100 3/20/03, Miek Gieben wrote: >[On 20 Mar, @05:06, David wrote in "KSK Flag could have a better n ..."] >> My belief is that the confusion here is caused by the fact that the >> term "Key Signing Key" or KSK is used so heavily in discussion of a >> particular key management technique (i.e., a separate KSK and ZSK) >> that the use of the name in the flag implies (rightly or wrongly) that >> this technique is in use. > >maybe "DS key" is good name, because this is the key of which the parent >has the corresponding DS, > >regards, > Miek > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 20 19:23:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15396 for ; Thu, 20 Mar 2003 19:23:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18wAEF-0005nQ-00 for namedroppers-data@psg.com; Thu, 20 Mar 2003 16:17:47 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #1) id 18wAEB-0005n3-00 for namedroppers@ops.ietf.org; Thu, 20 Mar 2003 16:17:44 -0800 Received: from ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.8/8.11.6) with ESMTP id h2L0EW12024529; Fri, 21 Mar 2003 01:14:32 +0100 Message-Id: <200303210014.h2L0EW12024529@birch.ripe.net> To: David Blacka cc: namedroppers@ops.ietf.org, ogud@ogud.com Subject: Re: KSK Flag could have a better name In-Reply-To: Message from David Blacka of "Wed, 19 Mar 2003 23:06:21 EST." <200303192306.21306.davidb@verisignlabs.com> Date: Fri, 21 Mar 2003 01:14:31 +0100 From: Olaf Kolkman X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_01_02 version=2.44 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk David Blacka writes: (...) * So, I think we need a separate term for this flag and the keys that * use it. Perhaps "Security Entry Point Key (Flag)", or "Introductory * Key (Flag)". I might also be a good idea for the KSK flag draft to be * a bit more explict about how a zone signer should and shouldn't use * this flag. (...) When this bit was first suggested, long time ago, somebody referred to it as the secure entry point (SEP) bit. While writing the document I choose to use the wording of the DS draft since I do not like to have to many definitions of different key-roles around. I agree with your point and would like to change the wording but it would be nice if the same wording would be used in the DS draft as well. So this is a suggestion to Olafur to change his text as well (we can do synchronization off-line). --Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 20 19:24:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15487 for ; Thu, 20 Mar 2003 19:24:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18wAD9-0005ko-00 for namedroppers-data@psg.com; Thu, 20 Mar 2003 16:16:39 -0800 Received: from gusto.araneus.fi ([204.152.186.164]) by psg.com with esmtp (Exim 3.36 #1) id 18wAD6-0005kS-00 for namedroppers@ops.ietf.org; Thu, 20 Mar 2003 16:16:36 -0800 Received: from guava.araneus.fi (adsl-63-197-0-204.dsl.snfc21.pacbell.net [63.197.0.204]) by gusto.araneus.fi (8.12.6/8.11.6) with ESMTP id h2L0GVN0020071; Thu, 20 Mar 2003 16:16:32 -0800 (PST) Received: from guava.araneus.fi (localhost [127.0.0.1]) by guava.araneus.fi (8.12.8/8.11.6) with ESMTP id h2L0GWNl000828; Thu, 20 Mar 2003 16:16:32 -0800 (PST) Received: (from gson@localhost) by guava.araneus.fi (8.12.8/8.12.6/Submit) id h2L0GTLU000825; Thu, 20 Mar 2003 16:16:29 -0800 (PST) Date: Thu, 20 Mar 2003 16:16:29 -0800 (PST) Message-Id: <200303210016.h2L0GTLU000825@guava.araneus.fi> To: namedroppers@ops.ietf.org Subject: draft-ietf-dnsext-insensitive-02.txt From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=2.8 required=5.0 tests=RCVD_IN_RFCI,SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.44 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk A couple of issues with draft-ietf-dnsext-insensitive-02: First of all, the draft seems much longer than it needs to be. Keep in mind that the draft arose from the following request from Erik Nordmark: [...] it would be quite helpful to point out that the DNS servers notion of "case" is limited to octets that are in the ASCII range. Otherwise folks will continue to discuss what case sensitive means for octet values >128. That could be said in a single sentence. The text on classes and extended label types in sections 3.1-3.2 are useful additional clarifications, but there is no real need for an extended treatment that at best repeats what is already said in STD 13 and at worst conflicts with it, or for historical notes on the development of movable type. 2.1 Escaping Unusual DNS Label Octets The purpose of section 2.1 is unclear. Is it merely defining the notation used for domain names in the remainder of the draft (if so, why not simply refer to RFC1035 section 5?), or is it intended as a clarification or update to RFC1035 section 5? Originally, DNS input came from an ASCII Master File as defined in [STD 13]. DNS Dynamic update has been added as a source of DNS data [RFC 2136, 3007]. When a node in the DNS name tree is created by such input, no case conversion is done and the case of ASCII labels is preserved if they are for nodes being created. However, no change is made in the name label on nodes that already exist in the DNS data being augmented or updated. [...] The same considerations apply when inputting multiple data records with owner names differing only in case. From the example above, if an "A" record is stored under owner name "xyz.BAR.example" and then a second "A" record under "XYZ.BAR.example", the second will be stored at the node with the first (lower case initial label) name. I have a problem with this text. It seems to imply that implementations must not, and do not, update the character case of existing labels in the database when they receive new data having a different character case (e.g., in a dynamic update), but such updating is not forbidden by STD 13. One could even argue that updating the case would be desirable since the most recently added data are more likely to reflect the administrator's current preferences regarding character case than the oldest data. I would like the draft to be changed to say that the final node may have the character case of either the initial name or the new name, assuming this text needs to be there at all. Another issue that needs to cleared up is whether the text in RFC1035 section 2.3.3 saying In general, this preserves the case of the first label of a domain name, but forces standardization of interior node labels. should be interpreted as saying that the character case of interior node labels MAY be standardized by the server or that it MUST be standardized. The draft seems to be assuming a MUST, but I would strongly suggest an interpretation of MAY. Making it a MUST would severely limit the options of implementers without offering any benefit in return. For example, it would outlaw implementations that store a separate copy of the complete owner name with each RRset. -- Andreas Gustafsson, gson@nominum.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 20 21:29:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19118 for ; Thu, 20 Mar 2003 21:29:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18wC9K-000AMv-00 for namedroppers-data@psg.com; Thu, 20 Mar 2003 18:20:50 -0800 Received: from maya40.nic.fr ([192.134.4.151]) by psg.com with esmtp (Exim 3.36 #1) id 18wC9G-000AMh-00 for namedroppers@ops.ietf.org; Thu, 20 Mar 2003 18:20:46 -0800 Received: from kerkenna.nic.fr (kerkenna.nic.fr [192.134.4.98]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id h2L2I1J0571260; Fri, 21 Mar 2003 03:18:01 +0100 (CET) Received: (from souissi@localhost) by kerkenna.nic.fr (8.11.6/8.9.3) id h2L2I0s11656; Fri, 21 Mar 2003 03:18:00 +0100 Date: Fri, 21 Mar 2003 03:18:00 +0100 From: Mohsen Souissi To: Robert Elz Cc: ogud@ogud.com, namedroppers@ops.ietf.org, Vladimir Ksinant , Mohsen Souissi Subject: Re: Update of RFC1886 Interop Report Message-ID: <20030321031800.B10164@kerkenna.nic.fr> References: <20030310200110.B1441@kerkenna.nic.fr> <18306.1047367805@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <18306.1047367805@munnari.OZ.AU>; from kre@munnari.OZ.AU on Tue, Mar 11, 2003 at 02:30:05PM +0700 X-Spam-Status: No, hits=-2.5 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_01_02,USER_AGENT, USER_AGENT_MUTT version=2.44 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Robert, On 11 Mar, Robert Elz wrote: | Mon, 10 Mar 2003 20:01:10 +0100 | From: Mohsen Souissi | Message-ID: <20030310200110.B1441@kerkenna.nic.fr> | | | RFC1886 Interop Report was reviewed and comments sent after the last | | call related to draft-ietf-dnsext-rfc1886bis-01.txt were taken into | | account. An updated version of the report is now available on : | | | | http://w6.afnic.fr/RFC1886/testRFC1886.html (dual-stack) | | I'm sorry to have to say that you still don't have that right. | | First, it is not "necessary" to test additional section processing of | SOA records, as none of that is required. That is, it doesn't matter | in the slightest what happens when a SOA query is done, whether NS's | are put in the auth section or not, nor whether A/AAAA are then added | to the additional section for those NS's. | | There's nothing wrong with noting that many servers do this, and thus | you decided to test it, and even to note the results, but please update | the interop report to stop it pretending that SOA testing is required | for 1886bis to go forward. | | In other words, change this text from the new report: | | So, the additional section processing of authority section must be tested. | | It is necessary to test the following records: MX, NS, SRV and SOA. | | into something like: | | So, additional section processing of the authority section was also | tested to see what implementors have done there. | | It is necessary to test the MX NS and SRV records, SOA was also tested. ==> OK, point taken. We are working on a new version of the interop report. It will be available soon. | | You do however need to test the additional section processing in a | referral, as distinct from an explicit NS lookup - those two should | be noted separately in the results. ==> The "referral" case is the result of SOA queries and it is indeed separate (in the report) from the "explicit NS lookup". | Second, when a server fails the tests (which you report server Z as | having done for some) you should find out why, and include that | information. | | It may be that from reading 1886 the authors of that server came to | different conclusions about what was required than others have. In | that case, whatever was unclear about 1886 would need to be fixed in | 1886bis so that future implementors don't get trapped the same way. | | On the other hand, there may just be admitted implementation shortfalls | or bugs in implementation Z, along the lines of "oh yes, I didn't get | to that yet" or "oops, I see what happened" or even "I don't think that's | the right thing to do so I won't do it" from the implementor, indicating | that the text in 1886 was fine, but there were implementation errors (in | which case no revisions are needed to the doc, and the buggy implementation | is irrelevant, as there are still X and Y around, and only 2 are required.) | | This is particularly true when there are just 3 implementations tested | (if there were 10 tested, and 9 did it the right way, and one didn't, | it might be reasonable to just assume "implementation bug", but with | 1 out of 3 getting it wrong that's a much bigger risk). | | [Aside: I'd love to know how an implementation can possibly fail to | support a particular domain name (as a server) ... but that's not | really relevant here - but are you sure that the particular one you | tested just wasn't "not configured for IP6.ARPA" ?] | ==> Yes, it was definitely not supported at the time of interop tests. As for the other issues, we informed the implementors about them. Our feeling is that there were bugs in the implementations in question. Only the implementors can tell whether the issues are related to the specifications or are simply bugs. We believe that if the implementors had experienced any trouble with the specifications (RFC 1886 and RC 3152), they would have shown up. Vladimir and Mohsen. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 21 14:20:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23483 for ; Fri, 21 Mar 2003 14:20:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18wRng-0004jh-00 for namedroppers-data@psg.com; Fri, 21 Mar 2003 11:03:32 -0800 Received: from h87.s239.netsol.com ([216.168.239.87] helo=localhost.localdomain) by psg.com with esmtp (Exim 3.36 #1) id 18wRnb-0004jT-00; Fri, 21 Mar 2003 11:03:27 -0800 Received: (from markk@localhost) by localhost.localdomain (8.11.6/8.11.6) id h2LJ3PB02927; Fri, 21 Mar 2003 14:03:25 -0500 Date: Fri, 21 Mar 2003 14:03:25 -0500 From: Mark Kosters To: Randy Bush Cc: namedroppers Subject: Re: extend last calls in process Message-ID: <20030321190325.GC2187@verisignlabs.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i X-Spam-Status: No, hits=-3.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MUTT version=2.44 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, Mar 20, 2003 at 08:34:18AM -0800, Randy Bush wrote: > some folk are uncomfortable that this iesg week is in the middle of > the last call period. so let's extend these three last calls one > week to end on 2003.03.31. It would be useful that once these last calls are completed, that the chairs be diligent on communicating back to the list what their impression(s) of the results are. Mark -- Mark Kosters markk@verisignlabs.com Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Mar 22 05:16:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23391 for ; Sat, 22 Mar 2003 05:16:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18wft1-000JTv-00 for namedroppers-data@psg.com; Sat, 22 Mar 2003 02:05:59 -0800 Received: from adm-dhcp-122.adm.chalmers.se ([129.16.152.27] helo=slimsixten.besserwisser.org) by psg.com with esmtp (Exim 3.36 #1) id 18wfsv-000JTj-00 for namedroppers@ops.ietf.org; Sat, 22 Mar 2003 02:05:54 -0800 Received: from localhost.besserwisser.org (mansaxel@localhost.besserwisser.org [127.0.0.1]) by slimsixten.besserwisser.org (8.12.6/8.12.2) with ESMTP id h2MA5tjd030656; Sat, 22 Mar 2003 11:05:56 +0100 (CET) Date: Thu, 20 Mar 2003 22:44:21 +0100 From: =?ISO-8859-1?Q?M=E5ns_Nilsson?= To: David Blacka , namedroppers@ops.ietf.org Subject: Re: Q-03: inclusion of KEY records in additional records section Message-ID: <195490000.1048196661@localhost> In-Reply-To: <200303192345.05600.davidb@verisignlabs.com> References: <5.1.1.6.2.20030212134348.0254be98@localhost> <200302121927.47595.davidb@verisignlabs.com> <200303192345.05600.davidb@verisignlabs.com> X-Mailer: Mulberry/2.2.1 (OpenBSD/x86) X-PGP-KEY: http://vvv.besserwisser.org/key MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========915475387==========" X-Spam-Status: No, hits=-0.7 required=5.0 tests=DATE_IN_PAST_24_48,IN_REP_TO,MIME_LONG_LINE_QP, PGP_SIGNATURE_2,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01 version=2.44 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --==========915475387========== Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable --On Wednesday, March 19, 2003 23:45:05 -0500 David Blacka wrote: > I've changed my mind. I now think that servers SHOULD attempt to send > the KEY RRs in the additional section. That is, I think that we should=20 > strengthen the rule rather than eliminate it. My reasoning is that: >=20 > * the code complexity of doing this is pretty minor, > * optimizing for fewer round trips makes sense: bandwidth will increase = > over time, but we cannot exceed the speed of light, > * since the client (via EDNS0) controls the max size of the response > and the key RRs can be silently truncated, the extra size of the message > should do no harm. This was also the conclusion arrived at during smalltalk during the pre-IETF DNSSEC workshop.=20 I am a strong supporter of the policy of including KEY records as early/often as possible. Minimising number of RTT iterations is a major speed hack, in my humble opinion.=20 --=20 M=E5ns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead. --==========915475387========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (OpenBSD) iD8DBQE+ejY102/pMZDM1cURAu2SAJ9kmLYA4/WzdoRmHL6fKmgb+b1EqACfS5v7 1IaVmJnTy1I5gem2TldgDeo= =p96+ -----END PGP SIGNATURE----- --==========915475387==========-- -- to unsubscribe send a message to namedroppers-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 22 09:19:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26249 for ; Sat, 22 Mar 2003 09:19:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18wjfK-0000wi-00 for namedroppers-data@psg.com; Sat, 22 Mar 2003 06:08:06 -0800 Received: from one.elistx.com ([209.116.252.130]) by psg.com with esmtp (Exim 3.36 #1) id 18wjfG-0000wK-00 for namedroppers@ops.ietf.org; Sat, 22 Mar 2003 06:08:02 -0800 Received: from ogud.com (pcp816081pcs.nrockv01.md.comcast.net [68.49.60.118]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HC5005GSLYV0C@eListX.com> for namedroppers@ops.ietf.org; Sat, 22 Mar 2003 09:08:55 -0500 (EST) Received: from ENGILL.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.3/8.12.3) with ESMTP id h2ME8sj6007993; Sat, 22 Mar 2003 09:08:58 -0500 (EST envelope-from ogud@ogud.com) Date: Thu, 20 Mar 2003 17:26:04 -0500 From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: Q1 followup - arguements against "MUST NOT" language In-reply-to: <200303052243.h25Mh5ip033616@drugs.dv.isc.org> X-Sender: post@localhost To: Mark.Andrews@isc.org, gson@nominum.com (Andreas Gustafsson) Cc: Scott Rose , namedroppers@ops.ietf.org Message-id: <5.1.1.6.2.20030320172329.022837b8@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=us-ascii References: X-Spam-Status: No, hits=0.9 required=5.0 tests=DATE_IN_PAST_24_48,EMAIL_ATTRIBUTION,IN_REP_TO, QUOTED_EMAIL_TEXT,RCVD_IN_RFCI,SPAM_PHRASE_00_01 version=2.44 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 17:43 2003-03-05, Mark.Andrews@isc.org wrote: > The requirement is that the case be preserved. How you achieve > that is a secondary matter. Outlawing compression is one > way. Not compressing against the QNAME is another. In this case all compression pointers would only point to Answer, Authority and additional sections. 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 Sat Mar 22 10:59:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28767 for ; Sat, 22 Mar 2003 10:59:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18wlFH-0005uN-00 for namedroppers-data@psg.com; Sat, 22 Mar 2003 07:49:19 -0800 Received: from [2001:4f8:3:bb:2e0:81ff:fe10:67ab] (helo=as.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 18wlFE-0005qV-00 for namedroppers@ops.ietf.org; Sat, 22 Mar 2003 07:49:16 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 1FC38379E40 for ; Sat, 22 Mar 2003 15:49:03 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Q-03: inclusion of KEY records in additional records section In-Reply-To: Message from =?ISO-8859-1?Q?M=E5ns_Nilsson?= of "Thu, 20 Mar 2003 22:44:21 +0100." <195490000.1048196661@localhost> X-Mailer: MH-E 7.2; nmh 1.0.4; GNU Emacs 21.2.1 Date: Sat, 22 Mar 2003 15:49:03 +0000 Message-Id: <20030322154903.1FC38379E40@as.vix.com> X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.44 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > ... I now think that servers SHOULD attempt to send the KEY RRs in > > the additional section. That is, I think that we should strengthen > > the rule rather than eliminate it. ... > This was also the conclusion arrived at during smalltalk during the > pre-IETF DNSSEC workshop. > > I am a strong supporter of the policy of including KEY records as > early/often as possible. Minimising number of RTT iterations is a major > speed hack, in my humble opinion. Me, too. -- to unsubscribe send a message to namedroppers-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 23 11:25:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05238 for ; Sun, 23 Mar 2003 11:25:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18x85y-000PNj-00 for namedroppers-data@psg.com; Sun, 23 Mar 2003 08:13:14 -0800 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 18x85T-000PI8-00 for namedroppers@ops.ietf.org; Sun, 23 Mar 2003 08:12:43 -0800 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h2NEuL625301 for ; Sun, 23 Mar 2003 06:56:21 -0800 Date: Sun, 23 Mar 2003 06:56:21 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: LLMNR Issue 29: Valid Responses Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.1 required=5.0 tests=SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.44 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Issue 29: Valid Responses Submitter: Christian Huitema Submitter email address: huitema@microsoft.com Date first submitted: January 17, 2003 Reference: Document: LLMNR-13 Comment type: T Priority: S Section: 3 Rationale/Explanation of issue: Insert the following text in Section 3: 3.1 Names and addresses in LLMNR responses Some DNS RRs include values that are specific to an interface, such as IPv4 or IPv6 addresses, or domain names that defended using the LLMNR mechanism. RRs returned in LLMNR responses MUST only include values that are valid on the local interface. In particular: * If a link-scope IPv6 address is returned in a AAAA RR, that address MUST be valid on the local link over which LLMNR is used; * If an IPv4 address is returned, it must be reachable through the link over which LLMNR is used; * If a domain name is returned (for example in a CNAME, MX or SRV record), the name must be valid on the local interface. -- to unsubscribe send a message to namedroppers-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 23 11:25:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05256 for ; Sun, 23 Mar 2003 11:25:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18x83s-000PAr-00 for namedroppers-data@psg.com; Sun, 23 Mar 2003 08:11:04 -0800 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 18x83M-000P2p-00 for namedroppers@ops.ietf.org; Sun, 23 Mar 2003 08:10:32 -0800 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h2NEsAm25201 for ; Sun, 23 Mar 2003 06:54:10 -0800 Date: Sun, 23 Mar 2003 06:54:10 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: LLMNR Issue 27: Editorial NITs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.1 required=5.0 tests=SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.44 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Issue 27: Editorial Nits Submitter: Christian Huitema Submitter email address: huitema@microsoft.com Date first submitted: January 17, 2003 Reference: Document: LLMNR-13 Comment type: E Priority: S Section: Various Rationale/Explanation of issue: Throughout the document, replace "LINKLOCAL" with "link-scope multicast". -- to unsubscribe send a message to namedroppers-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 23 11:25:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05257 for ; Sun, 23 Mar 2003 11:25:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18x84u-000PHg-00 for namedroppers-data@psg.com; Sun, 23 Mar 2003 08:12:08 -0800 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 18x84N-000PBE-00 for namedroppers@ops.ietf.org; Sun, 23 Mar 2003 08:11:35 -0800 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h2NEtEC25251 for ; Sun, 23 Mar 2003 06:55:14 -0800 Date: Sun, 23 Mar 2003 06:55:14 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: LLMNR Issue 28: Addressing Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.1 required=5.0 tests=SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.44 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Issue 28: Addressing Submitter: Christian Huitema Submitter email address: huitema@microsoft.com Date first submitted: January 17, 2003 Reference: Document: LLMNR-13 Comment type: T Priority: S Section: 2.5 Rationale/Explanation of issue: Change: "For IPv4 link-scope addressing, section 2.4 of "Dynamic Configuration of IPv4 Link-Local Addresses" [IPV4Link] lays out the rules with respect to source address selection, TTL settings, and acceptable source/destination address combinations. IPv6 is described in [RFC2460]; IPv6 link-scope addressing is described in [RFC2373]. LLMNR queries and responses obey the rules laid out in these documents. " To: "The source address of the LLMNR packets must be on link, and the destination address must be either a link-scope multicast address or an on-link address. For IPv4, an on-link address is defined as an address whose prefix belongs to a subnet on the local link; for IPv6, an on-link address is either a link-local address, as defined in the IPv6 addressing architecture, or an address whose prefix belongs to a subnet on the local link." -- to unsubscribe send a message to namedroppers-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 23 18:30:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15330 for ; Sun, 23 Mar 2003 18:30:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xEcF-000Ez0-00 for namedroppers-data@psg.com; Sun, 23 Mar 2003 15:10:59 -0800 Received: from [2001:610:ff:1::2] (helo=bartok.sidn.nl) by psg.com with esmtp (Exim 3.36 #1) id 18xEc9-000Ev2-00 for namedroppers@ops.ietf.org; Sun, 23 Mar 2003 15:10:53 -0800 Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.12.8/8.12.8) with ESMTP id h2NNAPT1065960 for ; Mon, 24 Mar 2003 00:10:27 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200303232310.h2NNAPT1065960@bartok.sidn.nl> To: namedroppers Subject: Some comments on draft-ietf-dnsext-dns-threats-02.txt Date: Mon, 24 Mar 2003 00:10:25 +0100 From: Jaap Akkerhuis X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In Section 2.1: The terminology "monkey-in-the-middle attacks." is fun but shoudn't we align it with the usual boring man in the middle? In Section 2.6: that some day it'll be on the front page of the New York Times, even if we cannot conceive of a plausible scenario involving this attack today. This implies that some mitigation of this risk is required. Do we really need to name NYT here? "frontpages of news papers" might be enough. In 4. Other issues [Odds and ends that don't yet fit anywhere else, to be revised...] Eh... Shouldn't this been revised by now? In any case, this sentence should be rewritten. In 4.1. Interactions With Other Protocols ..... This topic needs further study. and in 4.2 Dynamic update NOTE: Scaling properties of the key management problem here is a particular concern that needs more study. There is recommandation of furhther study. I assume that this is outside the scope of the current document. Maybe start of Sectiopn 4 should be: In this section we mention subjets which soesn't fit anywhere and probably need further study. and then we can drop "further study" in the sub sections. I noticed that in th conclusion it says: The authors would also like to thank Paul Mockapetris and Xunhua Wang, both of whom sent useful information to the authors, about which the authors have, as yet, done absolutely nothing. We were listening, really, we just ran out of time before the draft deadline. Are there any plans to do anything with these remarks? Just my cents, jaap -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 24 11:20:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24476 for ; Mon, 24 Mar 2003 11:20:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xUKc-000Ji6-00 for namedroppers-data@psg.com; Mon, 24 Mar 2003 07:57:50 -0800 Received: from one.elistx.com ([209.116.252.130]) by psg.com with esmtp (Exim 3.36 #1) id 18xUK5-000Jcz-00 for namedroppers@ops.ietf.org; Mon, 24 Mar 2003 07:57:17 -0800 Received: from ogud.com (pcp816081pcs.nrockv01.md.comcast.net [68.49.60.118]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HC900F6UGCCZH@eListX.com> for namedroppers@ops.ietf.org; Mon, 24 Mar 2003 10:57:49 -0500 (EST) Received: from ENGILL.ogud.com (ns.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.3/8.12.3) with ESMTP id h2OFvWj4014855; Mon, 24 Mar 2003 10:57:33 -0500 (EST envelope-from ogud@ogud.com) Date: Mon, 24 Mar 2003 10:55:21 -0500 From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: Q-03: inclusion of KEY records in additional records section In-reply-to: <195490000.1048196661@localhost> X-Sender: post@localhost To: =?iso-8859-1?Q?M=E5ns?= Nilsson , David Blacka , namedroppers@ops.ietf.org Cc: Paul Vixie Message-id: <5.1.1.6.2.20030324094803.023640f8@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=iso-8859-1 References: <200303192345.05600.davidb@verisignlabs.com> <5.1.1.6.2.20030212134348.0254be98@localhost> <200302121927.47595.davidb@verisignlabs.com> <200303192345.05600.davidb@verisignlabs.com> X-Spam-Status: No, hits=-26.7 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA24476 I'm not trying to be stubborn about this, but I do not see the benefit of the current rules for inclusion of KEY RRset in additional section. Can some resolver writers please speak up on this issue? At 16:44 2003-03-20, Måns Nilsson wrote: >--On Wednesday, March 19, 2003 23:45:05 -0500 David Blacka > wrote: > > > I've changed my mind. I now think that servers SHOULD attempt to send > > the KEY RRs in the additional section. That is, I think that we should > > strengthen the rule rather than eliminate it. My reasoning is that: > > > > * the code complexity of doing this is pretty minor, Agreed on the server side. On the resolver side there is no difference as the resolver MUST be able to look up any missing information. > > * optimizing for fewer round trips makes sense: bandwidth will increase > > over time, but we cannot exceed the speed of light, My assertion is that in most common cases there is NO savings, see the example below. > > * since the client (via EDNS0) controls the max size of the response > > and the key RRs can be silently truncated, the extra size of the message > > should do no harm. I agree 100%. >This was also the conclusion arrived at during smalltalk during the >pre-IETF DNSSEC workshop. > >I am a strong supporter of the policy of including KEY records as >early/often as possible. Minimising number of RTT iterations is a major >speed hack, in my humble opinion. RFC2535 specifies 4 cases where KEY records are to be placed in the additional section: SOA, NS, A, AAAA Do you support the rule for all four or a subset ? Given the example below, where is the benefit? >Trace (QN: query name, QT: query type, QS: server queried) >R: QN: a.b.c.d.example. QT: TXT QS: 1 >S1: > AU: d.example. NS 2 > d.example. DS > d.example. SIG(DS) > >R: QN: a.b.c.d.example. QT: TXT QS: 2 >S2: > AU: c.d.example. NS 3 > c.d.example. DS > c.d.example. SIG(DS) > >R: QN: a.b.c.d.example. QT: TXT QS:3 >S3: > AU: b.c.d.example. NS 4 > b.c.d.example. DS > b.c.d.example. SIG(DS) > >R: QN: a.b.c.d.example. QT: TXT QS:4 >S4: > AN: a.b.c.d.example. TXT > a.b.c.d.example. SIG(TXT) > >In order to validate the chain the resolver still needs to query for >KEY's for example., d.example., c.d.example., b.c.d.example. Just to be fair, cases where there is benefit: - negative answers, the SOA rule saves one query[1]. - when same server has child and a ancestor, during backtracking to the known KEY RRset, NS rule will save query KEY RRset, but DS sets have to be explicitly looked up. - Priming query for root, NS and KEY sets arrive in one packet (if the signed KEY set is small enough to fit with the signed NS set and glue). My assertion is that a security aware resolver when it sees a DS on a referral (for ) it SHOULD issue two queries in parallel:[2] one following the tree QN: QT: QS: second one asking for the KEY RRset of the zone just discovered. QN: QT: KEY QS: If resolver does this, users will not see any speed difference. If the resolver has the KEY set for there is no need to ask the second question. To avoid the second lookup the following rules can help: "referral SHOULD include the covering KEY RRset" This is saying that the KEY RRset signing DS or NXT is placed in the additional section. "always include covering KEY RRset." but this is not what the 2535 rules are saying. Olafur [1]. In the case of negative answers resolver will frequently have learned the KEY previously. What the percentage is unknown (at least to me). [2] One of the discussions the comes up when people are writing DNSSEC resolver is optimize for network or crypto delay? The argument is if you optimize for network then you may perform unneeded crypto, the second case all crypto validation takes place when it is known that there DS +KEY chain to the answer. There is no one right answer. -- to unsubscribe send a message to namedroppers-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 24 11:36:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24871 for ; Mon, 24 Mar 2003 11:36:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xUib-000Luj-00 for namedroppers-data@psg.com; Mon, 24 Mar 2003 08:22:37 -0800 Received: from thing.verisignlabs.com ([65.201.175.62] helo=cliffie.verisignlabs.com) by psg.com with esmtp (Exim 3.36 #1) id 18xUi5-000LmE-00 for namedroppers@ops.ietf.org; Mon, 24 Mar 2003 08:22:05 -0800 Received: from pinion.admin.cto.netsol.com (scooter.bo.cto.netsol.com [172.25.170.10]) (AUTH: LOGIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by cliffie.verisignlabs.com with esmtp; Mon, 24 Mar 2003 11:21:40 -0500 From: David Blacka Organization: Verisign, Inc. To: namedroppers@ops.ietf.org Subject: Re: Q-03: inclusion of KEY records in additional records section Date: Mon, 24 Mar 2003 11:21:37 -0500 User-Agent: KMail/1.5 References: <200303192345.05600.davidb@verisignlabs.com> <5.1.1.6.2.20030324094803.023640f8@localhost> In-Reply-To: <5.1.1.6.2.20030324094803.023640f8@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Message-Id: <200303241121.37529.davidb@verisignlabs.com> X-Spam-Status: No, hits=-26.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA24871 On Monday 24 March 2003 10:55 am, Ólafur Guðmundsson wrote: > > > I'm not trying to be stubborn about this, but I do not see the > benefit of the current rules for inclusion of KEY RRset in > additional section. I agreed with this. The current rules do not make sense in light of DS. > My assertion is that in most common cases there is NO savings, > see the example below. My assertion is that there may be savings, and including the KEY RRset does no harm (since it can be silently truncated). > >I am a strong supporter of the policy of including KEY records as > >early/often as possible. Minimising number of RTT iterations is a major > >speed hack, in my humble opinion. > > RFC2535 specifies 4 cases where KEY records are to be placed in > the additional section: SOA, NS, A, AAAA > > Do you support the rule for all four or a subset ? A superset. > My assertion is that a security aware resolver when it sees a DS on a > referral (for ) it SHOULD issue two queries in parallel:[2] > one following the tree > QN: QT: QS: > second one asking for the KEY RRset of the zone just discovered. > QN: QT: KEY QS: > > If resolver does this, users will not see any speed difference. > If the resolver has the KEY set for there is no need to ask > the second question. Wait a minute. Parallel queries are a pretty nice client strategy, but it isn't particularly optimal for servers. However, if the standard recommends a parallel query strategy, then including the KEY RRset is certainly less attractive. > To avoid the second lookup the following rules can help: > "referral SHOULD include the covering KEY RRset" > This is saying that the KEY RRset signing DS or NXT is placed in the > additional section. > > "always include covering KEY RRset." > > but this is not what the 2535 rules are saying. Correct. The DS document needs to change the 2535 rules. I am arguing that it should be changed to this rather than its opposite. Always including the covering KEY RRset makes sense to me. Essentially, you include the KEY RRset as soon as there is a signature that would need the keys in order to verify. As a caveat, however, it should be pointed out that without more operational experience, it is hard to tell what approach is best. If a significant percentage of DNSSEC responses get the KEY RRset truncated, maybe parallel queries are the way to go, and servers should not waste their time trying to stuff the KEY RRset into the additional section. If the larger UDP responses more frequently fragment, perhaps parallel queries are also ultimately kinder to the network. Or maybe not. -- David Blacka Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 24 13:51:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28758 for ; Mon, 24 Mar 2003 13:51:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xWrm-0009C4-00 for namedroppers-data@psg.com; Mon, 24 Mar 2003 10:40:14 -0800 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 18xWrF-00098Q-00 for namedroppers@ops.ietf.org; Mon, 24 Mar 2003 10:39:41 -0800 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 1A4C918ED for ; Mon, 24 Mar 2003 13:38:46 -0500 (EST) Date: Mon, 24 Mar 2003 13:38:46 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Q-03: inclusion of KEY records in additional records section In-Reply-To: <200303241121.37529.davidb@verisignlabs.com> References: <200303192345.05600.davidb@verisignlabs.com> <5.1.1.6.2.20030324094803.023640f8@localhost> <200303241121.37529.davidb@verisignlabs.com> User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030324183846.1A4C918ED@thrintun.hactrn.net> X-Spam-Status: No, hits=-9.9 required=5.0 tests=IN_REP_TO,REFERENCES,USER_AGENT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Three issues with putting stuff in the Additional section as a performance optimization are: - Making sure that the relative priorities of the various kinds of stuff that go into the Additional section is totally clear (ie, which goes in first); - Making sure that the rules for when the TC bit should and should not be set are totally clear; and - Making sure that the rules for what the resolver should do about all of this is totally clear. There is text on this in the DNSSECbis drafts, please read it and tell us whether we got it right. -- to unsubscribe send a message to namedroppers-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 25 08:31:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09464 for ; Tue, 25 Mar 2003 08:31:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xoH1-000827-00 for namedroppers-data@psg.com; Tue, 25 Mar 2003 05:15:27 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 18xoG6-0007wn-00 for namedroppers@ops.ietf.org; Tue, 25 Mar 2003 05:14: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 IAA08318; Tue, 25 Mar 2003 08:11:47 -0500 (EST) Message-Id: <200303251311.IAA08318@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-records-03.txt Date: Tue, 25 Mar 2003 08:11:47 -0500 X-Spam-Status: No, hits=2.2 required=5.0 tests=MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.50 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) 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 : Resource Records for DNS Security Extensions Author(s) : R. Arends et al. Filename : draft-ietf-dnsext-dnssec-records-03.txt Pages : 33 Date : 2003-3-24 This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the KEY, DS, SIG, and NXT resource records. The purpose and format of each resource record is descibed in detail and an example of each resource record is given. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-records-03.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-records-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-records-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-24141153.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-records-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-records-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-24141153.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 25 08:31:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09483 for ; Tue, 25 Mar 2003 08:31:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xoI7-00084f-00 for namedroppers-data@psg.com; Tue, 25 Mar 2003 05:16:35 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 18xoG2-0007wC-00 for namedroppers@ops.ietf.org; Tue, 25 Mar 2003 05: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 IAA08299; Tue, 25 Mar 2003 08:11:43 -0500 (EST) Message-Id: <200303251311.IAA08299@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-14.txt Date: Tue, 25 Mar 2003 08:11:42 -0500 X-Spam-Status: No, hits=2.2 required=5.0 tests=MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.50 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) 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 : Linklocal Multicast Name Resolution (LLMNR) Author(s) : L. Esibov, B. Aboba, D. Thaler Filename : draft-ietf-dnsext-mdns-14.txt Pages : 20 Date : 2003-3-24 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. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-14.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-14.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-14.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-24141142.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-24141142.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 25 12:56:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23092 for ; Tue, 25 Mar 2003 12:56:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xsOZ-000Je7-00 for namedroppers-data@psg.com; Tue, 25 Mar 2003 09:39:31 -0800 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.36 #1) id 18xsO2-000Jc7-00 for namedroppers@ops.ietf.org; Tue, 25 Mar 2003 09:38:58 -0800 Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id h2PHcYs02474; Tue, 25 Mar 2003 09:38:34 -0800 (PST) From: Bill Manning Message-Id: <200303251738.h2PHcYs02474@boreas.isi.edu> Subject: Re: llmnr vs. alternatives In-Reply-To: <20030318175658.2390F379EEF@as.vix.com> from Paul Vixie at "Mar 18, 3 05:56:58 pm" To: paul@vix.com (Paul Vixie) Date: Tue, 25 Mar 2003 09:38:34 -0800 (PST) Cc: namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-3.3 required=5.0 tests=IN_REP_TO autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % bill, as the last holder of the editor token, could you repost the draft? % Will do so. --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 25 15:12:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00199 for ; Tue, 25 Mar 2003 15:12:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xuZe-00013p-00 for namedroppers-data@psg.com; Tue, 25 Mar 2003 11:59:06 -0800 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 18xuZ8-0000za-00 for namedroppers@ops.ietf.org; Tue, 25 Mar 2003 11:58:34 -0800 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h2PIg0B27205 for ; Tue, 25 Mar 2003 10:42:01 -0800 Date: Tue, 25 Mar 2003 10:42:00 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: LLMNR issue summary Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-5.8 required=5.0 tests=USER_AGENT_PINE autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk There are currently 7 open LLMNR Issues: Issue 2: TTL=255 on Send, Check on Receive? Issue 3: Unsafe queries Issue 6: IPv6 Multicast Groups Issue 21: PTR queries Issue 28: Addressing Issue 29: Valid Responses Issue 30: Why is Dynamic Updated Needed? Issue 2 At IETF 56, the discussion seemed to indicate that sending with TTL=255 and checking on receipt would "do no harm" so that it was ok. The major issues encountered in Zeroconf WG with IPv4LL don't seem to apply here, since there are no legacy LLMNR implementations out there that set TTL to something other than 255, so we have a clean slate. Also, even if the IPv4LL draft doesn't specify setting or checking of TTL, an application can still do so. So I'd like to recommend that we keep the existing -14 text that mandates setting TTL=255 and checking it. Issue 3 The discussion at IETF 56 centered on how this would impact a typical use case: two users, one with machine bernarda.microsoft.com and another with randy.psg.com attempting to communicate over an adhoc network. The proposed change would not allow these two machines to resolve each other's name, since neither host exists within the other's "default domain". One possible solution to this would be for the two machines to answer queries for "bernarda" and "randy", rather than only answering queries for the FQDN. If this would work, then the proposed rule is ok as is. What do people think? Issue 21 Back of the envelope calculations seem to indicate to me that bogus PTR queries can be a significant problem in some cases. Measurements show that a significant fraction of DNS queries are not answered, and this is particularly true with PTR queries. So we can have a substantial amount of bogus LLMNR PTR query traffic. I am particularly worried about wireless networks with lots of people like at IETF 56. 5 queries a second from 3000 people would end up eating up a significant fraction of the total bandwidth of an 802.11 network, particularly if there are lots of folks who have to step down to lower rates (1,2,5 Mbps). So there is some reason for concern. In the discussion at IETF 56, there was concern that it might not be possible for a host to know all the networks it was connected to. The question then arises as to whether it is ok not to send a PTR query for addresses on networks the host doesn't know about. It was pointed out that if the host doesn't have a route for that address, then it will route the packet to the gateway, which might not have a route for it either. The question also arose as to why we *ever* want to send IPv6 PTR queries via LLMNR. After all, the ICMP node information query accomplishes the same thing and its use isn't restricted to linklocal. Why not use that instead? So I would like to request feedback from DNSEXT WG on whether: a. We need to send PTR queries at all via LLMNR. If we do, is this just for IPv4? Both IPv4 and IPv6? b. If we need to send them, does it make sense to restrict them to networks on-link? c. If we do send them even for networks off-link, how do you propose to deal with the ensuing bogus traffic? Issue 6 At IETF 56, the sentiment seemed to be for reducing the number of multicast groups used for IPv6. The proposed text uses multiple groups for A/AAAA queries, but a single group for all other queries. This would result in a host with a single name, but multiple addresses listening on only one multicast group for all the PTR RRs it has. One question is whether the scalability benefits of multiple groups is worth the complexity. In my mind, multiple groups do provide some scaling benefits, but only if the overall traffic load is low. If the problem outlined in Issue 21 isn't addressed, I think we will have a scaling problem for multiple groups or a single group. Opinions solicited. Issues 28 and 29 This is similar to Issue 21, in that it is proposed that the receiver check for an "on-link" address in the source address field of LLMNR queries and responses. As with Issue 21, this causes queries or responses sent from networks the host doesn't know about to be dropped. Is this corner case something we need to worry about? Issue 30 This issue claims that there is no benefit to doing a dynamic update with pre-requisite NXRRSET in order to detect duplicate UNIQUE RRs. Instead, why not just send an RR query? Perhaps someone can explain what the benefit is -- and why it outweighs the additional complexity. Personally, I do not see the benefit of dynamic update, but am willing to be convinced otherwise. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 25 15:20:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01179 for ; Tue, 25 Mar 2003 15:20:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xuk7-0001nr-00 for namedroppers-data@psg.com; Tue, 25 Mar 2003 12:09:55 -0800 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 18xuja-0001kr-00 for namedroppers@ops.ietf.org; Tue, 25 Mar 2003 12:09:23 -0800 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h2PIqnn27813 for ; Tue, 25 Mar 2003 10:52:49 -0800 Date: Tue, 25 Mar 2003 10:52:49 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: LLMNR Issues List Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-5.8 required=5.0 tests=USER_AGENT_PINE autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The LLMNR issues list has been updated to reflect the issues that were resolved in LLMNR-14. We still have 7 open issues. The list is available at: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html -- to unsubscribe send a message to namedroppers-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 25 18:13:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10217 for ; Tue, 25 Mar 2003 18:13:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xxPK-000AXQ-00 for namedroppers-data@psg.com; Tue, 25 Mar 2003 15:00:38 -0800 Received: from [fe80::203:47ff:fefa:d9e7] (helo=rip.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18xxOn-000AVV-00 for namedroppers@ops.ietf.org; Tue, 25 Mar 2003 15:00:05 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com) by rip.psg.com with esmtp (Exim 4.12) id 18xxOR-0006hC-00 for namedroppers@ops.ietf.org; Tue, 25 Mar 2003 14:59:43 -0800 Message-Id: <20030325122251.12ee18ff.Juergen@ripe.net> In-Reply-To: <200303241121.37529.davidb@verisignlabs.com> References: <200303192345.05600.davidb@verisignlabs.com> <5.1.1.6.2.20030324094803.023640f8@localhost> <200303241121.37529.davidb@verisignlabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Date: Tue, 25 Mar 2003 12:22:51 +0100 From: Juergen Pfleger To: David Blacka Cc: namedroppers@ops.ietf.org Subject: Re: Q-03: inclusion of KEY records in additional records section X-Spam-Status: No, hits=-20.7 required=5.0 tests=IN_REP_TO,MIME_LONG_LINE_QP,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REFERENCES,REPLY_WITH_QUOTES,RESENT_TO version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA10217 [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] On Monday 24 March 2003 10:55 am, Ólafur Guðmundsson wrote: > > > I'm not trying to be stubborn about this, but I do not see the > benefit of the current rules for inclusion of KEY RRset in > additional section. > > >I am a strong supporter of the policy of including KEY records as > > >early/often as possible. Minimising number of RTT iterations is a major > > >speed hack, in my humble opinion. > > > > RFC2535 specifies 4 cases where KEY records are to be placed in > > the additional section: SOA, NS, A, AAAA > > I think, adding the KEY RRset to these additional sections is enough. > > My assertion is that a security aware resolver when it sees a DS on a > > referral (for ) it SHOULD issue two queries in parallel:[2] > > one following the tree > > QN: QT: QS: > > second one asking for the KEY RRset of the zone just discovered. > > QN: QT: KEY QS: Before a resolver enters section 4 (RFC 1034 5.3.3. rsolver algorithm (analyze section)) he must know the sectstat of the current zone (ver.secure or insecure). (A magic logic has to be added between section 3 and 4 RFC1034 sect 5.3.3) That means , check if i key should be there . If yes, find the key in (cache or packet?) or query for it. If there is now key (but expected) mark server as lame , try next AA server for this zone. >From my point of view: the resolver should query ahead at the delegation point to get an AA answer for the NS record. (if certain logic is added to the resolver this may also minimize the lame delegations effect or security lameness ). The second reason to do is that we need an authoritative Key to check if the DS RRSet is pointing to the right key id before we go ahead. > > To avoid the second lookup the following rules can help: > > "referral SHOULD include the covering KEY RRset" > > This is saying that the KEY RRset signing DS or NXT is placed in the > > additional section. > > > > "always include covering KEY RRset." > > > > but this is not what the 2535 rules are saying. > > Correct. The DS document needs to change the 2535 rules. I am arguing > that it should be changed to this rather than its opposite. > > "referral SHOULD include the covering KEY RRset" I agree 100% juergen pfleger juergen@ripe.net NP-Intern -- to unsubscribe send a message to namedroppers-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 25 23:31:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17525 for ; Tue, 25 Mar 2003 23:31:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18y2KG-000NLn-00 for namedroppers-data@psg.com; Tue, 25 Mar 2003 20:15:44 -0800 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 18y2KB-000NLQ-00 for namedroppers@ops.ietf.org; Tue, 25 Mar 2003 20:15:40 -0800 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 6F07E18ED for ; Tue, 25 Mar 2003 23:15:07 -0500 (EST) Date: Tue, 25 Mar 2003 23:15:07 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Some comments on draft-ietf-dnsext-dns-threats-02.txt In-Reply-To: <200303232310.h2NNAPT1065960@bartok.sidn.nl> References: <200303232310.h2NNAPT1065960@bartok.sidn.nl> User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030326041507.6F07E18ED@thrintun.hactrn.net> X-Spam-Status: No, hits=-19.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Jaap, Thanks for all the comments. Glad to know somebody read it :). All suggestions accepted and will be incorporated except for: > In Section 2.1: > > The terminology "monkey-in-the-middle attacks." is fun but shoudn't > we align it with the usual boring man in the middle? Equal opportunity for the bad gals. -- to unsubscribe send a message to namedroppers-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 26 15:00:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10250 for ; Wed, 26 Mar 2003 15:00:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yGr3-000AEj-00 for namedroppers-data@psg.com; Wed, 26 Mar 2003 11:46:33 -0800 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 18yGqr-000ADm-00 for namedroppers@ops.ietf.org; Wed, 26 Mar 2003 11:46:22 -0800 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 60ED018EC for ; Wed, 26 Mar 2003 14:45:46 -0500 (EST) Date: Wed, 26 Mar 2003 14:45:46 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: DNS Threats In-Reply-To: <5.1.1.6.2.20030312222622.022df350@localhost> References: <5.1.1.6.2.20030312222622.022df350@localhost> User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: multipart/mixed; boundary="Multipart_Wed_Mar_26_14:44:52_2003-1" Message-Id: <20030326194546.60ED018EC@thrintun.hactrn.net> X-Spam-Status: No, hits=-21.8 required=5.0 tests=BAYES_10,IN_REP_TO,PATCH_UNIFIED_DIFF,REFERENCES,USER_AGENT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --Multipart_Wed_Mar_26_14:44:52_2003-1 Content-Type: text/plain; charset=US-ASCII I've incorporated the last call comments so far, and just did an ID-nits.html pass of my own. diff of nroff changes attached below, but for a good time check out: http://www.hactrn.net/ietf/dns/threats/changes-from-02-to-current.html which I generated using Bill Fenner's nifty htmlwdiff script. Note that a few of the changes take the form of explicitly stating that certain topics are beyond the scope of the current document rather than just not having been written yet. I think that this is consistant with what the WG is telling me (namely, that it's time to ship this puppy, and handle future work in future documents). Last, I'd appreciate it if somebody could look over the list of references to see if I got the Normative/Informative split right. There's plenty of room left in the Acknowledgements section :). Thanks! --Rob --Multipart_Wed_Mar_26_14:44:52_2003-1 Content-Type: text/plain; charset=US-ASCII diff -u -B -b -r1.18 -r1.19 --- draft-ietf-dnsext-dns-threats.ms 4 Nov 2002 05:34:55 -0000 1.18 +++ draft-ietf-dnsext-dns-threats.ms 26 Mar 2003 19:10:35 -0000 1.19 @@ -1,7 +1,7 @@ -.\" $Id: draft-ietf-dnsext-dns-threats.ms,v 1.18 2002/11/04 05:34:55 sra Exp $ +.\" $Id: draft-ietf-dnsext-dns-threats.ms,v 1.19 2003/03/26 19:10:35 sra Exp $ .\" .\" %% draft_name ::= draft-ietf-dnsext-dns-threats -.\" %% draft_number ::= 02 +.\" %% draft_number ::= 03 .\" %% author_foot ::= Atkins & Austein .\" %% author ::= D. Atkins .\" %% author ::= IHTFP Consulting @@ -97,7 +97,7 @@ While a number of detail decisions were yet to be made (and in some cases remade after implementation experience) over the subsequent -eight years, the basic model and design goals have remained fixed. +decade, the basic model and design goals have remained fixed. Nowhere, however, does any of the DNSSEC work attempt to specify in any detail the sorts of attacks against which DNSSEC is intended to @@ -107,8 +107,8 @@ until 1995, for reasons that Bellovin explained in the paper's epilogue [Bellovin95]. -While it may seem a bit strange to publish the threat analysis eight -years after starting work on the protocol designed to defend against +While it may seem a bit strange to publish the threat analysis a +decade after starting work on the protocol designed to defend against it, that is nevertheless what this note attempts to do. Better late than never. @@ -117,12 +117,12 @@ For purposes of discussion, this note uses the term "DNSSEC" to refer to the core hierarchical public key and signature mechanism specified -in the DNSSEC documents, and refer to TKEY and TSIG as separate +in the DNSSEC documents, and refers to TKEY and TSIG as separate mechanisms, even though TKEY and TSIG are also part of the larger problem of "securing DNS" and thus are often considered part of the overall set of "DNS security extensions". This is an arbitrary distinction that in part reflects the way in which the protocol has -evolved (introduction of a putatively simpler transaction model +evolved (introduction of a putatively simpler transaction model for certain operations), and perhaps should be changed in a future revision of this note. @@ -154,7 +154,7 @@ even chose to return the correct result in the answer section of a reply message while using other parts of the message to set the stage for something more complicated, for example, a name-based attack -(q.v., below). +(see below). While it certainly would be possible to sign DNS messages using TSIG or IPsec, or even to encrypt them using IPsec, this would not be a @@ -186,7 +186,7 @@ .in 5 .ti 3 -- Perform all all of the DNSSEC signature checking on its own, +- Perform all of the DNSSEC signature checking on its own, .ti 3 - Use TSIG (or some equivalent mechanism) to insure the integrity of @@ -260,8 +260,8 @@ .ti 3 - Victim issues a query, perhaps at the instigation of the attacker or -some third party; in some the query itself may be unrelated to the -name under attack (ie, the attacker is just using this query as a +some third party; in some cases the query itself may be unrelated to the +name under attack (that is, the attacker is just using this query as a means to inject false information about some other name). .ti 3 @@ -392,7 +392,7 @@ in some cases, even the immediate failure of a missing RR might be considered a problem. The question remains: how serious is this threat? Clearly the threat does exist; general paranoia says that -some day it'll be on the front page of the New York Times, even if we +some day it'll be on the front page of some major newspaper, even if we cannot conceive of a plausible scenario involving this attack today. This implies that some mitigation of this risk is required. @@ -514,9 +514,10 @@ .ti 0 .ne 4 -4. Other issues +4. Topics for Future Work -[Odds and ends that don't yet fit anywhere else, to be revised...] +This section lists a few subjects not covered above which probably +need additional study, additional mechanisms, or both. .ti 0 .ne 4 @@ -526,7 +527,7 @@ the boundaries of the DNS protocol itself, since those are the problems against (some of) which DNSSEC was intended to protect. There are, however, other potential problems at the boundaries where -DNS interacts with other protocols. This topic needs further study. +DNS interacts with other protocols. .ti 0 .ne 4 @@ -576,8 +577,8 @@ remove zones but not add them; Carol may need to be able to add, remove, or modify nodes, but only A records. -NOTE: Scaling properties of the key management problem here is a -particular concern that needs more study. +Scaling properties of the key management problem here are a particular +concern that needs more study. .ti 0 .ne 4 @@ -619,13 +620,13 @@ This entire document is about security considerations of the DNS. The authors believe that deploying DNSSEC will help to address some, but -not all, of the known threats to with DNS. +not all, of the known threats to the DNS. .ti 0 .ne 4 IANA Considerations -None known. +None. .ti 0 .ne 4 @@ -634,54 +635,25 @@ This note is based both previous published works by others and on a number of discussions both public and private over a period of many years, but particular thanks go to +Jaap Akkerhuis, Steve Bellovin, Dan Bernstein, Randy Bush, Olafur Gudmundsson, +Rip Loomis, Allison Mankin, +Paul Mockapetris, +Mans Nilsson, Paul Vixie, +Xunhua Wang, and any other members of the DNS, DNSSEC, DNSIND, and DNSEXT working groups whose names and contributions the authors have forgotten, none of whom are responsible for what the authors did with their ideas. -The authors would also like to thank Paul Mockapetris and Xunhua Wang, -both of whom sent useful information to the authors, about which the -authors have, as yet, done absolutely nothing. We were listening, -really, we just ran out of time before the draft deadline. - .in 8 .ti 0 .ne 4 -References - -.ti 3 -[Bellovin95] -Bellovin, S., -"Using the Domain Name System for System Break-Ins", -Proceedings of the Fifth Usenix Unix Security Symposium, -June 1995. - -.ti 3 -.ne 2 -[Galvin93] Design team meeting summary message posted to -dns-security@tis.com mailing list by Jim Galvin on 19 November 1993. - -.ti 3 -.ne 2 -[Schuba93] -Schuba, C., -"Addressing Weaknesses in the Domain Name System Protocol", -Master's thesis, -Purdue University Department of Computer Sciences, -August 1993. - -.ti 3 -.ne 2 -[Vixie95] -Vixie, P, -"DNS and BIND Security Issues", -Proceedings of the Fifth Usenix Unix Security Symposium, -June 1995. +Normative References .ti 3 .ne 2 @@ -710,7 +682,7 @@ .ti 3 .ne 2 [DNS-CLARIFY] -Elz, R., and Bush, R., +Elz, R., and R. Bush, "Clarifications to the DNS Specification" RFC 2181, July 1997. @@ -742,7 +714,7 @@ .ti 3 .ne 2 [TSIG] -Vixie, P., Gudmundsson, O., Eastlake, D., and Wellington, B., +Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)" RFC 2845, May 2000. @@ -779,12 +751,46 @@ RFC 3090, March 2001. +.in 8 +.ti 0 +.ne 4 +Informative References + +.ti 3 +[Bellovin95] +Bellovin, S., +"Using the Domain Name System for System Break-Ins", +Proceedings of the Fifth Usenix Unix Security Symposium, +June 1995. + +.ti 3 +.ne 2 +[Galvin93] Design team meeting summary message posted to +dns-security@tis.com mailing list by Jim Galvin on 19 November 1993. + +.ti 3 +.ne 2 +[Schuba93] +Schuba, C., +"Addressing Weaknesses in the Domain Name System Protocol", +Master's thesis, +Purdue University Department of Computer Sciences, +August 1993. + +.ti 3 +.ne 2 +[Vixie95] +Vixie, P, +"DNS and BIND Security Issues", +Proceedings of the Fifth Usenix Unix Security Symposium, +June 1995. + .ti 3 .ne 2 [SEC-CONS] Rescorla, E., Korver, B., and the Internet Architecture Board, "Guidelines for Writing RFC Text on Security Considerations", -work in progress (draft-iab-sec-cons-01.txt), +work in progress (draft-iab-sec-cons-03.txt), October 2002. .in 6 @@ -806,7 +812,46 @@ Rob Austein Email: sra@hactrn.net + .fi +.in 3 +.ti 0 +.ne 4 +Full Copyright Statement + +Copyright (C) The Internet Society (2003). All Rights Reserved. + +This document and translations of it may be copied and furnished to +others, and derivative works that comment on or otherwise explain it +or assist in its implementation may be prepared, copied, published +and distributed, in whole or in part, without restriction of any +kind, provided that the above copyright notice and this paragraph are +included on all such copies and derivative works. However, this +document itself may not be modified in any way, such as by removing +the copyright notice or references to the Internet Society or other +Internet organizations, except as needed for the purpose of +developing Internet standards in which case the procedures for +copyrights defined in the Internet Standards process must be +followed, or as required to translate it into languages other than +English. + +The limited permissions granted above are perpetual and will not be +revoked by the Internet Society or its successors or assigns. + +This document and the information contained herein is provided on an +"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING +TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING +BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION +HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF +MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +.ti 0 +.ne 4 +Acknowledgement + +Funding for the RFC Editor function is currently provided by the +Internet Society. + .\" .\" Local Variables: .\" mode:nroff --Multipart_Wed_Mar_26_14:44:52_2003-1-- -- to unsubscribe send a message to namedroppers-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 27 02:09:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15075 for ; Thu, 27 Mar 2003 02:09:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yREY-000AqH-00 for namedroppers-data@psg.com; Wed, 26 Mar 2003 22:51:30 -0800 Received: from sentry.gw.tislabs.com ([192.94.214.100]) by psg.com with esmtp (Exim 3.36 #1) id 18yRET-000Aq3-00 for namedroppers@ops.ietf.org; Wed, 26 Mar 2003 22:51:25 -0800 Received: by sentry.gw.tislabs.com; id BAA02575; Thu, 27 Mar 2003 01:52:19 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xmaa02564; Thu, 27 Mar 03 01:51:57 -0500 Received: from localhost (weiler@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) with ESMTP id h2R6p0E18738 for ; Thu, 27 Mar 2003 01:51:00 -0500 (EST) Date: Thu, 27 Mar 2003 01:51:00 -0500 (EST) From: Sam Weiler X-X-Sender: To: Subject: Re: DNSEXT WGLC: To OPT-IN or not to OPT_IN In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-13.7 required=5.0 tests=BAYES_01,IN_REP_TO,OPT_IN,OPT_IN_CAPS,USER_AGENT_PINE autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Summary: I still oppose opt-in, but for the moment I'm willing to step aside and let it advance. I am, though, going to send out a proposal to mitigate some of the damage opt-in causes. I'm also wondering if opt-in (and DS) should be held back until we fix the problem described in draft-weiler-dnsext-dnssec-2535-compat-00.txt. I would be happier if other uses for opt-in were documented. If nothing else, they would help shoot down my forthcoming proposal. I also suspect a good argument could be made for the utility of opt-in without the delegation-only restriction, though I'm not willing to wait to beat all the corner cases out of another change. I would also be more comfortable if I saw hard numbers of signing costs with and without opt-in; the fact that .com has been signed without opt-in in testbeds makes me leery of claims that it's impractical, especially with non-testbed hardware. Joerg and Frederico, can you provide more details of your analysis? (Yes, I know the list has talked about it for years, but I'm a relative newcomer, and hardware keeps getting cheaper.) Irrelevant details: First, I applaud the chairs' decisions to split this last call into two parts and then extend the last call past IETF56. I still had (and have) issues with the document, and I appreciate the extra time. And I disagree with Roy re: the appropriateness of this second last call -- mere technical completeness does not justify the advancement of a document. Second, as for consensus, the Religious Society of Friends (Quakers) have some interesting ideas about it, and I've used the phrase "step aside" as a Quaker might. Quakers, while they let one person block consensus, provide a number of ways for people to implicitly or explicitly register disapproval, discomfort, or other opposition to an action without blocking consensus and standing in the way of progress. For the moment, and this may change, that's what I'm doing. Another interesting custom during Quaker "meetings for worship with an attention to business" is that each person is expected to speak no more than once on a given topic (unless they're the chief stuckee or have peculiar specialized knowledge) -- if something more needs to be said, then the spirit will lead another to say it. Perhaps we could learn something from them. Slightly more relevant detail: Paul's 14 May message helped reframe the debate for me. He reminded me that opt-in really is optional -- a zone owner can ignore it and keep the stronger security guarantees. If that were the end of the story, I'd say we should rely on financial and political pressure, not standards process pressure, to make zone owners behave the way we want. Unfortunately, opt-in also adds resolver complexity, which means that the proponents need to justify the change. I'm not sure they've done that adequately, but I'm willing to quit fighting. They have contributed to the implementation and testing to show that the complexity is manageable, and I thank them for that. -- Sam -- to unsubscribe send a message to namedroppers-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 27 02:13:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17213 for ; Thu, 27 Mar 2003 02:13:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yRPH-000Bsq-00 for namedroppers-data@psg.com; Wed, 26 Mar 2003 23:02:35 -0800 Received: from sentry.gw.tislabs.com ([192.94.214.100]) by psg.com with esmtp (Exim 3.36 #1) id 18yRPF-000Bsc-00 for namedroppers@ops.ietf.org; Wed, 26 Mar 2003 23:02:33 -0800 Received: by sentry.gw.tislabs.com; id CAA03077; Thu, 27 Mar 2003 02:03:25 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma003043; Thu, 27 Mar 03 02:02:49 -0500 Received: from localhost (weiler@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) with ESMTP id h2R71qw19097 for ; Thu, 27 Mar 2003 02:01:52 -0500 (EST) Date: Thu, 27 Mar 2003 02:01:52 -0500 (EST) From: Sam Weiler X-X-Sender: To: Subject: Opt-in planned obsolescence In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-14.3 required=5.0 tests=BAYES_01,IN_REP_TO,OPT_IN,USER_AGENT_PINE autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This proposal addresses one of the technical concerns re: opt-in. Two of the objections to opt-in are that it 1) reduces security and 2) adds complexity. As time and technology make signing whole zones less expensive, we might get the stronger security guarantees back. We do not, however, ever get to remove the opt-in code from resolvers unless we can guarantee that ALL opt-in zones are gone. As such, the complexity cost of opt-in will stay with us eternally, long after the justification for it has passed by. If we could somehow limit the number of zones that use opt-in, we might eventually be able to obsolete opt-in and remove the opt-in code from resolvers, saving that ongoing complexity cost. The proposal: limit opt-in to TLDs. Since TLDs are relatively few in number, it's tractable to track all the operators down and beat them up. Once none use opt-in, opt-in code can be removed from resolvers. Specific text: "TLDs MAY use opt-in. Deeper delegations MUST NOT use opt-in. Resolvers SHOULD reject opt-in delegations from non-TLDs." Technically, it's still better to not do opt-in. The objections I've heard to this planned obsolescence proposal, though, aren't technical. We shouldn't put on our technical blinders just because financial and political issues are forcing us down the opt-in road -- we should still try to make the technical best of the situation. Olaf's and Scott's May 13th messages reminded me to dig this proposal up. Remember to thank them when you next see them. -- Sam -- to unsubscribe send a message to namedroppers-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 27 02:46:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18954 for ; Thu, 27 Mar 2003 02:46:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yRyE-000FSQ-00 for namedroppers-data@psg.com; Wed, 26 Mar 2003 23:38:42 -0800 Received: from sentry.gw.tislabs.com ([192.94.214.100]) by psg.com with esmtp (Exim 3.36 #1) id 18yRyB-000FQv-00 for namedroppers@ops.ietf.org; Wed, 26 Mar 2003 23:38:39 -0800 Received: by sentry.gw.tislabs.com; id CAA03766; Thu, 27 Mar 2003 02:39:33 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma003745; Thu, 27 Mar 03 02:39:27 -0500 Received: from localhost (weiler@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) with ESMTP id h2R7cUA20224 for ; Thu, 27 Mar 2003 02:38:30 -0500 (EST) Date: Thu, 27 Mar 2003 02:38:30 -0500 (EST) From: Sam Weiler X-X-Sender: To: Subject: Re: Q-6: May security-aware resolvers cache "Bad" data? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-21.2 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT, USER_AGENT_PINE autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 5 Mar 2003, Edward Lewis wrote: > Pro removal: the crypto equivalent of neg caching is possible. > OTOH: an attack of sending bad SIG's can "starve" a cache > Pro removal: local policy can be to return data only if the cd bit is set > (i.e., saves cache from requerying itself on repeated queries) > OTOH: not caching it makes the requester try to get it from source > (i.e., will return it anyway on +cd, but won't remember) I can imagine a chronically-broken delegation for which many validators/clients hard-configure a key. If a cache that knows nothing of the zone's real key is sitting in front of a bunch of those clients, should it cache the data? Ed might be on to something: you return cached data only with +cd set. Even so, I'm thinking Brian has the right security analysis: > While forbidding failure caching might be going a bit far, caching > failures is really not a good idea. It means that if a server receives > a spoofed response, it will cache the data, and use the cached failure > as an indication to not try again. This leads to obvious DoS attacks. Given the security model, though, it's sort of a toss-up -- you're only guaranteed to be able to identify bad answers, there's no guarantee that you'll get the good one. And you don't want zones getting beaten to death when their secure delegation breaks, so perhaps caching is really a good idea. Maybe it should be left to the implementation. -- Sam -- to unsubscribe send a message to namedroppers-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 27 04:17:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20747 for ; Thu, 27 Mar 2003 04:17:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yTOB-000PqV-00 for namedroppers-data@psg.com; Thu, 27 Mar 2003 01:09:35 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #1) id 18yTNo-000Ppy-00 for namedroppers@ops.ietf.org; Thu, 27 Mar 2003 01:09:12 -0800 Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.8/8.11.6) with SMTP id h2R99A12008317; Thu, 27 Mar 2003 10:09:10 +0100 Date: Thu, 27 Mar 2003 10:09:10 +0100 From: "Olaf M. Kolkman" To: Sam Weiler Cc: Subject: Re: Opt-in planned obsolescence Message-Id: <20030327100910.7cb0f5e2.olaf@ripe.net> In-Reply-To: References: Organization: RIPE NCC X-Mailer: Sylpheed version 0.8.11claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-24.2 required=5.0 tests=BAYES_01,IN_REP_TO,OPT_IN,OPT_IN_CAPS,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > This proposal addresses one of the technical concerns re: opt-in. > > Two of the objections to opt-in are that it 1) reduces security and 2) > adds complexity. Short comment: Solving complexity by adding more complexity? Longer comment: - Having OPT-IN over delegation points only and noticing that most of the zones in the world do not have very deep delegation trees I think that OPT-IN will be limited to TLDs de-facto. - This is difficult to enforce because of TLDs that have a two level structure like "co.uk." I do not think that this is very practical. I do not think that the protocol should enforce limited use. I do think that operators should think twice before deploying an OPT-IN zone. --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 27 05:09:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21724 for ; Thu, 27 Mar 2003 05:09:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yU9I-0004fc-00 for namedroppers-data@psg.com; Thu, 27 Mar 2003 01:58:16 -0800 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 18yU9G-0004fQ-00 for namedroppers@ops.ietf.org; Thu, 27 Mar 2003 01:58:14 -0800 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 2E17918DF for ; Thu, 27 Mar 2003 04:57:43 -0500 (EST) Date: Thu, 27 Mar 2003 04:57:43 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: To OPT-IN or not to OPT_IN In-Reply-To: References: User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030327095743.2E17918DF@thrintun.hactrn.net> X-Spam-Status: No, hits=-14.5 required=5.0 tests=BAYES_01,IN_REP_TO,OPT_IN,OPT_IN_CAPS,REFERENCES,USER_AGENT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I oppose opt-in, but would be willing to stand aside if the WG were to approach consensus in favor of opt-in, because I strongly agree that we need to make a decision and put this behind us. I've posted enough on this subject in the past that the reasons why I oppose opt-in should be clear by this point (for an example, see my message to this list on 4 February 2003). The summary version is that opt-in trades some near-term pain (cost) for operators of large servers against some ongoing pain (cost and complexity) for developers and resolver operators, and while I have some sympathy for the large server operators, I don't think that this is a good tradeoff for the Internet as a whole. Thanks to Sam Weiler for reminding me of appropriate terminology (having spent four years at a Friend's school, I should know this stuff, but it's been a while...). -- to unsubscribe send a message to namedroppers-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 27 06:25:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23488 for ; Thu, 27 Mar 2003 06:25:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yVPC-000DIe-00 for namedroppers-data@psg.com; Thu, 27 Mar 2003 03:18:46 -0800 Received: from [2001:6e0:206:1:250:daff:fe3d:1d6] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 3.36 #1) id 18yVPA-000DGb-00 for namedroppers@ops.ietf.org; Thu, 27 Mar 2003 03:18:44 -0800 Received: from open.nlnetlabs.nl (localhost [IPv6:::1]) by open.nlnetlabs.nl (8.12.6/8.12.6) with ESMTP id h2RBIgec020351 for ; Thu, 27 Mar 2003 12:18:42 +0100 (CET) (envelope-from ted@open.nlnetlabs.nl) Received: (from ted@localhost) by open.nlnetlabs.nl (8.12.6/8.12.6/Submit) id h2RBIf1K020350 for namedroppers@ops.ietf.org; Thu, 27 Mar 2003 12:18:41 +0100 (CET) Message-Id: <200303271118.h2RBIf1K020350@open.nlnetlabs.nl> From: ted@NLnetLabs.nl (Ted Lindgreen) Date: Thu, 27 Mar 2003 12:18:41 +0100 In-Reply-To: "Rob Austein's message as of Mar 27, 11:14" X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: To OPT-IN or not to OPT_IN X-Spam-Status: No, hits=-11.2 required=5.0 tests=BAYES_01,IN_REP_TO,OPT_IN,OPT_IN_CAPS,QUOTED_EMAIL_TEXT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [Quoting Rob Austein, on Mar 27, 11:14, in "Re: DNSEXT WGLC: To ..."] > I oppose opt-in, but would be willing to stand aside if the WG were to > approach consensus in favor of opt-in, because I strongly agree that > we need to make a decision and put this behind us. This is exactly also my position. I strongly feel that the problems that OptIn may or may not solve or impose are dwarfed by the problems we still have to face to get DNSSEC widely deployed. Most of the work sofar has been done from the viewpoint of the DNS-administrator, we still have to do a lot of work to make DNSSEC understood, working, and useful for the user. -- ted (NLnet Labs) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 27 07:14:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24511 for ; Thu, 27 Mar 2003 07:14:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yW5r-000I1P-00 for namedroppers-data@psg.com; Thu, 27 Mar 2003 04:02:51 -0800 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 18yW5o-000I19-00 for namedroppers@ops.ietf.org; Thu, 27 Mar 2003 04:02:49 -0800 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.3/8.12.3/Debian-5) with ESMTP id h2RC2g6i021081 for ; Thu, 27 Mar 2003 13:02:42 +0100 Received: (from miekg@localhost) by elektron.atoom.net (8.12.3/8.12.3/Debian-5) id h2RC2gCD021080 for namedroppers@ops.ietf.org; Thu, 27 Mar 2003 13:02:42 +0100 Date: Thu, 27 Mar 2003 13:02:42 +0100 From: Miek Gieben To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: To OPT-IN or not to OPT_IN Message-ID: <20030327120242.GB20783@atoom.net> Mail-Followup-To: namedroppers@ops.ietf.org References: <20030327095743.2E17918DF@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030327095743.2E17918DF@thrintun.hactrn.net> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-24.2 required=5.0 tests=BAYES_01,IN_REP_TO,OPT_IN,OPT_IN_CAPS,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 27 Mar, @10:57, Rob wrote in "Re: DNSEXT WGLC: To OPT-IN or ..."] > I oppose opt-in, but would be willing to stand aside if the WG were to > approach consensus in favor of opt-in, because I strongly agree that > we need to make a decision and put this behind us. I totally agree with this. That is: I oppose opt-in, but ... grtz Miek -- :wq! -- to unsubscribe send a message to namedroppers-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 27 07:56:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26105 for ; Thu, 27 Mar 2003 07:56:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yWo7-000NH7-00 for namedroppers-data@psg.com; Thu, 27 Mar 2003 04:48:35 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 18yWo5-000NFB-00 for namedroppers@ops.ietf.org; Thu, 27 Mar 2003 04:48:33 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25444; Thu, 27 Mar 2003 07:46:09 -0500 (EST) Message-Id: <200303271246.HAA25444@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-unknown-rrs-05.txt Date: Thu, 27 Mar 2003 07:46:09 -0500 X-Spam-Status: No, hits=-2.7 required=5.0 tests=BAYES_10,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) 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 : Handling of Unknown DNS Resource Record Types Author(s) : A. Gustafsson Filename : draft-ietf-dnsext-unknown-rrs-05.txt Pages : 8 Date : 2003-3-26 Extending the Domain Name System with new Resource Record types currently requires changes to name server software. This document specifies the changes necessary to allow future DNS implementations to handle new RR types transparently. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-unknown-rrs-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-unknown-rrs-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-unknown-rrs-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-26122953.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-unknown-rrs-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-unknown-rrs-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-26122953.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 27 09:04:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29276 for ; Thu, 27 Mar 2003 09:04:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yXqv-0005Xe-00 for namedroppers-data@psg.com; Thu, 27 Mar 2003 05:55:33 -0800 Received: from [2001:4f8:3:bb:2e0:81ff:fe10:67ab] (helo=as.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 18yXqt-0005Un-00 for namedroppers@ops.ietf.org; Thu, 27 Mar 2003 05:55:31 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 46EF0379E40 for ; Thu, 27 Mar 2003 13:55:18 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Opt-in planned obsolescence In-Reply-To: Message from "Olaf M. Kolkman" of "Thu, 27 Mar 2003 10:09:10 +0100." <20030327100910.7cb0f5e2.olaf@ripe.net> X-Mailer: MH-E 7.2; nmh 1.0.4; GNU Emacs 21.2.1 Date: Thu, 27 Mar 2003 13:55:18 +0000 Message-Id: <20030327135518.46EF0379E40@as.vix.com> X-Spam-Status: No, hits=-12.4 required=5.0 tests=BAYES_01,IN_REP_TO,OPT_IN_CAPS,QUOTED_EMAIL_TEXT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I do not think that this is very practical. I do not think that the > protocol should enforce limited use. I do think that operators should > think twice before deploying an OPT-IN zone. Me, too. -- to unsubscribe send a message to namedroppers-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 27 09:15:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29532 for ; Thu, 27 Mar 2003 09:15:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yY4N-0007PU-00 for namedroppers-data@psg.com; Thu, 27 Mar 2003 06:09:27 -0800 Received: from [2001:4f8:3:bb:2e0:81ff:fe10:67ab] (helo=as.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 18yY4K-0007PE-00 for namedroppers@ops.ietf.org; Thu, 27 Mar 2003 06:09:24 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 823AD379EEF for ; Thu, 27 Mar 2003 14:09:11 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Q-6: May security-aware resolvers cache "Bad" data? In-Reply-To: Message from Sam Weiler of "Thu, 27 Mar 2003 02:38:30 EST." X-Mailer: MH-E 7.2; nmh 1.0.4; GNU Emacs 21.2.1 Date: Thu, 27 Mar 2003 14:09:11 +0000 Message-Id: <20030327140911.823AD379EEF@as.vix.com> X-Spam-Status: No, hits=-12.2 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Pro removal: the crypto equivalent of neg caching is possible. > OTOH: an attack of sending bad SIG's can "starve" a cache > Pro removal: local policy can be to return data only if the cd bit is set > (i.e., saves cache from requerying itself on repeated queries) > OTOH: not caching it makes the requester try to get it from source > (i.e., will return it anyway on +cd, but won't remember) negative caching functions as a "hold-down", which on the one hand helps with authority-server and network load as well as average completion time for queries which will fail due to broken validation chains, but on the other hand means that a broken chain that is repaired will not be visible during the negative caching window. for name nonexistence we tolerate the hold-down because the chance that a name doesn't exist due to an error is thought to be low compared to the chance that it really doesn't exist. for validation failure i think we can make the same assumption. broken validation chains are errors, not omissions, and if the minimum retry interval before trying to validate it again is, say, five minutes, then it's more likely to help than hurt the zone owner. but as sam says: > Maybe it should be left to the implementation. an implementation who didn't want to do negative caching should not be considered incorrect by the specification. so, the language could be softened from "must not cache" to "may cache, with a negative TTL of up to the zone minimum ttl, if the SOA was gathered securely, or five minutes, whichever is shorter." -- to unsubscribe send a message to namedroppers-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 27 09:21:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29742 for ; Thu, 27 Mar 2003 09:21:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yYAw-0008JV-00 for namedroppers-data@psg.com; Thu, 27 Mar 2003 06:16:14 -0800 Received: from [2001:4f8:3:bb:2e0:81ff:fe10:67ab] (helo=as.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 18yYAu-0008Id-00 for namedroppers@ops.ietf.org; Thu, 27 Mar 2003 06:16:12 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 11ABF379E40 for ; Thu, 27 Mar 2003 14:15:59 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: To OPT-IN or not to OPT_IN In-Reply-To: Message from Sam Weiler of "Thu, 27 Mar 2003 01:51:00 EST." X-Mailer: MH-E 7.2; nmh 1.0.4; GNU Emacs 21.2.1 Date: Thu, 27 Mar 2003 14:15:59 +0000 Message-Id: <20030327141559.11ABF379E40@as.vix.com> X-Spam-Status: No, hits=-11.2 required=5.0 tests=BAYES_01,IN_REP_TO,OPT_IN,OPT_IN_CAPS,QUOTED_EMAIL_TEXT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Slightly more relevant detail: > > Paul's 14 May message helped reframe the debate for me. He reminded > me that opt-in really is optional -- a zone owner can ignore it and > keep the stronger security guarantees. If that were the end of the > story, I'd say we should rely on financial and political pressure, not > standards process pressure, to make zone owners behave the way we > want. Unfortunately, opt-in also adds resolver complexity, which > means that the proponents need to justify the change. I'm not sure > they've done that adequately, but I'm willing to quit fighting. They > have contributed to the implementation and testing to show that the > complexity is manageable, and I thank them for that. i think that with that as your reason for thinking it's a bad idea, that standing aside is the right thing to do. the loss of security to opt-in is optional, and represents the possibility that some other zone operator may not want as much security in their zones as you want in yours, and we would normally say that it's their zone and they should be able to decide without help from outsiders how secure their zone ought to be. now as to whether the zone security flexibility being desired is worth, or not worth, the resolver complexity that's required, we've all been down that thread and there's apparently nothing new on this controversial topic. i just want to say: it appears not to be a given, either way. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 27 10:25:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03013 for ; Thu, 27 Mar 2003 10:25:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yZ0a-000FdB-00 for namedroppers-data@psg.com; Thu, 27 Mar 2003 07:09:36 -0800 Received: from sentry.gw.tislabs.com ([192.94.214.100]) by psg.com with esmtp (Exim 3.36 #1) id 18yZ0W-000Fcz-00 for namedroppers@ops.ietf.org; Thu, 27 Mar 2003 07:09:33 -0800 Received: by sentry.gw.tislabs.com; id KAA14379; Thu, 27 Mar 2003 10:10:28 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma014354; Thu, 27 Mar 03 10:10:11 -0500 Received: from localhost (weiler@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) with ESMTP id h2RF9FC13470 for ; Thu, 27 Mar 2003 10:09:15 -0500 (EST) Date: Thu, 27 Mar 2003 10:09:15 -0500 (EST) From: Sam Weiler X-X-Sender: To: Subject: Re: DNSEXT WGLC: To OPT-IN or not to OPT_IN In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-29.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,OPT_IN_CAPS, QUOTED_EMAIL_TEXT,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 27 Mar 2003, Sam Weiler wrote: > I still oppose opt-in, but for the moment I'm willing to step aside > and let it advance. Actually, I do have a minor issue with the document itself. This sentence in the abstract is grossly overbroad: "Maintaining this cryptography is not practical or necessary." The document also does not address why signing insecure delegations is unnecessary. There are, in fact, reasons for doing so, as documented in the security considerations. Perhaps the entire sentence should be dropped? -- Sam -- to unsubscribe send a message to namedroppers-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 27 10:26:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03060 for ; Thu, 27 Mar 2003 10:26:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yYsg-000EZm-00 for namedroppers-data@psg.com; Thu, 27 Mar 2003 07:01:26 -0800 Received: from sentry.gw.tislabs.com ([192.94.214.100]) by psg.com with esmtp (Exim 3.36 #1) id 18yYsc-000EZZ-00 for namedroppers@ops.ietf.org; Thu, 27 Mar 2003 07:01:22 -0800 Received: by sentry.gw.tislabs.com; id KAA13927; Thu, 27 Mar 2003 10:02:17 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma013875; Thu, 27 Mar 03 10:01:39 -0500 Received: from localhost (weiler@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) with ESMTP id h2RF0gZ12781; Thu, 27 Mar 2003 10:00:42 -0500 (EST) Date: Thu, 27 Mar 2003 10:00:42 -0500 (EST) From: Sam Weiler X-X-Sender: To: "Olaf M. Kolkman" cc: Subject: Re: Opt-in planned obsolescence In-Reply-To: <20030327100910.7cb0f5e2.olaf@ripe.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-29.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,OPT_IN_CAPS, QUOTED_EMAIL_TEXT,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 27 Mar 2003, Olaf M. Kolkman wrote: > - Having OPT-IN over delegation points only and noticing that most of > the zones in the world do not have very deep delegation trees I think > that OPT-IN will be limited to TLDs de-facto. I suspect that even very small zones will find some creative uses for opt-in, and you'll see it at more places in the tree. > - This is difficult to enforce because of TLDs that have a two level > structure like "co.uk." I did, in fact, mean "resolvers SHOULD reject opt-in delegations from zones other than the root" or perhaps even "resolvers SHOULD reject opt-in delegations more than one label in length". Which leaves co.uk out in the cold. Having co.uk speak up or having some of the bizarre uses for opt-in documented would help persuade me that this limitation is a bad idea. -- Sam -- to unsubscribe send a message to namedroppers-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 27 10:26:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03099 for ; Thu, 27 Mar 2003 10:26:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yZB6-000H3t-00 for namedroppers-data@psg.com; Thu, 27 Mar 2003 07:20:28 -0800 Received: from ops.arin.net ([192.149.252.141]) by psg.com with esmtp (Exim 3.36 #1) id 18yZB1-000H0o-00 for namedroppers@ops.ietf.org; Thu, 27 Mar 2003 07:20:23 -0800 Received: from [192.149.252.108] ([192.136.136.26]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id KAA01582 for ; Thu, 27 Mar 2003 10:20:20 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@ops Message-Id: In-Reply-To: <20030327100910.7cb0f5e2.olaf@ripe.net> References: <20030327100910.7cb0f5e2.olaf@ripe.net> Date: Thu, 27 Mar 2003 10:20:15 -0500 To: From: Edward Lewis Subject: Re: Opt-in planned obsolescence Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-28.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 2:01 -0500 3/27/03, Sam Weiler wrote: >If we could somehow limit the number of zones that use opt-in, we >might eventually be able to obsolete opt-in and remove the opt-in code >from resolvers, saving that ongoing complexity cost. You do realize that if just one zone runs this legally, 1,394,782 resolvers need to have the code. If 1,394,782 zones run this legally, 1,394,782 resolvers need to have the code. Worse, limiting the scope is one more rule the 1,394,782 resolvers need to enforce. (About the 1,394,782 - we know who you are. ;) ) (Just kidding - the number *is* meaningless, btw.) >Since TLDs are relatively few in number That's for ICANN (et.al.) to decide, not us. (PS - what about .co.jp, .co.uk, and the like?) >it's tractable to track all the operators down and beat them up. E.g., read NANOG, for just a taste of what it takes to lay a smack down (that's evidently what the kids call it these days) on just the operators just in North America. >Technically, it's still better to not do opt-in. The objections I've >heard to this planned obsolescence proposal, though, aren't technical. >We shouldn't put on our technical blinders just because financial and >political issues are forcing us down the opt-in road -- we should >still try to make the technical best of the situation. Frankly, I don't see a technical reason to avoid opt-in. It accommodates a wider range of what operators want to offer in terms of DNSSEC while not compromising the overall operation of the DNS. Yes, descendent zones of an opt-in zone may have issues - but they choices. Okay, this is another thread. As far as code base, no implementer had said that opt-in is onerous, I've even heard that it's just a few lines of code. As far as the protocol is concerned, it's one bit in the NXT that is redefined. 'Course, signed wild cards and opt-in and dynamic update and opt-in don't mix and maybe that's a concern at some level, put pragmatically no one seems enough to care that there are really problems. >Olaf's and Scott's May 13th messages reminded me to dig this proposal >up. Remember to thank them when you next see them. I'll deal with Olaf in May. Scott, I'm coming over to your place in an hour. I'm bringing my big stick. ;) Sorry...couldn't resist. At 10:09 +0100 3/27/03, Olaf M. Kolkman wrote: >Short comment: Solving complexity by adding more complexity? Yeah, what he said. Oh, and: At 13:55 +0000 3/27/03, Paul Vixie wrote: > >Me, too. > Me, too. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer I've had it with world domination. The maintenance fees are too high. -- to unsubscribe send a message to namedroppers-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 27 12:45:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09590 for ; Thu, 27 Mar 2003 12:45:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ybEK-000A4a-00 for namedroppers-data@psg.com; Thu, 27 Mar 2003 09:31:56 -0800 Received: from [3ffe:b00:c18:3::a] (helo=jazz.viagenie.qc.ca) by psg.com with esmtp (Exim 3.36 #1) id 18ybEG-0009wa-00 for namedroppers@ops.ietf.org; Thu, 27 Mar 2003 09:31:52 -0800 Received: from localhost (retro.viagenie.qc.ca [206.123.31.22]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id h2RHV9u75826; Thu, 27 Mar 2003 12:31:09 -0500 (EST) Date: Thu, 27 Mar 2003 12:30:39 -0500 From: Marc Blanchet To: Eastlake III Donald-LDE008 cc: namedroppers@ops.ietf.org Subject: RE: draft-ietf-dnsext-insensitive-01.txt Message-ID: <2839380000.1048786239@classic.viagenie.qc.ca> In-Reply-To: <19CD0E423FC1D611893500508B6F0B9C90E530@ma07exm01.dma.isg.mot.com> References: <19CD0E423FC1D611893500508B6F0B9C90E530@ma07exm01.dma.isg.mot.co m> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Spam-Status: No, hits=-13.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA09590 - I understood the intent of the document and the DNS processing of labels. - However, I do think that some text about idn would be on subject so that the reader will have a full picture of the issue. At least some pointers to the RFCs would be useful. Here is some suggested draft text. new section: 5. Internationalized domain names (idn) idns are encoded by the applications, as specified in RFC3490, RFC3454, RFC3491, RFC3492. For non-ascii domain names that are conforming to this idn standard, an application-level transformation of the idn to a DNS conformant restricted ascii label, is handled before sent in the DNS request. The case insensitivity, which varies depending on the script used, is handled as part of the transformation, as described in RFC3454 and RFC3491. 6. Security considerations (then add the references at the end of the document). Marc. -- jeudi, mars 27, 2003 10:21:09 -0500 Eastlake III Donald-LDE008 wrote/a ecrit: > The current draft is -02, not -01. > > It's probably reasonable to add something to say that case > insensitivity isn't handled in idn. The "case insensitivity" > has only to do with byte values and the DNS has no idea whether > someone thinks some label is supposed to be ASCII or > international or alien or just a seaquence of binary octets. > > Donald > > -----Original Message----- > From: Marc Blanchet [mailto:Marc.Blanchet@viagenie.qc.ca] > Sent: Tuesday, March 18, 2003 1:12 PM > To: Eastlake III Donald-LDE008 > Cc: namedroppers@ops.ietf.org > Subject: draft-ietf-dnsext-insensitive-01.txt > > I would like to suggest to add a section to this draft about how case > insensitivity is handled in idn, in order to get some references to > additional related work (idn) that have important impact on case > insensitivity for the user point of view. > > Regards, Marc. > ------------------------------------------ Marc Blanchet Viagénie tel: +1-418-656-9254x225 ------------------------------------------ http://www.freenet6.net: IPv6 connectivity ------------------------------------------ http://www.normos.org: IETF(RFC,draft), IANA,W3C,... standards. ------------------------------------------ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 27 12:45:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09605 for ; Thu, 27 Mar 2003 12:45:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ybEp-000AC8-00 for namedroppers-data@psg.com; Thu, 27 Mar 2003 09:32:27 -0800 Received: from ops.arin.net ([192.149.252.141]) by psg.com with esmtp (Exim 3.36 #1) id 18ybEk-000A9d-00 for namedroppers@ops.ietf.org; Thu, 27 Mar 2003 09:32:23 -0800 Received: from [192.149.252.108] ([192.136.136.26]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id MAA19954; Thu, 27 Mar 2003 12:32:21 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@ops Message-Id: In-Reply-To: References: Date: Thu, 27 Mar 2003 12:32:00 -0500 To: Sam Weiler From: Edward Lewis Subject: Re: Opt-in planned obsolescence Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-31.1 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, SIGNATURE_SHORT_SPARSE autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 10:00 -0500 3/27/03, Sam Weiler wrote: >I suspect that even very small zones will find some creative uses for >opt-in, and you'll see it at more places in the tree. I'm not sure if the statement is meant as sarcasm, but in general, when a mechanism finds more usefulness than originally intended, that's a good thing. Marketing folks label this organic growth. You appear to be assuming that opt-in is dangerous. At least that's what I assume you are thinking. From my view point, opt-in is not dangerous. If a zone chooses to use opt-in, the zone has some decisions to make. E.g., is the typo attack of interest? Any zone delegated below an opt-in zone is impacted by the choices made. All other zones are not. How does opt-in impact DNS? Outside of DNSSEC, not at all. How does opt-in impact DNSSEC? To answer this, think of the situation of the resolver. Recall that DNSSEC is designed to permit a resolver to judge the authenticity of the response. DNSSEC is not designed to make statements about a zone's security preferences. Once a resolver has an answer in hand, in 2535-era DNSSEC, either the data is supposed to be unsigned or signed. How the verifier distinguished the "supposed to" is through a diligent search of the configured keys and zone cuts. All that opt-in does is allow a switch from signed to unsigned above the zone cut and not at the zone cut. The FUD is that opt-in messes up zone management security. With opt-in, a zone can't be sure that delegations are improperly inserted. With opt-in, a zone can't be sure that a signed wild card will work properly. With opt-in, we forbid dynamic update now because there hasn't been time to work it out. But DNSSEC isn't about zone management security. That's the prime defense of the opt-in supporters. Opt-in is vulnerable to delegation insertions, but so is unsecured DNS. Opt-in isn't causing a failure here. But then, why bother doing opt-in? With opt-in, I can set up a resolver to succeed in establishing some confidence in an answer in the instances that this can be done. Yes, DNSSEC without opt-in increases the the percentages of these instances to 100, but at least opt-in gets it above the current level of 0 that DNS offers today. >> - This is difficult to enforce because of TLDs that have a two level >> structure like "co.uk." > >I did, in fact, mean "resolvers SHOULD reject opt-in delegations from >zones other than the root" or perhaps even "resolvers SHOULD reject >opt-in delegations more than one label in length". Which leaves co.uk >out in the cold. Having co.uk speak up or having some of the bizarre >uses for opt-in documented would help persuade me that this limitation >is a bad idea. What do you mean be "resolvers should reject"? Why do you want to add such an artificial limitation? #ifdef ietf-debate-society Instead of asking to be persuaded that the limitation is a bad idea, you need to make a case that the limitation is a good idea. Don't fight entropy unless the disorder is becoming a nuisance. #endif (Sorry, the html tag fad is still too new for me.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer I've had it with world domination. The maintenance fees are too high. -- to unsubscribe send a message to namedroppers-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 27 12:48:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09811 for ; Thu, 27 Mar 2003 12:48:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ybLB-000AfV-00 for namedroppers-data@psg.com; Thu, 27 Mar 2003 09:39:01 -0800 Received: from ops.arin.net ([192.149.252.141]) by psg.com with esmtp (Exim 3.36 #1) id 18ybL8-000AfC-00 for namedroppers@ops.ietf.org; Thu, 27 Mar 2003 09:38:58 -0800 Received: from [192.149.252.108] ([192.136.136.26]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id MAA20872; Thu, 27 Mar 2003 12:38:57 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@ops Message-Id: In-Reply-To: References: Date: Thu, 27 Mar 2003 12:38:52 -0500 To: Sam Weiler From: Edward Lewis Subject: Re: Q-6: May security-aware resolvers cache "Bad" data? Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-29.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 2:38 -0500 3/27/03, Sam Weiler wrote: >Maybe it should be left to the implementation. Yeah - less limitations. ;) Really - since we don't know whether the hold down or the damping of traffic is better, let the implementors find out. PS - Besides the potential for the middle box having the wrong key, it might also have the wrong time. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer I've had it with world domination. The maintenance fees are too high. -- to unsubscribe send a message to namedroppers-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 27 13:16:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10763 for ; Thu, 27 Mar 2003 13:16:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ybnW-000FYx-00 for namedroppers-data@psg.com; Thu, 27 Mar 2003 10:08:18 -0800 Received: from pushme.nist.gov ([129.6.16.92] helo=postmark.nist.gov) by psg.com with esmtp (Exim 3.36 #1) id 18ybnR-000FYN-00 for namedroppers@ops.ietf.org; Thu, 27 Mar 2003 10:08:14 -0800 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h2RI7oCZ016912 for ; Thu, 27 Mar 2003 13:07:50 -0500 (EST) Message-ID: <001501c2f48b$c8bdd230$b9370681@barnacle> From: "Scott Rose" To: Subject: Open DNSSECbis spec questions Date: Thu, 27 Mar 2003 13:07:52 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit From a comment to the editor's list about re-iterating the "open questions" from the WG meeting in San Francisco (In case you can't wait for the notes): As I have them: Q1 - resolved Q2 - Should we move DSA to "optional" and have RSA/SHA1 be the only mandatory to implement algorithm? Q3 - Can we drop the requirement to add the KEY/SIG(KEY) to the additional section of a response? Q5 - Should algorithm code 252 (now "Indirect") remain, or move it to "Reserved"? Q6 - Started as "Should sec-aware resolvers cache known "BAD" data"? but now ecompasses how servers/resolvers should interpret the CD bit in the DNS header. Anybody taking notes at the time have further discussion to add to this? 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 Thu Mar 27 13:24:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11040 for ; Thu, 27 Mar 2003 13:24:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ybyM-000HJW-00 for namedroppers-data@psg.com; Thu, 27 Mar 2003 10:19:30 -0800 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 18ybyI-000HJC-00 for namedroppers@ops.ietf.org; Thu, 27 Mar 2003 10:19:26 -0800 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id B666418DF for ; Thu, 27 Mar 2003 13:18:54 -0500 (EST) Date: Thu, 27 Mar 2003 13:18:54 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Q-6: May security-aware resolvers cache "Bad" data? In-Reply-To: References: User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030327181854.B666418DF@thrintun.hactrn.net> X-Spam-Status: No, hits=-32.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Thu, 27 Mar 2003 12:38:52 -0500, Edward Lewis wrote: > > PS - Besides the potential for the middle box having the wrong key, > it might also have the wrong time. That's the case that particularly concerned 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 27 13:59:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12962 for ; Thu, 27 Mar 2003 13:59:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ycUN-000MOp-00 for namedroppers-data@psg.com; Thu, 27 Mar 2003 10:52:35 -0800 Received: from mail-pink.research.att.com ([192.20.225.111]) by psg.com with esmtp (Exim 3.36 #1) id 18ycUI-000MOc-00 for namedroppers@ops.ietf.org; Thu, 27 Mar 2003 10:52:30 -0800 Received: from bigmail.research.att.com (H-135-207-30-101.research.att.com [135.207.30.101]) by mail-pink.research.att.com (Postfix) with ESMTP id 586B858259; Thu, 27 Mar 2003 13:41:22 -0500 (EST) Received: from berkshire.research.att.com (raptor.research.att.com [135.207.23.32]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with ESMTP id h2RIqUe24040; Thu, 27 Mar 2003 13:52:30 -0500 (EST) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 991D27B4D; Thu, 27 Mar 2003 13:52:29 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: Rob Austein Cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: To OPT-IN or not to OPT_IN In-Reply-To: Your message of "Thu, 27 Mar 2003 04:57:43 EST." <20030327095743.2E17918DF@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 Mar 2003 13:52:29 -0500 Message-Id: <20030327185229.991D27B4D@berkshire.research.att.com> X-Spam-Status: No, hits=-14.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,OPT_IN_CAPS autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In message <20030327095743.2E17918DF@thrintun.hactrn.net>, Rob Austein writes: >I oppose opt-in, but would be willing to stand aside if the WG were to >approach consensus in favor of opt-in, because I strongly agree that >we need to make a decision and put this behind us. > >I've posted enough on this subject in the past that the reasons why I >oppose opt-in should be clear by this point (for an example, see my >message to this list on 4 February 2003). The summary version is that >opt-in trades some near-term pain (cost) for operators of large >servers against some ongoing pain (cost and complexity) for developers >and resolver operators, and while I have some sympathy for the large >server operators, I don't think that this is a good tradeoff for the >Internet as a whole. I agree on both points. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book) -- to unsubscribe send a message to namedroppers-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 27 14:42:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14960 for ; Thu, 27 Mar 2003 14:42:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yd9Y-00038q-00 for namedroppers-data@psg.com; Thu, 27 Mar 2003 11:35:08 -0800 Received: from ops.arin.net ([192.149.252.141]) by psg.com with esmtp (Exim 3.36 #1) id 18yd9Q-000383-00 for namedroppers@ops.ietf.org; Thu, 27 Mar 2003 11:35:00 -0800 Received: from [192.149.252.108] ([192.136.136.26]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id OAA13260; Thu, 27 Mar 2003 14:34:59 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@ops Message-Id: Date: Thu, 27 Mar 2003 14:34:52 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: opt-in and consensus Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-6.0 required=5.0 tests=BAYES_01,OPT_IN,SIGNATURE_SHORT_SPARSE version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The opt-in issue has to some extent polarized the working group into folks that are "for" opt-in and folks that are "against" opt-in. Fortunately, the polarization is not strong and for the most part amicable. But ultimately, this polarization puts the WG chairs in a nearly impossible situation. Consensus doesn't mean majority rule, nor even super majority, in fact, any sense of voting is undesirable. The fact that we have folks supporting or not supporting opt-in is a symptom that I think we've lost the way to consensus. (This is a lot like curving an exam. Where do I draw the line between the A's and B's? This kind of issue puts too much pressure on the ones 'forced' to declare the result. It's better to prepare the exam such that a curve is not needed - it can be done.) I think that the first realization is that neither the WG nor the IETF can prevent any individual (organization) from running anything on the Internet. It's coming down a realization to me that it is not up to the WG to allow or deny opt-in, but to review how it works. During the review the WG might recommend strict boundaries on the use of opt-in, with the realization that the WG can only recommend boundaries. It is the obligation of the draft editors that the review results be accurately, clearly, and faithfully reflected in the final document. Forcing our beloved chairs to choose "for" or "against" is not right. The action item for the group is to scour, test, and comment on the current document that is the definition of opt-in. This is a WG item, hence it ought to reflect our consensus. Don't review it just for grammar and spelling - is it missing something? An applicability statement? A strong enough security considerations? I sense that some folks wouldn't want to use opt-in in their zone. That's fine, there's never been a mandatory to use protocol or option. (An ISP is free to transit only Appletalk if they want, even though it is not an IETF defined standard.) For folks that do not want to use opt-in, is there a reason that your neighbor shouldn't. I'm not talking in the vein of "I invite my competitors to run their network this way" but in the vein of whether my competitors will pollute my use of the network through this use. Will opt-in undermine the ability of resolvers to authenticate data received? Will opt-in in some zones result in resolvers being able to authenticate data in zones not using opt-in? Do I want to use opt-in? That's not the question. Will opt-in in .example.com. prevent me from validating www.arin.net.? Not by the current definition, so far as I can tell. That's the view point I'd like to see reflected in the document. PS - For all the talk about the spirit of the protocol, remember that what matters is what ultimately is on the wire. Can I get from the result to a 'trust anchor' is more important in DNSSEC than if a zone is secure or not. PPS - Why am I saying this? It's not that I believe we should have it, I have no interest in opt-in either way. I feel like many others that this issue has hung on way too long - and I'm thinking that it is not the issue, but rather the discussion that is the problem. PPPS - Although I am not trying to push for opt-in, don't oppose something that does not impact you. Oppose something only if you know it will impact you (negatively). Hopefully opposition will come in a form that is easily understood ("send text"). And to be fair - a negative impact includes a large array of impacts, so don't be shy. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer I've had it with world domination. The maintenance fees are too high. -- to unsubscribe send a message to namedroppers-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 27 17:33:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22472 for ; Thu, 27 Mar 2003 17:33:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yfmK-0003yk-00 for namedroppers-data@psg.com; Thu, 27 Mar 2003 14:23:20 -0800 Received: from thing.verisignlabs.com ([65.201.175.62] helo=cliffie.verisignlabs.com) by psg.com with esmtp (Exim 3.36 #1) id 18yfmD-0003yT-00 for namedroppers@ops.ietf.org; Thu, 27 Mar 2003 14:23:13 -0800 Received: from pinion.admin.cto.netsol.com (scooter.bo.cto.netsol.com [::ffff:172.25.170.10]) (AUTH: LOGIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by cliffie.verisignlabs.com with esmtp; Thu, 27 Mar 2003 17:23:11 -0500 From: David Blacka Organization: Verisign, Inc. To: Sam Weiler , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: To OPT-IN or not to OPT_IN Date: Thu, 27 Mar 2003 17:23:09 -0500 User-Agent: KMail/1.5 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200303271723.09538.davidb@verisignlabs.com> X-Spam-Status: No, hits=-30.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,OPT_IN_CAPS, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thursday 27 March 2003 01:51 am, Sam Weiler wrote: > Summary: > > I still oppose opt-in, but for the moment I'm willing to step aside > and let it advance. I am, though, going to send out a proposal to > mitigate some of the damage opt-in causes. Damage? > I would also be more comfortable if I saw hard numbers of signing > costs with and without opt-in; the fact that .com has been signed > without opt-in in testbeds makes me leery of claims that it's > impractical, especially with non-testbed hardware. Joerg and > Frederico, can you provide more details of your analysis? (Yes, I > know the list has talked about it for years, but I'm a relative > newcomer, and hardware keeps getting cheaper.) The amount of time and the cost of the hardware needed to *sign* .com is a red herring. Opt-In has never been about making the impossible possible, or even making the impractical practical. It is about making the inefficient more efficient. And for the zones for which Opt-In is appropriate, the gains in efficiency are not temporary. Even as the costs of not doing Opt-In decrease, using Opt-In will still be better for them. Remember that, for these zones, Opt-In relieves signing, provisioning, distribution, and serving costs. Those different costs may all eventually shrink, but they don't shrink at the same rate. So I take issue with the assertion that Opt-In is all about relieving "near-term pain" at the cost of inflicting "ongoing pain". Both types of pain are ongoing. > Paul's 14 May message helped reframe the debate for me. He reminded > me that opt-in really is optional -- a zone owner can ignore it and > keep the stronger security guarantees. If that were the end of the > story, I'd say we should rely on financial and political pressure, > not standards process pressure, to make zone owners behave the way > we want. Unfortunately, opt-in also adds resolver complexity, which > means that the proponents need to justify the change. I'm not sure > they've done that adequately, but I'm willing to quit fighting. > They have contributed to the implementation and testing to show that > the complexity is manageable, and I thank them for that. What kind of justification are you looking for that hasn't been said? Some zone owners have said they want it. It very clearly solves a problem. It may not be a problem that *you* have. Lets talk about the complexity for a bit. While there certainly is a theoretical fixed, absolute cost to implementing Opt-In, we don't really know what that cost is yet. I know that whatever the cost of implementing it in BIND 9 was, the costs of implementing again in other implementations are going to be less. The more it is implemented, the greater it will be understood, and the easier it will be to implement the next time. So I certainly believe that the resolver cost is not going to be constant for the lifespan of DNSSEC. That said, I have yet to hear anything from the resolver developers why (or even if) implementing opt-in on the resolver side is hard. In fact, I have only heard (and only heard, mind you) that the resolver side was fairly easy and the authoritative part was hard. Which was not what I expected given that I found that doing an authoritative server fairly easy to implement, compared to making it do DNSSEC at all. -- David Blacka Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 27 18:06:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23721 for ; Thu, 27 Mar 2003 18:06:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ygHb-0009H4-00 for namedroppers-data@psg.com; Thu, 27 Mar 2003 14:55:39 -0800 Received: from thing.verisignlabs.com ([65.201.175.62] helo=cliffie.verisignlabs.com) by psg.com with esmtp (Exim 3.36 #1) id 18ygHZ-0009Gs-00 for namedroppers@ops.ietf.org; Thu, 27 Mar 2003 14:55:37 -0800 Received: from pinion.admin.cto.netsol.com (scooter.bo.cto.netsol.com [::ffff:172.25.170.10]) (AUTH: LOGIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by cliffie.verisignlabs.com with esmtp; Thu, 27 Mar 2003 17:55:36 -0500 From: David Blacka Organization: Verisign, Inc. To: Sam Weiler , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: To OPT-IN or not to OPT_IN Date: Thu, 27 Mar 2003 17:55:34 -0500 User-Agent: KMail/1.5 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200303271755.34080.davidb@verisignlabs.com> X-Spam-Status: No, hits=-30.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,OPT_IN_CAPS, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thursday 27 March 2003 10:09 am, Sam Weiler wrote: > On Thu, 27 Mar 2003, Sam Weiler wrote: > > > I still oppose opt-in, but for the moment I'm willing to step aside > > and let it advance. > > Actually, I do have a minor issue with the document itself. > > This sentence in the abstract is grossly overbroad: "Maintaining this > cryptography is not practical or necessary." The document also does > not address why signing insecure delegations is unnecessary. There > are, in fact, reasons for doing so, as documented in the security > considerations. Perhaps the entire sentence should be dropped? At this point, you are going to have to send text, I think. I can no longer guess what people actually want this document to say. -- David Blacka Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 27 18:57:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27031 for ; Thu, 27 Mar 2003 18:57:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yh2v-000HNj-00 for namedroppers-data@psg.com; Thu, 27 Mar 2003 15:44:33 -0800 Received: from thing.verisignlabs.com ([65.201.175.62] helo=cliffie.verisignlabs.com) by psg.com with esmtp (Exim 3.36 #1) id 18yh2s-000HNK-00 for namedroppers@ops.ietf.org; Thu, 27 Mar 2003 15:44:31 -0800 Received: from pinion.admin.cto.netsol.com (scooter.bo.cto.netsol.com [::ffff:172.25.170.10]) (AUTH: LOGIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by cliffie.verisignlabs.com with esmtp; Thu, 27 Mar 2003 18:44:27 -0500 From: David Blacka Organization: Verisign, Inc. To: David Conrad , Mark Kosters Subject: Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN Date: Thu, 27 Mar 2003 18:44:23 -0500 User-Agent: KMail/1.5 Cc: namedroppers@ops.ietf.org References: <8791B591-55E4-11D7-85A7-000393DB42B2@nominum.com> In-Reply-To: <8791B591-55E4-11D7-85A7-000393DB42B2@nominum.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200303271844.23747.davidb@verisignlabs.com> X-Spam-Status: No, hits=-31.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,OPT_IN_CAPS, QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I apologize for not catching this earlier... On Friday 14 March 2003 01:16 am, David Conrad wrote: > > And we have had some experience that it interoperates > > correctly with at least two authoritative opt-in servers. So with this > > knowledge of actual running code, perhaps we should ask ISC and/or > > Nominum to > > comment on how much more "complex" it is to add opt-in support. > > I'm told that > - implementation of the validator turns out to be easy Yay! > - implementation of the authoritative side is harder Ok, I think I understand that, at least in the context of how I think BIND 9 works. > - figuring out what needs to be cached is the hard bit Somebody absolutely needs to explain this, as Opt-In does not envision any new caching requirements. Well, the draft does talk about needing to fetch NXT records from the cache in an additional case, but that doesn't cover this statement. -- David Blacka Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 27 18:58:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27059 for ; Thu, 27 Mar 2003 18:58:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yhCZ-000JAz-00 for namedroppers-data@psg.com; Thu, 27 Mar 2003 15:54:31 -0800 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 18yhCX-000JAn-00 for namedroppers@ops.ietf.org; Thu, 27 Mar 2003 15:54:29 -0800 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 7F57618EE for ; Thu, 27 Mar 2003 18:53:57 -0500 (EST) Date: Thu, 27 Mar 2003 18:53:57 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Open DNSSECbis spec questions In-Reply-To: <001501c2f48b$c8bdd230$b9370681@barnacle> References: <001501c2f48b$c8bdd230$b9370681@barnacle> User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030327235357.7F57618EE@thrintun.hactrn.net> X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,IN_REP_TO,REFERENCES,USER_AGENT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Please also note that there are a bunch of little open issues flagged with "Editors' note" in the current text of the drafts. If the WG really needs to have the editors group pull each of those out and ask it as a separate numbered question on the mailing list, we'll do so, but one would like to think that at least a few members of this WG were actually reading the drafts. -- to unsubscribe send a message to namedroppers-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 27 22:50:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03102 for ; Thu, 27 Mar 2003 22:50:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ykip-0005hz-00 for namedroppers-data@psg.com; Thu, 27 Mar 2003 19:40:03 -0800 Received: from [fe80::203:47ff:fefa:d9e7] (helo=rip.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18ykij-0005hE-00 for namedroppers@ops.ietf.org; Thu, 27 Mar 2003 19:39:57 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com) by rip.psg.com with esmtp (Exim 4.12) id 18ykij-000MCC-00 for namedroppers@ops.ietf.org; Thu, 27 Mar 2003 19:39:57 -0800 Message-ID: <19CD0E423FC1D611893500508B6F0B9C90E530@ma07exm01.dma.isg.mot.com> MIME-Version: 1.0 Content-Type: text/plain From: Eastlake III Donald-LDE008 To: "'Marc Blanchet'" Cc: namedroppers@ops.ietf.org Subject: RE: draft-ietf-dnsext-insensitive-01.txt Date: Thu, 27 Mar 2003 10:21:09 -0500 X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] The current draft is -02, not -01. It's probably reasonable to add something to say that case insensitivity isn't handled in idn. The "case insensitivity" has only to do with byte values and the DNS has no idea whether someone thinks some label is supposed to be ASCII or international or alien or just a seaquence of binary octets. Donald -----Original Message----- From: Marc Blanchet [mailto:Marc.Blanchet@viagenie.qc.ca] Sent: Tuesday, March 18, 2003 1:12 PM To: Eastlake III Donald-LDE008 Cc: namedroppers@ops.ietf.org Subject: draft-ietf-dnsext-insensitive-01.txt I would like to suggest to add a section to this draft about how case insensitivity is handled in idn, in order to get some references to additional related work (idn) that have important impact on case insensitivity for the user point of view. Regards, Marc. -- to unsubscribe send a message to namedroppers-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 27 23:01:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03425 for ; Thu, 27 Mar 2003 23:01:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ykkV-0005qj-00 for namedroppers-data@psg.com; Thu, 27 Mar 2003 19:41:47 -0800 Received: from [fe80::203:47ff:fefa:d9e7] (helo=rip.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18ykkT-0005qX-00 for namedroppers@ops.ietf.org; Thu, 27 Mar 2003 19:41:45 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com) by rip.psg.com with esmtp (Exim 4.12) id 18ykkT-000MCO-00; Thu, 27 Mar 2003 19:41:45 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 27 Mar 2003 19:41:44 -0800 To: Sam Weiler Cc: "Olaf M. Kolkman" , Subject: Re: Opt-in planned obsolescence References: <20030327100910.7cb0f5e2.olaf@ripe.net> Message-Id: X-Spam-Status: No, hits=-14.3 required=5.0 tests=BAYES_10,OPT_IN,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I suspect that even very small zones will find some creative uses for > opt-in, and you'll see it at more places in the tree. give weenies a gun and they will shoot themselves and their neighbors in the feet. -- to unsubscribe send a message to namedroppers-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 27 23:10:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03587 for ; Thu, 27 Mar 2003 23:10:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ykzI-0008Q3-00 for namedroppers-data@psg.com; Thu, 27 Mar 2003 19:57:04 -0800 Received: from [fe80::203:47ff:fefa:d9e7] (helo=rip.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18ykzD-0008ND-00 for namedroppers@ops.ietf.org; Thu, 27 Mar 2003 19:56:59 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com) by rip.psg.com with esmtp (Exim 4.12) id 18ykzC-000MH8-00; Thu, 27 Mar 2003 19:56:58 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 27 Mar 2003 19:56:58 -0800 To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: opt-in and consensus References: Message-Id: X-Spam-Status: No, hits=-14.3 required=5.0 tests=BAYES_10,OPT_IN,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The opt-in issue has to some extent polarized the working group into > folks that are "for" opt-in and folks that are "against" opt-in. > Fortunately, the polarization is not strong and for the most part > amicable. But ultimately, this polarization puts the WG chairs in a > nearly impossible situation. what a piffle excuse for politization. -- to unsubscribe send a message to namedroppers-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 28 09:02:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28937 for ; Fri, 28 Mar 2003 09:02:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yuDT-000AHS-00 for namedroppers-data@psg.com; Fri, 28 Mar 2003 05:48:19 -0800 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.36 #1) id 18yuDQ-000AHG-00 for namedroppers@ops.ietf.org; Fri, 28 Mar 2003 05:48:16 -0800 Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id h2SDmB605825; Fri, 28 Mar 2003 05:48:11 -0800 (PST) From: Bill Manning Message-Id: <200303281348.h2SDmB605825@boreas.isi.edu> Subject: Re: llmnr vs. alternatives In-Reply-To: <200303251738.h2PHcYs02474@boreas.isi.edu> from Bill Manning at "Mar 25, 3 09:38:34 am" To: bmanning@ISI.EDU (Bill Manning) Date: Fri, 28 Mar 2003 05:48:11 -0800 (PST) Cc: paul@vix.com, namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,IN_REP_TO autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % % bill, as the last holder of the editor token, could you repost the draft? % % % Will do so. actually, its still active: draft-dnsext-opcode-discover-01.txt --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 28 10:01:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01289 for ; Fri, 28 Mar 2003 10:01:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yvC4-000NJC-00 for namedroppers-data@psg.com; Fri, 28 Mar 2003 06:50:56 -0800 Received: from [2001:4f8:3:bb:2e0:81ff:fe10:67ab] (helo=as.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 18yvC2-000NIg-00 for namedroppers@ops.ietf.org; Fri, 28 Mar 2003 06:50:54 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 78EE9379EF5 for ; Fri, 28 Mar 2003 14:50:40 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: llmnr vs. alternatives In-Reply-To: Message from Bill Manning of "Fri, 28 Mar 2003 05:48:11 PST." <200303281348.h2SDmB605825@boreas.isi.edu> X-Mailer: MH-E 7.2; nmh 1.0.4; GNU Emacs 21.2.1 Date: Fri, 28 Mar 2003 14:50:40 +0000 Message-Id: <20030328145040.78EE9379EF5@as.vix.com> X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,IN_REP_TO autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > actually, its still active: > > draft-dnsext-opcode-discover-01.txt this hasn't hasn't been on any wg meeting agenda. has anybody checked it out? with special reference to comparison against the problems still being fixed in llmnr? -- to unsubscribe send a message to namedroppers-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 28 11:05:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05167 for ; Fri, 28 Mar 2003 11:05:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ywDn-000Af1-00 for namedroppers-data@psg.com; Fri, 28 Mar 2003 07:56:47 -0800 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.36 #1) id 18ywDR-000Abm-00 for namedroppers@ops.ietf.org; Fri, 28 Mar 2003 07:56:25 -0800 Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id h2SFuNQ14719; Fri, 28 Mar 2003 07:56:23 -0800 (PST) From: Bill Manning Message-Id: <200303281556.h2SFuNQ14719@boreas.isi.edu> Subject: Re: llmnr vs. alternatives In-Reply-To: <20030328145040.78EE9379EF5@as.vix.com> from Paul Vixie at "Mar 28, 3 02:50:40 pm" To: paul@vix.com (Paul Vixie) Date: Fri, 28 Mar 2003 07:56:23 -0800 (PST) Cc: namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,IN_REP_TO autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % > actually, its still active: % > % > draft-dnsext-opcode-discover-01.txt % % this hasn't hasn't been on any wg meeting agenda. has anybody checked % it out? with special reference to comparison against the problems still % being fixed in llmnr? This draft was/is in last call and should be on the IESG agenda. The last thing that was fixed was the references. From where I sit, this was last discussed in London and was last-called just after Atl. It appears to not be on the offical last-call page off the IETF website. Looks like it was dropped again. :) Perhaps Olafur would correct my misunderstandings. --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 28 11:24:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05713 for ; Fri, 28 Mar 2003 11:24:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ywY3-000E7q-00 for namedroppers-data@psg.com; Fri, 28 Mar 2003 08:17:43 -0800 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.36 #1) id 18ywY0-000E7e-00 for namedroppers@ops.ietf.org; Fri, 28 Mar 2003 08:17:40 -0800 Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id h2SGHWc00623; Fri, 28 Mar 2003 08:17:32 -0800 (PST) From: Bill Manning Message-Id: <200303281617.h2SGHWc00623@boreas.isi.edu> Subject: Re: llmnr vs. alternatives In-Reply-To: <200303281556.h2SFuNQ14719@boreas.isi.edu> from Bill Manning at "Mar 28, 3 07:56:23 am" To: bmanning@ISI.EDU (Bill Manning) Date: Fri, 28 Mar 2003 08:17:32 -0800 (PST) Cc: paul@vix.com, namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,IN_REP_TO autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % % > actually, its still active: % % > draft-dnsext-opcode-discover-01.txt % % % % this hasn't hasn't been on any wg meeting agenda. has anybody checked % % it out? with special reference to comparison against the problems still % % being fixed in llmnr? % % % This draft was/is in last call and should be on the IESG agenda. % The last thing that was fixed was the references. From where % I sit, this was last discussed in London and was last-called % just after Atl. It appears to not be on the offical last-call % page off the IETF website. Looks like it was dropped again. :) % Perhaps Olafur would correct my misunderstandings. % going through archives... I will correct myself. The doc was within 48 hours of going to last call when one of the co-authors withdrew his support. I suspect that this action triggered the WG chairs to hold off on sending it to last call. Now that we have all the co-authors backing the drafts advancement to either experimental or informational status (I don't care which, as long as it does not go on the Stds track), perhaps the WG chairs would push it out for the IESG to consider it for publication. --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 31 04:33:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00233 for ; Mon, 31 Mar 2003 04:33:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18zvSQ-000MjL-00 for namedroppers-data@psg.com; Mon, 31 Mar 2003 01:19:58 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #1) id 18zvSO-000Mj7-00 for namedroppers@ops.ietf.org; Mon, 31 Mar 2003 01:19:56 -0800 Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.9/8.11.6) with SMTP id h2V9JsRp015997 for ; Mon, 31 Mar 2003 11:19:54 +0200 Date: Mon, 31 Mar 2003 11:19:54 +0200 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: DNSSEC protocol doc question: pre-conf keys. Message-Id: <20030331111954.01add0a0.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.8.11claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I am going through the DNSSEC protocol modifications document (version 01) to get an answer to the following question: Is it legal to have a pre-configured key (trusted-key in bind) that is not included in the apex KEY RR set but that is used to create a signature over that KEY RR set? I've carefully read section 2 and section 4 of the document. But may have been looking at the wrong place for the answer. Anyhow, the situation seems to be allowed by the following sentence in section 2: "For each private key used to create SIG RRs, there SHOULD be a corresponding KEY RR stored at the zone apex" Given the SHOULD, a resolver should be able with the case of a KSK which signes ZSKs in the apex Key RR set and that is exclusively configured in the resolvers configuration and does not live in the apex Key RR set. Is this a proper interpretation? If so I am afraid that there are other interpretations possible. The issue of how to deal with preconfigured keys is not spelled out, shouldn't it? -- 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 31 05:09:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00755 for ; Mon, 31 Mar 2003 05:09:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18zwAs-000Oo4-00 for namedroppers-data@psg.com; Mon, 31 Mar 2003 02:05:54 -0800 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 18zwAq-000Ons-00 for namedroppers@ops.ietf.org; Mon, 31 Mar 2003 02:05:52 -0800 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.3/8.12.3/Debian-5) with ESMTP id h2VA5kit031115; Mon, 31 Mar 2003 12:05:46 +0200 Received: (from miekg@localhost) by elektron.atoom.net (8.12.3/8.12.3/Debian-5) id h2VA5k5j031114; Mon, 31 Mar 2003 12:05:46 +0200 Date: Mon, 31 Mar 2003 12:05:46 +0200 From: Miek Gieben To: "Olaf M. Kolkman" Cc: namedroppers@ops.ietf.org Subject: Re: DNSSEC protocol doc question: pre-conf keys. Message-ID: <20030331100546.GB30673@atoom.net> Mail-Followup-To: "Olaf M. Kolkman" , namedroppers@ops.ietf.org References: <20030331111954.01add0a0.olaf@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030331111954.01add0a0.olaf@ripe.net> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-26.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 31 Mar, @11:19, Olaf wrote in "DNSSEC protocol doc question: ..."] > > > I am going through the DNSSEC protocol modifications document (version > 01) to get an answer to the following question: > > > Is it legal to have a pre-configured key (trusted-key in bind) that > is not included in the apex KEY RR set but that is used to create a > signature over that KEY RR set? > > > I've carefully read section 2 and section 4 of the document. But may > have been looking at the wrong place for the answer. In section 5 it says: An initial KEY RR can be used to authenticate a zone's apex KEY RRset. To authenticate an apex KEY RRset using an initial key, the resolver MUST: 1. Verify that the initial KEY RR appears in the apex KEY RRset, and verify that the KEY RR has the Zone Key Flag (KEY RDATA bit 7) set to one. 2. Verify that there is some SIG RR which covers the apex KEY RRset, and that the combination of the SIG RR and the initial KEY RR authenticates the KEY RRset. The process for using a SIG RR to authenticate an RRset is described in Section 5.2. > Anyhow, the situation seems to be allowed by the following sentence in > section 2: > > "For each private key used to create SIG RRs, there SHOULD be a > corresponding KEY RR stored at the zone apex" > > Given the SHOULD, a resolver should be able with the case of a > KSK which signes ZSKs in the apex Key RR set and that is exclusively > configured in the resolvers configuration and does not live in the > apex Key RR set. in section 5 it is a MUST, so this seems a contradiction to me.... Besides this, I also think that step 1. for the resolver is not necessary. If there is a sig that matches, shouldn't that be enough? grtz Miek -- :wq! -- to unsubscribe send a message to namedroppers-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 31 05:41:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01182 for ; Mon, 31 Mar 2003 05:41:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18zwfF-000Pvq-00 for namedroppers-data@psg.com; Mon, 31 Mar 2003 02:37:17 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #1) id 18zwfC-000PvZ-00 for namedroppers@ops.ietf.org; Mon, 31 Mar 2003 02:37:15 -0800 Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.9/8.11.6) with SMTP id h2VAbDRp004238 for ; Mon, 31 Mar 2003 12:37:13 +0200 Date: Mon, 31 Mar 2003 12:37:13 +0200 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: Re: DNSSEC protocol doc question: pre-conf keys. Message-Id: <20030331123713.13cfbd32.olaf@ripe.net> In-Reply-To: <20030331111954.01add0a0.olaf@ripe.net> References: <20030331111954.01add0a0.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.8.11claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-26.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Thanks Miek, > The issue of how to deal with preconfigured keys is not spelled out, > shouldn't it? Sorry, that statement is not true... It is spelled out in section 5 (*blush*). --Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 31 08:18:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05641 for ; Mon, 31 Mar 2003 08:18:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18zz3D-0006fV-00 for namedroppers-data@psg.com; Mon, 31 Mar 2003 05:10:11 -0800 Received: from pushme.nist.gov ([129.6.16.92] helo=postmark.nist.gov) by psg.com with esmtp (Exim 3.36 #1) id 18zz39-0006f7-00 for namedroppers@ops.ietf.org; Mon, 31 Mar 2003 05:10:07 -0800 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h2VD9iCZ016742 for ; Mon, 31 Mar 2003 08:09:44 -0500 (EST) Message-ID: <005a01c2f786$cd4625c0$b9370681@barnacle> From: "Scott Rose" To: References: <20030331111954.01add0a0.olaf@ripe.net> <20030331100546.GB30673@atoom.net> Subject: Re: DNSSEC protocol doc question: pre-conf keys. Date: Mon, 31 Mar 2003 08:09:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-22.6 required=5.0 tests=BAYES_01,ORIGINAL_MESSAGE,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit As for the contradiction in sections 2 and 5: I would say it "SHOULD" since it won't really break DNS to not have the "secure entry point" key (either a zone or key-signing key) offline. It would be impossible to verify unless the key was pre-configured, but unless local policy is "only accept verified RR sets", things will still work, just not verify. I could see where a zone would want to have the secure entry point offline. The root zone could publish the key somewhere else, to reduce response sizes, for example. Otherwise, it seems a bit self-defeating. Is there a reason for stating that a zone MUST have its secure entry point key in the served zone? Scott ----- Original Message ----- From: "Miek Gieben" To: "Olaf M. Kolkman" Cc: Sent: Monday, March 31, 2003 5:05 AM Subject: Re: DNSSEC protocol doc question: pre-conf keys. > [On 31 Mar, @11:19, Olaf wrote in "DNSSEC protocol doc question: ..."] > > > > > > I am going through the DNSSEC protocol modifications document (version > > 01) to get an answer to the following question: > > > > > > Is it legal to have a pre-configured key (trusted-key in bind) that > > is not included in the apex KEY RR set but that is used to create a > > signature over that KEY RR set? > > > > > > I've carefully read section 2 and section 4 of the document. But may > > have been looking at the wrong place for the answer. > > In section 5 it says: > > An initial KEY RR can be used to authenticate a zone's apex KEY > RRset. To authenticate an apex KEY RRset using an initial key, the > resolver MUST: > > 1. Verify that the initial KEY RR appears in the apex KEY RRset, and > verify that the KEY RR has the Zone Key Flag (KEY RDATA bit 7) > set to one. > > 2. Verify that there is some SIG RR which covers the apex KEY RRset, > and that the combination of the SIG RR and the initial KEY RR > authenticates the KEY RRset. The process for using a SIG RR to > authenticate an RRset is described in Section 5.2. > > > Anyhow, the situation seems to be allowed by the following sentence in > > section 2: > > > > "For each private key used to create SIG RRs, there SHOULD be a > > corresponding KEY RR stored at the zone apex" > > > > Given the SHOULD, a resolver should be able with the case of a > > KSK which signes ZSKs in the apex Key RR set and that is exclusively > > configured in the resolvers configuration and does not live in the > > apex Key RR set. > > in section 5 it is a MUST, so this seems a contradiction to me.... > > Besides this, I also think that step 1. for the resolver is not necessary. > If there is a sig that matches, shouldn't that be enough? > > > grtz Miek > > -- > :wq! > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 31 08:40:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06065 for ; Mon, 31 Mar 2003 08:40:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18zzRh-00086b-00 for namedroppers-data@psg.com; Mon, 31 Mar 2003 05:35:29 -0800 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 18zzRe-00086L-00 for namedroppers@ops.ietf.org; Mon, 31 Mar 2003 05:35:27 -0800 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.3/8.12.3/Debian-5) with ESMTP id h2VDZLit003181 for ; Mon, 31 Mar 2003 15:35:21 +0200 Received: (from miekg@localhost) by elektron.atoom.net (8.12.3/8.12.3/Debian-5) id h2VDZLk1003180 for namedroppers@ops.ietf.org; Mon, 31 Mar 2003 15:35:21 +0200 Date: Mon, 31 Mar 2003 15:35:21 +0200 From: Miek Gieben To: namedroppers Subject: secure entry point Message-ID: <20030331133521.GA3042@atoom.net> Mail-Followup-To: namedroppers Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01,USER_AGENT version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk How is a secure entry point defined? From the dnssec drafts I gather that a secure entry point is defined by a key signing key. But should we not also include the nameserver IP address(es) for the secure entry point? grtz Miek -- :wq! -- to unsubscribe send a message to namedroppers-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 31 08:56:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06605 for ; Mon, 31 Mar 2003 08:56:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18zzhW-00091q-00 for namedroppers-data@psg.com; Mon, 31 Mar 2003 05:51:50 -0800 Received: from zydeco.netbusters.com ([66.92.86.178]) by psg.com with esmtp (Exim 3.36 #1) id 18zzhU-00091e-00 for namedroppers@ops.ietf.org; Mon, 31 Mar 2003 05:51:49 -0800 Received: by zydeco.netbusters.com (Postfix, from userid 513) id 21FCCB63B2; Mon, 31 Mar 2003 13:51:46 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by zydeco.netbusters.com (Postfix) with ESMTP id 20CFC7EC1A for ; Mon, 31 Mar 2003 08:51:46 -0500 (EST) Date: Mon, 31 Mar 2003 08:51:46 -0500 (EST) From: Donald Eastlake 3rd X-X-Sender: dee3@zydeco.netbusters.com To: namedroppers Subject: Re: secure entry point In-Reply-To: <20030331133521.GA3042@atoom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk If you trust a public key to sign DNS data and can verify the signature over that data, it doesn't make any difference where you got the data from. There is no reason to worry about the IP address of the nameserver. Thanks, Donald ====================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 155 Beaver Street +1-508-634-2066(h) +1-508-851-8280(w) Milford, MA 01757 USA Donald.Eastlake@motorola.com On Mon, 31 Mar 2003, Miek Gieben wrote: > Date: Mon, 31 Mar 2003 15:35:21 +0200 > From: Miek Gieben > To: namedroppers > Subject: secure entry point > > How is a secure entry point defined? From the dnssec drafts I gather that a > secure entry point is defined by a key signing key. But should we not also > include the nameserver IP address(es) for the secure entry point? > > grtz Miek > > > -- > :wq! > -- to unsubscribe send a message to namedroppers-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 31 09:33:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07528 for ; Mon, 31 Mar 2003 09:33:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19009e-000AMU-00 for namedroppers-data@psg.com; Mon, 31 Mar 2003 06:20:54 -0800 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 19009c-000AMI-00 for namedroppers@ops.ietf.org; Mon, 31 Mar 2003 06:20:52 -0800 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.3/8.12.3/Debian-5) with ESMTP id h2VEKjit004526 for ; Mon, 31 Mar 2003 16:20:47 +0200 Received: (from miekg@localhost) by elektron.atoom.net (8.12.3/8.12.3/Debian-5) id h2VEKicw004525 for namedroppers@ops.ietf.org; Mon, 31 Mar 2003 16:20:44 +0200 Date: Mon, 31 Mar 2003 16:20:44 +0200 From: Miek Gieben To: namedroppers Subject: Re: secure entry point Message-ID: <20030331142044.GC3689@atoom.net> Mail-Followup-To: namedroppers References: <20030331133521.GA3042@atoom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-25.2 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 31 Mar, @15:51, Donald wrote in "Re: secure entry point ..."] > If you trust a public key to sign DNS data and can verify the signature > over that data, it doesn't make any difference where you got the data > from. There is no reason to worry about the IP address of the > nameserver. But this opens up a huge dos attack (this has nothing to do with "dnssec does help against doc attacks"). You will only have to spoof the IP address of a secure entry point and you're done. The resolver will notice that the signatures do not match and will declare the thing BAD. This can easily be prevented by also configuring secure entry point ip adresses. (you already have to configure the secure entry point keys anyway, so this adds little more work) grtz Miek -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 31 09:35:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07621 for ; Mon, 31 Mar 2003 09:35:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1900HO-000Ajc-00 for namedroppers-data@psg.com; Mon, 31 Mar 2003 06:28:54 -0800 Received: from pushme.nist.gov ([129.6.16.92] helo=postmark.nist.gov) by psg.com with esmtp (Exim 3.36 #1) id 1900HM-000AjP-00 for namedroppers@ops.ietf.org; Mon, 31 Mar 2003 06:28:53 -0800 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h2VESYCZ004071; Mon, 31 Mar 2003 09:28:34 -0500 (EST) Message-ID: <009501c2f791$d0e3e4f0$b9370681@barnacle> From: "Scott Rose" To: "Miek Gieben" , "namedroppers" References: <20030331133521.GA3042@atoom.net> Subject: Re: secure entry point Date: Mon, 31 Mar 2003 09:28:36 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-21.8 required=5.0 tests=BAYES_10,ORIGINAL_MESSAGE,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I've always taking "secure entry point" to basically mean a "pre-configured key" It could be any trusted key that can be used to start a chain of authentication. It doesn't technically have to be a key signing key, but could be a zone key, or even a hash of a key, like in a DS RR. My take anyway, Scott ----- Original Message ----- From: "Miek Gieben" To: "namedroppers" Sent: Monday, March 31, 2003 8:35 AM Subject: secure entry point > How is a secure entry point defined? From the dnssec drafts I gather that a > secure entry point is defined by a key signing key. But should we not also > include the nameserver IP address(es) for the secure entry point? > > grtz Miek > > > -- > :wq! > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 31 09:49:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07948 for ; Mon, 31 Mar 2003 09:49:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1900Qy-000BJj-00 for namedroppers-data@psg.com; Mon, 31 Mar 2003 06:38:48 -0800 Received: from [2001:4f8:3:bb:2e0:81ff:fe10:67ab] (helo=as.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 1900Qx-000BJD-00 for namedroppers@ops.ietf.org; Mon, 31 Mar 2003 06:38:47 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 1DEED379E40 for ; Mon, 31 Mar 2003 14:38:34 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: DNSSEC protocol doc question: pre-conf keys. In-Reply-To: Message from "Scott Rose" of "Mon, 31 Mar 2003 08:09:45 EST." <005a01c2f786$cd4625c0$b9370681@barnacle> X-Mailer: MH-E 7.2; nmh 1.0.4; GNU Emacs 21.2.1 Date: Mon, 31 Mar 2003 14:38:34 +0000 Message-Id: <20030331143834.1DEED379E40@as.vix.com> X-Spam-Status: No, hits=-13.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I could see where a zone would want to have the secure entry point offline. > The root zone could publish the key somewhere else, to reduce response > sizes, for example. Otherwise, it seems a bit self-defeating. agreed. > Is there a reason for stating that a zone MUST have its secure entry point > key in the served zone? not in my view. this appears to be an overspecification. -- to unsubscribe send a message to namedroppers-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 31 10:47:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11971 for ; Mon, 31 Mar 2003 10:47:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1901NI-000EcN-00 for namedroppers-data@psg.com; Mon, 31 Mar 2003 07:39:04 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #1) id 1901NF-000EcB-00 for namedroppers@ops.ietf.org; Mon, 31 Mar 2003 07:39:02 -0800 Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.9/8.11.6) with SMTP id h2VFcwRp014131; Mon, 31 Mar 2003 17:38:58 +0200 Date: Mon, 31 Mar 2003 17:38:58 +0200 From: "Olaf M. Kolkman" To: "Scott Rose" Cc: Subject: Re: DNSSEC protocol doc question: pre-conf keys. Message-Id: <20030331173858.4ac2d987.olaf@ripe.net> In-Reply-To: <005a01c2f786$cd4625c0$b9370681@barnacle> References: <20030331111954.01add0a0.olaf@ripe.net> <20030331100546.GB30673@atoom.net> <005a01c2f786$cd4625c0$b9370681@barnacle> Organization: RIPE NCC X-Mailer: Sylpheed version 0.8.11claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-26.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I could see where a zone would want to have the secure entry point > offline. The root zone could publish the key somewhere else, to reduce > response sizes, for example. That is why I looked at this in the first place. I have argued for the fact that verifiers 'MUST' fail if they fail to find a self signature over the trusted key. The reason for this is to be able to signal that 'somethings is wrong'. However, I start to believe that from a crypto/security point of view that argument is nonsense. I thus agree with having the 'MUST' removed. --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 31 10:50:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12063 for ; Mon, 31 Mar 2003 10:50:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1901SP-000ErM-00 for namedroppers-data@psg.com; Mon, 31 Mar 2003 07:44:21 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #1) id 1901SL-000Er7-00 for namedroppers@ops.ietf.org; Mon, 31 Mar 2003 07:44:17 -0800 Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.9/8.11.6) with SMTP id h2VFiCRp015263; Mon, 31 Mar 2003 17:44:12 +0200 Date: Mon, 31 Mar 2003 17:44:12 +0200 From: "Olaf M. Kolkman" To: "Scott Rose" Cc: "Miek Gieben" , "namedroppers" Subject: Re: secure entry point Message-Id: <20030331174412.2b735744.olaf@ripe.net> In-Reply-To: <009501c2f791$d0e3e4f0$b9370681@barnacle> References: <20030331133521.GA3042@atoom.net> <009501c2f791$d0e3e4f0$b9370681@barnacle> Organization: RIPE NCC X-Mailer: Sylpheed version 0.8.11claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-26.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > could be a zone key, or even a hash of a key, like in a DS RR. > But we just established (in another thread) that it is not required to have the 'secure entry point key' in the apex key set and directly use the configured public key to verify signatures of the KSKs in the apex keyset. Thereby reducing the size of the root KEY RRs and having more space for ZSKs. Or am I confused again :-) --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 31 17:32:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28911 for ; Mon, 31 Mar 2003 17:32:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1907ao-000EpS-00 for namedroppers-data@psg.com; Mon, 31 Mar 2003 14:17:26 -0800 Received: from ops.arin.net ([192.149.252.141]) by psg.com with esmtp (Exim 3.36 #1) id 1907al-000Eol-00 for namedroppers@ops.ietf.org; Mon, 31 Mar 2003 14:17:23 -0800 Received: from [192.149.252.108] ([192.136.136.89]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id RAA16875; Mon, 31 Mar 2003 17:17:16 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@ops Message-Id: In-Reply-To: <20030331133521.GA3042@atoom.net> References: <20030331133521.GA3042@atoom.net> Date: Mon, 31 Mar 2003 17:16:34 -0500 To: Miek Gieben From: Edward Lewis Subject: Re: secure entry point Cc: namedroppers Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-29.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk That's how I defined it in the 1998 secure resolver, using a file called "/etc/sresolv.conf" as a replacement for /etc/resolv.conf. It worked well. 'Course, SEP as referred to in the KSK-flag draft doesn't necessarily need to use the same definition. One reason I stored the IP addresses was to be able to use dnssec in a disconnected environment. 'Course, there are many ways to do that, I was just experimenting with some running code just for the experience. (Ahh, those were the days.) At 15:35 +0200 3/31/03, Miek Gieben wrote: >How is a secure entry point defined? From the dnssec drafts I gather that a >secure entry point is defined by a key signing key. But should we not also >include the nameserver IP address(es) for the secure entry point? > >grtz Miek > > >-- >:wq! > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer I've had it with world domination. The maintenance fees are too high. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: