From owner-namedroppers@ops.ietf.org Fri Aug 1 03:35: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 DAA01660 for ; Fri, 1 Aug 2003 03:35:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19iUL5-0008k7-87 for namedroppers-data@psg.com; Fri, 01 Aug 2003 07:28:35 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.20) id 19iUL3-0008jv-6s for namedroppers@ops.ietf.org; Fri, 01 Aug 2003 07:28:33 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h716xxs23568 for ; Thu, 31 Jul 2003 23:59:59 -0700 Date: Thu, 31 Jul 2003 23:59:59 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Request for DNSEXT WG last call on draft-ietf-dnsext-mdns-22.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-8.8 required=5.0 tests=BAYES_20,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The LLMNR I-D, draft-ietf-dnsext-mdns-22.txt currently has no open issues. In order to complete DNSEXT WG review, I would like to request that the document be brought to DNSEXT WG last call. For a listing of previously proposed and resolved issues, see the LLMNR Issues web page, 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 Fri Aug 1 11:31: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 LAA26641 for ; Fri, 1 Aug 2003 11:31:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19ibl3-000NN1-7u for namedroppers-data@psg.com; Fri, 01 Aug 2003 15:23:53 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.20) id 19ibl0-000NMp-Dh for namedroppers@ops.ietf.org; Fri, 01 Aug 2003 15:23:50 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26386; Fri, 1 Aug 2003 11:23:46 -0400 (EDT) Message-Id: <200308011523.LAA26386@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-rfc2536bis-dsa-03.txt Date: Fri, 01 Aug 2003 11:23:46 -0400 X-Spam-Status: No, hits=-3.5 required=5.0 tests=BAYES_01,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-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 : DSA Keying and Signature Information in the DNS Author(s) : D. Eastlake Filename : draft-ietf-dnsext-rfc2536bis-dsa-03.txt Pages : 7 Date : 2003-7-31 A standard method of encoding US Government Digital Signature Algorithm keying and signature information is described for use in the Domain Name System. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2536bis-dsa-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-rfc2536bis-dsa-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-rfc2536bis-dsa-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-8-1114208.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-rfc2536bis-dsa-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-rfc2536bis-dsa-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-1114208.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 Aug 1 15:18: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 PAA06193 for ; Fri, 1 Aug 2003 15:18:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19ifJV-0007wu-Ru for namedroppers-data@psg.com; Fri, 01 Aug 2003 19:11:41 +0000 Received: from [216.168.239.87] (helo=chinook.rgy.netsol.com) by psg.com with esmtp (Exim 4.20) id 19ifJT-0007wX-AR for namedroppers@ops.ietf.org; Fri, 01 Aug 2003 19:11:39 +0000 Received: by chinook.rgy.netsol.com (Postfix, from userid 500) id 9B09B9BE21; Fri, 1 Aug 2003 15:11:38 -0400 (EDT) Date: Fri, 1 Aug 2003 15:11:38 -0400 From: Matt Larson To: Namedroppers Mailing List Subject: DNSSECbis Q-13: Implementation advice regarding caching in security-aware resolvers Message-ID: <20030801191138.GR6603@chinook.rgy.netsol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i X-Spam-Status: No, hits=-10.9 required=5.0 tests=BAYES_10,OPT_IN,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This question corresponds to editor's note #12 from draft-ietf-dnsext-dnssec-protocol-01. Q-13: Should the implementation advice regarding caching in security-aware resolvers remain in the document? Background: Here is the text in question from Section 4 (pages 22-23) of draft-ietf-dnsext-dnssec-protocol-01: A security-aware resolver SHOULD cache each response as a single atomic entry, indexed by the triple , with the single atomic entry containing the entire answer, including the named RRset and any associated DNSSEC RRs. The resolver SHOULD discard the entire atomic entry when any of the RRs contained in it expire. Editors' note: This is implementation advice which came out of discussions at various workshops and investigations into possible implementation issues with the (as yet unsettled) opt-in proposal. All of this advice has been discussed in WG meetings, and as far as the editors know these recommendations are not controversial, but it is up to the WG to decide whether this sort of implementation advice belongs in this document. Please indicate whether you think this implementation advice should remain in the document or not. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Aug 1 15:29: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 PAA07095 for ; Fri, 1 Aug 2003 15:29:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19ifWF-0008WT-2X for namedroppers-data@psg.com; Fri, 01 Aug 2003 19:24:51 +0000 Received: from [216.168.239.87] (helo=chinook.rgy.netsol.com) by psg.com with esmtp (Exim 4.20) id 19ifWC-0008WG-So for namedroppers@ops.ietf.org; Fri, 01 Aug 2003 19:24:48 +0000 Received: by chinook.rgy.netsol.com (Postfix, from userid 500) id 534639BE21; Fri, 1 Aug 2003 15:24:48 -0400 (EDT) Date: Fri, 1 Aug 2003 15:24:47 -0400 From: Matt Larson To: Namedroppers Mailing List Subject: DNSSECbis Q-14: Security-aware recursive name server and response synthesis: SHOULD NOT or MUST NOT Message-ID: <20030801192447.GS6603@chinook.rgy.netsol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i X-Spam-Status: No, hits=-12.9 required=5.0 tests=BAYES_01,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This question corresponds to editor's note #13 from draft-ietf-dnsext-dnssec-protocol-01. Q-14: Under certain circumstances, a security-aware recursive name servers could conceivably synthesize a response to one request using security data in its cache from a different, previous request. This behavior is currently discouraged with SHOULD NOTs, but should it be prohibited with MUST NOTs instead? Background: Here is the text in question from Section 4.1 (page 23) of draft-ietf-dnsext-dnssec-protocol-01: A security-aware recursive name server SHOULD NOT attempt to answer a query by piecing together cached data it received in response to previous queries that requested different QNAMEs, QTYPEs, or QCLASSes. A security-aware recursive name server SHOULD NOT use NXT RRs from one negative response to synthesize a response for a different query. A security-aware recursive name server SHOULD NOT use a previous wildcard expansion to generate a response to a different query. Editors' note: Should any of the SHOULD NOTs in this paragraph be MUST NOTs instead? -- to unsubscribe send a message to namedroppers-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 Aug 1 15:30: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 PAA07132 for ; Fri, 1 Aug 2003 15:30:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19ifZ6-0008h3-8b for namedroppers-data@psg.com; Fri, 01 Aug 2003 19:27:48 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.20) id 19ifZ3-0008gl-Cw for namedroppers@ops.ietf.org; Fri, 01 Aug 2003 19:27:45 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06528; Fri, 1 Aug 2003 15:27:41 -0400 (EDT) Message-Id: <200308011927.PAA06528@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-rfc2539bis-dhk-03.txt Date: Fri, 01 Aug 2003 15:27:41 -0400 X-Spam-Status: No, hits=-3.5 required=5.0 tests=BAYES_01,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-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 : Storage of Diffie-Hellman Keys in the Domain Name System (DNS) Author(s) : D. Eastlake Filename : draft-ietf-dnsext-rfc2539bis-dhk-03.txt Pages : 9 Date : 2003-8-1 A standard method for storing Diffie-Hellman keys in the Domain Name System is described which utilizes DNS KEY resource records. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2539bis-dhk-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-rfc2539bis-dhk-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-rfc2539bis-dhk-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-8-1153451.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-rfc2539bis-dhk-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-rfc2539bis-dhk-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-1153451.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 Aug 1 15:38: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 PAA07867 for ; Fri, 1 Aug 2003 15:38:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19ifgZ-0009EH-Jd for namedroppers-data@psg.com; Fri, 01 Aug 2003 19:35:31 +0000 Received: from [216.168.239.87] (helo=chinook.rgy.netsol.com) by psg.com with esmtp (Exim 4.20) id 19ifgX-0009E3-GN for namedroppers@ops.ietf.org; Fri, 01 Aug 2003 19:35:29 +0000 Received: by chinook.rgy.netsol.com (Postfix, from userid 500) id DCE1F9BE21; Fri, 1 Aug 2003 15:35:28 -0400 (EDT) Date: Fri, 1 Aug 2003 15:35:28 -0400 From: Matt Larson To: Namedroppers Mailing List Subject: DNSSECbis Q-15: Security-aware stub resolver setting the CD bit: SHOULD NOT or MUST NOT? Message-ID: <20030801193528.GU6603@chinook.rgy.netsol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i X-Spam-Status: No, hits=-12.1 required=5.0 tests=BAYES_10,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This question corresponds to editor's note #14 from draft-ietf-dnsext-dnssec-protocol-01. Q-15: Should a security-aware stub resolver be allowed to set the CD bit on queries or should this behavior be prohibited? Background: Here is the text in question from Section 4.2 (page 24) of draft-ietf-dnsext-dnssec-protocol-01: A security-aware stub resolver SHOULD NOT set the CD bit when sending queries, since, by definition, a security-aware stub resolver does not validate signatures and thus depends on the security-aware recursive name server to perform validation on its behalf. Editors' note: Should this SHOULD NOT be a MUST NOT? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Aug 1 17: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 RAA13485 for ; Fri, 1 Aug 2003 17:42:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19ihYA-000ErX-Pa for namedroppers-data@psg.com; Fri, 01 Aug 2003 21:34:58 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.20) id 19ihY8-000ErK-8Y for namedroppers@ops.ietf.org; Fri, 01 Aug 2003 21:34:56 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id h71LY6ln018378 for ; Fri, 1 Aug 2003 17:34:06 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAASyai5J; Fri, 1 Aug 03 17:34:06 -0400 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id h71LXVwx029143; Fri, 1 Aug 2003 17:33:31 -0400 (EDT) Date: Fri, 1 Aug 2003 17:33:31 -0400 (EDT) From: Sam Weiler X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org cc: "Steven M. Bellovin" Subject: TCR registry text In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-18.5 required=5.0 tests=BAYES_20,IN_REP_TO,REFERENCES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In Vienna, it was decided to create separate security algorithm registries for the new type codes (DNSKEY, RRSIG) and for new application key RR's (ie. IPSECKEY). Here's the text I plan to add to the draft. Note that it drops all mention of type 1 (RSA/MD5, deprecated for this purpose), type 4 (previously "reserved" for ECC), and indirect. Comments would be appreciated. The current registry is at: http://www.iana.org/assignments/dns-sec-alg In order to allow DNS Security and SIG(0) to use different sets of algorithms, the existing "DNS Security Algorithm Numbers" registry is renamed as the "SIG(0) Algorithm Numbers" registry and a new "DNS Security Algorithm Numbers" registry is established. The initial algorithm values are: 2 Diffie-Hellman [RFC2539] 3 DSA/SHA1 [RFC2536] 5 RSA/SHA-1 [RFC3110] 253 Private algorithms - domain name [RFC2535] 254 Private algorithms - OID [RFC2535] Values 0, 1, and 255 are reserved. Values 4 and 6 through 252 are available for assignment by IETF Standards Action. It is suggested, but not required, that new algorithms usable by both DNS Security and SIG(0) be assigned the same number in both registries. -- 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 Fri Aug 1 17:56: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 RAA13763 for ; Fri, 1 Aug 2003 17:56:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19iho8-000FqC-CZ for namedroppers-data@psg.com; Fri, 01 Aug 2003 21:51:28 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.20) id 19iho6-000Fpu-21 for namedroppers@ops.ietf.org; Fri, 01 Aug 2003 21:51:26 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id h71LoaE0018801 for ; Fri, 1 Aug 2003 17:50:36 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAvdaaUK; Fri, 1 Aug 03 17:50:36 -0400 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id h71Lo4Th029419; Fri, 1 Aug 2003 17:50:04 -0400 (EDT) Date: Fri, 1 Aug 2003 17:50:03 -0400 (EDT) From: Sam Weiler X-X-Sender: weiler@filbert To: Matt Larson cc: Namedroppers Mailing List Subject: Re: DNSSECbis Q-15: Security-aware stub resolver setting the CD bit: SHOULD NOT or MUST NOT? In-Reply-To: <20030801193528.GU6603@chinook.rgy.netsol.com> Message-ID: References: <20030801193528.GU6603@chinook.rgy.netsol.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Q-15: Should a security-aware stub resolver be allowed to set the CD > bit on queries or should this behavior be prohibited? It hinges on the "security-aware" definition, but, generally, it should be allowed. In particular, a user may wish to bypass DNSSEC checking (by active decision or policy), and clients should be written to allow for that. > Editors' note: Should this SHOULD NOT be a MUST NOT? No. -- 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 Fri Aug 1 18:47: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 SAA16196 for ; Fri, 1 Aug 2003 18:47:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19iic3-000IjQ-R6 for namedroppers-data@psg.com; Fri, 01 Aug 2003 22:43:03 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.20) id 19iic1-000IjE-Gw for namedroppers@ops.ietf.org; Fri, 01 Aug 2003 22:43:01 +0000 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id DD4EC191C for ; Fri, 1 Aug 2003 18:42:30 -0400 (EDT) Date: Fri, 01 Aug 2003 18:42:30 -0400 From: Rob Austein To: Namedroppers Mailing List Subject: Re: DNSSECbis Q-15: Security-aware stub resolver setting the CD bit: SHOULD NOT or MUST NOT? In-Reply-To: <20030801193528.GU6603@chinook.rgy.netsol.com> References: <20030801193528.GU6603@chinook.rgy.netsol.com> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030801224230.DD4EC191C@thrintun.hactrn.net> X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Fri, 1 Aug 2003 15:35:28 -0400, Matt Larson wrote: > > This question corresponds to editor's note #14 from > draft-ietf-dnsext-dnssec-protocol-01. > > Q-15: Should a security-aware stub resolver be allowed to set the CD > bit on queries or should this behavior be prohibited? > > Background: Here is the text in question from Section 4.2 (page 24) of > draft-ietf-dnsext-dnssec-protocol-01: > > A security-aware stub resolver SHOULD NOT set the CD bit when sending > queries, since, by definition, a security-aware stub resolver does > not validate signatures and thus depends on the security-aware > recursive name server to perform validation on its behalf. > > Editors' note: Should this SHOULD NOT be a MUST NOT? Note: "security-aware stub resolver" has a precise definition, see draft-ietf-dnsext-dnssec-intro. One could reasonably challenge that definition, but leave that until the next paragraph: the point here is that this Editors' note was phrased in the context of that definition. As far as the definition itself goes: this is by far the biggest stretch away from classical DNS terminology in the terminology we're using in the current DNSSECbis docs. The problem that this was trying to express is that some people see a big difference between two different kinds of recursive-mode-only resolvers, and see phrases like "a stub resolver that validates signatures" or "a stub resolver that includes a cache" as oxymorons. The basic model that these folks have seems to be that a stub resolver, by definition, is dumber than a turnip. Personally, I don't really care whether "stub" implies "dumber than a turnip" or not, "dumber than a turnip" does seem to imply "too dumb to verify signatures". So, since the existance of mechanisms like the AD bit suggested that we needed a term for recursive-mode-only resolvers that don't validate signatures, I hit upon the phrase "security-aware stub resolver" as a least-bad fit. Whether this definition is useful is for the WG to decide, but, if it's not useful, please suggest an unambiguous alternative. -- to unsubscribe send a message to namedroppers-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 Aug 4 09:46:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA25741 for ; Mon, 4 Aug 2003 09:46:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19jfXN-000Cu6-Ul for namedroppers-data@psg.com; Mon, 04 Aug 2003 13:38:09 +0000 Received: from [129.6.16.93] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.20) id 19jfX6-000Csc-Kw for namedroppers@ops.ietf.org; Mon, 04 Aug 2003 13:37:52 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h74DbfaH000230 for ; Mon, 4 Aug 2003 09:37:41 -0400 (EDT) Message-ID: <00d501c35a8d$95ce26f0$b9370681@barnacle> From: "Scott Rose" To: "Namedroppers Mailing List" References: <20030801193528.GU6603@chinook.rgy.netsol.com> <20030801224230.DD4EC191C@thrintun.hactrn.net> Subject: Re: DNSSECbis Q-15: Security-aware stub resolver setting the CD bit: SHOULD NOT or MUST NOT? Date: Mon, 4 Aug 2003 09:37:43 -0400 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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-11.3 required=5.0 tests=BAYES_30,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I support the spec stating that a stub resolver must be allowed to set the CD bit in a query if it so chooses. There is no "rule" saying a security aware stub resolver (secstub resolver?) can't have a full validator as well. It seems a matter of local policy for the client. Scott ----- Original Message ----- From: "Rob Austein" To: "Namedroppers Mailing List" Sent: Friday, August 01, 2003 6:42 PM Subject: Re: DNSSECbis Q-15: Security-aware stub resolver setting the CD bit: SHOULD NOT or MUST NOT? > At Fri, 1 Aug 2003 15:35:28 -0400, Matt Larson wrote: > > > > This question corresponds to editor's note #14 from > > draft-ietf-dnsext-dnssec-protocol-01. > > > > Q-15: Should a security-aware stub resolver be allowed to set the CD > > bit on queries or should this behavior be prohibited? > > > > Background: Here is the text in question from Section 4.2 (page 24) of > > draft-ietf-dnsext-dnssec-protocol-01: > > > > A security-aware stub resolver SHOULD NOT set the CD bit when sending > > queries, since, by definition, a security-aware stub resolver does > > not validate signatures and thus depends on the security-aware > > recursive name server to perform validation on its behalf. > > > > Editors' note: Should this SHOULD NOT be a MUST NOT? > > Note: "security-aware stub resolver" has a precise definition, see > draft-ietf-dnsext-dnssec-intro. One could reasonably challenge that > definition, but leave that until the next paragraph: the point here is > that this Editors' note was phrased in the context of that definition. > > As far as the definition itself goes: this is by far the biggest > stretch away from classical DNS terminology in the terminology we're > using in the current DNSSECbis docs. The problem that this was trying > to express is that some people see a big difference between two > different kinds of recursive-mode-only resolvers, and see phrases like > "a stub resolver that validates signatures" or "a stub resolver that > includes a cache" as oxymorons. The basic model that these folks have > seems to be that a stub resolver, by definition, is dumber than a > turnip. Personally, I don't really care whether "stub" implies > "dumber than a turnip" or not, "dumber than a turnip" does seem to > imply "too dumb to verify signatures". So, since the existance of > mechanisms like the AD bit suggested that we needed a term for > recursive-mode-only resolvers that don't validate signatures, I hit > upon the phrase "security-aware stub resolver" as a least-bad fit. > > Whether this definition is useful is for the WG to decide, but, if > it's not useful, please suggest an unambiguous alternative. > > -- > to 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 Aug 4 10:29:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29258 for ; Mon, 4 Aug 2003 10:29:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19jgGx-000FTF-8a for namedroppers-data@psg.com; Mon, 04 Aug 2003 14:25:15 +0000 Received: from [209.116.252.130] (helo=one.elistx.com) by psg.com with esmtp (Exim 4.20) id 19jgGt-000FT3-41 for namedroppers@ops.ietf.org; Mon, 04 Aug 2003 14:25:11 +0000 Received: from ogud.com (pcp04400154pcs.nrockv01.md.comcast.net [69.140.166.204]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HJ300G20MSGJZ@eListX.com> for namedroppers@ops.ietf.org; Mon, 04 Aug 2003 10:26:40 -0400 (EDT) Received: from ENGILL.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.8p1/8.12.8) with ESMTP id h74EPZhJ019789 for ; Mon, 04 Aug 2003 10:25:36 -0400 (EDT envelope-from ogud@ogud.com) Date: Mon, 04 Aug 2003 10:23:41 -0400 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: DNSEXT WGLC for LLMNR X-Sender: (Unverified) To: namedroppers@ops.ietf.org Message-id: <5.1.1.6.2.20030804100523.0161cfe0@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=BAYES_20 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a last call for the DNSEXT document Linklocal Multicast Name Resolution (LLMNR) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-22.txt This document defines a new protocol that operates on a local link where there to enable name resolution. This protocol inherits DNS wire formats but operates on a different port and different transport. This protocol has been thorough many changes in the last 6 months to make it cleaner, simpler and to avoid it becoming a possible DoS amplifier. For a listing of previously proposed and resolved issues, see the LLMNR Issues web page, available at: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html Please read the document, send in statements of support/opposition/clarifications/etc. This protocol is on standards track, if you disagree with that please speak up. If there is no discussion about this document the default action by chairs is to advance it as that seems to be the recommendation of the people that have commented on this document over the last one year. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 5 10:25: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 KAA13435 for ; Tue, 5 Aug 2003 10:25:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19k2au-0007r0-Dy for namedroppers-data@psg.com; Tue, 05 Aug 2003 14:15:20 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.20) id 19k2ar-0007ql-PG for namedroppers@ops.ietf.org; Tue, 05 Aug 2003 14:15:17 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12718; Tue, 5 Aug 2003 10:15:13 -0400 (EDT) Message-Id: <200308051415.KAA12718@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-2535typecode-change-04.txt Date: Tue, 05 Aug 2003 10:15:12 -0400 X-Spam-Status: No, hits=0.0 required=5.0 tests=BAYES_20,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-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 : Legacy Resolver Compatibility for Delegation Signer Author(s) : S. Weiler Filename : draft-ietf-dnsext-dnssec-2535typecode-change-04.txt Pages : 5 Date : 2003-8-5 As the DNS Security (DNSSEC) specifications have evolved, the syntax and semantics of the DNSSEC resource records (RRs) have changed. Many deployed nameservers understand variants of these semantics. Dangerous interactions can occur when a resolver that understands an earlier version of these semantics queries an authoritative server that understands the new delegation signer semantics, including at least one failure scenario that will cause an unsecured zone to be unresolvable. This document proposes that these interactions be avoided by changing the type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-2535typecode-change-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-2535typecode-change-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-2535typecode-change-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-5090210.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-2535typecode-change-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-2535typecode-change-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-5090210.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 Aug 6 14:27: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 OAA28316 for ; Wed, 6 Aug 2003 14:27:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19kSqX-000LoX-Hh for namedroppers-data@psg.com; Wed, 06 Aug 2003 18:17:13 +0000 Received: from [129.6.16.93] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.20) id 19kSqC-000LnA-L9 for namedroppers@ops.ietf.org; Wed, 06 Aug 2003 18:16:52 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h76IGS5x002272 for ; Wed, 6 Aug 2003 14:16:28 -0400 (EDT) Message-ID: <004b01c35c46$db311940$b9370681@barnacle> From: "Scott Rose" To: Subject: SIG(0) draft - or - rfc2931bis draft Date: Wed, 6 Aug 2003 14:16:29 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0048_01C35C25.540C6670" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0048_01C35C25.540C6670 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Attached is the first edition of the rfc2931bis draft (SIG(0)). It is an individual submission for now, next version could be a WG document if there is concensus. The changes are the references to RFC2535 and the new typecode rollover stuff. Scott ------=_NextPart_000_0048_01C35C25.540C6670 Content-Type: text/plain; name="draft-srose-rfc2931bis-00.txt" Content-Disposition: attachment; filename="draft-srose-rfc2931bis-00.txt" Content-Transfer-Encoding: quoted-printable =0A= =0A= Network Working Group S. Rose=0A= Internet-Draft NIST=0A= Expires: February 4, 2004 August 6, 2003=0A= =0A= =0A= DNS Request and Transaction Signatures ( SIG(0)s )=0A= draft-srose-rfc2931bis-00=0A= =0A= Status of this Memo=0A= =0A= This document is an Internet-Draft and is in full conformance with=0A= all provisions of Section 10 of RFC2026.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF), its areas, and its working groups. Note that=0A= other groups may also distribute working documents as Internet-=0A= Drafts.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six months=0A= and may be updated, replaced, or obsoleted by other documents at any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as "work in progress."=0A= =0A= The list of current Internet-Drafts can be accessed at http://=0A= www.ietf.org/ietf/1id-abstracts.txt.=0A= =0A= The list of Internet-Draft Shadow Directories can be accessed at=0A= http://www.ietf.org/shadow.html.=0A= =0A= This Internet-Draft will expire on February 4, 2004.=0A= =0A= Copyright Notice=0A= =0A= Copyright (C) The Internet Society (2003). All Rights Reserved.=0A= =0A= Abstract=0A= =0A= Extensions to the Domain Name System (DNS) can provide data origin=0A= and transaction integrity and authentication to security aware=0A= resolvers and applications through the use of cryptographic digital=0A= signatures. However, these security extensions do not provide=0A= authentication at the transaction or message level. This document=0A= describes a message authentication scheme (called SIG(0)) that=0A= provides message level authentication and integrity checking by means=0A= of a meta-RR in the additional section of a DNS message.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Rose Expires February 4, 2004 [Page 1]=0A= =0C=0A= Internet-Draft rfc2931bis August 2003=0A= =0A= =0A= Table of Contents=0A= =0A= 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 2. SIG(0) Design Rationale . . . . . . . . . . . . . . . . . . . 4=0A= 2.1 Message Authentication . . . . . . . . . . . . . . . . . . . . 4=0A= 2.2 Request Authentication . . . . . . . . . . . . . . . . . . . . 4=0A= 2.3 Keying . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4=0A= 3. Differences Between TSIG and SIG(0) . . . . . . . . . . . . . 6=0A= 4. The SIG(0) Resource Record . . . . . . . . . . . . . . . . . . 7=0A= 4.1 SIG(0) Lifetime and Expiration . . . . . . . . . . . . . . . . 8=0A= 4.2 Calculating Request and Transaction SIG(0)s . . . . . . . . . 8=0A= 4.3 Inclusion of SIG(0) RR in a DNS Message . . . . . . . . . . . 9=0A= 4.4 Processing Responses and SIG(0) RRs . . . . . . . . . . . . . 9=0A= 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10=0A= 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11=0A= 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12=0A= Nornative References . . . . . . . . . . . . . . . . . . . . . 13=0A= Informative References . . . . . . . . . . . . . . . . . . . . 14=0A= Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14=0A= Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Rose Expires February 4, 2004 [Page 2]=0A= =0C=0A= Internet-Draft rfc2931bis August 2003=0A= =0A= =0A= 1. Introduction=0A= =0A= intro=0A= =0A= It is assumed that the reader has some knowledge of the DNSSEC=0A= extensions ([6], [7], and [8]) The key words "MUST", "MUST NOT",=0A= NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"=0A= in this document are to be interpreted as described in RFC 2119 [2].=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Rose Expires February 4, 2004 [Page 3]=0A= =0C=0A= Internet-Draft rfc2931bis August 2003=0A= =0A= =0A= 2. SIG(0) Design Rationale=0A= =0A= SIG(0) provides protection for DNS transactions and requests that is=0A= not provided by the regular RRSIG, DNSKEY, and NSEC RRs specified in=0A= [7]. These services do not cover glue records, DNS message headers,=0A= the query section of DNS requests, and do not provide protection of=0A= the overall integrity of a DNS message. The RRSIG RR is used to=0A= authenticate data resource records (RRs) or authenticatably deny=0A= their nonexistence. The SIG(0) RR is a variant of the RRSIG RR that=0A= covers the entire DNS message. This would give the same protection=0A= levels to the DNS message headers and query section as the RRSIG RR=0A= gives to a data RR set.=0A= =0A= 2.1 Message Authentication=0A= =0A= Message authentication means that a requester can be sure it is at=0A= least getting the messages from the server it queried and that the=0A= received messages have not be tampered with in transit. This is=0A= accomplished by optionally adding either a TSIG RR [3] or, a SIG(0)=0A= RR at the end of the message which digitally signs the concatenation=0A= of the server's response and the corresponding resolver query.=0A= =0A= 2.2 Request Authentication=0A= =0A= Queries and update messages can be authenticated by including a TSIG=0A= or a SIG(0) RR at the end of the request. There is little need to=0A= authenticate a traditional DNS query, although it may be desired for=0A= dynamic updates to a zone, or to provide proof of the identity. In=0A= the latter, message authentication may be used as a form of=0A= indentification. The presence of a SIG(0) may allow certain access=0A= based on the capability of providing a SIG(0) signature. Due to the=0A= cost associated with generating a SIG(0) RR, this ability should not=0A= be used for general purpose DNS lookups.=0A= =0A= Requests with a non- empty additional information section produce=0A= error returns or may even be ignored by a few such older DNS servers.=0A= However, this syntax for signing requests is defined to be used for=0A= authenticating dynamic update requests [5], TKEY requests [4], or=0A= possible future requests requiring authentication.=0A= =0A= 2.3 Keying=0A= =0A= The private keys used in transaction authentication belong to the=0A= entitiy composing the DNS message, not to the zone involved. Request=0A= authentication may also involve the private key of the host or other=0A= entity depending on the request authority seeking to be established.=0A= The corresponding public key(s) are normally stored in and retrieved=0A= from the DNS for verification as KEY RRs with a protocol byte of 3=0A= =0A= =0A= =0A= Rose Expires February 4, 2004 [Page 4]=0A= =0C=0A= Internet-Draft rfc2931bis August 2003=0A= =0A= =0A= (DNSSEC).=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Rose Expires February 4, 2004 [Page 5]=0A= =0C=0A= Internet-Draft rfc2931bis August 2003=0A= =0A= =0A= 3. Differences Between TSIG and SIG(0)=0A= =0A= There are significant differences between TSIG and SIG(0).=0A= =0A= Because TSIG involves secret keys installed at both the requester and=0A= server the presence of such a key implies that the other party=0A= understands TSIG and very likely has the same key installed.=0A= Furthermore, TSIG uses keyed hash authentication codes which are=0A= relatively inexpensive to compute. Thus it is common to authenticate=0A= requests with TSIG and responses are authenticated with TSIG if the=0A= corresponding request is authenticated.=0A= =0A= SIG(0) on the other hand, uses public key authentication, where the=0A= public keys are stored in DNS as KEY RRs and a private key is stored=0A= at the signer. Existence of such a KEY RR does not necessarily imply=0A= implementation of SIG(0). In addition, SIG(0) involves relatively=0A= expensive public key cryptographic operations that should be=0A= minimized and the verification of a SIG(0) involves obtaining and=0A= verifying the corresponding KEY which can be an expensive and lengthy=0A= operation. Indeed, a policy of using SIG(0) on all requests and=0A= verifying it before responding would, for some configurations, lead=0A= to a deadly embrace with the attempt to obtain and verify the KEY=0A= needed to authenticate the request SIG(0) resulting in additional=0A= requests accompanied by a SIG(0) leading to further requests=0A= accompanied by a SIG(0), etc. Furthermore, omitting SIG(0)s when not=0A= required on requests halves the number of public key operations=0A= required by the transaction.=0A= =0A= For these reasons, SIG(0)s SHOULD only be used on requests when=0A= necessary to authenticate that the requester has some required=0A= privilege or identity. SIG(0)s on replies are defined in such a way=0A= as to not require a SIG(0) on the corresponding request and still=0A= provide transaction protection. For other replies, whether they are=0A= authenticated by the server or required to be authenticated by the=0A= requester SHOULD be a local configuration option.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Rose Expires February 4, 2004 [Page 6]=0A= =0C=0A= Internet-Draft rfc2931bis August 2003=0A= =0A= =0A= 4. The SIG(0) Resource Record=0A= =0A= Note: requests and responses can either have a single TSIG or one=0A= SIG(0) but not both a TSIG and a SIG(0).=0A= =0A= The structure of the SIG(0) resource records (RRs) is similar to the=0A= RRSIG RR [7] with the following differences outlined below. Any=0A= conflict between the DNSSEC specification and this document=0A= concerning SIG(0) RRs should be resolved in favor of this document.=0A= =0A= The owner's name of a SIG(0) MUST be the root. That is, a single=0A= zero (0) octet. Likewise, the class code MUST be ANY and TTL value=0A= MUST be zero (0).=0A= =0A= The type code for the SIG(0) is 24.=0A= =0A= The RDATA of the SIG(0) is given as:=0A= =0A= 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3=0A= 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=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= | reserved | Algorithm | Labels |=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= | reserved |=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= | Signature Expiration |=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= | Signature Inception |=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= | Key Tag | /=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name /=0A= / /=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= / /=0A= / Signature /=0A= / /=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= =0A= The fixed sized resevered sections MUST be zero (0).=0A= =0A= The Algorithm field is described in Section 6.=0A= =0A= The Labels and Key Tag field are constructed the same way as the=0A= same filds in the RRSIG RR. See [7]. Since the owner name of the=0A= SIG(0) is zero, the labels field MUST also be zero (0).=0A= =0A= For all SIG(0)s, the signer name field MUST be a name of the=0A= originating host and there MUST be a KEY RR at that name with the=0A= =0A= =0A= =0A= Rose Expires February 4, 2004 [Page 7]=0A= =0C=0A= Internet-Draft rfc2931bis August 2003=0A= =0A= =0A= public key corresponding to the private key used to calculate the=0A= signature. (The host domain name used may be the inverse IP=0A= address mapping name for an IP address of the host if the relevant=0A= KEY is stored there.)=0A= =0A= =0A= 4.1 SIG(0) Lifetime and Expiration=0A= =0A= The inception and expiration times in SIG(0)s are for the purpose of=0A= resisting replay attacks. They should be set to form a time bracket=0A= such that messages outside that bracket can be ignored. In IP=0A= networks, this time bracket should not normally extend further than 5=0A= minutes into the past and 5 minutes into the future.=0A= =0A= 4.2 Calculating Request and Transaction SIG(0)s=0A= =0A= A DNS query message signed with a SIG(0) places the RR at the end of=0A= the additional section. The signature is calculated by using a=0A= plaintext (see [7]) of (1) the SIG(0)'s RDATA entirely omitting the=0A= signature section itself (19 bytes), (2) the entire DNS message minus=0A= the UDP/IP header. The additional section RR count in the DNS=0A= message header should NOT include the SIG(0) itself.=0A= =0A= That is:=0A= =0A= plaintext =3D RDATA | DNSquery - SIG(0)=0A= =0A= where "|" is concatenation and RDATA is the RDATA of the SIG(0) being=0A= calculated omitting the signature field itself.=0A= =0A= Similarly, a SIG(0) used to secure a response are calculated by using=0A= a plaintext of (1) the SIG(0) RDATA omitting the signature itself=0A= (again, 19 bytes), (2) the entire DNS query message that produced=0A= this response, but not its UDP/IP header, and (3) the entire DNS=0A= response message, but not the UDP/IP header. Again, like the query=0A= message, the additional section RR counts do not reflect the the=0A= SIG(0) RR itself.=0A= =0A= That is=0A= =0A= plaintext =3D RDATA | full query | response - SIG(0)=0A= =0A= where "|" is concatenation and RDATA is the RDATA of the SIG(0) being=0A= calculated.=0A= =0A= Verification of a response SIG(0) (which is signed by the server host=0A= key, not the zone key) by the requesting resolver shows that the=0A= query and response were not tampered with in transit, that the=0A= =0A= =0A= =0A= Rose Expires February 4, 2004 [Page 8]=0A= =0C=0A= Internet-Draft rfc2931bis August 2003=0A= =0A= =0A= response corresponds to the intended query, and that the original=0A= response comes from the queried server.=0A= =0A= In the case of a DNS message via TCP, a SIG(0) on the first data=0A= packet is calculated with "data" as above and for each subsequent=0A= packet, it is calculated as follows:=0A= =0A= data =3D RDATA | DNS payload - SIG(0) | previous packet=0A= =0A= where "|" is concatenations, RDATA is as above, and previous packet=0A= is the previous DNS payload including DNS header and the SIG(0) but=0A= not the TCP/IP header. Support of SIG(0) for TCP is OPTIONAL. As an=0A= alternative, TSIG may be used after, if necessary, setting up a key=0A= with TKEY [4].=0A= =0A= Except where needed to authenticate an update, TKEY, or similar=0A= privileged request, servers are not required to check for a request=0A= SIG(0).=0A= =0A= 4.3 Inclusion of SIG(0) RR in a DNS Message=0A= =0A= When SIG(0) authentication on a response is desired, that SIG RR MUST=0A= be considered the highest priority of any additional information for=0A= inclusion in the response. If the SIG(0) RR cannot be added without=0A= causing the message to be truncated, the server MUST alter the=0A= response so that a SIG(0) can be included. This response consists of=0A= only the question and a SIG(0) record, and has the TC bit set and=0A= RCODE 0 (NOERROR). The client should retry the request using TCP.=0A= =0A= 4.4 Processing Responses and SIG(0) RRs=0A= =0A= A SIG(0) SHOULD be placed as the last RR in the additional section of=0A= a DNS message. If it is located in any other section, it MUST NOT be=0A= considered valid. For TKEY responses, it MUST be checked and the=0A= message rejected if the checks fail unless otherwise specified for=0A= the TKEY mode in use. For all other responses, it MAY be checked and=0A= the message rejected if the checks fail.=0A= =0A= If a response's SIG(0) check succeed, such a transaction=0A= authentication signature does NOT directly authenticate the validity=0A= any data-RRs in the message. However, it authenticates that they=0A= were sent by the queried server and have not been altered. (Only a=0A= proper SIG(0) RR signed by the zone or a key tracing its authority to=0A= the zone or to static resolver configuration can directly=0A= authenticate data-RRs, depending on resolver policy.) If a resolver=0A= or server does not plan to implement transaction and/or request=0A= SIG(0), it MUST ignore them without error where they are optional and=0A= treat them as failing where they are required.=0A= =0A= =0A= =0A= Rose Expires February 4, 2004 [Page 9]=0A= =0C=0A= Internet-Draft rfc2931bis August 2003=0A= =0A= =0A= 5. Security Considerations=0A= =0A= A more detailed description of the threats against the DNS are given=0A= in [9].=0A= =0A= Because requests and replies are highly variable, message=0A= authentication SIGs can not be pre-calculated. Thus it will be=0A= necessary to keep the private key on-line. This will cause the DNS=0A= entity to rely on the system security for keeping the key secure.=0A= =0A= The inclusion of the SIG(0) inception and expiration time under the=0A= signature improves resistance to replay attacks. The benefit of=0A= using private and public key pairs allows for the distribution of the=0A= public verification key while keeping the private signing key secure.=0A= This is an advantage of SIG(0) message authentication schemes over=0A= the TSIG RR schemes, which use a shared secret that must be=0A= distributed securely.=0A= =0A= SIG(0) signature scheme cannot be used to authenticate source data,=0A= only to authenticate a resolver request and/or a server response.=0A= The DNS security mechanisms described in [7] should be used to=0A= provide coverage of the original source data.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Rose Expires February 4, 2004 [Page 10]=0A= =0C=0A= Internet-Draft rfc2931bis August 2003=0A= =0A= =0A= 6. IANA Considerations=0A= =0A= In order to allow DNS Security and SIG(0) to use different sets of=0A= algorithms, the existing "DNS Security Algorithm Numbers" registry is=0A= renamed as the "SIG(0) Algorithm Numbers" registry and a new "DNS=0A= Security Algorithm Numbers" registry is established. The initial=0A= algorithm values are:=0A= =0A= VALUE Algorithm [mnemonic] RFC=0A= 0 Reserved -=0A= 1 Reserved (Obsolete) RFC 2537=0A= 2 Diffie-Hellman [DH] RFC 2539=0A= 3 DSA [DSA] RFC 2536=0A= 4 available for assignment=0A= 5 RSA/SHA1 [RSA/SHA1] RFC 3110=0A= 6-252 available for assignment -=0A= 253 private [PRIVATE_DNS] -=0A= 254 private [PRIVATE_OID] -=0A= 255 reserved -=0A= =0A= As support for SIG(0) is not mandatory to the DNS protocol, there are=0A= no mandatory to implement algorithms for SIG(0). It is suggested,=0A= but not required, that new algorithms usable by both DNS Security and=0A= SIG(0) be assigned the same number in both registries.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Rose Expires February 4, 2004 [Page 11]=0A= =0C=0A= Internet-Draft rfc2931bis August 2003=0A= =0A= =0A= 7. Acknowledgements=0A= =0A= The author would like to acknowledge the author of the original=0A= SIG(0) draft, Donald Eastlake, as well as the express graditude for=0A= those that helped prod the author into producing this draft.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Rose Expires February 4, 2004 [Page 12]=0A= =0C=0A= Internet-Draft rfc2931bis August 2003=0A= =0A= =0A= Nornative References=0A= =0A= [1] Elz, R. and R. Bush, "Serial Number Arithmatic", RFC 1982,=0A= August 1996.=0A= =0A= [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement=0A= Levels", BCP 14, RFC 2119, March 1997.=0A= =0A= [3] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,=0A= "Secret Key Transaction Authentication for DNS (TSIG)", RFC=0A= 2845, May 2000.=0A= =0A= [4] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC=0A= 2930, September 2000.=0A= =0A= [5] Wellington, B., "Secure Domain Name System (DNS) Dynamic=0A= Update", RFC 3007, November 2000.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Rose Expires February 4, 2004 [Page 13]=0A= =0C=0A= Internet-Draft rfc2931bis August 2003=0A= =0A= =0A= Informative References=0A= =0A= [6] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,=0A= "DNS Security Introduction and Requirements", draft-ietf-dnsext-=0A= dnssec-intro-05 (work in progress), February 2003.=0A= =0A= [7] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,=0A= "Resource Records for DNS Security Extensions", draft-ietf-=0A= dnsext-dnssec-records-04 (work in progress), February 2003.=0A= =0A= [8] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,=0A= "Protocol Modifications for the DNS Security Extensions", draft-=0A= ietf-dnsext-dnssec-protocol-00 (work in progress), Februari=0A= 2003.=0A= =0A= [9] Atkins, D. and R. Austein, "Threat Analysis Of The Domain Name=0A= System", draft-ietf-dnsext-dns-threats-02 (work in progress),=0A= November 2002.=0A= =0A= =0A= Author's Address=0A= =0A= Scott Rose=0A= National Institute for Standards and Technology=0A= 100 Bureau Drive=0A= Gaithersburg, MD 20899-8920=0A= USA=0A= =0A= EMail: scott.rose@nist.gov=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Rose Expires February 4, 2004 [Page 14]=0A= =0C=0A= Internet-Draft rfc2931bis August 2003=0A= =0A= =0A= Full Copyright Statement=0A= =0A= Copyright (C) The Internet Society (2003). All Rights Reserved.=0A= =0A= This document and translations of it may be copied and furnished to=0A= others, and derivative works that comment on or otherwise explain it=0A= or assist in its implementation may be prepared, copied, published=0A= and distributed, in whole or in part, without restriction of any=0A= kind, provided that the above copyright notice and this paragraph are=0A= included on all such copies and derivative works. However, this=0A= document itself may not be modified in any way, such as by removing=0A= the copyright notice or references to the Internet Society or other=0A= Internet organizations, except as needed for the purpose of=0A= developing Internet standards in which case the procedures for=0A= copyrights defined in the Internet Standards process must be=0A= followed, or as required to translate it into languages other than=0A= English.=0A= =0A= The limited permissions granted above are perpetual and will not be=0A= revoked by the Internet Society or its successors or assigns.=0A= =0A= This document and the information contained herein is provided on an=0A= "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING=0A= TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING=0A= BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION=0A= HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF=0A= MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0A= =0A= Acknowledgement=0A= =0A= Funding for the RFC Editor function is currently provided by the=0A= Internet Society.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Rose Expires February 4, 2004 [Page 15]=0A= =0C=0A= ------=_NextPart_000_0048_01C35C25.540C6670-- -- to unsubscribe send a message to namedroppers-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 Aug 6 14: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 OAA29293 for ; Wed, 6 Aug 2003 14:47:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19kTFa-000Nnh-H9 for namedroppers-data@psg.com; Wed, 06 Aug 2003 18:43:06 +0000 Received: from [209.116.252.130] (helo=one.elistx.com) by psg.com with esmtp (Exim 4.20) id 19kTFX-000NnJ-R6 for namedroppers@ops.ietf.org; Wed, 06 Aug 2003 18:43:03 +0000 Received: from ogud.com (pcp04400154pcs.nrockv01.md.comcast.net [69.140.166.204]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HJ700DI4O2C8Z@eListX.com> for namedroppers@ops.ietf.org; Wed, 06 Aug 2003 14:44:36 -0400 (EDT) Received: from ENGILL.ogud.com (mail.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.8p1/8.12.8) with ESMTP id h76IiCc7000457 for ; Wed, 06 Aug 2003 14:44:13 -0400 (EDT envelope-from ogud@ogud.com) Date: Wed, 06 Aug 2003 14:42:34 -0400 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: Fwd: DNSEXT WGLC: Case Insensitive X-Sender: (Unverified) To: namedroppers@ops.ietf.org Message-id: <5.1.1.6.2.20030806144134.02121858@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_10 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Reminder of an ongoing WG last call that ends soon. >Date: Tue, 22 Jul 2003 18:15:25 -0400 >From: =D3lafur Gudmundsson/DNSEXT co-chair >Subject: DNSEXT WGLC: Case Insensitive >To: namedroppers@ops.ietf.org > >This starts a working group last call on this draft: >http://www.ietf.org/internet-drafts/draft-ietf-dnsext-insensitive-03.txt > >This document clarifies RFC1035 in regards to what values in a Domain Name >are affected by case insensitivity rules. >http://www.ietf.org/internet-drafts/draft-ietf-dnsext-insensitive-03.txt >This document is on standards track. > >Please send in any comments/support/opposition to this document to >namedroppers mailing list by August 7'th. >Silence on this draft will be considered as support to advance it. > > Olafur and 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 Wed Aug 6 14:53:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29463 for ; Wed, 6 Aug 2003 14:53:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19kTLm-000OMs-4J for namedroppers-data@psg.com; Wed, 06 Aug 2003 18:49:30 +0000 Received: from [128.32.132.165] (helo=nicemice.net) by psg.com with esmtp (Exim 4.20) id 19kTLi-000OMJ-HE for namedroppers@ops.ietf.org; Wed, 06 Aug 2003 18:49:26 +0000 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 19kTLh-00063k-00 for ; Wed, 06 Aug 2003 11:49:25 -0700 Date: Sun, 27 Jul 2003 23:58:53 +0000 From: "Adam M. Costello" To: IETF dnsext working group Subject: let CNAME and DNAME coexist at a node? Message-ID: <20030727235853.GA18049@nicemice.net> Reply-To: IETF dnsext working group Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i X-Spam-Status: No, hits=-7.9 required=5.0 tests=BAYES_30,USER_AGENT_MUTT version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk A node is not allowed to have both a CNAME record and a DNAME record, but I think such a combination would be harmless and useful. (But I don't have a lot of practice reasoning about DNS resolution, so please read the following critically and watch for errors.) RFC 1034 says: If a CNAME RR is present at a node, no other data should be present; RFC 2672 reiterates that rule: If a DNAME RR is present at a node N, there may be other data at N (except a CNAME or another DNAME) RFC 1035 gives the following reasons for its prohibition of combining CNAME with other resource record types at a node: this ensures that the data for a canonical name and its aliases cannot be different. This rule also insures that a cached CNAME can be used without checking with an authoritative server for other RR types. These reasons don't apply to the combination of CNAME and DNAME. The CNAME record affects queries for the owner name itself, but has no effect on queries for its descendants. Conversely, the DNAME record affects queries for the descendents, but has no effect on queries for the owner name itself (except explicit queries for DNAME records, which would be unaffected by the CNAME record). In short, CNAME and DNAME don't get in each other's way at all; their jurisdictions are non-overlapping. It would be useful to have both CNAME and DNAME at the same node. For example, supposed I wanted example.net to be an alternate spelling of example.com, so that (a) http://www.example.net/ reaches the same web server as http://www.example.com/ (b) foo@bar.example.net reaches the same mail server as foo@bar.example.com (c) http://example.net/ reaches the same web server as http://example.com/ (d) foo@example.net reaches the same mail server as foo@example.com I could accomplish (a) and (b) (but not (c) and (d)) using DNAME: example.net. DNAME example.com. I could accomplish (c) and (d) (but not (a) and (b)) using CNAME: example.net. CNAME example.com. If I were allowed to use CNAME and DNAME together, I could accomplish all four: example.net. CNAME example.com. DNAME example.com. Without being able to use CNAME and DNAME together, the best I can do is use DNAME only, and simulate the effect of CNAME by keeping the A and MX records synchronized for example.net and example.com (in two separate zones). The only way I can see to completely alias an entire domain (a node and all its descendants) is to combine CNAME and DNAME. Before RFC 2672 is advanced to draft standard, should it be revised to allow this combination (updating RFC 1034)? AMC -- to unsubscribe send a message to namedroppers-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 Aug 6 23:16: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 XAA15718 for ; Wed, 6 Aug 2003 23:16:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19kb9g-000840-Vt for namedroppers-data@psg.com; Thu, 07 Aug 2003 03:09:32 +0000 Received: from [2001:470:1f00:ffff::5a1] (helo=bsdi.dv.isc.org) by psg.com with esmtp (Exim 4.20) id 19kb9d-00083l-QC for namedroppers@ops.ietf.org; Thu, 07 Aug 2003 03:09:30 +0000 Received: from bsdi.dv.isc.org (localhost.dv.isc.org [127.0.0.1]) by bsdi.dv.isc.org (8.12.9/8.12.9) with ESMTP id h7739RYf074823 for ; Thu, 7 Aug 2003 13:09:28 +1000 (EST) (envelope-from marka@bsdi.dv.isc.org) Message-Id: <200308070309.h7739RYf074823@bsdi.dv.isc.org> To: IETF dnsext working group From: Mark.Andrews@isc.org Subject: Re: let CNAME and DNAME coexist at a node? In-reply-to: Your message of "Sun, 27 Jul 2003 23:58:53 GMT." <20030727235853.GA18049@nicemice.net> Date: Thu, 07 Aug 2003 13:09:27 +1000 X-Spam-Status: No, hits=-8.5 required=5.0 tests=BAYES_20,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > A node is not allowed to have both a CNAME record and a DNAME record, > but I think such a combination would be harmless and useful. > > (But I don't have a lot of practice reasoning about DNS resolution, so > please read the following critically and watch for errors.) > > RFC 1034 says: > > If a CNAME RR is present at a node, no other data should be present; > > RFC 2672 reiterates that rule: > > If a DNAME RR is present at a node N, there may be other data at N > (except a CNAME or another DNAME) > > RFC 1035 gives the following reasons for its prohibition of combining > CNAME with other resource record types at a node: > > this ensures that the data for a canonical name and its aliases > cannot be different. This rule also insures that a cached CNAME can > be used without checking with an authoritative server for other RR > types. > > These reasons don't apply to the combination of CNAME and DNAME. The > CNAME record affects queries for the owner name itself, but has no > effect on queries for its descendants. Conversely, the DNAME record > affects queries for the descendents, but has no effect on queries for > the owner name itself (except explicit queries for DNAME records, which > would be unaffected by the CNAME record). What is the behaviour of a cache that isn't aware of your new rules with the following query sequence? dig example.net CNAME dig example.net DNAME > In short, CNAME and DNAME don't get in each other's way at all; their > jurisdictions are non-overlapping. > > It would be useful to have both CNAME and DNAME at the same node. For > example, supposed I wanted example.net to be an alternate spelling of > example.com, so that > > (a) http://www.example.net/ reaches the same web server as > http://www.example.com/ > > (b) foo@bar.example.net reaches the same mail server as > foo@bar.example.com > > (c) http://example.net/ reaches the same web server as > http://example.com/ Solve the general problem of supporting http://example.net/ pointing to some arbitary server. Its solution space will cover this. > (d) foo@example.net reaches the same mail server as > foo@example.com foo@example.net DOES NOT EXIST if you use a CNAME. MTA's re-write foo@example.net -> foo@example.com. A MX record pointing to the same server avoids the re-write. > I could accomplish (a) and (b) (but not (c) and (d)) using DNAME: > > example.net. DNAME example.com. > > I could accomplish (c) and (d) (but not (a) and (b)) using CNAME: > > example.net. CNAME example.com. > If I were allowed to use CNAME and DNAME together, I could accomplish > all four: > > example.net. CNAME example.com. > DNAME example.com. > > Without being able to use CNAME and DNAME together, the best I can do is > use DNAME only, and simulate the effect of CNAME by keeping the A and MX > records synchronized for example.net and example.com (in two separate > zones). > > The only way I can see to completely alias an entire domain (a node > and all its descendants) is to combine CNAME and DNAME. Before RFC > 2672 is advanced to draft standard, should it be revised to allow this > combination (updating RFC 1034)? > > AMC > > -- > to 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 Aug 7 00:17: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 AAA17186 for ; Thu, 7 Aug 2003 00:17:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19kc9o-000CoO-6I for namedroppers-data@psg.com; Thu, 07 Aug 2003 04:13:44 +0000 Received: from [128.32.132.165] (helo=nicemice.net) by psg.com with esmtp (Exim 4.20) id 19kc9j-000CnW-Sv for namedroppers@ops.ietf.org; Thu, 07 Aug 2003 04:13:39 +0000 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 19kc9j-0007Rg-00 for ; Wed, 06 Aug 2003 21:13:39 -0700 Date: Thu, 7 Aug 2003 04:13:39 +0000 From: "Adam M. Costello" To: IETF dnsext working group Subject: Re: let CNAME and DNAME coexist at a node? Message-ID: <20030807041339.GE26928@nicemice.net> Reply-To: IETF dnsext working group References: <20030727235853.GA18049@nicemice.net> <200308070309.h7739RYf074823@bsdi.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200308070309.h7739RYf074823@bsdi.dv.isc.org> User-Agent: Mutt/1.5.4i X-Spam-Status: No, hits=-38.6 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mark.Andrews@isc.org wrote: > What is the behaviour of a cache that isn't aware of your new > rules with the following query sequence? > > dig example.net CNAME > dig example.net DNAME Oh dear, that's a problem. The server will cache the CNAME pointing from example.net to example.com, and then when it gets the DNAME query for example.net, it will try to chase down a DNAME record belonging to example.com rather than example.net. That might be a show-stopper. > > (c) http://example.net/ reaches the same web server as > > http://example.com/ > > Solve the general problem of supporting http://example.net/ > pointing to some arbitary server. Its solution space will > cover this. I thought the general problem had already been solved, and the solution is to make example.net be a CNAME for the server. I guess I don't understand what you mean. > > (d) foo@example.net reaches the same mail server as > > foo@example.com > > foo@example.net DOES NOT EXIST if you use a CNAME. > MTA's re-write foo@example.net -> foo@example.com. Only for the SMTP commands (like MAIL and RCPT). The only header fields affected by this rewriting are Received and Return-Path. The fields that users typically see (To, From, Cc, Reply-To, etc) are not rewritten (at least, they shouldn't be according to RFC 1123 section 5.2.6). Therefore, from a user's perspective, foo@example.net exists and works like any other address, even if example.net has a CNAME record. AMC -- to unsubscribe send a message to namedroppers-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 Aug 7 00:37: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 AAA17719 for ; Thu, 7 Aug 2003 00:37:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19kcTd-000EVN-8E for namedroppers-data@psg.com; Thu, 07 Aug 2003 04:34:13 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.20) id 19kcTa-000EUO-1a for namedroppers@ops.ietf.org; Thu, 07 Aug 2003 04:34:10 +0000 Received: (qmail 4637 invoked by uid 1016); 7 Aug 2003 04:34:29 -0000 Date: 7 Aug 2003 04:34:29 -0000 Message-ID: <20030807043429.4636.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: let CNAME and DNAME coexist at a node? References: <20030727235853.GA18049@nicemice.net> <200308070309.h7739RYf074823@bsdi.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-14.6 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mark.Andrews@isc.org writes: > foo@example.net DOES NOT EXIST if you use a CNAME. > MTA's re-write foo@example.net -> foo@example.com. Your understanding of the situation is obsolete. We MTA implementors really don't like having to do this, and at some point we're going to stop. RFC 2821 (paying no attention to backwards compatibility) allows MTA implementors to stop doing this already. Bottom line: You can't rely on SMTP clients to rewrite aliases. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Aug 7 11: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 LAA18954 for ; Thu, 7 Aug 2003 11:32:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19kmdU-00061N-Vk for namedroppers-data@psg.com; Thu, 07 Aug 2003 15:25:04 +0000 Received: from [212.16.99.49] (helo=burp.tkv.asdf.org) by psg.com with esmtp (Exim 4.20) id 19kmdR-00060c-OH for namedroppers@ops.ietf.org; Thu, 07 Aug 2003 15:25:02 +0000 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h77FP05Y003690 for ; Thu, 7 Aug 2003 18:25:00 +0300 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-6.4) id h77FP0MX003686; Thu, 7 Aug 2003 18:25:00 +0300 Date: Thu, 7 Aug 2003 18:25:00 +0300 Message-Id: <200308071525.h77FP0MX003686@burp.tkv.asdf.org> From: Markku Savela To: namedroppers@ops.ietf.org In-reply-to: <5.1.1.6.2.20030804100523.0161cfe0@localhost> (message from =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair on Mon, 04 Aug 2003 10:23:41 -0400) Subject: Re: DNSEXT WGLC for LLMNR References: <5.1.1.6.2.20030804100523.0161cfe0@localhost> X-Spam-Status: No, hits=-21.0 required=5.0 tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I've some comments on this... > This is a last call for the DNSEXT document > Linklocal Multicast Name Resolution (LLMNR) > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-22.txt -------------------------------------- .... 2.3. Unicast queries and responses Unicast queries SHOULD be sent when: a. A sender repeats a query after it received a response with the TC bit set to the previous LLMNR multicast query, or b. The sender queries for a PTR RR. .... --------------------------------------- Concerning 2.3 (b): How are you supposed to generate a unicast query out of PTR query, which is NOT "*.in-addr.arpa" or "*.ip6.arpa"? Thus, the section should be amended to include only PTR queries that are actually constructed from full IP addresses? Other PTR queries need to go via normal UDP? --------------------------------------- .... 4. Conflict resolution .... - multiple hosts may respond to a query for an A or AAAA type record for a cluster name (assigned to multiple hosts in the cluster) - only a single host may respond to a query for an A or AAAA type record for a hostname. .... --------------------------------------- The "cluster name" semantics is unclear to. How does a sender that queries a name know whether the name is a "hostname" or "cluster name"? Two choices: a) it's implicitly a "cluster name", if multiple answers are received (e.g. there will never be any conflict from sender viewpoint). b) each host must be configured locally with the list of legal "cluster names", and sender only accepts multiple answers for these names. I assume (a) is intended? -- to unsubscribe send a message to namedroppers-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 Aug 7 13:26: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 NAA23016 for ; Thu, 7 Aug 2003 13:26:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19koST-000E0p-Q8 for namedroppers-data@psg.com; Thu, 07 Aug 2003 17:21:49 +0000 Received: from [129.6.16.93] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.20) id 19koSM-000Dzc-0g for namedroppers@ops.ietf.org; Thu, 07 Aug 2003 17:21:42 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h77HLN5x007779 for ; Thu, 7 Aug 2003 13:21:23 -0400 (EDT) Message-ID: <027401c35d08$53e78830$b9370681@barnacle> From: "Scott Rose" To: Subject: Error codes and SIG(0) Date: Thu, 7 Aug 2003 13:21:24 -0400 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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_10 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a part of the SIG(0) updating draft that is kind of an open question. In the current RFC 2931, there is no error code (like in TSIG) returned to the client when an error occurs. This is also an issue in draft-stjohns-secure-notify-00.txt when talking about error codes to return when using SIG(0)'s as part of the notify message. Is there a need to have some sort of error code returned when using SIG(0)? This could be the same codes as used with TSIG (BADSIG, BADTIME), with a slight variation in meaning. Probably with never having a return signed with a SIG(0) (to prevent an easy DoS attack). It would just return the error response without a SIG(0). The first question to ask ourselves is whether or not there needs to be text on error return codes for SIG(0) errors. 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 Aug 7 14:00: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 OAA24436 for ; Thu, 7 Aug 2003 14:00:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19kozw-000GU1-7n for namedroppers-data@psg.com; Thu, 07 Aug 2003 17:56:24 +0000 Received: from [195.169.222.38] (helo=elektron.atoom.net) by psg.com with esmtp (Exim 4.20) id 19kozs-000GTb-Op for namedroppers@ops.ietf.org; Thu, 07 Aug 2003 17:56:20 +0000 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.9/8.12.9/Debian-5) with ESMTP id h77HuDIe018414; Thu, 7 Aug 2003 19:56:13 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.9/8.12.9/Debian-5) with ESMTP id h77HuCI8018410; Thu, 7 Aug 2003 19:56:12 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Thu, 7 Aug 2003 19:56:12 +0200 (CEST) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: Scott Rose cc: namedroppers@ops.ietf.org Subject: Re: Error codes and SIG(0) In-Reply-To: <027401c35d08$53e78830$b9370681@barnacle> Message-ID: References: <027401c35d08$53e78830$b9370681@barnacle> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE,X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 7 Aug 2003, Scott Rose wrote: > This is a part of the SIG(0) updating draft that is kind of an open > question. In the current RFC 2931, there is no error code (like in TSIG) > returned to the client when an error occurs. This is also an issue in > draft-stjohns-secure-notify-00.txt when talking about error codes to return > when using SIG(0)'s as part of the notify message. > > Is there a need to have some sort of error code returned when using SIG(0)? > This could be the same codes as used with TSIG (BADSIG, BADTIME), with a > slight variation in meaning. Probably with never having a return signed > with a SIG(0) (to prevent an easy DoS attack). It would just return the > error response without a SIG(0). > > The first question to ask ourselves is whether or not there needs to be text > on error return codes for SIG(0) errors. IMHO it would be very handy for debugging server side problems. If an error is replicated in a response message, it would be handy to classify them in BADSIG BADKEY BADTIME BADMODE BADNAME BADALG. It would actually be handy to map them them in the extended RCODE in the OPT (edns(0)) record as well. 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 Aug 7 14:48: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 OAA26550 for ; Thu, 7 Aug 2003 14:48:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19kpgN-000JOs-1x for namedroppers-data@psg.com; Thu, 07 Aug 2003 18:40:15 +0000 Received: from [129.6.16.93] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.20) id 19kpgK-000JOY-0J for namedroppers@ops.ietf.org; Thu, 07 Aug 2003 18:40:12 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h77Ids5x016452 for ; Thu, 7 Aug 2003 14:39:54 -0400 (EDT) Message-ID: <02a401c35d13$4bd9e9c0$b9370681@barnacle> From: "Scott Rose" To: References: <027401c35d08$53e78830$b9370681@barnacle> Subject: Re: Error codes and SIG(0) Date: Thu, 7 Aug 2003 14:39:55 -0400 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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-15.5 required=5.0 tests=BAYES_10,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit However, there seems to be a problem. The TSIG extended rcode values are stored in the TSIG, while the "extended RCODE" value is in the OPT RR. According to the IANA database, both have reserved the code 16 for BADVERS and BADSIG. There is no space for an extended rcode value in the SIG(0) RR, unless the spec is changed to give remap a field to that purpose. Or else the two competing rcode assignments be reconciled somehow. Scott ----- Original Message ----- From: "Roy Arends" To: "Scott Rose" Cc: Sent: Thursday, August 07, 2003 1:56 PM Subject: Re: Error codes and SIG(0) > On Thu, 7 Aug 2003, Scott Rose wrote: > > > This is a part of the SIG(0) updating draft that is kind of an open > > question. In the current RFC 2931, there is no error code (like in TSIG) > > returned to the client when an error occurs. This is also an issue in > > draft-stjohns-secure-notify-00.txt when talking about error codes to return > > when using SIG(0)'s as part of the notify message. > > > > Is there a need to have some sort of error code returned when using SIG(0)? > > This could be the same codes as used with TSIG (BADSIG, BADTIME), with a > > slight variation in meaning. Probably with never having a return signed > > with a SIG(0) (to prevent an easy DoS attack). It would just return the > > error response without a SIG(0). > > > > The first question to ask ourselves is whether or not there needs to be text > > on error return codes for SIG(0) errors. > > IMHO it would be very handy for debugging server side problems. If an > error is replicated in a response message, it would be handy to classify > them in BADSIG BADKEY BADTIME BADMODE BADNAME BADALG. It would actually > be handy to map them them in the extended RCODE in the OPT (edns(0)) > record as well. > > 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 Aug 7 17:32: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 RAA04093 for ; Thu, 7 Aug 2003 17:32:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19ks6Z-0003HJ-Pa for namedroppers-data@psg.com; Thu, 07 Aug 2003 21:15:27 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.20) id 19ks6X-0003H6-MS for namedroppers@ops.ietf.org; Thu, 07 Aug 2003 21:15:25 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id E856F13948 for ; Thu, 7 Aug 2003 21:15:24 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Error codes and SIG(0) In-Reply-To: Message from "Scott Rose" of "Thu, 07 Aug 2003 14:39:55 -0400." <02a401c35d13$4bd9e9c0$b9370681@barnacle> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 07 Aug 2003 21:15:24 +0000 Message-Id: <20030807211524.E856F13948@sa.vix.com> X-Spam-Status: No, hits=-9.5 required=5.0 tests=BAYES_20,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > However, there seems to be a problem. The TSIG extended rcode values are > stored in the TSIG, while the "extended RCODE" value is in the OPT RR. > According to the IANA database, both have reserved the code 16 for BADVERS > and BADSIG. There is no space for an extended rcode value in the SIG(0) RR, > unless the spec is changed to give remap a field to that purpose. > > Or else the two competing rcode assignments be reconciled somehow. the original edns proposal had a major and a minor version number, with the intent that minor version numbers could indicate understanding of (and therefore an implicit solicitation of) more OPT's without changing the encoding format of anything in the opt-rdata. this got taken out, and our only method of indicating an initiator's ability to understand a new OPT (like an extended error code blob) would be to negotiate a higher edns version number. this seems like overkill, but could be done. -- to unsubscribe send a message to namedroppers-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 Aug 8 09:11: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 JAA09790 for ; Fri, 8 Aug 2003 09:11:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19l6rf-000NrU-CF for namedroppers-data@psg.com; Fri, 08 Aug 2003 13:01:03 +0000 Received: from [129.6.16.93] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.20) id 19l6rT-000Nq9-FY for namedroppers@ops.ietf.org; Fri, 08 Aug 2003 13:00:51 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h78D0T5x005272 for ; Fri, 8 Aug 2003 09:00:29 -0400 (EDT) Message-ID: <008301c35dad$0bdcc910$b9370681@barnacle> From: "Scott Rose" To: References: <20030807211524.E856F13948@sa.vix.com> Subject: Re: Error codes and SIG(0) Date: Fri, 8 Aug 2003 09:00:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-16.1 required=5.0 tests=BAYES_10,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Another option would be to re-allocate a field in the SIG(0) RDATA to act as the same extended error code field in the TSIG RDATA. There are a few "left over" fields in the SIG(0) to do this, as they were part of the original SIG RR. In that case, the returning an error from a SIG(0) would be more like returning an error in TSIG. That is, there would be a SIG(0) RR at the end of the response without the actual signature field, and the error code set to some value. ----- Original Message ----- From: "Paul Vixie" To: Sent: Thursday, August 07, 2003 5:15 PM Subject: Re: Error codes and SIG(0) > > However, there seems to be a problem. The TSIG extended rcode values are > > stored in the TSIG, while the "extended RCODE" value is in the OPT RR. > > According to the IANA database, both have reserved the code 16 for BADVERS > > and BADSIG. There is no space for an extended rcode value in the SIG(0) RR, > > unless the spec is changed to give remap a field to that purpose. > > > > Or else the two competing rcode assignments be reconciled somehow. > > the original edns proposal had a major and a minor version number, with > the intent that minor version numbers could indicate understanding of > (and therefore an implicit solicitation of) more OPT's without changing > the encoding format of anything in the opt-rdata. this got taken out, > and our only method of indicating an initiator's ability to understand > a new OPT (like an extended error code blob) would be to negotiate a > higher edns version number. this seems like overkill, but could be done. > > -- > to 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 Aug 11 15:56: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 PAA02809 for ; Mon, 11 Aug 2003 15:56:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19mIcI-000HO0-F5 for namedroppers-data@psg.com; Mon, 11 Aug 2003 19:46:06 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.20) id 19mIcF-000HNn-Gz for namedroppers@ops.ietf.org; Mon, 11 Aug 2003 19:46:03 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01275; Mon, 11 Aug 2003 15:45:57 -0400 (EDT) Message-Id: <200308111945.PAA01275@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-wcard-clarify-01.txt Date: Mon, 11 Aug 2003 15:45:57 -0400 X-Spam-Status: No, hits=1.5 required=5.0 tests=BAYES_30,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-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 : Clarifying the Role of Wild Card Domains in the Domain Name System Author(s) : B. Halley, E. Lewis Filename : draft-ietf-dnsext-wcard-clarify-01.txt Pages : 0 Date : 2003-8-11 The definition of wild cards is recast from the original in RFC 1034, in words that are more specific and in line with RFC 2119. This document is meant to supplement the definition in RFC 1034 and to alter neither the spirit nor intent of that definition. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-wcard-clarify-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-wcard-clarify-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-wcard-clarify-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-8-11143200.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-wcard-clarify-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-wcard-clarify-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-11143200.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 Aug 11 15:59: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 PAA03175 for ; Mon, 11 Aug 2003 15:59:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19mIke-000Hq4-G5 for namedroppers-data@psg.com; Mon, 11 Aug 2003 19:54:44 +0000 Received: from [131.137.245.203] (helo=mx03.forces.gc.ca) by psg.com with esmtp (Exim 4.20) id 19mIkb-000Hpj-Py for namedroppers@ops.ietf.org; Mon, 11 Aug 2003 19:54:41 +0000 Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx03.forces.gc.ca (DND-Mailer) with ESMTP id C675A20660A for ; Mon, 11 Aug 2003 15:53:04 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19mId7-0007bm-4C for ietf-announce-list@asgard.ietf.org; Mon, 11 Aug 2003 15:46:57 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19mIcG-0007Ru-Hz for all-ietf@asgard.ietf.org; Mon, 11 Aug 2003 15:46:04 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01275; Mon, 11 Aug 2003 15:45:57 -0400 (EDT) Message-Id: <200308111945.PAA01275@ietf.org> 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-wcard-clarify-01.txt Date: Mon, 11 Aug 2003 15:45:57 -0400 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="MIMEStream=_0+241724_53130367821208_3148410049" X-Spam-Status: No, hits=2.8 required=5.0 tests=NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --MIMEStream=_0+241724_53130367821208_3148410049 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 : Clarifying the Role of Wild Card Domains in the Domain Name System Author(s) : B. Halley, E. Lewis Filename : draft-ietf-dnsext-wcard-clarify-01.txt Pages : 0 Date : 2003-8-11 The definition of wild cards is recast from the original in RFC 1034, in words that are more specific and in line with RFC 2119. This document is meant to supplement the definition in RFC 1034 and to alter neither the spirit nor intent of that definition. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-wcard-clarify-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-wcard-clarify-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-wcard-clarify-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. --MIMEStream=_0+241724_53130367821208_3148410049 Content-Type: Multipart/Alternative; boundary="MIMEStream=_1+273797_78541621326173_0616746533" --MIMEStream=_1+273797_78541621326173_0616746533 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-11143200.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-wcard-clarify-01.txt --MIMEStream=_1+273797_78541621326173_0616746533 Content-Type: Message/External-body; name="draft-ietf-dnsext-wcard-clarify-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-11143200.I-D@ietf.org> --MIMEStream=_1+273797_78541621326173_0616746533-- --MIMEStream=_0+241724_53130367821208_3148410049-- -- to unsubscribe send a message to namedroppers-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 Aug 12 09:47: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 JAA13189 for ; Tue, 12 Aug 2003 09:47:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19mZLr-0005cK-Rm for namedroppers-data@psg.com; Tue, 12 Aug 2003 13:38:15 +0000 Received: from [129.6.16.93] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.20) id 19mZLo-0005c2-Ux for namedroppers@ops.ietf.org; Tue, 12 Aug 2003 13:38:13 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h7CDbs5x012147 for ; Tue, 12 Aug 2003 09:37:54 -0400 (EDT) Message-ID: <009d01c360d6$ef6a6120$b9370681@barnacle> From: "Scott Rose" To: Subject: Adding an error code field to SIG(0) Date: Tue, 12 Aug 2003 09:37:54 -0400 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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-1.6 required=5.0 tests=BAYES_30 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit As a follow up to the new SIG(0) revision, I talked about adding an error code field or having the server return an error result in an reply with an OPT message. If the first solution is agreed upon, it would be the first 16 bits of the "original TTL" field in the SIG RR. Since there is no TTL field needed for meta-RRs, this could now be 16 bits for the error code, and 16 reserved bits. The first draft of the error handling text is below. This is not in the first draft (draft-srose-rfc2931bis-00.txt) 5. Error Responses If the attempted validation of a SIG(0) results in an error condition, the host (DNS server or client) SHOULD send an error message back to the message sender. The response message consists of the following elements: A DNS message error code if applicable. The original question section. Empty answer and authority section. Additional section consisting of a properly constructed SIG(0) RR with the extended error code, but without an accompanying signature. That is, missing the final field in the RDATA. The SIG(0) returned in the error response does not contain a signature to avoid a denial of service attack based on tying up server resources valid cryptographic operations. The error code returned in the SIG(0) RDATA depends on the type of error encountered during validation. If the server gets a message from a client that is not authorized to make requests, the servers MUST reply with a REFUSED RCODE in the response header and NOERROR in the SIG(0) error code field. The server is not required to check the validity of the SIG(0) and MAY reject the request outright. If the client is allowed to make the request, but the validator cannot obtain the public key needed to validate the SIG(0), the server MUST send back a DNS message with ServFail RCODE in the message header and BADKEY error code in the SIG(0) RR in the additional section. If the request fails to validate because of a timing error (that is, the current server time falls out of the range given by the inception and expiration times), the server MUST return a DNS response with ServFail in the response code and BADTIME in the error code in the SIG(0) RDATA. The time values in the response SIG(0) can be used by the client to judge clock skew. If the signature fails to validate for some other reason, the server MUST send a response with the ServFail response code in the message header, and a BADSIG error code in the SIG(0) RDATA. --------------------------- comments desired/welcomed 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 Tue Aug 12 16:47: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 QAA28843 for ; Tue, 12 Aug 2003 16:47:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19mfsH-0000C6-EW for namedroppers-data@psg.com; Tue, 12 Aug 2003 20:36:09 +0000 Received: from [192.149.252.33] (helo=smtp1.arin.net) by psg.com with esmtp (Exim 4.20) id 19mfsD-000091-Ba for namedroppers@ops.ietf.org; Tue, 12 Aug 2003 20:36:05 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 7B6B639C; Tue, 12 Aug 2003 16:36:02 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id 2957D324 for ; Tue, 12 Aug 2003 16:36:02 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1) with ESMTP id 553635; Tue, 12 Aug 2003 16:34:50 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: Date: Tue, 12 Aug 2003 16:36:01 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: !aa &&!ra question Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-1.1 required=5.0 tests=BAYES_30,MANY_EXCLAMATIONS,SIGNATURE_SHORT_SPARSE version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Under what conditions can a response have the aa bit off and the ra bit off? I'm assuming that aa means that the data came from the data the server is authoritative for, or in the bad old days, the first "retransmission" of a response by a cache. I'm assuming that ra means I'll do recursion (for you). Is it possible that !aa && !ra means that I've learned this via recursion, but I won't recurse for you? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer One good way to avoid becoming scared: always keep your eyes shut. -- to unsubscribe send a message to namedroppers-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 Aug 12 17: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 RAA29417 for ; Tue, 12 Aug 2003 17:07:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19mgHE-0003eJ-8w for namedroppers-data@psg.com; Tue, 12 Aug 2003 21:01:56 +0000 Received: from [129.9.80.165] (helo=fxshpr08.extra.daimlerchrysler.com) by psg.com with esmtp (Exim 4.20) id 19mgHB-0003e3-Ot for namedroppers@ops.ietf.org; Tue, 12 Aug 2003 21:01:53 +0000 Received: (from uucp@localhost) by fxshpr08.extra.daimlerchrysler.com (8.12.8/8.9.0) id h7CKw5hc022836 for ; Tue, 12 Aug 2003 16:58:05 -0400 (EDT) Received: from nodnsquery(53.231.71.24) by fxshpr08.extra.daimlerchrysler.com via csmap (V6.0) id srcAAAriaqMS; Tue, 12 Aug 03 16:58:05 -0400 Received: from odconpr2-hme0.oddc.chrysler.com ([127.0.0.1]) by odconpr2-hme0.oddc.chrysler.com (Mail-Gear 2.0.0 bld 66) with SMTP id M2003081217015017326 for ; Tue, 12 Aug 2003 17:01:50 -0400 Received: from shmrspr2-hme0.shdc.chrysler.com ([129.9.145.240]) by odconpr2-hme0.oddc.chrysler.com (SAVSMTP 3.1.1.32) with SMTP id M2003081217014703686 for ; Tue, 12 Aug 2003 17:01:47 -0400 Received: from wokcdts1.is.chrysler.com (wokcdts1-eri0-1.is.chrysler.com [53.230.102.56]) by shmrspr2-hme0.shdc.chrysler.com (8.12.8/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id h7CL1loQ008352 for ; Tue, 12 Aug 2003 17:01:47 -0400 (EDT) Received: from daimlerchrysler.com (localhost [127.0.0.1]) by wokcdts1.is.chrysler.com (8.12.8/8.9.1) with ESMTP id h7CL16sw028621 for ; Tue, 12 Aug 2003 17:01:06 -0400 (EDT) Message-ID: <3F395592.9224DCA7@daimlerchrysler.com> Date: Tue, 12 Aug 2003 17:01:06 -0400 From: Kevin Darcy X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: !aa &&!ra question References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-23.2 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,MANY_EXCLAMATIONS, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward Lewis wrote: > Under what conditions can a response have the aa bit off and the ra bit off? > > I'm assuming that aa means that the data came from the data the > server is authoritative for, or in the bad old days, the first > "retransmission" of a response by a cache. > > I'm assuming that ra means I'll do recursion (for you). > > Is it possible that !aa && !ra means that I've learned this via > recursion, but I won't recurse for you? Yes. And referrals. - 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 Tue Aug 12 17:13: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 RAA29499 for ; Tue, 12 Aug 2003 17:13:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19mgNq-0004ar-52 for namedroppers-data@psg.com; Tue, 12 Aug 2003 21:08:46 +0000 Received: from [195.169.222.38] (helo=elektron.atoom.net) by psg.com with esmtp (Exim 4.20) id 19mgNn-0004af-Do for namedroppers@ops.ietf.org; Tue, 12 Aug 2003 21:08:43 +0000 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.9/8.12.9/Debian-5) with ESMTP id h7CL8Z9V003413; Tue, 12 Aug 2003 23:08:36 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.9/8.12.9/Debian-5) with ESMTP id h7CL8ZUN003409; Tue, 12 Aug 2003 23:08:35 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Tue, 12 Aug 2003 23:08:35 +0200 (CEST) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: Edward Lewis cc: namedroppers@ops.ietf.org Subject: Re: !aa &&!ra question In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=-38.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,MANY_EXCLAMATIONS, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_PINE,X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 12 Aug 2003, Edward Lewis wrote: > Under what conditions can a response have the aa bit off and the ra bit off? > > I'm assuming that aa means that the data came from the data the > server is authoritative for, or in the bad old days, the first > "retransmission" of a response by a cache. > > I'm assuming that ra means I'll do recursion (for you). > > Is it possible that !aa && !ra means that I've learned this via > recursion, but I won't recurse for you? Responses from authoritative servers will also give (!ra,!aa) when queried for data that give either delegations or referrals to root(hints). There are probably more cases. 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 Tue Aug 12 18:04: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 SAA00413 for ; Tue, 12 Aug 2003 18:04:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19mh9Q-000BKx-LF for namedroppers-data@psg.com; Tue, 12 Aug 2003 21:57:56 +0000 Received: from [192.149.252.33] (helo=smtp1.arin.net) by psg.com with esmtp (Exim 4.20) id 19mh9O-000BKk-9y for namedroppers@ops.ietf.org; Tue, 12 Aug 2003 21:57:54 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id DBC64372; Tue, 12 Aug 2003 17:57:53 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id 8C13C31F; Tue, 12 Aug 2003 17:57:53 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1) with ESMTP id 553818; Tue, 12 Aug 2003 17:56:41 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Tue, 12 Aug 2003 17:57:52 -0400 To: Roy Arends From: Edward Lewis Subject: Re: !aa &&!ra question Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-28.0 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,MANY_EXCLAMATIONS, REFERENCES,REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 23:08 +0200 8/12/03, Roy Arends wrote: >Responses from authoritative servers will also give (!ra,!aa) when queried >for data that give either delegations or referrals to root(hints). I shoulda added '&& ancount > 0" which rules out referrals. (I'm looking at some real data from a test.) I've seen Kevin's answer too. Thanks. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer One good way to avoid becoming scared: always keep your eyes shut. -- to unsubscribe send a message to namedroppers-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 Aug 12 18:35: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 SAA01818 for ; Tue, 12 Aug 2003 18:35:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19mhg6-000G6S-S9 for namedroppers-data@psg.com; Tue, 12 Aug 2003 22:31:42 +0000 Received: from [195.169.222.38] (helo=elektron.atoom.net) by psg.com with esmtp (Exim 4.20) id 19mhg4-000G6G-5J for namedroppers@ops.ietf.org; Tue, 12 Aug 2003 22:31:40 +0000 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.9/8.12.9/Debian-5) with ESMTP id h7CMVa9V005857; Wed, 13 Aug 2003 00:31:37 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.9/8.12.9/Debian-5) with ESMTP id h7CMVagZ005853; Wed, 13 Aug 2003 00:31:36 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 13 Aug 2003 00:31:36 +0200 (CEST) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: Edward Lewis cc: namedroppers@ops.ietf.org Subject: Re: !aa &&!ra question In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=-38.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,MANY_EXCLAMATIONS, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_PINE,X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 12 Aug 2003, Edward Lewis wrote: > At 23:08 +0200 8/12/03, Roy Arends wrote: > >Responses from authoritative servers will also give (!ra,!aa) when queried > >for data that give either delegations or referrals to root(hints). > > I shoulda added '&& ancount > 0" which rules out referrals. (I'm > looking at some real data from a test.) I've seen Kevin's answer too. I guess it must be glue@root then: try: dig +norec @a.root-servers.net ns1.mynet.net. a 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 Tue Aug 12 18:37: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 SAA01850 for ; Tue, 12 Aug 2003 18:37:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19mhik-000GWG-2p for namedroppers-data@psg.com; Tue, 12 Aug 2003 22:34:26 +0000 Received: from [195.169.222.38] (helo=elektron.atoom.net) by psg.com with esmtp (Exim 4.20) id 19mhih-000GW1-QT for namedroppers@ops.ietf.org; Tue, 12 Aug 2003 22:34:23 +0000 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.9/8.12.9/Debian-5) with ESMTP id h7CMYL9V005876; Wed, 13 Aug 2003 00:34:21 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.9/8.12.9/Debian-5) with ESMTP id h7CMYKh5005872; Wed, 13 Aug 2003 00:34:21 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 13 Aug 2003 00:34:20 +0200 (CEST) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: Edward Lewis cc: namedroppers@ops.ietf.org Subject: Re: !aa &&!ra question In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=-38.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,MANY_EXCLAMATIONS, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_PINE,X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 13 Aug 2003, Roy Arends wrote: > On Tue, 12 Aug 2003, Edward Lewis wrote: > > > At 23:08 +0200 8/12/03, Roy Arends wrote: > > >Responses from authoritative servers will also give (!ra,!aa) when queried > > >for data that give either delegations or referrals to root(hints). > > > > I shoulda added '&& ancount > 0" which rules out referrals. (I'm > > looking at some real data from a test.) I've seen Kevin's answer too. > > I guess it must be glue@root then: > > try: > > dig +norec @a.root-servers.net ns1.mynet.net. a Scratch that, any BIND 8.* (and prolly 4.*) will give glue back in answer section with !aa & !ra. 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 Wed Aug 13 04:17: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 EAA12136 for ; Wed, 13 Aug 2003 04:17:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19mqk2-000Ox3-S9 for namedroppers-data@psg.com; Wed, 13 Aug 2003 08:12:22 +0000 Received: from [193.0.1.96] (helo=birch.ripe.net) by psg.com with esmtp (Exim 4.20) id 19mqjz-000Owq-Ig for namedroppers@ops.ietf.org; Wed, 13 Aug 2003 08:12:19 +0000 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 h7D8CI3j006468 for ; Wed, 13 Aug 2003 10:12:18 +0200 Date: Wed, 13 Aug 2003 10:12:18 +0200 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: DNSSEC Open Questions Message-Id: <20030813101218.18d5417d.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.0 (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=-3.1 required=5.0 tests=BAYES_20 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear Colleagues, In order to quickly resolve the open issues for the DNSSECbis edit we want to try to get consesus on the still open issues. The processes for this is as follows: For each still open question on the list as posted July 14 and the new questions (numbers 13-14-15 dated August 3) we propose a text for a default solution. If there is no further discussion on the item before September 1 the editors may intrepred that silence as consent and put the solution in the document. Below is a summary of what we suggest, we will post these individually in the threads relevant to these discussions. Please use this thread for discussion of the process and the individual question-threads on the questions for discussing the technical/editorial content. All these have subject headers like: DNSSECbis Q-99: The issue with Bla is Foo. The documents are in an advanced state; If you have other issues please bring them up, preferably before last call. Q1 - CLOSED resolved Q2 - Should we move DSA to "optional" and have RSA/SHA1 be the only mandatory to implement algorithm? *Consensus? * We feel the thread leads towards making DSA optional to implement and to have RSA/SHA1 the only mandatory to implement algorithm. We also think all arguments been posted on the list. Please provide your yes or no, with a consice list of technical argumenst and try not to discuss each others arguments if they have allready been brought up previously in the thread. Silence will be taken as consensus with DSA optional and RSA/SHA1 as the only mandatory algorithm. Q3 - Can we drop the requirement to add the KEY/SIG(KEY) to the additional section of a response? *CLOSED: Consensus seems to be in favor of dropping requirement* For completeness: We, chairs, declare that consensus is in favor of dropping the requirement Q4 - mistake in numbering, there is no Q4 Q5 - Should algorithm code 252 (now "Indirect") remain, or move it to "Reserved"? *CLOSED: Consensus - Obsoleted by typecode rollover. Useless since there is still no draft describing its use. DNSKEY and KEY would have to have differing IANA algorithm registries. For completeness: As far as we know there has not been discussion on namedroppers so consensus cannot be declared, however this point is obsoleted by the typecode rollover, the working group does not need to have consensus on that. Q6 - Started as "Should sec-aware resolvers cache known "BAD" data"? but now encompasses how servers/resolvers should interpret the CD bit in the DNS header. * No formal consensus reached yet, discussion died out * We think think that this discussion needs to be completed. We propose the following and want to gauge concensus on that proposal. Security aware caching name servers SHOULD not cache bad data (normal circumstances), on the other hand security aware servers SHOULD cache data in the cases where a query for the same data is received in short time intervalls (DOS like circumstances). Note that this kind of caching is a form of negative caching, however the TTL vallue can not be derived from the data and has to be set by the implementation. We will refer to the data that is cached under these circumstances as data from the 'BAD cache'. If a query is received with the CD bit on, the server SHOULD in normal circumstances disable checking for the particular query and forward the data to the querying client. If the CD bit is set and data is available in the 'BAD cache' it should be fetched from there. If the CD is not set the server returns a failure. (wordcrafting is needed here. In the current implementation this would be a SERVFAIL). [Please respond to the content of this proposed text in the thread itself] Q7- Should the DNSSECbis documents discuss use of preconfigured trusted DSs in addition to preconfigured trusted KEYs? *CLOSED: consensus is: sure, why not? * For completeness: We declare the following consensus from the discussion on the list: The DNSSECbis document discuss different possibities for configuring a trust anchor. Q8 - Should the apex allow zone KEY RRs only? *CLOSED: Consensus seems to be no restrictions at all on KEY RR placement in a zone * besides, DNSKEY are the zone keys now. For completeness: We declare consensus as no restrictions at all on DNSKEY and KEY RR placement. Q9 - Dropping the SIG(NXT) from the NXT RRs included in the Auth. section on wildcard and negative replies *CLOSED: Consensus seems to be no allowing of NXT/SIG(NXT) breakup in authority section. Truncate response * For completeness: The consensus is that the complete set of NXT RRs is to be included in the authority section and that the inability to include one or more will lead to a message that is marked as truncated. Q10 - Silly state - some further elaboration and text will be presented to the list at a later date. Q11 - KEY RRs at delegation point. CLOSED: DNSKEY/KEY would be glue. Not a DNSSEC issue about what to allow as non-auth glue. Local policy about serving and accepting unsigned data would dictate. We feel that based on the discussion on the list this question can not be closed. The discussion so far can be summarized as above: DNSSEC does not introduce any special additional specifications whether RRs are to be treated as glue or not. No further discussion on this item before September 1 will be taken as consensus for this position. Q12 - Should support for configuring multiple trusted public keys in a security-aware resolver be a MUST rather than a SHOULD? We will take further silence on the list as consensus for the text as sugested in the original message. Consensus is gauged September 1. Q-13: Should the implementation advice regarding caching in security-aware resolvers remain in the document? We will take silence on the list as consensus for keeping this advice in the document. Q-14: Under certain circumstances, a security-aware recursive name servers could conceivably synthesize a response to one request using security data in its cache from a different, previous request. This behavior is currently discouraged with SHOULD NOTs, but should it be prohibited with MUST NOTs instead? We will take silence on the list as consensus for a change from SHOULD NOTs to MUST NOTs. Q-15: Should a security-aware stub resolver be allowed to set the CD bit on queries or should this behavior be prohibited? Question 15 seems to be based on a editorial goof. This question will either be clarified or obsoleted. Olafur and Olaf DNSEXT Chairs. -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-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 Aug 13 04:37: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 EAA12584 for ; Wed, 13 Aug 2003 04:37:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19mr3l-000PsF-L5 for namedroppers-data@psg.com; Wed, 13 Aug 2003 08:32:45 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.20) id 19mr3b-000Prn-OF for namedroppers@ops.ietf.org; Wed, 13 Aug 2003 08:32:40 +0000 Received: from delta.cs.mu.OZ.AU ([172.30.0.189]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h7D8WC114542; Wed, 13 Aug 2003 15:32:25 +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 h7D8TJG23941; Wed, 13 Aug 2003 15:29:32 +0700 (ICT) From: Robert Elz To: Edward Lewis cc: namedroppers@ops.ietf.org Subject: Re: !aa &&!ra question In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Aug 2003 15:29:19 +0700 Message-ID: <24792.1060763359@munnari.OZ.AU> X-Spam-Status: No, hits=-11.7 required=5.0 tests=BAYES_20,IN_REP_TO,MANY_EXCLAMATIONS,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Tue, 12 Aug 2003 16:36:01 -0400 From: Edward Lewis Message-ID: | Under what conditions can a response have the aa bit off and the ra bit off? !aa just means server is not auth for the answer. !ra just means no recursion available. Those are independent, attempting to assign a common meaning to any combination of those bits is not a wise thing to attempt. I suspect that you're really asking "how can a server possibly ever get data that it isn't auth for if it doesn't offer recursion"? The answer to that is "any of a million ways, and nothing you should care about". Doing recursion for someone else is one way, glue is another, ... kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 13 04:56: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 EAA12805 for ; Wed, 13 Aug 2003 04:56:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19mrNL-0000wk-8A for namedroppers-data@psg.com; Wed, 13 Aug 2003 08:52:59 +0000 Received: from [195.169.222.38] (helo=elektron.atoom.net) by psg.com with esmtp (Exim 4.20) id 19mrNG-0000wX-FQ for namedroppers@ops.ietf.org; Wed, 13 Aug 2003 08:52:54 +0000 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.9/8.12.9/Debian-5) with ESMTP id h7D8qgbq019563; Wed, 13 Aug 2003 10:52:42 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.9/8.12.9/Debian-5) with ESMTP id h7D8qfSX019559; Wed, 13 Aug 2003 10:52:41 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 13 Aug 2003 10:52:41 +0200 (CEST) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: Robert Elz cc: Edward Lewis , namedroppers@ops.ietf.org Subject: Re: !aa &&!ra question In-Reply-To: <24792.1060763359@munnari.OZ.AU> Message-ID: References: <24792.1060763359@munnari.OZ.AU> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=-38.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,MANY_EXCLAMATIONS, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_PINE,X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 13 Aug 2003, Robert Elz wrote: > Date: Tue, 12 Aug 2003 16:36:01 -0400 > From: Edward Lewis > Message-ID: > > | Under what conditions can a response have the aa bit off and the ra bit off? > > !aa just means server is not auth for the answer. > !ra just means no recursion available. > > Those are independent, attempting to assign a common meaning to any > combination of those bits is not a wise thing to attempt. > > I suspect that you're really asking "how can a server possibly ever > get data that it isn't auth for if it doesn't offer recursion"? > > The answer to that is "any of a million ways, and nothing you should care > about". Au contraire ! It is a good exercise. Classifying responses is handy for debugging dns-related problems. I care about that. I assume more people do. 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 Wed Aug 13 07:25: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 HAA15909 for ; Wed, 13 Aug 2003 07:25:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19mtg7-0008fU-GB for namedroppers-data@psg.com; Wed, 13 Aug 2003 11:20:31 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.20) id 19mtg3-0008f9-K2 for namedroppers@ops.ietf.org; Wed, 13 Aug 2003 11:20:27 +0000 Received: from delta.cs.mu.OZ.AU ([172.30.0.189]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h7DBKI120782; Wed, 13 Aug 2003 18:20:19 +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 h7DB9iG26478; Wed, 13 Aug 2003 18:09:55 +0700 (ICT) From: Robert Elz To: Roy Arends cc: Edward Lewis , namedroppers@ops.ietf.org Subject: Re: !aa &&!ra question In-Reply-To: References: <24792.1060763359@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Aug 2003 18:09:44 +0700 Message-ID: <3876.1060772984@munnari.OZ.AU> X-Spam-Status: No, hits=-14.4 required=5.0 tests=BAYES_10,IN_REP_TO,MANY_EXCLAMATIONS,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Wed, 13 Aug 2003 10:52:41 +0200 (CEST) From: Roy Arends Message-ID: | Au contraire ! | | It is a good exercise. Classifying responses is handy for debugging | dns-related problems. I care about that. I assume more people do. Perhaps I used the wrong words. What I meant was that nothing can draw any firm conclusions about meaning from this - even if you think you know today everything about how this might have happened, tomorrow someone will invent a new way to get to the same state. That's fine for a human who is willing to do the work, including e-mail to server admins, wacko queries to the server to attempt to figure out its version, e-mail to the software authors, ... It isn't something that any software should ever use for any purpose however, and in particular, the Is it possible that !aa && !ra means that I've learned this via recursion, but I won't recurse for you? query that Ed asked in the message that started this - yes, it is possible, but it is only one possibility, and it would be wrong to conclude that is the correct interpretation in a particular case without lots more investigation. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 13 09:33: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 JAA18762 for ; Wed, 13 Aug 2003 09:33:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19mved-000FYi-7C for namedroppers-data@psg.com; Wed, 13 Aug 2003 13:27:07 +0000 Received: from [192.149.252.33] (helo=smtp1.arin.net) by psg.com with esmtp (Exim 4.20) id 19mveZ-000FYL-Ok for namedroppers@ops.ietf.org; Wed, 13 Aug 2003 13:27:03 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 452D6408; Wed, 13 Aug 2003 09:27:03 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id D626E403; Wed, 13 Aug 2003 09:27:02 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1) with ESMTP id 555220; Wed, 13 Aug 2003 09:25:47 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <24792.1060763359@munnari.OZ.AU> References: <24792.1060763359@munnari.OZ.AU> Date: Wed, 13 Aug 2003 09:22:17 -0400 To: Robert Elz From: Edward Lewis Subject: Re: !aa &&!ra question Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-28.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,MANY_EXCLAMATIONS, REFERENCES,REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 15:29 +0700 8/13/03, Robert Elz wrote: >I suspect that you're really asking "how can a server possibly ever >get data that it isn't auth for if it doesn't offer recursion"? Pretty much... >The answer to that is "any of a million ways, and nothing you should care >about". In the context I'm in, it matters. Under the banner of "lame delegation testing," I want to make sure that named servers are authoritative and not just answering. I also want to be able to send a heuristic statement about "what's the matter" to the delegation's operator. (Ya know, turnover of staff and whatnot.) >Doing recursion for someone else is one way, glue is another, ... Okay - in my context (SOA lookups) it seems like it would be insidious, under-handed recursion and not glue. ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer One good way to avoid becoming scared: always keep your eyes shut. -- to unsubscribe send a message to namedroppers-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 Aug 13 09:33: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 JAA18781 for ; Wed, 13 Aug 2003 09:33:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19mvem-000FZv-Be for namedroppers-data@psg.com; Wed, 13 Aug 2003 13:27:16 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.20) id 19mveb-000FYa-5l for namedroppers@ops.ietf.org; Wed, 13 Aug 2003 13:27:05 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id A9E184E1; Wed, 13 Aug 2003 09:27:04 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id F18CB4D6; Wed, 13 Aug 2003 09:27:03 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1) with ESMTP id 555221; Wed, 13 Aug 2003 09:25:48 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <3876.1060772984@munnari.OZ.AU> References: <24792.1060763359@munnari.OZ.AU> <3876.1060772984@munnari.OZ.AU> Date: Wed, 13 Aug 2003 09:23:43 -0400 To: Robert Elz From: Edward Lewis Subject: Re: !aa &&!ra question Cc: Roy Arends , Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-28.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,MANY_EXCLAMATIONS, REFERENCES,REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 18:09 +0700 8/13/03, Robert Elz wrote: >That's fine for a human who is willing to do the work, including e-mail >to server admins, wacko queries to the server to attempt to figure out >its version, e-mail to the software authors, ... Willing, well, is one word...'directed' is another. ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer One good way to avoid becoming scared: always keep your eyes shut. -- to unsubscribe send a message to namedroppers-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 Aug 13 09:39: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 JAA18864 for ; Wed, 13 Aug 2003 09:39:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19mvlc-000GE4-Gx for namedroppers-data@psg.com; Wed, 13 Aug 2003 13:34:20 +0000 Received: from [192.149.252.33] (helo=smtp1.arin.net) by psg.com with esmtp (Exim 4.20) id 19mvlZ-000GAu-1X for namedroppers@ops.ietf.org; Wed, 13 Aug 2003 13:34:18 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 30FEA424; Wed, 13 Aug 2003 09:34:15 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id CCCAC421 for ; Wed, 13 Aug 2003 09:34:14 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1) with ESMTP id 555237; Wed, 13 Aug 2003 09:32:59 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: Date: Wed, 13 Aug 2003 09:34:13 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: wcard Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-6.4 required=5.0 tests=BAYES_10,SIGNATURE_SHORT_SPARSE version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk A new version (now with 99% less DNSSEC!) of the wild card clarify document has been posted (and if you are reading this message you probably already know that). I think it contains all the hanging issues (for what remains in the doc) from the discussions held at the last in-face meeting. Things to look out for - make sure I captured comments right, I've not been dedicating time to this recently. I also put in new text for the handling of a CNAME at a '*' which I literally stitched together Frankstein-like from other parts of 1034 to keep it in style and I only hope it's readable. (The new text is supposed to replace RFC 1034's 4.3.2-3c.) It there ain't problems, I wouldn't have regrets if it were sent to the IESG, unless the chairs want to last call it. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer One good way to avoid becoming scared: always keep your eyes shut. -- to unsubscribe send a message to namedroppers-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 Aug 13 12:47: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 MAA25610 for ; Wed, 13 Aug 2003 12:47:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19mydJ-0001Su-CK for namedroppers-data@psg.com; Wed, 13 Aug 2003 16:37:57 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.20) id 19mydF-0001Sh-9F for namedroppers@ops.ietf.org; Wed, 13 Aug 2003 16:37:53 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id h7DGasPQ026911 for ; Wed, 13 Aug 2003 12:36:54 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAl2aWJ0; Wed, 13 Aug 03 12:36:54 -0400 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id h7DGaTUI014841 for ; Wed, 13 Aug 2003 12:36:29 -0400 (EDT) Date: Wed, 13 Aug 2003 12:36:29 -0400 (EDT) From: Sam Weiler X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org Subject: DNSSECbis Q-2: degradation attack In-Reply-To: <20030813101218.18d5417d.olaf@ripe.net> Message-ID: References: <20030813101218.18d5417d.olaf@ripe.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-18.5 required=5.0 tests=BAYES_20,IN_REP_TO,REFERENCES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This grew out of Q2 discussions (re: moving DSA to optional). I like the idea of moving DSA to optional (it's a weak liking -- I don't care that much), but we need to address the following first: A degradation attack is possible when multiple algorithms appear in an apex DNSKEYset and/or DSset. If not fixed, this attack will make new (or optional) algorithms undeployable. First, the proposed change that avoids the attack: Every RRset MUST be signed by at least one DNSKEY of each algorithm in the DSset and each additional algorithm, if any, in the apex DNSKEYset. The apex DNSKEYset itself must be signed by each algorithm appearing in the zone's DSset. And the implications for a validator: 1) If the only algorithms in a DSset aren't ones you understand, you may treat the zone as unsigned (as things are now). 2) If there are algorithms you grok in the DSset, but the only algorithms signing the DNSKEYset are ones you don't understand, you should assume something bad is happening. (this is a change) 3) And if there are algorithms you grok in the DSset and DNSKEYset, but the only signatures on some RRset are made with algorithms you don't understand, you should assume something bad is happening (this is a change). This change is based on the premise that the failure mode when "I don't grok your algorithm(s)" may be different from the "this RRset looks like it should be signed, but I haven't gotten a good RRSIG" failure mode. In the former case, current code may treat the zone as unsigned and keep giving answers. In the latter, current code (generally) won't return an answer. The Problem: As currently specified, it's sufficient for an RRset to be signed by any of the zone's apex DNSKEYs. There's no way for a validator to tell which DNSKEYs the zone used (or intended to use) to sign a given RRset. If a zone includes an optional algorithm in its apex DNSKEYset, then signs some RRs with only that algorithm, a validator can't tell whether or not it's supposed to be getting other RRSIGs or not. For example, a zone with a type 5 DNSKEY (RSA/SHA-1) and a type 42 DNSKEY (CryptSam, yet to be specified) might choose to sign its DNSKEYset with the type 5 DNSKEY and everything else with the type 42 DNSKEY. In that case, you'd want a validator that doesn't understand type 42 to do something gentle, such as treating the zone as unsigned. The problem is that an attacker can strip RRSIGs. Assume, in the example above, that the zone owner signed the whole zone with BOTH DNSKEYs. That would let well-behaved clients, absent an attack, validate the data. But an attacker, knowing that type 42 DNSKEYs aren't widely supported, could forge answers in the zone and forge type 42 RRSIGs (with random data), knowing that virtually no one would be able to validate those signatures. There's no way for most validators to tell the difference between this case and the "I only signed with type 42" case above. Hence, adding a DNSKEY of a non-mandatory type to your apex DNSKEYset opens the door to a degradation attack. The same problem exists in the DS-->DNSKEYset security chain. If a parent adds a DS record of an optional type, the attacker can forge a DNSKEYset signed by only the optional algorithm type that appears in the DSset. A liberal validator, assuming that an RRSIG made by any of the DS's is sufficient, will treat the zone as unsigned. (Presumably the attacker would want the forged DNSKEYset to include the real DNSKEY of the optional algorithm, since any validator can at least check to see if there's a DNSKEY corresponding to one of the DS RRs and that at least one of the signatures on the DNSKEYset purports to have been made by a DNSKEY of the same tag.) Both of these problems give zone owners a strong incentive to not add optional algorithms. The Fix: In broad terms, we need to add a mechanism that says "you can expect this RRset to be signed by these algorithms". Rather than specify a new (or per-RRset) mechanism, this fix assigns some additional semantics to existing data. Specifically, "if the algorithm is in the DNSKEYset, you have to sign everything with it". This avoids making any bits-on-the-wire protocol changes. And for the DSset, the rule looks like "if an algorithm is in the DSset, it has to be used to sign the DNSKEYset (hence it has to be in the DNSKEYset, hence it has to sign the whole zone)". Again, these are all client (and signer) behavior changes. Authoritative servers don't change, and bits on the wire don't change. This isn't to say that each key in the DNSKEYset or each key corresponding to a DS must be used, just that every algorithm must be used. Furthermore, a validator should accept ANY valid signature chain, even if it doesn't get RRSIGs of all algorithms types or if some RRSIGs fail to validate. A validator may ignore an algorithm, perhaps because that algorithm is weak, in which case it may make its validation decision as though the algorithm is completely unknown to it. For example, if the only DS records at a delegation are for such an algorithm, the validator probably treats the delegation as unsecured. -- to unsubscribe send a message to namedroppers-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 Aug 13 15:24: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 PAA02938 for ; Wed, 13 Aug 2003 15:24:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19n141-000AJB-Is for namedroppers-data@psg.com; Wed, 13 Aug 2003 19:13:41 +0000 Received: from [129.6.16.93] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.20) id 19n13r-000AIX-GK for namedroppers@ops.ietf.org; Wed, 13 Aug 2003 19:13:32 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h7DJDL5x020488 for ; Wed, 13 Aug 2003 15:13:21 -0400 (EDT) Message-ID: <01b601c361ce$f67e1080$b9370681@barnacle> From: "Scott Rose" To: References: <20030813101218.18d5417d.olaf@ripe.net> Subject: Re: DNSSECbis Q-2: degradation attack Date: Wed, 13 Aug 2003 15:13:22 -0400 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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I agree with the suggested text. Seems like something that should be stated in the protocol draft when signed zones are discussed. Scott ----- Original Message ----- From: "Sam Weiler" To: Sent: Wednesday, August 13, 2003 12:36 PM Subject: DNSSECbis Q-2: degradation attack > This grew out of Q2 discussions (re: moving DSA to optional). I like > the idea of moving DSA to optional (it's a weak liking -- I don't > care that much), but we need to address the following first: > > A degradation attack is possible when multiple algorithms appear in an > apex DNSKEYset and/or DSset. If not fixed, this attack will make new > (or optional) algorithms undeployable. First, the proposed change > that avoids the attack: > > Every RRset MUST be signed by at least one DNSKEY of each algorithm > in the DSset and each additional algorithm, if any, in the apex > DNSKEYset. The apex DNSKEYset itself must be signed by each > algorithm appearing in the zone's DSset. > > And the implications for a validator: > > 1) If the only algorithms in a DSset aren't ones you understand, > you may treat the zone as unsigned (as things are now). > > 2) If there are algorithms you grok in the DSset, but the only > algorithms signing the DNSKEYset are ones you don't understand, you > should assume something bad is happening. (this is a change) > > 3) And if there are algorithms you grok in the DSset and DNSKEYset, > but the only signatures on some RRset are made with algorithms you > don't understand, you should assume something bad is happening > (this is a change). > > This change is based on the premise that the failure mode when "I > don't grok your algorithm(s)" may be different from the "this RRset > looks like it should be signed, but I haven't gotten a good RRSIG" > failure mode. In the former case, current code may treat the zone as > unsigned and keep giving answers. In the latter, current code > (generally) won't return an answer. > > The Problem: > > As currently specified, it's sufficient for an RRset to be signed > by any of the zone's apex DNSKEYs. There's no way for a validator > to tell which DNSKEYs the zone used (or intended to use) to sign a > given RRset. > > If a zone includes an optional algorithm in its apex DNSKEYset, > then signs some RRs with only that algorithm, a validator can't > tell whether or not it's supposed to be getting other RRSIGs or > not. For example, a zone with a type 5 DNSKEY (RSA/SHA-1) and a > type 42 DNSKEY (CryptSam, yet to be specified) might choose to sign > its DNSKEYset with the type 5 DNSKEY and everything else with the > type 42 DNSKEY. In that case, you'd want a validator that doesn't > understand type 42 to do something gentle, such as treating the > zone as unsigned. > > The problem is that an attacker can strip RRSIGs. Assume, in the > example above, that the zone owner signed the whole zone with BOTH > DNSKEYs. That would let well-behaved clients, absent an attack, > validate the data. > > But an attacker, knowing that type 42 DNSKEYs aren't widely > supported, could forge answers in the zone and forge type 42 RRSIGs > (with random data), knowing that virtually no one would be able to > validate those signatures. There's no way for most validators to > tell the difference between this case and the "I only signed with > type 42" case above. Hence, adding a DNSKEY of a non-mandatory > type to your apex DNSKEYset opens the door to a degradation attack. > > The same problem exists in the DS-->DNSKEYset security chain. If a > parent adds a DS record of an optional type, the attacker can forge > a DNSKEYset signed by only the optional algorithm type that appears > in the DSset. A liberal validator, assuming that an RRSIG made by > any of the DS's is sufficient, will treat the zone as unsigned. > (Presumably the attacker would want the forged DNSKEYset to include > the real DNSKEY of the optional algorithm, since any validator can > at least check to see if there's a DNSKEY corresponding to one of > the DS RRs and that at least one of the signatures on the DNSKEYset > purports to have been made by a DNSKEY of the same tag.) > > Both of these problems give zone owners a strong incentive to not > add optional algorithms. > > The Fix: > > In broad terms, we need to add a mechanism that says "you can > expect this RRset to be signed by these algorithms". Rather than > specify a new (or per-RRset) mechanism, this fix assigns some > additional semantics to existing data. Specifically, "if the > algorithm is in the DNSKEYset, you have to sign everything with > it". This avoids making any bits-on-the-wire protocol changes. > > And for the DSset, the rule looks like "if an algorithm is in the > DSset, it has to be used to sign the DNSKEYset (hence it has to be > in the DNSKEYset, hence it has to sign the whole zone)". Again, > these are all client (and signer) behavior changes. Authoritative > servers don't change, and bits on the wire don't change. > > This isn't to say that each key in the DNSKEYset or each key > corresponding to a DS must be used, just that every algorithm must > be used. > > Furthermore, a validator should accept ANY valid signature chain, > even if it doesn't get RRSIGs of all algorithms types or if some > RRSIGs fail to validate. A validator may ignore an algorithm, > perhaps because that algorithm is weak, in which case it may make > its validation decision as though the algorithm is completely > unknown to it. For example, if the only DS records at a delegation > are for such an algorithm, the validator probably treats the > delegation as unsecured. > > > > > -- > to 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 Aug 13 16:31: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 QAA04907 for ; Wed, 13 Aug 2003 16:31:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19n2AC-000EBL-4M for namedroppers-data@psg.com; Wed, 13 Aug 2003 20:24:08 +0000 Received: from [192.52.233.66] (helo=mlbxsmtp2.harris.com) by psg.com with esmtp (Exim 4.20) id 19n2A7-000EAs-Ps for namedroppers@ops.ietf.org; Wed, 13 Aug 2003 20:24:03 +0000 Received: from mail pickup service by mlbxsmtp2.harris.com with Microsoft SMTPSVC; Wed, 13 Aug 2003 16:21:53 -0400 Received: from psg.com ([147.28.0.62]) by mlbxsmtp2.harris.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 13 Aug 2003 15:26:40 -0400 Received: from lserv by psg.com with local (Exim 4.20) id 19n141-000AJB-Is for namedroppers-data@psg.com; Wed, 13 Aug 2003 19:13:41 +0000 Received: from [129.6.16.93] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.20) id 19n13r-000AIX-GK for namedroppers@ops.ietf.org; Wed, 13 Aug 2003 19:13:32 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h7DJDL5x020488 for ; Wed, 13 Aug 2003 15:13:21 -0400 (EDT) Message-ID: <01b601c361ce$f67e1080$b9370681@barnacle> From: "Scott Rose" To: References: <20030813101218.18d5417d.olaf@ripe.net> Subject: Re: DNSSECbis Q-2: degradation attack Date: Wed, 13 Aug 2003 15:13:22 -0400 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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 13 Aug 2003 19:26:40.0453 (UTC) FILETIME=[D238B750:01C361D0] X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,REFERENCES version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I agree with the suggested text. Seems like something that should be stated in the protocol draft when signed zones are discussed. Scott ----- Original Message ----- From: "Sam Weiler" To: Sent: Wednesday, August 13, 2003 12:36 PM Subject: DNSSECbis Q-2: degradation attack > This grew out of Q2 discussions (re: moving DSA to optional). I like > the idea of moving DSA to optional (it's a weak liking -- I don't > care that much), but we need to address the following first: > > A degradation attack is possible when multiple algorithms appear in an > apex DNSKEYset and/or DSset. If not fixed, this attack will make new > (or optional) algorithms undeployable. First, the proposed change > that avoids the attack: > > Every RRset MUST be signed by at least one DNSKEY of each algorithm > in the DSset and each additional algorithm, if any, in the apex > DNSKEYset. The apex DNSKEYset itself must be signed by each > algorithm appearing in the zone's DSset. > > And the implications for a validator: > > 1) If the only algorithms in a DSset aren't ones you understand, > you may treat the zone as unsigned (as things are now). > > 2) If there are algorithms you grok in the DSset, but the only > algorithms signing the DNSKEYset are ones you don't understand, you > should assume something bad is happening. (this is a change) > > 3) And if there are algorithms you grok in the DSset and DNSKEYset, > but the only signatures on some RRset are made with algorithms you > don't understand, you should assume something bad is happening > (this is a change). > > This change is based on the premise that the failure mode when "I > don't grok your algorithm(s)" may be different from the "this RRset > looks like it should be signed, but I haven't gotten a good RRSIG" > failure mode. In the former case, current code may treat the zone as > unsigned and keep giving answers. In the latter, current code > (generally) won't return an answer. > > The Problem: > > As currently specified, it's sufficient for an RRset to be signed > by any of the zone's apex DNSKEYs. There's no way for a validator > to tell which DNSKEYs the zone used (or intended to use) to sign a > given RRset. > > If a zone includes an optional algorithm in its apex DNSKEYset, > then signs some RRs with only that algorithm, a validator can't > tell whether or not it's supposed to be getting other RRSIGs or > not. For example, a zone with a type 5 DNSKEY (RSA/SHA-1) and a > type 42 DNSKEY (CryptSam, yet to be specified) might choose to sign > its DNSKEYset with the type 5 DNSKEY and everything else with the > type 42 DNSKEY. In that case, you'd want a validator that doesn't > understand type 42 to do something gentle, such as treating the > zone as unsigned. > > The problem is that an attacker can strip RRSIGs. Assume, in the > example above, that the zone owner signed the whole zone with BOTH > DNSKEYs. That would let well-behaved clients, absent an attack, > validate the data. > > But an attacker, knowing that type 42 DNSKEYs aren't widely > supported, could forge answers in the zone and forge type 42 RRSIGs > (with random data), knowing that virtually no one would be able to > validate those signatures. There's no way for most validators to > tell the difference between this case and the "I only signed with > type 42" case above. Hence, adding a DNSKEY of a non-mandatory > type to your apex DNSKEYset opens the door to a degradation attack. > > The same problem exists in the DS-->DNSKEYset security chain. If a > parent adds a DS record of an optional type, the attacker can forge > a DNSKEYset signed by only the optional algorithm type that appears > in the DSset. A liberal validator, assuming that an RRSIG made by > any of the DS's is sufficient, will treat the zone as unsigned. > (Presumably the attacker would want the forged DNSKEYset to include > the real DNSKEY of the optional algorithm, since any validator can > at least check to see if there's a DNSKEY corresponding to one of > the DS RRs and that at least one of the signatures on the DNSKEYset > purports to have been made by a DNSKEY of the same tag.) > > Both of these problems give zone owners a strong incentive to not > add optional algorithms. > > The Fix: > > In broad terms, we need to add a mechanism that says "you can > expect this RRset to be signed by these algorithms". Rather than > specify a new (or per-RRset) mechanism, this fix assigns some > additional semantics to existing data. Specifically, "if the > algorithm is in the DNSKEYset, you have to sign everything with > it". This avoids making any bits-on-the-wire protocol changes. > > And for the DSset, the rule looks like "if an algorithm is in the > DSset, it has to be used to sign the DNSKEYset (hence it has to be > in the DNSKEYset, hence it has to sign the whole zone)". Again, > these are all client (and signer) behavior changes. Authoritative > servers don't change, and bits on the wire don't change. > > This isn't to say that each key in the DNSKEYset or each key > corresponding to a DS must be used, just that every algorithm must > be used. > > Furthermore, a validator should accept ANY valid signature chain, > even if it doesn't get RRSIGs of all algorithms types or if some > RRSIGs fail to validate. A validator may ignore an algorithm, > perhaps because that algorithm is weak, in which case it may make > its validation decision as though the algorithm is completely > unknown to it. For example, if the only DS records at a delegation > are for such an algorithm, the validator probably treats the > delegation as unsecured. > > > > > -- > to 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: -- to unsubscribe send a message to namedroppers-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 Aug 13 17:54: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 RAA07703 for ; Wed, 13 Aug 2003 17:54:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19n3RH-000IwS-Rr for namedroppers-data@psg.com; Wed, 13 Aug 2003 21:45:51 +0000 Received: from [209.116.252.130] (helo=one.elistx.com) by psg.com with esmtp (Exim 4.20) id 19n3R7-000Iw3-Fq for namedroppers@ops.ietf.org; Wed, 13 Aug 2003 21:45:41 +0000 Received: from ogud.com (pcp04400154pcs.nrockv01.md.comcast.net [69.140.166.204]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HJK001BYV6VMA@eListX.com> for namedroppers@ops.ietf.org; Wed, 13 Aug 2003 17:47:19 -0400 (EDT) Received: from ENGILL.ogud.com (mail.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.8p1/8.12.8) with ESMTP id h7DLklWE004806 for ; Wed, 13 Aug 2003 17:46:48 -0400 (EDT envelope-from ogud@ogud.com) Date: Wed, 13 Aug 2003 17:45:04 -0400 From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: DNSEXT IETF-57 WG minutes (draft) X-Sender: post@localhost To: namedroppers@ops.ietf.org Message-id: <5.1.1.6.2.20030813173749.015dc968@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.5 required=5.0 tests=BAYES_20,OPT_IN_CAPS version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Send in comments before I submit these: X-UIDL: 2P?"!&B~!!R&-!!4)I"! IETF 57 - Vienna, Austria DNSEXT Minutes Olafur thanked Randy Bush for his long service as WG chair and welcomed Olaf Kolkman as the new co-chair. Charter Text on list Focus on DNSSEC docs and its dependencies Process in the coming 2-3 months Important to have the core documents reviewed by more people Once DNSSEC done, advance docs that are in PS status to DS List put out of docs and will be used to build milestones Update from AD OPT-IN to Informational RFC, instead of Experimental Question on why INFO vs. EXP, answer was WG didn't accept, but there is need to document this for history. Since code exists and its sort-of half-baked, and people may want to "play" with it, it should be EXP. INFO: here's the endpoint, we're not putting on ST, EXP: go play with this and come back More words needed as to why decision was made, chairs to draft boilerplate text for document. IPSECKEY WG defining RR to store IPSEC Keys for Opportunistic Encryption, Will be most likely defining new IANA registry to key types for IPSECKEY if you think that's not a good idea, speak up on IPSECKEY WG list LLMNR 18 Issues raised and 17 resolved WG Last Call asked for in email DNSSEC Editors Report Want more input on the drafts from the list 4 drafts, 1 is threats, other 3 are BIS core drafts Open Issues Unresolved questions posted to list with some still unresolved Type code rollover draft may be revised to create new registry for new types not sure if that's necessary motivation came from wanting to keep KEY/SIG for SIG(0) uses new registry will allow DNSKEY/RRSIG to drop cruft from current registry are there any issues with having all of these new registries? IANA might be concerned about it due to the number of registries DS and Wildcard draft DS is in IESG last call Waiting on wildcard clarify DNSSEC-editors Question 6: should caches retain failed verifications (rephrase: how to interpret CD bit) Should caches try to reduce the number of identical queries going out by caching failed verification responses? CD bit just an optimization (a way to tell recursive nameserver you don't have to check SIGs if you don't want to) should CD be: I'm going to check SIGs, stay out of my way. one interpretation of RFC2535 is to say if verification fails, the recursive nameserver must drop the data SERVFAIL is not a good response when DNSSEC fails, need way to tell application what failed, why, where to go threat: if recursive nameserver's clock is wrong, but application host's clock is right, indirect DOS, which is unacceptable any other thoughts on CD bit, discuss on list Wildcard Clarification draft-ietf-dnsext-wcard-clarify-00.txt Since March Proof to formalize the notion/definition of closest encloser Proposals: Split document into 2 pieces Pre-DNSSEC and DNSSEC parts document contains 1034 updates and DNSSEC updates chapters 1-5, and appendix Appendix A update 1034 chapters 6,7 update/clarify DNSSEC Clarifying 1034 (Pre-DNSSEC) Existence statement Impact of Wild Card domain name owning particular RRs (CNAME, NS, DNAME, SOA) Related to CNAME-change to 4.3.2-3.c DNSSEC Part Rules for NXT's as part of authenticated denial as it relates to wild cards Fix up the proof, Bob would like someone with more formal math knowledge to check over proof Add "recipe" resulting from proof for implementor Where does this "part" go? Existence 1034 words too vague CNAMEs what happens to CNAMES owned by wild card names? according to 4.3.2 its okay NSs MAY? SHOULD? MUST? reject zone on load? no - don't say anything on wild cards owning NSs DNAMEs DNAME has problems, not specifically related to wild cards SOAs doesn't need discussion... Q: for these things that are deemed non-scenical, are implementor going to be directed to give horrible errors? it might not make sense to bar these at this time CNAME: not sure there's no problem text in 1034 is advisory, not a step-by-step procedure, different implementor might do steps in different order, it might be good to write the steps into a protocol document Q: is this necessary for the Pre-DNSSEC stuff? DNSSEC stuff is necessary Yes, the issue is 2 different servers doing it differently (a master and a slave) Change to 4.3.2-3.c add explicit text for CNAME chasing Actions Split Existence Add text to clarify "* NS" Modify step 3.c of 4.3.2 in 1034 Move DNSSEC text to own document Add "recipe" resulting from proof, edit proof Q: should these DNSSEC bits be put into a separate doc and progressed and then added to BIS documents by editors Not sure, depends on what the change is Comment: If we're going to mess with 4.3.2-3.c, then let's go ahead and make all the necessary changes to the algorithm change it from advisory to a nailed-down set of steps Chair: move DNSSEC parts to dnssec-BIS documents, only update 1034 in your document. TSIG Interoperabilty Testing Results Goal to move RFC2845 from PS to DS Must do interop tests with at least 2 independent implementations Categories: Client-Server (C-S) Slave-Master (S-M) Client-Forwarder-Server (C-F-S) Preliminary report at http://w6.nic.fr/RFC2845/ Full or partial interoperabilty found depending on category of tests (C-S, S-M, C-F-S) Q: were "other" clients (dhcpd doing TSIG dynups) tested? no Q: was any feedback given back to implementor on error messages due to error conditions? don't think so Secure Notify (diagrams showing zone relationships and steps in SEP key rollover) Goals automate parent-child interactions derived trust from established trust anchor (e.g. parent DS record) change parent-child interactions from OPS issue to Protocol issue Remove human from loop for routine actions Approach use NOTIFY from child to signal changes in Apex SEP KEY RRs NS records Glue? (maybe, maybe not) Secure NOTIFY by SIG(0) from SEP KEY chains to parent's DS Issues Type code change removes SIG(0) for SEP KEY (SEP DNSKEY) Will be resolved by TSIG(0) document (proposed) Q: Does this require that the SEP bit be set? yes that doc said that that bit would be info only, not used for protocol then why put it in the protocol? it should be used really applies to verification protocol - shouldn't be used there, but uses like this are okay Q: Use a key that belongs to the child to talk to the registry? no, not the registry, but to the master this changes the way registries interact with masters don't think so, parent may choose to not accept this packet, doesn't affect how registries talk to masters Chair: should separate DS bits from NS bits, parent zone has no way to check whether child zone is properly configured, updating NS could be harmful isn't it local policy to do that? lots of checks must be done to protect DNS from bad operators Comment: worried about adding new features to NOTIFY, designed along SNMP-TRAP theory: hint that now would be a good time to pull NOTIFY is pre-DNSSEC, since NOTIFY can be signed, data can be included preference to use UPDATE rather than NOTIFY UPDATE semantics don't cleanly fit this model Comment: could be really, really useful in the reverse tree universities have delegated entire /24s to departments who run their own nameservers policy would fit well automatic tunnel brokers using reverse map are also a good fit Q: what can i do with this, that i can't do with dynamic update? DS doesn't belong to child, DS is just a hash of my key technically, content of DS belongs to child, but signature of DS belongs to parent Comment: another key change document that uses only 1 DS at a time Comment: no shortage of opcodes, let's define a new opcode for it don't want to write yet another draft Comment: using dynamic update does remove one timing dependency Mike: trust anchor sits in SEP key, could you expand on that in the doc Q: is work in this area important for this WG? Chair: this doc makes changes to the protocol, must be DNSEXT, but it makes assumptions based on ops possibility all of this work gets dumped into a completely new WG Q: this WG or another WG? DNSEXT can take this work on if it doesn't go anywhere else not a prereq for the base docs Comment: cautious about changing the protocol since other protocol changes are being made for the DNSSEC stuff not sure if it is a good general solution Chair: key management issues are a major deployability issue for DNSSEC this needs to be looked at really hard wants the key management "pieces" to work on their own Chair: even with this doc in DNSEXT and changing the protocol, addressing ops issues maybe there are other solutions that address the same problem Chair: number of requirements assumptions that need to be fleshed out may be a couple of good, effective ways to solve it there are multiple requirements with multiple solutions Comment: come to DNSOP and discuss things there Final Comment There are now two tall Vikings running DNSEXT and if no one reads the documents, we will be using our Viking knowledge -- to unsubscribe send a message to namedroppers-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 Aug 13 18:12: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 SAA09067 for ; Wed, 13 Aug 2003 18:12:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19n3ml-000Kah-FX for namedroppers-data@psg.com; Wed, 13 Aug 2003 22:08:03 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.20) id 19n3mi-000KaV-7j for namedroppers@ops.ietf.org; Wed, 13 Aug 2003 22:08:00 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h7DLcFZ12260 for ; Wed, 13 Aug 2003 14:38:15 -0700 Date: Wed, 13 Aug 2003 14:38:15 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed Resolution to LLMNR Issue 43: PTR queries and cluster names Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-8.8 required=5.0 tests=BAYES_20,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The text of LLMNR Issue 43 is enclosed below. The proposed resolution is as follows: In Section 2.3, change: "b. The sender queries for a PTR RR." To: "b. The sender queries for the PTR RR of a fully formed IP address within the "in-addr.arpa" or "ipv6.arpa" zones." In Section 4, change: "The sender MUST anticipate receiving multiple replies to the same LLMNR query, in the event that several LLMNR enabled computers receive the query and respond with valid answers. When this occurs, the responses MAY first be concatenated, and then treated in the same manner that multiple RRs received from the same DNS server would." To: "The sender MUST anticipate receiving multiple replies to the same LLMNR query, in the event that several LLMNR enabled computers receive the query and respond with valid answers. When this occurs, the responses MAY first be concatenated, and then treated in the same manner that multiple RRs received from the same DNS server would; the sender perceives no inherent conflict from the receipt of multiple responses." ---------------------------------------------------------------------------- Issue 43: PTR queries and cluster names Submitter name: Markku Savella Submitter email address: msa@burp.tkv.asdf.org Date first submitted: August 4, 2003 Reference: Document: LLMNR-22 Comment type: T Priority: S Section: 2.3, 4 Rationale/Explanation of issue: 2.3. Unicast queries and responses Unicast queries SHOULD be sent when: a. A sender repeats a query after it received a response with the TC bit set to the previous LLMNR multicast query, or b. The sender queries for a PTR RR. .... --------------------------------------- Concerning 2.3 (b): How are you supposed to generate a unicast query out of PTR query, which is NOT "*.in-addr.arpa" or "*.ip6.arpa"? Thus, the section should be amended to include only PTR queries that are actually constructed from full IP addresses? Other PTR queries need to go via normal UDP? --------------------------------------- .... 4. Conflict resolution .... - multiple hosts may respond to a query for an A or AAAA type record for a cluster name (assigned to multiple hosts in the cluster) - only a single host may respond to a query for an A or AAAA type record for a hostname. .... --------------------------------------- The "cluster name" semantics is unclear to. How does a sender that queries a name know whether the name is a "hostname" or "cluster name"? Two choices: a) it's implicitly a "cluster name", if multiple answers are received (e.g. there will never be any conflict from sender viewpoint). b) each host must be configured locally with the list of legal "cluster names", and sender only accepts multiple answers for these names. I assume (a) is intended? [BA] I agree that a unicast query should only be sent for PTR RR queries for fully formed IP addresses within *.in-addr.arpa or *.ipv6.arpa. And yes, I believe that a name is inherently a cluster name if multiple answers are received (so there is no conflict from the sender viewpoint). Of course from the responder viewpoint, it is 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 Thu Aug 14 03:04: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 DAA01996 for ; Thu, 14 Aug 2003 03:04:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19nC1d-000OtV-Jf for namedroppers-data@psg.com; Thu, 14 Aug 2003 06:55:57 +0000 Received: from [212.16.99.49] (helo=burp.tkv.asdf.org) by psg.com with esmtp (Exim 4.20) id 19nC1Z-000Ot7-8O for namedroppers@ops.ietf.org; Thu, 14 Aug 2003 06:55:53 +0000 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h7E6tk5Y011245; Thu, 14 Aug 2003 09:55:46 +0300 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-6.4) id h7E6tjDT011241; Thu, 14 Aug 2003 09:55:45 +0300 Date: Thu, 14 Aug 2003 09:55:45 +0300 Message-Id: <200308140655.h7E6tjDT011241@burp.tkv.asdf.org> From: Markku Savela To: aboba@internaut.com CC: namedroppers@ops.ietf.org In-reply-to: (message from Bernard Aboba on Wed, 13 Aug 2003 14:38:15 -0700 (PDT)) Subject: Re: Proposed Resolution to LLMNR Issue 43: PTR queries and cluster names References: X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,IN_REP_TO,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > From: Bernard Aboba > "b. The sender queries for the PTR RR of a fully formed > IP address within the "in-addr.arpa" or "ipv6.arpa" zones." You copied my typing error, should be "ip6.arpa" ? -- to unsubscribe send a message to namedroppers-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 Aug 15 00:47: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 AAA06214 for ; Fri, 15 Aug 2003 00:47:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19nWEO-000KPD-8h for namedroppers-data@psg.com; Fri, 15 Aug 2003 04:30:28 +0000 Received: from [209.116.252.130] (helo=one.elistx.com) by psg.com with esmtp (Exim 4.20) id 19nWDO-000KKj-19 for namedroppers@ops.ietf.org; Fri, 15 Aug 2003 04:30:22 +0000 Received: from ogud.com (pcp04400154pcs.nrockv01.md.comcast.net [69.140.166.204]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HJN00DJ58ID3R@eListX.com> for namedroppers@ops.ietf.org; Fri, 15 Aug 2003 00:30:14 -0400 (EDT) Received: from ENGILL.ogud.com (ns.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.8p1/8.12.8) with ESMTP id h7F4TTWE095496; Fri, 15 Aug 2003 00:29:30 -0400 (EDT envelope-from ogud@ogud.com) Date: Fri, 15 Aug 2003 00:27:55 -0400 From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: DNSSECbis Q-2: degradation attack In-reply-to: X-Sender: post@localhost To: Sam Weiler , namedroppers@ops.ietf.org Message-id: <5.1.1.6.2.20030814233139.0169ef58@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=us-ascii References: <20030813101218.18d5417d.olaf@ripe.net> <20030813101218.18d5417d.olaf@ripe.net> X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 12:36 2003-08-13, Sam Weiler wrote: >This grew out of Q2 discussions (re: moving DSA to optional). I like >the idea of moving DSA to optional (it's a weak liking -- I don't >care that much), but we need to address the following first: > >A degradation attack is possible when multiple algorithms appear in an >apex DNSKEYset and/or DSset. If not fixed, this attack will make new >(or optional) algorithms undeployable. First, the proposed change >that avoids the attack: > > Every RRset MUST be signed by at least one DNSKEY of each algorithm > in the DSset and each additional algorithm, if any, in the apex > DNSKEYset. The apex DNSKEYset itself must be signed by each > algorithm appearing in the zone's DSset. IMHO this is an overkill and is restricting operation too much. What this is saying is if there is more than one alg in DS set then every RRset MUST be signed by all the algorithms at all times. How is this to be enforced ? We can not enforce this is in a signer, as someone may elect to implement algorithm independent signers. Should the master server can refuse to load zone that violates this for a single RRset? (Current protocol document does not say what to do if a master server sees an unsigned RRset in a secure zone). The basic premise for DNSSEC has been: if validator can verify RRset against ONE temporarily valid RRset signature it may to mark the RRest as secure. A paranoid validator should validate ALL available valid signatures before marking the set secure. I do not think it the protocol document role to dictate one or the other behavior. IFF we want to dictate behavior there are many other cases that need to be nailed down. >And the implications for a validator: > > 1) If the only algorithms in a DSset aren't ones you understand, > you may treat the zone as unsigned (as things are now). > > 2) If there are algorithms you grok in the DSset, but the only > algorithms signing the DNSKEYset are ones you don't understand, you > should assume something bad is happening. (this is a change) > > 3) And if there are algorithms you grok in the DSset and DNSKEYset, > but the only signatures on some RRset are made with algorithms you > don't understand, you should assume something bad is happening > (this is a change). > >This change is based on the premise that the failure mode when "I >don't grok your algorithm(s)" may be different from the "this RRset >looks like it should be signed, but I haven't gotten a good RRSIG" >failure mode. In the former case, current code may treat the zone as >unsigned and keep giving answers. In the latter, current code >(generally) won't return an answer. > >The Problem: > > As currently specified, it's sufficient for an RRset to be signed > by any of the zone's apex DNSKEYs. There's no way for a validator > to tell which DNSKEYs the zone used (or intended to use) to sign a > given RRset. > > If a zone includes an optional algorithm in its apex DNSKEYset, > then signs some RRs with only that algorithm, a validator can't > tell whether or not it's supposed to be getting other RRSIGs or > not. For example, a zone with a type 5 DNSKEY (RSA/SHA-1) and a > type 42 DNSKEY (CryptSam, yet to be specified) might choose to sign > its DNSKEYset with the type 5 DNSKEY and everything else with the > type 42 DNSKEY. In that case, you'd want a validator that doesn't > understand type 42 to do something gentle, such as treating the > zone as unsigned. See RFC3090 sections 2.1 and 2.2. If validator understands type 42 it may elect to use it. IFF some RRset is only signed with type 42 then any validator that does not understand/use that type, will drop this RRset as bad, this is the publishers choice. Unfortunately in 2535 there is no way for validator to detect if this is by choice or some of the RRSIG's where stripped from the answer. Your text attempts to differentiate between the cases, but I think the solution is worse than the problem. > The problem is that an attacker can strip RRSIGs. Assume, in the > example above, that the zone owner signed the whole zone with BOTH > DNSKEYs. That would let well-behaved clients, absent an attack, > validate the data. according to DNS-Threats document if an attacker can do this, all bets are off for DNSSEC, thus this is not a justification for a change. > But an attacker, knowing that type 42 DNSKEYs aren't widely > supported, could forge answers in the zone and forge type 42 RRSIGs > (with random data), knowing that virtually no one would be able to > validate those signatures. There's no way for most validators to > tell the difference between this case and the "I only signed with > type 42" case above. Hence, adding a DNSKEY of a non-mandatory > type to your apex DNSKEYset opens the door to a degradation attack. > Validator can attempt to get a SIG(0)/TSIG signed answer from Authorative server to detect this. > The same problem exists in the DS-->DNSKEYset security chain. If a > parent adds a DS record of an optional type, the attacker can forge > a DNSKEYset signed by only the optional algorithm type that appears > in the DSset. A liberal validator, assuming that an RRSIG made by > any of the DS's is sufficient, will treat the zone as unsigned. > (Presumably the attacker would want the forged DNSKEYset to include > the real DNSKEY of the optional algorithm, since any validator can > at least check to see if there's a DNSKEY corresponding to one of > the DS RRs and that at least one of the signatures on the DNSKEYset > purports to have been made by a DNSKEY of the same tag.) If attacker can do this, it is simpler for him to flip bits in RRsigs to make zone date look bogus. > Both of these problems give zone owners a strong incentive to not > add optional algorithms. Identifying the problems is a good thing >The Fix: > > In broad terms, we need to add a mechanism that says "you can > expect this RRset to be signed by these algorithms". Rather than > specify a new (or per-RRset) mechanism, this fix assigns some > additional semantics to existing data. Specifically, "if the > algorithm is in the DNSKEYset, you have to sign everything with > it". This avoids making any bits-on-the-wire protocol changes. > > And for the DSset, the rule looks like "if an algorithm is in the > DSset, it has to be used to sign the DNSKEYset (hence it has to be > in the DNSKEYset, hence it has to sign the whole zone)". Again, > these are all client (and signer) behavior changes. Authoritative > servers don't change, and bits on the wire don't change. > > This isn't to say that each key in the DNSKEYset or each key > corresponding to a DS must be used, just that every algorithm must > be used. > > Furthermore, a validator should accept ANY valid signature chain, > even if it doesn't get RRSIGs of all algorithms types or if some > RRSIGs fail to validate. A validator may ignore an algorithm, > perhaps because that algorithm is weak, in which case it may make > its validation decision as though the algorithm is completely > unknown to it. For example, if the only DS records at a delegation > are for such an algorithm, the validator probably treats the > delegation as unsecured. > I repeat, IMHO the fix proposed is worse than the problem. Can you demonstrate a need for this change where attacker can succeed without gaining access to an Authorative server or see the query ? After I figure out the private part of the SEP key for the NL. TLD, what can I do ? How can I spread a bogus DS set for minbuza.nl ? 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 Aug 15 03:12: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 DAA20269 for ; Fri, 15 Aug 2003 03:12:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19nYYh-0002vO-HW for namedroppers-data@psg.com; Fri, 15 Aug 2003 06:59:35 +0000 Received: from [195.169.222.38] (helo=elektron.atoom.net) by psg.com with esmtp (Exim 4.20) id 19nYYe-0002vC-6J for namedroppers@ops.ietf.org; Fri, 15 Aug 2003 06:59:32 +0000 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.9/8.12.9/Debian-5) with ESMTP id h7F6xPRQ004687; Fri, 15 Aug 2003 08:59:25 +0200 Received: (from miekg@localhost) by elektron.atoom.net (8.12.9/8.12.9/Debian-5) id h7F6xOBo004683; Fri, 15 Aug 2003 08:59:24 +0200 Date: Fri, 15 Aug 2003 08:59:24 +0200 From: Miek Gieben To: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= Cc: Sam Weiler , namedroppers@ops.ietf.org Subject: Re: DNSSECbis Q-2: degradation attack Message-ID: <20030815065924.GA4324@atoom.net> Mail-Followup-To: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= , Sam Weiler , namedroppers@ops.ietf.org References: <20030813101218.18d5417d.olaf@ripe.net> <20030813101218.18d5417d.olaf@ripe.net> <5.1.1.6.2.20030814233139.0169ef58@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.20030814233139.0169ef58@localhost> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new 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.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit I tend to agree with Ólafur here. Lesson to be learned from this: if you are connected to the Internet and thus are expected to be visited by "normal" resolvers that do not understand CryptSam you should not use that algorithm. But if you are on a closed enviroment with "special" resolvers that do understand CryptSam you are free to use it. IMHO this should be reworded and be put in a BCP (maybe in the key-handling draft Olaf and I are writing). grtz Miek [On 15 Aug, @06:27, Ólafur wrote in "Re: DNSSECbis Q-2: degradation ..."] > At 12:36 2003-08-13, Sam Weiler wrote: > >This grew out of Q2 discussions (re: moving DSA to optional). I like > >the idea of moving DSA to optional (it's a weak liking -- I don't > >care that much), but we need to address the following first: > > > >A degradation attack is possible when multiple algorithms appear in an > >apex DNSKEYset and/or DSset. If not fixed, this attack will make new > >(or optional) algorithms undeployable. First, the proposed change > >that avoids the attack: > > > > Every RRset MUST be signed by at least one DNSKEY of each algorithm > > in the DSset and each additional algorithm, if any, in the apex > > DNSKEYset. The apex DNSKEYset itself must be signed by each > > algorithm appearing in the zone's DSset. > > IMHO this is an overkill and is restricting operation too much. > What this is saying is if there is more than one alg in DS set then > every RRset MUST be signed by all the algorithms at all times. > How is this to be enforced ? > We can not enforce this is in a signer, as someone may elect to implement > algorithm independent signers. > Should the master server can refuse to load zone that violates this > for a single RRset? > (Current protocol document does not say what to do if a master server > sees an unsigned RRset in a secure zone). > > The basic premise for DNSSEC has been: if validator can verify RRset > against ONE temporarily valid RRset signature it may to mark the > RRest as secure. A paranoid validator should validate ALL available valid > signatures before marking the set secure. > I do not think it the protocol document role to dictate one or the > other behavior. IFF we want to dictate behavior there are > many other cases that need to be nailed down. > -- to unsubscribe send a message to namedroppers-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 Aug 15 13:13: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 NAA05104 for ; Fri, 15 Aug 2003 13:13:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19nhqW-000C5m-NO for namedroppers-data@psg.com; Fri, 15 Aug 2003 16:54:36 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.20) id 19nhqS-000C5a-Kk for namedroppers@ops.ietf.org; Fri, 15 Aug 2003 16:54:32 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 152815684A; Fri, 15 Aug 2003 09:54:31 -0700 (PDT) Message-Id: <6.0.0.14.2.20030815121652.035be698@localhost> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.14 (Beta) Date: Fri, 15 Aug 2003 12:54:31 -0400 To: Sam Weiler , namedroppers@ops.ietf.org From: Mike StJohns Subject: Re: DNSSECbis Q-2: degradation attack In-Reply-To: References: <20030813101218.18d5417d.olaf@ripe.net> <20030813101218.18d5417d.olaf@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I had to think about this for a while and the read the other responses, so consider this a response to the chain, not just to Sam's email. I will note that this ends up being more of a DNS ops type of discussion, rather than a protocol discussion. Actually, this goes back to a previous thread about SEP keys and SEP bits. I think the appropriate logic (and this was related to the discussion on secure notify as well as some other discussions) is that The apex key set SHOULD be signed with all apex KEYs that have the SEP bit set. An apex key signature set is considered incomplete if it is missing SIGs against all apex SEP KEYS. [Rationale: If you have SEP keys at the apex that don't sign the apex KEY set, then they are extraneous material so why include them. OPS - although it may turn into a protocol issue if secure notify goes through] A DSSet SHOULD be signed at least once with every algorithm that appears in a SEP KEY. This implies that there must be at least one non-SEP KEY for every algorithm. [Rationale: If you don't do this, then you can end up terminating the chain of trust for that algorithm only. Its an operational determination though] That mostly takes care of the chaining issue. Its possible there will still be lame secure delegations where the parent doesn't sign things with all the algorithms in the child, but forcing the parent to have add a signing set because one of its children decided to try something new seems basically broken. E.g. I'm annoying.com, I sign my zone with DSA, RSA, classified algorithm 1, classified algorithm 2, proprietary sig algorithm 23, etc. My parent may not even be able to know the algorithm for forming a particular signature (classified alg 1), let alone being able to do it - correct software, licence fees paid, etc. This is simply an expansion of the island of trust discussion. Hmm... one more possibility - Say you have zone foo.com. In the foo.com zone exists a bar.foo.com branch. There is a delegation from that branch of bim.bar.foo.com. Does the bim.bar.foo.com SIG(DS(bim.bar.foo.com)) at the parent have a signer name of bar.foo.com or foo.com? If the former, then bar.foo.com needs its own keyset with at least one of each algorithm. But based on 3008 et al, I think the latter is correct these days. Mike At 12:36 8/13/2003, Sam Weiler wrote: >This grew out of Q2 discussions (re: moving DSA to optional). I like >the idea of moving DSA to optional (it's a weak liking -- I don't >care that much), but we need to address the following first: > >A degradation attack is possible when multiple algorithms appear in an >apex DNSKEYset and/or DSset. If not fixed, this attack will make new >(or optional) algorithms undeployable. First, the proposed change >that avoids the attack: > > Every RRset MUST be signed by at least one DNSKEY of each algorithm > in the DSset and each additional algorithm, if any, in the apex > DNSKEYset. The apex DNSKEYset itself must be signed by each > algorithm appearing in the zone's DSset. > >And the implications for a validator: > > 1) If the only algorithms in a DSset aren't ones you understand, > you may treat the zone as unsigned (as things are now). > > 2) If there are algorithms you grok in the DSset, but the only > algorithms signing the DNSKEYset are ones you don't understand, you > should assume something bad is happening. (this is a change) > > 3) And if there are algorithms you grok in the DSset and DNSKEYset, > but the only signatures on some RRset are made with algorithms you > don't understand, you should assume something bad is happening > (this is a change). > >This change is based on the premise that the failure mode when "I >don't grok your algorithm(s)" may be different from the "this RRset >looks like it should be signed, but I haven't gotten a good RRSIG" >failure mode. In the former case, current code may treat the zone as >unsigned and keep giving answers. In the latter, current code >(generally) won't return an answer. > >The Problem: > > As currently specified, it's sufficient for an RRset to be signed > by any of the zone's apex DNSKEYs. There's no way for a validator > to tell which DNSKEYs the zone used (or intended to use) to sign a > given RRset. > > If a zone includes an optional algorithm in its apex DNSKEYset, > then signs some RRs with only that algorithm, a validator can't > tell whether or not it's supposed to be getting other RRSIGs or > not. For example, a zone with a type 5 DNSKEY (RSA/SHA-1) and a > type 42 DNSKEY (CryptSam, yet to be specified) might choose to sign > its DNSKEYset with the type 5 DNSKEY and everything else with the > type 42 DNSKEY. In that case, you'd want a validator that doesn't > understand type 42 to do something gentle, such as treating the > zone as unsigned. > > The problem is that an attacker can strip RRSIGs. Assume, in the > example above, that the zone owner signed the whole zone with BOTH > DNSKEYs. That would let well-behaved clients, absent an attack, > validate the data. > > But an attacker, knowing that type 42 DNSKEYs aren't widely > supported, could forge answers in the zone and forge type 42 RRSIGs > (with random data), knowing that virtually no one would be able to > validate those signatures. There's no way for most validators to > tell the difference between this case and the "I only signed with > type 42" case above. Hence, adding a DNSKEY of a non-mandatory > type to your apex DNSKEYset opens the door to a degradation attack. > > The same problem exists in the DS-->DNSKEYset security chain. If a > parent adds a DS record of an optional type, the attacker can forge > a DNSKEYset signed by only the optional algorithm type that appears > in the DSset. A liberal validator, assuming that an RRSIG made by > any of the DS's is sufficient, will treat the zone as unsigned. > (Presumably the attacker would want the forged DNSKEYset to include > the real DNSKEY of the optional algorithm, since any validator can > at least check to see if there's a DNSKEY corresponding to one of > the DS RRs and that at least one of the signatures on the DNSKEYset > purports to have been made by a DNSKEY of the same tag.) > > Both of these problems give zone owners a strong incentive to not > add optional algorithms. > >The Fix: > > In broad terms, we need to add a mechanism that says "you can > expect this RRset to be signed by these algorithms". Rather than > specify a new (or per-RRset) mechanism, this fix assigns some > additional semantics to existing data. Specifically, "if the > algorithm is in the DNSKEYset, you have to sign everything with > it". This avoids making any bits-on-the-wire protocol changes. > > And for the DSset, the rule looks like "if an algorithm is in the > DSset, it has to be used to sign the DNSKEYset (hence it has to be > in the DNSKEYset, hence it has to sign the whole zone)". Again, > these are all client (and signer) behavior changes. Authoritative > servers don't change, and bits on the wire don't change. > > This isn't to say that each key in the DNSKEYset or each key > corresponding to a DS must be used, just that every algorithm must > be used. > > Furthermore, a validator should accept ANY valid signature chain, > even if it doesn't get RRSIGs of all algorithms types or if some > RRSIGs fail to validate. A validator may ignore an algorithm, > perhaps because that algorithm is weak, in which case it may make > its validation decision as though the algorithm is completely > unknown to it. For example, if the only DS records at a delegation > are for such an algorithm, the validator probably treats the > delegation as unsecured. > > > > >-- >to 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 Aug 16 22:15: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 WAA22609 for ; Sat, 16 Aug 2003 22:15:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19oCrS-000BN5-H1 for namedroppers-data@psg.com; Sun, 17 Aug 2003 02:01:38 +0000 Received: from [195.169.222.38] (helo=elektron.atoom.net) by psg.com with esmtp (Exim 4.20) id 19oCrO-000BMn-5a for namedroppers@ops.ietf.org; Sun, 17 Aug 2003 02:01:34 +0000 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.9/8.12.9/Debian-5) with ESMTP id h7H21T92021095; Sun, 17 Aug 2003 04:01:29 +0200 Received: (from miekg@localhost) by elektron.atoom.net (8.12.9/8.12.9/Debian-5) id h7H21SIJ021093; Sun, 17 Aug 2003 04:01:28 +0200 Date: Sun, 17 Aug 2003 04:01:28 +0200 From: Miek Gieben To: Mike StJohns Cc: Sam Weiler , namedroppers@ops.ietf.org Subject: Re: DNSSECbis Q-2: degradation attack Message-ID: <20030817020128.GA20956@atoom.net> Mail-Followup-To: Mike StJohns , Sam Weiler , namedroppers@ops.ietf.org References: <20030813101218.18d5417d.olaf@ripe.net> <20030813101218.18d5417d.olaf@ripe.net> <6.0.0.14.2.20030815121652.035be698@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.14.2.20030815121652.035be698@localhost> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=-15.5 required=5.0 tests=BAYES_10,IN_REP_TO,REFERENCES,USER_AGENT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I believe that stuff like this should be treated like an operational issue first. Make a BCP with all the DNSSEC's does and don'ts. If it really turns out to be a protocol issue - so be it, it can never be as bad as DS :P 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 Sun Aug 17 22:45: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 WAA26533 for ; Sun, 17 Aug 2003 22:44:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19oZpP-000Ekm-FP for namedroppers-data@psg.com; Mon, 18 Aug 2003 02:33:03 +0000 Received: from [192.149.252.33] (helo=smtp1.arin.net) by psg.com with esmtp (Exim 4.20) id 19oZpL-000Eka-Vq for namedroppers@ops.ietf.org; Mon, 18 Aug 2003 02:33:00 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 77F0D394; Sun, 17 Aug 2003 22:32:59 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id F272131A; Sun, 17 Aug 2003 22:32:58 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1) with ESMTP id 565117; Sun, 17 Aug 2003 22:31:21 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <20030817020128.GA20956@atoom.net> References: <20030813101218.18d5417d.olaf@ripe.net> <20030813101218.18d5417d.olaf@ripe.net> <6.0.0.14.2.20030815121652.035be698@localhost> <20030817020128.GA20956@atoom.net> Date: Sun, 17 Aug 2003 22:32:52 -0400 To: Miek Gieben From: Edward Lewis Subject: Re: DNSSECbis Q-2: degradation attack Cc: Mike StJohns , Sam Weiler , namedroppers@ops.ietf.org 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.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 4:01 +0200 8/17/03, Miek Gieben wrote: >If it really turns out to be a protocol issue - so be it, it can never be as >bad as DS :P I think it is a protocol issue from this perspective. DNSSEC has always been about protecting the resolver. The data exchanged in the protocol interaction is designed to allow the resolver to put the pieces together and say "yeah, I like this" or "umm, something's not right." DNSSEC doesn't protect the server so much - DNSSEC's data exchanges do not over come so-called denial of service issues. In the situation we are talking about, let's assume that a resolver has received an apex's key set with keys in it that the resolver understands (as well as the DS set and all needed "above"). Let's assume that there are keys the resolver doesn't understand too. The protocol document says that only one signature is required for each set of data in the zone. It says nothing else about the signature. The server might 1) sign the data with all algorithms or 2) sign the sets with just the algorithm the resolver doesn't understand. Let's say the resolver gets a data set with only a signature from the algorithm it doesn't know. In case 1, this means something was stripped. In case 2, the data arrived safely. The problem is that the resolver can't determine (it's undecidable) whether case 1 is the cause - and the data is fine, or case 2 is in effect - and the data has been mucked with. If I consider example.com to be secured, I expect and can get the DS set for sub.example.com. From that I can see whether sub.example.com uses keys I understand. If so, I troddle on securely, if not, I *could* troddle on as it there was no DS set. What's lacking is a way to "turn off" security inside a zone - not desirable with just one algorithm. But, when it comes to multiple algorithms and requiring just one signature, we are inviting zones to "turn off" security "per algorithm" in a zone. We shouldn't make the invite. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Sponge Bob Square Pants? I'm still trying to figure out the Macarena. -- to unsubscribe send a message to namedroppers-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 Aug 18 06:30: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 GAA15115 for ; Mon, 18 Aug 2003 06:30:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19ohA8-000Lg4-0G for namedroppers-data@psg.com; Mon, 18 Aug 2003 10:22:56 +0000 Received: from [193.0.1.96] (helo=birch.ripe.net) by psg.com with esmtp (Exim 4.20) id 19ohA4-000Lfq-1j for namedroppers@ops.ietf.org; Mon, 18 Aug 2003 10:22:52 +0000 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 h7IAMn3j023265 for ; Mon, 18 Aug 2003 12:22:49 +0200 Date: Mon, 18 Aug 2003 12:22:48 +0200 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: Re: DNSSECbis Q-2: degradation attack Message-Id: <20030818122248.429096f6.olaf@ripe.net> In-Reply-To: References: <20030813101218.18d5417d.olaf@ripe.net> <20030813101218.18d5417d.olaf@ripe.net> <6.0.0.14.2.20030815121652.035be698@localhost> <20030817020128.GA20956@atoom.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.0 (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=-11.3 required=5.0 tests=BAYES_30,IN_REP_TO,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I have been hesitating to participate in this thread for the following reason: I am not convinced if this _must_ be solved in order for DNSSEC to become a proposed standard. There is a operational way to cope with a change in algorithm if needed. I realize it involves becoming insecure. The last thing DNSSEC needs is yet another delay and solving problem will take time! So lets first ask ourselves the question: Does this need fixing now ? I am not yet convinced this needs fixing now; pointing to this issue in the protocol doc security section may be sufficient. What do others think? ------------------- I still can not help thinking about a possible way out so here is my contribution (I fear I am overlooking something and I miss the sparring partner to go over this, so bare with me if I am uttering nonsense). The problem as I read it from Mike's and Ed's message, is that one wants to turn the use of specific algorithms within a zone on or of, without imposing requirements on the algorithm used by the parent (and having the parent impose algorithms on the child). The scheme below does not require the algorithms of the parent and child to match. Besides one can use the keys without the SEP bit to turn specific algorithms on or off; making the it decidable which algorithms to expect. The solution boils down to enforcing the use of a distinct set of key signing keys and zone signing keys, use the SEP key to distinguish between them. Signer requirements: 1) the apex DNSKEY set MUST only be signed with keys that have the SEP bit on. All other RR-sets in the zone MUST be signed with keys that do not have the SEP bit set. 2) For each algorithm occurring for keys with the SEP bit set there MUST be one signature over the DNSSKEY set and for each algorithm for keys without the SEP bit set there MUST be one signature over each RR-set in the zone. Note: Except that there MUST be a matching DNSKEY in the apex for each DS RR there is no additional requirement with respect to the DS RR set. The Verifier requirements is that this behavior is verified as long as data is supposed to be secure. This needs proper word-smithing in MUST/SHOULD/MAY language, but this is the algorithm I am thinking of: Following the chain of trust from a trusted root down. - For each algorithm that you expect verify if the DNSKEY RR-set is properly signed with at least one key with the SEP bit set. You expect an algorithm if you have configured it in your trusted root or if it is a result from following the chain of trust. You now know you can trust the DNSKEY RR-set to be complete. - See which algorithms are available in the sub set of keys in the DNSKEY RR-set that do not have the SEP bit set. If you understand an algorithm, you expect signatures over zone data to be generated with it. If you do not understand any of the signatures you may, depending on local policy, treat the zone as verifiably insecure. At delegation points. - Verify if the DS RR-set is signed with all the algorithms you expect. You now know you can trust the DS RR-set to be complete. - See which algorithms are available in the DS RR-set and change the set of algorithms you expect to be the complete set of all algorithms you understand from the DS RR-set. If there are no algorithms you can deal with you may, depending again on local policy, treat the zone as verifiably insecure. - Follow the DS pointers for each of the algorithms you understand (i.e. expect) and iterate down the chain starting from the first step above. For end-nodes. - The data is secure if signed with all algorithms you expect. *sigh* Lets not discuss this further if there is no real need though. -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-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 Aug 18 10:32: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 KAA20982 for ; Mon, 18 Aug 2003 10:32:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19okv8-000IOx-21 for namedroppers-data@psg.com; Mon, 18 Aug 2003 14:23:42 +0000 Received: from [129.6.16.93] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.20) id 19okuy-000INW-AS for namedroppers@ops.ietf.org; Mon, 18 Aug 2003 14:23:37 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h7IENQt9026149 for ; Mon, 18 Aug 2003 10:23:26 -0400 (EDT) Message-ID: <006501c36594$4adc69b0$b9370681@barnacle> From: "Scott Rose" To: References: <20030813101218.18d5417d.olaf@ripe.net> <20030813101218.18d5417d.olaf@ripe.net> <6.0.0.14.2.20030815121652.035be698@localhost> <20030817020128.GA20956@atoom.net> Subject: Re: DNSSECbis Q-2: degradation attack Date: Mon, 18 Aug 2003 10:23:27 -0400 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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Also, since the attack and defense of this attack is based on the contents of a zone (that is, what constitutes a "signed zone") it should either be addressed in the protocol document (where signed/secure zones are discussed) or in a BCP/policy guide. Depends on how big of a threat a degradation attack is assumed to be. If it is a severe risk, than the protocol document, if not, a BCP or some other implementation guideline. Scott ----- Original Message ----- From: "Edward Lewis" To: "Miek Gieben" Cc: "Mike StJohns" ; "Sam Weiler" ; Sent: Sunday, August 17, 2003 10:32 PM Subject: Re: DNSSECbis Q-2: degradation attack > At 4:01 +0200 8/17/03, Miek Gieben wrote: > >If it really turns out to be a protocol issue - so be it, it can never be as > >bad as DS :P > > I think it is a protocol issue from this perspective. > > DNSSEC has always been about protecting the resolver. The data > exchanged in the protocol interaction is designed to allow the > resolver to put the pieces together and say "yeah, I like this" or > "umm, something's not right." > > DNSSEC doesn't protect the server so much - DNSSEC's data exchanges > do not over come so-called denial of service issues. > > In the situation we are talking about, let's assume that a resolver > has received an apex's key set with keys in it that the resolver > understands (as well as the DS set and all needed "above"). Let's > assume that there are keys the resolver doesn't understand too. > > The protocol document says that only one signature is required for > each set of data in the zone. It says nothing else about the > signature. > > The server might 1) sign the data with all algorithms or 2) sign the > sets with just the algorithm the resolver doesn't understand. > > Let's say the resolver gets a data set with only a signature from the > algorithm it doesn't know. In case 1, this means something was > stripped. In case 2, the data arrived safely. > > The problem is that the resolver can't determine (it's undecidable) > whether case 1 is the cause - and the data is fine, or case 2 is in > effect - and the data has been mucked with. > > If I consider example.com to be secured, I expect and can get the DS > set for sub.example.com. From that I can see whether sub.example.com > uses keys I understand. If so, I troddle on securely, if not, I > *could* troddle on as it there was no DS set. > > What's lacking is a way to "turn off" security inside a zone - not > desirable with just one algorithm. But, when it comes to multiple > algorithms and requiring just one signature, we are inviting zones to > "turn off" security "per algorithm" in a zone. We shouldn't make the > invite. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer > > Sponge Bob Square Pants? I'm still trying to figure out the Macarena. > > -- > to 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 Aug 18 14:05: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 OAA27746 for ; Mon, 18 Aug 2003 14:05:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19ooIX-0004X2-Tj for namedroppers-data@psg.com; Mon, 18 Aug 2003 18:00:05 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.20) id 19ooIS-0004W7-Uc for namedroppers@ops.ietf.org; Mon, 18 Aug 2003 18:00:00 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 8E62C13988 for ; Mon, 18 Aug 2003 18:00:00 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: DNSSECbis Q-2: degradation attack In-Reply-To: Message from "Olaf M. Kolkman" of "Mon, 18 Aug 2003 12:22:48 +0200." <20030818122248.429096f6.olaf@ripe.net> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 18 Aug 2003 18:00:00 +0000 Message-Id: <20030818180000.8E62C13988@sa.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.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I am not yet convinced this needs fixing now; pointing to this > issue in the protocol doc security section may be sufficient. What > do others think? i think that if we're not going to specify an alg rollover process, or the interaction when parents/children/resolvers only share a subset of algs, then we should remove the algid field and just laminate RSA for all time and assume that we will change port numbers if RSA is cracked. to that end, i would be an objector during WGLC if this isn't resolved. -- to unsubscribe send a message to namedroppers-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 Aug 19 13: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 NAA24370 for ; Tue, 19 Aug 2003 13:20:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19p9y9-000Bam-A0 for namedroppers-data@psg.com; Tue, 19 Aug 2003 17:08:29 +0000 Received: from [209.116.252.130] (helo=one.elistx.com) by psg.com with esmtp (Exim 4.20) id 19p9y5-000BaU-6Z for namedroppers@ops.ietf.org; Tue, 19 Aug 2003 17:08:25 +0000 Received: from ogud.com (pcp04400154pcs.nrockv01.md.comcast.net [69.140.166.204]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HJV00LAGMCUBR@eListX.com> for namedroppers@ops.ietf.org; Tue, 19 Aug 2003 13:10:06 -0400 (EDT) Received: from ENGILL.ogud.com (ns.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.8p1/8.12.8) with ESMTP id h7JH8kWE029162 for ; Tue, 19 Aug 2003 13:08:47 -0400 (EDT envelope-from ogud@ogud.com) Date: Tue, 19 Aug 2003 13:04:32 -0400 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: DNSEXT WGLC Summary: DNS Threats X-Sender: (Unverified) To: namedroppers@ops.ietf.org Message-id: <5.1.1.6.2.20030819130408.01f92a90@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=-1.6 required=5.0 tests=BAYES_30 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The Working group last call has completed. There is consensus to advance this document with minor modifications. Editors has updated the document to reflect all comments received. The chairs will forward this document to the IESG next week. Olafur & 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 Tue Aug 19 14:01: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 OAA26577 for ; Tue, 19 Aug 2003 14:01:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19pAh3-000GJW-6M for namedroppers-data@psg.com; Tue, 19 Aug 2003 17:54:53 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.20) id 19pAgy-000GJ1-82 for namedroppers@ops.ietf.org; Tue, 19 Aug 2003 17:54:48 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 301565681D for ; Tue, 19 Aug 2003 10:54:47 -0700 (PDT) Message-Id: <6.0.0.14.2.20030819132716.036ab008@localhost> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.14 (Beta) Date: Tue, 19 Aug 2003 13:54:44 -0400 To: namedroppers@ops.ietf.org From: Mike StJohns Subject: Re: DNSSECbis Q-2: degradation attack In-Reply-To: <20030818180000.8E62C13988@sa.vix.com> References: <20030818122248.429096f6.olaf@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-26.0 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 14:00 8/18/2003, Paul Vixie wrote: > > I am not yet convinced this needs fixing now; pointing to this > > issue in the protocol doc security section may be sufficient. What > > do others think? > >i think that if we're not going to specify an alg rollover process, or >the interaction when parents/children/resolvers only share a subset of >algs, Actually, at a minimum, the interaction should be specified. That's a protocol question. What probably can't be mandated is the actual contents of the zone. I *think* the current language in describing the resolution process actually does the right thing - but it would probably be better to explicitly address the issues Sam raised? Add a section 4.3 to draft-ietf-dnsext-dnssec-protocol describing the case where you have a broken chain due to the inability to verify because you don't understand a particular algorithm. The more I think about this, the less I'm inclined to believe its going to be a real problem given the current mechanisms. The resolver either understands or doesn't understand an algorithm If it understands it, it either trusts it or rejects it. (rejects it because its considered broken for ex) If it trusts it, it will follow a chain signed by it, otherwise it won't. the resolver may also impose certain minimums on things like key length to determine trust/reject? >then we should remove the algid field and just laminate RSA for >all time and assume that we will change port numbers if RSA is cracked. > >to that end, i would be an objector during WGLC if this isn't resolved. > >-- >to 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 Aug 19 23:18: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 XAA23344 for ; Tue, 19 Aug 2003 23:18:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19pJHc-000GHC-PM for namedroppers-data@psg.com; Wed, 20 Aug 2003 03:05:12 +0000 Received: from [209.116.252.130] (helo=one.elistx.com) by psg.com with esmtp (Exim 4.20) id 19pJHZ-000GGb-9X for namedroppers@ops.ietf.org; Wed, 20 Aug 2003 03:05:09 +0000 Received: from ogud.com (pcp04400154pcs.nrockv01.md.comcast.net [69.140.166.204]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HJW0004XDZFSV@eListX.com> for namedroppers@ops.ietf.org; Tue, 19 Aug 2003 23:06:52 -0400 (EDT) Received: from ENGILL.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.8p1/8.12.8) with ESMTP id h7K35RWE030520; Tue, 19 Aug 2003 23:05:27 -0400 (EDT envelope-from ogud@ogud.com) Date: Tue, 19 Aug 2003 23:04:27 -0400 From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: DNSEXT WGLC for LLMNR In-reply-to: <5.1.1.6.2.20030804100523.0161cfe0@localhost> X-Sender: post@localhost To: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair , namedroppers@ops.ietf.org Message-id: <5.1.1.6.2.20030819230233.0296c690@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Just a reminder this is an ongoing WG last call But I forgot to put an explicit deadline on this one so the deadline is August 25'th (that will make it 3 week last call). Olafur At 10:23 2003-08-04, =D3lafur Gudmundsson/DNSEXT co-chair wrote: >This is a last call for the DNSEXT document > Linklocal Multicast Name Resolution (LLMNR) >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-22.txt > >This document defines a new protocol that operates on a local link where >there to enable name resolution. This protocol inherits DNS wire >formats but operates on a different port and different transport. > >This protocol has been thorough many changes in the last 6 months to >make it cleaner, simpler and to avoid it becoming a possible DoS amplifier. >For a listing of previously proposed and resolved issues, see the LLMNR=20 >Issues web page, available at: >http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html > >Please read the document, send in statements of=20 >support/opposition/clarifications/etc. >This protocol is on standards track, if you disagree with that >please speak up. > >If there is no discussion about this document the default action by >chairs is to advance it as that seems to be the recommendation of the >people that have commented on this document over the last one year. > > Olafur > > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >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 Aug 19 23:47: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 XAA24269 for ; Tue, 19 Aug 2003 23:47:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19pJo0-000K0C-Ru for namedroppers-data@psg.com; Wed, 20 Aug 2003 03:38:40 +0000 Received: from [209.116.252.130] (helo=one.elistx.com) by psg.com with esmtp (Exim 4.20) id 19pJnx-000Jzo-Lz for namedroppers@ops.ietf.org; Wed, 20 Aug 2003 03:38:37 +0000 Received: from ogud.com (pcp04400154pcs.nrockv01.md.comcast.net [69.140.166.204]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HJW00510FJ8AS@eListX.com> for namedroppers@ops.ietf.org; Tue, 19 Aug 2003 23:40:20 -0400 (EDT) Received: from ENGILL.ogud.com (ns.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.8p1/8.12.8) with ESMTP id h7K3cuWE030592 for ; Tue, 19 Aug 2003 23:38:56 -0400 (EDT envelope-from ogud@ogud.com) Date: Tue, 19 Aug 2003 23:37:35 -0400 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: DNSEXT WGLC Summary: Key-Signing Key (KSK) Flag X-Sender: (Unverified) To: namedroppers@ops.ietf.org Message-id: <5.1.1.6.2.20030819232734.02c095f0@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=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This working group last call has concluded. The consensus of the working group was that this was important work but needed some modifications. The authors have updated the document and addressed all the issues. This consensus of the working group is to advance 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 Aug 20 00:04: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 AAA24745 for ; Wed, 20 Aug 2003 00:04:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19pK8J-000MbL-CA for namedroppers-data@psg.com; Wed, 20 Aug 2003 03:59:39 +0000 Received: from [209.116.252.130] (helo=one.elistx.com) by psg.com with esmtp (Exim 4.20) id 19pK8G-000MaC-M2 for namedroppers@ops.ietf.org; Wed, 20 Aug 2003 03:59:36 +0000 Received: from ogud.com (pcp04400154pcs.nrockv01.md.comcast.net [69.140.166.204]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HJW005FQGI73M@eListX.com> for namedroppers@ops.ietf.org; Wed, 20 Aug 2003 00:01:19 -0400 (EDT) Received: from ENGILL.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.8p1/8.12.8) with ESMTP id h7K3xtWE030637 for ; Tue, 19 Aug 2003 23:59:55 -0400 (EDT envelope-from ogud@ogud.com) Date: Tue, 19 Aug 2003 23:50:40 -0400 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: DNSEXT WGLC Summary: TKEY Renewal Mode-02 X-Sender: (Unverified) To: namedroppers@ops.ietf.org Message-id: <5.1.1.6.2.20030819234612.015ebd88@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=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The working group last call has concluded. The authors have issued a new draft that addresses all the issues raised during the last call. The consensus of the working group is to advance the document to Experimental status. The chair will forward the document to the IESG. 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 Aug 20 00:04: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 AAA24776 for ; Wed, 20 Aug 2003 00:04:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19pK8Q-000Mce-Rj for namedroppers-data@psg.com; Wed, 20 Aug 2003 03:59:46 +0000 Received: from [209.116.252.130] (helo=one.elistx.com) by psg.com with esmtp (Exim 4.20) id 19pK8G-000MaC-U1 for namedroppers@ops.ietf.org; Wed, 20 Aug 2003 03:59:37 +0000 Received: from ogud.com (pcp04400154pcs.nrockv01.md.comcast.net [69.140.166.204]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HJW005GFGI7AS@eListX.com> for namedroppers@ops.ietf.org; Wed, 20 Aug 2003 00:01:19 -0400 (EDT) Received: from ENGILL.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.8p1/8.12.8) with ESMTP id h7K3xtWG030637 for ; Tue, 19 Aug 2003 23:59:55 -0400 (EDT envelope-from ogud@ogud.com) Date: Tue, 19 Aug 2003 23:56:25 -0400 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: DNSEXT WGLC summary: IPv6 Name Auto Registration X-Sender: (Unverified) To: namedroppers@ops.ietf.org Message-id: <5.1.1.6.2.20030819235145.0173fd88@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=-5.8 required=5.0 tests=BAYES_10 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The working group last call has concluded. The last call was lively but did not result in a consensus. There were vocal opponents and supporters of this document, many raising excellent points (not all technical). At this point the DNSEXT working group will not recommend publication of this document as an RFC. 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 Aug 20 04:18: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 EAA28862 for ; Wed, 20 Aug 2003 04:18:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19pO0J-000OyD-MR for namedroppers-data@psg.com; Wed, 20 Aug 2003 08:07:39 +0000 Received: from [193.0.1.96] (helo=birch.ripe.net) by psg.com with esmtp (Exim 4.20) id 19pO0H-000OxX-3o for namedroppers@ops.ietf.org; Wed, 20 Aug 2003 08:07:37 +0000 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 h7K87Z3j002470 for ; Wed, 20 Aug 2003 10:07:35 +0200 Date: Wed, 20 Aug 2003 10:07:35 +0200 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: DNSEXT WGLC: Wildcard Clarify Message-Id: <20030820100735.39120ccd.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.0 (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=-5.8 required=5.0 tests=BAYES_10 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a last call for the 'Wildcard Clarify' document. Title: Clarifying the Role of Wild Card Domains in the Domain Name System URL: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-wcard-clarify-01.txt Please read the document, send in motivated statements of support, opposition, clarifications &c. This protocol is on standards track, if you disagree with that please speak up and motivate. The last call period is a little over 2 weeks and will conclude Sunday September 7, 2003. If there is no discussion about this document the default action by chairs is to advance it as the need for this document is clearly motivated by the authors and not opposed in recent discussion. -------------------- Abstract: The definition of wild cards is recast from the original in RFC 1034, in words that are more specific and in line with RFC 2119. This document is meant to supplement the definition in RFC 1034 and to alter neither the spirit nor intent of that definition. From the Introduction: Why is this document needed? Empirical evidence suggests that the words in RFC 1034 are not clear enough. There exist a number of implementations that have strayed (each differently) from that definition. There also exists a misconception of operators that the wild card can be used to add a specific RR type to all names, such as the MX RR example cited above. This document is also needed as input to efforts to extend DNS, such as the DNS Security Extensions [RFC 2535]. Lack of a clear base specification has proven to result in extension documents that have unpredictable consequences. (This is true in general, not just for DNS.) -------------------- -- Olaf DNSEXT Co-Chair -- to unsubscribe send a message to namedroppers-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 Aug 21 09:44: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 JAA05014 for ; Thu, 21 Aug 2003 09:44:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19ppW9-000MY4-GE for namedroppers-data@psg.com; Thu, 21 Aug 2003 13:30:21 +0000 Received: from [216.168.237.102] (helo=heron.verisign.com) by psg.com with esmtp (Exim 4.20) id 19ppVy-000MVN-Qw for namedroppers@ops.ietf.org; Thu, 21 Aug 2003 13:30:10 +0000 Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by heron.verisign.com (8.12.9/8.12.9) with ESMTP id h7LDVacf016802 for ; Thu, 21 Aug 2003 09:31:36 -0400 (EDT) Received: from chinook.rgy.netsol.com (host49-130-valks2.corppc.vrsn.com [10.131.130.49]) by VSVAPOSTALGW1.prod.netsol.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QNKZ9S0L; Thu, 21 Aug 2003 09:30:09 -0400 Received: by chinook.rgy.netsol.com (Postfix, from userid 500) id C1F849BE23; Thu, 21 Aug 2003 09:30:09 -0400 (EDT) Date: Thu, 21 Aug 2003 09:30:09 -0400 From: Matt Larson To: Namedroppers Mailing List Subject: DNSSECbis Q-16: Security-aware recursive name server behavior when CD=1 and DO=0 Message-ID: <20030821133009.GA17357@chinook.rgy.netsol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i X-Spam-Status: No, hits=-12.1 required=5.0 tests=BAYES_10,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This question corresponds to editors' note #14 from draft-ietf-dnsext-dnssec-protocol-01. (Note: DNSSECbis Q-15 incorrectly claimed to correspond to editors' note #14. Q-15 actually corresponds to editors' note #15.) Q-16: What should a security-aware recursive name server do if it receives a query with CD=1 and DO=0? Background: Here is the text in question from Section 4.1 (page 23) of draft-ietf-dnsext-dnssec-protocol-01: The name server side of a security-aware recursive name server MUST pass the sense of the CD bit to the resolver side along with the rest of an initiating query, so that the resolver side will know whether whether or not it is required to verify the response data it returns to the name server side. Suggested additional text: The sense of the CD bit is only considered when a query also has the DO bit set. A security-aware recursive name server MUST ignore the sense of the CD bit if the DO bit is not set. Please comment on the suggested text. -- to unsubscribe send a message to namedroppers-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 Aug 21 10:30: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 KAA07916 for ; Thu, 21 Aug 2003 10:30:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19pqMW-0005r5-Df for namedroppers-data@psg.com; Thu, 21 Aug 2003 14:24:28 +0000 Received: from [129.6.16.93] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.20) id 19pqMJ-0005qN-4k for namedroppers@ops.ietf.org; Thu, 21 Aug 2003 14:24:15 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h7LENpcR026137 for ; Thu, 21 Aug 2003 10:23:51 -0400 (EDT) Message-ID: <002401c367ef$d899d230$b9370681@barnacle> From: "Scott Rose" To: "Namedroppers Mailing List" References: <20030821133009.GA17357@chinook.rgy.netsol.com> Subject: Re: DNSSECbis Q-16: Security-aware recursive name server behavior when CD=1 and DO=0 Date: Thu, 21 Aug 2003 10:23:52 -0400 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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I'm for this text (big surprise, I know...) simply because it doesn't harm anything from the resolver point of view. If the resolver knows about EDNS, it probably knows some dnssec as well, and knows when it doesn't want to deal with it (DO=0). If the bits have been diddled in the process (attacker), the resolver/verifier will know something is amiss when the DNSSEC RRs are not returned, then it is up to local policy on how a suspected attack is handled. Scott ----- Original Message ----- From: "Matt Larson" To: "Namedroppers Mailing List" Sent: Thursday, August 21, 2003 9:30 AM Subject: DNSSECbis Q-16: Security-aware recursive name server behavior when CD=1 and DO=0 > This question corresponds to editors' note #14 from > draft-ietf-dnsext-dnssec-protocol-01. (Note: DNSSECbis Q-15 > incorrectly claimed to correspond to editors' note #14. Q-15 actually > corresponds to editors' note #15.) > > Q-16: What should a security-aware recursive name server do if it > receives a query with CD=1 and DO=0? > > Background: Here is the text in question from Section 4.1 (page 23) of > draft-ietf-dnsext-dnssec-protocol-01: > > The name server side of a security-aware recursive name server MUST > pass the sense of the CD bit to the resolver side along with the rest > of an initiating query, so that the resolver side will know whether > whether or not it is required to verify the response data it returns > to the name server side. > > Suggested additional text: > > The sense of the CD bit is only considered when a query also has > the DO bit set. A security-aware recursive name server MUST ignore > the sense of the CD bit if the DO bit is not set. > > Please comment on the suggested text. > > -- > to 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 Aug 21 21:29: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 VAA13160 for ; Thu, 21 Aug 2003 21:29:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19q0bq-0006bc-Lb for namedroppers-data@psg.com; Fri, 22 Aug 2003 01:20:58 +0000 Received: from [204.152.186.164] (helo=gusto.araneus.fi) by psg.com with esmtp (Exim 4.20) id 19q0bK-0006X1-80 for namedroppers@ops.ietf.org; Fri, 22 Aug 2003 01:20:26 +0000 Received: from guava.araneus.fi (adsl-63-197-0-204.dsl.snfc21.pacbell.net [63.197.0.204]) by gusto.araneus.fi (8.12.9/8.12.9) with ESMTP id h7M1J6h1024191; Thu, 21 Aug 2003 18:19:06 -0700 (PDT) Received: from guava.araneus.fi (localhost [127.0.0.1]) by guava.araneus.fi (8.12.9/8.11.6) with ESMTP id h7M1J7JN003913; Thu, 21 Aug 2003 18:19:07 -0700 (PDT) Received: (from gson@localhost) by guava.araneus.fi (8.12.9/8.12.6/Submit) id h7M1J4R2003910; Thu, 21 Aug 2003 18:19:04 -0700 (PDT) Date: Thu, 21 Aug 2003 18:19:04 -0700 (PDT) Message-Id: <200308220119.h7M1J4R2003910@guava.araneus.fi> To: Matt Larson Cc: Namedroppers Mailing List Subject: Re: DNSSECbis Q-16: Security-aware recursive name server behavior when CD=1 and DO=0 In-Reply-To: <20030821133009.GA17357@chinook.rgy.netsol.com> References: <20030821133009.GA17357@chinook.rgy.netsol.com> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=-36.2 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_RFCI,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_VM autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Matt Larson writes: > Suggested additional text: > > The sense of the CD bit is only considered when a query also has > the DO bit set. A security-aware recursive name server MUST ignore > the sense of the CD bit if the DO bit is not set. > > Please comment on the suggested text. What is the rationale for this change? -- 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 Fri Aug 22 10:16: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 KAA27128 for ; Fri, 22 Aug 2003 10:16:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19qCTy-000GDo-M3 for namedroppers-data@psg.com; Fri, 22 Aug 2003 14:01:38 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.20) id 19qCTR-000G62-Pv for namedroppers@ops.ietf.org; Fri, 22 Aug 2003 14:01:06 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24717; Fri, 22 Aug 2003 10:01:00 -0400 (EDT) Message-Id: <200308221401.KAA24717@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-ecc-key-04.txt Date: Fri, 22 Aug 2003 10:00:59 -0400 X-Spam-Status: No, hits=-2.7 required=5.0 tests=BAYES_10,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-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 : Elliptic Curve KEYs in the DNS Author(s) : R. Schroeppel, D. Eastlake Filename : draft-ietf-dnsext-ecc-key-04.txt Pages : 13 Date : 2003-8-22 A standard method for storing elliptic curve cryptographic keys in the Domain Name System is described. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ecc-key-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-ecc-key-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-ecc-key-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-22085940.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-ecc-key-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-ecc-key-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-22085940.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 Aug 22 10:40: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 KAA29971 for ; Fri, 22 Aug 2003 10:40:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19qCxo-000KgC-Gq for namedroppers-data@psg.com; Fri, 22 Aug 2003 14:32:28 +0000 Received: from [131.137.245.203] (helo=mx03.forces.gc.ca) by psg.com with esmtp (Exim 4.20) id 19qCv6-000KJf-4k for namedroppers@ops.ietf.org; Fri, 22 Aug 2003 14:29:40 +0000 Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx03.forces.gc.ca (DND-Mailer) with ESMTP id BD942206622 for ; Fri, 22 Aug 2003 10:24:42 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19qCUA-0004F7-DM for ietf-announce-list@asgard.ietf.org; Fri, 22 Aug 2003 10:01:50 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19qCTT-0003ww-5A for all-ietf@asgard.ietf.org; Fri, 22 Aug 2003 10:01:07 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24717; Fri, 22 Aug 2003 10:01:00 -0400 (EDT) Message-Id: <200308221401.KAA24717@ietf.org> 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-ecc-key-04.txt Date: Fri, 22 Aug 2003 10:00:59 -0400 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="MIMEStream=_0+150120_2095843096819_55366650988" X-Spam-Status: No, hits=-0.3 required=5.0 tests=BAYES_20,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --MIMEStream=_0+150120_2095843096819_55366650988 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Elliptic Curve KEYs in the DNS Author(s) : R. Schroeppel, D. Eastlake Filename : draft-ietf-dnsext-ecc-key-04.txt Pages : 13 Date : 2003-8-22 A standard method for storing elliptic curve cryptographic keys in the Domain Name System is described. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ecc-key-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-ecc-key-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-ecc-key-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --MIMEStream=_0+150120_2095843096819_55366650988 Content-Type: Multipart/Alternative; boundary="MIMEStream=_1+81897_37017778196021_01574354804" --MIMEStream=_1+81897_37017778196021_01574354804 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-22085940.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-ecc-key-04.txt --MIMEStream=_1+81897_37017778196021_01574354804 Content-Type: Message/External-body; name="draft-ietf-dnsext-ecc-key-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-22085940.I-D@ietf.org> --MIMEStream=_1+81897_37017778196021_01574354804-- --MIMEStream=_0+150120_2095843096819_55366650988-- -- to unsubscribe send a message to namedroppers-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 Aug 25 03:47: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 DAA00727 for ; Mon, 25 Aug 2003 03:47:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19rBuA-000Af7-C3 for namedroppers-data@psg.com; Mon, 25 Aug 2003 07:36:46 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.20) id 19rBu5-000AeF-Ph for namedroppers@ops.ietf.org; Mon, 25 Aug 2003 07:36:41 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 3148D4E219; Mon, 25 Aug 2003 09:36:41 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id D4F254E07C for ; Mon, 25 Aug 2003 09:36:40 +0200 (CEST) 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 h7P7aeWt012440 for ; Mon, 25 Aug 2003 09:36:40 +0200 Date: Mon, 25 Aug 2003 09:36:40 +0200 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: Re: DNSSECbis Q-16: Security-aware recursive name server behavior when CD=1 and DO=0 Message-Id: <20030825093640.77f9b918.olaf@ripe.net> In-Reply-To: <20030821133009.GA17357@chinook.rgy.netsol.com> References: <20030821133009.GA17357@chinook.rgy.netsol.com> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.0 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.054675 X-RIPE-Signature: 29e7a1ead344dd47436e48992deff6a7 X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,IN_REP_TO,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit We keep this Q16 open for 2 more weeks, and close this topic at Sep 7. The default action will be to keep the suggested text. -- Olaf Kolkman DNSEXT Co-Chair -- to unsubscribe send a message to namedroppers-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 Aug 25 08:17: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 IAA12740 for ; Mon, 25 Aug 2003 08:17:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19rG7h-000NKo-Ng for namedroppers-data@psg.com; Mon, 25 Aug 2003 12:07:01 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.20) id 19rG7T-000NGs-PY for namedroppers@ops.ietf.org; Mon, 25 Aug 2003 12:06:47 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h7PC6615018438 for ; Mon, 25 Aug 2003 08:06:10 -0400 (EDT) Message-ID: <013b01c36b01$46d5c560$b9370681@barnacle> From: "Scott Rose" To: "Namedroppers Mailing List" References: <20030821133009.GA17357@chinook.rgy.netsol.com> <200308220119.h7M1J4R2003910@guava.araneus.fi> Subject: Re: DNSSECbis Q-16: Security-aware recursive name server behavior when CD=1 and DO=0 Date: Mon, 25 Aug 2003 08:06:08 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The rationale is basically to reduce ambiguity. Both bits have a DNSSEC meaning, so the editors though it would be a good idea to hammer down the order for bit flags in a query. Since it was never mentioned in previous docs, we have to get WG consensus for this issue. ----- Original Message ----- From: "Andreas Gustafsson" To: "Matt Larson" Cc: "Namedroppers Mailing List" Sent: Thursday, August 21, 2003 9:19 PM Subject: Re: DNSSECbis Q-16: Security-aware recursive name server behavior when CD=1 and DO=0 > Matt Larson writes: > > Suggested additional text: > > > > The sense of the CD bit is only considered when a query also has > > the DO bit set. A security-aware recursive name server MUST ignore > > the sense of the CD bit if the DO bit is not set. > > > > Please comment on the suggested text. > > What is the rationale for this change? > -- > 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: -- to unsubscribe send a message to namedroppers-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 Aug 25 12:31: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 MAA27145 for ; Mon, 25 Aug 2003 12:31:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19rK4U-0001FF-CM for namedroppers-data@psg.com; Mon, 25 Aug 2003 16:19:58 +0000 Received: from [32.97.182.101] (helo=e1.ny.us.ibm.com) by psg.com with esmtp (Exim 4.20) id 19rK4M-0001DV-Hr for namedroppers@ops.ietf.org; Mon, 25 Aug 2003 16:19:50 +0000 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h7PGJmbe047148 for ; Mon, 25 Aug 2003 12:19:48 -0400 Received: from rotala.raleigh.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h7PGJd1i142648 for ; Mon, 25 Aug 2003 12:19:40 -0400 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.12.8/8.12.5) with ESMTP id h7PGG86l029955 for ; Mon, 25 Aug 2003 12:16:08 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.8/8.12.5/Submit) with ESMTP id h7PGG8In029950 for ; Mon, 25 Aug 2003 12:16:08 -0400 Message-Id: <200308251616.h7PGG8In029950@rotala.raleigh.ibm.com> To: namedroppers@ops.ietf.org Subject: AD review of draft-ietf-dnsext-dnssec-roadmap-07.txt Date: Mon, 25 Aug 2003 12:16:08 -0400 From: Thomas Narten X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hi. I've just re-reviewed this document. It's been around for a long time, and the IESG sent it back maybe a year ago with comments (mostly related to its extensive references to IDs). From the 20,000 foot level, I don't really see much value in publishing this document as an RFC. Reasons include: 1) a year or two from now, this document would seem to be irrelevant and I wouldn't expect anyone to need to read it. Indeed, I didn't get much out of reading it just now and I'm not sure who would need to read it. 2) It's a snapshot of things at a particular point in time, but as time moves on (and documents get revised and published), it gets out of date. 3) I don't think it's really worth spending cycles on getting the document through the final stages of IESG review, revision and publication. (Some more cleanup is needed - it still seems to talk about pre-3445 KEY usage.) 4) Documents of this type seem useful in the sense that they are useful as IDs, when the WG is trying to flesh out its roadmap. But the WG is past that point now, and its value seems largely past. So, unless the WG feels strongly it wants to move this document forward, I'd suggest we just let it die. Thomas -- to unsubscribe send a message to namedroppers-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 Aug 25 13:15: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 NAA00816 for ; Mon, 25 Aug 2003 13:15:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19rKnB-000EPN-0C for namedroppers-data@psg.com; Mon, 25 Aug 2003 17:06:09 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.20) id 19rKmi-000EIV-Fw for namedroppers@ops.ietf.org; Mon, 25 Aug 2003 17:05:40 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h7PH5I15014854; Mon, 25 Aug 2003 13:05:18 -0400 (EDT) Message-ID: <024c01c36b2b$10b6b140$b9370681@barnacle> From: "Scott Rose" To: , "Thomas Narten" References: <200308251616.h7PGG8In029950@rotala.raleigh.ibm.com> Subject: Re: AD review of draft-ietf-dnsext-dnssec-roadmap-07.txt Date: Mon, 25 Aug 2003 13:05:20 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-11.3 required=5.0 tests=BAYES_30,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit As the author of this draft (which means little): I agree. There is a section of the new DNSSECbis Intro that covers much of the same ground. Scott ----- Original Message ----- From: "Thomas Narten" To: Sent: Monday, August 25, 2003 12:16 PM Subject: AD review of draft-ietf-dnsext-dnssec-roadmap-07.txt > Hi. > > I've just re-reviewed this document. It's been around for a long time, > and the IESG sent it back maybe a year ago with comments (mostly > related to its extensive references to IDs). > > >From the 20,000 foot level, I don't really see much value in > publishing this document as an RFC. Reasons include: > > 1) a year or two from now, this document would seem to be irrelevant > and I wouldn't expect anyone to need to read it. Indeed, I didn't > get much out of reading it just now and I'm not sure who would need > to read it. > > 2) It's a snapshot of things at a particular point in time, but as > time moves on (and documents get revised and published), it gets > out of date. > > 3) I don't think it's really worth spending cycles on getting the > document through the final stages of IESG review, revision and > publication. (Some more cleanup is needed - it still seems to talk > about pre-3445 KEY usage.) > > 4) Documents of this type seem useful in the sense that they are > useful as IDs, when the WG is trying to flesh out its roadmap. But > the WG is past that point now, and its value seems largely past. > > So, unless the WG feels strongly it wants to move this document > forward, I'd suggest we just let it die. > > Thomas > > -- > to 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 Aug 25 14:34: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 OAA08247 for ; Mon, 25 Aug 2003 14:34:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19rLzZ-000A7B-5O for namedroppers-data@psg.com; Mon, 25 Aug 2003 18:23:01 +0000 Received: from [2001:4f8:3:bb:2e0:81ff:fe10:67ab] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.20) id 19rLzB-000A1n-Of for namedroppers@ops.ietf.org; Mon, 25 Aug 2003 18:22:37 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id DE573139B7 for ; Mon, 25 Aug 2003 18:22:36 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: "Namedroppers Mailing List" Subject: Re: DNSSECbis Q-16: Security-aware recursive name server behavior when CD=1 and DO=0 In-Reply-To: Message from "Scott Rose" of "Mon, 25 Aug 2003 08:06:08 -0400." <013b01c36b01$46d5c560$b9370681@barnacle> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 25 Aug 2003 18:22:36 +0000 Message-Id: <20030825182236.DE573139B7@sa.vix.com> X-Spam-Status: No, hits=-13.6 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > The rationale is basically to reduce ambiguity. Both bits have a DNSSEC > meaning, so the editors though it would be a good idea to hammer down the > order for bit flags in a query. Since it was never mentioned in previous > docs, we have to get WG consensus for this issue. to that end, i support the additional text: > > > The sense of the CD bit is only considered when a query also has > > > the DO bit set. A security-aware recursive name server MUST ignore > > > the sense of the CD bit if the DO bit is not set. -- to unsubscribe send a message to namedroppers-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 Aug 25 18:26: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 SAA20595 for ; Mon, 25 Aug 2003 18:26:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19rPcI-000Oq0-Qg for namedroppers-data@psg.com; Mon, 25 Aug 2003 22:15:14 +0000 Received: from [131.137.245.203] (helo=mx03.forces.gc.ca) by psg.com with esmtp (Exim 4.20) id 19rPc9-000Onp-3e for namedroppers@ops.ietf.org; Mon, 25 Aug 2003 22:15:05 +0000 Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx03.forces.gc.ca (DND-Mailer) with ESMTP id E7E75206609 for ; Mon, 25 Aug 2003 18:13:27 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19rPAM-000124-Nj for ietf-announce-list@asgard.ietf.org; Mon, 25 Aug 2003 17:46:22 -0400 Received: from apache by asgard.ietf.org with local (Exim 4.14) id 19rP9Y-0000tL-I5; Mon, 25 Aug 2003 17:45:32 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce: ; Cc: Internet Architecture Board , RFC Editor , Subject: Protocol Action: 'Delegation Signer Resource Record' to Proposed Standard Message-Id: Date: Mon, 25 Aug 2003 17:45:32 -0400 MIME-Version: 1.0 X-Spam-Status: No, hits=-4.0 required=5.0 tests=BAYES_10,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The IESG has approved the Internet-Draft 'Delegation Signer Resource Record' as a Proposed Standard. This document is the product of the DNS Extensions Working Group. The IESG contact persons are Thomas Narten and Margaret Wasserman. Technical Summary This document defines the Delegation Signer resource record (RR), which replaces the DNSSEC KEY record chain of trust defined in the original RFC 2535 DNSSEC protocol. The DS RR resides only at the parent and identifies (and signs) the key(s) that the child uses to self-sign its own KEY RRset. In contrast, the previously-used method, which relied on a DNSSEC KEY record chain of trust, had a number of operational issues, including that the same data was located in different places within the DNS (parent and child), which led to inconsistencies in practice, difficulties in updating signatures in some cases, and complexity in resolvers. The DS RR is an explicit statement about the delegation, rather than relying on inference. Delegation Signer changes the semantics of some previously defined DNSSEC operations and is not backwards compatible with RFC 2535. Working Group Summary There was consensus in the WG for this document. Protocol Quality This document has been reviewed for the IESG by Thomas Narten and Erik Nordmark. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 25 18:26: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 SAA20622 for ; Mon, 25 Aug 2003 18:26:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19rPcB-000Ooi-PO for namedroppers-data@psg.com; Mon, 25 Aug 2003 22:15:07 +0000 Received: from [131.137.245.203] (helo=mx03.forces.gc.ca) by psg.com with esmtp (Exim 4.20) id 19rPc2-000OmN-TI for namedroppers@ops.ietf.org; Mon, 25 Aug 2003 22:14:58 +0000 Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx03.forces.gc.ca (DND-Mailer) with ESMTP id A1B5A20660C for ; Mon, 25 Aug 2003 18:13:16 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19rPD6-0001ED-PP for ietf-announce-list@asgard.ietf.org; Mon, 25 Aug 2003 17:49:12 -0400 Received: from apache by asgard.ietf.org with local (Exim 4.14) id 19rPB0-00013A-8i; Mon, 25 Aug 2003 17:47:02 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce: ; Cc: Internet Architecture Board , RFC Editor , Subject: Protocol Action: 'Legacy Resolver Compatibility for Delegation Signer' to Proposed Standard Message-Id: Date: Mon, 25 Aug 2003 17:47:02 -0400 MIME-Version: 1.0 X-Spam-Status: No, hits=-4.0 required=5.0 tests=BAYES_10,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The IESG has approved the Internet-Draft 'Legacy Resolver Compatibility for Delegation Signer' as a Proposed Standard. This document is the product of the DNS Extensions Working Group. The IESG contact persons are Thomas Narten and Margaret Wasserman. Technical Summary As the DNS Security (DNSSEC) specifications have evolved, the syntax and semantics of the DNSSEC resource records (RRs) have changed. Many deployed nameservers understand variants of these semantics. Dangerous interactions can occur when a resolver that understands an earlier version of these semantics queries an authoritative server that understands the newer Delegation Signer RR semantics, including at least one failure scenario that will cause an unsecured zone to be unresolvable. This document changes the type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) for the newest version of these RRs to avoid those interactions. Using new type codes ensures that older and newer resolvers can easily distinguish which variant of these RRs have been implemented and how they should be interpreted. Working Group Summary There was consensus in the WG for this option. Note that this document is part of the overall DNSEXT plan of issuing individual updates to the DNSSEC RFCs; when all the changes have been completed, a revised version of 2535 will be issued tht incorportes all the changes. Protocol Quality This document has been reviewed for the IESG by Thomas Narten and Erik Nordmark. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 25 18:45: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 SAA21340 for ; Mon, 25 Aug 2003 18:45:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19rPxU-0005Ro-0j for namedroppers-data@psg.com; Mon, 25 Aug 2003 22:37:08 +0000 Received: from [2001:4f8:3:ba:2d0:a8ff:fe00:5581] (helo=gusto.araneus.fi) by psg.com with esmtp (Exim 4.20) id 19rPxD-0005Nr-Lv for namedroppers@ops.ietf.org; Mon, 25 Aug 2003 22:36:51 +0000 Received: from guava.araneus.fi (adsl-63-197-0-204.dsl.snfc21.pacbell.net [63.197.0.204]) by gusto.araneus.fi (8.12.9/8.12.9) with ESMTP id h7PMahh1016132; Mon, 25 Aug 2003 15:36:43 -0700 (PDT) Received: from guava.araneus.fi (localhost [127.0.0.1]) by guava.araneus.fi (8.12.9/8.11.6) with ESMTP id h7PMakJN004214; Mon, 25 Aug 2003 15:36:46 -0700 (PDT) Received: (from gson@localhost) by guava.araneus.fi (8.12.9/8.12.6/Submit) id h7PMahTv004211; Mon, 25 Aug 2003 15:36:43 -0700 (PDT) Date: Mon, 25 Aug 2003 15:36:43 -0700 (PDT) Message-Id: <200308252236.h7PMahTv004211@guava.araneus.fi> To: "Scott Rose" Cc: "Namedroppers Mailing List" Subject: Re: DNSSECbis Q-16: Security-aware recursive name server behavior when CD=1 and DO=0 In-Reply-To: <013b01c36b01$46d5c560$b9370681@barnacle> References: <20030821133009.GA17357@chinook.rgy.netsol.com> <200308220119.h7M1J4R2003910@guava.araneus.fi> <013b01c36b01$46d5c560$b9370681@barnacle> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=-37.0 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_RFCI,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_VM autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Scott Rose writes: > The rationale is basically to reduce ambiguity. Both bits have a DNSSEC > meaning, so the editors though it would be a good idea to hammer down the > order for bit flags in a query. Since it was never mentioned in previous > docs, we have to get WG consensus for this issue. I see no ambiguity. Both bits have a DNSSEC meaning, but they are fully orthogonal and do not conflict; all four combinations are well-defined. To recap the definitions of the bits: [RFC2535] The CD (checking disabled) bit indicates in a query that Pending (non-authenticated) data is acceptable to the resolver sending the query. [RFC3225] Setting the DO bit to one in a query indicates to the server that the resolver is able to accept DNSSEC security RRs. [...] More explicitly, DNSSEC-aware nameservers MUST NOT insert SIG, KEY, or NXT RRs to authenticate a response as specified in [RFC2535] unless the DO bit was set on the request. Security records that match an explicit SIG, KEY, NXT, or ANY query, or are part of the zone data for an AXFR or IXFR query, are included whether or not the DO bit was set. Specifically, having DO=0 and CD=1 means that the resolver cannot receive DNSSEC records (or maybe just doesn't want to), and wishes to disable DNSSEC checking by the server. The correct server behavior in this case is clearly and unambiguously to not verify and not send signatures. Of course, a resolver that sends DO=0 and CD=1 will receive unverified answers that it cannot itself verify due to the lack of signatures. Therefore, if security is desired, the resolver will not send DO=0 and CD=1. That does not mean there is any reason to make this combination of flags a special case on the server side, or that this combination of flags could not be useful in other situations such as diagnostic tools or other special applications that may want to receive pending data without signatures. -- 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 Aug 25 19:50: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 TAA23340 for ; Mon, 25 Aug 2003 19:50:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19rQwe-000NJ8-UL for namedroppers-data@psg.com; Mon, 25 Aug 2003 23:40:20 +0000 Received: from [17.254.0.51] (helo=mail-out2.apple.com) by psg.com with esmtp (Exim 4.20) id 19rQwa-000NI6-TQ for namedroppers@ops.ietf.org; Mon, 25 Aug 2003 23:40:16 +0000 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.12.9/8.12.9) with ESMTP id h7PNdsfR001813 for ; Mon, 25 Aug 2003 16:39:54 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Mon, 25 Aug 2003 16:39:49 -0700 Received: from [17.219.195.49] ([17.219.195.49]) by scv2.apple.com (8.12.9/8.12.9) with SMTP id h7PNe0WI021348 for ; Mon, 25 Aug 2003 16:40:00 -0700 (PDT) Message-Id: <200308252340.h7PNe0WI021348@scv2.apple.com> Subject: Re: DNSEXT WGLC for LLMNR Date: Mon, 25 Aug 2003 16:40:16 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_10 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >This is a last call for the DNSEXT document > Linklocal Multicast Name Resolution (LLMNR) >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-22.txt This is a busy time at Apple, working towards our next OS release, but I managed to make time to read draft-ietf-dnsext-mdns-22.txt. >The IPv4 link-scope multicast address a given responder listens >to, and to which a sender sends queries, is 224.0.0.251. If your intention is to make LLMNR interoperable with Rendezvous, I fully support that, and would be willing to do the necessary work. For example, Rendezvous does not currently support TCP queries, but we would be willing to add that support, and things like it, if the WG wanted to pursue that direction. Otherwise, if the intention is not to make LLMNR interoperable with Rendezvous, then it should not use the same multicast address. Using the same multicast address, and then using a different UDP port number so as to demultiplex the traffic in the kernel, would be the height of folly. The whole point of multicast (as opposed to good old-fashioned broadcast) is that it lets the Ethernet hardware (and/or the Ethernet switch) reduce the interrupt burden on the host CPU (and/or reduce the traffic on that link). Using the UDP port number as the filtering mechanism means that you pay all the cost of delivering a packet to a host that doesn't want it, only to have the packet discarded in the kernel because no one is listening on that port. The whole point of multicast is to prevent that waste. >Today, with the rise of home networking, there are an increasing number >of ad-hoc networks operating without a Domain Name System (DNS) server. I think this is side-stepping the real issue. The real issue is: >Today, with the rise of home networking, there are an increasing number >of home users who do not have ownership of any part of the name space >in which they can assign names. The whole section talking about "unqualified names" seems to be skirting around this issue without being willing to face it head-on and tackle it. Section 3.1 says: >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. You can't "request just the name". There is no way to represent an unqualified name ("no trailing dot") in the DNS packet format. What you mean is: >[1] Request the name with the current domain appended. >[2] Request the name with the root domain (".") appended. What this means is that if a home user calls their TV "tv", and their FM radio receiver "fm", and their CD player "cd", their computer is going to be sending queries for the TLDs "tv.", "fm." and "cd." (Tuvalu, Federal State of Micronesia, and Democratic Republic of the Congo, respectively.) This seems like it invites chaotic uncontrolled pollution of the top-level name space. Furthermore, because there is no way to represent an unqualified name in the DNS packet format, there is also no way to represent an unqualified name on the right-hand-side of a PTR, CNAME or SRV record. This means that if you do a LLMNR query for an SRV record with an "unqualified" name, what you get back is an SRV record containing a target host name that you can't use with LLMNR because it's not an "unqualified" name. >Unicast queries SHOULD be sent when: > > b. The sender queries for a [reverse mapping] PTR RR. Rendezvous has something called sleep proxy service, where a device can transfer its RRs to a sleep proxy server on the local LAN and then go into low-power sleep mode. The sleep proxy server answers queries on the device's behalf, and wakes the device with a magic packet when an A or SRV query is detected that indicates the device needs to wake up to provide some active service. Sending queries via unicast means the sleep proxy server may not get to see them, and may be unable to answer and/or wake the device. >The source address of LLMNR queries and responses MUST be "on link". Is this "MUST" a requirement imposed on senders, or a checking requirement imposed on receivers? >it is possible that some routers may not properly implement >link-scope multicast This is far fetched. How many routers *DO* implement multicast forwarding, but *DON'T* understand 224.0.0/8? It's not a plausible scenario. Rendezvous has been sending to 224.0.0.251 with TTL 255 for over a year (longer if you count OS 9) and there have been no problems reported. >The responder should use a pre-configured TTL value Pre-configured by whom? >[3] A responder with both link-local and routable addresses > MUST respond to LLMNR queries for A/AAAA RRs only with > routable address(es). This encourages use of routable > address(es) for establishment of new connections. This creates failures where failures were not necessary. Just put all answers in the response, and let the client use them intelligently: If the routable address works, great, otherwise, the client can try the LL to see if that works. Omitting the LL from the response does not help the client work better: it prevents the client from connecting in situations where it should be able to. (In some cases of network problems, omitting the LL addresses may prevent you from connecting to the some piece of network infrastructure to correct the misconfiguration that led to the problem in the first place.) >3.1. Unqualified names > >The same host MAY use LLMNR queries for the resolution of unqualified >host names Who makes the choice offered by that "MAY"? User? OS vendor? Application writer? >If a name is not qualified and does not end in a trailing dot, What does that mean? Do "fully qualified" and "ends in a trailing dot" mean the same thing, or is there a difference? >Where there is >no DNS server authoritative for the names of hosts on the local network What does that mean? What is the area code for mobile phones at an IETF meeting? The statement doesn't have well-defined meaning. My laptop computer has a name, and its name is not determined by its geographic location at any given time. DNS servers are authoritative for pieces of the name space, not for physical networks. Perhaps the text should say, "Where there is no DNS server authoritative for the name of at least *one* of the hosts *currently* on the local network..." >Where a host is configured to respond to LLMNR queries on more than one >interface, each interface should have its own independent LLMNR cache. Perhaps you mean "configured to *issue* LLMNR queries on more than one interface" >For each UNIQUE resource record in a given interface's configuration, >the host MUST verify resource record uniqueness on that interface. To >accomplish this, the host MUST send an LLMNR query for each UNIQUE >resource record. How many LLMNR queries? What interval? How long after the query (or queries) may it start issuing responses for that name? What about tie-breaking in the event of simultaneous startup (e.g. when power is restored after an outage)? >For example, the hostname could be chosen randomly from a large pool of >potential names Doesn't this miss the point of hostnames? The whole point of using names instead of dotted-decimal IP addresses is that names are supposed to be more memorable, and easier for humans to type. If we're going to use randomly chosen names, then we already have a mechanism for randomly choosing from a pool of potential identifiers: it's called a DHCP server. Isn't the point of LLMNR to let people pick a name for their machine that's a little more convenient and friendly than "dhcp-dynamic-191-72-231-201.ietf-53.ietf.org."? Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 25 22:44: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 WAA28556 for ; Mon, 25 Aug 2003 22:44:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19rTeV-000BlT-FR for namedroppers-data@psg.com; Tue, 26 Aug 2003 02:33:47 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.20) id 19rTeO-000BkF-HJ for namedroppers@ops.ietf.org; Tue, 26 Aug 2003 02:33:40 +0000 Received: (qmail 10707 invoked by uid 1016); 26 Aug 2003 02:42:18 -0000 Date: 26 Aug 2003 02:42:18 -0000 Message-ID: <20030826024218.10706.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: wcard-clarify breaking RFC 2308 NXDOMAIN References: <20030820100735.39120ccd.olaf@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-8.1 required=5.0 tests=BAYES_30,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Suppose that AOL sets up the following records: aol.com SOA ... aol.com NS a.ns.aol.com aol.com NS b.ns.aol.com www.aol.com A 1.2.3.4 a.ns.aol.com A 1.2.3.5 b.ns.aol.com A 1.2.3.5 Suppose there's a query for ns.aol.com. It's safe for AOL's servers to return NODATA. But is it safe for AOL's servers to return NXDOMAIN? RFC 2308 says that the answer is yes. It interprets NXDOMAIN as ``there are no records owned by the query name,'' which is exactly the situation here. (Section 5: ``NXDOMAIN ... the same ...'') But wcard-clarify-01 section 1.4, like RFC 1034, says that the answer is no. It interprets NXDOMAIN as ``there are no records whose owner name _ends with_ the query name,'' which is not the situation here. Most servers do, in fact, return NXDOMAIN in this situation, so it would be incredibly dangerous for a cache to apply NXDOMAIN in the way allowed by wcard-clarify-01 and by RFC 1034. The NXDOMAIN for ns.aol.com, for example, would nuke the a.ns.aol.com and b.ns.aol.com records. As a practical matter, the RFC 1034 meaning of NXDOMAIN doesn't save a noticeable percentage of queries, and the RFC 2308 meaning of NXDOMAIN reduces programming effort for many popular server database structures, so I don't see any reason to favor RFC 1034 over RFC 2308. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 25 23:31: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 XAA00420 for ; Mon, 25 Aug 2003 23:31:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19rUR8-000LhR-UI for namedroppers-data@psg.com; Tue, 26 Aug 2003 03:24:02 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.20) id 19rUR1-000Lgm-Cb for namedroppers@ops.ietf.org; Tue, 26 Aug 2003 03:23:55 +0000 Received: (qmail 60413 invoked by uid 1016); 26 Aug 2003 03:32:36 -0000 Date: 26 Aug 2003 03:32:36 -0000 Message-ID: <20030826033236.60412.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: wcard-clarify scope confusion References: <20030820100735.39120ccd.olaf@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-13.1 required=5.0 tests=BAYES_01,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The algorithm in RFC 1034 section 4.3.2 is clearly labelled as a mere _example_ of what servers are allowed to do. Many servers don't work that way. In particular, tinydns follows a very different algorithm, as do most LDAP-based DNS servers. For example, tinydns has some support for SOA synthesis; wcard-clarify-01 is simply wrong when it says that ``no implementation has done this.'' Does wcard-clarify-01 constrain the behavior of these servers? Does it have any impact outside the algorithm in RFC 1034 section 4.3.2? For example, when wcard-clarify-01 says (R2.1) that ``a domain name that is to be interpreted as a wild card MUST begin with a label of '0000 0001 0010 1010' in binary,'' is it prohibiting the behavior of advanced servers that allow record synthesis based on (say) regular expressions? Similarly, when wcard-clarify-01 says (R2.2) that ``escaped'' wild cards must be treated as wild cards, is it merely clarifying the semantics of RFC 1034 zone files (which aren't the same as BIND zone files), or is it trying to drag all possible DNS server configuration tools down to RFC 1034's level? Either way, why is the IETF sticking its nose into local configuration issues? This document seems to be a primitive implementation guide rather than a protocol spec. I realize that wildcards appear in the AXFR and NXT protocols, but wcard-clarify doesn't limit itself to the context of those protocols. To the extent that wcard-clarify goes beyond issues visible on the wire, it's violating section 6 of RFC 2119. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 25 23:36: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 XAA00613 for ; Mon, 25 Aug 2003 23:36:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19rUW9-000MAK-85 for namedroppers-data@psg.com; Tue, 26 Aug 2003 03:29:13 +0000 Received: from [192.149.252.33] (helo=smtp1.arin.net) by psg.com with esmtp (Exim 4.20) id 19rUVy-000M8p-Lv for namedroppers@ops.ietf.org; Tue, 26 Aug 2003 03:29:02 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id B9AD2527; Mon, 25 Aug 2003 23:28:58 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id 089B750F; Mon, 25 Aug 2003 23:28:58 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1) with ESMTP id 587995; Mon, 25 Aug 2003 23:26:40 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <20030826024218.10706.qmail@cr.yp.to> References: <20030820100735.39120ccd.olaf@ripe.net> <20030826024218.10706.qmail@cr.yp.to> Date: Mon, 25 Aug 2003 23:28:49 -0400 To: "D. J. Bernstein" From: Edward Lewis Subject: Re: wcard-clarify breaking RFC 2308 NXDOMAIN Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 2:42 +0000 8/26/03, D. J. Bernstein wrote: >Suppose that AOL sets up the following records: > > aol.com SOA ... > aol.com NS a.ns.aol.com > aol.com NS b.ns.aol.com > www.aol.com A 1.2.3.4 > a.ns.aol.com A 1.2.3.5 > b.ns.aol.com A 1.2.3.5 > >Suppose there's a query for ns.aol.com. It's safe for AOL's servers to >return NODATA. But is it safe for AOL's servers to return NXDOMAIN? > >RFC 2308 says that the answer is yes. It interprets NXDOMAIN as ``there >are no records owned by the query name,'' which is exactly the situation >here. (Section 5: ``NXDOMAIN ... the same ...'') > >But wcard-clarify-01 section 1.4, like RFC 1034, says that the answer is >no. It interprets NXDOMAIN as ``there are no records whose owner name >_ends with_ the query name,'' which is not the situation here. First, let's remove the use of the mnemonic and stick with 'name error' to describe the issue. In the editing process I am trying to remain implementation neutral, and, although NXDOMAIN does appear in some RFCs, those RFCs are out of scope for this clarification. (See the last part of this reply.) Second, RFC 2308 is a Proposed Standard and is not what wcard-clarify is working against (it's working against the Full Standard 1034). Perhaps in the process of getting 2308 to Draft Standard we can open up a discussion on it's interpretation of 'name error.' The intent of 'name error' is to convey from the server to the client that the name is non-existent, that the name had no bearing on the execution of the algorithm in section 4.3.2. of RFC 1034. Some folklore I recently heard may play into this, in the early days of DNS there was no QTYPE - you only looked up names (and maybe class). 'name error' meant that there was nothing to return. When QTYPE was introduced, an existing name but no data didn't get tagged as 'name error' - for backwards compatibility. In the given example, ns.aol.com (I'll ignore that you didn't specify a class and type in the query as it makes no difference here) did play a role in the execution of 4.3.2 - the fact that it exists (as a parent of a... and b...) means that section c is never executed - the query processing dies in case a. (Even if the code path chooses to check for c before a.) >Most servers do, in fact, return NXDOMAIN in this situation, so it would >be incredibly dangerous for a cache to apply NXDOMAIN in the way allowed >by wcard-clarify-01 and by RFC 1034. The NXDOMAIN for ns.aol.com, for >example, would nuke the a.ns.aol.com and b.ns.aol.com records. What do you mean by 'safe' and 'dangerous' in this context? >As a practical matter, the RFC 1034 meaning of NXDOMAIN doesn't save a >noticeable percentage of queries, and the RFC 2308 meaning of NXDOMAIN >reduces programming effort for many popular server database structures, >so I don't see any reason to favor RFC 1034 over RFC 2308. I don't know that this (the meaning of 'name error' and the apparent conflict between RFC 1034 and 2038) is an important issue, because wcard-clarify is not trying to have an impact on the meaning of 'name error' in responses. wcard-clarify is trying to define existence as it pertains to the execution of 4.3.2.c, i.e., whether synthesis of an answer is performed. In doing so, it strays dangerously close to defining the semantics of 'name error' which is the topic of 2308. Looking into the draft, I can find only 5 occurrences of 'name error' including one that is line wrapped. Three times is in section 1.4 describing the conflict of RFC 1034's definition of existence and it's definition of 'name error.' The other two times are in section 5 - once during the citation from RFC 1034 and then in the explanation paragraph below it. I can't see that wcard-clarify enters the issue of 'name error,' or for that matter, negative caching. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Sponge Bob Square Pants? I'm still trying to figure out the Macarena. -- to unsubscribe send a message to namedroppers-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 Aug 25 23:47: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 XAA01066 for ; Mon, 25 Aug 2003 23:47:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19rUb3-000NDz-AH for namedroppers-data@psg.com; Tue, 26 Aug 2003 03:34:17 +0000 Received: from [2001:470:1f00:ffff::5a1] (helo=bsdi.dv.isc.org) by psg.com with esmtp (Exim 4.20) id 19rUat-000NCx-Nc for namedroppers@ops.ietf.org; Tue, 26 Aug 2003 03:34:07 +0000 Received: from bsdi.dv.isc.org (localhost.dv.isc.org [127.0.0.1]) by bsdi.dv.isc.org (8.12.9/8.12.9) with ESMTP id h7Q3XbYf093253; Tue, 26 Aug 2003 13:33:37 +1000 (EST) (envelope-from marka@bsdi.dv.isc.org) Message-Id: <200308260333.h7Q3XbYf093253@bsdi.dv.isc.org> To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: wcard-clarify breaking RFC 2308 NXDOMAIN In-reply-to: Your message of "26 Aug 2003 02:42:18 GMT." <20030826024218.10706.qmail@cr.yp.to> Date: Tue, 26 Aug 2003 13:33:37 +1000 X-Spam-Status: No, hits=-12.0 required=5.0 tests=BAYES_01,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Suppose that AOL sets up the following records: > > aol.com SOA ... > aol.com NS a.ns.aol.com > aol.com NS b.ns.aol.com > www.aol.com A 1.2.3.4 > a.ns.aol.com A 1.2.3.5 > b.ns.aol.com A 1.2.3.5 > > Suppose there's a query for ns.aol.com. It's safe for AOL's servers to > return NODATA. But is it safe for AOL's servers to return NXDOMAIN? > > RFC 2308 says that the answer is yes. It interprets NXDOMAIN as ``there > are no records owned by the query name,'' which is exactly the situation > here. (Section 5: ``NXDOMAIN ... the same ...'') > No. RFC 2308 says that NXDOMAIN indicates a Name Error. "NXDOMAIN" - an alternate expression for the "Name Error" RCODE as described in [RFC1035 Section 4.1.1] and the two terms are used interchangeably in this document. RFC 2308 says that NXDOMAIN is independent of QTYPE. IT DOES NOT SAY THAT ALL QUERIES THAT ARE INDEPENDENT OF QTYPE RESULT IN NXDOMAIN. > But wcard-clarify-01 section 1.4, like RFC 1034, says that the answer is > no. It interprets NXDOMAIN as ``there are no records whose owner name > _ends with_ the query name,'' which is not the situation here. > > Most servers do, in fact, return NXDOMAIN in this situation, so it would > be incredibly dangerous for a cache to apply NXDOMAIN in the way allowed > by wcard-clarify-01 and by RFC 1034. The NXDOMAIN for ns.aol.com, for > example, would nuke the a.ns.aol.com and b.ns.aol.com records. > > As a practical matter, the RFC 1034 meaning of NXDOMAIN doesn't save a > noticeable percentage of queries, and the RFC 2308 meaning of NXDOMAIN > reduces programming effort for many popular server database structures, > so I don't see any reason to favor RFC 1034 over RFC 2308. > > ---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: -- 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 Aug 26 00:59: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 AAA04474 for ; Tue, 26 Aug 2003 00:59:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19rVn4-0008BA-19 for namedroppers-data@psg.com; Tue, 26 Aug 2003 04:50:46 +0000 Received: from [192.149.252.33] (helo=smtp1.arin.net) by psg.com with esmtp (Exim 4.20) id 19rVmn-00082q-N7 for namedroppers@ops.ietf.org; Tue, 26 Aug 2003 04:50:29 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 5F23C580; Tue, 26 Aug 2003 00:50:29 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id C4B64442 for ; Tue, 26 Aug 2003 00:50:28 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1) with ESMTP id 588122 for namedroppers@ops.ietf.org; Tue, 26 Aug 2003 00:48:12 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <20030826033236.60412.qmail@cr.yp.to> References: <20030820100735.39120ccd.olaf@ripe.net> <20030826033236.60412.qmail@cr.yp.to> Date: Tue, 26 Aug 2003 00:50:25 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: wcard-clarify scope confusion 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.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 3:32 +0000 8/26/03, D. J. Bernstein wrote: In the spirit of this being a working group... >Many servers don't work that way. In particular, tinydns follows a very >different algorithm, as do most LDAP-based DNS servers. For example, >tinydns has some support for SOA synthesis; wcard-clarify-01 is simply >wrong when it says that ``no implementation has done this.'' Can you elaborate on what you have implemented? I didn't find any discussion of this in the archives of the working group. SOA synthesis seems like a logical thing to do, I've never come across any one with implementation experience with this feature that has been willing to describe their success. >Does wcard-clarify-01 constrain the behavior of these servers? Does it >have any impact outside the algorithm in RFC 1034 section 4.3.2? To answer the first question, no, it doesn't. I'm not sure how to answer the second question - do you have an impact in mind? >For example, when wcard-clarify-01 says (R2.1) that ``a domain name that >is to be interpreted as a wild card MUST begin with a label of '0000 >0001 0010 1010' in binary,'' is it prohibiting the behavior of advanced >servers that allow record synthesis based on (say) regular expressions? No, the requirement specifies that a name written that way is to be interpreted as the basis of synthesis. It says nothing about it being the exclusive basis of synthesis. wcard-clarify is just shoring up what is in RFC 1034 and is not proposing any advances. >Similarly, when wcard-clarify-01 says (R2.2) that ``escaped'' wild cards >must be treated as wild cards, is it merely clarifying the semantics of >RFC 1034 zone files (which aren't the same as BIND zone files), or is it >trying to drag all possible DNS server configuration tools down to RFC >1034's level? Either way, why is the IETF sticking its nose into local >configuration issues? If you don't have zone files, you don't have to worry about escape sequences. Personally, I would prefer to not specify zone file issues, but the WG has stated that zone file formats are to be specified. I go along if just so that we have a format to use in email discussions. Just because wcard-clarify says that you must treat even an escaped '*' as a (potential) wild card domain name, the document does not say that you must have escapes - or zone files or configuration files. (But *if* you do...) >This document seems to be a primitive implementation guide rather than a >protocol spec. I realize that wildcards appear in the AXFR and NXT >protocols, but wcard-clarify doesn't limit itself to the context of >those protocols. To the extent that wcard-clarify goes beyond issues >visible on the wire, it's violating section 6 of RFC 2119. The document says nothing more than what is in RFC 1034. The document makes no requirements on configuration of servers, but it comments on the choices *some* implementers have made. And, as you mention here, the wire representation of the wild card domain name appears in AXFR, so it is a good thing that the definition is included. The NXT is still out of scope for this document (it's one of those dastardly DNSSEC concepts that need fleshing out). I am curious though about alternative approaches to synthesis of answers. I would find a document on that interesting and it would be helpful when writing the DNSSEC handling of negative answers and synthentic answers. But that's not part of the current document. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Sponge Bob Square Pants? I'm still trying to figure out the Macarena. -- to unsubscribe send a message to namedroppers-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 Aug 26 01:29: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 BAA05160 for ; Tue, 26 Aug 2003 01:29:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19rWIo-000D4A-Ew for namedroppers-data@psg.com; Tue, 26 Aug 2003 05:23:34 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.20) id 19rWHg-000Cxz-Vc for namedroppers@ops.ietf.org; Tue, 26 Aug 2003 05:22:25 +0000 Received: (qmail 87756 invoked by uid 1016); 26 Aug 2003 05:31:06 -0000 Date: 26 Aug 2003 05:31:06 -0000 Message-ID: <20030826053106.87755.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: wcard-clarify breaking RFC 2308 NXDOMAIN References: <20030820100735.39120ccd.olaf@ripe.net> <20030826024218.10706.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-19.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward Lewis writes: > What do you mean by 'safe' and 'dangerous' in this context? ``The NXDOMAIN for ns.aol.com, for example, would nuke the a.ns.aol.com and b.ns.aol.com records.'' The server is expecting the cache to see the a.ns.aol.com A record, but the cache is blinded by the NXDOMAIN. That's an interoperability disaster. wcard-clarify-01 says ``A QNAME and QCLASS matching an existing node never results in'' NXDOMAIN. That statement, with the wcard-clarify-01 definition of ``existing,'' is simply not true. As I said, real servers do generate NXDOMAIN in this situation. To avoid triggering the interoperability disaster, caches have to limit NXDOMAIN as indicated in RFC 2308. Perhaps you think that RFC 2308 was wrong and that servers shouldn't actually work this way, but this view doesn't change the danger from the cache's perspective. Please don't mislead cache implementors. The entire purpose of your document, apparently, is to communicate If there are records with owner names ending d.e.f, but no records with owner names ending c.d.e.f, then the only possible wildcard relevant to a.b.c.d.e.f is *.d.e.f. which you can say without redefining ``existence'' and without screwing up the NXDOMAIN semantics. ---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 Tue Aug 26 02:08: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 CAA14586 for ; Tue, 26 Aug 2003 02:08:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19rWtm-000KIZ-NZ for namedroppers-data@psg.com; Tue, 26 Aug 2003 06:01:46 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.20) id 19rWtU-000KBu-93 for namedroppers@ops.ietf.org; Tue, 26 Aug 2003 06:01:28 +0000 Received: (qmail 26936 invoked by uid 1016); 26 Aug 2003 06:10:09 -0000 Date: 26 Aug 2003 06:10:09 -0000 Message-ID: <20030826061009.26935.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: wcard-clarify scope confusion References: <20030820100735.39120ccd.olaf@ripe.net> <20030826033236.60412.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-29.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward Lewis writes: > the WG has stated that zone file formats are to be specified I don't understand. What would your ``zone file specification'' mean? Who would it apply to? BIND has its own zone-file format (depending on the BIND version), noticeably different from the RFC-1034-etc zone-file format; furthermore, the semantics of a zone file depend heavily on configuration data outside the zone file. Why do you think these local server-configuration mechanisms are any of the IETF's business? Do you think that RFC 1034's violation of RFC 2119 justifies new violations? Anyway, I find it difficult to believe that the scope of wcard-clarify is supposed to be limited to the semantics of stars in zone files. [ zone wildcards ] > Can you elaborate on what you have implemented? I can, but I'm not going to. It's not an IETF issue. ---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 Tue Aug 26 05:05: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 FAA24246 for ; Tue, 26 Aug 2003 05:05:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19rZZO-0008cD-GA for namedroppers-data@psg.com; Tue, 26 Aug 2003 08:52:54 +0000 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtp (Exim 4.20) id 19rZZL-0008av-7F for namedroppers@ops.ietf.org; Tue, 26 Aug 2003 08:52:51 +0000 Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.11.6/TechFak/2003/04/16/pk) with ESMTP id h7Q8qnG20191 for ; Tue, 26 Aug 2003 10:52:49 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id h7Q8qm011021 for ; Tue, 26 Aug 2003 10:52:48 +0200 (MEST) Message-Id: <200308260852.h7Q8qm011021@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org Subject: Re: wcard-clarify breaking RFC 2308 NXDOMAIN In-reply-to: Your message of "26 Aug 2003 05:31:06 -0000." <20030826053106.87755.qmail@cr.yp.to> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11017.1061887967.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Tue, 26 Aug 2003 10:52:48 +0200 From: Peter Koch X-Spam-Status: No, hits=-26.6 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Dan Bernstein wrote: > wcard-clarify-01 says ``A QNAME and QCLASS matching an existing node > never results in'' NXDOMAIN. That statement, with the wcard-clarify-01 > definition of ``existing,'' is simply not true. As I said, real servers > do generate NXDOMAIN in this situation. which is a bug that has been reported for some and has been fixed for others. From an operational perspective it's more than weird to be told a name doesn't exist which has existing descendants (i.e. subdomains). So, I really appreciate the clarification in 1.4 of draft-ietf-dnsext-wcard-clarify-01.txt. -Peter -- to unsubscribe send a message to namedroppers-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 Aug 26 08:31: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 IAA01338 for ; Tue, 26 Aug 2003 08:31:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19rcqn-0002RY-WB for namedroppers-data@psg.com; Tue, 26 Aug 2003 12:23:05 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.20) id 19rcqg-0002Pi-5W for namedroppers@ops.ietf.org; Tue, 26 Aug 2003 12:23:02 +0000 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 h7QCMkl06219; Tue, 26 Aug 2003 19:22:47 +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 h7QC5F311002; Tue, 26 Aug 2003 19:05:15 +0700 (ICT) From: Robert Elz To: "D. J. Bernstein" cc: namedroppers@ops.ietf.org Subject: Re: wcard-clarify breaking RFC 2308 NXDOMAIN In-Reply-To: <20030826024218.10706.qmail@cr.yp.to> References: <20030826024218.10706.qmail@cr.yp.to> <20030820100735.39120ccd.olaf@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 26 Aug 2003 19:05:15 +0700 Message-ID: <8923.1061899515@munnari.OZ.AU> X-Spam-Status: No, hits=-15.5 required=5.0 tests=BAYES_10,IN_REP_TO,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: 26 Aug 2003 02:42:18 -0000 From: "D. J. Bernstein" Message-ID: <20030826024218.10706.qmail@cr.yp.to> | Suppose there's a query for ns.aol.com. It's safe for AOL's servers to | return NODATA. But is it safe for AOL's servers to return NXDOMAIN? No. | RFC 2308 says that the answer is yes. It says nothing of the kind. That's an unbelievable stretch of what is written there. Aside from anything else, 2308 is talking about what caches do, not what servers do. Even if one could conclude from 2308 that caches must not rely upon the NXDOMAIN to infer that no sub-domains of the name can exist (which I don't think 2308 actually says, but ignore that for now), that in no way means that servers should ignore the spec (which is 1034 here) and start doing something bogus. | But wcard-clarify-01 section 1.4, like RFC 1034, says that the answer is | no. yes, and when 1034 says something, which isn't explicitly changed by some later spec (and precise wording in 1034 which has been altered is very rare) then what 1034 says always wins. Drawing inferences from a 2308 is not nearly enough to override 1034. | Most servers do, in fact, return NXDOMAIN in this situation, I have no idea how you have counted "most" there - but I assume it must mean "most server implementations" (and even there I'd like to see the evidence) because it certainly can't be intended to mean "most deployed servers" can it? We know that's BIND (BIND based) and BIND has never done that (not even in the most ancient bug ridden versions). | so it would | be incredibly dangerous for a cache to apply NXDOMAIN in the way allowed | by wcard-clarify-01 and by RFC 1034. That's probably true - it would be unwise for a cache to rely upon this, as broken servers have been known to exist. It would be nice to stamp out all those broken servers (or most of them anyway) so that we could rely upon that. | As a practical matter, the RFC 1034 meaning of NXDOMAIN doesn't save a | noticeable percentage of queries, No, but it does give valuable information to someone making a query. If I query for A records for abc.example.com and get NXDOMAIN, then I know it doesn't exist, and so there's no point trying www.abc.example.com or anything similar. On the other hand, if I get NODATA, then I know it does exist, and that my scribbled notation of what domain name I should be looking for has a good chance of being right. 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 Aug 26 09:03: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 JAA02223 for ; Tue, 26 Aug 2003 09:03:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19rdOa-000A86-N4 for namedroppers-data@psg.com; Tue, 26 Aug 2003 12:58:00 +0000 Received: from [192.149.252.33] (helo=smtp1.arin.net) by psg.com with esmtp (Exim 4.20) id 19rdOP-000A4P-FH for namedroppers@ops.ietf.org; Tue, 26 Aug 2003 12:57:49 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 4393143B; Tue, 26 Aug 2003 08:57:47 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id CD8EF425; Tue, 26 Aug 2003 08:57:46 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1) with ESMTP id 588839; Tue, 26 Aug 2003 08:55:29 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <20030826061009.26935.qmail@cr.yp.to> References: <20030820100735.39120ccd.olaf@ripe.net> <20030826033236.60412.qmail@cr.yp.to> <20030826061009.26935.qmail@cr.yp.to> Date: Tue, 26 Aug 2003 08:57:25 -0400 To: "D. J. Bernstein" From: Edward Lewis Subject: Re: wcard-clarify scope confusion Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-33.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REFERENCES,REPLY_WITH_QUOTES, SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 6:10 +0000 8/26/03, D. J. Bernstein wrote: >Edward Lewis writes: >> the WG has stated that zone file formats are to be specified > >I don't understand. What would your ``zone file specification'' mean? The zone file specification that you referred to in your message, the one defined in RFC 1034 and not the one in the implementation you mentioned. >Who would it apply to? BIND has its own zone-file format (depending on >the BIND version), noticeably different from the RFC-1034-etc zone-file >format; furthermore, the semantics of a zone file depend heavily on >configuration data outside the zone file. Why do you think these local >server-configuration mechanisms are any of the IETF's business? Do you >think that RFC 1034's violation of RFC 2119 justifies new violations? Again, I agree with you that the zone file is not a topic for interoperability, however, the WG asks for such a discussion to be present. And again, it's also a nice documentation convention for conveying concepts in email. You started the thread with a zone file like piece of text. >Anyway, I find it difficult to believe that the scope of wcard-clarify >is supposed to be limited to the semantics of stars in zone files. You are right, the scope is the role played in the synthesis wild card domain names play in answering queries and how to recognize wild card domain names in zone transfers. > > [ zone wildcards ] >> Can you elaborate on what you have implemented? > >I can, but I'm not going to. It's not an IETF issue. Then I'm forced to leave in the text that not implementations have done SOA and zone synthesis. It wouldn't be right to say "and someone claims to have done this," now, would it? Without backing material that is. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Sponge Bob Square Pants? I'm still trying to figure out the Macarena. -- to unsubscribe send a message to namedroppers-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 Aug 26 09:03: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 JAA02268 for ; Tue, 26 Aug 2003 09:03:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19rdOS-000A5J-QM for namedroppers-data@psg.com; Tue, 26 Aug 2003 12:57:52 +0000 Received: from [192.149.252.33] (helo=smtp1.arin.net) by psg.com with esmtp (Exim 4.20) id 19rdOM-000A48-Gj for namedroppers@ops.ietf.org; Tue, 26 Aug 2003 12:57:46 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id C9D1D423; Tue, 26 Aug 2003 08:57:45 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id 45F90363; Tue, 26 Aug 2003 08:57:45 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1) with ESMTP id 588838; Tue, 26 Aug 2003 08:55:27 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <20030826053106.87755.qmail@cr.yp.to> References: <20030820100735.39120ccd.olaf@ripe.net> <20030826024218.10706.qmail@cr.yp.to> <20030826053106.87755.qmail@cr.yp.to> Date: Tue, 26 Aug 2003 08:50:58 -0400 To: "D. J. Bernstein" From: Edward Lewis Subject: Re: wcard-clarify breaking RFC 2308 NXDOMAIN Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-33.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 5:31 +0000 8/26/03, D. J. Bernstein wrote: >Edward Lewis writes: >> What do you mean by 'safe' and 'dangerous' in this context? > >``The NXDOMAIN for ns.aol.com, for example, would nuke the a.ns.aol.com >and b.ns.aol.com records.'' The server is expecting the cache to see the >a.ns.aol.com A record, but the cache is blinded by the NXDOMAIN. That's >an interoperability disaster. > >wcard-clarify-01 says ``A QNAME and QCLASS matching an existing node >never results in'' NXDOMAIN. That statement, with the wcard-clarify-01 >definition of ``existing,'' is simply not true. As I said, real servers >do generate NXDOMAIN in this situation. I'm confused. In the first paragraph it seems that you are arguing for a no error RCODE with an empty answer section to be returned, otherwise caches would be blinded. I agree with that, although I've always felt that negative answers ought not be interpreted by caches beyond the query string for which they were obtained. (The reason I feel this way has to do with wild card synthesized NXT records.) In the second paragraph, are you saying a name error should be the right response because implementations to that now? From the semantics in 1034, I would think that the implementations are in error, a name error happens with the name in the query is non-existent. Or are you saying that there is something wrong with the redefinition of existence that conflicts with name error. The portion of the draft you are quoting is text lifted from 1034 and modified for new (tighter) definition of existence. The sentence in question is unchanged from 1034. >To avoid triggering the interoperability disaster, caches have to limit >NXDOMAIN as indicated in RFC 2308. Perhaps you think that RFC 2308 was >wrong and that servers shouldn't actually work this way, but this view >doesn't change the danger from the cache's perspective. I don't see any reason to discuss this hear, wcard-clarify is not updating RFC 2308. Wcard-clarify says nothing about negative answers and how they are handled in caches, it says nothing about when they are generated that differs from what's in RFC 1034. >Please don't mislead cache implementors. The entire purpose of your >document, apparently, is to communicate > > If there are records with owner names ending d.e.f, but no records > with owner names ending c.d.e.f, then the only possible wildcard > relevant to a.b.c.d.e.f is *.d.e.f. > >which you can say without redefining ``existence'' and without screwing >up the NXDOMAIN semantics. The 'new' definition of existence because of the words here (from 1034): "Each ... leaf ... (which may be empty)." All this draft does us say that empty leaf nodes do not exist (they've never been assumed to exist), as well as all nodes in a completely empty domain. I don't think that anyone has ever treated nodes as existing that the draft is defining away now. It's just that the definition needs to be tighter once we try to authenticate denial of existence. It's a paper change to pre-DNSSEC DNS. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Sponge Bob Square Pants? I'm still trying to figure out the Macarena. -- to unsubscribe send a message to namedroppers-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 Aug 26 09:13: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 JAA02800 for ; Tue, 26 Aug 2003 09:13:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19rdY9-000CWE-IQ for namedroppers-data@psg.com; Tue, 26 Aug 2003 13:07:53 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.20) id 19rdY5-000CUS-H3 for namedroppers@ops.ietf.org; Tue, 26 Aug 2003 13:07:49 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h7QD7D15022682; Tue, 26 Aug 2003 09:07:14 -0400 (EDT) Message-ID: <00c801c36bd2$f871fd30$b9370681@barnacle> From: "Scott Rose" To: "Andreas Gustafsson" Cc: "Namedroppers Mailing List" References: <20030821133009.GA17357@chinook.rgy.netsol.com><200308220119.h7M1J4R2003910@guava.araneus.fi><013b01c36b01$46d5c560$b9370681@barnacle> <200308252236.h7PMahTv004211@guava.araneus.fi> Subject: Re: DNSSECbis Q-16: Security-aware recursive name server behavior when CD=1 and DO=0 Date: Tue, 26 Aug 2003 09:07:14 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think we're in agreement here. There is some concern that there is ambiguity over what the combo of the AD, CD and DO bits mean. The text that Matt gave was an attempt to clarify it for implementation guidelines. Scott ----- Original Message ----- From: "Andreas Gustafsson" To: "Scott Rose" Cc: "Namedroppers Mailing List" Sent: Monday, August 25, 2003 6:36 PM Subject: Re: DNSSECbis Q-16: Security-aware recursive name server behavior when CD=1 and DO=0 > Scott Rose writes: > > The rationale is basically to reduce ambiguity. Both bits have a DNSSEC > > meaning, so the editors though it would be a good idea to hammer down the > > order for bit flags in a query. Since it was never mentioned in previous > > docs, we have to get WG consensus for this issue. > > I see no ambiguity. Both bits have a DNSSEC meaning, but they are > fully orthogonal and do not conflict; all four combinations are > well-defined. > > To recap the definitions of the bits: > > [RFC2535] > The CD (checking disabled) > bit indicates in a query that Pending (non-authenticated) data is > acceptable to the resolver sending the query. > > [RFC3225] > Setting the DO bit to one in a query indicates to the server that the > resolver is able to accept DNSSEC security RRs. [...] > More explicitly, DNSSEC-aware nameservers MUST NOT insert SIG, KEY, > or NXT RRs to authenticate a response as specified in [RFC2535] > unless the DO bit was set on the request. Security records that > match an explicit SIG, KEY, NXT, or ANY query, or are part of the > zone data for an AXFR or IXFR query, are included whether or not the > DO bit was set. > > Specifically, having DO=0 and CD=1 means that the resolver cannot > receive DNSSEC records (or maybe just doesn't want to), and wishes to > disable DNSSEC checking by the server. The correct server behavior in > this case is clearly and unambiguously to not verify and not send > signatures. > > Of course, a resolver that sends DO=0 and CD=1 will receive unverified > answers that it cannot itself verify due to the lack of signatures. > Therefore, if security is desired, the resolver will not send DO=0 and > CD=1. That does not mean there is any reason to make this combination > of flags a special case on the server side, or that this combination > of flags could not be useful in other situations such as diagnostic > tools or other special applications that may want to receive pending > data without signatures. > -- > 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 Tue Aug 26 10:27: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 KAA07979 for ; Tue, 26 Aug 2003 10:27:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19recE-0001gA-NH for namedroppers-data@psg.com; Tue, 26 Aug 2003 14:16:10 +0000 Received: from [192.96.22.18] (helo=citadel.cequrux.com) by psg.com with esmtp (Exim 4.20) id 19rebd-0001WI-EL for namedroppers@ops.ietf.org; Tue, 26 Aug 2003 14:15:33 +0000 Received: (from nobody@localhost) by citadel.cequrux.com (8.8.8/8.6.9) id QAA01532 for ; Tue, 26 Aug 2003 16:15:29 +0200 (SAST) Received: by citadel.cequrux.com via recvmail id 1490; Tue, 26 Aug 2003 16:14:41 +0200 (SAST) Date: Tue, 26 Aug 2003 16:14:41 +0200 From: Alan Barrett To: namedroppers@ops.ietf.org Subject: Re: wcard-clarify breaking RFC 2308 NXDOMAIN Message-ID: <20030826141441.GK910@apb.cequrux.com> References: <20030820100735.39120ccd.olaf@ripe.net> <20030826024218.10706.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030826024218.10706.qmail@cr.yp.to> 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 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 26 Aug 2003, D. J. Bernstein wrote: > Suppose that AOL sets up the following records: > > aol.com SOA ... > aol.com NS a.ns.aol.com > aol.com NS b.ns.aol.com > www.aol.com A 1.2.3.4 > a.ns.aol.com A 1.2.3.5 > b.ns.aol.com A 1.2.3.5 > > Suppose there's a query for ns.aol.com. It's safe for AOL's servers to > return NODATA. But is it safe for AOL's servers to return NXDOMAIN? The server should return NODATA. Since ns.aol.com has descendents, NXDOMAIN is not an appropriate response. > RFC 2308 says that the answer is yes. It interprets NXDOMAIN as > ``there are no records owned by the query name,'' which is exactly the > situation here. (Section 5: ``NXDOMAIN ... the same > ...'') I can't find any text in RFC 2308 that implies that it's OK for a server to respond with NXDOMAIN in this situation. RFC2308 does say what a cache is allowed to do if it receives NXDOMAIN. > But wcard-clarify-01 section 1.4, like RFC 1034, says that the answer > is no. It interprets NXDOMAIN as ``there are no records whose owner > name _ends with_ the query name,'' which is not the situation here. draft-ietf-wcard-clarify-01 is correct about this point. I see no conflict between this and RFC 2308. > Most servers do, in fact, return NXDOMAIN in this situation, Oh, really? > so it would be incredibly dangerous for a cache to apply NXDOMAIN in > the way allowed by wcard-clarify-01 and by RFC 1034. The NXDOMAIN for > ns.aol.com, for example, would nuke the a.ns.aol.com and b.ns.aol.com > records. There should not be an NXDOMAIN for ns.aol.com; if there is, then the server that sent it is in error, and should not be surprised if it causes trouble elsewhere. --apb (Alan Barrett) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 26 10:35: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 KAA08734 for ; Tue, 26 Aug 2003 10:35:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19renM-0004Gs-DN for namedroppers-data@psg.com; Tue, 26 Aug 2003 14:27:40 +0000 Received: from [2001:4f8:3:bb:2e0:81ff:fe10:67ab] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.20) id 19renJ-0004GT-TP for namedroppers@ops.ietf.org; Tue, 26 Aug 2003 14:27:37 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 4C62F139CB for ; Tue, 26 Aug 2003 14:27:37 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: wcard-clarify breaking RFC 2308 NXDOMAIN In-Reply-To: Message from Peter Koch of "Tue, 26 Aug 2003 10:52:48 +0200." <200308260852.h7Q8qm011021@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 26 Aug 2003 14:27:37 +0000 Message-Id: <20030826142737.4C62F139CB@sa.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.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > From an operational perspective it's more than weird to be told a name > doesn't exist which has existing descendants (i.e. subdomains). So, I > really appreciate the clarification in 1.4 of > draft-ietf-dnsext-wcard-clarify-01.txt. me too. the fuzziness of the 1034/1035 description of empty nonterminals has led to a lot of pain and confusion, and i don't just mean in dnssec. the wcard-clarify description does not constitute a change from 1034/1035, it really is just a clarification, and it's a good and nec'y clarification. -- to unsubscribe send a message to namedroppers-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 Aug 26 13:54: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 NAA17148 for ; Tue, 26 Aug 2003 13:54:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19rhqG-000I7a-JA for namedroppers-data@psg.com; Tue, 26 Aug 2003 17:42:52 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.20) id 19rhqA-000I5p-6y for namedroppers@ops.ietf.org; Tue, 26 Aug 2003 17:42:46 +0000 Received: (qmail 46553 invoked by uid 1016); 26 Aug 2003 17:44:47 -0000 Date: 26 Aug 2003 17:44:47 -0000 Message-ID: <20030826174447.46552.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: wcard-clarify breaking RFC 2308 NXDOMAIN References: <20030820100735.39120ccd.olaf@ripe.net> <20030826024218.10706.qmail@cr.yp.to> <20030826141441.GK910@apb.cequrux.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-13.1 required=5.0 tests=BAYES_01,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I specifically raised the NXDOMAIN-semantics issue here on 1999.12.08, under the subject line ``sub.dom with cached NXDOMAIN dom.'' Paul Vixie responded: RFC 2308 implicitly outlawed BIND's behaviour, which is to return NOERROR/ANCOUNT=0 for empty nonterminals. After RFC 2308, empty nonterminals are signalled with NXDOMAIN. There wasn't even a whisper of disagreement. There also have been no reports of interoperability problems---i.e., of caches violating the explicit statements in RFC 2308 by applying NXDOMAIN to subdomains. Using NXDOMAIN for empty nonterminals has obvious benefits for some server-side database structures. I took advantage of this in tinydns, which I released a few weeks later, and which is now very widely used. Other implementors have also taken advantage of the NXDOMAIN semantics. Now, four years later, without any excuse, people here are suddenly trying to retroactively change the NXDOMAIN semantics, prohibiting the extremely widespread behavior of using NXDOMAIN for empty nonterminals. Elz says that using NXDOMAIN for empty nonterminals is an ``unbelievable stretch'' and that I'm telling server implementors to ``start doing something bogus.'' If there's some benefit of changing the NXDOMAIN semantics, then I'm willing to discuss whether that benefit outweighs the costs. I am not, however, going to tolerate fraud. The wcard-``clarify'' use of NXDOMAIN is _not_ how DNS works. _I_ am not the one proposing changes to the DNS protocol. ---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 Tue Aug 26 14:42: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 OAA20638 for ; Tue, 26 Aug 2003 14:42:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19rifs-0004rr-6D for namedroppers-data@psg.com; Tue, 26 Aug 2003 18:36:12 +0000 Received: from [192.149.252.33] (helo=smtp1.arin.net) by psg.com with esmtp (Exim 4.20) id 19rifd-0004k5-Tf for namedroppers@ops.ietf.org; Tue, 26 Aug 2003 18:35:58 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 643B3603; Tue, 26 Aug 2003 14:35:54 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id DEE77583 for ; Tue, 26 Aug 2003 14:35:53 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1) with ESMTP id 589850; Tue, 26 Aug 2003 14:33:35 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <20030826174447.46552.qmail@cr.yp.to> References: <20030820100735.39120ccd.olaf@ripe.net> <20030826024218.10706.qmail@cr.yp.to> <20030826141441.GK910@apb.cequrux.com> <20030826174447.46552.qmail@cr.yp.to> Date: Tue, 26 Aug 2003 14:35:51 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: wcard-clarify breaking RFC 2308 NXDOMAIN Cc: edlewis@arin.net 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.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 17:44 +0000 8/26/03, D. J. Bernstein wrote: >however, going to tolerate fraud. The wcard-``clarify'' use of NXDOMAIN >is _not_ how DNS works. _I_ am not the one proposing changes to the DNS >protocol. You're barking up the wrong tree. No one is proposing a change to the DNS protocol and, in this case, no one should be. Using grep to find NXDOMAIN finds that it appears twice, each in the context of why is it not used (elsewhere) in the draft. Grepping for 'name error' shows that is used only in the context of repeating what was in RFC 1034. There is no redefinition, no reinterpretation of the concept. The issue you are raising, that an empty non-terminal ought to return a name error for queries about it, is a valid one. It makes sense that if I ask for data and there is none to return (authoritatively) I get back a consistent message. Having RCODE="name error" if the name doesn't exist and RCODE="no error" if the name does but the data not makes little sense to me. Harking back to the basis of the protocol, the Full Standard document, there is a difference though. If wcard-clarify was to propose what you state there would be two problems. One, it would be a change to the Full Standard by specifying a different response to a query, which seems to be something you do not want - a change to the protocol. Two, the proposal would be out of scope. This is a clarification of wild card domain name synthesis after all, not a discussion on negative answers. But this is all off-topic for the document in last call. Wild card synthesis is concerned with whether or not a name exists, hence the discussion of it. Beyond that, no statements are made about what the server ultimately returns to the querier. I am not sure what would make you happy. If you want RFC 1034 to be altered to allow a name error to be declared for empty non-terminals, well, this is not the place to argue it, that would be when we get around to rehashing RFC 2308. As you emphasize above, wcard-clarify is a clarification document not a change document, yet is seems that the issue you have is nestled in RFC 1034. Your choice seems to be to rewrite wcard-clarify to alter RFC 1034, making the draft not a clarification but an update, or leave wcard-clarify as just a clarification document and fix implementations, such as the versions of the one you often cite, BIND, that are not within interpretation of the words in RFC 1034. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Sponge Bob Square Pants? I'm still trying to figure out the Macarena. -- to unsubscribe send a message to namedroppers-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 Aug 26 15:04: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 PAA23152 for ; Tue, 26 Aug 2003 15:04:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19rixs-0009fB-Rx for namedroppers-data@psg.com; Tue, 26 Aug 2003 18:54:48 +0000 Received: from [2001:4f8:3:ba:2d0:a8ff:fe00:5581] (helo=gusto.araneus.fi) by psg.com with esmtp (Exim 4.20) id 19rixg-0009du-Bs for namedroppers@ops.ietf.org; Tue, 26 Aug 2003 18:54:36 +0000 Received: from guava.araneus.fi (adsl-63-197-0-204.dsl.snfc21.pacbell.net [63.197.0.204]) by gusto.araneus.fi (8.12.9/8.12.9) with ESMTP id h7QIsUh1020882; Tue, 26 Aug 2003 11:54:30 -0700 (PDT) Received: from guava.araneus.fi (localhost [127.0.0.1]) by guava.araneus.fi (8.12.9/8.11.6) with ESMTP id h7QIsTJN006028; Tue, 26 Aug 2003 11:54:29 -0700 (PDT) Received: (from gson@localhost) by guava.araneus.fi (8.12.9/8.12.6/Submit) id h7QIsTrW006025; Tue, 26 Aug 2003 11:54:29 -0700 (PDT) Date: Tue, 26 Aug 2003 11:54:29 -0700 (PDT) Message-Id: <200308261854.h7QIsTrW006025@guava.araneus.fi> To: "Scott Rose" Cc: "Andreas Gustafsson" , "Namedroppers Mailing List" Subject: Re: DNSSECbis Q-16: Security-aware recursive name server behavior when CD=1 and DO=0 In-Reply-To: <00c801c36bd2$f871fd30$b9370681@barnacle> References: <20030821133009.GA17357@chinook.rgy.netsol.com> <200308220119.h7M1J4R2003910@guava.araneus.fi> <013b01c36b01$46d5c560$b9370681@barnacle> <200308252236.h7PMahTv004211@guava.araneus.fi> <00c801c36bd2$f871fd30$b9370681@barnacle> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=-37.0 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_RFCI,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_VM autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Scott Rose writes: > I think we're in agreement here. Just in case it wasn't clear from my previous mail, I am opposed to adding the text suggested in Q-16. Are you saying you have changed your mind and are now also opposing it? > There is some concern that there is > ambiguity over what the combo of the AD, CD and DO bits mean. The text that > Matt gave was an attempt to clarify it for implementation guidelines. Q-16 does not mention the AD bit. Adding the text suggested in Q-16 is not a clarification of the existing protocol - it is a protocol change. Currently servers are allowed to send non-authenticated data when CD=1 and DO=0 (just as they are when DO=1, because DO currently does not figure into the definition of CD). The proposed text changes this. -- 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 Tue Aug 26 15:18: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 PAA26769 for ; Tue, 26 Aug 2003 15:18:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19rjDr-000EhW-Ty for namedroppers-data@psg.com; Tue, 26 Aug 2003 19:11:19 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.20) id 19rjDn-000Egf-GY for namedroppers@ops.ietf.org; Tue, 26 Aug 2003 19:11:15 +0000 Received: (qmail 72781 invoked by uid 1016); 26 Aug 2003 19:19:56 -0000 Date: 26 Aug 2003 19:19:56 -0000 Message-ID: <20030826191956.72780.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: wcard-clarify breaking RFC 2308 NXDOMAIN References: <20030820100735.39120ccd.olaf@ripe.net> <20030826024218.10706.qmail@cr.yp.to> <20030826141441.GK910@apb.cequrux.com> <20030826174447.46552.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-28.5 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward Lewis writes: > The issue you are raising, that an empty non-terminal ought to return > a name error for queries about it, is a valid one. This isn't an issue I'm ``raising.'' It's an issue I raised in 1999. The undisputed answer was that, after RFC 2308, NXDOMAIN was allowed--- and preferred. In fact, Vixie said that NXDOMAIN was _required_. Most server implementations work this way. There have been no reports of caches having trouble with it. Nobody has given any reasons to prohibit NXDOMAIN here. You argue that you can't be changing the protocol because you're merely repeating RFC 1034. Your logic is flawed, and your conclusion is wrong. Repeating this error from RFC 1034 _does_ change the protocol. Here's a more extreme example, so you can understand the mistake in your argument. http://cr.yp.to/djbdns/notes.html, under ``Expiring glue,'' describes a common situation where the RFC 1034 resolution algorithm doesn't work---it's fundamentally broken. Real caches use a different algorithm. This part of RFC 1034 is simply wrong; repeating it in a new spec would be a serious mistake. ---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 Tue Aug 26 16:08: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 QAA04193 for ; Tue, 26 Aug 2003 16:08:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19rjzC-0002r5-R3 for namedroppers-data@psg.com; Tue, 26 Aug 2003 20:00:14 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.20) id 19rjz6-0002nh-Eo for namedroppers@ops.ietf.org; Tue, 26 Aug 2003 20:00:08 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id D9A7D5F4; Tue, 26 Aug 2003 16:00:00 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 77E0D51E for ; Tue, 26 Aug 2003 16:00:00 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1) with ESMTP id 590110; Tue, 26 Aug 2003 15:57:41 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <20030826191956.72780.qmail@cr.yp.to> References: <20030820100735.39120ccd.olaf@ripe.net> <20030826024218.10706.qmail@cr.yp.to> <20030826141441.GK910@apb.cequrux.com> <20030826174447.46552.qmail@cr.yp.to> <20030826191956.72780.qmail@cr.yp.to> Date: Tue, 26 Aug 2003 15:59:58 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: wcard-clarify breaking RFC 2308 NXDOMAIN Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-16.9 required=5.0 tests=BAYES_01,IN_REP_TO,REFERENCES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk What part of your last message relates to wild card synthesis? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Sponge Bob Square Pants? I'm still trying to figure out the Macarena. -- to unsubscribe send a message to namedroppers-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 Aug 26 20:23: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 UAA25885 for ; Tue, 26 Aug 2003 20:23:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19rnre-0000cS-U4 for namedroppers-data@psg.com; Wed, 27 Aug 2003 00:08:42 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.20) id 19rnK9-000FhM-GQ for namedroppers@ops.ietf.org; Tue, 26 Aug 2003 23:34:05 +0000 Received: (qmail 29532 invoked by uid 1016); 26 Aug 2003 22:01:01 -0000 Date: 26 Aug 2003 22:01:01 -0000 Message-ID: <20030826220101.29531.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: wcard-clarify breaking RFC 2308 NXDOMAIN References: <20030820100735.39120ccd.olaf@ripe.net> <20030826024218.10706.qmail@cr.yp.to> <20030826141441.GK910@apb.cequrux.com> <20030826174447.46552.qmail@cr.yp.to> <20030826191956.72780.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-6.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward Lewis writes: > What part of your last message relates to wild card synthesis? What part of the wcard-clarify-01 statement ``A QNAME and QCLASS matching an existing node never results in a response return code of authoritative name error'' relates to wild card synthesis? Why does this document stray into a thicket of screwy definitions and discussions of no apparent relevance to wildcards? How can it possibly take 663 lines to say ``If there are records with owner names ending d.e.f, but no records with owner names ending c.d.e.f, then the only possible wildcard relevant to a.b.c.d.e.f is *.d.e.f''? Maybe it would help to settle the scope discussion first. I get the feeling that wcard-clarify would be quite a bit shorter if its scope were clarified. ---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 Tue Aug 26 23:05: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 XAA10563 for ; Tue, 26 Aug 2003 23:05:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19rqTo-0006o1-JK for namedroppers-data@psg.com; Wed, 27 Aug 2003 02:56:16 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.20) id 19rqTJ-0006iK-19 for namedroppers@ops.ietf.org; Wed, 27 Aug 2003 02:55:45 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 8640156F; Tue, 26 Aug 2003 22:55:44 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 2702153A; Tue, 26 Aug 2003 22:55:44 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1) with ESMTP id 591170; Tue, 26 Aug 2003 22:53:24 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <20030826220101.29531.qmail@cr.yp.to> References: <20030820100735.39120ccd.olaf@ripe.net> <20030826024218.10706.qmail@cr.yp.to> <20030826141441.GK910@apb.cequrux.com> <20030826174447.46552.qmail@cr.yp.to> <20030826191956.72780.qmail@cr.yp.to> <20030826220101.29531.qmail@cr.yp.to> Date: Tue, 26 Aug 2003 22:55:31 -0400 To: "D. J. Bernstein" From: Edward Lewis Subject: Re: wcard-clarify breaking RFC 2308 NXDOMAIN Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-5.4 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 22:01 +0000 8/26/03, D. J. Bernstein wrote: >Maybe it would help to settle the scope discussion first. I get the >feeling that wcard-clarify would be quite a bit shorter if its scope >were clarified. Life's too short to waste on this discussion. Being that this is a volunteer effort, I will not further this thread (feeling no compelling reason to do so) and will take editing action on this point only if directed to do so. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Sponge Bob Square Pants? I'm still trying to figure out the Macarena. -- to unsubscribe send a message to namedroppers-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 Aug 27 04:48: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 EAA07522 for ; Wed, 27 Aug 2003 04:48:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19rvlE-000JrI-Uv for namedroppers-data@psg.com; Wed, 27 Aug 2003 08:34:36 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.22) id 19rvkP-000J0h-6t for namedroppers@ops.ietf.org; Wed, 27 Aug 2003 08:33:46 +0000 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 h7R8W0B12293; Wed, 27 Aug 2003 15:32:01 +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 h7R8TbD15144; Wed, 27 Aug 2003 15:29:37 +0700 (ICT) From: Robert Elz To: "D. J. Bernstein" cc: namedroppers@ops.ietf.org Subject: Re: wcard-clarify breaking RFC 2308 NXDOMAIN In-Reply-To: <20030826174447.46552.qmail@cr.yp.to> References: <20030826174447.46552.qmail@cr.yp.to> <20030820100735.39120ccd.olaf@ripe.net> <20030826024218.10706.qmail@cr.yp.to> <20030826141441.GK910@apb.cequrux.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 27 Aug 2003 15:29:37 +0700 Message-ID: <15467.1061972977@munnari.OZ.AU> X-Spam-Status: No, hits=-3.0 required=5.0 tests=BAYES_20,IN_REP_TO,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: 26 Aug 2003 17:44:47 -0000 From: "D. J. Bernstein" Message-ID: <20030826174447.46552.qmail@cr.yp.to> | I specifically raised the NXDOMAIN-semantics issue here on 1999.12.08, | under the subject line ``sub.dom with cached NXDOMAIN dom.'' Actually, you specifically asked what a cache should do, which was definitely relevant to 2308. | Paul Vixie responded: I guess I must have skipped that message, as being a topic of no great interest but ... | RFC 2308 implicitly outlawed BIND's behaviour, "BIND's behaviour" wasn't the issue - as you pointed out in your earlier message, it is in the DNS spec. While it might be possible for a radom RFC to take some undefined case, and implicitly define it, so that an implementation that had adopted a different interpretation doesn't conform to the new spec, it is most certainly not possible for an RFC (which is dealingwith a different issue) to just "implicitly" define away a part of a standard. That would need to be done very explicitly. Furthermore, a message from Paul cannot possibly have the effect of giving status like that. | There wasn't even a whisper of disagreement. Probably because no-one was paying much attention. | Now, four years later, without any excuse, people here are suddenly | trying to retroactively change the NXDOMAIN semantics, No-one here is doing anything of the kind. You seem to have assumed, perhaps with some justification - though incorrectly - that the semantics changed 4 years ago. It is a little hard to believe that you really consider what at best (for your case) is definitely "implicit" in 2308, but which in reality isn't there at all, along with one e-mail message, can possibly have changed 1034. You'd be spitting rocks if someone tried a similar argument to justify an approach that you disagreed with - you even claim that some of 2181, which most people believe is just restating 1034 more clearly, and which is all very explicit, is wrong and should be ignored... | If there's some benefit of changing the NXDOMAIN semantics, then I'm | willing to discuss whether that benefit outweighs the costs. If there had been going to be a change in 1999, that would have been when that discussion would have been appropriate, would it not? Would you care to point out where that discussion was held? Or are you expecting us to believe that a (fairly significant) change to the DNS spec was done with no thought at all, but just, seemingly, by accident. This part of 1034 has never been changed. I have been told that bind 9 up to 9.2.2 got this wrong - that's not terribly surprising, those versions got a few other things wrong too. I haven't been able to yet test to see whether the 9.3 (still beta I think) versions fixed this one along with all the other stuff that got fixed there. If not, it needs to be. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 27 06:25: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 GAA13668 for ; Wed, 27 Aug 2003 06:25:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19rxL3-000MRO-KM for namedroppers-data@psg.com; Wed, 27 Aug 2003 10:15:41 +0000 Received: from [192.96.22.18] (helo=citadel.cequrux.com) by psg.com with esmtp (Exim 4.22) id 19rxJk-000L5f-Tp for namedroppers@ops.ietf.org; Wed, 27 Aug 2003 10:14:21 +0000 Received: (from nobody@localhost) by citadel.cequrux.com (8.8.8/8.6.9) id MAA16223 for ; Wed, 27 Aug 2003 12:14:16 +0200 (SAST) Received: by citadel.cequrux.com via recvmail id 16220; Wed, 27 Aug 2003 12:13:51 +0200 (SAST) Date: Wed, 27 Aug 2003 12:13:51 +0200 From: Alan Barrett To: namedroppers@ops.ietf.org Subject: Re: wcard-clarify breaking RFC 2308 NXDOMAIN Message-ID: <20030827101350.GN910@apb.cequrux.com> References: <20030820100735.39120ccd.olaf@ripe.net> <20030826024218.10706.qmail@cr.yp.to> <20030826141441.GK910@apb.cequrux.com> <20030826174447.46552.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030826174447.46552.qmail@cr.yp.to> X-Spam-Status: No, hits=-3.9 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 26 Aug 2003, D. J. Bernstein wrote: > I specifically raised the NXDOMAIN-semantics issue here on 1999.12.08, > under the subject line ``sub.dom with cached NXDOMAIN dom.'' Paul > Vixie responded: > > RFC 2308 implicitly outlawed BIND's behaviour, which is to return > NOERROR/ANCOUNT=0 for empty nonterminals. After RFC 2308, empty > nonterminals are signalled with NXDOMAIN. > > There wasn't even a whisper of disagreement. If Paul Vixie said that, he was wrong. His mistake does not amount to a change of the protocol. > Now, four years later, without any excuse, people here are suddenly > trying to retroactively change the NXDOMAIN semantics, prohibiting > the extremely widespread behavior of using NXDOMAIN for empty > nonterminals. You are trying to claim that the semantics changed in 1999. I don't blieve that the semantics changed in 1999. > If there's some benefit of changing the NXDOMAIN semantics, then I'm > willing to discuss whether that benefit outweighs the costs. I don't see any benefit to changing the semantics. As far as I can see, they were defined in RFC 1034, not changed in RFC 2308, and not changed in draft-ietf-wcard-clarify-01. > I am not, however, going to tolerate fraud. It's easy to interpret your claim that the semantics changed in 1999 as fraud. > The wcard-``clarify'' use of NXDOMAIN is _not_ how DNS works. _I_ am > not the one proposing changes to the DNS protocol. Yes, it it. Yes, you are. --apb (Alan Barrett) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 27 11:36: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 LAA09786 for ; Wed, 27 Aug 2003 11:36:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19s298-000K6w-GC for namedroppers-data@psg.com; Wed, 27 Aug 2003 15:23:42 +0000 Received: from [2001:4f8:3:bb:2e0:81ff:fe10:67ab] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.22) id 19s28K-000JyY-Dp for namedroppers@ops.ietf.org; Wed, 27 Aug 2003 15:22:52 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id A90CB139B2 for ; Wed, 27 Aug 2003 15:22:51 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: wcard-clarify breaking RFC 2308 NXDOMAIN In-Reply-To: Message from Alan Barrett of "Wed, 27 Aug 2003 12:13:51 +0200." <20030827101350.GN910@apb.cequrux.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 27 Aug 2003 15:22:51 +0000 Message-Id: <20030827152251.A90CB139B2@sa.vix.com> X-Spam-Status: No, hits=-3.4 required=5.0 tests=BAYES_20,IN_REP_TO,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > Vixie responded: > > > > RFC 2308 implicitly outlawed BIND's behaviour, which is to return > > NOERROR/ANCOUNT=0 for empty nonterminals. After RFC 2308, empty > > nonterminals are signalled with NXDOMAIN. > > > > There wasn't even a whisper of disagreement. > > If Paul Vixie said that, he was wrong. His mistake does not amount to a > change of the protocol. i did say it and i was wrong. -- to unsubscribe send a message to namedroppers-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 Aug 27 13:14: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 NAA18892 for ; Wed, 27 Aug 2003 13:14:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19s3iS-0007kC-6I for namedroppers-data@psg.com; Wed, 27 Aug 2003 17:04:16 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.22) id 19s3hw-0007eE-1v for namedroppers@ops.ietf.org; Wed, 27 Aug 2003 17:03:44 +0000 Received: (qmail 70610 invoked by uid 1016); 27 Aug 2003 17:12:24 -0000 Date: 27 Aug 2003 17:12:24 -0000 Message-ID: <20030827171224.70609.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: wcard-clarify violating RFC 2119, section 6 References: <20030826174447.46552.qmail@cr.yp.to> <20030820100735.39120ccd.olaf@ripe.net> <20030826024218.10706.qmail@cr.yp.to> <20030826141441.GK910@apb.cequrux.com> <15467.1061972977@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-3.5 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk RFC 2119 does not allow the IETF to poke its nose into private implementation issues: Imperatives of the type defined in this memo ... must not be used to try to impose a particular method on implementors where the method is not required for interoperability. Does anyone have an INTEROPERABILITY argument for the wcard-clarify restrictions? If not, those restrictions must be removed. Robert Elz writes: > it is most certainly not possible for an RFC (which is dealingwith a > different issue) to just "implicitly" define away a part of a standard. Are you trying to claim that RFC 2308 didn't change the DNS protocol? Here's an example of how RFC 2308's explicit requirements on caches implicitly allow extra behavior by servers: (1) Caches are explicitly prohibited---by RFC 2308---from applying NXDOMAIN except to the same (class and) name. (2) Caches do not, in fact, apply NXDOMAIN to subdomains. A huge number of servers use NXDOMAIN even when subdomains exist. (3) In light of #1 and #2, there is no interoperability excuse for discouraging or prohibiting the _server_ behavior. (4) Because of #3, discouraging or prohibiting the _server_ behavior would violate RFC 2119, section 6. (5) Therefore, wcard-clarify violates RFC 2119, section 6. I realize that RFC 2119 can't go back and fix RFC 1034, but it certainly applies to wcard-clarify. ---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 Aug 27 14:03: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 OAA22889 for ; Wed, 27 Aug 2003 14:03:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19s4Xn-000FNv-U8 for namedroppers-data@psg.com; Wed, 27 Aug 2003 17:57:19 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.22) id 19s4XI-000FEM-BE for namedroppers@ops.ietf.org; Wed, 27 Aug 2003 17:56:48 +0000 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 h7RHuZB05965; Thu, 28 Aug 2003 00:56:35 +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 h7RHuBD03824; Thu, 28 Aug 2003 00:56:15 +0700 (ICT) From: Robert Elz To: "D. J. Bernstein" cc: namedroppers@ops.ietf.org Subject: Re: wcard-clarify violating RFC 2119, section 6 In-Reply-To: <20030827171224.70609.qmail@cr.yp.to> References: <20030827171224.70609.qmail@cr.yp.to> <20030826174447.46552.qmail@cr.yp.to> <20030820100735.39120ccd.olaf@ripe.net> <20030826024218.10706.qmail@cr.yp.to> <20030826141441.GK910@apb.cequrux.com> <15467.1061972977@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 28 Aug 2003 00:56:11 +0700 Message-ID: <18758.1062006971@munnari.OZ.AU> X-Spam-Status: No, hits=-1.3 required=5.0 tests=BAYES_30,IN_REP_TO,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: 27 Aug 2003 17:12:24 -0000 From: "D. J. Bernstein" Message-ID: <20030827171224.70609.qmail@cr.yp.to> | RFC 2119 does not allow the IETF to poke its nose into private | implementation issues: RFC2119 does not put blinders on the IETF - any more than 1034 does, or 791, or anything else. 2119 is a bunch of definitions of some common words that it is generally better to use in a consistent way across RFCs, rather than, as was done before 2119, everyone having slightly different definitions which were different and confusing. The rules in 2119 apply to people who choose to use 2119, and specify how some words should be used. And then they apply only as much as the author/working-group decide not to override them. They do not constrain in any way what the working group can do. It is certainly worth pointing out where you believe that the usage of a 2119 word is inconsistent with its definition in 2119 - that's something for the WG to look at, and see if there is agreement that there is a difference, and second, whether the difference matters. If both are accepted, the word should be changed (and that kind of thing gets done a lot). If either isn't accepted, the word can stay. | Imperatives of the type defined in this memo ... must not be used to | try to impose a particular method on implementors where the method is | not required for interoperability. | | Does anyone have an INTEROPERABILITY argument for the wcard-clarify | restrictions? If you're talking in particular about the NXDOMAIN case, then clearly that does affect interoperability. It specifies the meaning of data that is carried over the wire, which must be understood correctly in order to be meaningful - this is the very essence of interoperability. That no implementations that we know about happen to care a lot one way or the other is irrelevant. | Are you trying to claim that RFC 2308 didn't change the DNS protocol? No, but for now, just because I haven't re-read all of it in order to verify that. What I was saying in the section that you quoted is that 2308 cannot make back-door changes (by implication) to 1034. Whatever it changed explicitly, that's fine (if there was anything). It most certainly did not change the specification that NODATA (the reply format that we use that pseudo-error-code to mean of course) is the correct reply for a query of an empty non-terminal. | Here's an example of how RFC 2308's explicit requirements on caches | implicitly allow extra behavior by servers: | | (1) Caches are explicitly prohibited---by RFC 2308---from applying | NXDOMAIN except to the same (class and) name. | (2) Caches do not, in fact, apply NXDOMAIN to subdomains. A huge | number of servers use NXDOMAIN even when subdomains exist. | (3) In light of #1 and #2, there is no interoperability excuse for | discouraging or prohibiting the _server_ behavior. Nonsense. 2308 only applies to caches - caches aren't the only users of DNS replies - resolvers get them too, 2308 doesn't apply at all to resolvers. If a resolver chooses to apply NXDOMAIN to sub-domains, it is absolutely permitted to do so. What's more, even beyond that, humans are consumers of DNS replies. And humans too are not bound by 2038. And I can assure you that I most certainly do assume that when I see a NXDOMAIN that there are no sub-domains. If your serrver is saying NXDOMAIN when sub-domains exist, then it is lying to me - causing me to fail to discover things that I would otherwise find (that is, if I ever happened to chance upon an implementation of your server in use anywhere, I haven't yet, that I know of). | (4) Because of #3, discouraging or prohibiting the _server_ behavior | would violate RFC 2119, section 6. False premise. | (5) Therefore, wcard-clarify violates RFC 2119, section 6. False premise. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 27 20:03: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 UAA20906 for ; Wed, 27 Aug 2003 20:03:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19sA4P-000OJe-8l for namedroppers-data@psg.com; Wed, 27 Aug 2003 23:51:21 +0000 Received: from [2001:470:1f00:ffff::5a1] (helo=bsdi.dv.isc.org) by psg.com with esmtp (Exim 4.22) id 19sA4M-000OJ4-9q for namedroppers@ops.ietf.org; Wed, 27 Aug 2003 23:51:18 +0000 Received: from bsdi.dv.isc.org (localhost.dv.isc.org [127.0.0.1]) by bsdi.dv.isc.org (8.12.9/8.12.9) with ESMTP id h7RNpFYf038176 for ; Thu, 28 Aug 2003 09:51:16 +1000 (EST) (envelope-from marka@bsdi.dv.isc.org) Message-Id: <200308272351.h7RNpFYf038176@bsdi.dv.isc.org> Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: wcard-clarify violating RFC 2119, section 6 In-reply-to: Your message of "27 Aug 2003 17:12:24 GMT." <20030827171224.70609.qmail@cr.yp.to> Date: Thu, 28 Aug 2003 09:51:15 +1000 X-Spam-Status: No, hits=-0.6 required=5.0 tests=BAYES_30,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > RFC 2119 does not allow the IETF to poke its nose into private > implementation issues: > > Imperatives of the type defined in this memo ... must not be used to > try to impose a particular method on implementors where the method is > not required for interoperability. > > Does anyone have an INTEROPERABILITY argument for the wcard-clarify > restrictions? If not, those restrictions must be removed. > > Robert Elz writes: > > it is most certainly not possible for an RFC (which is dealingwith a > > different issue) to just "implicitly" define away a part of a standard. > > Are you trying to claim that RFC 2308 didn't change the DNS protocol? > Here's an example of how RFC 2308's explicit requirements on caches > implicitly allow extra behavior by servers: > > (1) Caches are explicitly prohibited---by RFC 2308---from applying > NXDOMAIN except to the same (class and) name. All RFC 2308 say is that if you have a NXDOMAIN response for foo.example.net/IN/A then you can return that NXDOMAIN in response to a later query for foo.example.net/IN/MX. NXDOMAIN is independent of TYPE not CLASS. It does not say that you can synthesize a NXDOMAIN response for xxx.foo.example.net/IN/A based on a NXDOMAIN response for foo.example.net/IN/A. If you want RFC 2308 to say this we can deal with that when the WG looks at moving RFC 2308 from PS to DS. NODATA responses on the other hand are both TYPE and CLASS dependent. While RFC 2308 does not say this, you should be able to return a NODATA response to types other than ANY based on a NODATA response to ANY query. This is also RFC 2308bis fodder. For the record RFC 2535 failed to account for empty nodes in the tree. BIND 9 *was* following RFC 2535. BIND 9.2.3 onwards has reverted back to RFC 103[45]. BIND 8 always followed RFC 103[45] by returning NODATA responses to empty nodes. RFC 2535 implied that you always got a NXDOMAIN response between the ownername of a NXT record and the "next domain name". This lead to the ridiculous state of a "non existant" name influencing whether a wildcard match was made or not. I argued at the time that RFC 2535 was wrong, that empty nodes don't return NXDOMAIN. With RFC 2535 being replaced is it possible to correct this error. > (2) Caches do not, in fact, apply NXDOMAIN to subdomains. A huge > number of servers use NXDOMAIN even when subdomains exist. > (3) In light of #1 and #2, there is no interoperability excuse for > discouraging or prohibiting the _server_ behavior. > (4) Because of #3, discouraging or prohibiting the _server_ behavior > would violate RFC 2119, section 6. > (5) Therefore, wcard-clarify violates RFC 2119, section 6. > > I realize that RFC 2119 can't go back and fix RFC 1034, but it certainly > applies to wcard-clarify. > > ---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: -- 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 Aug 28 00:19: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 AAA13710 for ; Thu, 28 Aug 2003 00:19:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19sEAZ-0008gk-Pe for namedroppers-data@psg.com; Thu, 28 Aug 2003 04:13:59 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.22) id 19sE9Y-0008Qc-Ha for namedroppers@ops.ietf.org; Thu, 28 Aug 2003 04:12:56 +0000 Received: (qmail 26192 invoked by uid 1016); 28 Aug 2003 04:20:06 -0000 Date: 28 Aug 2003 04:20:06 -0000 Message-ID: <20030828042006.26191.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: wcard-clarify violating RFC 2119, section 6 References: <20030827171224.70609.qmail@cr.yp.to> <20030826174447.46552.qmail@cr.yp.to> <20030820100735.39120ccd.olaf@ripe.net> <20030826024218.10706.qmail@cr.yp.to> <20030826141441.GK910@apb.cequrux.com> <15467.1061972977@munnari.OZ.AU> <18758.1062006971@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-1.4 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Robert Elz writes: > The rules in 2119 apply to people who choose to use 2119 wcard-clarify-01: ``The key words ... are to be interpreted as described in ... [RFC2119].'' RFC 2119: ``Imperatives of the type defined in this memo ... must not be used to try to impose a particular method on implementors where the method is not required for interoperability.'' (I'm not going to bother responding to your idiotic assertion that ``required for interoperability'' means ``visible on the wire.'') Even if RFC 2119 didn't exist, having the IETF poke its nose into private implementation issues would violate United States antitrust law. > If a resolver chooses to apply NXDOMAIN to sub-domains, > it is absolutely permitted to do so. Wrong. That would (1) violate RFC 2308 and (2) fail to interoperate with existing servers. You're free to switch terminology---your competitors have ``caches'' while you have an ``apply-one-answer-to-another-query mechanism''---but your AOATAQ mechanism is, in fact, a cache, and has to obey the same rules as any other cache. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Aug 28 00:46: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 AAA16124 for ; Thu, 28 Aug 2003 00:46:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19sEah-000D6z-4X for namedroppers-data@psg.com; Thu, 28 Aug 2003 04:40:59 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.22) id 19sEaB-000D5L-5S for namedroppers@ops.ietf.org; Thu, 28 Aug 2003 04:40:27 +0000 Received: (qmail 54489 invoked by uid 1016); 28 Aug 2003 04:47:30 -0000 Date: 28 Aug 2003 04:47:30 -0000 Message-ID: <20030828044730.54488.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Cc: ietf@ietf.org Subject: Re: wcard-clarify breaking RFC 2308 NXDOMAIN References: <20030820100735.39120ccd.olaf@ripe.net> <20030826024218.10706.qmail@cr.yp.to> <20030826141441.GK910@apb.cequrux.com> <20030826174447.46552.qmail@cr.yp.to> <20030827101350.GN910@apb.cequrux.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-1.8 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Alan Barrett writes: > If Paul Vixie said that, ``After RFC 2308, empty nonterminals are signalled with NXDOMAIN.'' http://groups.google.com/groups?selm=199912080700.XAA18392%40bb.rc.vix.com > he was wrong. His mistake does not amount to a change of the protocol. Let me get this straight. After the BIND company (1) issues an RFC that clearly allows NXDOMAIN in this situation, (2) tells a new implementor that NXDOMAIN in this situation is fine, (3) publishes BIND 9, which uses NXDOMAIN in this situation, and (4) allows this use of NXDOMAIN to be deployed for four years, you think it's perfectly reasonable for the BIND company to change its mind and publish a new RFC saying---without a shred of justification--- that NXDOMAIN in this situation is prohibited? If the answer to my question in 1999 had been ``Don't use NXDOMAIN,'' I would have done the extra work to generate NODATA. But Vixie said that NXDOMAIN was allowed (in fact, required). So I used NXDOMAIN. Now, four years later, the BIND company is trying to force my users into a completely unnecessary patch cycle. If the BIND company wants to screw BIND users, I don't particularly care; but having the BIND company abuse the standards process to punish _my_ users is completely unacceptable. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Aug 28 05:52: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 FAA22969 for ; Thu, 28 Aug 2003 05:52:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19sJKn-000BrQ-VQ for namedroppers-data@psg.com; Thu, 28 Aug 2003 09:44:53 +0000 Received: from [192.96.22.18] (helo=citadel.cequrux.com) by psg.com with esmtp (Exim 4.22) id 19sJJr-000Bkl-Q7 for namedroppers@ops.ietf.org; Thu, 28 Aug 2003 09:43:56 +0000 Received: (from nobody@localhost) by citadel.cequrux.com (8.8.8/8.6.9) id LAA13097; Thu, 28 Aug 2003 11:43:48 +0200 (SAST) Received: by citadel.cequrux.com via recvmail id 13093; Thu, 28 Aug 2003 11:43:40 +0200 (SAST) Date: Thu, 28 Aug 2003 11:43:38 +0200 From: Alan Barrett To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org, ietf@ietf.org Subject: Re: wcard-clarify breaking RFC 2308 NXDOMAIN Message-ID: <20030828094338.GQ910@apb.cequrux.com> References: <20030820100735.39120ccd.olaf@ripe.net> <20030826024218.10706.qmail@cr.yp.to> <20030826141441.GK910@apb.cequrux.com> <20030826174447.46552.qmail@cr.yp.to> <20030827101350.GN910@apb.cequrux.com> <20030828044730.54488.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030828044730.54488.qmail@cr.yp.to> X-Spam-Status: No, hits=-3.9 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 28 Aug 2003, D. J. Bernstein wrote: > Let me get this straight. After the BIND company > > (1) issues an RFC that clearly allows NXDOMAIN in this situation, > (2) tells a new implementor that NXDOMAIN in this situation is fine, > (3) publishes BIND 9, which uses NXDOMAIN in this situation, and > (4) allows this use of NXDOMAIN to be deployed for four years, (1) did not happen. (2) was a mistake by one person, not by a company or the IETF. (3) is a bug in bind 9. (4) is a bug in bind 9. > you think it's perfectly reasonable for the BIND company to change its > mind and publish a new RFC saying---without a shred of justification--- > that NXDOMAIN in this situation is prohibited? Since the premises to not hold, the conclusion makes no sense. --apb (Alan Barrett) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Aug 28 05:52: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 FAA22970 for ; Thu, 28 Aug 2003 05:52:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19sJHT-000BRS-QA for namedroppers-data@psg.com; Thu, 28 Aug 2003 09:41:27 +0000 Received: from [192.96.22.18] (helo=citadel.cequrux.com) by psg.com with esmtp (Exim 4.22) id 19sJGv-000BQA-En for namedroppers@ops.ietf.org; Thu, 28 Aug 2003 09:40:53 +0000 Received: (from nobody@localhost) by citadel.cequrux.com (8.8.8/8.6.9) id LAA12949 for ; Thu, 28 Aug 2003 11:40:45 +0200 (SAST) Received: by citadel.cequrux.com via recvmail id 12906; Thu, 28 Aug 2003 11:40:04 +0200 (SAST) Date: Thu, 28 Aug 2003 11:40:03 +0200 From: Alan Barrett To: namedroppers@ops.ietf.org Subject: Re: wcard-clarify violating RFC 2119, section 6 Message-ID: <20030828094003.GP910@apb.cequrux.com> References: <20030827171224.70609.qmail@cr.yp.to> <20030826174447.46552.qmail@cr.yp.to> <20030820100735.39120ccd.olaf@ripe.net> <20030826024218.10706.qmail@cr.yp.to> <20030826141441.GK910@apb.cequrux.com> <15467.1061972977@munnari.OZ.AU> <18758.1062006971@munnari.OZ.AU> <20030828042006.26191.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030828042006.26191.qmail@cr.yp.to> X-Spam-Status: No, hits=-3.9 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 28 Aug 2003, D. J. Bernstein wrote: > (I'm not going to bother responding to your idiotic assertion that > ``required for interoperability'' means ``visible on the wire.'') That wasn't an idiotic assertion. The concept of interoperability is much broader than "interoperability with known present-day implementations of today's specifications". It also includes interoperability with potential future implementations of todays specifications, and interoperability with potential future implementations of potential future updated specifications. > > If a resolver chooses to apply NXDOMAIN to sub-domains, > > it is absolutely permitted to do so. > > Wrong. That would (1) violate RFC 2308 RFC 2308 appears to be silent on this issue. A reasonable interpretation of RFC 1034 would certainly permit the inference that NXDOMAIN also applies to subdomains. > and (2) fail to interoperate with existing servers. Yes, but the existing servers for which interoperation would fail (those that return NXDOMAIN for empty non-terminals) are out of compliance with the specification in RFC 1034. When there's a failure to interoperate, and one of he implementations is clearly out of compliance with the spec, it's usually (but not always) a good idea to change the non-compliant implementation to bring it into line. It is sometimes a good idea to change the specification, but that hasn't been demonstrated in this case. In this case, I think the right thing to do is: not change the specification; fix the broken implementations (bind9 and tinydns); somehow try to prevent similar misinterpretations of the specification from arising in future. --apb (Alan Barrett) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Aug 28 06: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 GAA24113 for ; Thu, 28 Aug 2003 06:02:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19sJUz-000DDx-5H for namedroppers-data@psg.com; Thu, 28 Aug 2003 09:55:25 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.22) id 19sJUT-000D7t-7o for namedroppers@ops.ietf.org; Thu, 28 Aug 2003 09:54:53 +0000 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 h7S9sgB02535; Thu, 28 Aug 2003 16:54:45 +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 h7S9rqa27599; Thu, 28 Aug 2003 16:53:52 +0700 (ICT) From: Robert Elz To: "D. J. Bernstein" cc: namedroppers@ops.ietf.org Subject: Re: wcard-clarify violating RFC 2119, section 6 In-Reply-To: <20030828042006.26191.qmail@cr.yp.to> References: <20030828042006.26191.qmail@cr.yp.to> <20030827171224.70609.qmail@cr.yp.to> <20030826174447.46552.qmail@cr.yp.to> <20030820100735.39120ccd.olaf@ripe.net> <20030826024218.10706.qmail@cr.yp.to> <20030826141441.GK910@apb.cequrux.com> <15467.1061972977@munnari.OZ.AU> <18758.1062006971@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 28 Aug 2003 16:53:52 +0700 Message-ID: <6845.1062064432@munnari.OZ.AU> X-Spam-Status: No, hits=-1.3 required=5.0 tests=BAYES_30,IN_REP_TO,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: 28 Aug 2003 04:20:06 -0000 From: "D. J. Bernstein" Message-ID: <20030828042006.26191.qmail@cr.yp.to> | Robert Elz writes: | > The rules in 2119 apply to people who choose to use 2119 | | wcard-clarify-01: ``The key words ... are to be interpreted as | described in ... [RFC2119].'' Yes, that's fine - as I said, you're free to argue that a particular usage of a word is in conflict with 2119, when 2119 is being used. The working group is free to decide to ignore your argument, 2119 is not a straight jacket. | (I'm not going to bother responding to your idiotic assertion that | ``required for interoperability'' means ``visible on the wire.'') If that was what I had said, you'd be right, that would be idiotic - but it wasn't what I said - what I said was that the meaning of something which is visible on the wire would clearly be needed for interoperability. You make that point yourself, indirectly, in another message (see below). But that isn't all of what "required for interoperability" means of course, there's more to it than that. | Even if RFC 2119 didn't exist, having the IETF poke its nose into | private implementation issues would violate United States antitrust law. This is not a private implementation issue, it is a question of what bits on the wire actually mean. NXDOMAIN means the name does not exist. A name that does not exist clearly cannot have sub-domains, it would have to exist for that to be true. That's the definition of the error code. It has nothing at all to do with how you choose to implement it, nor how anyone else does. | > If a resolver chooses to apply NXDOMAIN to sub-domains, | > it is absolutely permitted to do so. | | Wrong. That would (1) violate RFC 2308 It would do nothing of the kind. 2308 applies to caches, and what they return to resolvers. | and (2) fail to interoperate with existing servers. It would fail with some broken servers. I don't care. Those servers should be fixed. | You're free to switch terminology---your competitors have ``caches'' I have no competitors, DNS code is one thing I have never been involved in writing (the odd bug fix from time to time is about it). | while you have an ``apply-one-answer-to-another-query | mechanism''---but your AOATAQ mechanism is, in fact, a cache, and has to | obey the same rules as any other cache. Not in the 2308 sense it isn't. What 2308 says that can be done (it doesn't actually say that anything in this are cannot be, as I recall it), is that an NXDOMAIN response can be returned when a previous answer for the same name + class returned NXDOMAIN. If I am not returning NXDOMAIN, but simply not doing any more queries, there's no way that 2308 can apply. You're right, you can describe that as a cache - but it isn't the kind of cache that 2308 applies to. (Nor, for example, does 2308 apply to the processor (fast access to RAM) cache which may remember an answer and give it back later - the NXDOMAIN semantics we're discussing here aren't relevant, but timers are - but no-one expects the processor cache to understand DNS TTLs and invalidate itself if the DNS TTL times out.) djb@cr.yp.to said in a different message: | Let me get this straight. After the BIND company | (1) issues an RFC that clearly allows NXDOMAIN in this situation, | (2) tells a new implementor that NXDOMAIN in this situation is fine, | (3) publishes BIND 9, which uses NXDOMAIN in this situation, and | (4) allows this use of NXDOMAIN to be deployed for four years, | you think it's perfectly reasonable for the BIND company to change its mind | and publish a new RFC saying---without a shred of justification--- that | NXDOMAIN in this situation is prohibited? Huh? The BIND company (whatever that might be) does not get to make IETF standards. The IETF issued 2308, which does not clearly allow NXDOMAIN in this situation (you yourself claimed, at most, that it implied it as being possible - which is disputed anyway). (2) and (3) have nothing to do with most of us here, certainly not me, and I believe, not Alan Barrett, to whom this reply was addressed. Nothing Paul Vixie does or says in any way controls what I believe (neither he, nor any organisation he's been associated with, ever, has ever had any control over my actions). (4) no-one did that I know of, this is a relatively unusual case, and I suspect that most people simply never noticed it happening. Then, the IETF is now publishing an RFC which says what the IETF has always believed to be the state of affairs, whatever a small number of people may have believed. | If the answer to my question in 1999 had been ``Don't use NXDOMAIN,'' | I would have done the extra work to generate NODATA. But Vixie said | that NXDOMAIN was allowed (in fact, required). So I used NXDOMAIN. Yes, we know that, he made a mistake. What's less believable is that you could have seriously believed this. But never mind. Then this ... | Now, four years later, the BIND company is trying to force my users into a | completely unnecessary patch cycle. If the BIND company wants to screw BIND | users, I don't particularly care; but having the BIND company abuse the | standards process to punish _my_ users is completely unacceptable. ingnoring the "BIND company" invective, is what I referred to above. If there was no interoperability issue here, you'd simply ignore this completely (as you ignore other parts of the specification that you don't agree with). I have had enough of this absurd debate. The DNS has *never* allowed NXDOMAIN as a response to an empty non-terminal. The name exists, obviously, so claiming it does not would be absurd. That some implementors (and I am not counting you in this group) managed to confuse "name exists", with "RR attached to the name exists" is unfortunate, but there's zero chance that those implementation bugs, or your own deliberate choice, are going to change this part of the standard. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Aug 28 09:31: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 JAA13630 for ; Thu, 28 Aug 2003 09:31:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19sMjX-0002Bb-U2 for namedroppers-data@psg.com; Thu, 28 Aug 2003 13:22:39 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.22) id 19sMg4-0001ua-Ed for namedroppers@ops.ietf.org; Thu, 28 Aug 2003 13:19:04 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id E1C405AA; Thu, 28 Aug 2003 09:19:03 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 5715A4A9 for ; Thu, 28 Aug 2003 09:19:03 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1) with ESMTP id 595888; Thu, 28 Aug 2003 09:16:36 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: Date: Thu, 28 Aug 2003 09:19:05 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: half time report on wcard Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_20 version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk We're closing in on the half time of the last call on wcard clarify. (Yes, a bit early, but a long weekend is upcoming in my locale, and some folks are headed off to RIPE next week.) So far I've seen three comments on this document. 1) A question about why the label begins with 0b01. Apparently there's a mistake there (that I just caught). A normal label (length) begins with 00, not 01. Looking at RFC 1035, 4.1.4, it mentions 11 as being a compression pointer, 10 and 01 as being reserved. I can't find where 00 is defined - which is what should be in wcard clarify. "I just caught" - because I replied to the questioner with '01' is normal and he didn't balk. Apparently I was wrong then, I did just notice the mistake. 2) A question about the phrase "spirit nor intent" - don't the two mean the same thing? Spirit is mentioned because I'm trying to preserve, as much as I can, the flavor of 1034. (That's why I cut and paste it's words so much.) Intent means that there are no protocol changes proposed up until the WG asked to modify "applying a wild card while chasing a CNAME." Even that change appears to fit the intent of the original document though. 3) A comment about "NXDOMAIN," RFC 2308, and the phrase "A QNAME and QCLASS matching an existing node never results in a response return code of authoritative name error." I find that this comment is irrelevant to the document for a couple of reasons. For one, RFC 2308 isn't even referenced by this document, so any discussion relating to it and whether or not there's a conflict between 2308 and 1034 is out of scope. Secondly, the reason the sentence in question appears at all is to show how a changed definition of existence reads in the spirit of 1034. The sentence in question is verbatim from 1034 in a paragraph whose middle sentence has been altered. The middle sentence is relevant for discussion, the last one (the one in question) is there to provide context (and the spirit). In summary - if there is a discussion to be had here, this is the wrong last call to carry it out in. So, at the half way point I need to make sure I have the right label type indicator. Does anyone know where the label type of '00' is defined? I can't locate it in 1035. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Sponge Bob Square Pants? I'm still trying to figure out the Macarena. -- to unsubscribe send a message to namedroppers-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 Aug 28 09:59: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 JAA16025 for ; Thu, 28 Aug 2003 09:59:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19sNDe-0004WH-LS for namedroppers-data@psg.com; Thu, 28 Aug 2003 13:53:46 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.22) id 19sND8-0004Ux-Ka for namedroppers@ops.ietf.org; Thu, 28 Aug 2003 13:53:15 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 1C8CD4E61B; Thu, 28 Aug 2003 15:53:13 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id B3A8D4E5DE; Thu, 28 Aug 2003 15:53:12 +0200 (CEST) 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 h7SDrCWt006095; Thu, 28 Aug 2003 15:53:12 +0200 Date: Thu, 28 Aug 2003 15:53:12 +0200 From: "Olaf M. Kolkman" To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: half time report on wcard Message-Id: <20030828155312.4d8a3632.olaf@ripe.net> In-Reply-To: References: Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.0 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.500262 X-RIPE-Signature: 47e629e2e260de5d32c418a78620cad9 X-Spam-Status: No, hits=-1.7 required=5.0 tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > So, at the half way point I need to make sure I have the right label > type indicator. Does anyone know where the label type of '00' is > defined? I can't locate it in 1035. Is this what you are looking for: 1035 section 3.1 1st paragraph The high order two bits of every length octet must be zero, and the remaining six bits of the length field limit the label to 63 octets or less. -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-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 Aug 28 10:12: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 KAA17890 for ; Thu, 28 Aug 2003 10:12:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19sNQU-0005k3-R5 for namedroppers-data@psg.com; Thu, 28 Aug 2003 14:07:02 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.22) id 19sNPK-0005eY-TH for namedroppers@ops.ietf.org; Thu, 28 Aug 2003 14:05:51 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 611FB701; Thu, 28 Aug 2003 10:05:50 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 024BF6E4; Thu, 28 Aug 2003 10:05:50 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1) with ESMTP id 596070; Thu, 28 Aug 2003 10:03:22 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <20030828155312.4d8a3632.olaf@ripe.net> References: <20030828155312.4d8a3632.olaf@ripe.net> Date: Thu, 28 Aug 2003 10:05:50 -0400 To: "Olaf M. Kolkman" From: Edward Lewis Subject: Re: half time report on wcard Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Yeah. I thought/knew it was in there, but couldn't find the right grep to pull it up when I looked. At 15:53 +0200 8/28/03, Olaf M. Kolkman wrote: >Is this what you are looking for: > > 1035 section 3.1 1st paragraph -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Sponge Bob Square Pants? I'm still trying to figure out the Macarena. -- to unsubscribe send a message to namedroppers-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 Aug 28 10:53: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 KAA21471 for ; Thu, 28 Aug 2003 10:53:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19sNyq-0008YU-Am for namedroppers-data@psg.com; Thu, 28 Aug 2003 14:42:32 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.22) id 19sNyK-0008Va-19 for namedroppers@ops.ietf.org; Thu, 28 Aug 2003 14:42:00 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 4E8214E187; Thu, 28 Aug 2003 16:41:59 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id DBC464E12C; Thu, 28 Aug 2003 16:41:58 +0200 (CEST) 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 h7SEfwWt019450; Thu, 28 Aug 2003 16:41:58 +0200 Date: Thu, 28 Aug 2003 16:41:58 +0200 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Cc: Edward Lewis Subject: Re: half time report on wcard Message-Id: <20030828164158.2f977ac8.olaf@ripe.net> In-Reply-To: References: Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.0 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.480819 X-RIPE-Signature: 20ff419ea8ab6c4782ff10f43f251637 X-Spam-Status: No, hits=-3.9 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 28 Aug 2003 09:19:05 -0400 Edward Lewis wrote: (...) > > In summary - if there is a discussion to be had here, this is the > wrong last call to carry it out in. > It is important to acknowledge that the critique on the draft was that the draft supposedly introduced incompatibility with other documents. The argument currently ongoing is whether or not that critique is correct and/or relevant, that discussion is IMHO still within scope of the last call. However, unless new arguments are brought to the table the discussion on NXDOMAIN, RFC 2308 and incompatibilities is to be concluded. I propose that participants summarize their arguments on this matter and not further react on the mails on this particular subject. Please let us not repeat arguments ad-infinitum, remain courteous and try to focus on the document at hand. I would like to repeat the call to provide motivated support or opposition to the document or, if there is critique, provide motivation and alternative text. -- Olaf Kolkman DNSEXT Co-Chair. -- to unsubscribe send a message to namedroppers-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 Aug 28 11:22: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 LAA23646 for ; Thu, 28 Aug 2003 11:22:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19sOWp-000BWV-1G for namedroppers-data@psg.com; Thu, 28 Aug 2003 15:17:39 +0000 Received: from [2001:4f8:3:bb:2e0:81ff:fe10:67ab] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.22) id 19sOWn-000BWI-AD for namedroppers@ops.ietf.org; Thu, 28 Aug 2003 15:17:37 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id D14DB139C1; Thu, 28 Aug 2003 15:17:36 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org, ietf@ietf.org Subject: Re: wcard-clarify breaking RFC 2308 NXDOMAIN In-Reply-To: Message from Alan Barrett of "Thu, 28 Aug 2003 11:43:38 +0200." <20030828094338.GQ910@apb.cequrux.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 28 Aug 2003 15:17:36 +0000 Message-Id: <20030828151736.D14DB139C1@sa.vix.com> X-Spam-Status: No, hits=-1.7 required=5.0 tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > (3) publishes BIND 9, which uses NXDOMAIN in this situation, and > (3) is a bug in bind 9. which version/versions, specifically? see below. --- ;; ANSWER SECTION: version.bind. 0 CH TXT "9.3.0a0" --- ;; QUESTION SECTION: ;this.example.vix.com. IN A ;; AUTHORITY SECTION: example.vix.com. 3600 IN SOA example.vix.com. root.vix.com. 2003082602 1800 900 604800 86400 --- #fh:i386# grep this example.vix.com test.a.is.this A 127.0.0.5 --- i don't know why any of you is bothering to refute bernstein's assertions, or even respond to him, or even read his tripe. however, do consider the likelihood of him defending my prior comments had he DISAGREED with them, and also consider that whilest i did in fact misunderstand/misread RFC2308, several other members of what bernstein laughably calls "the bind company", notably the author of rfc2308 and a coauthor of the current wildcard draft, have views remarkably different than the one bernstein quotes me as having. can we have some serious discourse 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 Aug 28 14:17: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 OAA06497 for ; Thu, 28 Aug 2003 14:17:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19sR7u-000OTH-Ov for namedroppers-data@psg.com; Thu, 28 Aug 2003 18:04:06 +0000 Received: from [17.254.0.51] (helo=mail-out2.apple.com) by psg.com with esmtp (Exim 4.22) id 19sR7O-000ORw-Rd for namedroppers@ops.ietf.org; Thu, 28 Aug 2003 18:03:34 +0000 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.12.9/8.12.9) with ESMTP id h7SI3XiZ017214 for ; Thu, 28 Aug 2003 11:03:33 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 28 Aug 2003 11:03:08 -0700 Received: from [17.202.44.119] (chesh7.apple.com [17.202.44.119]) by scv2.apple.com (8.12.9/8.12.9) with SMTP id h7SI3OWI021630 for ; Thu, 28 Aug 2003 11:03:24 -0700 (PDT) Message-Id: <200308281803.h7SI3OWI021630@scv2.apple.com> Subject: LLMNR interoperability with Rendezvous? Date: Thu, 28 Aug 2003 11:03:35 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-transfer-encoding: quoted-printable X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I'm asking this question at the suggestion of =D3lafur Gudmundsson. Is there any interest in this working group in making LLMNR interoperate with Rendezvous? In addition to Mac OS 9 and OS X, there's Rendezvous for Linux, Windows, VxWorks and other platforms. There are Rendezvous network printers, network scanners, headless Rendezvous file servers, consumer electronics home Hi-Fi equipment, home media servers, and so on. LLMNR could interoperate with that installed base with only a few trivial changes, but the will to make those changes depends on whether the working group has any interest in interoperability. Opinions? Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Aug 28 14:33: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 OAA07404 for ; Thu, 28 Aug 2003 14:33:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19sRTu-0000HA-6P for namedroppers-data@psg.com; Thu, 28 Aug 2003 18:26:50 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.22) id 19sRTO-0000Fz-4C for namedroppers@ops.ietf.org; Thu, 28 Aug 2003 18:26:18 +0000 Received: (qmail 2290 invoked by uid 1016); 28 Aug 2003 18:29:22 -0000 Date: 28 Aug 2003 18:29:22 -0000 Message-ID: <20030828182922.2289.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: half time report on wcard References: <20030828164158.2f977ac8.olaf@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-1.4 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Olaf M. Kolkman writes: > alternative text The alternative to this particular RFC 2119 violation is to simply omit the offending sentence from the document. Wildcards have exactly the same semantics whether or not these NXDOMAINs are allowed. Why did wcard-clarify stray into NXDOMAIN issues in the first place? Why have we still not heard a clear statement of the scope of wcard-clarify? I had assumed that this was a matter of poor communication, but now I'm getting the feeling that the _authors_ don't have a clear idea of what their document was supposed to cover. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Aug 28 14:39: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 OAA07703 for ; Thu, 28 Aug 2003 14:39:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19sRZe-0000in-RI for namedroppers-data@psg.com; Thu, 28 Aug 2003 18:32:46 +0000 Received: from [2001:4f8:3:bb:2e0:81ff:fe10:67ab] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.22) id 19sRZd-0000iY-Nm for namedroppers@ops.ietf.org; Thu, 28 Aug 2003 18:32:45 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 69B68139B2 for ; Thu, 28 Aug 2003 18:32:45 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: LLMNR interoperability with Rendezvous? In-Reply-To: Message from Stuart Cheshire of "Thu, 28 Aug 2003 11:03:35 MST." <200308281803.h7SI3OWI021630@scv2.apple.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 28 Aug 2003 18:32:45 +0000 Message-Id: <20030828183245.69B68139B2@sa.vix.com> X-Spam-Status: No, hits=-3.0 required=5.0 tests=BAYES_20,IN_REP_TO version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk yes. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Aug 28 15:04: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 PAA09386 for ; Thu, 28 Aug 2003 15:04:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19sRx2-00030w-RI for namedroppers-data@psg.com; Thu, 28 Aug 2003 18:56:56 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.22) id 19sRwX-0002yM-1R for namedroppers@ops.ietf.org; Thu, 28 Aug 2003 18:56:25 +0000 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 205CA18DC for ; Thu, 28 Aug 2003 14:56:11 -0400 (EDT) Date: Thu, 28 Aug 2003 14:56:11 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: LLMNR interoperability with Rendezvous? In-Reply-To: <200308281803.h7SI3OWI021630@scv2.apple.com> References: <200308281803.h7SI3OWI021630@scv2.apple.com> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030828185611.205CA18DC@thrintun.hactrn.net> X-Spam-Status: No, hits=-3.9 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Thu, 28 Aug 2003 11:03:35 -0700, Stuart Cheshire wrote: > > LLMNR could interoperate with that installed base with only a few trivial > changes, but the will to make those changes depends on whether the > working group has any interest in interoperability. If the differences are in fact trivial, yes, but let's see the proposal before making that judgement. -- to unsubscribe send a message to namedroppers-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 Aug 28 15:07: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 PAA09789 for ; Thu, 28 Aug 2003 15:07:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19sRzZ-0003JO-FA for namedroppers-data@psg.com; Thu, 28 Aug 2003 18:59:33 +0000 Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.22) id 19sRy9-00037B-Pz for namedroppers@ops.ietf.org; Thu, 28 Aug 2003 18:58:05 +0000 Received: from depa.dmes.org (dialup-171.75.163.11.Dial1.Boston1.Level3.net [171.75.163.11]) by toccata.fugue.com (Postfix) with ESMTP id 30E2D1B2726; Thu, 28 Aug 2003 13:43:35 -0500 (CDT) From: Ted Lemon To: Stuart Cheshire , Subject: Re: LLMNR interoperability with Rendezvous? Date: Thu, 28 Aug 2003 14:57:02 -0400 User-Agent: KMail/1.5 References: <200308281803.h7SI3OWI021630@scv2.apple.com> In-Reply-To: <200308281803.h7SI3OWI021630@scv2.apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200308281457.02898.mellon@nominum.com> X-Spam-Status: No, hits=-5.2 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_NJABL,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thursday 28 August 2003 14:03, Stuart Cheshire wrote: > LLMNR could interoperate with that installed base with only a few trivial > changes, but the will to make those changes depends on whether the > working group has any interest in interoperability. It would be disappointing, to say the least, if LLMNR and Rendezvous didn't interoperate. -- to unsubscribe send a message to namedroppers-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 Aug 28 15:43: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 PAA12161 for ; Thu, 28 Aug 2003 15:43:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19sSX6-0006AQ-Eq for namedroppers-data@psg.com; Thu, 28 Aug 2003 19:34:12 +0000 Received: from [207.65.203.98] (helo=goose.ehsco.com) by psg.com with esmtp (Exim 4.22) id 19sSX1-0006A7-UC for namedroppers@ops.ietf.org; Thu, 28 Aug 2003 19:34:08 +0000 Received: from [207.65.3.26] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 4.1) with ESMTP-TLS id 480141; Thu, 28 Aug 2003 14:34:12 -0500 Message-ID: <3F4E592C.9030007@ehsco.com> Date: Thu, 28 Aug 2003 14:34:04 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Stuart Cheshire CC: namedroppers@ops.ietf.org Subject: Re: LLMNR interoperability with Rendezvous? References: <200308281803.h7SI3OWI021630@scv2.apple.com> In-Reply-To: <200308281803.h7SI3OWI021630@scv2.apple.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.3 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MOZILLA_UA version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 8/28/2003 1:03 PM Stuart Cheshire wrote: > LLMNR could interoperate with that installed base with only a few > trivial changes, but the will to make those changes depends on whether > the working group has any interest in interoperability. Lacking any specifics, yes, it would be a good thing. What are the necessary changes? -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Aug 28 15: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 PAA13376 for ; Thu, 28 Aug 2003 15:56:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19sSjK-0007IT-BM for namedroppers-data@psg.com; Thu, 28 Aug 2003 19:46:50 +0000 Received: from [3ffe:b80:2:a90::2] (helo=hades.pp.htv.fi) by psg.com with esmtp (Exim 4.22) id 19sSil-0007Fi-2T for namedroppers@ops.ietf.org; Thu, 28 Aug 2003 19:46:15 +0000 Received: from hades.pp.htv.fi (liljeber@localhost [127.0.0.1]) by hades.pp.htv.fi (8.12.9/8.12.9/Debian-5) with ESMTP id h7SJm2bO029969; Thu, 28 Aug 2003 22:48:02 +0300 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.9/8.12.9/Debian-5) id h7SJm0HH029968; Thu, 28 Aug 2003 22:48:00 +0300 X-Authentication-Warning: hades.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LLMNR interoperability with Rendezvous? From: Mika Liljeberg To: Rob Austein Cc: namedroppers@ops.ietf.org In-Reply-To: <20030828185611.205CA18DC@thrintun.hactrn.net> References: <200308281803.h7SI3OWI021630@scv2.apple.com> <20030828185611.205CA18DC@thrintun.hactrn.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1062100080.9714.293.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Thu, 28 Aug 2003 22:48:00 +0300 X-Spam-Status: No, hits=-7.0 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_XIMIAN, X_AUTH_WARNING autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 2003-08-28 at 21:56, Rob Austein wrote: > If the differences are in fact trivial, yes, but let's see the > proposal before making that judgement. My thoughts exactly. 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 Thu Aug 28 19:57: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 TAA01596 for ; Thu, 28 Aug 2003 19:57:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19sWVZ-0001pi-2F for namedroppers-data@psg.com; Thu, 28 Aug 2003 23:48:53 +0000 Received: from [205.150.200.166] (helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 4.22) id 19sWU8-0001jX-RE for namedroppers@ops.ietf.org; Thu, 28 Aug 2003 23:47:24 +0000 Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [205.150.200.247]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h7SNk2d29805 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Thu, 28 Aug 2003 19:46:08 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h7SNk139005117 for ; Thu, 28 Aug 2003 19:46:02 -0400 To: namedroppers@ops.ietf.org Subject: Re: LLMNR interoperability with Rendezvous? In-reply-to: Your message of "Thu, 28 Aug 2003 11:03:35 PDT." <200308281803.h7SI3OWI021630@scv2.apple.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 28 Aug 2003 19:46:01 -0400 Message-ID: <5116.1062114361@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Status: No, hits=-1.3 required=5.0 tests=BAYES_30,IN_REP_TO version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Having little personal experience with Rendezvous or LLMNR, or desire to use either of them, I'd say that they should interoperate. Now that I know there are more than OS X using it, maybe I'll encounter it. ] Out and about in Ottawa. hmmm... beer. | 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/notebook using, kernel hacking, security guy"); [ -- to unsubscribe send a message to namedroppers-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 Aug 28 20:03: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 UAA02046 for ; Thu, 28 Aug 2003 20:03:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19sWcV-0002VY-6t for namedroppers-data@psg.com; Thu, 28 Aug 2003 23:56:03 +0000 Received: from [144.189.100.102] (helo=motgate4.mot.com) by psg.com with esmtp (Exim 4.22) id 19sWbz-0002UM-9e for namedroppers@ops.ietf.org; Thu, 28 Aug 2003 23:55:31 +0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h7SNtUGq021390 for ; Thu, 28 Aug 2003 16:55:30 -0700 (MST) Received: from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id h7SNtDYA007350 for ; Thu, 28 Aug 2003 18:55:16 -0500 Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.9/8.12.8) with ESMTP id h7SNtNcB014216; Fri, 29 Aug 2003 09:55:24 +1000 (EST) Message-ID: <3F4E966B.8080909@motorola.com> Date: Fri, 29 Aug 2003 09:55:23 +1000 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stuart Cheshire CC: namedroppers@ops.ietf.org Subject: Re: LLMNR interoperability with Rendezvous? References: <200308281803.h7SI3OWI021630@scv2.apple.com> In-Reply-To: <200308281803.h7SI3OWI021630@scv2.apple.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-3.9 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Stuart Cheshire wrote: > LLMNR could interoperate with that installed base with only a few trivial > changes, but the will to make those changes depends on whether the > working group has any interest in interoperability. I think that would be a useful thing to achieve. Some details spelling out what needs to be changed would help. - aidan -- to unsubscribe send a message to namedroppers-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 Aug 28 21:06: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 VAA07548 for ; Thu, 28 Aug 2003 21:06:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19sXbC-0007zN-CJ for namedroppers-data@psg.com; Fri, 29 Aug 2003 00:58:46 +0000 Received: from [127.0.0.1] (helo=roam.psg.com) by psg.com with esmtp (Exim 4.22) id 19sXbB-0007zA-0G; Fri, 29 Aug 2003 00:58:45 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.22) id 19sXbA-000Gkq-8g; Fri, 29 Aug 2003 09:58:44 +0900 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 29 Aug 2003 09:58:43 +0900 To: Stuart Cheshire Cc: Subject: Re: LLMNR interoperability with Rendezvous? References: <200308281803.h7SI3OWI021630@scv2.apple.com> Message-Id: X-Spam-Status: No, hits=-5.1 required=5.0 tests=BAYES_10,QUOTED_EMAIL_TEXT,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Is there any interest in this working group in making LLMNR interoperate > with Rendezvous? sure. what changes will be needed in rendezvous? 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 Aug 28 21:09: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 VAA07924 for ; Thu, 28 Aug 2003 21:09:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19sXfy-0008PL-D2 for namedroppers-data@psg.com; Fri, 29 Aug 2003 01:03:42 +0000 Received: from [2001:470:1f00:ffff::5a1] (helo=bsdi.dv.isc.org) by psg.com with esmtp (Exim 4.22) id 19sXfw-0008P9-P6 for namedroppers@ops.ietf.org; Fri, 29 Aug 2003 01:03:41 +0000 Received: from bsdi.dv.isc.org (localhost.dv.isc.org [127.0.0.1]) by bsdi.dv.isc.org (8.12.9/8.12.9) with ESMTP id h7T139Yf043800; Fri, 29 Aug 2003 11:03:09 +1000 (EST) (envelope-from marka@bsdi.dv.isc.org) Message-Id: <200308290103.h7T139Yf043800@bsdi.dv.isc.org> To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: half time report on wcard In-reply-to: Your message of "28 Aug 2003 18:29:22 GMT." <20030828182922.2289.qmail@cr.yp.to> Date: Fri, 29 Aug 2003 11:03:09 +1000 X-Spam-Status: No, hits=-0.6 required=5.0 tests=BAYES_30,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Olaf M. Kolkman writes: > > alternative text > > The alternative to this particular RFC 2119 violation is to simply omit > the offending sentence from the document. Wildcards have exactly the > same semantics whether or not these NXDOMAINs are allowed. > > Why did wcard-clarify stray into NXDOMAIN issues in the first place? Why > have we still not heard a clear statement of the scope of wcard-clarify? > I had assumed that this was a matter of poor communication, but now I'm > getting the feeling that the _authors_ don't have a clear idea of what > their document was supposed to cover. Wildcards are stopped by existing names. If you change what names exist you changes what queries match the wildcard. So to clarify wildcards you also have to clarify what names exist. For the record it is RFC 2535 Section 5.1 that is problematical. "The presence of the NXT RR means that no name between its owner name and the name in its RDATA area exists and that no other types exist under its owner name." This fails to account for empty nodes in the tree. -- 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 Fri Aug 29 04: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 EAA24868 for ; Fri, 29 Aug 2003 04:01:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19sdxu-0005kI-Gk for namedroppers-data@psg.com; Fri, 29 Aug 2003 07:46:38 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.22) id 19sdwy-0005fY-VS for namedroppers@ops.ietf.org; Fri, 29 Aug 2003 07:45:41 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 5A3204E704; Fri, 29 Aug 2003 09:45:40 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 7FD114E6F9; Fri, 29 Aug 2003 09:45:39 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.9/8.11.6) with ESMTP id h7T7jcWt003969; Fri, 29 Aug 2003 09:45:39 +0200 Message-Id: <200308290745.h7T7jcWt003969@birch.ripe.net> To: Stuart Cheshire Cc: namedroppers@ops.ietf.org Subject: Re: LLMNR interoperability with Rendezvous? In-Reply-To: Message from Stuart Cheshire of "Thu, 28 Aug 2003 11:03:35 PDT." <200308281803.h7SI3OWI021630@scv2.apple.com> Date: Fri, 29 Aug 2003 09:45:38 +0200 From: Olaf Kolkman X-RIPE-Spam-Status: N 0.499346 X-RIPE-Signature: 0a52137eeefb72357f85191050fe7441 X-Spam-Status: No, hits=-1.3 required=5.0 tests=BAYES_30,IN_REP_TO version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Stuart Cheshire writes: * I'm asking this question at the suggestion of Ólafur Gudmundsson. Stuart and other namedroppers, On Thu, 28 Aug 2003 11:03:35 -0700 Stuart Cheshire wrote: * I'm asking this question at the suggestion of Ólafur Gudmundsson. Allow me to quote what we - chairs - wrote to you privately and then propose a process to keep impulse and get a satisfying protocol as working-group result. Dear Stuart, The question if the document should be made interoperable with Rendezvous should be asked to the mailing list so that the working group can decide. However, the document went through numerous cycles during which issues where thoroughly discussed. The issue of the TTL=1 has review from the working group and that issue is not to be opened again. If LLMNR and Rendezvous can be made compatible without reopening old issues, and the working group wants to pursue, we will allow further discussion. If there are items, that went through working group review and have been decided upon (such as the TTL issue) and are prohibiting compatibility than we am afraid that we will have to submit the document to the IESG as-is. The issues discussed and resolved can be found at http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html If you can provide the working group a list of 'original' issues that need to be addressed to make the protocol compatible with rendezvous and the working group is happy to address these we can continue working on the draft. From a working group perspective the work is otherwise done; we cannot go back and revisit the issues. We would be happy to add to our last call report that similar work is ongoing. -- Olaf Kolkman and Olafur Gudmundsson DNSEXT Chairs Our proposal: Stuart, please provide the working group with a list with issues previously not discussed and a separate list of items that have been discussed. Please provide that list before the end of next week (Sep 7). From the list of issues that already have been discussed and decided upon we propose you provide a technical motivation for the choices that were made for rendezvous and the reason why they cannot be brought in-line with the draft. If there are incompatibilities with rendezvous and the draft that can be fixed by fixing rendezvous, it would be nice to know about. We will give the document editors the opportunity to argue that changing the text to achieve compatibility is not trivial (a pointer to the archives, and maybe a 2 line abstract, is sufficient). After that we will ask the working group if there is consensus to 'the list and the motivations justifying review'. We will default to 'no consensus for justification' if there is no, or too little, response to that question. The list of original issues is open to discussion, no question, but that is only relevant if the review of old issues accepted by the group. This document has been on the table for quite some time, issues brought up where extremely well managed by the document editors. We do not want to see the document stalled because of late participation in the process; revisiting closed items is not productive. -- Olaf Kolkman and Olafur Gudmundsson DNSEXT Chairs -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Aug 29 05:36: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 FAA03692 for ; Fri, 29 Aug 2003 05:36:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19sfaH-000Elh-HQ for namedroppers-data@psg.com; Fri, 29 Aug 2003 09:30:21 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.22) id 19sfZd-000Egb-CF for namedroppers@ops.ietf.org; Fri, 29 Aug 2003 09:29:41 +0000 From: Masataka Ohta Message-Id: <200308290914.SAA01873@necom830.hpcl.titech.ac.jp> Received: from mohta@localhost by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id SAA01873; Fri, 29 Aug 2003 18:14:15 +0900 Subject: Re: LLMNR interoperability with Rendezvous? In-Reply-To: <200308290745.h7T7jcWt003969@birch.ripe.net> from Olaf Kolkman at "Aug 29, 2003 09:45:38 am" To: Olaf Kolkman Date: Fri, 29 Aug 2003 18:14:12 +0859 () CC: Stuart Cheshire , namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_20,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2 version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk It seems to me that the question should be whether the protocol called Rendezvous is good enough or not. If it is not, we should keep LLMNR, which may or may not interoperate with Rendezvous. If it is, we should simply use it and abandon LLMNR. 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 Fri Aug 29 11:25: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 LAA02586 for ; Fri, 29 Aug 2003 11:25:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19skwV-000Gcx-Ch for namedroppers-data@psg.com; Fri, 29 Aug 2003 15:13:39 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.22) id 19skvZ-000GWA-Kz for namedroppers@ops.ietf.org; Fri, 29 Aug 2003 15:12:41 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id CC059139A3 for ; Fri, 29 Aug 2003 15:12:40 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: LLMNR interoperability with Rendezvous? In-Reply-To: Message from Masataka Ohta of "Fri, 29 Aug 2003 18:14:12 +0859." <200308290914.SAA01873@necom830.hpcl.titech.ac.jp> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 29 Aug 2003 15:12:40 +0000 Message-Id: <20030829151240.CC059139A3@sa.vix.com> X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > It seems to me that the question should be whether the protocol > called Rendezvous is good enough or not. > > If it is not, we should keep LLMNR, which may or may not interoperate > with Rendezvous. > > If it is, we should simply use it and abandon LLMNR. as a proponent of the DISCOVER opcode, i have some sympathy for the above position. however, rendezvous and llmnr are not merely different ways to accomplish the same thing... they accomplish different things. for example when selecting a printer or file server, apple's macos/x users see the list of available resources instantly when they bring up a "chooser" panel; this is because the services periodically solicit themselves in some multicast kind of way. to do resource discovery of this kind with llmnr would mean a short delay when the panel was being initialized, while all relevant servers and printers heard a query and sent a reply. i do not think that apple would consider llmnr a successful replacement for rendezvous as long as this feature difference existed. i think it's clear that "architecture" did not happen with regard to dns and multicast. so i really do have sympathy for the above position. -- to unsubscribe send a message to namedroppers-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 Aug 29 11:48: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 LAA04946 for ; Fri, 29 Aug 2003 11:48:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19slP1-000Jni-SH for namedroppers-data@psg.com; Fri, 29 Aug 2003 15:43:07 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.22) id 19slNr-000JfS-VR for namedroppers@ops.ietf.org; Fri, 29 Aug 2003 15:41:56 +0000 Received: (qmail 88226 invoked by uid 1016); 29 Aug 2003 15:41:29 -0000 Date: 29 Aug 2003 15:41:29 -0000 Message-ID: <20030829154129.88222.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: half time report on wcard References: <20030828182922.2289.qmail@cr.yp.to> <200308290103.h7T139Yf043800@bsdi.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-1.8 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mark.Andrews@isc.org writes: > to clarify wildcards you also have to clarify what names exist Wrong. There are dozens of ways to say A wildcard record *.Y applies to a query name X if (1) Y is not equal to X and (2) Y is the longest suffix of X for which there are records (of any type) whose domain names end with Y. Otherwise *.Y does not apply to X. Examples: ... without giving a screwy definition of ``existence'' and without touching the semantics of NXDOMAIN. ---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 Fri Aug 29 14:09: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 OAA19562 for ; Fri, 29 Aug 2003 14:09:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19snXn-0007MR-TU for namedroppers-data@psg.com; Fri, 29 Aug 2003 18:00:19 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.22) id 19snXF-0007GS-CQ for namedroppers@ops.ietf.org; Fri, 29 Aug 2003 17:59:45 +0000 From: Masataka Ohta Message-Id: <200308291747.CAA01969@necom830.hpcl.titech.ac.jp> Received: from mohta@localhost by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id CAA01969; Sat, 30 Aug 2003 02:47:19 +0900 Subject: Re: LLMNR interoperability with Rendezvous? In-Reply-To: <20030829151240.CC059139A3@sa.vix.com> from Paul Vixie at "Aug 29, 2003 03:12:40 pm" To: Paul Vixie Date: Sat, 30 Aug 2003 02:47:18 +0859 () CC: namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul; > > It seems to me that the question should be whether the protocol > > called Rendezvous is good enough or not. > > > > If it is not, we should keep LLMNR, which may or may not interoperate > > with Rendezvous. > > > > If it is, we should simply use it and abandon LLMNR. > > as a proponent of the DISCOVER opcode, i have some sympathy for the above > position. however, rendezvous and llmnr are not merely different ways to > accomplish the same thing... they accomplish different things. A problem is that it is often the case that some of the accomplished thing may not be so useful that they should be compared only with useful features. > for example > when selecting a printer or file server, apple's macos/x users see the list > of available resources instantly when they bring up a "chooser" panel; this > is because the services periodically solicit themselves in some multicast > kind of way. to do resource discovery of this kind with llmnr would mean > a short delay when the panel was being initialized, while all relevant > servers and printers heard a query and sent a reply. i do not think that > apple would consider llmnr a successful replacement for rendezvous as long > as this feature difference existed. Thank you. The remaining question is whether rendezvous is a successful replacement for llmnr or not. It is my understanding that llmnr is not DNS and requirements for llmnr can be satisfied if some sort of discovery is supported, even if the packet format is not identical to that of DNS. 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 Fri Aug 29 18:22: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 SAA12333 for ; Fri, 29 Aug 2003 18:22:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19srSR-000E22-4S for namedroppers-data@psg.com; Fri, 29 Aug 2003 22:11:03 +0000 Received: from [219.101.47.130] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.22) id 19srMk-000DYE-5p for namedroppers@ops.ietf.org; Fri, 29 Aug 2003 22:05:10 +0000 Received: by coconut.itojun.org (Postfix, from userid 1001) id 6909B9A; Sat, 30 Aug 2003 07:05:09 +0900 (JST) To: paul@vix.com Cc: namedroppers@ops.ietf.org Subject: Re: LLMNR interoperability with Rendezvous? In-Reply-To: Your message of "Fri, 29 Aug 2003 15:12:40 +0000" <20030829151240.CC059139A3@sa.vix.com> References: <20030829151240.CC059139A3@sa.vix.com> X-Mailer: Cue version 0.6 (030716-1832/itojun) Mime-Version: 1.0 From: itojun@iijlab.net Content-Type: Text/Plain; charset=us-ascii Message-Id: <20030829220509.6909B9A@coconut.itojun.org> Date: Sat, 30 Aug 2003 07:05:09 +0900 (JST) X-Spam-Status: No, hits=0.3 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk is dns-sd part of Rendezvous included in the current discussion? i assumed not. > as a proponent of the DISCOVER opcode, i have some sympathy for the above > position. however, rendezvous and llmnr are not merely different ways to > accomplish the same thing... they accomplish different things. for example > when selecting a printer or file server, apple's macos/x users see the list > of available resources instantly when they bring up a "chooser" panel; this > is because the services periodically solicit themselves in some multicast > kind of way. to do resource discovery of this kind with llmnr would mean > a short delay when the panel was being initialized, while all relevant > servers and printers heard a query and sent a reply. i do not think that > apple would consider llmnr a successful replacement for rendezvous as long > as this feature difference existed. the above talks about dns-sd part, i guess. 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 Aug 29 22:44: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 WAA01878 for ; Fri, 29 Aug 2003 22:44:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19svad-000BcM-HT for namedroppers-data@psg.com; Sat, 30 Aug 2003 02:35:47 +0000 Received: from [17.254.0.51] (helo=mail-out2.apple.com) by psg.com with esmtp (Exim 4.22) id 19svZk-000BVz-2N for namedroppers@ops.ietf.org; Sat, 30 Aug 2003 02:34:52 +0000 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.12.9/8.12.9) with ESMTP id h7U2YpiZ021339 for ; Fri, 29 Aug 2003 19:34:51 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 29 Aug 2003 19:34:25 -0700 Received: from [17.202.44.119] (chesh7.apple.com [17.202.44.119]) by scv2.apple.com (8.12.9/8.12.9) with SMTP id h7U2YgWI003875 for ; Fri, 29 Aug 2003 19:34:42 -0700 (PDT) Message-Id: <200308300234.h7U2YgWI003875@scv2.apple.com> Subject: Re: LLMNR interoperability with Rendezvous? Date: Fri, 29 Aug 2003 19:34:52 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Spam-Status: No, hits=-1.4 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Randy Bush wrote: >sure. what changes will be needed in rendezvous? We'd need to add the ability to respond to TCP connections (which is something that was always in the plans anyway; we simply haven't had any devices that needed it yet). There are several things that Rendezvous does that LLMNR doesn't, but I was not asking the Working Group to adopt these extensions. They are things that Rendezvous does to accomodate the situation where more than one host may respond to a given query, something that has not been a priority for this Working Group or LLMNR. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Aug 29 22:45: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 WAA01918 for ; Fri, 29 Aug 2003 22:45:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19svbC-000BgQ-11 for namedroppers-data@psg.com; Sat, 30 Aug 2003 02:36:22 +0000 Received: from [17.254.0.51] (helo=mail-out2.apple.com) by psg.com with esmtp (Exim 4.22) id 19svZG-000BV4-4M for namedroppers@ops.ietf.org; Sat, 30 Aug 2003 02:34:22 +0000 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.12.9/8.12.9) with ESMTP id h7U2YLiZ021151 for ; Fri, 29 Aug 2003 19:34:21 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 29 Aug 2003 19:33:55 -0700 Received: from [17.202.44.119] (chesh7.apple.com [17.202.44.119]) by scv2.apple.com (8.12.9/8.12.9) with SMTP id h7U2Y6WI003689 for ; Fri, 29 Aug 2003 19:34:07 -0700 (PDT) Message-Id: <200308300234.h7U2Y6WI003689@scv2.apple.com> Subject: Re: LLMNR interoperability with Rendezvous? Date: Fri, 29 Aug 2003 19:34:16 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-transfer-encoding: quoted-printable X-Spam-Status: No, hits=-0.4 required=5.0 tests=QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable >Stuart, please provide the working group with a list with issues >previously not discussed and a separate list of items that have been >discussed. Please provide that list before the end of next week (Sep >7). The road block is the TTL incompatibility: Rendezvous sets IP TTL=3D255, and checks IP TTL on reception, and discards packets that have lower TTLs indicating that they may originate from off-link attackers. LLMNR sets IP TTL=3D1, and on reception discards packets that don't have IP= TTL=3D1. Aside from that difference, Rendezvous does everything that LLMNR does. The packet formats are identical (DNS packet format). A Rendezvous responder will respond to queries from a LLMNR querier, and a LLMNR responder will answer queries from a Rendezvous querier, were it not for the fact that they are both choosing to ignore and discard each other's packets. This seems like a silly incompatibility. =D3lafur wrote: > the document went through numerous cycles during which issues > where thoroughly discussed. The issue of the TTL=3D1 has review > from the working group and that issue is not to be opened again. So, this is the show-stopping incompatibility. We can't change Rendezvous's TTL handling because too many Rendezvous hardware products have already shipped from Apple and other companies. DNSEXT can't change LLMNR's TTL handling because it has been thoroughly discussed and is not to be opened again. This is an impasse. Even with the best will in the world, the circumstances are such that it is simply not possible for either side to make the change to interoperate with the other. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Aug 30 01:38: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 BAA11326 for ; Sat, 30 Aug 2003 01:38:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19syLn-0001Rn-Ky for namedroppers-data@psg.com; Sat, 30 Aug 2003 05:32:39 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.22) id 19syL1-0001Nj-OU for namedroppers@ops.ietf.org; Sat, 30 Aug 2003 05:31:51 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 6FF674E7B4; Sat, 30 Aug 2003 07:31:06 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id DE9FF4E18B; Sat, 30 Aug 2003 07:31:05 +0200 (CEST) Received: from cow.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.9/8.11.6) with ESMTP id h7U5V5Wt025996; Sat, 30 Aug 2003 07:31:05 +0200 Message-Id: <200308300531.h7U5V5Wt025996@birch.ripe.net> To: Stuart Cheshire Cc: namedroppers@ops.ietf.org Subject: Re: LLMNR interoperability with Rendezvous? In-Reply-To: Message from Stuart Cheshire of "Fri, 29 Aug 2003 19:34:16 PDT." <200308300234.h7U2Y6WI003689@scv2.apple.com> Date: Sat, 30 Aug 2003 07:31:05 +0200 From: Olaf Kolkman X-RIPE-Spam-Status: N 0.444040 X-RIPE-Signature: e30d0757e08bf585a9f97ac1d542ec15 X-Spam-Status: No, hits=-1.3 required=5.0 tests=BAYES_30,IN_REP_TO version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Stuart Cheshire writes: * >Stuart, please provide the working group with a list with issues * >previously not discussed and a separate list of items that have been * >discussed. Please provide that list before the end of next week (Sep * >7). * * The road block is the TTL incompatibility: Going back to our proposal, you providing us 2 lists. We now have 1 item and we like to make sure: - Is this 1 item the complete list of issues previously discussed and that need to be reviewed? - Is the list of 'new items' an empty list? We proposed the process so that the working group can make an informed decision, based on the amount of things that need to be revisited, if we need to go back and re-argue the issue. No hidden surprises further down the road ;-) ? --Olaf Kolkman DNSEXT Co-Chair -- to unsubscribe send a message to namedroppers-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 Aug 30 02:02: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 CAA14691 for ; Sat, 30 Aug 2003 02:02:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19syjX-0003uo-NU for namedroppers-data@psg.com; Sat, 30 Aug 2003 05:57:11 +0000 Received: from [141.225.37.221] (helo=thales.memphis.edu) by psg.com with smtp (Exim 4.22) id 19sygf-0003b1-OU for namedroppers@ops.ietf.org; Sat, 30 Aug 2003 05:54:13 +0000 Received: (qmail 18902 invoked by uid 500); 30 Aug 2003 05:54:34 -0000 From: mw-list-namedroppers@csi.hu Date: Sat, 30 Aug 2003 00:54:34 -0500 To: Name Droppers Subject: Re: wcard-clarify violating RFC 2119, section 6 Message-ID: <20030830055434.GA18190@csi.hu> References: <20030827171224.70609.qmail@cr.yp.to> <20030826174447.46552.qmail@cr.yp.to> <20030820100735.39120ccd.olaf@ripe.net> <20030826024218.10706.qmail@cr.yp.to> <20030826141441.GK910@apb.cequrux.com> <15467.1061972977@munnari.OZ.AU> <18758.1062006971@munnari.OZ.AU> <20030828042006.26191.qmail@cr.yp.to> <20030828094003.GP910@apb.cequrux.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030828094003.GP910@apb.cequrux.com> User-Agent: Mutt/1.5.4i X-Spam-Status: No, hits=-3.9 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,NO_REAL_NAME, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MUTT autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, Aug 28, 2003 at 11:40:03AM +0200, Alan Barrett wrote: > RFC 2308 appears to be silent on this issue. A reasonable > interpretation of RFC 1034 would certainly permit the inference that > NXDOMAIN also applies to subdomains. Is there a place in RFC 1034 you have in mind where the interpretation of name error would suggest this? In fact, I find that the opposite is true. How can anybody infer from reading Each node and leaf on the tree corresponds to a resource set (which may be empty). in section 3.1, that in fact what it says is Each node and leaf on the tree corresponds to a resource set (which may be empty, but then the resource sets of all subnodes must be empty too). I believe the author specifically wants to allow names that refer to nothing (what else is the meaning of an empty resource set), and once he established the concepts precisely in the beginning, he identifies a name with the node and then the node with the associated resource set. So when he later writes about nonexistent names he means nonexistent (empty) associated resource set. So when you receive a "name error" when querying aol.org for ns.aol.org, it seems to be a stretch to conclude that you also have to give up on d.ns.aol.org. Mate --- Mate Wierdl | Dept. of Math. Sciences | University of Memphis -- to unsubscribe send a message to namedroppers-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 Aug 30 10:34: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 KAA15407 for ; Sat, 30 Aug 2003 10:34:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19t6ck-0006Z9-Uw for namedroppers-data@psg.com; Sat, 30 Aug 2003 14:22:42 +0000 Received: from [192.149.252.33] (helo=smtp1.arin.net) by psg.com with esmtp (Exim 4.22) id 19t6bQ-0006Un-JU for namedroppers@ops.ietf.org; Sat, 30 Aug 2003 14:21:20 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 7101960E; Sat, 30 Aug 2003 10:21:19 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id BCDA141B; Sat, 30 Aug 2003 10:21:18 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.168.1.101]) by arin.net (CommuniGate Pro SMTP 4.1) with ESMTP id 603021; Sat, 30 Aug 2003 10:18:41 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <20030830055434.GA18190@csi.hu> References: <20030827171224.70609.qmail@cr.yp.to> <20030826174447.46552.qmail@cr.yp.to> <20030820100735.39120ccd.olaf@ripe.net> <20030826024218.10706.qmail@cr.yp.to> <20030826141441.GK910@apb.cequrux.com> <15467.1061972977@munnari.OZ.AU> <18758.1062006971@munnari.OZ.AU> <20030828042006.26191.qmail@cr.yp.to> <20030828094003.GP910@apb.cequrux.com> <20030830055434.GA18190@csi.hu> Date: Sat, 30 Aug 2003 10:21:20 -0400 To: mw-list-namedroppers@csi.hu From: Edward Lewis Subject: Re: wcard-clarify violating RFC 2119, section 6 Cc: Name Droppers Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This discussion is crossing the line of being on-topic for wild card, but the question raised is a reasonable one. And the discussion does start in scope for the document, and when it strays, it strays into an area that does need to be discussed... At 0:54 -0500 8/30/03, mw-list-namedroppers@csi.hu wrote: >On Thu, Aug 28, 2003 at 11:40:03AM +0200, Alan Barrett wrote: >> RFC 2308 appears to be silent on this issue. A reasonable >> interpretation of RFC 1034 would certainly permit the inference that >> NXDOMAIN also applies to subdomains. > >Is there a place in RFC 1034 you have in mind where the interpretation of >name error would suggest this? In 4.3.2, step c. "If a match is impossible" you seek to apply wild card synthesis. If you treat all names as existing (many with empty sets), you will *always* get an exact match as in step a. There will never be a time to apply step c - hence the realization that 1034 didn't really mean to say 'everything exists' as it does. That's as far as the wcard-clarify needs to go - to make sure wild card synthesis actually happens. Going into the name error issue now... If you notice, if you don't ever enter step c, you don't return name error at all. So, instead of treating all names as existing but some not having data means that you will only see negative answers fitting 'no error/no data' instead of seeing name error when hitting a empty non-terminal. >In fact, I find that the opposite is true. How can anybody infer from >reading > > Each node and leaf on the tree corresponds to a resource set (which > may be empty). > >in section 3.1, that in fact what it says is > > Each node and leaf on the tree corresponds to a resource set (which > may be empty, but then the resource sets of all subnodes must be > empty too). Recall that 4.3.2 contains the suggested may an authoritative server responds. In this case, there's complete knowledge of the search space and the server just runs to the edge of it when it looks for data that's 'not there' - e.g., in step c. If I'm looking for a 6 label deep answer and nothing matches more than 3 of them - I 'know' that there's no data. I don't see that there isn't a fourth and then infer there's no fifth and sixth. The confusion in the discussion is that RFC 2308 talks about what happens at a cache (NCACHE). The logic at a recursive server is quite different. I've refrained on commenting on that because recursive servers don't do wild card synthesis. >So when you receive a "name error" when querying aol.org for >ns.aol.org, it seems to be a stretch to conclude that you also have to >give up on d.ns.aol.org. If you ask for d.ns.aol.org. and the query hits a cache that sees that there's a name error when asking for ns.aol.org, then, well, I can understand why you'd assume there'd be no d.ns.aol.org worth asking for. But it's a siren's call to optimize away the lookup. A cache doesn't have perfect knowledge. It could be that the name error came on a query a week ago and hasn't timed out yet - and in the meantime the deeper name added. DNS isn't real time, but at least at the authoritative source I have current information - cache have never had the guarantee. And once we get to discussing DNSSEC's authenticated denial of existence another complication will arise with wild card synthesized NXT's. Because of the replacement of the owner name, relying on NXT's to supply information about what's in a zone won't be accurate. E.g., *.example.com NXT w.example.com will be used to synthesize a negative answer to x.example.com and show that there's nothing from x.example.com to w.example.com. If you do the name math right, that would exclude example.com too. The moral of the story is that caches ought to answer negatively only if they got a negative answer to the same query before (within the right time span). They shouldn't assume a name error means there's nothing below (things change with time) and they have to narrowly interpret authenticated denial of existence messages (when they do flow). By now we've veered far away from wild card synthesis and into the behaviors of caches... PS - I was a bit confused by the paragraph about the author's intentions, because I'm not sure if you are referring to rfc 1034 or the clarification. But, the need to define node as non-existent in the clarification draft is so that step c of 4.3.2 gets executed and thus synthesis done. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Sponge Bob Square Pants? I'm still trying to figure out the Macarena. -- to unsubscribe send a message to namedroppers-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 Aug 30 11:33: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 LAA18439 for ; Sat, 30 Aug 2003 11:33:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19t7dn-000CIp-Qp for namedroppers-data@psg.com; Sat, 30 Aug 2003 15:27:51 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.22) id 19t7cs-000CC6-95 for namedroppers@ops.ietf.org; Sat, 30 Aug 2003 15:26:54 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h7UEtYw10393 for ; Sat, 30 Aug 2003 07:55:35 -0700 Date: Sat, 30 Aug 2003 07:55:34 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed resolution to LLMNR Issue 44 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests=USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The text of Issue 44 is included below. The proposed fixes are as follows: Change "224.0.0.251" throughout the document to TBD. In Section 3, change: "[2] Where a DNS server is configured, by default a sender SHOULD send LLMNR queries only for names that are either unqualified or exist within the default domain. Where no DNS server is configured, an LLMNR query MAY be sent for any name." To: "[2] Where a DNS server is configured, by default a sender SHOULD send LLMNR A or AAAA queries only for names that are either unqualified or exist within the default domain. Where no DNS server is configured, an LLMNR query MAY be sent for any name. It is consistent with this recommendation for a sender to use LLMNR queries for the resolution of unqualified host names, and conventional DNS queries for resolution of other DNS names." In Section 2.5, change: "The source address of LLMNR queries and responses MUST be "on link"." To: "A transmitting host MUST select a source address for LLMNR queries and responses that is "on link"." Change Section 2.6 from: "2.6. Retransmissions In order to avoid synchronization, LLMNR queries and responses are delayed by a time uniformly distributed between 0 and 200 ms. If an LLMNR query sent over UDP is not resolved within the timeout interval (LLMNR_TIMEOUT), then a sender MAY repeat the transmission of the query in order to assure that it was received by a host capable of responding to it. Since a multicast query sender cannot know beforehand whether it will receive no response, one response, or more than one response, it SHOULD wait for LLMNR_TIMEOUT in order to collect all possible responses, rather than considering the multicast query answered after the first response is received. A unicast query sender considers the query answered after the first response is received, so that it only waits for LLMNR_TIMEOUT if no response has been received. LLMNR implementations SHOULD dynamically estimate the timeout value (LLMNR_TIMEOUT) based on the last response received, on a per-interface basis. The algorithms described in [RFC2988] are suggested, with a minimum timeout value of 300 ms. Retransmission of UDP queries SHOULD NOT be attempted more than 3 times. Where LLMNR queries are sent using TCP, retransmission is handled by the transport layer." To: "2.6. Retransmissions In order to avoid synchronization, LLMNR queries and responses are delayed by a time uniformly distributed between 0 and 200 ms. If an LLMNR query sent over UDP is not resolved within the timeout interval (LLMNR_TIMEOUT), then a sender MAY repeat the transmission of the query in order to assure that it was received by a host capable of responding to it. Since a multicast query sender cannot know beforehand whether it will receive no response, one response, or more than one response, it SHOULD wait for LLMNR_TIMEOUT in order to collect all possible responses, rather than considering the multicast query answered after the first response is received. A unicast query sender considers the query answered after the first response is received, so that it only waits for LLMNR_TIMEOUT if no response has been received. LLMNR implementations SHOULD dynamically estimate the timeout value (LLMNR_TIMEOUT) based on the last response received for a query, on a per-interface basis. The algorithms described in [RFC2988] are suggested, with a minimum timeout value of 300 ms. Retransmission of UDP queries SHOULD NOT be attempted more than 3 times. Where LLMNR queries are sent using TCP, retransmission is handled by the transport layer." In Section 2.7 change: "The responder should use a pre-configured TTL value in the records returned in the LLMNR query response." To: "The responder should use a pre-configured TTL value in the records returned in the LLMNR query response. A default value of 30 seconds is recommended. In highly dynamic environments (such as adhoc networks) it may be necessary to set the TTL to a lower value." In Section 3, change: "RRs returned in LLMNR responses MUST only include values that are valid on the local interface, such as IPv4 or IPv6 addresses valid on the local link or names defended using the mechanism described in Section 4. In particular:" To: "It is the responsibility of the sender to ensure that RRs returned in LLMNR responses MUST only include values that are valid on the local interface, such as IPv4 or IPv6 addresses valid on the local link or names defended using the mechanism described in Section 4. In particular:" Change section 3.1, from: "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: "If a name is not qualified, for the purposes of LLMNR, the implicit search order is as follows: [1] Request the name with the current domain appended. [2] Request the name with the root domain (".") appended. This is the behavior suggested by [RFC1536]. LLMNR uses this technique to resolve unqualified host names." In Section 3.2, change: "Where there is no DNS server authoritative for the names of hosts on the local network" To: "Where there is no DNS server authoritative for the name of at least one of the hosts currently on the local network" Change: "linklocal name resoltion over IPv4." To: "linklocal name resolution over IPv4." In Section 4, change: "Where a host is configured to respond to LLMNR queries on more than one interface, each interface should have its own independent LLMNR cache." To: "Where a host is configured to issue LLMNR queries on more than one interface, each interface should have its own independent LLMNR cache." In Section 4, change: "For each UNIQUE resource record in a given interface's configuration, the host MUST verify resource record uniqueness on that interface. To accomplish this, the host MUST send an LLMNR query for each UNIQUE resource record. By default, a host SHOULD be configured to behave as though all RRs are UNIQUE. Uniqueness verification is carried out when the host: - starts up or is rebooted - wakes from sleep (if the network interface was inactive during sleep) - is configured to respond to the LLMNR queries on an interface - is configured to respond to the LLMNR queries using additional UNIQUE resource records - detects that an interface is connected and is usable (e.g. an IEEE 802 hardware link-state change indicating that a cable was attached or that an association has occurred with a wireless base station and that any required authentication has completed)" To: "For each UNIQUE resource record in a given interface's configuration, the host MUST verify resource record uniqueness on that interface. To accomplish this, the host MUST send an LLMNR query for each UNIQUE resource record, as described in Section 2.6. By default, a host SHOULD be configured to behave as though all RRs are UNIQUE. Uniqueness verification is carried out when the host: - starts up or is rebooted - is configured to respond to the LLMNR queries on an interface - is configured to respond to the LLMNR queries using additional UNIQUE resource records" Proposed Resolution: Accept ------------------------------------------------------ Issue 44: Miscellaneous Comments Submitter name: Stuart Cheshire Submitter email address: cheshire@apple.com Date first submitted: August 24, 2003 Reference: Document: LLMNR-22 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: This is a busy time at Apple, working towards our next OS release, but I managed to make time to read draft-ietf-dnsext-mdns-22.txt. >The IPv4 link-scope multicast address a given responder listens >to, and to which a sender sends queries, is 224.0.0.251. If your intention is to make LLMNR interoperable with Rendezvous, I fully support that, and would be willing to do the necessary work. For example, Rendezvous does not currently support TCP queries, but we would be willing to add that support, and things like it, if the WG wanted to pursue that direction. Otherwise, if the intention is not to make LLMNR interoperable with Rendezvous, then it should not use the same multicast address. Using the same multicast address, and then using a different UDP port number so as to demultiplex the traffic in the kernel, would be the height of folly. The whole point of multicast (as opposed to good old-fashioned broadcast) is that it lets the Ethernet hardware (and/or the Ethernet switch) reduce the interrupt burden on the host CPU (and/or reduce the traffic on that link). Using the UDP port number as the filtering mechanism means that you pay all the cost of delivering a packet to a host that doesn't want it, only to have the packet discarded in the kernel because no one is listening on that port. The whole point of multicast is to prevent that waste. >Today, with the rise of home networking, there are an increasing number >of ad-hoc networks operating without a Domain Name System (DNS) server. I think this is side-stepping the real issue. The real issue is: >Today, with the rise of home networking, there are an increasing number >of home users who do not have ownership of any part of the name space >in which they can assign names. The whole section talking about "unqualified names" seems to be skirting around this issue without being willing to face it head-on and tackle it. Section 3.1 says: >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. You can't "request just the name". There is no way to represent an unqualified name ("no trailing dot") in the DNS packet format. What you mean is: >[1] Request the name with the current domain appended. >[2] Request the name with the root domain (".") appended. What this means is that if a home user calls their TV "tv", and their FM radio receiver "fm", and their CD player "cd", their computer is going to be sending queries for the TLDs "tv.", "fm." and "cd." (Tuvalu, Federal State of Micronesia, and Democratic Republic of the Congo, respectively.) This seems like it invites chaotic uncontrolled pollution of the top-level name space. [BA] I assume you are referring to DNS queries for "tv." Presumably there is no harm in allowing LLMNR queries for this. The draft allows a host to resolve queries for unqualified names only via LLMNR, so this can be avoided. Are you suggesting that this behavior be recommended? Furthermore, because there is no way to represent an unqualified name in the DNS packet format, there is also no way to represent an unqualified name on the right-hand-side of a PTR, CNAME or SRV record. This means that if you do a LLMNR query for an SRV record with an "unqualified" name, what you get back is an SRV record containing a target host name that you can't use with LLMNR because it's not an "unqualified" name. [BA] Agreed. This should be fixed. See resolution above. >Unicast queries SHOULD be sent when: > > b. The sender queries for a [reverse mapping] PTR RR. Rendezvous has something called sleep proxy service, where a device can transfer its RRs to a sleep proxy server on the local LAN and then go into low-power sleep mode. The sleep proxy server answers queries on the device's behalf, and wakes the device with a magic packet when an A or SRV query is detected that indicates the device needs to wake up to provide some active service. Sending queries via unicast means the sleep proxy server may not get to see them, and may be unable to answer and/or wake the device. [BA] It also means that other hosts won't see these queries. On a high populated network such as the IETF's, such queries could consume a substantial percentage of all bandwidth, and so it is desirable to limit them. >The source address of LLMNR queries and responses MUST be "on link". Is this "MUST" a requirement imposed on senders, or a checking requirement imposed on receivers? [BA] On senders. There is no checking requirement on receivers. >it is possible that some routers may not properly implement >link-scope multicast This is far fetched. How many routers *DO* implement multicast forwarding, but *DON'T* understand 224.0.0/8? It's not a plausible scenario. Rendezvous has been sending to 224.0.0.251 with TTL 255 for over a year (longer if you count OS 9) and there have been no problems reported. [BA] Just because there have been no "problems reported" does not mean that there aren't offending home gateways. This might not be an issue because the multicast packets are dropped deeper in the network. >The responder should use a pre-configured TTL value Pre-configured by whom? [BA] By the implementation. >[3] A responder with both link-local and routable addresses > MUST respond to LLMNR queries for A/AAAA RRs only with > routable address(es). This encourages use of routable > address(es) for establishment of new connections. This creates failures where failures were not necessary. Just put all answers in the response, and let the client use them intelligently: If the routable address works, great, otherwise, the client can try the LL to see if that works. Omitting the LL from the response does not help the client work better: it prevents the client from connecting in situations where it should be able to. (In some cases of network problems, omitting the LL addresses may prevent you from connecting to the some piece of network infrastructure to correct the misconfiguration that led to the problem in the first place.) [BA] The ZEROCONF WG has recommended this behavior to encourage use of a routable address when it is available. The routable address is likely to be more stable, and since the IPv4 LL draft will incorporate behavior to allow hosts with routable and IPv4 LL addresses to communicate, I'm not sure why this should be an issue. Since LLMNR is about linklocal name resolution, a host configured to ARP for addresses on the local link (whether they are routable or IPv4 LL) should be able to reach both types of addresses. >3.1. Unqualified names > >The same host MAY use LLMNR queries for the resolution of unqualified >host names Who makes the choice offered by that "MAY"? User? OS vendor? Application writer? [BA] The LLMNR implementation. >If a name is not qualified and does not end in a trailing dot, What does that mean? Do "fully qualified" and "ends in a trailing dot" mean the same thing, or is there a difference? [BA] They means the same thing. See proposed resolution above. >Where there is >no DNS server authoritative for the names of hosts on the local network What does that mean? What is the area code for mobile phones at an IETF meeting? The statement doesn't have well-defined meaning. My laptop computer has a name, and its name is not determined by its geographic location at any given time. DNS servers are authoritative for pieces of the name space, not for physical networks. Perhaps the text should say, "Where there is no DNS server authoritative for the name of at least *one* of the hosts *currently* on the local network..." [BA] Agreed. >Where a host is configured to respond to LLMNR queries on more than one >interface, each interface should have its own independent LLMNR cache. Perhaps you mean "configured to *issue* LLMNR queries on more than one interface" [BA] Yes. >For each UNIQUE resource record in a given interface's configuration, >the host MUST verify resource record uniqueness on that interface. To >accomplish this, the host MUST send an LLMNR query for each UNIQUE >resource record. How many LLMNR queries? What interval? How long after the query (or queries) may it start issuing responses for that name? [BA] UNIQUEness verification is handled similarly to any other query, as specified in Section 2.6. What about tie-breaking in the event of simultaneous startup (e.g. when power is restored after an outage)? [BA] The draft does not specify what is done in the event of a name conflict. In general, automatic name change may be neither possible nor desirable. >For example, the hostname could be chosen randomly from a large pool of >potential names Doesn't this miss the point of hostnames? The whole point of using names instead of dotted-decimal IP addresses is that names are supposed to be more memorable, and easier for humans to type. If we're going to use randomly chosen names, then we already have a mechanism for randomly choosing from a pool of potential identifiers: it's called a DHCP server. Isn't the point of LLMNR to let people pick a name for their machine that's a little more convenient and friendly than "dhcp-dynamic-191-72-231-201.ietf-53.ietf.org."? [BA] This is just cited as an example of how name conflict can be avoided. It is not being recommended necessarily -- and could be usable in situations where no human intervention is anticipated. -- to unsubscribe send a message to namedroppers-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 Aug 31 08:57: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 IAA05943 for ; Sun, 31 Aug 2003 08:57:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19tRZQ-000K2P-Sg for namedroppers-data@psg.com; Sun, 31 Aug 2003 12:44:40 +0000 Received: from [205.150.200.166] (helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 4.22) id 19tRYu-000Jxy-Hx for namedroppers@ops.ietf.org; Sun, 31 Aug 2003 12:44:08 +0000 Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [205.150.200.247]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h7VCgld14748 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Sun, 31 Aug 2003 08:42:52 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h7VCggQW023093 for ; Sun, 31 Aug 2003 08:42:46 -0400 To: namedroppers@ops.ietf.org Subject: Re: LLMNR interoperability with Rendezvous? In-reply-to: Your message of "Fri, 29 Aug 2003 19:34:16 PDT." <200308300234.h7U2Y6WI003689@scv2.apple.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Sun, 31 Aug 2003 08:42:42 -0400 Message-ID: <23092.1062333762@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Status: No, hits=-3.6 required=5.0 tests=BAYES_30,IN_REP_TO,PGP_SIGNATURE autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Stuart" == Stuart Cheshire writes: Stuart> The road block is the TTL incompatibility: Stuart> Rendezvous sets IP TTL=255, and checks IP TTL on reception, and Stuart> discards packets that have lower TTLs indicating that they may Stuart> originate from off-link attackers. Stuart> LLMNR sets IP TTL=1, and on reception discards packets that don't Stuart> have IP TTL=1. If I'm not mistaken, the BGP protocol originally used TTL=1, but now recommends using TTL=255 and checking that way instead. ] Out and about in Ottawa. hmmm... beer. | 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/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP1HtQIqHRg3pndX9AQH71wP/WzT6e1yIRXR5151HSYxykOBdAj3WaDeU Nnzchl6fqdv817XmtbfnToKCMKaIJAI4iruieE0b5gx4YveFKbeHprnK34D4QCst noZZLivS+2j2S2NS1XXsySXUZODBQD0FRjLaa6MGrut1WiuUU06rCGhVVE1N7Duv EsCQtwVdgRU= =mYuw -----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 Sun Aug 31 09:14: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 JAA06167 for ; Sun, 31 Aug 2003 09:14:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19tRwk-000MPF-Uf for namedroppers-data@psg.com; Sun, 31 Aug 2003 13:08:46 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.22) id 19tRwE-000MMV-BK for namedroppers@ops.ietf.org; Sun, 31 Aug 2003 13:08:14 +0000 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 h7VD8AB02691; Sun, 31 Aug 2003 20:08:11 +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 h7VD2MG13720; Sun, 31 Aug 2003 20:02:24 +0700 (ICT) From: Robert Elz To: mw-list-namedroppers@csi.hu cc: Name Droppers Subject: Re: wcard-clarify violating RFC 2119, section 6 In-Reply-To: <20030830055434.GA18190@csi.hu> References: <20030830055434.GA18190@csi.hu> <20030827171224.70609.qmail@cr.yp.to> <20030826174447.46552.qmail@cr.yp.to> <20030820100735.39120ccd.olaf@ripe.net> <20030826024218.10706.qmail@cr.yp.to> <20030826141441.GK910@apb.cequrux.com> <15467.1061972977@munnari.OZ.AU> <18758.1062006971@munnari.OZ.AU> <20030828042006.26191.qmail@cr.yp.to> <20030828094003.GP910@apb.cequrux.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 31 Aug 2003 20:02:22 +0700 Message-ID: <19794.1062334942@munnari.OZ.AU> X-Spam-Status: No, hits=-3.0 required=5.0 tests=BAYES_20,IN_REP_TO,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Sat, 30 Aug 2003 00:54:34 -0500 From: mw-list-namedroppers@csi.hu Message-ID: <20030830055434.GA18190@csi.hu> | Is there a place in RFC 1034 you have in mind where the interpretation of | name error would suggest this? | | In fact, I find that the opposite is true. Actually, I think you might not, when you reconsider. | How can anybody infer from reading | | Each node and leaf on the tree corresponds to a resource set (which | may be empty). | | in section 3.1, that in fact what it says is | | Each node and leaf on the tree corresponds to a resource set (which | may be empty, but then the resource sets of all subnodes must be | empty too). It doesn't, and no-one claims that. | I believe the author specifically wants to allow names that refer to | nothing (what else is the meaning of an empty resource set), Yes, exactly. | and once he established the concepts precisely in the beginning, | he identifies a name with the node and then the node with the | associated resource set. So when he later writes about nonexistent | names he means nonexistent (empty) associated resource set. I'm not sure I can parse that last sentence, but I think I agree. That is, I think you're saying, that if a name has an empty resource set (or a non-empty one for that matter), it exists. That I believe is the intent of the sentence from 1034 you quoted. | So when you receive a "name error" when querying aol.org for | ns.aol.org, it seems to be a stretch to conclude that you also have to | give up on d.ns.aol.org. What I think you're missing there, is the real point. That is, if d.ns.aol.org exists, then (obviously, as you can see it sitting there in that name) ns.aol.org exists. Consequently, you don't get a "name error" (rcode == 3, which we mostly call NXDOMAIN) when you query ns.aol.com (you cannot) regardless of what RR's exist at that node (including none). Even Prof Bernstein agrees that this is what RFC1034/5 say is correct. His argument has been that that was changed by RFC2308 (it wasn't, but that's not relevant to your point). kre ps: from reading 1034/5, I believe that servers should really also support empty terminal names (that is, names with no RRs, no sub-domains, but which exist none the less). I don't know of any servers that implement those. Does anyone? I'm not sure that it matters, as I doubt there is much in the way of practical use for such things. However, they seem to be clearly allowed, so at the very least, those familiar with the DNSSEC algorithms (particularly for proving non-existence) should probably make sure that the algorithms work in the presence of emtpy terminal 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 Sun Aug 31 10:27: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 KAA07990 for ; Sun, 31 Aug 2003 10:27:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19tT5m-0001gd-UV for namedroppers-data@psg.com; Sun, 31 Aug 2003 14:22:10 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.22) id 19tT5G-0001fz-8r for namedroppers@ops.ietf.org; Sun, 31 Aug 2003 14:21:38 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 789225CF; Sun, 31 Aug 2003 10:21:37 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id E3FF45C2; Sun, 31 Aug 2003 10:21:36 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.168.1.101]) by arin.net (CommuniGate Pro SMTP 4.1) with ESMTP id 605883; Sun, 31 Aug 2003 10:18:55 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <19794.1062334942@munnari.OZ.AU> References: <20030830055434.GA18190@csi.hu> <20030827171224.70609.qmail@cr.yp.to> <20030826174447.46552.qmail@cr.yp.to> <20030820100735.39120ccd.olaf@ripe.net> <20030826024218.10706.qmail@cr.yp.to> <20030826141441.GK910@apb.cequrux.com> <15467.1061972977@munnari.OZ.AU> <18758.1062006971@munnari.OZ.AU> <20030828042006.26191.qmail@cr.yp.to> <20030828094003.GP910@apb.cequrux.com> <19794.1062334942@munnari.OZ.AU> Date: Sun, 31 Aug 2003 10:21:44 -0400 To: Robert Elz From: Edward Lewis Subject: empty terminals was Re: wcard-clarify ... Cc: Name Droppers Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-5.6 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 20:02 +0700 8/31/03, Robert Elz wrote: >ps: from reading 1034/5, I believe that servers should really also support >empty terminal names (that is, names with no RRs, no sub-domains, but which >exist none the less). I don't know of any servers that implement those. The only possible reasons for this might be that you want wild card synthesis to not apply to a particular name or you do not want to return a name error for a particular name. (I.e., never step into 'c' of 4.3.2.) >Does anyone? I'm not sure that it matters, as I doubt there is much in >the way of practical use for such things. However, they seem to be clearly >allowed, so at the very least, those familiar with the DNSSEC algorithms >(particularly for proving non-existence) should probably make sure that >the algorithms work in the presence of emtpy terminal names. "Does anyone?" No implementation I've ever seen does. Unless we here from someone of the 1034 era, I doubt we could determine whether empty terminals were an intended consequence. My reading, and why I originally suggested the rewording of existence, is that empty terminals were not an intended consequence. And, even if they were, my gut is that they are as useful as IQUERY, also defined back then but since rescinded. I can't think of a patented "it would be a really bad idea because..." to answer this. I can see implementing it, and the configuring of empty terminals. But it just doesn't seem natural. The question for the wcard-clarify is then: "Do we want to alter the existence to allow for empty terminals?" If so, how to you distinguish (at a master server) between an existing and non-existing empty terminal? PS - Since DNSSEC is lurking in the issue, way back when, the DNSSEC developers had an assumption that no name would own just an NXT RR. That would be violated by empty terminals. Perhaps we need to discuss that issue. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Sponge Bob Square Pants? I'm still trying to figure out the Macarena. -- to unsubscribe send a message to namedroppers-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 Aug 31 11:42: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 LAA08858 for ; Sun, 31 Aug 2003 11:42:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19tUHA-0007mV-Ha for namedroppers-data@psg.com; Sun, 31 Aug 2003 15:38:00 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.22) id 19tUH9-0007mJ-4H for namedroppers@ops.ietf.org; Sun, 31 Aug 2003 15:37:59 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id C1AD713999 for ; Sun, 31 Aug 2003 15:37:58 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Name Droppers Subject: Re: wcard-clarify violating RFC 2119, section 6 In-Reply-To: Message from Robert Elz of "Sun, 31 Aug 2003 20:02:22 +0700." <19794.1062334942@munnari.OZ.AU> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sun, 31 Aug 2003 15:37:58 +0000 Message-Id: <20030831153758.C1AD713999@sa.vix.com> X-Spam-Status: No, hits=-3.4 required=5.0 tests=BAYES_20,IN_REP_TO,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ps: from reading 1034/5, I believe that servers should really also support > empty terminal names (that is, names with no RRs, no sub-domains, but which > exist none the less). I don't know of any servers that implement those. > Does anyone? I'm not sure that it matters, as I doubt there is much in > the way of practical use for such things. However, they seem to be clearly > allowed, so at the very least, those familiar with the DNSSEC algorithms > (particularly for proving non-existence) should probably make sure that > the algorithms work in the presence of emtpy terminal names. i don't agree. 1034/5 explains several ways a name can exist, and in each case one can infer what data content or protocol event gives rise to that existence. no such existence is supported for empty terminals. -- to unsubscribe send a message to namedroppers-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 Aug 31 11:57: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 LAA09006 for ; Sun, 31 Aug 2003 11:57:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19tUWG-0009I3-Tf for namedroppers-data@psg.com; Sun, 31 Aug 2003 15:53:36 +0000 Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.22) id 19tUVU-0009DE-WF for namedroppers@ops.ietf.org; Sun, 31 Aug 2003 15:52:49 +0000 Received: from depa.dmes.org (user-uinj218.dialup.mindspring.com [165.121.136.40]) by toccata.fugue.com (Postfix) with ESMTP id 760811B58D2 for ; Sun, 31 Aug 2003 10:36:03 -0500 (CDT) From: Ted Lemon To: namedroppers@ops.ietf.org Subject: Re: LLMNR interoperability with Rendezvous? Date: Sun, 31 Aug 2003 11:50:02 -0400 User-Agent: KMail/1.5 References: <23092.1062333762@marajade.sandelman.ottawa.on.ca> In-Reply-To: <23092.1062333762@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: <200308311150.02665.mellon@nominum.com> X-Spam-Status: No, hits=-1.4 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_NJABL,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sunday 31 August 2003 08:42, Michael Richardson wrote: > Stuart> The road block is the TTL incompatibility: > If I'm not mistaken, the BGP protocol originally used TTL=1, but now > recommends using TTL=255 and checking that way instead. Hm. I was one of the people who thought that TTL=255 wasn't such a great idea, all other things being equal. However, nobody ever presented any strong reason why we should use one over the other - it was always a matter of preferences and fine distinctions. I really don't think insisting on TTL=1 is a good idea if it means we can't interoperate with a lot of existing devices out there, because there isn't a clear advantage to it. It winds up just being a gratuitous incompatibility. So although the time is late, and I'm not in love with the idea of reopening resolved issues, I think this is worth changing. -- to unsubscribe send a message to namedroppers-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 Aug 31 12:39: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 MAA09445 for ; Sun, 31 Aug 2003 12:39:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19tVBn-000CeH-Ui for namedroppers-data@psg.com; Sun, 31 Aug 2003 16:36:31 +0000 Received: from [205.150.200.166] (helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 4.22) id 19tVB1-000CZ5-De for namedroppers@ops.ietf.org; Sun, 31 Aug 2003 16:35:43 +0000 Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [205.150.200.247]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h7VGY6d15997 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Sun, 31 Aug 2003 12:34:16 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h7VGMZt1008815 for ; Sun, 31 Aug 2003 12:24:23 -0400 To: namedroppers@ops.ietf.org Subject: Re: LLMNR interoperability with Rendezvous? In-reply-to: Your message of "Sun, 31 Aug 2003 11:50:02 EDT." <200308311150.02665.mellon@nominum.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Sun, 31 Aug 2003 12:21:26 -0400 Message-ID: <8814.1062346886@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Status: No, hits=-3.6 required=5.0 tests=BAYES_30,IN_REP_TO,PGP_SIGNATURE autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Ted" == Ted Lemon writes: >> If I'm not mistaken, the BGP protocol originally used TTL=1, but now >> recommends using TTL=255 and checking that way instead. Ted> Hm. I was one of the people who thought that TTL=255 wasn't such a Ted> great idea, all other things being equal. However, nobody ever Ted> presented any strong reason why we should use one over the other - Ted> it was always a matter of preferences and fine distinctions. TTL=1 depends upon the routers dropping at exactly the right time. TTL=255 is locally checkable, but requires that link-local multicast works. Both depend upon the router doing something correctly. I can't comment on what has been broken more often. I think that there are/were many "internet-sharing" programs for windows(95) which broke TTL=1 processing. Odds are they didn't even speak multicast, so I don't know what the major risks are. ] Out and about in Ottawa. hmmm... beer. | 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/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP1IghIqHRg3pndX9AQGk6QQAz6gLdm4OK/pL12PkAxP+XDfJCqBu/Jlv H/HJ+1fUkbNQRNGqL+tPTAPynA1ChPTSeDvXsBbyGLh6FS1hpDwLnJabM9xSop0I Se1Z8btBpNVTQ3EmjWSjJuJOYDvisfwXYt4Gh/AzF1gRXHMlkU5QqH/MEb591L93 UUEgb2JQRlo= =hVt8 -----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 Sun Aug 31 14:55: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 OAA10836 for ; Sun, 31 Aug 2003 14:55:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19tXFQ-000NcU-I3 for namedroppers-data@psg.com; Sun, 31 Aug 2003 18:48:24 +0000 Received: from [3ffe:b80:2:a90::2] (helo=hades.pp.htv.fi) by psg.com with esmtp (Exim 4.22) id 19tXFD-000NbQ-Nn for namedroppers@ops.ietf.org; Sun, 31 Aug 2003 18:48:12 +0000 Received: from hades.pp.htv.fi (liljeber@localhost [127.0.0.1]) by hades.pp.htv.fi (8.12.9/8.12.9/Debian-5) with ESMTP id h7VImAlr001818; Sun, 31 Aug 2003 21:48:11 +0300 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.9/8.12.9/Debian-5) id h7VIm8RK001817; Sun, 31 Aug 2003 21:48:08 +0300 X-Authentication-Warning: hades.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LLMNR interoperability with Rendezvous? From: Mika Liljeberg To: Michael Richardson Cc: namedroppers@ops.ietf.org In-Reply-To: <8814.1062346886@marajade.sandelman.ottawa.on.ca> References: <8814.1062346886@marajade.sandelman.ottawa.on.ca> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1062355688.1581.50.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Sun, 31 Aug 2003 21:48:08 +0300 X-Spam-Status: No, hits=-7.0 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_XIMIAN, X_AUTH_WARNING autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sun, 2003-08-31 at 19:21, Michael Richardson wrote: > >>>>> "Ted" == Ted Lemon writes: > >> If I'm not mistaken, the BGP protocol originally used TTL=1, but now > >> recommends using TTL=255 and checking that way instead. > > Ted> Hm. I was one of the people who thought that TTL=255 wasn't such a > Ted> great idea, all other things being equal. However, nobody ever > Ted> presented any strong reason why we should use one over the other - > Ted> it was always a matter of preferences and fine distinctions. > > TTL=1 depends upon the routers dropping at exactly the right time. > TTL=255 is locally checkable, but requires that link-local multicast works. I think that in practise the choise of TTL only has relevance with unicast queries and responses sent to non link-local destination addresses. If the destination address is link-local (including multicast), setting or checking the TTL has little value. We might as well do what rendezvous does. As for unicast to non link-local destinations addresses: - Setting TTL=1 makes sense with TCP, since it prevents a TCP connection from being created with an off-link peer. A smart TCP implementation will abort the connection attempt immediately when receiving the time exceeded ICMP error from the local router. This is generally better than timing out. - For UDP unicast, setting and checking TTL=255 gives good protection against off-link attackers. This makes good sense for responses as it will guard against cache poisoning attempts by off-link attackers. We will also never leak responses off-link if we check TTL=255 in query packets. - However, if we use TTL=255 in queries we *will* leak query packets off-link and we will lose the rapid "time exceeded" response from the local router. The ICMP error response was considered desirable with reverse queries. In many cases a reverse query will yield no response from DNS. This causes the resolver to fall back on LLMNR and typically the query will fail after the LLMNR sender times out. If we touch the TTL rules we will have to rethink some of these issues, including the rules that tells us when to use unicast. 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 Aug 31 17:01: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 RAA13373 for ; Sun, 31 Aug 2003 17:01:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19tZEH-0008G7-DD for namedroppers-data@psg.com; Sun, 31 Aug 2003 20:55:21 +0000 Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.22) id 19tZCz-0008BX-D8 for namedroppers@ops.ietf.org; Sun, 31 Aug 2003 20:54:01 +0000 Received: from depa.dmes.org (user-uinj218.dialup.mindspring.com [165.121.136.40]) by toccata.fugue.com (Postfix) with ESMTP id A52B31B25CC; Sun, 31 Aug 2003 15:40:04 -0500 (CDT) From: Ted Lemon To: Mika Liljeberg , Michael Richardson Subject: Re: LLMNR interoperability with Rendezvous? Date: Sun, 31 Aug 2003 16:54:03 -0400 User-Agent: KMail/1.5 Cc: namedroppers@ops.ietf.org References: <8814.1062346886@marajade.sandelman.ottawa.on.ca> <1062355688.1581.50.camel@hades> In-Reply-To: <1062355688.1581.50.camel@hades> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200308311654.03211.mellon@nominum.com> X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_NJABL, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sunday 31 August 2003 14:48, Mika Liljeberg wrote: > As for unicast to non link-local destinations addresses: Hm, I guess I need to read the latest draft. I thought LLMNR was link-local. :'/ -- to unsubscribe send a message to namedroppers-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 Aug 31 17:13: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 RAA13482 for ; Sun, 31 Aug 2003 17:13:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19tZSK-0009aM-PV for namedroppers-data@psg.com; Sun, 31 Aug 2003 21:09:52 +0000 Received: from [3ffe:b80:2:a90::2] (helo=hades.pp.htv.fi) by psg.com with esmtp (Exim 4.22) id 19tZRV-0009W3-Pi for namedroppers@ops.ietf.org; Sun, 31 Aug 2003 21:09:02 +0000 Received: from hades.pp.htv.fi (liljeber@localhost [127.0.0.1]) by hades.pp.htv.fi (8.12.9/8.12.9/Debian-5) with ESMTP id h7VL92lr002433; Mon, 1 Sep 2003 00:09:02 +0300 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.9/8.12.9/Debian-5) id h7VL90YN002432; Mon, 1 Sep 2003 00:09:00 +0300 X-Authentication-Warning: hades.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LLMNR interoperability with Rendezvous? From: Mika Liljeberg To: Ted Lemon Cc: Michael Richardson , namedroppers@ops.ietf.org In-Reply-To: <200308311654.03211.mellon@nominum.com> References: <8814.1062346886@marajade.sandelman.ottawa.on.ca> <1062355688.1581.50.camel@hades> <200308311654.03211.mellon@nominum.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1062364140.1581.53.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Mon, 01 Sep 2003 00:09:00 +0300 X-Spam-Status: No, hits=-9.4 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_XIMIAN,X_AUTH_WARNING autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sun, 2003-08-31 at 23:54, Ted Lemon wrote: > On Sunday 31 August 2003 14:48, Mika Liljeberg wrote: > > As for unicast to non link-local destinations addresses: > > Hm, I guess I need to read the latest draft. I thought LLMNR was link-local. > :'/ Well, it is. But the participating nodes may be using their routable 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 Sun Aug 31 20:30: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 UAA16213 for ; Sun, 31 Aug 2003 20:30:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19tcT2-000O0i-9H for namedroppers-data@psg.com; Mon, 01 Sep 2003 00:22:48 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.22) id 19tcSO-000Nxe-5G for namedroppers@ops.ietf.org; Mon, 01 Sep 2003 00:22:08 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h7VNoep27772 for ; Sun, 31 Aug 2003 16:50:40 -0700 Date: Sun, 31 Aug 2003 16:50:40 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Re: LLMNR TTL change Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_20,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk As Mika has indicated, this issue is not as simple as it looks. For those who are new to this issue (or are just now reading the draft for the first time), past discussion is covered in issues 2, 34 and 35 of the LLMNR Issues list: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html A brief summary of the discussion is as follows: a. Multicast queries. Here the destination is a link-scope multicast address, so it can be argued that TTL is not particularly relevant. In Issue 44, Stuart argued that TTL=255 can be used in this situation without fear of leakage, and I would agree. b. TCP queries and responses. Here the goal is to prevent establishment of a TCP connection to an off-link destination. IMHO, the argument for TTL=1 is fairly persuasive here, as is the argument for not utilizing multicast for PTR queries, which are highly likely to be bogus. c. UDP Responses. This is the case which has generated the most discussion. Setting TTL=255 on UDP Responses and checking it does ensure against spoofing by an off-link host. The potential downside is leakage by a host that does not ARP for IPv4 Link-Local addresses, or by a host that responds to UDP unicast queries. If it is reasonable to assume that LLMNR is only implemented on hosts that also implement the IPv4 LL spec, then the former concern can be dismissed. The latter concern is more serious, since use of TCP for unicast queries is not required. Given that this is WG last call, and that the draft as well as the discussion is fairly far advanced, it's expected that posters wishing to see a change to the draft do the following: 1. Read the draft. It's available at http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-22.txt 2. Read the Issues list: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html 3. Submit a change request in the format specified on the Issues list. This includes clearly indicating what text you want changed, and what you want it changed to. -- to unsubscribe send a message to namedroppers-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 Aug 31 21:30: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 VAA16749 for ; Sun, 31 Aug 2003 21:30:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19tdRw-0002oz-Il for namedroppers-data@psg.com; Mon, 01 Sep 2003 01:25:44 +0000 Received: from [211.29.163.60] (helo=bsdi.dv.isc.org) by psg.com with esmtp (Exim 4.22) id 19tdQe-0002g6-Rq for namedroppers@ops.ietf.org; Mon, 01 Sep 2003 01:24:25 +0000 Received: from bsdi.dv.isc.org (localhost.dv.isc.org [127.0.0.1]) by bsdi.dv.isc.org (8.12.9/8.12.9) with ESMTP id h811NmYf054106; Mon, 1 Sep 2003 11:23:49 +1000 (EST) (envelope-from marka@bsdi.dv.isc.org) Message-Id: <200309010123.h811NmYf054106@bsdi.dv.isc.org> To: Edward Lewis Cc: Robert Elz , Name Droppers From: Mark.Andrews@isc.org Subject: Re: empty terminals was Re: wcard-clarify ... In-reply-to: Your message of "Sun, 31 Aug 2003 10:21:44 -0400." Date: Mon, 01 Sep 2003 11:23:48 +1000 X-Spam-Status: No, hits=-2.3 required=5.0 tests=BAYES_20,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > At 20:02 +0700 8/31/03, Robert Elz wrote: > >ps: from reading 1034/5, I believe that servers should really also support > >empty terminal names (that is, names with no RRs, no sub-domains, but which > >exist none the less). I don't know of any servers that implement those. > > The only possible reasons for this might be that you want wild card > synthesis to not apply to a particular name or you do not want to > return a name error for a particular name. (I.e., never step into > 'c' of 4.3.2.) > > >Does anyone? I'm not sure that it matters, as I doubt there is much in > >the way of practical use for such things. However, they seem to be clearly > >allowed, so at the very least, those familiar with the DNSSEC algorithms > >(particularly for proving non-existence) should probably make sure that > >the algorithms work in the presence of emtpy terminal names. > > "Does anyone?" No implementation I've ever seen does. > > Unless we here from someone of the 1034 era, I doubt we could > determine whether empty terminals were an intended consequence. My > reading, and why I originally suggested the rewording of existence, > is that empty terminals were not an intended consequence. And, even > if they were, my gut is that they are as useful as IQUERY, also > defined back then but since rescinded. > > I can't think of a patented "it would be a really bad idea > because..." to answer this. I can see implementing it, and the > configuring of empty terminals. But it just doesn't seem natural. > > The question for the wcard-clarify is then: > > "Do we want to alter the existence to allow for empty terminals?" If > so, how to you distinguish (at a master server) between an existing > and non-existing empty terminal? No. > > PS - Since DNSSEC is lurking in the issue, way back when, the DNSSEC > developers had an assumption that no name would own just an NXT RR. > That would be violated by empty terminals. Perhaps we need to > discuss that issue. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer > > Sponge Bob Square Pants? I'm still trying to figure out the Macarena. > > -- > to 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 Sun Aug 31 23:07: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 XAA17874 for ; Sun, 31 Aug 2003 23:07:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19tew6-000ARR-Ha for namedroppers-data@psg.com; Mon, 01 Sep 2003 03:00:58 +0000 Received: from randy by psg.com with local (Exim 4.22) id 19tevA-000AJZ-Ui for namedroppers@ops.ietf.org; Mon, 01 Sep 2003 03:00:00 +0000 To: namedroppers@ops.ietf.org Subject: list policy Message-Id: From: Randy Bush Date: Mon, 01 Sep 2003 03:00:00 +0000 X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) 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: