From owner-namedroppers@ops.ietf.org Wed Oct 1 04:34: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 EAA03134 for ; Wed, 1 Oct 2003 04:34:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A4cFo-000CJ2-6a for namedroppers-data@psg.com; Wed, 01 Oct 2003 08:22:36 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.22) id 1A4cFI-000CGB-KD for namedroppers@ops.ietf.org; Wed, 01 Oct 2003 08:22:04 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 07E404E570; Wed, 1 Oct 2003 10:22:04 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 764B44E18F for ; Wed, 1 Oct 2003 10:22:03 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id h918M3JO019632 for ; Wed, 1 Oct 2003 10:22:03 +0200 Date: Wed, 1 Oct 2003 10:22:03 +0200 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: Re: Q-10: Reaction to "Silly" NXT's Message-Id: <20031001102203.46f9095c.olaf@ripe.net> In-Reply-To: References: Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.6 (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.000086 X-RIPE-Signature: 5e5df3daf93429db5f735a3454e2aa98 X-Spam-Status: No, hits=-1.8 required=5.0 tests=BAYES_30,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 Content-Transfer-Encoding: 7bit A comment/clarification with respect to this issue and draft-ietf-dnsext-dnssec-protocol-02.txt In the initial mail Ed wrote: > Any comments on this proposal? (It's been posted a few times.) > Sooner or later this will be cast into MUST/SHOULD language and > submitted to the dnssec-editors, based on feedback. The "Silly State" discussion died without text being submitted to the editors. The draft now contains in section 5.4: Since a verified NSEC RR proves the existance of both itself and its corresponding RRSIG RR, a verifier MUST ignore the settings of the NSEC and RRSIG bits in an NSEC RR. In other words it clarifies the RFC2535 approach and does not add additional checks. If the Working Group still want to pursue with 'Silly State' then those interested should come up with a "diff" against dnssec-protocol-2. That text, which should have a motivation, will then be discussed on its merits. We want to try to get a final version of the protocol draft before the cut-off in about 3 weeks. To allow some time for discussion a text would need to be submitted within, say, a week. --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 Wed Oct 1 11:12: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 LAA17337 for ; Wed, 1 Oct 2003 11:12:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A4iSV-000HI0-3t for namedroppers-data@psg.com; Wed, 01 Oct 2003 15:00:07 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.22) id 1A4iQQ-000H4e-RI for namedroppers@ops.ietf.org; Wed, 01 Oct 2003 14:57:58 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16512; Wed, 1 Oct 2003 10:57:51 -0400 (EDT) Message-Id: <200310011457.KAA16512@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-protocol-02.txt Date: Wed, 01 Oct 2003 10:57:51 -0400 X-Spam-Status: No, hits=2.9 required=5.0 tests=BAYES_30,MIME_BOUND_NEXTPART,NO_REAL_NAME, RCVD_IN_OSIRUSOFT_COM,TO_MALFORMED version=2.55 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-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 : Protocol Modifications for the DNS Security Extensions Author(s) : R. Arends Filename : draft-ietf-dnsext-dnssec-protocol-02.txt Pages : 47 Date : 2003-10-1 This document is part of a family of documents which describes the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications which add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-protocol-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-protocol-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-protocol-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-1103314.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-protocol-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-protocol-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-1103314.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 Oct 3 05:58: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 FAA28975 for ; Fri, 3 Oct 2003 05:58:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A5MTF-000A2C-0y for namedroppers-data@psg.com; Fri, 03 Oct 2003 09:43:33 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.22) id 1A5MSf-000A0Y-OY for namedroppers@ops.ietf.org; Fri, 03 Oct 2003 09:42:57 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 252834EF24; Fri, 3 Oct 2003 11:42:57 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id A425E4ED42 for ; Fri, 3 Oct 2003 11:42:56 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id h939gu2h016537 for ; Fri, 3 Oct 2003 11:42:56 +0200 Date: Fri, 3 Oct 2003 11:42:56 +0200 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: Re: wcard-clarify's change Message-Id: <20031003114256.15494de9.olaf@ripe.net> In-Reply-To: <20030928150322.9E8301394B@sa.vix.com> References: <20030928150322.9E8301394B@sa.vix.com> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.6 (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.097100 X-RIPE-Signature: 78b560cc8baeb3e82534932cfafb6cd0 X-Spam-Status: No, hits=-0.4 required=5.0 tests=BAYES_30,IN_REP_TO,RCVD_IN_OSIRUSOFT_COM,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 Namedroppers, We have to get to a consensus on this one at some point. I want to try and keep momentum going. Let us define X="something that matches the *" Then I think we have consensus on the fact that there is a problem in the fact that for QNAME=X QTYPE=A we will get different answers from a cache depending on the fact if the cache was asked QNAME=X,QTYPE=CNAME before. This is an ambiguity and it needs clarification. I think that the TTL=0 solution will not lead to consensus so we are currently left with two possibilities: - Either clarify the algorithm so that QNAME=X,QNAME!=CNAME will produce a CNAME response in the authoritative server. - Or outlawing "* CNAME". Am I missing other solutions? Process: - If there is anybody who CANNOT live with one of the two solutions than speak up and motivate. - If there is a strong preference for one of the solutions than also speak up and motivate. - If you can live with the default (below), or you really do not care which solution is picked, it would be nice to know so we know people actually read this thread. I hope that based on these two questions we can cook up the consensus solution. Please keep in mind you do not have to like that solution but you should be able to live with it. If there is no input before Oct 18 I will take "Outlawing * CNAME" as being the consensus outcome of this issue. The motivation for me choosing that particular solution as default is that it is simplest; you do not have to deal with all kinds of loop protections etc. -- Olaf DNSEXT Co-Chair. Is there an English equivalent to the proverb "een olifant in een porcelein kast"? -- to unsubscribe send a message to namedroppers-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 Oct 3 06:24: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 GAA29441 for ; Fri, 3 Oct 2003 06:24:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A5N2g-000CIu-0E for namedroppers-data@psg.com; Fri, 03 Oct 2003 10:20:10 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.22) id 1A5N23-000CDv-Ry for namedroppers@ops.ietf.org; Fri, 03 Oct 2003 10:19:33 +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 h93AIaw27078; Fri, 3 Oct 2003 17:18:40 +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 h93AHnE08643; Fri, 3 Oct 2003 17:17:49 +0700 (ICT) From: Robert Elz To: "Olaf M. Kolkman" cc: namedroppers@ops.ietf.org Subject: Re: wcard-clarify's change In-Reply-To: <20031003114256.15494de9.olaf@ripe.net> References: <20031003114256.15494de9.olaf@ripe.net> <20030928150322.9E8301394B@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 03 Oct 2003 17:17:48 +0700 Message-ID: <23881.1065176268@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 I can live with either, no problem outlawing CNAME in a '*' record. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Oct 3 11:27: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 LAA12097 for ; Fri, 3 Oct 2003 11:27:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A5Rg6-00064h-7D for namedroppers-data@psg.com; Fri, 03 Oct 2003 15:17:10 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.22) id 1A5Rfa-00062D-88 for namedroppers@ops.ietf.org; Fri, 03 Oct 2003 15:16:38 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.22) id 1A5RfR-000FpT-US; Fri, 03 Oct 2003 08:16:30 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 3 Oct 2003 08:16:29 -0700 To: Robert Elz Cc: "Olaf M. Kolkman" , namedroppers@ops.ietf.org Subject: Re: wcard-clarify's change References: <20031003114256.15494de9.olaf@ripe.net> <20030928150322.9E8301394B@sa.vix.com> <23881.1065176268@munnari.OZ.AU> Message-Id: X-Spam-Status: No, hits=-1.3 required=5.0 tests=BAYES_30,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 > I can live with either, no problem outlawing CNAME in a '*' record. as paul said, that is a change, not a clarification, and hence outside the range of this document. randy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Oct 3 13:52: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 NAA18314 for ; Fri, 3 Oct 2003 13:52:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A5U1D-000JAN-7l for namedroppers-data@psg.com; Fri, 03 Oct 2003 17:47:07 +0000 Received: from [192.150.250.67] (helo=fuchsia.home) by psg.com with esmtp (Exim 4.22) id 1A5U0a-000J8M-W3; Fri, 03 Oct 2003 17:46:29 +0000 Received: from delta.cs.mu.OZ.AU (delta.wi0.home [192.168.192.31]) by fuchsia.home with ESMTP id h93HiNIe007798; Sat, 4 Oct 2003 00:44:24 +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 h93HiYS14335; Sat, 4 Oct 2003 00:44:35 +0700 (ICT) From: Robert Elz To: Randy Bush cc: "Olaf M. Kolkman" , namedroppers@ops.ietf.org Subject: Re: wcard-clarify's change In-Reply-To: References: <20031003114256.15494de9.olaf@ripe.net> <20030928150322.9E8301394B@sa.vix.com> <23881.1065176268@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 04 Oct 2003 00:44:34 +0700 Message-ID: <28336.1065203074@munnari.OZ.AU> X-Spam-Status: No, hits=-5.1 required=5.0 tests=BAYES_10,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: Fri, 3 Oct 2003 08:16:29 -0700 From: Randy Bush Message-ID: | > I can live with either, no problem outlawing CNAME in a '*' record. | | as paul said, that is a change, not a clarification, and hence | outside the range of this document. Randy, something has to be done. The option that can be argued that is not a change is to explicitly permit CNAME in wildcards, and actually make it work correctly. That would be OK too. But just doing nothing is unacceptable. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Oct 3 14:17: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 OAA19130 for ; Fri, 3 Oct 2003 14:17:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A5UQn-000Lyp-69 for namedroppers-data@psg.com; Fri, 03 Oct 2003 18:13:33 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.22) id 1A5UQ1-000Lvh-6E for namedroppers@ops.ietf.org; Fri, 03 Oct 2003 18:12:45 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 747C513948 for ; Fri, 3 Oct 2003 18:12:11 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: wcard-clarify's change In-Reply-To: Message from Robert Elz of "Sat, 04 Oct 2003 00:44:34 +0700." <28336.1065203074@munnari.OZ.AU> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 03 Oct 2003 18:12:11 +0000 Message-Id: <20031003181211.747C513948@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 > | > I can live with either, no problem outlawing CNAME in a '*' record. > | > | as paul said, that is a change, not a clarification, and hence > | outside the range of this document. > > Randy, something has to be done. The option that can be argued that > is not a change is to explicitly permit CNAME in wildcards, and actually > make it work correctly. That would be OK too. But just doing nothing > is unacceptable. i think that clarifying rfc1034 is the right goal, and that in this case, that means clarifying that wildcard CNAME's will result in noerror/nodata responses, which is (a) useless and (b) counterintuitive and (c) probably not what the zone editor wants and so therefore (d) it's not recommended. -- to unsubscribe send a message to namedroppers-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 Oct 3 14:26: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 OAA19332 for ; Fri, 3 Oct 2003 14:26:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A5UXC-000MZJ-6a for namedroppers-data@psg.com; Fri, 03 Oct 2003 18:20:10 +0000 Received: from [192.150.250.67] (helo=fuchsia.home) by psg.com with esmtp (Exim 4.22) id 1A5UWb-000MVC-7y; Fri, 03 Oct 2003 18:19:33 +0000 Received: from delta.cs.mu.OZ.AU (delta.wi0.home [192.168.192.31]) by fuchsia.home with ESMTP id h93IHWIe013379; Sat, 4 Oct 2003 01:17:33 +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 h93IHIS13605; Sat, 4 Oct 2003 01:17:18 +0700 (ICT) From: Robert Elz To: Randy Bush , "Olaf M. Kolkman" , namedroppers@ops.ietf.org Subject: Re: wcard-clarify's change In-Reply-To: <28336.1065203074@munnari.OZ.AU> References: <28336.1065203074@munnari.OZ.AU> <20031003114256.15494de9.olaf@ripe.net> <20030928150322.9E8301394B@sa.vix.com> <23881.1065176268@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 04 Oct 2003 01:17:18 +0700 Message-ID: <6505.1065205038@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 I just said ... | That would be OK too. But just doing nothing is unacceptable. I should have also added that we should make the best of the two choices (if there is a "best" - or for Randy "better") on technical grounds, not based on some absurd self imposed rule about what this document is supposed to be permitted to do or not do. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Oct 3 14:32: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 OAA19562 for ; Fri, 3 Oct 2003 14:32:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A5Uej-000NRZ-25 for namedroppers-data@psg.com; Fri, 03 Oct 2003 18:27:57 +0000 Received: from [192.150.250.67] (helo=fuchsia.home) by psg.com with esmtp (Exim 4.22) id 1A5UeC-000NOh-C2 for namedroppers@ops.ietf.org; Fri, 03 Oct 2003 18:27:25 +0000 Received: from delta.cs.mu.OZ.AU (delta.wi0.home [192.168.192.31]) by fuchsia.home with ESMTP id h93IPOIe021480; Sat, 4 Oct 2003 01:25:24 +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 h93IP1S06207; Sat, 4 Oct 2003 01:25:03 +0700 (ICT) From: Robert Elz To: Paul Vixie cc: namedroppers@ops.ietf.org Subject: Re: wcard-clarify's change In-Reply-To: <20031003181211.747C513948@sa.vix.com> References: <20031003181211.747C513948@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 04 Oct 2003 01:25:01 +0700 Message-ID: <1879.1065205501@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: Fri, 03 Oct 2003 18:12:11 +0000 From: Paul Vixie Message-ID: <20031003181211.747C513948@sa.vix.com> | i think that clarifying rfc1034 is the right goal, and that in this case, | that means clarifying that wildcard CNAME's will result in noerror/nodata | responses, which is (a) useless and (b) counterintuitive and (c) probably | not what the zone editor wants and so therefore (d) it's not recommended. Paul, you keep skipping the point, which is that "wildcard CNAME's will result in noerror/nodata responses" is simply not true. And I don't mean just because a (set of) very popular implementations doesn't do that. I mean that whether you get the empty response (assuming the server is implemented the way you believe is the correct way) depends upon where you ask the question, and what previous questions that server has been asked. That is what is unacceptable - the DNS needs to supply predictable answers, whatever they are. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Oct 3 17:07: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 RAA29236 for ; Fri, 3 Oct 2003 17:07:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A5WzX-000BF1-JL for namedroppers-data@psg.com; Fri, 03 Oct 2003 20:57:35 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.22) id 1A5Wz0-000BBE-JC for namedroppers@ops.ietf.org; Fri, 03 Oct 2003 20:57:02 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id h93KtOVX019221 for ; Fri, 3 Oct 2003 16:55:24 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAozaqIL; Fri, 3 Oct 03 16:55:22 -0400 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id h93KtbD9000778; Fri, 3 Oct 2003 16:55:37 -0400 (EDT) Date: Fri, 3 Oct 2003 16:55:37 -0400 (EDT) From: Sam Weiler X-X-Sender: weiler@filbert To: "Olaf M. Kolkman" cc: namedroppers@ops.ietf.org Subject: Re: wcard-clarify's change In-Reply-To: <20031003114256.15494de9.olaf@ripe.net> Message-ID: References: <20030928150322.9E8301394B@sa.vix.com> <20031003114256.15494de9.olaf@ripe.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,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 > Is there an English equivalent to the proverb "een olifant in een > porcelein kast"? "An elephant in a china shop?" "A bull in a china shop" is more common 'round these parts. http://www.adbusters.org/oldwebsite/Uncommercials/bullspot.html -- 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 Oct 3 18:49: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 SAA03283 for ; Fri, 3 Oct 2003 18:49:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A5YbD-000JUL-3D for namedroppers-data@psg.com; Fri, 03 Oct 2003 22:40:35 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.22) id 1A5Yah-000JP5-0z for namedroppers@ops.ietf.org; Fri, 03 Oct 2003 22:40:03 +0000 From: Masataka Ohta Message-Id: <200310032229.HAA00984@necom830.hpcl.titech.ac.jp> Received: from mohta@localhost by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id HAA00984; Sat, 4 Oct 2003 07:29:33 +0900 Subject: Re: wcard-clarify's change In-Reply-To: <20031003114256.15494de9.olaf@ripe.net> from "Olaf M. Kolkman" at "Oct 3, 2003 11:42:56 am" To: "Olaf M. Kolkman" Date: Sat, 4 Oct 2003 07:29:32 +0859 () CC: namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-0.5 required=5.0 tests=BAYES_30,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 Olaf; > - Or outlawing "* CNAME". > Process: > > - If there is anybody who CANNOT live with one of the two solutions than > speak up and motivate. I can't live with a solution that QNAME=X, QNAME!=CNAME produces an error QNAME=*, QNAME!=CNAME does not produce an error even though the latter is the behaviour specified at 3a of 4.3.2. So, just accept the fact that 3c of 4.3.2 contradicts with other descriptions in rfc1034 and it should be clarified that wildcard CNAME is OK. 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 Oct 3 21:37: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 VAA06887 for ; Fri, 3 Oct 2003 21:37:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A5bDP-0007kW-AC for namedroppers-data@psg.com; Sat, 04 Oct 2003 01:28:11 +0000 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtp (Exim 4.22) id 1A5bCt-0007hY-54 for namedroppers@ops.ietf.org; Sat, 04 Oct 2003 01:27:39 +0000 Received: from thangorodrim.hactrn.net (thangorodrim.wlan.wesleyan.edu [129.133.169.36]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "thangorodrim.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id 5BA4DC6 for ; Fri, 3 Oct 2003 21:27:06 -0400 (EDT) Received: from thangorodrim.hactrn.net (localhost [::1]) by thangorodrim.hactrn.net (Postfix) with ESMTP id 4F73920A8 for ; Sat, 4 Oct 2003 01:23:25 +0000 (UTC) Date: Fri, 03 Oct 2003 21:23:23 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: wcard-clarify's change In-Reply-To: <20031003114256.15494de9.olaf@ripe.net> References: <20030928150322.9E8301394B@sa.vix.com> <20031003114256.15494de9.olaf@ripe.net> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20031004012325.4F73920A8@thangorodrim.hactrn.net> X-Spam-Status: No, hits=-6.7 required=5.0 tests=BAYES_01,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 Fri, 3 Oct 2003 11:42:56 +0200, Olaf Kolkman wrote: > > If there is no input before Oct 18 I will take "Outlawing * CNAME" as > being the consensus outcome of this issue. The motivation for me > choosing that particular solution as default is that it is simplest; > you do not have to deal with all kinds of loop protections etc. I think that this is the right thing to do. -- to unsubscribe send a message to namedroppers-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 Oct 4 03:18: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 DAA27176 for ; Sat, 4 Oct 2003 03:18:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A5gVx-0004nw-Hp for namedroppers-data@psg.com; Sat, 04 Oct 2003 07:07:41 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.22) id 1A5gVA-0004lD-Re for namedroppers@ops.ietf.org; Sat, 04 Oct 2003 07:06:53 +0000 Received: from delta.cs.mu.OZ.AU (jade.coe.psu.ac.th [172.30.0.21]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h9476Vw04914; Sat, 4 Oct 2003 14:06:33 +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 h9474fo07989; Sat, 4 Oct 2003 14:05:10 +0700 (ICT) From: Robert Elz To: Masataka Ohta cc: "Olaf M. Kolkman" , namedroppers@ops.ietf.org Subject: Re: wcard-clarify's change In-Reply-To: <200310032229.HAA00984@necom830.hpcl.titech.ac.jp> References: <200310032229.HAA00984@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 04 Oct 2003 14:04:41 +0700 Message-ID: <13231.1065251081@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: Sat, 4 Oct 2003 07:29:32 +0859 () From: Masataka Ohta Message-ID: <200310032229.HAA00984@necom830.hpcl.titech.ac.jp> | I can't live with a solution that | QNAME=X, QNAME!=CNAME produces an error | QNAME=*, QNAME!=CNAME does not produce an error Otha-san - could you possibly repeat that with a little more detail, or perhaps precision ... Why would anyone care if the QNAME was "CNAME" for example? (Is there something wrong with having a host called cname.example.com ?) kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Oct 4 08:55: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 IAA04211 for ; Sat, 4 Oct 2003 08:55:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A5liS-000P10-Q1 for namedroppers-data@psg.com; Sat, 04 Oct 2003 12:40:56 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.22) id 1A5lhg-000Owk-3Z for namedroppers@ops.ietf.org; Sat, 04 Oct 2003 12:40:08 +0000 From: Masataka Ohta Message-Id: <200310041224.VAA02688@necom830.hpcl.titech.ac.jp> Received: from mohta@localhost by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id VAA02688; Sat, 4 Oct 2003 21:24:12 +0900 Subject: Re: wcard-clarify's change In-Reply-To: <13231.1065251081@munnari.OZ.AU> from Robert Elz at "Oct 4, 2003 02:04:41 pm" To: Robert Elz Date: Sat, 4 Oct 2003 21:24:11 +0859 () CC: "Olaf M. Kolkman" , namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_30,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 kre; > Date: Sat, 4 Oct 2003 07:29:32 +0859 () > From: Masataka Ohta > Message-ID: <200310032229.HAA00984@necom830.hpcl.titech.ac.jp> > > | I can't live with a solution that > | QNAME=X, QNAME!=CNAME produces an error > | QNAME=*, QNAME!=CNAME does not produce an error > > Otha-san - could you possibly repeat that with a little more detail, > or perhaps precision ... Why would anyone care if the QNAME was "CNAME" > for example? Oops, I meant (assuming X does not explicitly exist) | QNAME=X, QTYPE!=CNAME produces an error | QNAME=*, QTYPE!=CNAME does not produce an error because latter behaviour is specified at 3a of 4.3.2, which means code is error prone, regardless of whether it is an implementaion one or a pseudo one of 3c. So, just don't believe in pseudo code and follow explanations in other parts of rfc1034 to allow wildcarded CNAME, which is the clarification. 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 Sat Oct 4 09:18: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 JAA04554 for ; Sat, 4 Oct 2003 09:18:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A5mED-0001OL-J9 for namedroppers-data@psg.com; Sat, 04 Oct 2003 13:13:45 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.22) id 1A5mDH-0001L9-Ry for namedroppers@ops.ietf.org; Sat, 04 Oct 2003 13:12: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 h94DChw07225; Sat, 4 Oct 2003 20:12:44 +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 h94DCWq27471; Sat, 4 Oct 2003 20:12:35 +0700 (ICT) From: Robert Elz To: Masataka Ohta cc: "Olaf M. Kolkman" , namedroppers@ops.ietf.org Subject: Re: wcard-clarify's change In-Reply-To: <200310041224.VAA02688@necom830.hpcl.titech.ac.jp> References: <200310041224.VAA02688@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 04 Oct 2003 20:12:32 +0700 Message-ID: <11222.1065273152@munnari.OZ.AU> X-Spam-Status: No, hits=-5.1 required=5.0 tests=BAYES_10,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, 4 Oct 2003 21:24:11 +0859 () From: Masataka Ohta Message-ID: <200310041224.VAA02688@necom830.hpcl.titech.ac.jp> | because latter behaviour is specified at 3a of 4.3.2, which means | code is error prone, regardless of whether it is an implementaion | one or a pseudo one of 3c. Right - now I think just about everyone agrees that 1034's spec of wildcard handling (where the wildcard has a CNAME record) is simply broken. The question is what to do about it. This ... | So, just don't believe in pseudo code and follow explanations in | other parts of rfc1034 to allow wildcarded CNAME, which is the | clarification. is certainly one option. The other is to simply outlaw wildcarded CNAME. Defining it to work sensibly (as you're suggesting) has the advantage that it adds flexibility, and means one less special case (though implementations at least need to make sure to handle * IN CNAME nosuchname in some rational way). Outlawing it is easy to accomplish, works everywhere already (if there is no wildcard CNAME record, what the implementation might do if it had one is irrelevant - so if wildcard CNAME is illegal, anyone who has one in their zone simply needs to remove it). and most probably does no great harm (uses for wildcard CNAME that make sense are few and far between...) Do you have a reason for preferring to define it (make it work properly)? kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Oct 4 11:31: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 LAA08180 for ; Sat, 4 Oct 2003 11:31:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A5oGW-0009sE-TN for namedroppers-data@psg.com; Sat, 04 Oct 2003 15:24:16 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.22) id 1A5oG0-0009p9-8m for namedroppers@ops.ietf.org; Sat, 04 Oct 2003 15:23:44 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.22) id 1A5oFy-0000eU-Uz; Sat, 04 Oct 2003 08:23:43 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 4 Oct 2003 08:23:42 -0700 To: Robert Elz Cc: namedroppers@ops.ietf.org Subject: Re: wcard-clarify's change References: <20031003114256.15494de9.olaf@ripe.net> <20030928150322.9E8301394B@sa.vix.com> <23881.1065176268@munnari.OZ.AU> <28336.1065203074@munnari.OZ.AU> Message-Id: X-Spam-Status: No, hits=-1.3 required=5.0 tests=BAYES_30,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 >>> I can live with either, no problem outlawing CNAME in a '*' record. >> as paul said, that is a change, not a clarification, and hence >> outside the range of this document. > Randy, something has to be done. about what exactly? > The option that can be argued that is not a change is to > explicitly permit CNAME in wildcards i think that is pretty clear, as paul also pointed out > and actually make it work correctly. what's "correctly?" they are returned for a direct query. you want more? i suspect folk don't. randy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Oct 4 11:45: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 LAA08481 for ; Sat, 4 Oct 2003 11:45:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A5oXA-000BAA-4f for namedroppers-data@psg.com; Sat, 04 Oct 2003 15:41:28 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.22) id 1A5oWe-000B6H-6h for namedroppers@ops.ietf.org; Sat, 04 Oct 2003 15:40:56 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 741CF13971; Sat, 4 Oct 2003 15:40:22 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Robert Elz Cc: Masataka Ohta , "Olaf M. Kolkman" , namedroppers@ops.ietf.org Subject: Re: wcard-clarify's change In-Reply-To: Message from Robert Elz of "Sat, 04 Oct 2003 20:12:32 +0700." <11222.1065273152@munnari.OZ.AU> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sat, 04 Oct 2003 15:40:22 +0000 Message-Id: <20031004154022.741CF13971@sa.vix.com> X-Spam-Status: No, hits=-0.4 required=5.0 tests=BAYES_30,IN_REP_TO,RCVD_IN_OSIRUSOFT_COM 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, presenting wildcard cnames that way (declaring them broken vs. fixing them) presumes facts not yet generally accepted. consider this text from rfc1034: If a CNAME RR is present at a node, no other data should be present; 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. this argues that a wildcard cname would be legal if there were no other descendents of the same parent. what's strange is that pvm said "at a node" rather than "whose owner matches the qname". but the last sentence is compelling evidence that the pseudocode is not in error, that the behaviour you're calling "broken" was intentional, and that wildcard cnames really just don't do what people intuitively feel they ought to. paul -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Oct 5 06:32: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 GAA12068 for ; Sun, 5 Oct 2003 06:32:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A65tn-0002a5-9l for namedroppers-data@psg.com; Sun, 05 Oct 2003 10:13:59 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A65t8-0002OQ-Ja for namedroppers@ops.ietf.org; Sun, 05 Oct 2003 10:13:23 +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 h95ADAO01491; Sun, 5 Oct 2003 17:13: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 h95ACww29370; Sun, 5 Oct 2003 17:12:59 +0700 (ICT) From: Robert Elz To: Paul Vixie cc: Masataka Ohta , "Olaf M. Kolkman" , namedroppers@ops.ietf.org Subject: Re: wcard-clarify's change In-Reply-To: <20031004154022.741CF13971@sa.vix.com> References: <20031004154022.741CF13971@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 05 Oct 2003 17:12:57 +0700 Message-ID: <15719.1065348777@munnari.OZ.AU> X-Spam-Status: No, hits=-0.4 required=5.0 tests=BAYES_30,IN_REP_TO,RCVD_IN_OSIRUSOFT_COM,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, 04 Oct 2003 15:40:22 +0000 From: Paul Vixie Message-ID: <20031004154022.741CF13971@sa.vix.com> | presenting wildcard cnames that way (declaring them broken vs. fixing them) | presumes facts not yet generally accepted. No, you still keep missing the point. Or at least, on the list you do. | consider this text from rfc1034: | | If a CNAME RR is present at a node, no other data should be | present; 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. Yes. All that is fine. | this argues that a wildcard cname would be legal if there were no other | descendents of the same parent. Of course. I am not attempting to claim that 1034 makes wildcard CNAME illegal. | what's strange is that pvm said "at a | node" rather than "whose owner matches the qname". I'm not sure what is strange about that. | but the last sentence | is compelling evidence that the pseudocode is not in error, I have no idea how you arrive at that conclusion. What the last sentence says is that a CNAME must be the only RR, as otherwise, a cache with a CNAME record, when asked for an A for that name, wouldn't know whether it should just chase the CNAME, and return the A for the canonical name, or whether it was required to query the auth server, and find out if there was also an A record (in addition to one at the canonical name, if any). That's all quite clear - but I don't see how it provides any evidence at all about whether CNAMES at wildcards were intended to be noticed when the name is not explicitly in the zone, but the wildcard CNAME is. | that the behaviour you're calling "broken" was intentional, Note, the behaviour I am calling "broken" has nothing to do with the algorithm in 3.4 particularly at all. If it caused no other problems, I'd be happy to leave things in the (totally useless) state where a lookup of type CNAME would find the wildcard record, and a lookup of type A would not - which is what you claim the algorithm requires. The broken behaviour is that that does not produce a consistent result when a cache is queried, rather than the auth server directly. The answer depends upon earlier queries. If you're claiming that's a design feature, I'd like to see some evidence for it. Nowhere else in the DNS is it possible to make a query for type=X and have that query affect the result of a later query for the same qname of type=Y (or not if everything is correctly configured, and operating). | and that wildcard | cnames really just don't do what people intuitively feel they ought to. I don't care what they do, or don't do. I consider them useless in any case. What bothers me is that you're seriously suggesting that the DNS should be explicitly made non-deterministic, but you won't actually say so directly. randy@psg.com said: | what's "correctly?" they are returned for a direct query. you want more? I want consistent predictable answers. Is that too much to ask? In this case, I don't care what the answers are, but I want to know what answers resolvers will obtain for queries I know they will make, whenever I make any DNS configuration that is not invalid. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Oct 5 20:54: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 UAA01062 for ; Sun, 5 Oct 2003 20:54:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A6JQe-000MYu-C9 for namedroppers-data@psg.com; Mon, 06 Oct 2003 00:40:48 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A6JQ8-000M0X-Dr for namedroppers@ops.ietf.org; Mon, 06 Oct 2003 00:40:16 +0000 From: Masataka Ohta Message-Id: <200310060031.JAA06524@necom830.hpcl.titech.ac.jp> Received: from mohta@localhost by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id JAA06524; Mon, 6 Oct 2003 09:30:57 +0859 Subject: Re: wcard-clarify's change In-Reply-To: <11222.1065273152@munnari.OZ.AU> from Robert Elz at "Oct 4, 2003 08:12:32 pm" To: Robert Elz Date: Mon, 6 Oct 2003 09:30:56 +0859 () CC: "Olaf M. Kolkman" , 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 kre; > | because latter behaviour is specified at 3a of 4.3.2, which means > | code is error prone, regardless of whether it is an implementaion > | one or a pseudo one of 3c. > > Right - now I think just about everyone agrees that 1034's spec of > wildcard handling (where the wildcard has a CNAME record) is simply > broken. I think it is merely that some description is missing, which, in general, makes specifcation ambiguous. A complication is that missing decription in psuedo code makes the code not ambiguous but broken. But, it merely means that we shouldn't blindly believe psuedo code, In this case, the code is not consistent with the rest of the specification nor other part of the code itself. > The question is what to do about it. Add some description. > Do you have a reason for preferring to define it (make it work properly)? In this case, it is already defined. See above. Another reason not to outlaw wildcarded CNAME is that some might already be using it in some zone. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Oct 6 04:52: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 EAA22427 for ; Mon, 6 Oct 2003 04:52:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A6Qwg-000KgH-S5 for namedroppers-data@psg.com; Mon, 06 Oct 2003 08:42:22 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A6Qw7-000K51-Eu for namedroppers@ops.ietf.org; Mon, 06 Oct 2003 08:41:47 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id D10A54E06D; Mon, 6 Oct 2003 10:41:46 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 754634E2C4 for ; Mon, 6 Oct 2003 10:41:46 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id h968fkNW018964 for ; Mon, 6 Oct 2003 10:41:46 +0200 Date: Mon, 6 Oct 2003 10:41:46 +0200 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: Re: wcard-clarify's change Message-Id: <20031006104146.4a0aa5c6.olaf@ripe.net> In-Reply-To: <20031003114256.15494de9.olaf@ripe.net> References: <20030928150322.9E8301394B@sa.vix.com> <20031003114256.15494de9.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.6 (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.479190 X-RIPE-Signature: 470d6186f0dbe249ab84d085bd512ad7 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 Content-Transfer-Encoding: 7bit > Am I missing other solutions? I think there is a 3rd solution, although I personally do not like it, I want to mention it. Leaving the existing situation but facing that a security aware resolver will need to have the intelligence to do the CNAME query and resolve the ambiguity. Explanation: Assume the security aware resolver queries for QNAME=X (X being a name that matches the wildcard that has a CNAME) and QTYPE=A. The authoritative server will return something like RCODE=NOERROR ; answer empty ; authority X NSEC CNAME SIG NSEC X SIG (labelcount indicating wildcard) So the resolver gets an answer with the NSEC RR proving there is a CNAME and the SIG proving that the match was against a wildcard. The security aware resolver would have to know to do a query for QNAME=X, QTYPE=CNAME to get the proper CNAME. A non-secure resolver wouldn't know what situation its in. -- 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 Oct 6 16:16: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 QAA20824 for ; Mon, 6 Oct 2003 16:16:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A6bZa-000H4n-8g for namedroppers-data@psg.com; Mon, 06 Oct 2003 20:03:14 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A6bZ3-000GRv-59 for namedroppers@ops.ietf.org; Mon, 06 Oct 2003 20:02:41 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19833; Mon, 6 Oct 2003 16:02:26 -0400 (EDT) Message-Id: <200310062002.QAA19833@ietf.org> From: The IESG To: IETF-Announce: ; Cc: Olafur Gudmundsson , Olaf Kolkman , namedroppers@ops.ietf.org Subject: WG Action: RECHARTER: DNS Extensions (dnsext) Date: Mon, 06 Oct 2003 16:02:25 -0400 X-Spam-Status: No, hits=2.9 required=5.0 tests=OPT_IN_CAPS,RCVD_IN_OSIRUSOFT_COM,TO_MALFORMED version=2.55 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The DNS Extensions (dnsext) Working Group in the Internet Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. DNS Extensions (dnsext) ----------------------- Current Status: Active Working Group Chair(s): Olafur Gudmundsson Olaf Kolkman Internet Area Director(s): Thomas Narten Margret Wasserman Internet Area Advisor: Thomas Narten Mailing Lists: General Discussion: namedroppers@ops.ietf.org To Subscribe: namedroppers-request@ops.ietf.org Archive: The DNSEXT Working Group actually uses an additional mailing list: DNS Security: dnssec@cafax.se To Subscribe: dnssec-request@cafax.se Archive: http://www.cafax.se/dnssec/ and ftp://ftp.cafax.se/pub/archives/dnssec.list Description of Working Group: DNS was originally specified in RFC's 1034 and 1035, with subsequent updates. Within the scope of this WG are DNS protocol issues, including the specification of message formats, message handling, and data formats used for DNS client-server and server-server communication. This WG is focused on advancing the zone transfer, update and notify documents to Draft standard and on the rewrite of the DNSSEC proposed standard. Issues surrounding the operation of DNS, recommendations concerning the configuration of DNS servers, and other issues with the use of the protocol are out of scope for this Working Group. These issues are considered in other venues, such as the DNS Operations Working Group. Specific work items are: o Protocol clarifications and corrections for DNSSEC, initially these clarifications will be done as separate RFCs that will later be folded into a document that we refer to as the RFC 2535bis document standard. These include changes that simplify the operation of DNSSEC. o Generate new specification documents of DNSSEC (the RFC 2535bis document set) that includes all changes to RFC2535. This includes the following RFCs 2931, 3007, 3008, 3090 and 3226 and a number of Internet Drafts including DS, AD-is-secure, Key Signing Flag, etc. Advance this document set through the standards process. o Clarification of RFC1034/1035 relating to DNSEXT ongoing work. + Clarification of wildcard processing rules. + Case Insensitivity Clarification. o After the work items above have been completed the working group will continue on reviewing the following existing proposed standard and examine if there is a possibility to progress them on the standards track. + RFC1995 (IXFR) to Draft standard. + RFC1996 (Notify) to Draft standard. + RFC2136bis (Dynamic Update) to Draft Standard. + RFC2181 (Clarify) to IESG for advancement to Draft Standard + RFC2308 (Neg Caching) to Draft Standard. + RFC2671 (EDNS0) to Draft Standard. + RFC2845 (TSIG)to Draft standard. + RFC2930 (TKEY) to Draft standard. + RFC3007 (Secure Update) to Draft standard. + RFC3??? AXFR clarify to Draft Standard. + RFC3??? GSS/TSIG to Draft Standard o Foster the development of Link Local Multicast Name Resolution (LLMNR) standard. The WG has taken up this work since LLMNR it is very similar to the DNS protocol. LLMNR is targeted as proposed standard. The lifetime of the group is set by the work items above but while these are ongoing the working group has additional tasks: o Reviewing and providing recommendations about the specification, by other working groups, of RR types that do not require any special processing and that do not require any special naming conventions. Goals and Milestones: Sep 03 Update boilerplate text on OPT-IN Oct 03 Forward LLMNR to IESG for Proposed Standard. Oct 03 WG last call on the DNSSEC document set(RFC2535-bis). Oct 03 Forward Wildcard clarification to IESG for proposed standard Nov 03 Submit KEY algorithm documents RFC253[69d] and RFC3110 to IESG for proposed standard. Sep/Oct 03 Forward RFC2535-bis to IESG for proposed standard. Feb 04 Submit to IESG RFC2845 (TSIG)to Draft standard. Feb 04 Submit to IESG RFC2930 (TKEY) to Draft standard. Nov 03 Start of process of reviewing the following RFCs and to move them to PS status. Feb 04 RFC1982 (Serial Number Arithmetic) Feb 04 RFC2782 (SRV RR) to Draft Standard Feb 04 RFC2538 (CERT RR) to Draft Standard. May 04 RFC1995 (IXFR) to Draft standard May 04 RFC1996 (Notify) to Draft Standard. May 04 RFC2136 (Dynamic Update) to Draft Standard. May 04 RFC3007 (Secure Update) to Draft standard. Aug 04 RFC2181 (Clarify) to Draft Standard. Aug 04 RFC2671 (EDNS0) to Draft Standard. Aug 04 RFC2308 (Neg Caching) to Draft Standard. Nov 04 RFC3090 (TKEY) to Draft Standard. Nov 04 FRC2539 (DH Key RR) to Draft Standard. Nov 04 RFC3226 (Message Size) to Draft Standard. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Oct 6 19:00: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 TAA27361 for ; Mon, 6 Oct 2003 19:00:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A6eCy-000L3V-FD for namedroppers-data@psg.com; Mon, 06 Oct 2003 22:52:04 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A6eBw-000JyH-JZ for namedroppers@ops.ietf.org; Mon, 06 Oct 2003 22:51:00 +0000 Received: from ENGILL.ogud.com (mail.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id h96MnxjD013294; Mon, 6 Oct 2003 18:50:00 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20030926094448.01648520@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 06 Oct 2003 18:45:10 -0400 To: Stuart Cheshire From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: Re: LLMNR interoperability with Rendezvous? Cc: namedroppers@ops.ietf.org In-Reply-To: <200309200203.h8K23cCn024691@scv3.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-1.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, 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:04 2003-09-19, Stuart Cheshire wrote: > >This entire episode, including the reversal of the rough consensus > >favoring TTL=1 for link-local traffic in the ZeroConf WG, brings to mind > >the freshman engineering example in which a column is removed from a > >room for aesthetic reasons, rendering the entire building weak. > >Please do not mess with the foundation without compelling reasons! > >John, you have this completely backwards. > >Up to draft-ietf-dnsext-mdns-17.txt, it said: > > >In composing an LLMNR response, the responder MUST set the Hop Limit > >field in the IPv6 header and the TTL field in IPv4 header of the LLMNR > >response to 255. The sender MUST verify that the Hop Limit field in > >IPv6 header and TTL field in IPv4 header of each response to the LLMNR > >query is set to 255. If it is not, then sender MUST ignore the > >response. > >It was only a couple of months ago, after Apple and other companies had >been shipping products for over a year, that DNSEXT decided to reverse >its consensus. > >You may remember that I was one of the people who argued for TTL=1 in the >first place, but I was swayed by the working group consensus, so we >shipped with TTL=255, and then the working group changed its mind back >again. Stewart, You shipped code against an uncompleted specification and as it goes there was development on the TTL issue and consensus changed. Some room has been provided to review the issue but the fact that there is code shipped against an uncompleted specification is not a valid argument in that review, only an argument to revisit the issue. Thus you on your own and with known consequences decided to ship code against uncompleted specification. If your company wants interoperabilty they can update distributions, and possibly at the same time a put in a kludge to talk to the old implementations. Sorry but that is the cold facts. Olafur 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 Oct 6 19:30:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27889 for ; Mon, 6 Oct 2003 19:30:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A6ej4-0000fm-TL for namedroppers-data@psg.com; Mon, 06 Oct 2003 23:25:14 +0000 Received: from [211.29.163.60] (helo=bsdi.dv.isc.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A6eiY-0000EQ-WB for namedroppers@ops.ietf.org; Mon, 06 Oct 2003 23:24:43 +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 h96NNa0o008311; Tue, 7 Oct 2003 09:23:36 +1000 (EST) (envelope-from marka@bsdi.dv.isc.org) Message-Id: <200310062323.h96NNa0o008311@bsdi.dv.isc.org> To: "Olaf M. Kolkman" Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: wcard-clarify's change In-reply-to: Your message of "Mon, 06 Oct 2003 10:41:46 +0200." <20031006104146.4a0aa5c6.olaf@ripe.net> Date: Tue, 07 Oct 2003 09:23:36 +1000 X-Spam-Status: No, hits=1.2 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > > Am I missing other solutions? > > I think there is a 3rd solution, although I personally do not like it, > I want to mention it. > > Leaving the existing situation but facing that a security aware > resolver will need to have the intelligence to do the CNAME query and > resolve the ambiguity. > > Explanation: > > Assume the security aware resolver queries for QNAME=X (X being a name > that matches the wildcard that has a CNAME) and QTYPE=A. > > The authoritative server will return something like > > RCODE=NOERROR > ; answer empty > > ; authority > X NSEC CNAME SIG NSEC > X SIG (labelcount indicating wildcard) > > > So the resolver gets an answer with the NSEC RR proving there is a > CNAME and the SIG proving that the match was against a wildcard. The > security aware resolver would have to know to do a query for QNAME=X, > QTYPE=CNAME to get the proper CNAME. This is ridiculous. Failure to follow wildcard CNAME records in RFC 1034 section 4.3.2 is clearly a oversite. There is no technical reason not to follow them for QTYPE!=CNAME. Following them clearly works based on years of experience and is consistant with the use of CNAME elsewhere in the DNS. It has to be a oversite as no engineer (we are engineers arn't we) would deliberately design a system which make the answers from the cache dependent apon the query order. I have argued for a long time to get 3c expanded to include following CNAMEs. I will continue to argue for that result. > A non-secure resolver wouldn't know what situation its in. > > -- 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: -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Oct 6 19:31:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27954 for ; Mon, 6 Oct 2003 19:31:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A6ejg-0001JZ-66 for namedroppers-data@psg.com; Mon, 06 Oct 2003 23:25:52 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A6eim-0000SQ-OE for namedroppers@ops.ietf.org; Mon, 06 Oct 2003 23:24:57 +0000 Received: (from bmanning@localhost) by karoshi.com (8.11.6/8.11.6 - yeah right) id h96NNSV26236; Mon, 6 Oct 2003 16:23:28 -0700 From: bmanning@karoshi.com Message-Id: <200310062323.h96NNSV26236@karoshi.com> Subject: Re: LLMNR interoperability with Rendezvous? To: ogud@ogud.com (=?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair) Date: Mon, 6 Oct 2003 16:23:28 -0700 (PDT) Cc: cheshire@apple.com (Stuart Cheshire), namedroppers@ops.ietf.org In-Reply-To: <5.1.1.6.2.20030926094448.01648520@localhost> from "=?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair" at Oct 06, 2003 06:45:10 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.3 required=5.0 tests=IN_REP_TO,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 Content-Transfer-Encoding: 7bit > >It was only a couple of months ago, after Apple and other companies had > >been shipping products for over a year, that DNSEXT decided to reverse > >its consensus. what consensus? i've not seen any RFC that describes consensus on this topic. > Stewart, > > You shipped code against an uncompleted specification and as it goes is the llmnr spec complete? has it gone past last call and reached IESG approval to publish as an RFC? if not, there is still time to tweek the spec to meet empirical, operational feedback. > Olafur DNSEXT co-chair. --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Oct 6 20:38: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 UAA29832 for ; Mon, 6 Oct 2003 20:38:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A6fib-0006lX-KH for namedroppers-data@psg.com; Tue, 07 Oct 2003 00:28:49 +0000 Received: from [17.254.13.22] (helo=mail-out3.apple.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A6fi6-0006A9-Gu for namedroppers@ops.ietf.org; Tue, 07 Oct 2003 00:28:18 +0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.10/8.12.9) with ESMTP id h970SGvd002698 for ; Mon, 6 Oct 2003 17:28:16 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 6 Oct 2003 17:27:46 -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 h970S3WI015405; Mon, 6 Oct 2003 17:28:03 -0700 (PDT) Message-Id: <200310070028.h970S3WI015405@scv2.apple.com> Subject: Re: LLMNR interoperability with Rendezvous? Date: Mon, 6 Oct 2003 17:28:15 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "=?ISO-8859-1?Q?=d3lafur_Gudmundsson/DNSEXT_co-chair?=" , 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 >You shipped code against an uncompleted specification and as it goes >there was development on the TTL issue and consensus changed. Some >room has been provided to review the issue but the fact that there >is code shipped against an uncompleted specification is not a valid >argument in that review, only an argument to revisit the issue. > >Thus you on your own and with known consequences decided to ship code >against uncompleted specification. >If your company wants interoperabilty they can update distributions, >and possibly at the same time a put in a kludge to talk to the >old implementations. > > Sorry but that is the cold facts. > Olafur DNSEXT co-chair. =D3lafur, you're mixing up two issues. In his pejorative "freshman engineering" analogy, I thought John Schnizlein was suggesting that Apple disregarded the Working Group consensus and intentionally did the opposite for no good reason (though perhaps that's not what he was saying). I was just pointing out one simple fact. At the time we shipped, apparent Working Group consensus, as reflected in the drafts at that time, was that the TTL should be 255, and that's exactly what we did. I did *not* say that Working Groups cannot change consensus -- as we know, they do that all the time. On a related subject, I asked a while back if any LLMNR implementers had tested to see if their implementations do or do not interoperate successfully with Mac OS X. Specifically, if a LLMNR query is sent to 224.0.0.251:5353 with an IP TTL of 255, do Mac OS X machines on that link respond correctly? 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 Oct 6 22:50: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 WAA02878 for ; Mon, 6 Oct 2003 22:50:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A6hmJ-0003iw-Rs for namedroppers-data@psg.com; Tue, 07 Oct 2003 02:40:47 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A6hln-00037l-QV for namedroppers@ops.ietf.org; Tue, 07 Oct 2003 02:40:15 +0000 Received: from cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 06 Oct 2003 19:47:44 -0700 Received: from jschnizl-w2k.cisco.com (sjc-vpn1-132.cisco.com [10.21.96.132]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h972eBYc001940; Mon, 6 Oct 2003 19:40:11 -0700 (PDT) Message-Id: <4.3.2.7.2.20031006220806.00b7ced8@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 06 Oct 2003 22:40:09 -0400 To: Stuart Cheshire From: John Schnizlein Subject: Re: LLMNR interoperability with Rendezvous? Cc: "Ólafur Gudmundsson/DNSEXT co-chair" , In-Reply-To: <200310070028.h970S3WI015405@scv2.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-0.4 required=5.0 tests=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 Content-Transfer-Encoding: 8bit >>Thus you on your own and with known consequences decided to ship code >>against uncompleted specification. > >Ólafur, you're mixing up two issues. > >In his pejorative "freshman engineering" analogy, I thought John >Schnizlein was suggesting that Apple disregarded the Working Group >consensus and intentionally did the opposite for no good reason (though >perhaps that's not what he was saying). I was just pointing out one >simple fact. At the time we shipped, apparent Working Group consensus, as >reflected in the drafts at that time, was that the TTL should be 255, and >that's exactly what we did. I did *not* say that Working Groups cannot >change consensus -- as we know, they do that all the time. My plea to preserve the semantics of TTL was not pejorative "freshman engineering". The justification of TTL=255, based on misreading multicast implications, was rejected in the discussion of the issue in the ZeroConf WG. My complaint was that the consensus in the ZeroConf WG in favor of preserving the meaning of TTL, with TTL=1 for no hops (link local) in combination with Christian's accommodation of other TTLs for compatibility where an application needed something else, was reversed by the Chair based on private arguments after the issue was officially closed. I never said Apple disregarded WG consensus in deploying Rendezvous using TTL=255. I did raise the concern when the ZeroConf WG reversed the rough consensus in favor of TTL=1, that the LLMNR draft had settled on it. My personal background with Apple goes as far back as 1985, when I bought Kinetics FastPaths to connect Macintosh networks on the campus network I designed and managed. I have owned Macintosh computers since 1987, and designed an operated an AppleTalk network from 1989 until 1996. I have been a consistent supporter of the migration of AppleTalk to IP throughout this period. I admired both the Macintosh and NeXT designs and bought systems, either personally or for my various employers reflecting these opinions. This is not about me. As in the Middle-East, any position can be argued by claiming the basis at a time long enough ago. The history is less important than preserving the foundation of the Internet Protocol. I recall your statements that you had advocated TTL=1 for the reasons it gained rough consensus in the ZeroConf WG (prior to the reversal). Your argument was that Apple deployed the draft specification of TTL=255. Now that the mistaken multicast justification for TTL=255 is deprecated, and the impracticality of demanding that all (previously) installed routers block forwarding of the recently (in the larger picture) LL prefix in order to keep link-local traffic local has been recognized, please re-join the advocacy of TTL=1 for link-local. With respect, John -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Oct 7 00:48: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 AAA05834 for ; Tue, 7 Oct 2003 00:48:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A6je4-000GYm-6L for namedroppers-data@psg.com; Tue, 07 Oct 2003 04:40:24 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A6jdY-000GC1-PC for namedroppers@ops.ietf.org; Tue, 07 Oct 2003 04:39:52 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 2BA0B13966 for ; Tue, 7 Oct 2003 04:39:22 +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 =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair of "Mon, 06 Oct 2003 18:45:10 -0400." <5.1.1.6.2.20030926094448.01648520@localhost> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 07 Oct 2003 04:39:22 +0000 Message-Id: <20031007043922.2BA0B13966@sa.vix.com> X-Spam-Status: No, hits=0.1 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM 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 > >You may remember that I was one of the people who argued for TTL=1 in the > >first place, but I was swayed by the working group consensus, so we > >shipped with TTL=255, and then the working group changed its mind back > >again. > > You shipped code against an uncompleted specification and as it goes > there was development on the TTL issue and consensus changed. Some > room has been provided to review the issue but the fact that there is > code shipped against an uncompleted specification is not a valid > argument in that review, only an argument to revisit the issue. > > Thus you on your own and with known consequences decided to ship code > against uncompleted specification. > If your company wants interoperabilty they can update distributions, > and possibly at the same time a put in a kludge to talk to the > old implementations. you cannot possibly be serious. apple should have waited an extra two years to deploy functionality necessary to its product/service technology simply because the volunteers of namedroppers couldn't be bothered to do a rigorous enough review to be able to figure out a ttl issue? that's not just unlikely, it's insane. it'll never happen and shouldn't happen. meanwhile the new products entering the field won't be compatible with anything previously existing in the field. if i were a hardware or software vendor i'd either support both or support rendezvous, just to make sure there was somebody to sell it to on day 1. penalizing apple for trying hard to play well with others but launching their best guess when the deadline loomed isn't going to be effective and would not be ethical even if it was. -- to unsubscribe send a message to namedroppers-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 Oct 7 03:29: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 DAA21974 for ; Tue, 7 Oct 2003 03:29:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A6m7r-000BZD-JL for namedroppers-data@psg.com; Tue, 07 Oct 2003 07:19:19 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A6m7H-000AxN-ID for namedroppers@ops.ietf.org; Tue, 07 Oct 2003 07:18:43 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id EEBD14FCE2; Tue, 7 Oct 2003 09:18:42 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 9CA354FCD9 for ; Tue, 7 Oct 2003 09:18:42 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id h977IgNW016799 for ; Tue, 7 Oct 2003 09:18:42 +0200 Date: Tue, 7 Oct 2003 09:18:42 +0200 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: Request for Agenda Items Message-Id: <20031007091842.28423fbd.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.6 (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.222389 X-RIPE-Signature: 68903cf1bc48d5d8010c5980b21a2904 X-Spam-Status: No, hits=0.0 required=5.0 tests=BAYES_30,RCVD_IN_OSIRUSOFT_COM 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 The DNEXT WG meeting during IETF45 will be @: MONDAY, November 10, 2003 0900-1130 Morning Sessions INT dnsext DNS Extensions WG The agenda will cover administrivia and will have a large fraction of its time devoted to DNSSEC. Hereby a request for other agenda items. Please contact the chairs if you have suggestions or want to speak. -- Olaf DNSEXT Co-Chair ---------------------------------| 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 Tue Oct 7 14:28: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 OAA15531 for ; Tue, 7 Oct 2003 14:28:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A6wLI-0000IT-En for namedroppers-data@psg.com; Tue, 07 Oct 2003 18:13:52 +0000 Received: from [128.9.144.145] (helo=gamma.isi.edu) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A6wKm-0000BZ-RF for namedroppers@ops.ietf.org; Tue, 07 Oct 2003 18:13:20 +0000 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id h97IDIO08098; Tue, 7 Oct 2003 11:13:18 -0700 (PDT) Message-Id: <200310071813.h97IDIO08098@gamma.isi.edu> To: IETF-Announce: ; Subject: RFC 3596 on DNS Extensions to Support IP Version 6 Cc: rfc-editor@rfc-editor.org, namedroppers@ops.ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 07 Oct 2003 11:13:17 -0700 X-Spam-Status: No, hits=-95.3 required=5.0 tests=MIME_BOUND_NEXTPART,MSG_ID_ADDED_BY_MTA_3,NO_REAL_NAME, RCVD_IN_OSIRUSOFT_COM,TO_MALFORMED,USER_IN_WHITELIST 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 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3596 Title: DNS Extensions to Support IP Version 6 Author(s): S. Thomson, C. Huitema, V. Ksinant, M. Souissi Status: Standards Track Date: October 2003 Mailbox: sethomso@cisco.com, huitema@microsoft.com, vladimir.ksinant@6wind.com, Mohsen.Souissi@nic.fr Pages: 8 Characters: 14093 Obsoletes: 3152, 1886 I-D Tag: draft-ietf-dnsext-rfc1886bis-03.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3596.txt This document defines the changes that need to be made to the Domain Name System (DNS) to support hosts running IP version 6 (IPv6). The changes include a resource record type to store an IPv6 address, a domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves. This document is a product of the DNS Extensions Working Group of the IETF. This is now a Draft Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <031007111143.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3596 --OtherAccess Content-Type: Message/External-body; name="rfc3596.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <031007111143.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Oct 8 20:12: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 UAA16093 for ; Wed, 8 Oct 2003 20:12:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A7OJb-000ERO-E7 for namedroppers-data@psg.com; Thu, 09 Oct 2003 00:05:59 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A7OJ3-000EPw-H5 for namedroppers@ops.ietf.org; Thu, 09 Oct 2003 00:05:25 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id h9903inP025540 for ; Wed, 8 Oct 2003 20:03:44 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAxgay4X; Wed, 8 Oct 03 20:03:43 -0400 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id h98NbF1G010889 for ; Wed, 8 Oct 2003 19:37:18 -0400 (EDT) Date: Wed, 8 Oct 2003 19:37:15 -0400 (EDT) From: Sam Weiler X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org Subject: DS & TCR clarifications Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_30,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 1) Section 2.4 of DS-15 says "Algorithm MUST be an algorithm number assigned in the range 1..251 and the algorithm MUST be allowed to sign DNS data." TCR-04 retains types 253 (private, named) and 254 (private, OID), but dropped 252 (indirect), 255 (reserved), and 0 (reserved). Shouldn't DS be usable with private algorithms, too? I propose completely dropping the restriction from the DS draft. Either way, one of the drafts will probably be editted to make this explicit -- either DS will remove/change the restriction and gain a normative reference on TCR, or TCR will immediately remove/change the restriction. The question is not which of those should happen, but what the restriction should be. 2) Does the IANA registry need to include the algorithm mnemonics? I think so, since dnssec-records-04 says that DS, RRSIG, and DNSKEY presentation formats can use mnemonics. (This will be a change to the TCR draft.) 2a) Are the mnemonics in records-04, section A.1 correct? (Some algorithms need to be removed, but are the mnemonics correct?) 2b) The DS draft says nothing about using mnemonics in the presentation format (section 2.5). Do we really want to change that in DNSSECbis? -- 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 Wed Oct 8 20: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 UAA16109 for ; Wed, 8 Oct 2003 20:12:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A7OA2-000Dck-FR for namedroppers-data@psg.com; Wed, 08 Oct 2003 23:56:06 +0000 Received: from [205.229.151.150] (helo=fe-louie.olympus.f5net.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A7O9W-000Db8-PL for namedroppers@ops.ietf.org; Wed, 08 Oct 2003 23:55:34 +0000 Received: from exchone.olympus.f5net.com ([192.168.11.209]) by fe-louie.olympus.f5net.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 8 Oct 2003 16:55:34 -0700 x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: FW: RFC 3596 on DNS Extensions to Support IP Version 6 Date: Wed, 8 Oct 2003 16:55:34 -0700 Message-ID: <9C44AE0FB9D352429CB57CF47F6F989C428098@exchone> Thread-Topic: RFC 3596 on DNS Extensions to Support IP Version 6 Thread-Index: AcONAy+US/0YILFhSd6QM3/OmHdYNAA9FJOwAAAHg9A= From: "Jack Tavares" To: X-OriginalArrivalTime: 08 Oct 2003 23:55:34.0610 (UTC) FILETIME=[AA0FB320:01C38DF7] 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 So does this mean that A6 and DNAME are dead? > >=20 > > I-D Tag: draft-ietf-dnsext-rfc1886bis-03.txt > >=20 > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc3596.txt > >=20 > >=20 >=20 -- to unsubscribe send a message to namedroppers-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 Oct 8 20:46:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17265 for ; Wed, 8 Oct 2003 20:46:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A7Os7-000HHG-0n for namedroppers-data@psg.com; Thu, 09 Oct 2003 00:41:39 +0000 Received: from [211.29.163.60] (helo=bsdi.dv.isc.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A7OrX-000HDx-Uh for namedroppers@ops.ietf.org; Thu, 09 Oct 2003 00:41:06 +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 h990eI0o017360; Thu, 9 Oct 2003 10:40:21 +1000 (EST) (envelope-from marka@bsdi.dv.isc.org) Message-Id: <200310090040.h990eI0o017360@bsdi.dv.isc.org> To: "Jack Tavares" Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: FW: RFC 3596 on DNS Extensions to Support IP Version 6 In-reply-to: Your message of "Wed, 08 Oct 2003 16:55:34 MST." <9C44AE0FB9D352429CB57CF47F6F989C428098@exchone> Date: Thu, 09 Oct 2003 10:40:18 +1000 X-Spam-Status: No, hits=0.3 required=5.0 tests=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 > So does this mean that A6 and DNAME are dead? DNAME is alive and well. A6 is experimental. > > > I-D Tag: draft-ietf-dnsext-rfc1886bis-03.txt > > > > > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc3596.txt We use DNAME to map IP6.INT queries to IP6.ARPA queries. Hopefully one day there will just be: IP6.INT. DNAME IP6.ARPA. As you deploy your IP6.ARPA zone ask your IP6.INT upstream to replace you delegation with a DNAME record. Once they have a zone of DNAMES they can then do the same upwards. This requires your upstream to be using DNAME aware servers. Mark > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Oct 9 01:09: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 BAA23908 for ; Thu, 9 Oct 2003 01:09:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A7SrH-0009Ms-8Z for namedroppers-data@psg.com; Thu, 09 Oct 2003 04:57:03 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A7SqR-0009KA-J3 for namedroppers@ops.ietf.org; Thu, 09 Oct 2003 04:56:11 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id BC72F13967 for ; Thu, 9 Oct 2003 04:55:38 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: FW: RFC 3596 on DNS Extensions to Support IP Version 6 In-Reply-To: Message from "Jack Tavares" of "Wed, 08 Oct 2003 16:55:34 MST." <9C44AE0FB9D352429CB57CF47F6F989C428098@exchone> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 09 Oct 2003 04:55:38 +0000 Message-Id: <20031009045538.BC72F13967@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 dname lives a6 does not ietf may use different labels but those are the facts anyway re: > Subject: FW: RFC 3596 on DNS Extensions to Support IP Version 6 > Date: Wed, 8 Oct 2003 16:55:34 -0700 > X-MS-Has-Attach: > Thread-Topic: RFC 3596 on DNS Extensions to Support IP Version 6 > Thread-Index: AcONAy+US/0YILFhSd6QM3/OmHdYNAA9FJOwAAAHg9A= > From: "Jack Tavares" > To: > Sender: owner-namedroppers@ops.ietf.org > > So does this mean that A6 and DNAME are dead? > > > > > > > I-D Tag: draft-ietf-dnsext-rfc1886bis-03.txt > > > > > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc3596.txt > > > > > > > > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Oct 9 04:08:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10982 for ; Thu, 9 Oct 2003 04:08:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A7VjA-000O5q-Il for namedroppers-data@psg.com; Thu, 09 Oct 2003 08:00:52 +0000 Received: from [80.56.52.166] (helo=elektron.atoom.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A7Vic-000O4O-7g for namedroppers@ops.ietf.org; Thu, 09 Oct 2003 08:00:18 +0000 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.10/8.12.10/Debian-4) with ESMTP id h99808Yb002952 for ; Thu, 9 Oct 2003 10:00:11 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.10/8.12.10/Debian-4) with ESMTP id h99807Mm002949 for ; Thu, 9 Oct 2003 10:00:08 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Thu, 9 Oct 2003 10:00:07 +0200 (CEST) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: namedroppers@ops.ietf.org Subject: DNSSECbis Q-17: typecode change and TKEY Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=-3.0 required=5.0 tests=BAYES_20,USER_AGENT_PINE,X_AUTH_WARNING 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 TKEY (2930) provisions key agreement methods. One method for a resolver and a server to agree about shared secret keying material for use in TSIG (2845) is through DNS requests using, for example, Diffie-Hellman (DH) Exchanged Keying. Essentially, a resolver sends a query accompanied by a KEY RR in the additional section specifying a resolver DH key (2539), or, a KEY accompanied by its SIG(KEY). The issue at hand is the accompanied KEY RR (and SIG) in light of the recent type-code rollover, which leaves the KEY RR for the use of SIG(0) only. There are a few ways out: 1) retain KEY, SIG RR for the use of TKEY as well as SIG(0). 2) Have draft-ietf-dnsext-dnssec-2535typecode-change update RFC 2930 as well. Either way, draft-ietf-dnsext-dnssec-2535typecode-change, and 2535bis accordingly, has to include some text on this. Regards, Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Oct 9 08:26: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 IAA17374 for ; Thu, 9 Oct 2003 08:26:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A7Zi1-000IM5-1y for namedroppers-data@psg.com; Thu, 09 Oct 2003 12:15:57 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A7ZhV-000IL2-DS for namedroppers@ops.ietf.org; Thu, 09 Oct 2003 12:15:25 +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 h99CFJe7022764 for ; Thu, 9 Oct 2003 08:15:20 -0400 (EDT) Message-ID: <017a01c38e5f$02f84c10$b9370681@barnacle> From: "Scott Rose" To: References: Subject: Re: DNSSECbis Q-17: typecode change and TKEY Date: Thu, 9 Oct 2003 08:15:20 -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=0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM,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 Personally, I agree with 1). KEY could be used for transaction authentication and DNSKEY used for generating RRSIGs only. That way, KEY can retain the use of the DH algorithm code, and DNSKEY may not need it. Scott ----- Original Message ----- From: "Roy Arends" To: Sent: Thursday, October 09, 2003 4:00 AM Subject: DNSSECbis Q-17: typecode change and TKEY > TKEY (2930) provisions key agreement methods. One method for a resolver > and a server to agree about shared secret keying material for use in TSIG > (2845) is through DNS requests using, for example, Diffie-Hellman (DH) > Exchanged Keying. > > Essentially, a resolver sends a query accompanied by a KEY RR in the > additional section specifying a resolver DH key (2539), or, a KEY > accompanied by its SIG(KEY). > > The issue at hand is the accompanied KEY RR (and SIG) in light of the > recent type-code rollover, which leaves the KEY RR for the use of SIG(0) > only. > > There are a few ways out: > > 1) retain KEY, SIG RR for the use of TKEY as well as SIG(0). > 2) Have draft-ietf-dnsext-dnssec-2535typecode-change update RFC 2930 as > well. > > Either way, draft-ietf-dnsext-dnssec-2535typecode-change, and 2535bis > accordingly, has to include some text on this. > > Regards, > > Roy > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-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 Oct 9 10:49: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 KAA23023 for ; Thu, 9 Oct 2003 10:48:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A7byM-0002e2-61 for namedroppers-data@psg.com; Thu, 09 Oct 2003 14:40:58 +0000 Received: from [195.47.254.20] (helo=mail.rfc.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A7bxq-0002Zi-MQ for namedroppers@ops.ietf.org; Thu, 09 Oct 2003 14:40:26 +0000 Received: from segot-wtest (unknown [195.100.50.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rfc.se (Postfix) with ESMTP id 433B119570; Thu, 9 Oct 2003 16:40:23 +0200 (CEST) Date: Thu, 9 Oct 2003 16:40:26 +0200 (CEST) From: Jakob Schlyter To: Roy Arends Cc: namedroppers@ops.ietf.org Subject: Re: DNSSECbis Q-17: typecode change and TKEY In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_PINE 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, 9 Oct 2003, Roy Arends wrote: > 1) retain KEY, SIG RR for the use of TKEY as well as SIG(0). > 2) Have draft-ietf-dnsext-dnssec-2535typecode-change update RFC 2930 as > well. I'd would go for (1) since signing transactions and rr sets have different usages, separating the keys makes sense. jakob -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Oct 9 14:01: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 OAA01759 for ; Thu, 9 Oct 2003 14:01:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A7erY-0003MO-FH for namedroppers-data@psg.com; Thu, 09 Oct 2003 17:46:08 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A7erR-0003Lx-BC for namedroppers@ops.ietf.org; Thu, 09 Oct 2003 17:46:01 +0000 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 51CA418F8 for ; Thu, 9 Oct 2003 13:45:28 -0400 (EDT) Date: Thu, 09 Oct 2003 13:45:28 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: DNSSECbis Q-17: typecode change and TKEY In-Reply-To: References: 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: <20031009174528.51CA418F8@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Thu, 9 Oct 2003 16:40:26 +0200 (CEST), Jakob Schlyter wrote: > > On Thu, 9 Oct 2003, Roy Arends wrote: > > > 1) retain KEY, SIG RR for the use of TKEY as well as SIG(0). > > 2) Have draft-ietf-dnsext-dnssec-2535typecode-change update RFC 2930 as > > well. > > I'd would go for (1) since signing transactions and rr sets have different > usages, separating the keys makes sense. What Jakob said. -- to unsubscribe send a message to namedroppers-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 Oct 9 16:29:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09573 for ; Thu, 9 Oct 2003 16:29:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A7hH5-000A1h-7O for namedroppers-data@psg.com; Thu, 09 Oct 2003 20:20:39 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A7hGv-000A1M-8E for namedroppers@ops.ietf.org; Thu, 09 Oct 2003 20:20:29 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id h99KIlCr008933 for ; Thu, 9 Oct 2003 16:18:47 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcCAAwEaiCr; Thu, 9 Oct 03 16:18:47 -0400 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id h99JsjKY019945 for ; Thu, 9 Oct 2003 15:54:45 -0400 (EDT) Date: Thu, 9 Oct 2003 15:54:45 -0400 (EDT) From: Sam Weiler X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org Subject: mnemonics (was: Re: DS & TCR clarifications) In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00,UPPERCASE_25_50 autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 8 Oct 2003, Sam Weiler wrote: > 2a) Are the mnemonics in records-04, section A.1 correct? (Some > algorithms need to be removed, but are the mnemonics correct?) Answering my own question, since no one else has: no. records-04 also removed the mnemonics for the flags and protocol fields. Is that intentional? RFC2535 section 7 says: Value Symbol 001 RSAMD5 002 DH 003 DSA 004 ECC 252 INDIRECT 253 PRIVATEDNS 254 PRIVATEOID RFC3110 does not define a mnemonic for RSA/SHA-1 The current draft (records-04) says: VALUE Algorithm [mnemonic] RFC STATUS 0 Reserved - - 1 RSA/MD5 [RSA/MD5] RFC 2537 NOT RECOMMENDED 2 Diffie-Hellman [DH] RFC 2539 OPTIONAL 3 DSA [DSA] RFC 2536 OPTIONAL 4 elliptic curve [ECC] TBA OPTIONAL 5 RSA/SHA1 [RSA/SHA1] RFC 3110 MANDATORY 6-251 available for assignment - 252 reserved - 253 private [PRIVATE_DNS] see below OPTIONAL 254 private [PRIVATE_OID] see below OPTIONAL 255 reserved - So the mnemonics for 1 (which is "reserved" in the new registry anyway), 253, and 254 aren't the ones in 2535, and there never was a mnemonic for RSA/SHA1. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Oct 9 16:29: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 QAA09594 for ; Thu, 9 Oct 2003 16:29:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A7hH1-000A1W-Iz for namedroppers-data@psg.com; Thu, 09 Oct 2003 20:20:35 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A7hGu-000A1C-D9 for namedroppers@ops.ietf.org; Thu, 09 Oct 2003 20:20:28 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id h99KIkq5008930 for ; Thu, 9 Oct 2003 16:18:46 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAuEaiCr; Thu, 9 Oct 03 16:18:45 -0400 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id h99JrQjk019911 for ; Thu, 9 Oct 2003 15:53:26 -0400 (EDT) Date: Thu, 9 Oct 2003 15:53:26 -0400 (EDT) From: Sam Weiler X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org Subject: Re: DS & TCR clarifications In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-1.5 required=5.0 tests=BAYES_01 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > TCR-04 retains types 253 (private, named) and 254 > (private, OID), but dropped 252 (indirect), 255 (reserved), and 0 > (reserved). OK, I should re-read my own draft before posting: 0 and 255 (and 1) are still reserved -- even so, why should the DS draft restrict using them? -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Oct 9 18:44: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 SAA15351 for ; Thu, 9 Oct 2003 18:44:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A7jLo-000GPQ-Gf for namedroppers-data@psg.com; Thu, 09 Oct 2003 22:33:40 +0000 Received: from [128.9.144.145] (helo=gamma.isi.edu) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A7jLk-000GPE-68 for namedroppers@ops.ietf.org; Thu, 09 Oct 2003 22:33:36 +0000 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id h99MXXO08498; Thu, 9 Oct 2003 15:33:33 -0700 (PDT) Message-Id: <200310092233.h99MXXO08498@gamma.isi.edu> To: IETF-Announce: ; Subject: RFC 3645 on Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG) Cc: rfc-editor@rfc-editor.org, namedroppers@ops.ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 09 Oct 2003 15:33:33 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-14.3 required=5.0 tests=MIME_BOUND_NEXTPART, NO_REAL_NAME,USER_IN_DEF_WHITELIST autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3645 Title: Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG) Author(s): S. Kwan, P. Garg, J. Gilroy, L. Esibov, J. Westhead, R. Hall Status: Standards Track Date: October 2003 Mailbox: skwan@microsoft.com, praeritg@microsoft.com, jamesg@microsoft.com, levone@microsoft.com, randyhall@lucent.com, jwesth@microsoft.com Pages: 26 Characters: 56162 Updates: 2845 I-D Tag: draft-ietf-dnsext-gss-tsig-06.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3645.txt The Secret Key Transaction Authentication for DNS (TSIG) protocol provides transaction level authentication for DNS. TSIG is extensible through the definition of new algorithms. This document specifies an algorithm based on the Generic Security Service Application Program Interface (GSS-API) (RFC2743). This document updates RFC 2845. This document is a product of the DNS Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <031009153145.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3645 --OtherAccess Content-Type: Message/External-body; name="rfc3645.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <031009153145.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Oct 9 22:41:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22057 for ; Thu, 9 Oct 2003 22:41:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A7n5u-000POF-P8 for namedroppers-data@psg.com; Fri, 10 Oct 2003 02:33:30 +0000 Received: from [211.29.163.60] (helo=bsdi.dv.isc.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A7n5i-000PNU-9C for namedroppers@ops.ietf.org; Fri, 10 Oct 2003 02:33: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 h9A2WD0o021661 for ; Fri, 10 Oct 2003 12:32:16 +1000 (EST) (envelope-from marka@bsdi.dv.isc.org) Message-Id: <200310100232.h9A2WD0o021661@bsdi.dv.isc.org> To: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Fwd: Date: Fri, 10 Oct 2003 12:32:13 +1000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=0.2 required=5.0 tests=BAYES_44,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Could you forward this to namedroppers, it was only a private reply. Mark wrote: > > My preference would be just to make * CNAME behave like > any other CNAME. There is no good reason to not do this. > > It also allows for a level of indirection when the names > that match * goto a HTTP server run by a second party. > > I can live with outlawing CNAMEs. > > Note wildcard DNAMEs really need to be outlawed for exactly > the same reason CNAMEs needed to be corrected. Caches give > inconsistant/differing results based upon query history. -- to unsubscribe send a message to namedroppers-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 Oct 10 12:05: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 MAA04916 for ; Fri, 10 Oct 2003 12:05:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A7zZp-0000Ys-TE for namedroppers-data@psg.com; Fri, 10 Oct 2003 15:53:13 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A7zZZ-0000YC-Rr for namedroppers@ops.ietf.org; Fri, 10 Oct 2003 15:52:57 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id h9AFpFPg017642 for ; Fri, 10 Oct 2003 11:51:15 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAArHaiDI; Fri, 10 Oct 03 11:51:14 -0400 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id h9AFpWeP024801 for ; Fri, 10 Oct 2003 11:51:34 -0400 (EDT) Date: Fri, 10 Oct 2003 11:51:32 -0400 (EDT) From: Sam Weiler X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org Subject: Re: DS & TCR clarifications In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Next question: records-04 lists the algorithm status (optional, mandatory, not recommended) along with the parameter values and mnemonics. Should that in the registry, too? Also, we need a mnemonic for RSA/SHA-1 (for presentation formats). Make suggestions, or I'll invent one. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Oct 10 12:49: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 MAA06779 for ; Fri, 10 Oct 2003 12:49:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A80NZ-0002ix-N1 for namedroppers-data@psg.com; Fri, 10 Oct 2003 16:44:37 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A80NU-0002ik-Rw for namedroppers@ops.ietf.org; Fri, 10 Oct 2003 16:44:33 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id h9AGgoOH019720 for ; Fri, 10 Oct 2003 12:42:50 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAABdaGGM; Fri, 10 Oct 03 12:42:49 -0400 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id h9AGh9wf027243 for ; Fri, 10 Oct 2003 12:43:09 -0400 (EDT) Date: Fri, 10 Oct 2003 12:43:09 -0400 (EDT) From: Sam Weiler X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org Subject: Re: DS & TCR clarifications In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > records-04 lists the algorithm status (optional, mandatory, not > recommended) along with the parameter values and mnemonics. Should > that in the registry, too? Again, answering my own question: no. Rather, the TCR draft shouldn't do that. It's not in the registry now, we're getting by just fine, and I don't want the TCR draft to have to tackle the DSA mandatory/optional thing. If DNSSECbis wants to add status as a column in the registry, that's wonderful. Look for a new -05 that retains SIG and KEY for TKEY (sigh), renames the new registries (IESG request), and adds mnemonics to the new registry. -- 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 Oct 10 15:45:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16844 for ; Fri, 10 Oct 2003 15:45:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A830T-00095T-IL for namedroppers-data@psg.com; Fri, 10 Oct 2003 19:32:57 +0000 Received: from [195.47.254.20] (helo=mail.rfc.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A830I-00094x-7P for namedroppers@ops.ietf.org; Fri, 10 Oct 2003 19:32:46 +0000 Received: from criollo.schlyter.se (criollo.schlyter.se [195.47.254.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rfc.se (Postfix) with ESMTP id 3CE0319570; Fri, 10 Oct 2003 21:32:43 +0200 (CEST) Date: Fri, 10 Oct 2003 21:32:42 +0200 (CEST) From: Jakob Schlyter To: Sam Weiler Cc: namedroppers@ops.ietf.org Subject: Re: DS & TCR clarifications In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 10 Oct 2003, Sam Weiler wrote: > Also, we need a mnemonic for RSA/SHA-1 (for presentation formats). > Make suggestions, or I'll invent one. RSASHA1 jakob -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Oct 12 04:52: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 EAA12514 for ; Sun, 12 Oct 2003 04:52:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8bio-0006N4-FP for namedroppers-data@psg.com; Sun, 12 Oct 2003 08:37:02 +0000 Received: from [192.150.250.67] (helo=fuchsia.home) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A8bia-0006MU-1x for namedroppers@ops.ietf.org; Sun, 12 Oct 2003 08:36:48 +0000 Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h9BKPZIl018286 for ; Sun, 12 Oct 2003 03:25:36 +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 h9BKD3a24039 for ; Sun, 12 Oct 2003 03:13:05 +0700 (ICT) From: Robert Elz To: namedroppers@ops.ietf.org Subject: Any decision on wildcard CNAME ? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 12 Oct 2003 03:13:03 +0700 Message-ID: <11723.1065903183@munnari.OZ.AU> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_30 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I'm trying to work out what the WG decision is on wildcard CNAME so a new draft can get submitted sometime soon... As best I can tell, Masatake Ohta and Mark Andrews favour simply defining it to work (in the full and naturally expected way). Rob Austein and Olaf Kolkman seemed to prefer simply defining it to be illegal (or undefined, or something essentially equivalent). I, and I think some others (but I don't remember the names) want the thing fixed, but I don't care which of the above ways. Randy Bush and Paul Vixie seemed to want to leave the DNS with inconsistent results possible. Or did the last time they wrote. Large numbers of other people who I know read this list haven't expressed an opinion at all. Please do - without more input, there isn't going to be any way to come to any kind of conclusion on this. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Oct 12 05:21: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 FAA12948 for ; Sun, 12 Oct 2003 05:21:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8cMK-0007sN-1m for namedroppers-data@psg.com; Sun, 12 Oct 2003 09:17:52 +0000 Received: from [192.96.22.18] (helo=citadel.cequrux.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A8cMA-0007rS-SG for namedroppers@ops.ietf.org; Sun, 12 Oct 2003 09:17:43 +0000 Received: (from nobody@localhost) by citadel.cequrux.com (8.8.8/8.6.9) id LAA27126 for ; Sun, 12 Oct 2003 11:17:25 +0200 (SAST) Received: by citadel.cequrux.com via recvmail id 27124; Sun, 12 Oct 2003 11:16:52 +0200 (SAST) Date: Sun, 12 Oct 2003 11:16:51 +0200 From: Alan Barrett To: namedroppers@ops.ietf.org Subject: Re: Any decision on wildcard CNAME ? Message-ID: <20031012091651.GB7390@apb.cequrux.com> References: <11723.1065903183@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11723.1065903183@munnari.OZ.AU> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-1.5 required=5.0 tests=BAYES_01 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sun, 12 Oct 2003, Robert Elz wrote: > Large numbers of other people who I know read this list haven't > expressed an opinion at all. Please do - without more input, there > isn't going to be any way to come to any kind of conclusion on this. Either "it should work" or "it is illegal" will do, but I have a slight preference for defining it to work in the naturally expected way. The present situation, where people can argue that it is defined to give inconsistent results, is unacceptable. --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 Sun Oct 12 06:19: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 GAA13984 for ; Sun, 12 Oct 2003 06:19:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8dF7-0009wR-8A for namedroppers-data@psg.com; Sun, 12 Oct 2003 10:14:29 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A8dEq-0009vx-Mo for namedroppers@ops.ietf.org; Sun, 12 Oct 2003 10:14:12 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.12.8p2/8.12.8) with ESMTP id h9CADPvl029224; Sun, 12 Oct 2003 12:13:25 +0200 (CEST) (envelope-from ted@open.nlnetlabs.nl) Received: (from ted@localhost) by open.nlnetlabs.nl (8.12.8p2/8.12.8/Submit) id h9CADPtW029223; Sun, 12 Oct 2003 12:13:25 +0200 (CEST) (envelope-from ted) Message-Id: <200310121013.h9CADPtW029223@open.nlnetlabs.nl> From: ted@NLnetLabs.nl (Ted Lindgreen) Date: Sun, 12 Oct 2003 12:13:25 +0200 In-Reply-To: "Robert Elz's message as of Oct 12, 10:55" X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Robert Elz , namedroppers@ops.ietf.org Subject: Re: Any decision on wildcard CNAME ? X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-1.5 required=5.0 tests=BAYES_01 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [Quoting Robert Elz, on Oct 12, 10:55, in "Any decision on wild ..."] > Large numbers of other people who I know read this list haven't > expressed an opinion at all. Please do - without more input, there > isn't going to be any way to come to any kind of conclusion on this. We (developers of NSD) are (strongly) in favor of defining it to be illegal. Second best is make it work, provided that does not further complicate DNSSEC. Leaving it inconsistent will make implementing DNSSEC very difficult if not impossible. -- ted -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Oct 12 09:11: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 JAA16933 for ; Sun, 12 Oct 2003 09:11:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8fsE-000HWx-IY for namedroppers-data@psg.com; Sun, 12 Oct 2003 13:03:02 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1A8fsA-000HWQ-RH for namedroppers@ops.ietf.org; Sun, 12 Oct 2003 13:02:59 +0000 Received: (qmail 28769 invoked from network); 12 Oct 2003 13:01:02 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 12 Oct 2003 13:01:02 -0000 Message-ID: <3F895134.3000703@necom830.hpcl.titech.ac.jp> Date: Sun, 12 Oct 2003 22:03:48 +0900 From: masataka ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Ted Lindgreen CC: Robert Elz , namedroppers@ops.ietf.org Subject: Re: Any decision on wildcard CNAME ? References: <200310121013.h9CADPtW029223@open.nlnetlabs.nl> In-Reply-To: <200310121013.h9CADPtW029223@open.nlnetlabs.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ted; >>Large numbers of other people who I know read this list haven't >>expressed an opinion at all. Please do - without more input, there >>isn't going to be any way to come to any kind of conclusion on this. > > > We (developers of NSD) are (strongly) in favor of defining it > to be illegal. > > Second best is make it work, provided that does not further > complicate DNSSEC. Leaving it inconsistent will make > implementing DNSSEC very difficult if not impossible. My understanding is that the issue is orthogonal to DNSSEC complexity. 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 Sun Oct 12 13:33: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 NAA23753 for ; Sun, 12 Oct 2003 13:33:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8jv8-0007JD-Rt for namedroppers-data@psg.com; Sun, 12 Oct 2003 17:22:18 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A8jus-0007IX-S9 for namedroppers@ops.ietf.org; Sun, 12 Oct 2003 17:22:03 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.12.8p2/8.12.8) with ESMTP id h9CHLNvl031012 for ; Sun, 12 Oct 2003 19:21:23 +0200 (CEST) (envelope-from ted@open.nlnetlabs.nl) Received: (from ted@localhost) by open.nlnetlabs.nl (8.12.8p2/8.12.8/Submit) id h9CHLNja031011 for namedroppers@ops.ietf.org; Sun, 12 Oct 2003 19:21:23 +0200 (CEST) (envelope-from ted) Message-Id: <200310121721.h9CHLNja031011@open.nlnetlabs.nl> From: ted@NLnetLabs.nl (Ted Lindgreen) Date: Sun, 12 Oct 2003 19:21:23 +0200 X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: namedroppers@ops.ietf.org Subject: Re: Any decision on wildcard CNAME ? X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [Quoting masataka ohta, on Oct 12, 15:12, in "Re: Any decision on ..."] > > Second best is make it work, provided that does not further > > complicate DNSSEC. Leaving it inconsistent will make > > implementing DNSSEC very difficult if not impossible. > > My understanding is that the issue is orthogonal to DNSSEC complexity. Then I am probably missing something. Please enlighten us on what algoritme to use to prove correctness or non-existence of an RR derived from expansion of a wildcard CNAME with its current definition? We have great problems with this now, and want to get on with our work. -- ted -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Oct 12 15:14: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 PAA26212 for ; Sun, 12 Oct 2003 15:14:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8lXb-000CSV-16 for namedroppers-data@psg.com; Sun, 12 Oct 2003 19:06:07 +0000 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A8lXU-000CRs-0Y for namedroppers@ops.ietf.org; Sun, 12 Oct 2003 19:06:00 +0000 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 12 Oct 2003 12:05:59 -0700 Received: from 157.54.5.25 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 12 Oct 2003 12:05:59 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 12 Oct 2003 12:05:59 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 12 Oct 2003 12:02:19 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Sun, 12 Oct 2003 12:05:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Any decision on wildcard CNAME ? Date: Sun, 12 Oct 2003 12:05:57 -0700 Message-ID: Thread-Topic: Any decision on wildcard CNAME ? thread-index: AcOQ53oVj9KxG9ajSaiPSWjSAkBVowAC76EQ From: "Christian Huitema" To: "Ted Lindgreen" , X-OriginalArrivalTime: 12 Oct 2003 19:05:58.0355 (UTC) FILETIME=[DEA89A30:01C390F3] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-0.0 required=5.0 tests=BAYES_40 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > Then I am probably missing something. Please enlighten us on what > algoritme to use to prove correctness or non-existence of an RR > derived from expansion of a wildcard CNAME with its current definition? Yup. How is that different from a load balancing DNS making up records on the fly? Or a server programmed to synthesize PTR records? If you cannot see the problem on the wire, then you cannot rule out the behavior. Now, there are two ways were you might see the behavior "on the wire": in a zone transfer, and in a DNSSEC computation. Whatever rule is written can only be written in one of these two contexts. -- Christian Huitema=20 -- to unsubscribe send a message to namedroppers-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 Oct 12 16:06: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 QAA27252 for ; Sun, 12 Oct 2003 16:06:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8mQX-000Fcx-EY for namedroppers-data@psg.com; Sun, 12 Oct 2003 20:02:53 +0000 Received: from [217.215.21.151] (helo=poledra.8in.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A8mQO-000Faz-By for namedroppers@ops.ietf.org; Sun, 12 Oct 2003 20:02:44 +0000 Received: from amalthea.8in.net ([192.168.242.14] helo=amalthea) by poledra.8in.net with asmtp (Exim 3.35 #1 (Debian)) id 1A8mQF-00082a-00 for ; Sun, 12 Oct 2003 22:02:35 +0200 Message-ID: <01f701c390fb$e1d96e20$0ef2a8c0@amalthea> From: =?iso-8859-1?Q?Kandra_Nyg=E5rds?= To: References: <11723.1065903183@munnari.OZ.AU> Subject: Re: Any decision on wildcard CNAME ? Date: Sun, 12 Oct 2003 22:02:39 +0200 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.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit From: "Robert Elz" > I'm trying to work out what the WG decision is on wildcard CNAME > so a new draft can get submitted sometime soon... > > As best I can tell, Masatake Ohta and Mark Andrews favour simply > defining it to work (in the full and naturally expected way). I don't like wildcards in general, but I don't see any reason why a synthesized record should have different rules than a "natural" record. I'll go with this line, at least as far as the protocol goes. - Kandra -- to unsubscribe send a message to namedroppers-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 Oct 12 18:31: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 SAA02397 for ; Sun, 12 Oct 2003 18:31:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8ob9-0000SC-NR for namedroppers-data@psg.com; Sun, 12 Oct 2003 22:21:59 +0000 Received: from [207.65.203.98] (helo=goose.ehsco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A8oax-0000Qu-41 for namedroppers@ops.ietf.org; Sun, 12 Oct 2003 22:21:47 +0000 Received: from [207.65.3.26] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 4.1.3) with ESMTP-TLS id 635186; Sun, 12 Oct 2003 21:07:28 -0500 Message-ID: <3F89D3F7.1070801@ehsco.com> Date: Sun, 12 Oct 2003 17:21:43 -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: Robert Elz CC: namedroppers@ops.ietf.org Subject: Re: Any decision on wildcard CNAME ? References: <11723.1065903183@munnari.OZ.AU> In-Reply-To: <11723.1065903183@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-1.4 required=5.0 tests=BAYES_20 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 10/11/2003 3:13 PM Robert Elz wrote: > Large numbers of other people who I know read this list haven't > expressed an opinion at all. Please do - without more input, there > isn't going to be any way to come to any kind of conclusion on this. I don't have an implementation to vote with but if I did I'd vote to make wildcards work with CNAME as per other inherent limitations. -- 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 Sun Oct 12 18:35: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 SAA02475 for ; Sun, 12 Oct 2003 18:35:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8ojX-0001AY-4B for namedroppers-data@psg.com; Sun, 12 Oct 2003 22:30:39 +0000 Received: from [211.29.163.60] (helo=bsdi.dv.isc.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A8ojQ-00019i-Ja for namedroppers@ops.ietf.org; Sun, 12 Oct 2003 22:30:32 +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 h9CMTK0o031812; Mon, 13 Oct 2003 08:29:21 +1000 (EST) (envelope-from marka@bsdi.dv.isc.org) Message-Id: <200310122229.h9CMTK0o031812@bsdi.dv.isc.org> To: ted@NLnetLabs.nl (Ted Lindgreen) Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: Any decision on wildcard CNAME ? In-reply-to: Your message of "Sun, 12 Oct 2003 19:21:23 +0200." <200310121721.h9CHLNja031011@open.nlnetlabs.nl> Date: Mon, 13 Oct 2003 08:29:20 +1000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-0.7 required=5.0 tests=BAYES_10,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > [Quoting masataka ohta, on Oct 12, 15:12, in "Re: Any decision on ..."] > > > > Second best is make it work, provided that does not further > > > complicate DNSSEC. Leaving it inconsistent will make > > > implementing DNSSEC very difficult if not impossible. > > > > My understanding is that the issue is orthogonal to DNSSEC complexity. > > Then I am probably missing something. Please enlighten us on what > algoritme to use to prove correctness or non-existence of an RR > derived from expansion of a wildcard CNAME with its current definition? > We have great problems with this now, and want to get on with our work. You prove wildcard CNAMEs exactly the same way that you prove wildcard A records. Verify the name does not exist. (NSEC) Verify that expanded owner name matches the signature. (RRSIG). Banning records actually introduces MORE work for DNSSEC. You then have to check that you are not receiving a banned record. > -- ted > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Oct 13 04:46: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 EAA26776 for ; Mon, 13 Oct 2003 04:46:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8yAs-0002t7-0L for namedroppers-data@psg.com; Mon, 13 Oct 2003 08:35:30 +0000 Received: from [155.140.121.249] (helo=lonn000636.uk.net.intra) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A8yAf-0002rc-H3 for namedroppers@ops.ietf.org; Mon, 13 Oct 2003 08:35:17 +0000 Received: from lonn000941.bnpparibas.com (unverified) by lonn000636.uk.net.intra (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 13 Oct 2003 09:36:32 +0100 Subject: Re: Any decision on wildcard CNAME ? To: kre@munnari.OZ.AU Cc: namedroppers@ops.ietf.org From: tony.milton@bnpparibas.com Date: Mon, 13 Oct 2003 09:35:13 +0100 Message-ID: X-MIMETrack: Serialize by Router on LONSMTP003/SERVERS/SMTP(Release 5.0.12 |February 13, 2003) at 13/10/2003 09:34:48 AM MIME-Version: 1.0 Content-type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=0.2 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I'm with Masatake Ohta and Mark Andrews - define it to work. Regards, Tony Milton Internet kre@munnari.OZ.AU@ops.ietf.org - 11/10/2003 21:13 Sent by: owner-namedroppers@ops.ietf.org To: namedroppers cc: Subject: Any decision on wildcard CNAME ? I'm trying to work out what the WG decision is on wildcard CNAME so a new draft can get submitted sometime soon... As best I can tell, Masatake Ohta and Mark Andrews favour simply defining it to work (in the full and naturally expected way). Rob Austein and Olaf Kolkman seemed to prefer simply defining it to be illegal (or undefined, or something essentially equivalent). I, and I think some others (but I don't remember the names) want the thing fixed, but I don't care which of the above ways. Randy Bush and Paul Vixie seemed to want to leave the DNS with inconsistent results possible. Or did the last time they wrote. Large numbers of other people who I know read this list haven't expressed an opinion at all. Please do - without more input, there isn't going to be any way to come to any kind of conclusion on this. 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: This message and any attachments (the "message") is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. --------------------------------------------- Ce message et toutes les pieces jointes (ci-apres le "message") sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie. -- to unsubscribe send a message to namedroppers-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 Oct 13 09:10: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 JAA02916 for ; Mon, 13 Oct 2003 09:10:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A92GR-000MGF-UK for namedroppers-data@psg.com; Mon, 13 Oct 2003 12:57:31 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A92G5-000MES-Sj for namedroppers@ops.ietf.org; Mon, 13 Oct 2003 12:57:10 +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 h9DCv6D06274; Mon, 13 Oct 2003 19:57:06 +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 h9DCqEI00211; Mon, 13 Oct 2003 19:52:17 +0700 (ICT) From: Robert Elz To: Mark.Andrews@isc.org cc: ted@NLnetLabs.nl (Ted Lindgreen), namedroppers@ops.ietf.org Subject: Re: Any decision on wildcard CNAME ? In-Reply-To: <200310122229.h9CMTK0o031812@bsdi.dv.isc.org> References: <200310122229.h9CMTK0o031812@bsdi.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 13 Oct 2003 19:52:14 +0700 Message-ID: <15159.1066049534@munnari.OZ.AU> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Mon, 13 Oct 2003 08:29:20 +1000 From: Mark.Andrews@isc.org Message-ID: <200310122229.h9CMTK0o031812@bsdi.dv.isc.org> | Banning records actually introduces MORE work for DNSSEC. You | then have to check that you are not receiving a banned record. I have heard a similar sentiment (expressed in a different way) in private mail (which I would prefer not to receive - everyone send opinions to the list - unless you have an editorial not in the document) though, which suggests that perhaps a clarification of the option might be in order. I'm not certain this is what Olaf had in mind when he suggested this, but my impression of what "banning" the records would do isn't quite like that. That is, I don't think it is reasonable (or probably even possible) to outlaw the transmission of a CNAME record that was constructed from a wildcard, nor to force servers to barf on such things - as they might on an RR like name IN A 1.2.3.4.5 but that making it illegal would be specified something like is currently done when specifying that having the RDATA in an NS record be a CNAME is illegal. That is, if you do that, the server, caches, resolvers, may do anything that like with your data, treat the record as if it doesn't exist, treat it as if it does, with almost any meaning they like ... so just "don't do that". That is, provided we make it clear that a wildcard CNAME record isn't something that should be expected to exist, and is not intended to be handled (in any way at all), what implementations actually do should one be found, is entirely their business - including "let's try and make it work", "BARF loading the zone file and refuse to accept it", "do according to what appears to be the strict interpretation of the algorithm in 3.4.2 of 1034", or almost anything else (dumping core is not included though...) What effect that might have on the DNSSEC algorithms, especially wrt non-existence, I have no idea. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Oct 13 09:36: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 JAA04363 for ; Mon, 13 Oct 2003 09:36:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A92m2-000Osl-5A for namedroppers-data@psg.com; Mon, 13 Oct 2003 13:30:10 +0000 Received: from [127.0.0.1] (helo=roam.psg.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A92lt-000OqN-Ix; Mon, 13 Oct 2003 13:30:05 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A92lg-000BMd-3r; Mon, 13 Oct 2003 15:29:48 +0200 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 13 Oct 2003 15:29:45 +0200 To: Robert Elz Cc: namedroppers@ops.ietf.org Subject: Re: Any decision on wildcard CNAME ? References: <11723.1065903183@munnari.OZ.AU> Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-1.5 required=5.0 tests=BAYES_01 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Randy Bush and Paul Vixie seemed to want to leave the DNS with inconsistent > results possible. no, results consistent with 1034. if qtype=cname then return it. if not, don't. randy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Oct 13 10:13: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 KAA06815 for ; Mon, 13 Oct 2003 10:13:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A93MD-0001uP-3S for namedroppers-data@psg.com; Mon, 13 Oct 2003 14:07:33 +0000 Received: from [211.29.163.60] (helo=bsdi.dv.isc.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A93M7-0001tY-0W for namedroppers@ops.ietf.org; Mon, 13 Oct 2003 14:07:27 +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 h9DE680o033535 for ; Tue, 14 Oct 2003 00:06:08 +1000 (EST) (envelope-from marka@bsdi.dv.isc.org) Message-Id: <200310131406.h9DE680o033535@bsdi.dv.isc.org> To: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: Any decision on wildcard CNAME ? In-reply-to: Your message of "Mon, 13 Oct 2003 15:29:45 +0200." Date: Tue, 14 Oct 2003 00:06:08 +1000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-1.4 required=5.0 tests=BAYES_01,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > Randy Bush and Paul Vixie seemed to want to leave the DNS with inconsistent > > results possible. > > no, results consistent with 1034. if qtype=cname then return it. > if not, don't. > > randy Which leaves caches returning inconsistant result dependent on query history. So you want mail to go through from a MTA that make explict CNAME queries and not to go through from a MTA that makes implict CNAME queries (e.g. MX/A/AAAA)? Mark > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Oct 13 12:25: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 MAA13895 for ; Mon, 13 Oct 2003 12:25:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A95NN-000C1X-A9 for namedroppers-data@psg.com; Mon, 13 Oct 2003 16:16:53 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A95NB-000C0M-L5 for namedroppers@ops.ietf.org; Mon, 13 Oct 2003 16:16:41 +0000 Received: (from bmanning@localhost) by karoshi.com (8.11.6/8.11.6 - yeah right) id h9DGG4r31373; Mon, 13 Oct 2003 09:16:04 -0700 Date: Mon, 13 Oct 2003 09:16:04 -0700 From: bmanning@vacation.karoshi.com To: Robert Elz Cc: namedroppers@ops.ietf.org Subject: Re: Any decision on wildcard CNAME ? Message-ID: <20031013091604.A31325@vacation.karoshi.com> References: <11723.1065903183@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <11723.1065903183@munnari.OZ.AU>; from kre@munnari.OZ.AU on Sun, Oct 12, 2003 at 03:13:03AM +0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-1.4 required=5.0 tests=BAYES_01,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sun, Oct 12, 2003 at 03:13:03AM +0700, Robert Elz wrote: > I'm trying to work out what the WG decision is on wildcard CNAME > so a new draft can get submitted sometime soon... > > As best I can tell, Masatake Ohta and Mark Andrews favour simply > defining it to work (in the full and naturally expected way). In the best of all possible worlds, I think this is the right tactic. --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Oct 13 13:59:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17617 for ; Mon, 13 Oct 2003 13:59:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A96lq-000Jf3-Pu for namedroppers-data@psg.com; Mon, 13 Oct 2003 17:46:14 +0000 Received: from [204.152.186.164] (helo=gusto.araneus.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A96lj-000Jdk-1T for namedroppers@ops.ietf.org; Mon, 13 Oct 2003 17:46:07 +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.10/8.12.9) with ESMTP id h9DHioZc019758; Mon, 13 Oct 2003 10:44:50 -0700 (PDT) Received: from guava.araneus.fi (localhost [127.0.0.1]) by guava.araneus.fi (8.12.10/8.11.6) with ESMTP id h9DHiopE024150; Mon, 13 Oct 2003 10:44:50 -0700 (PDT) Received: (from gson@localhost) by guava.araneus.fi (8.12.10/8.12.6/Submit) id h9DHinlH018060; Mon, 13 Oct 2003 10:44:49 -0700 (PDT) Date: Mon, 13 Oct 2003 10:44:49 -0700 (PDT) Message-Id: <200310131744.h9DHinlH018060@guava.araneus.fi> To: namedroppers@ops.ietf.org Subject: Re: Any decision on wildcard CNAME ? In-Reply-To: <11723.1065903183@munnari.OZ.AU> References: <11723.1065903183@munnari.OZ.AU> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=BAYES_00,NO_REAL_NAME, RCVD_IN_RFCI autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Robert Elz writes: > Large numbers of other people who I know read this list haven't > expressed an opinion at all. I favor the option of "defining it to work (in the full and naturally expected way)". -- 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 Oct 13 14:43: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 OAA19637 for ; Mon, 13 Oct 2003 14:43:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A97Y6-000OeN-80 for namedroppers-data@psg.com; Mon, 13 Oct 2003 18:36:06 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A97Xv-000OdO-R5 for namedroppers@ops.ietf.org; Mon, 13 Oct 2003 18:35:55 +0000 Received: by shell-ng.nominum.com (Postfix, from userid 1411) id 9D9D356857; Mon, 13 Oct 2003 11:35:54 -0700 (PDT) To: namedroppers@ops.ietf.org Subject: Re: Any decision on wildcard CNAME ? References: <11723.1065903183@munnari.OZ.AU> From: Bob Halley Date: 13 Oct 2003 11:35:54 -0700 In-Reply-To: <11723.1065903183@munnari.OZ.AU> Message-ID: Lines: 5 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I prefer "define it to work" as well. I think this is the least-surprising approach and it doesn't add any more special cases to the server. /Bob -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Oct 13 16:06: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 QAA24657 for ; Mon, 13 Oct 2003 16:06:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A98nV-00073F-J2 for namedroppers-data@psg.com; Mon, 13 Oct 2003 19:56:05 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A98mw-0006yk-1u for namedroppers@ops.ietf.org; Mon, 13 Oct 2003 19:55:30 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23807; Mon, 13 Oct 2003 15:55:20 -0400 (EDT) Message-Id: <200310131955.PAA23807@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-05.txt Date: Mon, 13 Oct 2003 15:55:19 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 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-05.txt Pages : 5 Date : 2003-10-13 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 changes the type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) to avoid those interactions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-2535typecode-change-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-2535typecode-change-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-2535typecode-change-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-13145426.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-2535typecode-change-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-2535typecode-change-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-13145426.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 Oct 13 16:20: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 QAA26040 for ; Mon, 13 Oct 2003 16:20:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A9951-0009AI-Lq for namedroppers-data@psg.com; Mon, 13 Oct 2003 20:14:11 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A994u-00099O-82 for namedroppers@ops.ietf.org; Mon, 13 Oct 2003 20:14:04 +0000 Received: from cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 13 Oct 2003 13:14:47 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9DKE0Sw017340; Mon, 13 Oct 2003 13:14:01 -0700 (PDT) Received: from cisco.com ([161.44.65.126]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADC42501; Mon, 13 Oct 2003 16:13:59 -0400 (EDT) Message-ID: <3F8B0787.4080305@cisco.com> Date: Mon, 13 Oct 2003 16:13:59 -0400 From: Josh Littlefield Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Elz CC: namedroppers@ops.ietf.org Subject: Re: Any decision on wildcard CNAME ? References: <11723.1065903183@munnari.OZ.AU> In-Reply-To: <11723.1065903183@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I believe wildcard CNAMES should be defined to work like other wildcards. Despite the pseudo-code in 4.3.2, I have to imagine that was the original intent of RFC1034, because there is no other indication that wildcards to not apply to aliases. I still think this is in the realm of clarification. I also believe it matches common interpretation and implementation. -josh Robert Elz wrote: > I'm trying to work out what the WG decision is on wildcard CNAME > so a new draft can get submitted sometime soon... > > As best I can tell, Masatake Ohta and Mark Andrews favour simply > defining it to work (in the full and naturally expected way). > > Rob Austein and Olaf Kolkman seemed to prefer simply defining it to > be illegal (or undefined, or something essentially equivalent). > > I, and I think some others (but I don't remember the names) want the > thing fixed, but I don't care which of the above ways. > > Randy Bush and Paul Vixie seemed to want to leave the DNS with inconsistent > results possible. Or did the last time they wrote. > > Large numbers of other people who I know read this list haven't > expressed an opinion at all. Please do - without more input, there > isn't going to be any way to come to any kind of conclusion on this. > > kre -- ===================================================================== Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 1414 Massachusetts Avenue tel: 978-936-1379 fax: same Boxborough, MA 01719-2205 -- to unsubscribe send a message to namedroppers-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 Oct 13 16:46: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 QAA27973 for ; Mon, 13 Oct 2003 16:46:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A99Uu-000BbB-3s for namedroppers-data@psg.com; Mon, 13 Oct 2003 20:40:56 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A99Um-000BaV-Tm for namedroppers@ops.ietf.org; Mon, 13 Oct 2003 20:40:48 +0000 Received: (from bmanning@localhost) by karoshi.com (8.11.6/8.11.6 - yeah right) id h9DKekP00812; Mon, 13 Oct 2003 13:40:46 -0700 From: bmanning@karoshi.com Message-Id: <200310132040.h9DKekP00812@karoshi.com> Subject: latency/discover To: namedroppers@ops.ietf.org Date: Mon, 13 Oct 2003 13:40:46 -0700 (PDT) Cc: bmanning@karoshi.com X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=0.2 required=5.0 tests=BAYES_50,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit FYI. the draft that defines a new op-code, discover, that passed WG last-call early this year and then went into suspended animation pending some language clarifications will be re-emerging shortly. Given the delay between last call and the text cleanup, it might be prudent to have folk look it over again (given the WG has new ADs, new WG chairs, and has been re-chartered since the last time this doc has seen the light of day... :) --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Oct 14 15:47: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 PAA27058 for ; Tue, 14 Oct 2003 15:47:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A9Uvd-0000b8-VD for namedroppers-data@psg.com; Tue, 14 Oct 2003 19:33:57 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A9UvX-0000aL-Kc for namedroppers@ops.ietf.org; Tue, 14 Oct 2003 19:33:51 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25973; Tue, 14 Oct 2003 15:33:41 -0400 (EDT) Message-Id: <200310141933.PAA25973@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-dnsext-opcode-discover-02.txt Date: Tue, 14 Oct 2003 15:33:41 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_01,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 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 : The DISCOVER opcode Author(s) : B. Manning, P. Vixie, E. Guttman Filename : draft-dnsext-opcode-discover-02.txt Pages : 0 Date : 2003-10-14 The QUERY opcode in the DNS is designed for unicast. With the development of multicast capabilities in the DNS, it is desireable to have a more robust opcode for server interactions since a single request may result in replies from multiple responders. So DISCOVER is defined to deal with replies from multiple responders. As such, this document extend the core DNS specifications to allow clients to have a method for coping with replies from multiple responders. Use of this new opcode may facilitate DNS operations in modern networking topologies. A prototype of the DISCOVER opcode was developed as part of the TBDS project, funded under DARPA grant F30602-99-1-0523. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dnsext-opcode-discover-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-dnsext-opcode-discover-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-dnsext-opcode-discover-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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-10-14133622.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-dnsext-opcode-discover-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-dnsext-opcode-discover-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-14133622.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Oct 16 08:39: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 IAA00761 for ; Thu, 16 Oct 2003 08:39:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AA7C9-000IAg-KR for namedroppers-data@psg.com; Thu, 16 Oct 2003 12:25:33 +0000 Received: from [80.56.52.166] (helo=elektron.atoom.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AA7Bz-000IA1-8d for namedroppers@ops.ietf.org; Thu, 16 Oct 2003 12:25:23 +0000 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.10/8.12.10/Debian-4) with ESMTP id h9GCPIfj018283 for ; Thu, 16 Oct 2003 14:25:18 +0200 Received: (from miekg@localhost) by elektron.atoom.net (8.12.10/8.12.10/Debian-4) id h9GCPIQL018282 for namedroppers@ops.ietf.org; Thu, 16 Oct 2003 14:25:18 +0200 Date: Thu, 16 Oct 2003 14:25:18 +0200 From: Miek Gieben To: namedroppers Subject: wildcard as empty non terminal Message-ID: <20031016122518.GB18170@atoom.net> Mail-Followup-To: namedroppers Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-2.3 required=5.0 tests=BAYES_00,RCVD_IN_DYNABLOCK autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hello, while reading the wildcard clarification draft and trying to implement it in NSD, we had the following discussion. The draft states: 2. Defining the Wild Card Domain Name A wild card domain name is defined by having the initial label be: 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal) This defines domain names that may play a role in being a wild card, that is, being a source for synthesized answers. Domain names conforming to this definition that appear in queries and RDATA sections do not have any special role. These cases will be described in more detail in following sections. That is clear. In (to pick one) *.com, the '*' is a wildcard, in a.*.com the '*' is not a wildcard. Next consider this: we have a zone file with this: a.*.b rdata (this implicitely defines *.b as an empty non terminal) Next we get a query for x.y.b. Ok, we process the query, find the closest encloser, which is .b. Then we look for *.b, now it does start with a '*' so it has to be considered a wildcard. So x.y.b will match on *.b? Is this correct reasening? If not, where do we go wrong? 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 Thu Oct 16 09:06: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 JAA01642 for ; Thu, 16 Oct 2003 09:06:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AA7kl-000K1J-78 for namedroppers-data@psg.com; Thu, 16 Oct 2003 13:01:19 +0000 Received: from [211.29.163.60] (helo=bsdi.dv.isc.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AA7kg-000K0w-6m for namedroppers@ops.ietf.org; Thu, 16 Oct 2003 13:01:14 +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 h9GCxt0o066602 for ; Thu, 16 Oct 2003 22:59:55 +1000 (EST) (envelope-from marka@bsdi.dv.isc.org) Message-Id: <200310161259.h9GCxt0o066602@bsdi.dv.isc.org> To: namedroppers From: Mark.Andrews@isc.org Mail-Followup-To: namedroppers Subject: Re: wildcard as empty non terminal In-reply-to: Your message of "Thu, 16 Oct 2003 14:25:18 +0200." <20031016122518.GB18170@atoom.net> Date: Thu, 16 Oct 2003 22:59:55 +1000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Hello, > > while reading the wildcard clarification draft and trying to implement it in > NSD, we had the following discussion. > > The draft states: > > 2. Defining the Wild Card Domain Name > > A wild card domain name is defined by having the initial label be: > > 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal) > > This defines domain names that may play a role in being a wild card, > that is, being a source for synthesized answers. Domain names > conforming to this definition that appear in queries and RDATA > sections do not have any special role. These cases will be described > in more detail in following sections. > > That is clear. In (to pick one) *.com, the '*' is a wildcard, in > a.*.com the '*' is not a wildcard. > > Next consider this: > we have a zone file with this: > > a.*.b rdata > > (this implicitely defines *.b as an empty non terminal) > > Next we get a query for x.y.b. Ok, we process the query, find the closest > encloser, which is .b. Then we look for *.b, now it does start with a '*' so > it > has to be considered a wildcard. So x.y.b will match on *.b? Yes. > Is this correct reasening? If not, where do we go wrong? > > 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: -- 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 Oct 16 09:43: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 JAA02907 for ; Thu, 16 Oct 2003 09:43:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AA8IJ-000MIS-DT for namedroppers-data@psg.com; Thu, 16 Oct 2003 13:35:59 +0000 Received: from [80.56.52.166] (helo=elektron.atoom.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AA8I7-000MHb-84 for namedroppers@ops.ietf.org; Thu, 16 Oct 2003 13:35:47 +0000 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.10/8.12.10/Debian-4) with ESMTP id h9GDZgfj019161 for ; Thu, 16 Oct 2003 15:35:42 +0200 Received: (from miekg@localhost) by elektron.atoom.net (8.12.10/8.12.10/Debian-4) id h9GDZgu7019160 for namedroppers@ops.ietf.org; Thu, 16 Oct 2003 15:35:42 +0200 Date: Thu, 16 Oct 2003 15:35:42 +0200 From: Miek Gieben To: namedroppers Subject: Re: wildcard as empty non terminal Message-ID: <20031016133542.GA19147@atoom.net> Mail-Followup-To: namedroppers References: <20031016122518.GB18170@atoom.net> <200310161259.h9GCxt0o066602@bsdi.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200310161259.h9GCxt0o066602@bsdi.dv.isc.org> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-2.3 required=5.0 tests=BAYES_00,RCVD_IN_DYNABLOCK autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 16 Oct, @14:59, Mark.Andre wrote in "Re: wildcard as empty non term ..."] > > Next consider this: > > we have a zone file with this: > > > > a.*.b rdata > > > > (this implicitely defines *.b as an empty non terminal) > > > > Next we get a query for x.y.b. Ok, we process the query, find the closest > > encloser, which is .b. Then we look for *.b, now it does start with a '*' so > > it > > has to be considered a wildcard. So x.y.b will match on *.b? > > Yes. > ok, so a "lonely" '*' in a zonefile is always to be considered a wildcard, only stuff like aba*.com does not qualify? 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 Thu Oct 16 09:43: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 JAA02923 for ; Thu, 16 Oct 2003 09:43:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AA8MS-000Maq-Ut for namedroppers-data@psg.com; Thu, 16 Oct 2003 13:40:16 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AA8MN-000MZx-46 for namedroppers@ops.ietf.org; Thu, 16 Oct 2003 13:40:11 +0000 Received: (qmail 47066 invoked from network); 16 Oct 2003 13:39:26 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 16 Oct 2003 13:39:26 -0000 Message-ID: <3F8E9FF4.1090506@necom830.hpcl.titech.ac.jp> Date: Thu, 16 Oct 2003 22:41:08 +0900 From: masataka ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Mark.Andrews@isc.org CC: namedroppers Subject: Re: wildcard as empty non terminal References: <200310161259.h9GCxt0o066602@bsdi.dv.isc.org> In-Reply-To: <200310161259.h9GCxt0o066602@bsdi.dv.isc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mark; >>Next we get a query for x.y.b. Ok, we process the query, find the closest >>encloser, which is .b. Then we look for *.b, now it does start with a '*' so >>it >>has to be considered a wildcard. So x.y.b will match on *.b? > > > Yes. I think it is a reasonable clarification following 4.3.2, even though 4.3.3 states: : In the previous algorithm, special treatment was given to RRs with owner : names starting with the label "*". Such RRs are called wildcards. 4.3.3 should, instead, have stated : In the previous algorithm, special treatment was given to owner names : starting with the label "*". Such owner names are called wildcards. 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 Oct 17 23:07: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 XAA04377 for ; Fri, 17 Oct 2003 23:07:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AAhEk-0001KX-7F for namedroppers-data@psg.com; Sat, 18 Oct 2003 02:54:38 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AAhEe-0001Jo-OU for namedroppers@ops.ietf.org; Sat, 18 Oct 2003 02:54:32 +0000 Received: from ENGILL.ogud.com (ns.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id h9I2sKuG009967; Fri, 17 Oct 2003 22:54:20 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.0.0.22.2.20031016161952.0268eaa0@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 17 Oct 2003 22:54:20 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: Document review: draft-brand-drip-02.txt Cc: rsbx@acm.org, laurence@sherzer.net, ietf-drip-draft@spamblock.gamerz.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This document has been submitted to the RFC editor for publication. The IESG has asked the working group to comment on the DNS protocol aspects of this document. This is one of the roles this working group has in its charter. The URI for the document is: http://www.ietf.org/internet-drafts/draft-brand-drip-02.txt From ID announce message: > Title : Designated Relays Inquiry Protocol (DRIP) > Author(s) : R. Brand, L. Sherzer, R. W. Rognlie > Filename : draft-brand-drip-02.txt > Pages : 21 > Date : 2003-10-15 > >The Designated Relays Inquiry Protocol, DRIP, is a method for domain >name owners to specify the IP addresses that are authorized to relay >mail as a domain name. The protocol provides a method for server MTAs >to reject SMTP connections from IP addresses not authorized to use a >domain name. Please send in any comments/suggestions about the DNS aspects of this draft. Any commentary about the applicability of what is described in the document is out of scope for this discussion. The document proposes both a new RR type and a naming convention for it, the first is directly in scope of the working group, the second one probably is outside the scope of the working group. Given that the naming convention is closely tied to the structure of the proposed RR type, we will allow discussion about both. The DNSEXT chairs will summarize any comments/suggestions received 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 Sat Oct 18 09:19:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27800 for ; Sat, 18 Oct 2003 09:19:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AAqmw-000ERL-RT for namedroppers-data@psg.com; Sat, 18 Oct 2003 13:06:34 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AAqmp-000EQS-Bf for namedroppers@ops.ietf.org; Sat, 18 Oct 2003 13:06:27 +0000 Received: from hlid.md.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id h9ID65uF014308; Sat, 18 Oct 2003 09:06:06 -0400 (EDT) (envelope-from ogud@ogud.com) Received: from localhost (ogud@localhost) by hlid.md.ogud.com (8.12.8p2/8.12.8/Submit) with ESMTP id h9ID64XE014305; Sat, 18 Oct 2003 09:06:05 -0400 (EDT) X-Authentication-Warning: hlid.md.ogud.com: ogud owned process doing -bs Date: Sat, 18 Oct 2003 09:06:04 -0400 (EDT) From: Olafur Gudmundsson X-X-Sender: ogud@hlid.md.ogud.com To: Miek Gieben cc: namedroppers Subject: Re: wildcard as empty non terminal In-Reply-To: <20031016122518.GB18170@atoom.net> Message-ID: <20031018090310.Y14268@hlid.md.ogud.com> References: <20031016122518.GB18170@atoom.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 16 Oct 2003, Miek Gieben wrote: > Hello, > > while reading the wildcard clarification draft and trying to implement it in > NSD, we had the following discussion. > > The draft states: > > 2. Defining the Wild Card Domain Name > > A wild card domain name is defined by having the initial label be: > > 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal) > > This defines domain names that may play a role in being a wild card, > that is, being a source for synthesized answers. Domain names > conforming to this definition that appear in queries and RDATA > sections do not have any special role. These cases will be described > in more detail in following sections. > > That is clear. In (to pick one) *.com, the '*' is a wildcard, in > a.*.com the '*' is not a wildcard. > > Next consider this: > we have a zone file with this: > > a.*.b rdata > > (this implicitely defines *.b as an empty non terminal) > > Next we get a query for x.y.b. Ok, we process the query, find the closest > encloser, which is .b. Then we look for *.b, now it does start with a '*' so it > has to be considered a wildcard. So x.y.b will match on *.b? > > Is this correct reasening? If not, where do we go wrong? IMHO, wildcard algorigthm is only applicalble to terminal nodes in the tree. your system should see that when it reaches node *.b that there is a child node,or at least flag that this name has a child. Thus the wildcard algorithm should be disabled for that *.b. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Oct 18 14:16: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 OAA04307 for ; Sat, 18 Oct 2003 14:16:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AAvRR-000DkU-84 for namedroppers-data@psg.com; Sat, 18 Oct 2003 18:04:41 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AAvRK-000DjO-5D for namedroppers@ops.ietf.org; Sat, 18 Oct 2003 18:04:34 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 073791395D for ; Sat, 18 Oct 2003 18:03:56 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers Subject: Re: wildcard as empty non terminal In-Reply-To: Message from Olafur Gudmundsson of "Sat, 18 Oct 2003 09:06:04 -0400." <20031018090310.Y14268@hlid.md.ogud.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sat, 18 Oct 2003 18:03:56 +0000 Message-Id: <20031018180356.073791395D@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_10 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ... your system should see that when it reaches node *.b that there > is a child node,or at least flag that this name has a child. > > Thus the wildcard algorithm should be disabled for that *.b. i agree. -- to unsubscribe send a message to namedroppers-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 Oct 18 16:43: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 QAA08861 for ; Sat, 18 Oct 2003 16:43:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AAxmp-0005Gl-01 for namedroppers-data@psg.com; Sat, 18 Oct 2003 20:34:55 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AAxmh-0005Fs-4z for namedroppers@ops.ietf.org; Sat, 18 Oct 2003 20:34:47 +0000 Received: from ENGILL.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id h9IKYRuI015426; Sat, 18 Oct 2003 16:34:28 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.0.0.22.2.20031018163047.02b6bb80@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Sat, 18 Oct 2003 16:33:31 -0400 To: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair , namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: Re: Document review: draft-brand-drip-02.txt Cc: rsbx@acm.org, laurence@sherzer.net, ietf-drip-draft@spamblock.gamerz.net In-Reply-To: <6.0.0.22.2.20031016161952.0268eaa0@localhost> References: <6.0.0.22.2.20031016161952.0268eaa0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable At 22:54 2003-10-17, =D3lafur Gudmundsson/DNSEXT co-chair wrote: Correction: >The document proposes both a new RR type and a naming convention for it, >the first is directly in scope of the working group, the second one >probably is outside the scope of the working group. >Given that the naming convention is closely tied to the structure of >the proposed RR type, we will allow discussion about both. I made a mistake in my post. Somehow I misread section 3.2 to mean it was defining ${TYPE} as a new type. This document only defines a naming structure, that uses A and AAAA records. >The DNSEXT chairs will summarize any comments/suggestions received >to the IESG. We will close this review in 2 weeks. Olafur > 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 Oct 21 07:50:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14251 for ; Tue, 21 Oct 2003 07:50:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ABumM-0002nR-2C for namedroppers-data@psg.com; Tue, 21 Oct 2003 11:34:22 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ABum8-0002n8-AK for namedroppers@ops.ietf.org; Tue, 21 Oct 2003 11:34:08 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 8F1D14E3B9; Tue, 21 Oct 2003 13:34:07 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id D0BFA4E1EB; Tue, 21 Oct 2003 13:34:06 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id h9LBY6VZ003245; Tue, 21 Oct 2003 13:34:06 +0200 Date: Tue, 21 Oct 2003 13:34:06 +0200 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Cc: ogud@ogud.com Subject: Re: Any decision on wildcard CNAME ? Message-Id: <20031021133406.7a9bc890.olaf@ripe.net> In-Reply-To: <11723.1065903183@munnari.OZ.AU> References: <11723.1065903183@munnari.OZ.AU> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.6 (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.131299 X-RIPE-Signature: a2bf69b96a34dea516d4a7a2e14f26ac X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Namedroppers, After being off-line for over a week I just had the time to review the thread. Conclusion: The working group has consensus to modify wcard-clarify to allow for CNAMEs with wildcards and Process: This is a change to 1034. Even if it is only a clarification it should stand out really clear. We can do two things, modify the "wildcard clarify" document or spawn off a small I-D that documents the change only. Personally I have a preference for a small I-D, since there is already consensus on the content it should be a trivial thing to get through the WG. Any takers? --Olaf Summary of the discussion follows, no further comments in-line. The thread started with an issue raised by Vixie. http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01818.html The core of the problem is that the 1034 algorithm rules will not allow for a CNAME chain to be followed at a wildcard node except for when QTYPE=CNAME. This creates an inconsistency for caching forwarders: based on the query history (QTYPE has been CNAME or not) the caching forwarder will give different answers. After some discussion the consensus was reached that this problem needed to be addressed. Two possible solutions where presented and the working group was asked to reach consensus on those. (http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01853.html) After the call by Elz ( http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01895.html ) we had a number of people expressing a clear preference for allowing CNAMEs to exist in combination with wildcards. -- Olaf DNSEXT Co-Chair ---------------------------------| 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 Tue Oct 21 13:27: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 NAA27162 for ; Tue, 21 Oct 2003 13:27:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AC05a-000ISL-KT for namedroppers-data@psg.com; Tue, 21 Oct 2003 17:14:34 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AC05T-000IS5-PL for namedroppers@ops.ietf.org; Tue, 21 Oct 2003 17:14:27 +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 h9LHECe7007131 for ; Tue, 21 Oct 2003 13:14:12 -0400 (EDT) Message-ID: <032901c397f6$bfea53e0$b9370681@barnacle> From: "Scott Rose" To: Subject: DNSSECbis algorithm mnemonics (cleanup fix) Date: Tue, 21 Oct 2003 13:14:13 -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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-0.0 required=5.0 tests=BAYES_44 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit There is an error in the algorithm mnemonics in the current edition of the DNSSECbis records draft (-04 I believe). To bring the mnemonics back into line, they should be (and corrected back to): code mnemonic 1 RSAMD5 2 DH 3 DSA 4 ECC 5 RSASHA1 252 PRIVATEDNS 253 PRIVATEOID NOTE: there is no previously assigned mnemonic for RSA with SHA1. 'RSASHA1' is in line with the RSAMD5, so it seems reasonable. If no one has any objections, RSASHA1 will be the mnemonic from this point on. If there are, please state what the choice should be. 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 Oct 21 15:33:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02917 for ; Tue, 21 Oct 2003 15:33:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AC27F-000P6r-JD for namedroppers-data@psg.com; Tue, 21 Oct 2003 19:24:25 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AC278-000P6J-4K for namedroppers@ops.ietf.org; Tue, 21 Oct 2003 19:24:18 +0000 Received: from ENGILL.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id h9LJNauG029273 for ; Tue, 21 Oct 2003 15:23:39 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.0.0.22.2.20031021103604.02697e50@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Tue, 21 Oct 2003 15:24:04 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: DNSEXT WGLC Summary: LLMNR Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-1.5 required=5.0 tests=BAYES_01 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This last call has concluded. There was been extensive discussion about this draft. A number of new issues raised and closed. The most new document version (-24) reflects all the issues raised and closed in the working group last call. Summary: the working group has reached consensus to advance this document as a standards track document. This document is of high quality and the process that lead to this state is well documented on the document issues tracker website: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html. Some issues raised during the last call that where rejected. This is normal and expected. This even holds for objections based on shipping code tailored to an older version of this document, as no specification is to be considered final until after publication as an RFC. In particular there was extensive discussion about the TTL==[1 or 255] in this case the WG decided that it had made the right choice by selecting 1, see http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html#Issue 47 http://psg.com/lists/namedroppers/namedroppers.2003/msg01609.html 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 Oct 21 17:03: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 RAA09362 for ; Tue, 21 Oct 2003 17:03:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AC3Vw-0008iz-OH for namedroppers-data@psg.com; Tue, 21 Oct 2003 20:54:00 +0000 Received: from [17.254.13.22] (helo=mail-out3.apple.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AC3Vp-0008ie-4o for namedroppers@ops.ietf.org; Tue, 21 Oct 2003 20:53:53 +0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.10/8.12.9) with ESMTP id h9LKrrTi011688 for ; Tue, 21 Oct 2003 13:53:53 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 21 Oct 2003 13:53:21 -0700 Received: from [17.202.40.111] (graejo.apple.com [17.202.40.111]) by scv3.apple.com (8.12.9/8.12.9) with ESMTP id h9LKrQ0m016606; Tue, 21 Oct 2003 13:53:26 -0700 (PDT) In-Reply-To: <6.0.0.22.2.20031021103604.02697e50@localhost> References: <6.0.0.22.2.20031021103604.02697e50@localhost> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-14-415601979; protocol="application/pkcs7-signature" Message-Id: Cc: namedroppers@ops.ietf.org From: Joshua Graessley Subject: Re: DNSEXT WGLC Summary: LLMNR Date: Tue, 21 Oct 2003 13:53:51 -0700 To: =?ISO-8859-1?Q?=D3lafur_Gudmundsson/DNSEXT_co-chair?= X-Mailer: Apple Mail (2.606) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-1.5 required=5.0 tests=BAYES_01 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --Apple-Mail-14-415601979 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Speaking as an individual (as is always the case at the IETF), not as a=20= representative of Apple... A brilliant move by the working group. My congratulations to those=20 involved. By refusing to interoperate to punish a vendor for shipping a=20= product in a timely manner, the document this working group has=20 produced will now have to compete with that vendor. It's a good thing=20 the IETF exists to help fragment the market. LLMNR as defined in draft 24 is useless in my opinion. In order to=20 satisfy everyone, compromises were made. So many compromises that the=20 protocol is nearly useless. I see no reason why any vendor would=20 implement it, it doesn't seem to solve any problems. I am interested in a solution to the problem of ad-hoc networks. Two=20 people meet and use a cross over cable. LLMNR does not address that=20 scenario because there is no guidance on what name a device would have.=20= While many on this working group are probably responsible for a domain=20= or know someone who is, there are many people that use nothing but=20 dial-up and DSL. Many of those people have NATs, where their machines=20 have private addresses. Their computers don't really have a host name=20 they can call their own. In the ad-hoc scenario, such a user would have=20= no idea what name to use for their laptop. For this reason, LLMNR does=20= not address my needs for the ad-hoc solution. I am is also interested in solutions to common home network problems.=20 The world is filled with NATs. Many people have a few machines at home=20= with private addresses. Those machines don't have DNS names. When a=20 friend comes over with a laptop and plugs in, that friend gets an=20 address. The ability to use names in such a scenario would be a huge=20 benefit. As it is, that friend will get a configured DNS server address=20= just like every other device on that network. LLMNR is next to useless=20= at that point. If the laptop is configured to respond to a name such as=20= joe.example.com, LLMNR will never query for that name because there is=20= already a DNS name joe.example.com. The only name that would work with=20= LLMNR is one that gives an error when sending the query to a normal DNS=20= server. Maybe "joe." gives an error today. That might change in time.=20 Suddenly things stop working. The user has to come up with an easy to=20 remember name that will always fail when sent to DNS to get LLMNR to=20 work. LLMNR could have been used for new devices introduced on the network.=20 Headless devices like ethernet cameras have complicated manuals for=20 configuring the device the first time. The manual usually requires the=20= user to set their computer to an address in a specific subnet and then=20= connect to the device at a specific address on that subnet. With LLMNR,=20= the device could instead use DHCP or IPv4LL to acquire an address and=20 advertise the name with LLMNR. Configuration would be as simple as=20 launching a browser and typing in the LLMNR name of the device. What=20 LLMNR name could such a device use? It's not clear. Using Apple's mDNS protocol, I have solutions to all three scenarios.=20 Using LLMNR, I don't have a solution to any of these scenarios. Why=20 would I pick LLMNR over mDNS? With so many failure cases and no clear way to help a user configure=20 LLMNR, who would implement LLMNR and why? As stated in the Introduction "The goal of LLMNR is to enable name=20 resolution in scenarios in which conventional DNS name resolution is=20 not possible.". I think LLMNR fails to meet this goal. -josh On Oct 21, 2003, at 12:24 PM, =D3lafur Gudmundsson/DNSEXT co-chair = wrote: > > This last call has concluded. > There was been extensive discussion about this draft. > A number of new issues raised and closed. The most new document > version (-24) reflects all the issues raised and closed in the > working group last call. > > Summary: the working group has reached consensus to advance this > document as a standards track document. > > This document is of high quality and the process that lead to this=20 > state > is well documented on the document issues > tracker website: = http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html. > > Some issues raised during the last call that where rejected. This is > normal and expected. This even holds for objections based on > shipping code tailored to an older version of this document, as no > specification is to be considered final until after publication as an=20= > RFC. > In particular there was extensive discussion about the TTL=3D=3D[1 or = 255] > in this case the WG decided that it had made the right choice by > selecting 1, see > http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html#Issue 47 > http://psg.com/lists/namedroppers/namedroppers.2003/msg01609.html > > Olafur=20= --Apple-Mail-14-415601979 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAwqwATANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDMwOTA1MTgyNzUwWhcNMDQwOTA0MTgyNzUwWjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRqZ3JhZXNzbGV5QGFwcGxl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM7EXVgIo1XLZWghTrlD+Lyvh01y IH3rl7Q5SYYMwX2EQytFr3XZeubyuBy5kV3IjrDiI2R2siVX+pLCDsy7sWccyqCkqusGFRyiDyRI xb6ydueBxrAz26AfavFWmAZp+mdPt4qbXmlhoIwbb5UsqxfgO1mpFMB6Xh/FpS0ZkLMkrsYB0KFN 1STxdwNpZnlVNS7B/MlmaevcC59VzmPn6m2Ud7RTVqxYE49AYqnNDo9f/byj+RwKGjFpD+mjut8I kOpL2J0VM8KcCw9RZS3mZSTIyLYxVEgqLlrcyxo5Bwv0hde+CCYN2ZprMz3D9vymHmpGyhaJsnRe o5oNETuX2nUCAwEAAaMxMC8wHwYDVR0RBBgwFoEUamdyYWVzc2xleUBhcHBsZS5jb20wDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBVU7HfJ6R7f/4YqQ8iEa9pqZX9A9j2MU67D43nWolj XRdeQGxCkCWOrJLG7UgtiUvas7B9mZhRYYj0KrI3xkSX+N3G/IXDHo6OLH2rJY/43PRMj8CbWkP3 rPLTBZg2guU7a2wkgRig1heEaUBinl9h5TxfDosmHXKtiWVUFuVTXDCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDCrABMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTAyMTIwNTM1MVowIwYJKoZIhvcNAQkEMRYEFFMK CjSCueM6mAKCRHkPu919RLq/MHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMKsAEwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDCrABMA0GCSqGSIb3DQEBAQUABIIBAJ75 R28QezcOnsC1mFDzQRfrkrAeHPIbKYQeFlRC6TLoymyj9hN0JVTDj9SS4Nb1zuXbxDbRD4qN9QGZ bWrRnYu0Jh5MDqJH/xzrgTv2S9vR237t+frgW/Ms2IeSjwsYVhTbQcDGk3hpqnqmO1Wc53WZKObN kMk5XSso5L8oI6M9NSi8s//rOuc7+DWVrCF0LJyvmz2HHOsT5Q544RAq0wZ/PChoat0o0ZiezK9Q kmYof9Ip8iKutfFLeF9ijqDVfUcj28O2HMUFB9ZdCuC4o4y8BfYWCOtAXFxqP/1LRhH1ao7NpBQu vI158TxqH1Q9SrUigqh69yi0s+3gJ9FDeIoAAAAAAAA= --Apple-Mail-14-415601979-- -- to unsubscribe send a message to namedroppers-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 Oct 21 17:20: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 RAA10269 for ; Tue, 21 Oct 2003 17:20:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AC3rF-000AQf-In for namedroppers-data@psg.com; Tue, 21 Oct 2003 21:16:01 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AC3r8-000AQA-CE for namedroppers@ops.ietf.org; Tue, 21 Oct 2003 21:15:54 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 322CF1394C for ; Tue, 21 Oct 2003 21:15:24 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC Summary: LLMNR In-Reply-To: Message from Joshua Graessley of "Tue, 21 Oct 2003 13:53:51 MST." X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 21 Oct 2003 21:15:24 +0000 Message-Id: <20031021211524.322CF1394C@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-1.5 required=5.0 tests=BAYES_01 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk i have no comments for or against the quality of either the document or the protocol for either mDNS or LLMNR. however, i will echo one of joshua's concerns, which is that the document that will be advanced seems to be a compromise which will please nobody. i very much wish that there had been a design team, and community buy-in at the vision level, rather than the fragmented market that will apparently now exist. -- to unsubscribe send a message to namedroppers-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 Oct 21 18:00: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 SAA13021 for ; Tue, 21 Oct 2003 18:00:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AC4R4-000Cqx-9F for namedroppers-data@psg.com; Tue, 21 Oct 2003 21:53:02 +0000 Received: from [219.101.47.130] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AC4Qv-000CqN-C0 for namedroppers@ops.ietf.org; Tue, 21 Oct 2003 21:52:53 +0000 Received: by coconut.itojun.org (Postfix, from userid 1001) id 70C2C91; Wed, 22 Oct 2003 06:52:51 +0900 (JST) To: ogud@ogud.com Cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC Summary: LLMNR In-Reply-To: Your message of "Tue, 21 Oct 2003 15:24:04 -0400" <6.0.0.22.2.20031021103604.02697e50@localhost> References: <6.0.0.22.2.20031021103604.02697e50@localhost> X-Mailer: Cue version 0.6 (031002-0709/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20031021215251.70C2C91@coconut.itojun.org> Date: Wed, 22 Oct 2003 06:52:51 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > This last call has concluded. > There was been extensive discussion about this draft. > A number of new issues raised and closed. The most new document > version (-24) reflects all the issues raised and closed in the > working group last call. > > Summary: the working group has reached consensus to advance this > document as a standards track document. > > This document is of high quality and the process that lead to this state > is well documented on the document issues > tracker website: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html. document quality might be high, but if it does not interoperate with major implementation out there (i.e. Apple Rendezvous/mDNS) the document would be useless. 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 Tue Oct 21 20:39: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 UAA21514 for ; Tue, 21 Oct 2003 20:39:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AC6zE-000NCl-E5 for namedroppers-data@psg.com; Wed, 22 Oct 2003 00:36:28 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AC6z4-000NCF-P3 for namedroppers@ops.ietf.org; Wed, 22 Oct 2003 00:36:19 +0000 Received: (qmail 70451 invoked from network); 22 Oct 2003 00:37:12 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 22 Oct 2003 00:37:12 -0000 Message-ID: <3F95D144.9040106@necom830.hpcl.titech.ac.jp> Date: Wed, 22 Oct 2003 09:37:24 +0900 From: masataka ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Joshua Graessley CC: =?ISO-8859-1?Q?=D3lafur_Gudmundsson/DNSEXT_co-chair?= , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC Summary: LLMNR References: <6.0.0.22.2.20031021103604.02697e50@localhost> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Josh; > A brilliant move by the working group. My congratulations to those > involved. By refusing to interoperate to punish a vendor for shipping a > product in a timely manner, the document this working group has produced > will now have to compete with that vendor. It's a good thing the IETF > exists to help fragment the market. > > LLMNR as defined in draft 24 is useless in my opinion. I tend to agree, but, with reasons different from yours. If LLMNR is useless, it is not because of the way it was standardized but because its purpose is meaningless. > In order to > satisfy everyone, compromises were made. So many compromises that the > protocol is nearly useless. I see no reason why any vendor would > implement it, it doesn't seem to solve any problems. Vendors, especially biggest ones, have been having no trouble implementing useless protocols solving no problems. > I am interested in a solution to the problem of ad-hoc networks. Two > people meet and use a cross over cable. LLMNR does not address that > scenario because there is no guidance on what name a device would have. > While many on this working group are probably responsible for a domain > or know someone who is, there are many people that use nothing but > dial-up and DSL. Many of those people have NATs, where their machines > have private addresses. Their computers don't really have a host name > they can call their own. In the ad-hoc scenario, such a user would have > no idea what name to use for their laptop. For this reason, LLMNR does > not address my needs for the ad-hoc solution. Wrong. You can give a globally unique domain name for anything which may or may not be connected to the Internet. For example, a vendor can, at factory, assign its products globally unique domain names such as: abcd1234.pc.apple.com or abcd1234.camera.apple.com which is no more difficult than assigning MAC addresses for NIC cards. The vendor can, like NSI, even sell premium names. Thus, you have no trouble to use the globally unique (no worrying about name conflict) domain name in ad-hoc networks. Of course, if we don't have access to DNS, we may have alternative protocol, which may or may not be LLMNR. > As stated in the Introduction "The goal of LLMNR is to enable name > resolution in scenarios in which conventional DNS name resolution is not > possible.". I think LLMNR fails to meet this goal. I think it does, though I'm not sure the goal is meaningful. Masataka Ohta PS I'm not actively for or against LLMNR. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Oct 21 20:40: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 UAA21540 for ; Tue, 21 Oct 2003 20:40:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AC6vD-000MzE-2O for namedroppers-data@psg.com; Wed, 22 Oct 2003 00:32:19 +0000 Received: from [216.126.80.155] (helo=www.markbaker.ca) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AC6v5-000Myp-Dx for namedroppers@ops.ietf.org; Wed, 22 Oct 2003 00:32:11 +0000 Received: (from mbaker@localhost) by www.markbaker.ca (8.11.6/8.11.6) id h9M0X6i30230 for namedroppers@ops.ietf.org; Tue, 21 Oct 2003 20:33:06 -0400 Date: Tue, 21 Oct 2003 20:33:06 -0400 From: Mark Baker To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC Summary: LLMNR Message-ID: <20031021203306.D15751@www.markbaker.ca> References: <6.0.0.22.2.20031021103604.02697e50@localhost> <20031021215251.70C2C91@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20031021215251.70C2C91@coconut.itojun.org>; from itojun@itojun.org on Wed, Oct 22, 2003 at 06:52:51AM +0900 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-1.4 required=5.0 tests=BAYES_20 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, Oct 22, 2003 at 06:52:51AM +0900, Jun-ichiro itojun Hagino wrote: > document quality might be high, but if it does not interoperate with > major implementation out there (i.e. Apple Rendezvous/mDNS) the > document would be useless. I concur. I hope the WG appreciates what a mess it's creating. Is the TTL issue really *that* important? I don't really know (I'm more an apps guy), but the fact that the group has, at various times, held both positions, suggests to me that it isn't. Very disappointing ... Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca -- to unsubscribe send a message to namedroppers-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 Oct 21 23:01: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 XAA24985 for ; Tue, 21 Oct 2003 23:01:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AC91h-0004mT-Am for namedroppers-data@psg.com; Wed, 22 Oct 2003 02:47:09 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AC91X-0004lq-Qf for namedroppers@ops.ietf.org; Wed, 22 Oct 2003 02:47:00 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h9M2AmN14438 for ; Tue, 21 Oct 2003 19:10:48 -0700 Date: Tue, 21 Oct 2003 19:10:48 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC Summary: LLMNR Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, Oct 22, 2003 Mark Baker said: >I concur. >I hope the WG appreciates what a mess it's creating. Is the TTL issue >really *that* important? Yes, it is. If there is one critical achievement that is most important about the Internet it is the ability of hosts from different vendors to interoperate with TCP/IP. Today it is possible to take two hosts from almost any TCP/IP implementation and do things like transfer files (FTP). We've gotten so used to doing this that at times we don't appreciate how valuable this is -- or how easily this basic interoperability can be broken. Whatever else we do in the IETF, there is one thing that a specification must never do -- that is to break the basic interoperability of TCP/IP. If a new IETF specification can somehow make it impossible for two hosts which formerly interoperated to transfer a file that specification is fundamentally broken. It's one thing to create useless specifications -- but it's another thing to break fundamental aspects of the Internet architecture. The most important task of any IETF WG is to "do no harm". There are times when a poorly designed protocol, if deployed on a small scale, will not be harmful, but when deployed on a wide scale, can have large undesirable effects. The standardization of such a protocol cannot be justified purely on the basis of its immediate usefulness -- in fact it is precisely those protocols that are thought to be most useful which can create the biggest problems. So the issue here is not 'why doesn't the IETF bless this cool thing', but rather "what are the implications if this 'cool thing' were to be ubiquitously deployed on the Internet?" As IETF participants, we have the obligation to look beyond the short term to the long-term implications. The reality is that the early IPv4 Link-Local and mDNS specifications, were they to be widely deployed, have the potential to do serious damage. In IPv4 Link-Local, setting TTL=255 in IPv4 and testing for this breaks basic TCP/IP interoperability. Most IPv4 hosts today do not set TTL=255, and therefore any IPv4 host which requires TTL=255 in received packets will be unable to communicate with most existing hosts. If a host with a routable IPv4 address does not use this when available, and sets and tests for TTL=255, then it is possible for two hosts which both have routable addresses and formerly were able to communicate will be unable to talk to each other. This behavior was considered so problematic that when the IPv4 Link-Local specification went to IETF last call, there was an outpouring of concern about the consequences of its ill-considered design. As a result, the ZEROCONF WG has had to spend the last year rewriting the IPv4 Link-Local specification so as to "do no harm". The current specification no longer mandates a test for a TTL value, and prefers a routable address when available. It is perhaps not as "useful" as the early versions -- but it also does not break the basic interoperability of TCP/IP. Similar considerations arose in the design of the LLMNR protocol. In order to "do no harm" it was necessary to avoid adding new saddlebags to an old hourse -- such as trying to use DNS as a global service discovery mechanism, as DNS-SD does. It's one thing to ship something like this on a small proportion of Internet hosts -- but it's another thing entirely to attempt deploy something like that on a global scale. Making major modifications to protocols that form the fundamental underpinings of the Internet (such as DNS and BGP) is not just another "bad idea" -- it has the potential to cause major problems with the Internet architecture. The DNSEXT WG wisely decided that going down this road was inappropriate. It also decided that to avoid the potential for multicast storms it was necessary to restrict use of mDNS to link-scope. Furthermore, it was critical to enforce port and cache separation so that LLMNR could not be used to pollute the DNS cache and vice versa. To "do no harm" LLMNR needs to guarantee that it will come up with the same answer to a query as DNS would if the RRs are available, so that in normal use the results of a gethostbyname() call do not depend on which mechanism is used. To avoid leaking IPv4 Link-Local addresses beyond their scope, it is necessary for LLMNR to only return addresses and names valid on the interface on which the query was received and also to preferrentially return routable addresses when they are available. As the issues list shows, each of these issues resulted in changes being made to the LLMNR specification that caused it to diverge from the early mDNS specifications, but each change was carefully considered and thought through. While LLMNR has been a journey of a thousand steps, it is far from a random walk. While many of these decisions made LLMNR somewhat less 'useful' -- at the same time, they also made major problems less likely. The Internet is no longer an experiment today -- it's mission-critical infrastructure that millions of people rely on every day. That implies a higher level of due diligence. -- to unsubscribe send a message to namedroppers-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 Oct 22 03:43: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 DAA27838 for ; Wed, 22 Oct 2003 03:43:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACDWc-000LYo-JG for namedroppers-data@psg.com; Wed, 22 Oct 2003 07:35:22 +0000 Received: from [17.254.13.22] (helo=mail-out3.apple.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACDWE-000LWZ-TU for namedroppers@ops.ietf.org; Wed, 22 Oct 2003 07:34:58 +0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.10/8.12.9) with ESMTP id h9M7YwTi021173 for ; Wed, 22 Oct 2003 00:34:58 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 22 Oct 2003 00:34:27 -0700 Received: from [17.219.195.181] ([17.219.195.181]) by scv2.apple.com (8.12.9/8.12.9) with ESMTP id h9M7YfEV001973 for ; Wed, 22 Oct 2003 00:34:41 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v606) In-Reply-To: References: Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2-454067525; protocol="application/pkcs7-signature" Message-Id: <3C302004-0462-11D8-AD19-000A95B9474C@apple.com> From: Joshua Graessley Subject: Re: DNSEXT WGLC Summary: LLMNR Date: Wed, 22 Oct 2003 00:34:56 -0700 To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.606) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --Apple-Mail-2-454067525 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Oct 21, 2003, at 7:10 PM, Bernard Aboba wrote: > On Wed, Oct 22, 2003 Mark Baker said: > >> I concur. > >> I hope the WG appreciates what a mess it's creating. Is the TTL issue >> really *that* important? > > Yes, it is. > > If there is one critical achievement that is most important about the > Internet it is the ability of hosts from different vendors to > interoperate > with TCP/IP. Today it is possible to take two hosts from almost > any TCP/IP implementation and do things like transfer files (FTP). > We've > gotten so used to doing this that at times we don't appreciate how > valuable this is -- or how easily this basic interoperability can be > broken. > > Whatever else we do in the IETF, there is one thing that a > specification > must never do -- that is to break the basic interoperability of TCP/IP. > If a new IETF specification can somehow make it impossible > for two hosts which formerly interoperated to transfer a file that > specification is fundamentally broken. It's one thing to create useless > specifications -- but it's another thing to break fundamental aspects > of the Internet architecture. The most important task of any IETF WG > is > to "do no harm". At the end of the discussion listed for issue 2 "TTL=255 on send, check on receive?", the following suggests that the working group did not seem concerned with the issue of breaking things by using TTL 255. "[BA] - At IETF 56, the discussion seemed to indicate that sending with TTL=255 and checking on receipt would "do no harm" so that it was ok. The major issues encountered in Zeroconf WG with IPv4LL don't seem to apply here, since there are no legacy LLMNR implementations out there that set TTL to something other than 255, so we have a clean slate. Also, even if the IPv4LL draft doesn't specify setting or checking of TTL, an application can still do so. So I'd like to recommend that we keep the existing -14 text that mandates setting TTL=255 and checking it." I'm going to assume [BA] is short for Bernard Aboba. I can find no argument on the issues page that TTL 255 would do harm. The first mention of using a TTL of 1 is in Issue 33: PTR via Unicast. That suggestion was that PTR queries be sent unicast and a TTL of 1 be used. Issue 34 "Unicast Query Transport Issues" suggests sending unicast queries using TCP and setting the TTL to 1. This isn't recommended because TTL 255 breaks anything, it is recommended in an attempt to make the responses more difficult to spoof. The question of using some special domain such as ".local" surfaced a number of times. Use of a special domain such as dot-local would address many of the issues I brought up in my last email. The dot-local solution was always shot down with the response "use unqualified names". See issue #1. During the last call, Issue 45 was brought up, "Handling of Unqualified Names". The resolution was the removal of all references to unqualified names. The end result is no solution to Issue #1. A side effect of this is that Apple chose to use the top level domain 'local', being unable to get input other than "don't do that" from the working group. Instead of picking a domain that was likely to be unused and getting blessing so that everyone could coordinate and avoid using that domain, we picked a domain that was mostly unused and ran in to a few problems with sites that were using local as an internal domain. My impression is that the IETF exists to solve problems like that, not by ignoring them but by working through them. The resolution to each of the LLMNR issues on their own may have made sense when only that issue was examined. The combination of the resolutions to each of these issues is a document that, while technically correct, has lost it's purpose. I'm not sure what is to be done at this point. As one can see by reading the issues page , the working group has spun on many of these issues a number of times. I do know that the draft, as it stands, is not useful. > Similar considerations arose in the design of the LLMNR protocol. In > order to "do no harm" it was necessary to avoid adding new saddlebags > to > an old hourse -- such as trying to use DNS as a global service > discovery > mechanism, as DNS-SD does. It's one thing to ship something like this > on a > small proportion of Internet hosts -- but it's another thing entirely > to > attempt deploy something like that on a global scale. Making major > modifications to protocols that form the fundamental underpinings of > the > Internet (such as DNS and BGP) is not just another "bad idea" -- it has > the potential to cause major problems with the Internet architecture. > > The DNSEXT WG wisely decided that going down this road was > inappropriate. > It also decided that to avoid the potential for multicast storms it was > necessary to restrict use of mDNS to link-scope. Furthermore, it was > critical to enforce port and cache separation so that LLMNR could not > be > used to pollute the DNS cache and vice versa. I never made any mention of DNS-SD. I never suggested that we use multicast beyond the local link for mDNS. I'm not sure where the discussion about separation of caches came in to play. mDNS does a better job of keeping things separate. mDNS does not resolve any query unless the name ends in dot-local. An mDNS answer will not overwrite any DNS entry unless that DNS entry ends in dot-local. > To "do no harm" LLMNR needs to guarantee that it will come up with the > same answer to a query as DNS would if the RRs are available, so that > in > normal use the results of a gethostbyname() call do not depend on which > mechanism is used. To avoid leaking IPv4 Link-Local addresses beyond > their scope, it is necessary for LLMNR to only return addresses and > names valid on the interface on which the query was received and also > to preferrentially return routable addresses when they are available. > As the issues list shows, each of these issues resulted in changes > being > made to the LLMNR specification that caused it to diverge from the > early > mDNS specifications, but each change was carefully considered and > thought through. I'm not sure I follow. You say that it must "come up with the same answer to a query as DNS would". You also mention issues of leaking link-local addresses beyond their scope. Link-local addresses are not supposed to be in DNS records. In the case where LLMNR is used, it does make sense to respond with link-local addresses that are relevant on that network. That's precisely what mDNS does. mDNS doesn't pretend to attempt to give the same answers DNS would. > While LLMNR has been a journey of a thousand steps, it is far from a > random walk. > > While many of these decisions made LLMNR somewhat less 'useful' -- at > the > same time, they also made major problems less likely. The Internet > is no > longer an experiment today -- it's mission-critical infrastructure that > millions of people rely on every day. That implies a higher level of > due > diligence. Reading again through the list of issues and the resolutions, I don't see due diligence. I do see a pattern. The working group constantly goes back and forth on a number of issues, never really settling on one solution for very long. It seems more like the spec is what it is because it ended up in last call when it did. If we had gone on for another month or stopped a month earlier, who's to say it wouldn't be drastically different? I don't know how to solve this problem. The same arguments will probably continue to play out. We could publish LLMNR as it is, and it would be largely useless. We could attempt to address some of the issues, but we might just get stuck spinning again. How do we solve this? -josh --Apple-Mail-2-454067525 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAwqwATANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDMwOTA1MTgyNzUwWhcNMDQwOTA0MTgyNzUwWjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRqZ3JhZXNzbGV5QGFwcGxl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM7EXVgIo1XLZWghTrlD+Lyvh01y IH3rl7Q5SYYMwX2EQytFr3XZeubyuBy5kV3IjrDiI2R2siVX+pLCDsy7sWccyqCkqusGFRyiDyRI xb6ydueBxrAz26AfavFWmAZp+mdPt4qbXmlhoIwbb5UsqxfgO1mpFMB6Xh/FpS0ZkLMkrsYB0KFN 1STxdwNpZnlVNS7B/MlmaevcC59VzmPn6m2Ud7RTVqxYE49AYqnNDo9f/byj+RwKGjFpD+mjut8I kOpL2J0VM8KcCw9RZS3mZSTIyLYxVEgqLlrcyxo5Bwv0hde+CCYN2ZprMz3D9vymHmpGyhaJsnRe o5oNETuX2nUCAwEAAaMxMC8wHwYDVR0RBBgwFoEUamdyYWVzc2xleUBhcHBsZS5jb20wDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBVU7HfJ6R7f/4YqQ8iEa9pqZX9A9j2MU67D43nWolj XRdeQGxCkCWOrJLG7UgtiUvas7B9mZhRYYj0KrI3xkSX+N3G/IXDHo6OLH2rJY/43PRMj8CbWkP3 rPLTBZg2guU7a2wkgRig1heEaUBinl9h5TxfDosmHXKtiWVUFuVTXDCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDCrABMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTAyMjA3MzQ1N1owIwYJKoZIhvcNAQkEMRYEFHkx StOyxJLloVYXwXfoy3+nn3cyMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMKsAEwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDCrABMA0GCSqGSIb3DQEBAQUABIIBAAzd X5yjS2116141pbyf03sYIb4IkbMQM/0KzozAwxx61XVLO82fkJuyhj1pAXLDB9rVDTcoYZIulQcn Tmq6o2mmWu/xgTtMLioIflMlil2hJ4zWNmGgunCBnV+G5f3/18A1b0LEpK+6kOaH3/G+5mpo08Sg AsXBw3iDI/mgPyMtdamu3XhrqQ5cUGB8wq8eBq2+TVqZ91XBp6eKuhgCVCiuUS/XIClbZeer6g7Z SyrZ8FALLnxW+3q6H5ze0nI0TySPGZlLPJI3ftl5EYWvntY5xXZ//fAIEmBg8KwvpxF88GufpKJ2 eLItLgXqWl/SbyWBJ3yk5e9rka/sjsADfGUAAAAAAAA= --Apple-Mail-2-454067525-- -- to unsubscribe send a message to namedroppers-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 Oct 22 12:57: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 MAA17640 for ; Wed, 22 Oct 2003 12:57:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACM2E-000AFq-7r for namedroppers-data@psg.com; Wed, 22 Oct 2003 16:40:34 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACM25-000AFO-GF for namedroppers@ops.ietf.org; Wed, 22 Oct 2003 16:40:25 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h9MG4B230705 for ; Wed, 22 Oct 2003 09:04:11 -0700 Date: Wed, 22 Oct 2003 09:04:11 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC Summary: LLMNR Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >At the end of the discussion listed for issue 2 "TTL=255 on send, check >on receive?", the following suggests that the working group did not seem >concerned with the issue of breaking things by using TTL 255. It's worth understanding the history here. The decision to set TTL=255 and check it on reception within mDNS was largely based on this same technique being use in early IPv4 Link-Local versions. However, doing this in IPv4 Link-Local breaks TCP/IP interoperabilty and so the ZEROCONF WG chose to overturn this. Since the only existing hosts setting TTL=255 and checking it in mDNS are also doing this within IPv4 Link-Local, those hosts are unable to communicate with the majority of existing TCP/IP hosts. It's not possible to achieve "backward compatibility" with an implementation that is not interoperable with TCP/IP. What use is it to be able to resolve the name of a host that will drop all packets sent to it because they don't have TTL=255? That's just a recipe for user frustration. If no real interoperability is achievable, then at least we need to ensure that the separate flavors of TCP/IP do not interfere with one another. That's why LLMNR operates on a separate port and multicast address than mDNS. >The question of using some special domain such as ".local" surfaced a >number of times. Use of a special domain such as dot-local would address >many of the issues I brought up in my last email. As detailed in Issue #22, this was extensively debated and no real benefits were found to using the ".local" domain. If two machines are trying to communicate, one named erik.sun.com and another named bernard.microsoft.com, then for names to be resolved it is necessary to add ".local" to the searchlist, so that a query for erik.sun.com.local can be made. But this just results in additional packets on the wire for no real benefit. >The resolution to each of the LLMNR issues on their own may have made >sense when only that issue was examined. The combination of the >resolutions to each of these issues is a document that, while technically >correct, has lost it's purpose. The "purpose" that you're referring to is service discovery, not name resolution. LLMNR focusses only on name resolution -- but since there was never IETF consensus on use of mDNS for service discovery, it's hard to argue that this purpose was "lost". LLMNR *does* solve the link-scope name resolution problem. >I'm not sure what is to be done at this point. As one can see by reading >the issues page , >the working group has spun on many of these issues a number of times. It's true that there has been a lot of debate and reversal of positions. I attribute this to a lack of an appreciation of the difficulties involved in touching fundamental aspects of the Internet architecture -- IPv4 and name resolution. That kind of tinkering simply cannot proceed except with extreme caution. The early versions of the IPv4 Link-Local and mDNS specifications did not exhibit the required due diligence. I fear we will be dealing with the damage they created for years to come. >In the case where LLMNR is used, it does make sense to >respond with link-local addresses that are relevant on that network. Sure, but not in preference to routable addresses if available. In order to "do no harm" it is necessary for two hosts with routable addresses to be able to continue to interoperate with TCP/IP, even if they differ in their implementation of IPv4 Link-Local. For that to work, routable addresses need to be preferred. >That's precisely what mDNS does. mDNS doesn't pretend to attempt to give >the same answers DNS would. This causes breakage where the IPv4 Link-Local implementations are not interoperable (as they are not today). > If we had gone on for another month or stopped a month earlier, who's to > say it wouldn't be drastically different? Both the IPv4 Link-Local and LLMNR specifications have changed a lot in the last year, but they have changed consistently as the result of a better understanding of the problems caused by the early IPv4 LL and mDNS specifications. The consistent justification for the changes has been a concern for maintaining basic TCP/IP interoperability, which is the foundation of the Internet as we know it. >We could attempt to address some of the issues, but we >might just get stuck spinning again. How do we solve this? If there were interest in a genuine solution, it would start by giving up on the TTL=255 check in IPv4 Link-Local implementations, and preferring routable addresses where available. If that were done, at least basic TCP/IP interoperability could be maintained. -- to unsubscribe send a message to namedroppers-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 Oct 22 17:06: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 RAA28198 for ; Wed, 22 Oct 2003 17:06:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACQ3e-0006AB-61 for namedroppers-data@psg.com; Wed, 22 Oct 2003 20:58:18 +0000 Received: from [17.254.13.22] (helo=mail-out3.apple.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACQ3V-00069W-KD for namedroppers@ops.ietf.org; Wed, 22 Oct 2003 20:58:09 +0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.10/8.12.9) with ESMTP id h9MKw7Ti027086 for ; Wed, 22 Oct 2003 13:58:07 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 22 Oct 2003 13:57:32 -0700 Received: from [17.202.40.111] (graejo.apple.com [17.202.40.111]) by scv1.apple.com (8.12.9/8.12.9) with ESMTP id h9MKvaww017133; Wed, 22 Oct 2003 13:57:36 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v606) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-9-502252740; protocol="application/pkcs7-signature" Message-Id: <6CD0632A-04D2-11D8-AD19-000A95B9474C@apple.com> Cc: namedroppers@ops.ietf.org From: Joshua Graessley Subject: Re: DNSEXT WGLC Summary: LLMNR Date: Wed, 22 Oct 2003 13:58:02 -0700 To: Bernard Aboba X-Mailer: Apple Mail (2.606) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --Apple-Mail-9-502252740 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Oct 22, 2003, at 9:04 AM, Bernard Aboba wrote: >> At the end of the discussion listed for issue 2 "TTL=255 on send, >> check >> on receive?", the following suggests that the working group did not >> seem >> concerned with the issue of breaking things by using TTL 255. > > It's worth understanding the history here. The decision to set TTL=255 > and check it on reception within mDNS was largely based on this same > technique being use in early IPv4 Link-Local versions. However, doing > this in IPv4 Link-Local breaks TCP/IP interoperabilty and so the > ZEROCONF > WG chose to overturn this. Since the only existing hosts setting > TTL=255 > and checking it in mDNS are also doing this within IPv4 Link-Local, > those > hosts are unable to communicate with the majority of existing TCP/IP > hosts. Part of that history is that the IPv4LL working group got this idea from IPv6 Neighbor Discovery. IPv6 Neighbor Discovery uses TTL 255. It is not encumbered with the need to interoperate with legacy clients. You said: "At IETF 56, the discussion seemed to indicate that sending with TTL=255 and checking on receipt would "do no harm" so that it was ok. The major issues encountered in Zeroconf WG with IPv4LL don't seem to apply here, since there are no legacy LLMNR implementations out there that set TTL to something other than 255, so we have a clean slate." Mac OS X is not the only thing shipping with mDNS support. In addition, there is no problem with communicating with other hosts using TCP/IP whether or not an IPv4LL address is used. The check is not actually performed for IPv4LL traffic. I'm not sure why you keep bringing up IPv4LL. > It's not possible to achieve "backward compatibility" with an > implementation that is not interoperable with TCP/IP. What use is it > to > be able to resolve the name of a host that will drop all packets sent > to it because they don't have TTL=255? That's just a recipe for user > frustration. If no real interoperability is achievable, then at least > we > need to ensure that the separate flavors of TCP/IP do not interfere > with one another. That's why LLMNR operates on a separate port and > multicast address than mDNS. The interoperability problem lies in implementations of IPv4LL that check for TTL 255. This has nothing to do with LLMNR or mDNS. LLMNR and mDNS can be used wether the hosts have IPv4LL addresses or any other address (IPv4 or IPv6). >> The question of using some special domain such as ".local" surfaced a >> number of times. Use of a special domain such as dot-local would >> address >> many of the issues I brought up in my last email. > > As detailed in Issue #22, this was extensively debated and no real > benefits were found to using the ".local" domain. If two machines are > trying to communicate, one named erik.sun.com and another named > bernard.microsoft.com, then for names to be resolved it is > necessary to add ".local" to the searchlist, so that a query for > erik.sun.com.local can be made. But this just results in additional > packets on the wire for no real benefit. You have hosts with names like erik.sun.com and bernard.microsoft.com, therefore, you see no benefit. If someone has a host with a private address, a very common scenario in homes and small offices thanks to the evils of NAT, their host has no name. They can't use LLMNR. Originally, it was proposed that people use unqualified names. As noted in Issue 45, there is no such thing as an unqualified name, so resolving unqualified names using LLMNR made no sense and was stripped out of the document. This is my major gripe with this document as it stands. My first email didn't even mention the TTL issue. >> The resolution to each of the LLMNR issues on their own may have made >> sense when only that issue was examined. The combination of the >> resolutions to each of these issues is a document that, while >> technically >> correct, has lost it's purpose. > > The "purpose" that you're referring to is service discovery, not name > resolution. LLMNR focusses only on name resolution -- but since there > was > never IETF consensus on use of mDNS for service discovery, it's hard to > argue that this purpose was "lost". LLMNR *does* solve the link-scope > name resolution problem. When have I mentioned service discovery. None of the three examples I listed in the first email were related to service discovery. Masataka Ohta pointed out a solution to one of the three scenarios in his response. The other two have no solution with LLMNR. LLMNR doesn't solve name resolution in ad-hoc networks because there is no way that a host can know what name to use. LLMNR also fails in situations such as home networks were private addresses are used with a NAT. It would be convenient to use name resolution to look up the name of other hosts on the private network. There is no suggestion on what sorts of names a host on these networks should use to avoid conflicting with names in DNS. >> I'm not sure what is to be done at this point. As one can see by >> reading >> the issues page >> , >> the working group has spun on many of these issues a number of times. > > It's true that there has been a lot of debate and reversal of > positions. I > attribute this to a lack of an appreciation of the difficulties > involved > in touching fundamental aspects of the Internet architecture -- IPv4 > and > name resolution. That kind of tinkering simply cannot proceed except > with > extreme caution. The early versions of the IPv4 Link-Local and mDNS > specifications did not exhibit the required due diligence. I fear we > will > be dealing with the damage they created for years to come. I don't know why you keep going back to IPv4LL, that is irrelevant to LLMNR, except with respect to how such addresses should be handled when responding to an LLMNR query. >> In the case where LLMNR is used, it does make sense to >> respond with link-local addresses that are relevant on that network. > > Sure, but not in preference to routable addresses if available. In > order > to "do no harm" it is necessary for two hosts with routable addresses > to > be able to continue to interoperate with TCP/IP, even if they differ in > their implementation of IPv4 Link-Local. For that to work, routable > addresses need to be preferred. I'm in complete agreement. I don't really know what this has to do with the usefulness of LLMNR or how it compares to mDNS. >> That's precisely what mDNS does. mDNS doesn't pretend to attempt to >> give >> the same answers DNS would. > > This causes breakage where the IPv4 Link-Local implementations are not > interoperable (as they are not today). > >> If we had gone on for another month or stopped a month earlier, who's >> to >> say it wouldn't be drastically different? > > Both the IPv4 Link-Local and LLMNR specifications have changed a lot in > the last year, but they have changed consistently as the result of a > better understanding of the problems caused by the early IPv4 LL and > mDNS > specifications. The consistent justification for the changes has been > a > concern for maintaining basic TCP/IP interoperability, which is the > foundation of the Internet as we know it. LLMNR has nothing to do with TCP/IP interoperability. I don't know why you keep confusing the two issues. These are two separate issues. IPv4LL has nothing to do with this discussion. >> We could attempt to address some of the issues, but we >> might just get stuck spinning again. How do we solve this? > > If there were interest in a genuine solution, it would start by giving > up > on the TTL=255 check in IPv4 Link-Local implementations, and preferring > routable addresses where available. If that were done, at least basic > TCP/IP interoperability could be maintained. Isn't this an issue for the zeroconf working group to tackle with the IPv4LL draft? -josh --Apple-Mail-9-502252740 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAwqwATANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDMwOTA1MTgyNzUwWhcNMDQwOTA0MTgyNzUwWjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRqZ3JhZXNzbGV5QGFwcGxl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM7EXVgIo1XLZWghTrlD+Lyvh01y IH3rl7Q5SYYMwX2EQytFr3XZeubyuBy5kV3IjrDiI2R2siVX+pLCDsy7sWccyqCkqusGFRyiDyRI xb6ydueBxrAz26AfavFWmAZp+mdPt4qbXmlhoIwbb5UsqxfgO1mpFMB6Xh/FpS0ZkLMkrsYB0KFN 1STxdwNpZnlVNS7B/MlmaevcC59VzmPn6m2Ud7RTVqxYE49AYqnNDo9f/byj+RwKGjFpD+mjut8I kOpL2J0VM8KcCw9RZS3mZSTIyLYxVEgqLlrcyxo5Bwv0hde+CCYN2ZprMz3D9vymHmpGyhaJsnRe o5oNETuX2nUCAwEAAaMxMC8wHwYDVR0RBBgwFoEUamdyYWVzc2xleUBhcHBsZS5jb20wDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBVU7HfJ6R7f/4YqQ8iEa9pqZX9A9j2MU67D43nWolj XRdeQGxCkCWOrJLG7UgtiUvas7B9mZhRYYj0KrI3xkSX+N3G/IXDHo6OLH2rJY/43PRMj8CbWkP3 rPLTBZg2guU7a2wkgRig1heEaUBinl9h5TxfDosmHXKtiWVUFuVTXDCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDCrABMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTAyMjIwNTgwMlowIwYJKoZIhvcNAQkEMRYEFNXV onSChE7rycxYK433osZS40saMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMKsAEwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDCrABMA0GCSqGSIb3DQEBAQUABIIBAEdQ uNsN0t+Ml0kee/xrh6b+5mfSCIa0OSXXk+uDYJGtkaeYYMLutLqBYoudfrp3UCjyCvaZD+TN2iXy sy3foovy0vY2Rl9YflLKd6B/3uATEan7lvgSae9ggB+2wWY2qBXA0xTXImGTgxcLgp6ulkx8lwq5 J7kzP4ROojdiLV4BGl+iPRNYIam3pkggQLYulMBj3JWa8jzPQTdk1lyaiZOVFWVoBXWkFk7onT1D y7J412NtZtFwZmxMmNLk/Rv9kNncaA0cQ5Zq7WldxHWqAw7txaKlKrmpu2KGv9LPpNRivYXL6/1P uWyenn32afpoCNZhDk3LH0/zaUQfixxBHYAAAAAAAAA= --Apple-Mail-9-502252740-- -- to unsubscribe send a message to namedroppers-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 Oct 22 18:49: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 SAA03161 for ; Wed, 22 Oct 2003 18:49:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACRfl-000DG4-8A for namedroppers-data@psg.com; Wed, 22 Oct 2003 22:41:45 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1ACRfd-000DD7-Ud for namedroppers@ops.ietf.org; Wed, 22 Oct 2003 22:41:38 +0000 Received: (qmail 74305 invoked from network); 22 Oct 2003 22:42:48 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 22 Oct 2003 22:42:48 -0000 Message-ID: <3F9707E4.7020104@necom830.hpcl.titech.ac.jp> Date: Thu, 23 Oct 2003 07:42:44 +0900 From: masataka ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Joshua Graessley CC: Bernard Aboba , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC Summary: LLMNR References: <6CD0632A-04D2-11D8-AD19-000A95B9474C@apple.com> In-Reply-To: <6CD0632A-04D2-11D8-AD19-000A95B9474C@apple.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Joshua; > When have I mentioned service discovery. None of the three examples I > listed in the first email were related to service discovery. Masataka > Ohta pointed out a solution to one of the three scenarios in his > response. The other two have no solution with LLMNR. LLMNR doesn't solve > name resolution in ad-hoc networks because there is no way that a host > can know what name to use. What's wrong with a globally unique domain name configured at factory? > LLMNR also fails in situations such as home > networks were private addresses are used with a NAT. It would be > convenient to use name resolution to look up the name of other hosts on > the private network. Can I assume that the only DHCP and the only DNS servers of the home network is collocated on the NAT box? Then, a host can tell its domain name to the box through DHCP and the DNS server of the box can synthesis appropriate mapping. That is, we don't need multicast. 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 Wed Oct 22 19:02: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 TAA03885 for ; Wed, 22 Oct 2003 19:02:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACRuA-000ElI-P4 for namedroppers-data@psg.com; Wed, 22 Oct 2003 22:56:38 +0000 Received: from [17.254.13.22] (helo=mail-out3.apple.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACRu3-000EkR-1u for namedroppers@ops.ietf.org; Wed, 22 Oct 2003 22:56:31 +0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.10/8.12.9) with ESMTP id h9MMuUTi019995 for ; Wed, 22 Oct 2003 15:56:30 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 22 Oct 2003 15:55:59 -0700 Received: from [17.202.40.111] (graejo.apple.com [17.202.40.111]) by scv2.apple.com (8.12.9/8.12.9) with ESMTP id h9MMuEEV009598; Wed, 22 Oct 2003 15:56:14 -0700 (PDT) In-Reply-To: <3F9707E4.7020104@necom830.hpcl.titech.ac.jp> References: <6CD0632A-04D2-11D8-AD19-000A95B9474C@apple.com> <3F9707E4.7020104@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3-509359977; protocol="application/pkcs7-signature" Message-Id: Cc: Bernard Aboba , namedroppers@ops.ietf.org From: Joshua Graessley Subject: Re: DNSEXT WGLC Summary: LLMNR Date: Wed, 22 Oct 2003 15:56:29 -0700 To: masataka ohta X-Mailer: Apple Mail (2.606) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --Apple-Mail-3-509359977 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Oct 22, 2003, at 3:42 PM, masataka ohta wrote: > Joshua; > >> When have I mentioned service discovery. None of the three examples I >> listed in the first email were related to service discovery. Masataka >> Ohta pointed out a solution to one of the three scenarios in his >> response. The other two have no solution with LLMNR. LLMNR doesn't >> solve name resolution in ad-hoc networks because there is no way that >> a host can know what name to use. > > What's wrong with a globally unique domain name configured at > factory? I think the point of having a name is that it's easier to remember than an address. This is especially important when using IPv6LL addresses in an ad-hoc environment. Having to remember the name pbg4-b9-47-4c.names.apple.com would not be very useful. Being able to use a name like "joshs-powerbook" or "joshs-powerbook.llmnr." would make life simpler. Of course, this relies on good conflict detection, but a lot of that was stripped out of the document, assuming more that those who control the DNS name space will be responsible for handing out the names that are used with LLMNR. >> LLMNR also fails in situations such as home networks were private >> addresses are used with a NAT. It would be convenient to use name >> resolution to look up the name of other hosts on the private network. > > Can I assume that the only DHCP and the only DNS servers of the > home network is collocated on the NAT box? > > Then, a host can tell its domain name to the box through DHCP > and the DNS server of the box can synthesis appropriate mapping. > > That is, we don't need multicast. There are no NAT boxes, to the best of my knowledge, that do this today. If an implementation of LLMNR existed, and it was made to be useful in these scenarios, one could simply install LLMNR on the devices on the network without having to upgrade the NAT box. Even if NAT boxes did this, what domain name would the host tell the box it has? -josh --Apple-Mail-3-509359977 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAwqwATANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDMwOTA1MTgyNzUwWhcNMDQwOTA0MTgyNzUwWjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRqZ3JhZXNzbGV5QGFwcGxl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM7EXVgIo1XLZWghTrlD+Lyvh01y IH3rl7Q5SYYMwX2EQytFr3XZeubyuBy5kV3IjrDiI2R2siVX+pLCDsy7sWccyqCkqusGFRyiDyRI xb6ydueBxrAz26AfavFWmAZp+mdPt4qbXmlhoIwbb5UsqxfgO1mpFMB6Xh/FpS0ZkLMkrsYB0KFN 1STxdwNpZnlVNS7B/MlmaevcC59VzmPn6m2Ud7RTVqxYE49AYqnNDo9f/byj+RwKGjFpD+mjut8I kOpL2J0VM8KcCw9RZS3mZSTIyLYxVEgqLlrcyxo5Bwv0hde+CCYN2ZprMz3D9vymHmpGyhaJsnRe o5oNETuX2nUCAwEAAaMxMC8wHwYDVR0RBBgwFoEUamdyYWVzc2xleUBhcHBsZS5jb20wDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBVU7HfJ6R7f/4YqQ8iEa9pqZX9A9j2MU67D43nWolj XRdeQGxCkCWOrJLG7UgtiUvas7B9mZhRYYj0KrI3xkSX+N3G/IXDHo6OLH2rJY/43PRMj8CbWkP3 rPLTBZg2guU7a2wkgRig1heEaUBinl9h5TxfDosmHXKtiWVUFuVTXDCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDCrABMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTAyMjIyNTYyOVowIwYJKoZIhvcNAQkEMRYEFCiH 3gmXjL+88lRcQrk41Pbam8E6MHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMKsAEwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDCrABMA0GCSqGSIb3DQEBAQUABIIBAA7d HligrSjP+iC+3WpIu+Z7rpn6LQIXOJ5Qd+XCjSjx7pXrF7JJrn3zJ3T7LphRKOA1vDJGhkGCA215 cxjm9qIhnQd0KlOqzCotQ51ju7XmQf06EnvtXIU4uF0FAwzNDApcyKXB2ID3lWY0sH7NB8ufcd5k McsMsUj2+vslebO/qyXmcH2nOGXGKSJr699fwgRf4CPZsIJRyZbvJ20EK9WMxqBVWebnk5yB+V6J g9F48I8DlY9IjczSkZl65XUEP+k6sDFKnISMeELPBYq4MXI5JtJxAvNPdozkVrKhZ5b1ceLL7Zqx Vv9P4APq6lXH8gAF9nC8Uf1TXcfZSDhMd74AAAAAAAA= --Apple-Mail-3-509359977-- -- to unsubscribe send a message to namedroppers-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 Oct 22 23:41: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 XAA16987 for ; Wed, 22 Oct 2003 23:41:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACWEj-000651-0G for namedroppers-data@psg.com; Thu, 23 Oct 2003 03:34:09 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACWEd-00064i-Fb for namedroppers@ops.ietf.org; Thu, 23 Oct 2003 03:34:03 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h9N2vkr03700 for ; Wed, 22 Oct 2003 19:57:46 -0700 Date: Wed, 22 Oct 2003 19:57:46 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC Summary: LLMNR Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >You have hosts with names like erik.sun.com and bernard.microsoft.com, >therefore, you see no benefit. If someone has a host with a private >address, a very common scenario in homes and small offices thanks to the >evils of NAT, their host has no name. Why does their host not have a name? The hostname need not be dependent on the address. > They can't use LLMNR. Sure they can. LLMNR doesn't care what the host's IP address is. > LLMNR doesn't provide a way to name a host. Why does a name resolution protocol need to take care of selection of host names? In many cases today the hostname is selected by the OEM and ships with the PC or device. > Originally, it was proposed that people use unqualified names. In -24 LLMNR can be used to query any RR for any name. So there's no need to care about the definition of an "unqualified name". >The interoperability problem lies in implementations of IPv4LL that check >for TTL 255. This has nothing to do with LLMNR or mDNS. It does, because it has been suggested that if LLMNR were to adopt set TTL=255, check on reception, then interoperability would result. On August 30, 2003 the DNSEXT WG Co-Chair Olaf Kolkman asked for a list of *all* the changes that would be required beyond just the TTL change: http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01628.html To this day there has been no response to this question. I believe it is accurate to say that just making the TTL change would not generate any useful interoperability scenarios, because an LLMNR responder still would not respond to a query for a ".local" name. Even if it were to do that (for backward compatibility sake), we *still* wouldn't have interoperability if the LLMNR host also didn't implement DNS-SD. And even if it did that, we wouldn't have interoperability where IPv4 Link-Local addresses were used unless the LLMNR host also set TTL=255 on send. Given this, it's hard for me to conclude that the requested TTL change has any purpose beyond producing "PowerPoint interoperability" -- the ability to claim conformance without real interoperability. If this is wrong, please enlighten us with the details of what changes are needed in order to achieve some useful level of interoperability. -- to unsubscribe send a message to namedroppers-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 Oct 22 23:56:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17452 for ; Wed, 22 Oct 2003 23:56:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACWWs-0007e8-UK for namedroppers-data@psg.com; Thu, 23 Oct 2003 03:52:54 +0000 Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACWWm-0007d9-0e for namedroppers@ops.ietf.org; Thu, 23 Oct 2003 03:52:48 +0000 Received: from nominum.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 744471B207E; Wed, 22 Oct 2003 22:48:54 -0500 (CDT) Date: Wed, 22 Oct 2003 22:52:52 -0500 Subject: Re: DNSEXT WGLC Summary: LLMNR Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: namedroppers@ops.ietf.org To: Bernard Aboba From: Ted Lemon In-Reply-To: Message-Id: <6075D14A-050C-11D8-931D-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, October 22, 2003, at 09:57 PM, Bernard Aboba wrote: > Why does their host not have a name? The hostname need not be > dependent on > the address. My computer's name right now is "mdzadpa". When I got it, it didn't have a name. It chose a name when I customized it - the name it chose was "Ted Lemon's Computer". This is very like what Microsoft's own software does, although I think it would have chosen the name "TEDLEMON". Now, how does my computer go from here to having a fully-qualified name? I bought it to use at home. It doesn't belong to my employer. It's not "mdzadpa.nominum.com." It doesn't belong to my ISP. It's not "mdzadpa.speakeasy.net." For the average user, this is not going to change. It really doesn't make sense for the computer to identify itself as either of the two fully-qualified names I just suggested, and, indeed, my ISP wouldn't let me identify my computer that way. So for my computer to go around claiming to be "mdzadpa.speakeasy.net." would be incorrect behavior. That is not its name. This is true whether my computer is a Mac or a PC. Unix machines, maybe less true. Linux, I don't know. Cell phones, all bets are off. But for the vast majority of the computers that are presently connected to the network and that could benefit from LLMNR, there is no correct FQDN to assign them. So if you don't have a rule for producing an FQDN based on the unqualified name the user chose, that computer simply is not going to be able to identify itself using LLMNR. This means that LLMNR is effectively useless for the vast majority of all computers on which it's ever likely to be implemented, unless the LLMNR implementation does something extra-protocular to generate an FQDN. Perhaps the right thing is to specify the protocol by which this name is derived separately, but if so, we should say that that's the answer, not pretend that the problem need not be solved. -- to unsubscribe send a message to namedroppers-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 Oct 23 00:43: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 AAA19051 for ; Thu, 23 Oct 2003 00:43:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACXF5-000B3A-98 for namedroppers-data@psg.com; Thu, 23 Oct 2003 04:38:35 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACXEx-000B2c-Fh for namedroppers@ops.ietf.org; Thu, 23 Oct 2003 04:38:27 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h9N429V07552; Wed, 22 Oct 2003 21:02:09 -0700 Date: Wed, 22 Oct 2003 21:02:09 -0700 (PDT) From: Bernard Aboba To: Ted Lemon cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC Summary: LLMNR In-Reply-To: <6075D14A-050C-11D8-931D-000A95D9C74C@nominum.com> Message-ID: References: <6075D14A-050C-11D8-931D-000A95D9C74C@nominum.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > that computer simply is not going to be able to identify itself using > LLMNR. I'm not sure how you conclude this. LLMNR doesn't care whether the name is an FQDN or not. If you type "ping tedlemon" then the host will send an LLMNR query for "tedlemon". If you type "ping tedlemon.nominum.com" then if the configured DNS server doesn't answer the query or responds with "no such name" then an LLMNR query will be sent for "tedlemon.nominum.com" > implementation does something extra-protocular to generate an FQDN. Nope. LLMNR can send a query for any name. > Perhaps the right thing is to specify the protocol by which this name > is derived separately, but if so, we should say that that's the answer, All LLMNR needs to work is for a responder to have a name, any name. If it hears a query for that name, it will respond. -- to unsubscribe send a message to namedroppers-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 Oct 23 06:49: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 GAA12481 for ; Thu, 23 Oct 2003 06:49:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACcq8-000AhA-Sc for namedroppers-data@psg.com; Thu, 23 Oct 2003 10:37:12 +0000 Received: from [62.78.147.60] (helo=hades.pp.htv.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACcpz-000AgP-JR for namedroppers@ops.ietf.org; Thu, 23 Oct 2003 10:37:03 +0000 Received: from hades.pp.htv.fi (liljeber@localhost [127.0.0.1]) by hades.pp.htv.fi (8.12.10/8.12.10/Debian-4) with ESMTP id h9NAbBCu003861; Thu, 23 Oct 2003 13:37:11 +0300 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.10/8.12.10/Debian-4) id h9NAb9KW003860; Thu, 23 Oct 2003 13:37:09 +0300 Subject: Re: DNSEXT WGLC Summary: LLMNR From: Mika Liljeberg To: Bernard Aboba Cc: Ted Lemon , namedroppers@ops.ietf.org In-Reply-To: References: <6075D14A-050C-11D8-931D-000A95D9C74C@nominum.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1066905429.798.88.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 23 Oct 2003 13:37:09 +0300 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-2.3 required=5.0 tests=BAYES_00,RCVD_IN_DYNABLOCK autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I have to say that, to some extent, I share Joshua's concern with regard to naming devices in an ad-hoc fashion. While it is true that LLMNR can be used to query any name, the implicit assumption seems to be that the naming must be consistent with DNS. In ad-hoc scenarios users need to be able to nickname their devices with something that is easy to type and remember (and fits on a single line on a cell phone display, for instance). Users like simple names such as "phone", "headset", "pc", or "vcr". It's not acceptable to have something like "mdzadpa". Who can remember that? In case of conflict, I might want to use a longer name like "phone.mika". So instead of having a single nickname my device might have multiple nicknames. How could I resolve the inevitable conflict using LLMNR? In real life users deal with naming conflicts all the time and think nothing of it. People sometimes have the same first names, so we qualify what we mean by adding a surname or narrow the context in some other manner. Suppose Ted's phone also has names like "phone" and "phone.ted". My query for "phone" returns IP addresses for both my phone and Ted's phone. Since I got responses from more than one device a conflict has occurred. My application might try to resolve this by doing a reverse query for both IP addresses and receive the names "phone.mika" and "phone.ted" (or it might use some other protocol to get a better description of each device), which in turn would be presented to me in a selection dialog. I would then be able to qualify which one I meant by selecting one of the presented choises. There are various ways to implement the above but it seems clear to me that we can't do something like this in a manner that will satisfy the users if the naming is required to be consistent with DNS. Being able to pick any name you want is important. That being the case, I can see a need for a reserved TLD name for ad-hoc use, guaranteed never to appear in the global DNS. That doesn't mean LLMNR should not respond to queries for its DNS names as well. It just means that the names picked by the users themselves would be placed in a separate name space. MikaL On Thu, 2003-10-23 at 07:02, Bernard Aboba wrote: > > that computer simply is not going to be able to identify itself using > > LLMNR. > > I'm not sure how you conclude this. LLMNR doesn't care whether the > name is an FQDN or not. If you type "ping tedlemon" then the host will > send an LLMNR query for "tedlemon". If you type "ping > tedlemon.nominum.com" then if the configured DNS server doesn't answer the > query or responds with "no such name" then an LLMNR query will be sent for > "tedlemon.nominum.com" > > > implementation does something extra-protocular to generate an FQDN. > > Nope. LLMNR can send a query for any name. > > > Perhaps the right thing is to specify the protocol by which this name > > is derived separately, but if so, we should say that that's the answer, > > All LLMNR needs to work is for a responder to have a name, any name. If it > hears a query for that name, it will respond. > > -- > to 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 Oct 23 10:06: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 KAA22627 for ; Thu, 23 Oct 2003 10:06:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACfz2-0001UJ-7V for namedroppers-data@psg.com; Thu, 23 Oct 2003 13:58:36 +0000 Received: from [207.65.203.98] (helo=goose.ehsco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACfyv-0001Tm-D9 for namedroppers@ops.ietf.org; Thu, 23 Oct 2003 13:58:29 +0000 Received: from [207.65.3.26] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 4.1.3) with ESMTP-TLS id 640069; Thu, 23 Oct 2003 12:44:11 -0500 Message-ID: <3F97DE81.2060100@ehsco.com> Date: Thu, 23 Oct 2003 08:58:25 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Mika Liljeberg CC: Bernard Aboba , Ted Lemon , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC Summary: LLMNR References: <6075D14A-050C-11D8-931D-000A95D9C74C@nominum.com> <1066905429.798.88.camel@hades> In-Reply-To: <1066905429.798.88.camel@hades> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 10/23/2003 5:37 AM Mika Liljeberg wrote: > There are various ways to implement the above but it seems clear to me > that we can't do something like this in a manner that will satisfy the > users if the naming is required to be consistent with DNS. Well, since there are various ways to do it, there's no real restriction or requirement. An RR with an owner name of the device and textual data would provide friendly long names indexed to short (DNS) names. Having the systems include these RRs in the ~authority section of the question message would provide the advertisement and collision detection mechanisms. Due to the absence of an authoritative delegation hierarchy (this includes the absence of a .local, but also includes the absence of naming authority at the leaf-node), the short names must be kept separate from "real" DNS names anyway. -- 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 Oct 23 10:44: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 KAA26725 for ; Thu, 23 Oct 2003 10:44:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACgd5-00054D-3y for namedroppers-data@psg.com; Thu, 23 Oct 2003 14:39:59 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACgcs-000537-Bl for namedroppers@ops.ietf.org; Thu, 23 Oct 2003 14:39:46 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h9NE3Q510288 for ; Thu, 23 Oct 2003 07:03:27 -0700 Date: Thu, 23 Oct 2003 07:03:26 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC Summary: LLMNR In-Reply-To: <3F97DE81.2060100@ehsco.com> Message-ID: References: <6075D14A-050C-11D8-931D-000A95D9C74C@nominum.com> <1066905429.798.88.camel@hades> <3F97DE81.2060100@ehsco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > There are various ways to implement the above but it seems clear to me > that we can't do something like this in a manner that will satisfy the > users if the naming is required to be consistent with DNS. There's no requirement that an LLMNR responder register its name in DNS; however, if it does, then it will also respond to LLMNR queries for the name it registers. An LLMNR responder can choose to respond to the name "joe" or "joe.example.com". In terms of *attributes* of the host, such as a "friendly description", an icon, a sound, etc. these are all orthogonal issues to name resolution. Service discovery protocols (including uPnP, SLPv2, etc.) are typically extensible and can provide this kind of richness. There is no need to overload DNS to handle this. If the desire is merely to discover services and present them on the desktop in a pleasing way, I'd argue that name resolution is not required. Send a service discovery query, collate the results (which can include a naming attribute, by the way) and display them. If anything, the problem is that we have too many protocols that can handle this. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Oct 23 11:44:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00920 for ; Thu, 23 Oct 2003 11:44:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AChUf-000AOH-Ei for namedroppers-data@psg.com; Thu, 23 Oct 2003 15:35:21 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AChUR-000ANL-Sg for namedroppers@ops.ietf.org; Thu, 23 Oct 2003 15:35:08 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 4CC224E2E8; Thu, 23 Oct 2003 17:35:07 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id E2DF84E683; Thu, 23 Oct 2003 17:35:05 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id h9NFZ5VZ011955; Thu, 23 Oct 2003 17:35:05 +0200 Date: Thu, 23 Oct 2003 17:35:05 +0200 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Cc: ogud@ogud.com Subject: Re: Any decision on wildcard CNAME ? Message-Id: <20031023173505.6ed2e4ba.olaf@ripe.net> In-Reply-To: <20031021133406.7a9bc890.olaf@ripe.net> References: <11723.1065903183@munnari.OZ.AU> <20031021133406.7a9bc890.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.6 (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.051619 X-RIPE-Signature: 1eb5d0b444963061ebd74dbaf1d402bc X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit namedroppers, I recently wrote: > Personally I have a preference for a small I-D, since there is > already consensus on the content it should be a trivial thing to get > through the WG. > > Any takers? > Putting money where my mouth is but missing the 'initial submission deadline' I have something ready to be published shortly after the IETF. If you want to read and comment upon it: http://www.ripe.net/DISI/Notes/draft-kolkman-wcard-cname-processing-00.html or alternatively http://www.ripe.net/DISI/Notes/draft-kolkman-wcard-cname-processing-00.txt -- 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 Oct 23 13:29: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 NAA08227 for ; Thu, 23 Oct 2003 13:29:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACj5Y-000KRf-P3 for namedroppers-data@psg.com; Thu, 23 Oct 2003 17:17:32 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACj5U-000KRC-39 for namedroppers@ops.ietf.org; Thu, 23 Oct 2003 17:17:28 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9NHHPQY011358 for ; Thu, 23 Oct 2003 10:17:26 -0700 (PDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.208]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADK29619; Thu, 23 Oct 2003 13:17:24 -0400 (EDT) Message-Id: <4.3.2.7.2.20031023123253.00ba3700@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 23 Oct 2003 13:17:22 -0400 To: namedroppers@ops.ietf.org From: Ralph Droms Subject: Re: DNSEXT WGLC Summary: LLMNR In-Reply-To: References: <3F97DE81.2060100@ehsco.com> <6075D14A-050C-11D8-931D-000A95D9C74C@nominum.com> <1066905429.798.88.camel@hades> <3F97DE81.2060100@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I've been reviewing draft-ietf-dnsext-mdns-24.txt, and I found that I don't think I would know how to implement LLMNR based on this document. In particular, the description of some terms like hostname, current domain, as well as the behavior of senders and responders regarding unqualified names, needs to be clarified. One problem I have is the ambiguity between current host implementations of these concepts and the way the terms are used in the document. I think it would be useful to give concrete, implementation-independent definitions of the following terms in the terminology section: hostname - in section 2.2, the third paragraph begins with the sentence: 'As an example, a computer "host.example.com." ...' I don't know what this means in an implementation; is this a configured character string or a one-component name with the current domain appended or ??? I suggest that something like "hostname" be defined and used throughout the document for clarity. current domain - in section 3.1, the first item in the implicit search order is "...the name with the current domain appended". What, exactly, is the "current domain"? Is it the domain search list? I don't think that term is defined in RFC 1536, which is given as a reference to the list. authoritative - this term seems to be used in a different way than in DNS, and is defined by example rather than by a sentence or phrase owned by - in the fifth paragraph of section 2.2, what are "RRSets owned by the host"? (other DNS terms) - it might be good to say something in section 1.2 to the effect of "Other terminology from DNS is defined in RFC 1034 or RFC 1035 (whichever is appropriate). In fact, it might be good to explicitly state that the reader should be familiar with the concepts from DNS in RFC 1034 and RFC 1035. Regarding unqualified names, I'm trying to relate the protocol described in draft-ietf-dnsext-mdns-24.txt to the scenario I imagine I would use at home, where I have a couple of computers using private addressing behind NAT, which are configured with a list of DNS recursive name servers through DHCP. Each computer is configured with an unqualified name, say "den" and "laptop" and does not have a domain search list. I'd like to be able to be able to enter, for example, http://den/some-random-page.html So, the target of this URL is configured with the unqualified name "den". The sender presumably first sends a request to the each of the DNS servers in the configured list of servers, and gets no response or a negative response. According to section 3.1, the sender skips step 1 (no current domain or domain search list configured) and sends a request for the name with the root domain appended: "den." If the target is configured with the unqualified name "den", does it also respond to requests for the name "den."? Or, does the hostname always have to be a FQDN, so that if the user enters "den" as the "computer name", the hostname is then "den."? By the way, I found the description (section 3, first para) of when to use LLMNR to be confusing. Could that description be rewritten as a list of conditions or steps to take? - Ralph -- to unsubscribe send a message to namedroppers-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 Oct 23 13:51: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 NAA09014 for ; Thu, 23 Oct 2003 13:51:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACjW7-000NGS-Eh for namedroppers-data@psg.com; Thu, 23 Oct 2003 17:44:59 +0000 Received: from [17.254.13.22] (helo=mail-out3.apple.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACjW2-000NFT-KX for namedroppers@ops.ietf.org; Thu, 23 Oct 2003 17:44:54 +0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.10/8.12.9) with ESMTP id h9NHisTi016047 for ; Thu, 23 Oct 2003 10:44: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 ; Thu, 23 Oct 2003 10:44:22 -0700 Received: from [17.219.195.145] ([17.219.195.145]) by scv2.apple.com (8.12.9/8.12.9) with ESMTP id h9NHibEV012764 for ; Thu, 23 Oct 2003 10:44:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v606) In-Reply-To: References: <6075D14A-050C-11D8-931D-000A95D9C74C@nominum.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-8-577062929; protocol="application/pkcs7-signature" Message-Id: <9B29635C-0580-11D8-B5ED-000A95B9474C@apple.com> From: Joshua Graessley Subject: Re: DNSEXT WGLC Summary: LLMNR Date: Thu, 23 Oct 2003 10:44:52 -0700 To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.606) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --Apple-Mail-8-577062929 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Oct 22, 2003, at 9:02 PM, Bernard Aboba wrote: >> that computer simply is not going to be able to identify itself using >> LLMNR. > > I'm not sure how you conclude this. LLMNR doesn't care whether the > name is an FQDN or not. If you type "ping tedlemon" then the host will > send an LLMNR query for "tedlemon". If you type "ping > tedlemon.nominum.com" then if the configured DNS server doesn't answer > the > query or responds with "no such name" then an LLMNR query will be sent > for > "tedlemon.nominum.com" This is only true if the computer performing the lookup doesn't have a list of search domains or there is no tedlemon.. Example: User has DSL and NAT. Their ISP has told them to use the search domain example.net and use "mail" as the mail server name. This is a really stupid way to set things up, but it is fairly common. There exists a tedlemon.example.net. Ted Lemon visits, and hooks up his laptop. He's using the name "tedlemon". He tells Joe to connect to his web server (http://tedlemon/). Joe types it in, hits return. Joe gets a connection error because tedlemon.example.net resolved and isn't running a web server. Joe can not use a name to access Ted Lemon's computer. >> implementation does something extra-protocular to generate an FQDN. > > Nope. LLMNR can send a query for any name. LLMNR _can_ send a query for any name. It is not likely to send a query for most names unless DNS is available. When a DNS server is available, a user will be unable to determine which names can be used with LLMNR and which names can not. What works in one situation may not work in another. >> Perhaps the right thing is to specify the protocol by which this name >> is derived separately, but if so, we should say that that's the >> answer, > > All LLMNR needs to work is for a responder to have a name, any name. > If it > hears a query for that name, it will respond. There's no point in listening for a name if no one will ever us LLMNR to ask for it. -josh --Apple-Mail-8-577062929 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAwqwATANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDMwOTA1MTgyNzUwWhcNMDQwOTA0MTgyNzUwWjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRqZ3JhZXNzbGV5QGFwcGxl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM7EXVgIo1XLZWghTrlD+Lyvh01y IH3rl7Q5SYYMwX2EQytFr3XZeubyuBy5kV3IjrDiI2R2siVX+pLCDsy7sWccyqCkqusGFRyiDyRI xb6ydueBxrAz26AfavFWmAZp+mdPt4qbXmlhoIwbb5UsqxfgO1mpFMB6Xh/FpS0ZkLMkrsYB0KFN 1STxdwNpZnlVNS7B/MlmaevcC59VzmPn6m2Ud7RTVqxYE49AYqnNDo9f/byj+RwKGjFpD+mjut8I kOpL2J0VM8KcCw9RZS3mZSTIyLYxVEgqLlrcyxo5Bwv0hde+CCYN2ZprMz3D9vymHmpGyhaJsnRe o5oNETuX2nUCAwEAAaMxMC8wHwYDVR0RBBgwFoEUamdyYWVzc2xleUBhcHBsZS5jb20wDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBVU7HfJ6R7f/4YqQ8iEa9pqZX9A9j2MU67D43nWolj XRdeQGxCkCWOrJLG7UgtiUvas7B9mZhRYYj0KrI3xkSX+N3G/IXDHo6OLH2rJY/43PRMj8CbWkP3 rPLTBZg2guU7a2wkgRig1heEaUBinl9h5TxfDosmHXKtiWVUFuVTXDCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDCrABMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTAyMzE3NDQ1MlowIwYJKoZIhvcNAQkEMRYEFM0P QJnRXDK4J/RZJK0+lkdm+wReMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMKsAEwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDCrABMA0GCSqGSIb3DQEBAQUABIIBAM2z BpA1SpXfuEIrnv53vB8exUYRuHzvvqqSHrq9PWCTji03MpUFHojvi21onFVf1LrWrxxeQuFXErWj QyAY7+Oqw2vAflAvvM3omw5pPw0dscb89oqDJZHkLwvdZK1q/xYUv83IKcxdrgbar+cwj4E3S6P1 x3GWTPIxJ4efVoIEwaxxhw+mje7ko1oBYIOoScUoxg87pV+8TLJapuf8BM8lHB6QfVdGkDaAs0Ny njgstNwk2G/mypRsnwrpYqE/1OTtACEe/RwXZwkOHGgqREVKiNWNq7dOCWrZysC0tqYFCxsLJyjT alpR5+/ibLEE6JKDlfXpZHws5R6/kIf644IAAAAAAAA= --Apple-Mail-8-577062929-- -- to unsubscribe send a message to namedroppers-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 Oct 23 16:53: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 QAA18308 for ; Thu, 23 Oct 2003 16:53:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACmDw-0000z9-RO for namedroppers-data@psg.com; Thu, 23 Oct 2003 20:38:24 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACmDs-0000ys-32 for namedroppers@ops.ietf.org; Thu, 23 Oct 2003 20:38:20 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 7E7F74EEF7; Thu, 23 Oct 2003 22:38:19 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 1E5354EE43 for ; Thu, 23 Oct 2003 22:38:19 +0200 (CEST) Received: from x53.ripe.net (x53.ripe.net [193.0.1.53]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id h9NKcJVa011961 for ; Thu, 23 Oct 2003 22:38:19 +0200 Date: Thu, 23 Oct 2003 22:38:18 +0200 (CEST) From: Bruce Campbell X-X-Sender: bc@x53.ripe.net To: namedroppers@ops.ietf.org Subject: Draft: non-wildcard bit. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RIPE-Spam-Status: N 0.384122 X-RIPE-Signature: bd60467677fc2e959809a834d6f7fe30 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-1.5 required=5.0 tests=BAYES_01 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk With all the fuss on the unannounced addition of a wildcard record to the .com and .net zones, it is obvious that many applications need a clear and reliable method of knowing whether a response is 'real', or whether it has been synthesised. I'd like to put forward the following draft (submitted before the deadline, but currently in rfc-editor pre-meeting limbo) as _a_ solution to this problem, and see any on-list discussion on this solution before Minnie. http://www.ripe.net/home/bruce/draft-bcampbell-dns-non-wildcard-00.txt This document intends to describe a method of detecting the presence of a synthesised answer to a DNS query by the usage of a flag bit. It also suggests that the same flag be used to request that a synthesised answer not be returned. Note that 'flag bit' would either be the currently reserved header bit 9, or an EDNS option. -- Bruce Campbell I speak for myself. ( Of course, a perhaps far better, solution would be to have the zones signed and widespread deployment of DNSSEC-aware resolvers. ) -- to unsubscribe send a message to namedroppers-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 Oct 23 18:04: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 SAA21015 for ; Thu, 23 Oct 2003 18:04:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACnTu-0004Vp-GQ for namedroppers-data@psg.com; Thu, 23 Oct 2003 21:58:58 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACnTs-0004Vd-QR for namedroppers@ops.ietf.org; Thu, 23 Oct 2003 21:58:56 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 9C5D51390E for ; Thu, 23 Oct 2003 21:58:56 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Draft: non-wildcard bit. In-Reply-To: Message from Bruce Campbell of "Thu, 23 Oct 2003 22:38:18 +0200." X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 23 Oct 2003 21:58:56 +0000 Message-Id: <20031023215856.9C5D51390E@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > With all the fuss on the unannounced addition of a wildcard record to the > .com and .net zones, it is obvious that many applications need a clear and > reliable method of knowing whether a response is 'real', or whether it has > been synthesised. that's not obvious at all. -- to unsubscribe send a message to namedroppers-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 Oct 23 18:50: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 SAA23017 for ; Thu, 23 Oct 2003 18:50:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACoCP-0006b8-J2 for namedroppers-data@psg.com; Thu, 23 Oct 2003 22:44:57 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1ACoCK-0006as-VR for namedroppers@ops.ietf.org; Thu, 23 Oct 2003 22:44:53 +0000 Received: (qmail 20330 invoked by uid 1016); 23 Oct 2003 22:45:11 -0000 Date: 23 Oct 2003 22:45:11 -0000 Message-ID: <20031023224511.20329.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: Draft: non-wildcard bit. References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_10 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Bruce Campbell writes: > With all the fuss on the unannounced addition of a wildcard record to the > .com and .net zones, it is obvious that many applications need a clear and > reliable method of knowing whether a response is 'real' Exactly which applications are you talking about? What exactly is the definition of a ``real'' DNS record? What exactly do you want these applications to do with non-``real'' records? ---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 Oct 23 19:59: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 TAA25133 for ; Thu, 23 Oct 2003 19:59:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACpIW-000A8r-FQ for namedroppers-data@psg.com; Thu, 23 Oct 2003 23:55:20 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1ACpIS-000A8U-SM for namedroppers@ops.ietf.org; Thu, 23 Oct 2003 23:55:17 +0000 Received: (qmail 78892 invoked from network); 23 Oct 2003 23:56:46 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 23 Oct 2003 23:56:46 -0000 Message-ID: <3F986AAB.3030006@necom830.hpcl.titech.ac.jp> Date: Fri, 24 Oct 2003 08:56:27 +0900 From: masataka ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Joshua Graessley CC: Bernard Aboba , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC Summary: LLMNR References: <6CD0632A-04D2-11D8-AD19-000A95B9474C@apple.com> <3F9707E4.7020104@necom830.hpcl.titech.ac.jp> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Josh; >>> When have I mentioned service discovery. None of the three examples I >>> listed in the first email were related to service discovery. Masataka >>> Ohta pointed out a solution to one of the three scenarios in his >>> response. The other two have no solution with LLMNR. LLMNR doesn't >>> solve name resolution in ad-hoc networks because there is no way that >>> a host can know what name to use. >> What's wrong with a globally unique domain name configured at >> factory? > I think the point of having a name is that it's easier to remember than > an address. This is especially important when using IPv6LL addresses in > an ad-hoc environment. Having to remember the name > pbg4-b9-47-4c.names.apple.com would not be very useful. No, it is not, though your example is only as bad as raw IPv4 addresses. Wise vendors will use names more friendly to users. > Being able to > use a name like "joshs-powerbook" or "joshs-powerbook.llmnr." would make > life simpler. Of course, this relies on good conflict detection, What can you do if there is a conflict on "joshs-camera"? Note that cameras have no keyboard. Note also that a vendor can configure a camera of a registere user as: "camera0.josh-12.apple.com" >> Can I assume that the only DHCP and the only DNS servers of the >> home network is collocated on the NAT box? >> >> Then, a host can tell its domain name to the box through DHCP >> and the DNS server of the box can synthesis appropriate mapping. >> >> That is, we don't need multicast. > There are no NAT boxes, to the best of my knowledge, that do this today. Tell NAT box vendors to do so, then. That NAT boxes do or do not do something is not a valid reasoning to affect protocol development over the Internet. > Even if NAT boxes did this, what domain name would the host tell the box > it has? See above. 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 Oct 24 00:53: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 AAA03268 for ; Fri, 24 Oct 2003 00:53:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACtqd-000LWu-4K for namedroppers-data@psg.com; Fri, 24 Oct 2003 04:46:51 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACtqW-000LWK-4x for namedroppers@ops.ietf.org; Fri, 24 Oct 2003 04:46:44 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h9O4ALa26644 for ; Thu, 23 Oct 2003 21:10:21 -0700 Date: Thu, 23 Oct 2003 21:10:21 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC Summary: LLMNR In-Reply-To: <3F986AAB.3030006@necom830.hpcl.titech.ac.jp> Message-ID: References: <6CD0632A-04D2-11D8-AD19-000A95B9474C@apple.com> <3F9707E4.7020104@necom830.hpcl.titech.ac.jp> <3F986AAB.3030006@necom830.hpcl.titech.ac.jp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >This is only true if the computer performing the lookup doesn't have a >list of search domains or there is no tedlemon.. >Example: User has DSL and NAT. Their ISP has told them to use the search >domain example.net and use "mail" as the mail server name. This is a >really stupid way to set things up, but it is fairly common. There exists >a tedlemon.example.net. Ted Lemon visits, and hooks up his laptop. He's >using the name "tedlemon". He tells Joe to connect to his web server >(http://tedlemon/). Joe types it in, hits return. Joe gets a connection >error because tedlemon.example.net resolved and isn't running a web >server. Joe can not use a name to access Ted Lemon's computer. Nope. LLMNR was explicitly designed to work in this scenario. Section 3 says: "By default, LLMNR requests SHOULD be sent only when no manual or automatic DNS configuration has been performed, when DNS servers do not respond, or when they respond to a query with RCODE=3 (Authoritative Name Error) or RCODE=0, and an empty answer section." Also: "[1] If a DNS query does not receive a response, prior to falling back to LLMNR, the query SHOULD be retransmitted at least once. So the LLMNR sender would try "tedlemon.example.net" and would get back and error and then it would fall back to an LLMNR query for "tedlemon" eventually. -- to unsubscribe send a message to namedroppers-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 Oct 24 01:26: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 BAA03810 for ; Fri, 24 Oct 2003 01:26:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACuP5-000NNw-4S for namedroppers-data@psg.com; Fri, 24 Oct 2003 05:22:27 +0000 Received: from [204.152.189.141] (helo=a.mx.kooks.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACuP1-000NNi-F1 for namedroppers@ops.ietf.org; Fri, 24 Oct 2003 05:22:23 +0000 Received: from a.mx.kooks.net (a.mx.kooks.net [204.152.189.141]) by a.mx.kooks.net (Postfix) with ESMTP id 85A3922E5B; Thu, 23 Oct 2003 22:22:22 -0700 (PDT) Date: Thu, 23 Oct 2003 22:22:22 -0700 (PDT) From: Chris Yarnell To: Bruce Campbell Cc: namedroppers@ops.ietf.org Subject: Re: Draft: non-wildcard bit. In-Reply-To: Message-ID: <20031023222106.E25210@lame.kooks.net> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_10 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > .com and .net zones, it is obvious that many applications need a clear and > reliable method of knowing whether a response is 'real', or whether it has it is? please explain. -- to unsubscribe send a message to namedroppers-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 Oct 24 02: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 CAA18113 for ; Fri, 24 Oct 2003 02:27:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACvMr-000Pt3-5Q for namedroppers-data@psg.com; Fri, 24 Oct 2003 06:24:13 +0000 Received: from [17.254.13.22] (helo=mail-out3.apple.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACvMp-000Psr-2s for namedroppers@ops.ietf.org; Fri, 24 Oct 2003 06:24:11 +0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.10/8.12.9) with ESMTP id h9O6OATi028585 for ; Thu, 23 Oct 2003 23:24:10 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 23 Oct 2003 23:23:39 -0700 Received: from [17.219.197.80] ([17.219.197.80]) by scv2.apple.com (8.12.9/8.12.9) with ESMTP id h9O6NsEV028400; Thu, 23 Oct 2003 23:23:54 -0700 (PDT) In-Reply-To: References: <6CD0632A-04D2-11D8-AD19-000A95B9474C@apple.com> <3F9707E4.7020104@necom830.hpcl.titech.ac.jp> <3F986AAB.3030006@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-17-622619927; protocol="application/pkcs7-signature" Message-Id: Cc: namedroppers@ops.ietf.org From: Joshua Graessley Subject: Re: DNSEXT WGLC Summary: LLMNR Date: Thu, 23 Oct 2003 23:24:09 -0700 To: Bernard Aboba X-Mailer: Apple Mail (2.606) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --Apple-Mail-17-622619927 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Oct 23, 2003, at 9:10 PM, Bernard Aboba wrote: >> This is only true if the computer performing the lookup doesn't have a >> list of search domains or there is no tedlemon.> here>. >> Example: User has DSL and NAT. Their ISP has told them to use the >> search >> domain example.net and use "mail" as the mail server name. This is a >> really stupid way to set things up, but it is fairly common. There >> exists >> a tedlemon.example.net. Ted Lemon visits, and hooks up his laptop. >> He's >> using the name "tedlemon". He tells Joe to connect to his web server >> (http://tedlemon/). Joe types it in, hits return. Joe gets a >> connection >> error because tedlemon.example.net resolved and isn't running a web >> server. Joe can not use a name to access Ted Lemon's computer. > > Nope. LLMNR was explicitly designed to work in this scenario. Section > 3 > says: > > "By default, LLMNR requests SHOULD be sent only when no manual or > automatic DNS configuration has been performed, when DNS servers do > not respond, or > when they respond to a query with RCODE=3 (Authoritative Name Error) or > RCODE=0, and an empty answer section." > > Also: > > "[1] If a DNS query does not receive a response, prior to falling > back to LLMNR, the query SHOULD be retransmitted at least > once. > > So the LLMNR sender would try "tedlemon.example.net" and would get back > and error and then it would fall back to an LLMNR query for "tedlemon" > eventually. In the case stated above, there is DNS configured and there is a tedlemon.example.net. LLMNR would never be used. DNS would receive a response and never fall back to LLMNR. -josh --Apple-Mail-17-622619927 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAwqwATANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDMwOTA1MTgyNzUwWhcNMDQwOTA0MTgyNzUwWjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRqZ3JhZXNzbGV5QGFwcGxl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM7EXVgIo1XLZWghTrlD+Lyvh01y IH3rl7Q5SYYMwX2EQytFr3XZeubyuBy5kV3IjrDiI2R2siVX+pLCDsy7sWccyqCkqusGFRyiDyRI xb6ydueBxrAz26AfavFWmAZp+mdPt4qbXmlhoIwbb5UsqxfgO1mpFMB6Xh/FpS0ZkLMkrsYB0KFN 1STxdwNpZnlVNS7B/MlmaevcC59VzmPn6m2Ud7RTVqxYE49AYqnNDo9f/byj+RwKGjFpD+mjut8I kOpL2J0VM8KcCw9RZS3mZSTIyLYxVEgqLlrcyxo5Bwv0hde+CCYN2ZprMz3D9vymHmpGyhaJsnRe o5oNETuX2nUCAwEAAaMxMC8wHwYDVR0RBBgwFoEUamdyYWVzc2xleUBhcHBsZS5jb20wDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBVU7HfJ6R7f/4YqQ8iEa9pqZX9A9j2MU67D43nWolj XRdeQGxCkCWOrJLG7UgtiUvas7B9mZhRYYj0KrI3xkSX+N3G/IXDHo6OLH2rJY/43PRMj8CbWkP3 rPLTBZg2guU7a2wkgRig1heEaUBinl9h5TxfDosmHXKtiWVUFuVTXDCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDCrABMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTAyNDA2MjQwOVowIwYJKoZIhvcNAQkEMRYEFPib ipgdddbgvkljF64+dTZ8ZcyZMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMKsAEwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDCrABMA0GCSqGSIb3DQEBAQUABIIBADbC CrhV2k6ecBJLn6RQ1Kcr8TACfl5RB4iXveUwzmuqScQ+JqFhC4rg0InUJN8YTn1HibcNEzxKUnXz gR3QNYwqnf5OXMF5CLopQ4ZU/zcR0Z1WDTVwTHw1aCMT8vO2LZBVKZh5+1ao3vTAKmciSihuelng IFW1EDfV9od/VZYOzAxQCBpqhEAovQ0CY44WsuohmR+p7Q8RyH8x4RkOrofzO32JeV08RWF/1oKO Hhl6Ka3g2N7Ekvsv02TtdPDOaF87m0hLtjCccj1sYhVmtOlt4H7ewnxgVqYfxuTxJ/fyVfAqeBYG gppX+hqlZ59B3/wgJbpG7uxcsbfF+d+ULt0AAAAAAAA= --Apple-Mail-17-622619927-- -- to unsubscribe send a message to namedroppers-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 Oct 24 07:07: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 HAA25606 for ; Fri, 24 Oct 2003 07:07:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACzeP-000CQX-A0 for namedroppers-data@psg.com; Fri, 24 Oct 2003 10:58:37 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACzeN-000CQH-8p for namedroppers@ops.ietf.org; Fri, 24 Oct 2003 10:58:35 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.22) id 1ACzeM-000J3a-KO for namedroppers@ops.ietf.org; Fri, 24 Oct 2003 03:58:34 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit Date: Fri, 24 Oct 2003 00:49:37 -0500 Subject: Re: DNSEXT WGLC Summary: LLMNR Cc: namedroppers@ops.ietf.org To: Bernard Aboba From: Ted Lemon X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] On Thursday, October 23, 2003, at 11:10 PM, Bernard Aboba wrote: > So the LLMNR sender would try "tedlemon.example.net" and would get back > and error and then it would fall back to an LLMNR query for "tedlemon" > eventually. Only if there is no tedlemon.example.net. If there is one, it will get the wrong answer. This is because there is no way to say "I mean LLMNR." I can't say "ping tedlemon.llmnr" - all I can do is say "ping tedlemon", which is ambiguous. -- to unsubscribe send a message to namedroppers-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 Oct 24 10:14: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 KAA01966 for ; Fri, 24 Oct 2003 10:14:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AD2dE-000LdC-O7 for namedroppers-data@psg.com; Fri, 24 Oct 2003 14:09:36 +0000 Received: from [192.150.250.67] (helo=fuchsia.home) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AD2cv-000Lbj-L5 for namedroppers@ops.ietf.org; Fri, 24 Oct 2003 14:09:18 +0000 Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h9OE4xIl027246; Fri, 24 Oct 2003 21:04:59 +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 h9OE72h02549; Fri, 24 Oct 2003 21:07:04 +0700 (ICT) From: Robert Elz To: Ted Lemon cc: Bernard Aboba , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC Summary: LLMNR In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 24 Oct 2003 21:07:02 +0700 Message-ID: <26345.1067004422@munnari.OZ.AU> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Fri, 24 Oct 2003 00:49:37 -0500 From: Ted Lemon Message-ID: | Only if there is no tedlemon.example.net. If there is one, it will | get the wrong answer. This is because there is no way to say "I mean | LLMNR." I can't say "ping tedlemon.llmnr" - all I can do is say "ping | tedlemon", which is ambiguous. What happened to "ping tedlemon." ? If the names are actually different, then there's never going to be a problem. If the names are the same, then there's nothing rational that can be done. The ambiguity exists, the very best that can be done is to at least provide a well defined reconciliation rule. Appending a constant to a name and hoping to improve things is essentially the same as adding a constant to a pseudo-random number and hoping to improve it. If you want your local-only system to have a name that cannot possibly be confused with a DNS name, giving it a name in a fake TLD (like llmnr or local) will work just fine to allow you to reach that one safely by name (assuming there isn't another one on the LAN of course). Attempting to do this automatically simply doesn't help - that is, if you expect the system to be known as "tedlemon" and you believe that by doing the LLMNR lookup using "tedlemon.llmnr" automatically (and the node making itself known there that way automatically) then you're mistaken. The user still does "ping tedlemon" and gets an answer - from the "other" host with the same name - there's no indication that it isn't the one that was wanted. There's unquestionably a difficult naming issue here - applications want to "simply work" - that is, use a standard API to translate name->address, and be able to use the address with some kind of confidence. Having that able to work in a mixed environment of registered names, and "made up" names is really not easy. Appletalk provides no guidance, as it never had an environment like this to work in. The various attempts to solve this by fiddling with bits in the lookup format are sadly misguided (and adding a constant string to the name being sought is just fiddling with bits in the packet format). kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Oct 24 14:10:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20734 for ; Fri, 24 Oct 2003 14:10:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AD6BX-0008OY-4f for namedroppers-data@psg.com; Fri, 24 Oct 2003 17:57:15 +0000 Received: from [192.150.250.67] (helo=fuchsia.home) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AD6BC-0008NW-99 for namedroppers@ops.ietf.org; Fri, 24 Oct 2003 17:56:54 +0000 Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h9OHqtIl003188; Sat, 25 Oct 2003 00:52:56 +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 h9OHpZh10796; Sat, 25 Oct 2003 00:51:36 +0700 (ICT) From: Robert Elz To: Ted Lemon cc: namedroppers Subject: Re: DNSEXT WGLC Summary: LLMNR - Using root name servers in LLMNR In-Reply-To: <82316728-063D-11D8-99FC-000A95D9C74C@fugue.com> References: <82316728-063D-11D8-99FC-000A95D9C74C@fugue.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 25 Oct 2003 00:51:35 +0700 Message-ID: <27256.1067017895@munnari.OZ.AU> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Fri, 24 Oct 2003 11:17:05 -0500 From: Ted Lemon Message-ID: <82316728-063D-11D8-99FC-000A95D9C74C@fugue.com> | Then you get a query to the root: "who has the top-level domain | 'tedlemon'?". I think maybe the owners of the root name servers would | rather not see queries like that. Maybe I'm wrong. I'm sure that they wouldn't, but then again they get this stuff now, and this isn't going to increase it much. This use of the '.' isn't going to be very common - remember here we're imagining the rather fanciful case of the same name being used for something registered in the DNS in the search domains, and happening to have just turned up as an unregistered local node that we want to contact (note: not that wants to contact us). I'm not a root server operator, but even if I were, simple typos, and people who want to treat the DNS as a directory service, would bother me far more than this. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Oct 24 14:53: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 OAA22990 for ; Fri, 24 Oct 2003 14:53:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AD6xy-000B9d-VJ for namedroppers-data@psg.com; Fri, 24 Oct 2003 18:47:18 +0000 Received: from [17.254.13.22] (helo=mail-out3.apple.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AD6xu-000B8x-EF for namedroppers@ops.ietf.org; Fri, 24 Oct 2003 18:47:14 +0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.10/8.12.9) with ESMTP id h9OIlEwP000485 for ; Fri, 24 Oct 2003 11:47:14 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 24 Oct 2003 11:46:42 -0700 Received: from [17.202.40.111] (graejo.apple.com [17.202.40.111]) by scv3.apple.com (8.12.9/8.12.9) with ESMTP id h9OIkl0m020393 for ; Fri, 24 Oct 2003 11:46:47 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v606) In-Reply-To: <26345.1067004422@munnari.OZ.AU> References: <26345.1067004422@munnari.OZ.AU> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-23-667204344; protocol="application/pkcs7-signature" Message-Id: <7BA1B83C-0652-11D8-B5ED-000A95B9474C@apple.com> From: Joshua Graessley Subject: Re: DNSEXT WGLC Summary: LLMNR Date: Fri, 24 Oct 2003 11:47:13 -0700 To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.606) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --Apple-Mail-23-667204344 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit My apologies to the working group for wasting their time. It is apparent I am in the minority here. It seems the worry of conflicting with a name in DNS and being unable to use LLMNR is not an important issue to most folks. This is reflected in the draft. It is also quite apparent that LLMNR and mDNS solve completely different problems. LLMNR does not appear to solve any problems important to me or the vendor I work for. Maybe this working group will have luck finding someone that is interested in LLMNR. Best wishes, good luck! -josh --Apple-Mail-23-667204344 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAwqwATANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDMwOTA1MTgyNzUwWhcNMDQwOTA0MTgyNzUwWjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRqZ3JhZXNzbGV5QGFwcGxl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM7EXVgIo1XLZWghTrlD+Lyvh01y IH3rl7Q5SYYMwX2EQytFr3XZeubyuBy5kV3IjrDiI2R2siVX+pLCDsy7sWccyqCkqusGFRyiDyRI xb6ydueBxrAz26AfavFWmAZp+mdPt4qbXmlhoIwbb5UsqxfgO1mpFMB6Xh/FpS0ZkLMkrsYB0KFN 1STxdwNpZnlVNS7B/MlmaevcC59VzmPn6m2Ud7RTVqxYE49AYqnNDo9f/byj+RwKGjFpD+mjut8I kOpL2J0VM8KcCw9RZS3mZSTIyLYxVEgqLlrcyxo5Bwv0hde+CCYN2ZprMz3D9vymHmpGyhaJsnRe o5oNETuX2nUCAwEAAaMxMC8wHwYDVR0RBBgwFoEUamdyYWVzc2xleUBhcHBsZS5jb20wDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBVU7HfJ6R7f/4YqQ8iEa9pqZX9A9j2MU67D43nWolj XRdeQGxCkCWOrJLG7UgtiUvas7B9mZhRYYj0KrI3xkSX+N3G/IXDHo6OLH2rJY/43PRMj8CbWkP3 rPLTBZg2guU7a2wkgRig1heEaUBinl9h5TxfDosmHXKtiWVUFuVTXDCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDCrABMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTAyNDE4NDcxNFowIwYJKoZIhvcNAQkEMRYEFFxF 3N6TqsVEjpj8SpGq80ap+ngMMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMKsAEwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDCrABMA0GCSqGSIb3DQEBAQUABIIBAI5a v3FUQpRujhWQpEt4k5VUbyNcGyvvdmm+8kZrvkOvi4wdaiMuosbEe+l6RGAFlE8LLmgyhZXivKz9 KNEHMAQ2lmb8APOLA9xnvjlm1rMkDAYuIgQzyFFYHw4Csgna5lW6lfdoAMMYwYpXdSii0ih6N4hq IAp6yAyTKox7VFnN/CYW2TxWOXS9VjKZ57PE5YY7C5GFWzWHYlhwP11BF4jywJi5sgsGNB6XCrNy q25NgTAn6BwU4P9hXz+nQ9aZGHJGSQdn3U2wEzIKr4AGfQTwbWYfbjlvxSEEXk9VN1cOFDVFCcHF qj0bAtey4QkN0aDHR5JCnSqsQNrabqB4AdQAAAAAAAA= --Apple-Mail-23-667204344-- -- to unsubscribe send a message to namedroppers-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 Oct 24 17:17: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 RAA00139 for ; Fri, 24 Oct 2003 17:17:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AD9BG-000Hu2-RU for namedroppers-data@psg.com; Fri, 24 Oct 2003 21:09:10 +0000 Received: from [65.201.175.62] (helo=cliffie.verisignlabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AD9BC-000Htp-Mk for namedroppers@ops.ietf.org; Fri, 24 Oct 2003 21:09:06 +0000 Received: from pinion.admin.cto.netsol.com ([::ffff:172.25.170.10]) (AUTH: LOGIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by cliffie.verisignlabs.com with esmtp; Fri, 24 Oct 2003 17:09:06 -0400 From: David Blacka Organization: Verisign, Inc. To: namedroppers@ops.ietf.org Subject: Wildcard NS and DNSSEC Date: Fri, 24 Oct 2003 17:09:05 -0400 User-Agent: KMail/1.5.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310241709.05520.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Level: * X-Spam-Status: No, hits=1.0 required=5.0 tests=BAYES_01,OPT_IN_CAPS autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think that there is a conflict between the wildcard clarify and DNSSEC. Section 6.2 of wildcard-clarify says (essentially): Is it not a protocol error to have a NS RR owned by a wild card domian name, complimentary to the case of a SOA RR. However, for this to work, an implementation has to know how to synthesize a zone. In other words, wildcard NS records are technically legal. I am not taking a position on whether or not they should be legal. However, I cannot see how they work with DNSSEC. Imagine your fancy zone, example.net: example.net IN SOA .... example.net IN RRSIG SOA ... ... *.example.net IN NS ns1.super-wcard.example.com. *.example.net IN NS ns2.super-wcard.example.com. (ns1 & ns2 are nameservers that can synthesize entire zones ending with example.net). Continue to imagine that example.net is signed. And now imagine a referral generated by this wacky wildcard: QUESTION foo.example.net IN A ANSWER AUTHORITY foo.example.net IN NS ns1.super-wcard.example.com. foo.example.net IN NS ns2.super-wcard.example.com. f.example.net IN NSEC g.example.net A RRSIG NSEC ADDITIONAL ... Ok, so like a normal positive wildcard match, a NSEC record is included to show that there wasn't a non-wildcard record that should have matched or blocked. BUT, since delegation NS sets aren't signed, there is no RRSIG for the referral itself. For starters, I know for certain that this will not validate. It looks just like an Opt-In response (except for the NSEC bit on the NSEC record), and we have some experience with unaware validators choking on this sort of response. Additionally, you might be able to see that part of the standard wildcard validation is missing: proof that (at least) the wildcard actually exists. This is, IMHO, because a wildcard NS RRset is a truly odd thing: the zone is synthesizing records for which it isn't even authoritative. I suppose that it might be possible to handle this by adding another NSEC record for the wildcard, which may solve some nagging security issues, but would be a pretty odd special case. -- David Blacka Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Oct 25 01:02: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 BAA13218 for ; Sat, 25 Oct 2003 01:02:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ADGQg-00087Z-4m for namedroppers-data@psg.com; Sat, 25 Oct 2003 04:53:34 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ADGQe-00087K-LR for namedroppers@ops.ietf.org; Sat, 25 Oct 2003 04:53:32 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 889E913967; Sat, 25 Oct 2003 04:53:29 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Joshua Graessley Cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC Summary: LLMNR In-Reply-To: Message from Joshua Graessley of "Fri, 24 Oct 2003 11:47:13 MST." <7BA1B83C-0652-11D8-B5ED-000A95B9474C@apple.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sat, 25 Oct 2003 04:53:29 +0000 Message-Id: <20031025045329.889E913967@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > LLMNR does not appear to solve any problems important to me or the vendor I > work for. Maybe this working group will have luck finding someone that is > interested in LLMNR. i think that the llmnr document, or another to be advanced at the same time, should give implementation guidance to vendors who also implement dns and mdns. -- to unsubscribe send a message to namedroppers-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 Oct 25 11:33: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 LAA08138 for ; Sat, 25 Oct 2003 11:33:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ADQI6-0005rf-MY for namedroppers-data@psg.com; Sat, 25 Oct 2003 15:25:22 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ADQI4-0005rN-HF for namedroppers@ops.ietf.org; Sat, 25 Oct 2003 15:25:20 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 6A55E13975 for ; Sat, 25 Oct 2003 15:25:17 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Wildcard NS and DNSSEC In-Reply-To: Message from David Blacka of "Fri, 24 Oct 2003 17:09:05 -0400." <200310241709.05520.davidb@verisignlabs.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sat, 25 Oct 2003 15:25:17 +0000 Message-Id: <20031025152517.6A55E13975@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ... Section 6.2 of wildcard-clarify says (essentially): > > Is it not a protocol error to have a NS RR owned by a wild card > domian name, complimentary to the case of a SOA RR. However, for > this to work, an implementation has to know how to synthesize a > zone. > > In other words, wildcard NS records are technically legal. I am > not taking a position on whether or not they should be legal. fwiw, i am. the above wording gives no guidance to implementors and should be struck from the document. the proper wording is simply that "Having an NS RRset owned by a wild card domain name is undefined" which in terms of guidance to implementors is very much clearer. Either set of wording leaves open the possibility of later defining it. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Oct 26 06:23: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 GAA14964 for ; Sun, 26 Oct 2003 06:23:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ADio4-000OHK-SW for namedroppers-data@psg.com; Sun, 26 Oct 2003 11:11:36 +0000 Received: from [3ffe:805::230:48ff:fe22:6a53] (helo=karoshi.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ADio2-000OGz-15 for namedroppers@ops.ietf.org; Sun, 26 Oct 2003 11:11:34 +0000 Received: (from bmanning@localhost) by karoshi.com (8.11.6/8.11.6 - yeah right) id h9QBBGi29357; Sun, 26 Oct 2003 03:11:16 -0800 From: bmanning@karoshi.com Message-Id: <200310261111.h9QBBGi29357@karoshi.com> Subject: Re: Wildcard NS and DNSSEC To: davidb@verisignlabs.com (David Blacka) Date: Sun, 26 Oct 2003 03:11:16 -0800 (PST) Cc: namedroppers@ops.ietf.org In-Reply-To: <200310241709.05520.davidb@verisignlabs.com> from "David Blacka" at Oct 24, 2003 05:09:05 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > In other words, wildcard NS records are technically legal. I am > not taking a position on whether or not they should be legal. perhaps this is the distinction btwn "newtonian DNS" and "quantum DNS" ... :) > *.example.net IN NS ns1.super-wcard.example.com. > *.example.net IN NS ns2.super-wcard.example.com. > > (ns1 & ns2 are nameservers that can synthesize entire zones ending > with example.net). what would the zone "*.example.net" look like? specifically the SOA. > choking on this sort of response. Additionally, you might be able to > see that part of the standard wildcard validation is missing: proof > that (at least) the wildcard actually exists. This is, IMHO, because > a wildcard NS RRset is a truly odd thing: the zone is synthesizing > records for which it isn't even authoritative. again.. what are the contents fo the "wildcard zone" > I suppose that it might be possible to handle this by adding another > NSEC record for the wildcard, which may solve some nagging security > issues, but would be a pretty odd special case. -IF- we go this far, then an NSEC rr for the wildcard would be useful. > > -- > David Blacka > Sr. Engineer Verisign Applied Research > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-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 Oct 26 07:39: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 HAA16382 for ; Sun, 26 Oct 2003 07:39:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ADk6P-0001gK-LP for namedroppers-data@psg.com; Sun, 26 Oct 2003 12:34:37 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1ADk6M-0001fy-Sk for namedroppers@ops.ietf.org; Sun, 26 Oct 2003 12:34:35 +0000 Received: (qmail 89503 invoked from network); 26 Oct 2003 12:36:49 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 26 Oct 2003 12:36:49 -0000 Message-ID: <3F9BBFA2.6010609@necom830.hpcl.titech.ac.jp> Date: Sun, 26 Oct 2003 21:35:46 +0900 From: masataka ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: David Blacka CC: namedroppers@ops.ietf.org Subject: Re: Wildcard NS and DNSSEC References: <200310241709.05520.davidb@verisignlabs.com> In-Reply-To: <200310241709.05520.davidb@verisignlabs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit David Blacka; > I think that there is a conflict between the wildcard clarify and > DNSSEC. Section 6.2 of wildcard-clarify says (essentially): > > Is it not a protocol error to have a NS RR owned by a wild card > domian name, complimentary to the case of a SOA RR. However, for > this to work, an implementation has to know how to synthesize a > zone. > > In other words, wildcard NS records are technically legal. I am > not taking a position on whether or not they should be legal. Hmmmmm, after rereading the paragraph, it seems to me that the draft says something on a wildcarded authoritative NS (and SOA), but perhaps not on a wildcarded referal NS. However, the wildcarded authoritative NS (and SOA) is, IMHO, illegal, or, at least, meaningless. The problem is that SOA and authoritative NS must appear at the root, and nowhere else, of a zone, which makes wildcarding, which makes the RRs appear at lower nodes of the zone, meaningless. On the other hand, it seems to me that referral NS, which seems to be useful (at least for NSI, maybe), is not considered explicitely in the draft but, IMHO, should be legislated more explicitely. 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 Sun Oct 26 15:19:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27263 for ; Sun, 26 Oct 2003 15:19:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ADrF5-000MZ8-Ku for namedroppers-data@psg.com; Sun, 26 Oct 2003 20:12:03 +0000 Received: from [65.201.175.62] (helo=cliffie.verisignlabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ADrF2-000MYt-VU for namedroppers@ops.ietf.org; Sun, 26 Oct 2003 20:12:01 +0000 Received: from piston.dyn.verisignlabs.com ([::ffff:68.48.27.14]) (AUTH: PLAIN davidb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by cliffie.verisignlabs.com with esmtp; Sun, 26 Oct 2003 15:12:00 -0500 From: David Blacka Organization: Verisign, Inc. To: namedroppers@ops.ietf.org Subject: Re: Wildcard NS and DNSSEC Date: Sun, 26 Oct 2003 15:11:59 -0500 User-Agent: KMail/1.5 References: <200310261111.h9QBBGi29357@karoshi.com> In-Reply-To: <200310261111.h9QBBGi29357@karoshi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310261511.59474.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sunday 26 October 2003 06:11 am, bmanning@karoshi.com wrote: > > In other words, wildcard NS records are technically legal. I am > > not taking a position on whether or not they should be legal. > > perhaps this is the distinction btwn > "newtonian DNS" and "quantum DNS" ... :) > > > *.example.net IN NS ns1.super-wcard.example.com. > > *.example.net IN NS ns2.super-wcard.example.com. > > > > (ns1 & ns2 are nameservers that can synthesize entire zones ending > > with example.net). > > what would the zone "*.example.net" look like? > specifically the SOA. Why does this matter? In my mind, the zones are not necessarily represented by a bunch of wildcard records. It would be sufficient to write a special authoritative server that just had rules for generating the correct responses base on the query. > > I suppose that it might be possible to handle this by adding another > > NSEC record for the wildcard, which may solve some nagging security > > issues, but would be a pretty odd special case. > > -IF- we go this far, then an NSEC rr for the wildcard > would be useful. -IF- we went this far, the validator wouldn't just need the NSEC record, it would need to know what to do with it. -- David Blacka Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Oct 26 15:34: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 PAA27813 for ; Sun, 26 Oct 2003 15:34:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ADrW0-000NWU-M0 for namedroppers-data@psg.com; Sun, 26 Oct 2003 20:29:32 +0000 Received: from [65.201.175.62] (helo=cliffie.verisignlabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ADrVx-000NWA-Md for namedroppers@ops.ietf.org; Sun, 26 Oct 2003 20:29:29 +0000 Received: from piston.dyn.verisignlabs.com ([::ffff:68.48.27.14]) (AUTH: PLAIN davidb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by cliffie.verisignlabs.com with esmtp; Sun, 26 Oct 2003 15:29:29 -0500 From: David Blacka Organization: Verisign, Inc. To: namedroppers@ops.ietf.org Subject: Re: Wildcard NS and DNSSEC Date: Sun, 26 Oct 2003 15:29:28 -0500 User-Agent: KMail/1.5 References: <200310241709.05520.davidb@verisignlabs.com> <3F9BBFA2.6010609@necom830.hpcl.titech.ac.jp> In-Reply-To: <3F9BBFA2.6010609@necom830.hpcl.titech.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310261529.28671.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sunday 26 October 2003 07:35 am, masataka ohta wrote: > David Blacka; > > > I think that there is a conflict between the wildcard clarify and > > DNSSEC. Section 6.2 of wildcard-clarify says (essentially): > > > > Is it not a protocol error to have a NS RR owned by a wild card > > domian name, complimentary to the case of a SOA RR. However, for > > this to work, an implementation has to know how to synthesize a > > zone. > > > > In other words, wildcard NS records are technically legal. I am > > not taking a position on whether or not they should be legal. > > Hmmmmm, after rereading the paragraph, it seems to me that > the draft says something on a wildcarded authoritative NS (and > SOA), but perhaps not on a wildcarded referal NS. Interesting. I came to the opposite conclusion. The earlier paragraphs in the section seem to be talking about delegation NS RRsets. If you and I can disagree on this, then it is clear that 6.2 isn't clear. > However, the wildcarded authoritative NS (and SOA) is, IMHO, > illegal, or, at least, meaningless. > > The problem is that SOA and authoritative NS must appear > at the root, and nowhere else, of a zone, which makes > wildcarding, which makes the RRs appear at lower nodes > of the zone, meaningless. I didn't follow that. It is perfectly valid to have a zone that only has records at the apex. In fact, I imagine that is how this whole situation would have to work: synthesized zones with only records at the apex. > On the other hand, it seems to me that referral NS, which > seems to be useful (at least for NSI, maybe), is not > considered explicitely in the draft but, IMHO, should be > legislated more explicitely. My main point is that 2535bis and wcard-clarify are, IMO, in conflict, and, since 2535bis has a normative reference to wcard-clarify, that is definitely a problem. -- David Blacka Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Oct 26 16:04: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 QAA28213 for ; Sun, 26 Oct 2003 16:04:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ADs0c-000PQI-O1 for namedroppers-data@psg.com; Sun, 26 Oct 2003 21:01:10 +0000 Received: from [2002:425c:4242:0:250:daff:fe82:1c39] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ADs0Z-000PPt-WA for namedroppers@ops.ietf.org; Sun, 26 Oct 2003 21:01:08 +0000 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id CA90218E2 for ; Sun, 26 Oct 2003 16:01:04 -0500 (EST) Date: Sun, 26 Oct 2003 16:01:04 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Wildcard NS and DNSSEC In-Reply-To: <200310261529.28671.davidb@verisignlabs.com> References: <200310241709.05520.davidb@verisignlabs.com> <3F9BBFA2.6010609@necom830.hpcl.titech.ac.jp> <200310261529.28671.davidb@verisignlabs.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: <20031026210104.CA90218E2@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Sun, 26 Oct 2003 15:29:28 -0500, David Blacka wrote: > ... > My main point is that 2535bis and wcard-clarify are, IMO, in > conflict, and, since 2535bis has a normative reference to > wcard-clarify, that is definitely a problem. Ignoring the rest of the conversation for the moment, thanks for pointing this out. This was a normative reference up through dnssec-protocol-02, but since wcard-clarify no longer contains any text about DNSSEC (bis or classic), the citations that made this a normative reference will be gone in dnssec-protocol-03. I'll make wcard-clarify an informative reference in dnssec-protocol-03 (which we'll be dropping into the I-D queue before the gate slams shut tomorow morning). What to do from there is, of course, up to the WG. -- to unsubscribe send a message to namedroppers-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 Oct 26 16:17: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 QAA28477 for ; Sun, 26 Oct 2003 16:17:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ADsDR-0000JG-46 for namedroppers-data@psg.com; Sun, 26 Oct 2003 21:14:25 +0000 Received: from [2002:425c:4242:0:250:daff:fe82:1c39] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ADsDG-0000Hx-Bf for namedroppers@ops.ietf.org; Sun, 26 Oct 2003 21:14:14 +0000 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id EF59818E1 for ; Sun, 26 Oct 2003 16:14:12 -0500 (EST) Date: Sun, 26 Oct 2003 16:14:12 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Wildcard NS and DNSSEC In-Reply-To: <20031026210104.CA90218E2@thrintun.hactrn.net> References: <200310241709.05520.davidb@verisignlabs.com> <3F9BBFA2.6010609@necom830.hpcl.titech.ac.jp> <200310261529.28671.davidb@verisignlabs.com> <20031026210104.CA90218E2@thrintun.hactrn.net> 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: <20031026211412.EF59818E1@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Correcting my own misstatement to save the rest of you the trouble: wcard-clarify was incorrectly listed as an informative reference in dnssec-protocol-02, but the reference was in fact normative. That's been fixed. Sorry for the confusion. -- to unsubscribe send a message to namedroppers-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 Oct 26 18:27: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 SAA04633 for ; Sun, 26 Oct 2003 18:27:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ADuES-0005PL-LB for namedroppers-data@psg.com; Sun, 26 Oct 2003 23:23:36 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1ADuEQ-0005P7-0G for namedroppers@ops.ietf.org; Sun, 26 Oct 2003 23:23:34 +0000 Received: (qmail 92421 invoked from network); 26 Oct 2003 23:25:57 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 26 Oct 2003 23:25:57 -0000 Message-ID: <3F9C57BD.9080701@necom830.hpcl.titech.ac.jp> Date: Mon, 27 Oct 2003 08:24:45 +0900 From: masataka ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: David Blacka CC: namedroppers@ops.ietf.org Subject: Re: Wildcard NS and DNSSEC References: <200310241709.05520.davidb@verisignlabs.com> <3F9BBFA2.6010609@necom830.hpcl.titech.ac.jp> <200310261529.28671.davidb@verisignlabs.com> In-Reply-To: <200310261529.28671.davidb@verisignlabs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit David Blacka; >>The problem is that SOA and authoritative NS must appear >>at the root, and nowhere else, of a zone, which makes >>wildcarding, which makes the RRs appear at lower nodes >>of the zone, meaningless. > > > I didn't follow that. It is perfectly valid to have a zone that only has > records at the apex. Yes. > In fact, I imagine that is how this whole situation > would have to work: synthesized zones with only records at the apex. Yes, syhthesis is fine. But, it is enough to have wildcard notation in zone files internal to a name server only without having it with the protocol. In addition, to do so, wildcarded referral NS is just enough. Note that wildcarded authoritative NS and SOA does not appear on the wire even with "*" query. Or, can you show me a conter example? Note also that zone transfer of a zone with wildcarded SOA is impossible. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Oct 27 05:04: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 FAA04582 for ; Mon, 27 Oct 2003 05:04:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AE48V-0002ZD-MV for namedroppers-data@psg.com; Mon, 27 Oct 2003 09:58:07 +0000 Received: from [2002:425c:4242:0:250:daff:fe82:1c39] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AE48T-0002Yx-HS for namedroppers@ops.ietf.org; Mon, 27 Oct 2003 09:58:05 +0000 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id C659618E1 for ; Mon, 27 Oct 2003 04:58:03 -0500 (EST) Date: Mon, 27 Oct 2003 04:58:03 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: New versions of DNSSECbis drafts available 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: <20031027095803.C659618E1@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The DNSSEC document editors just submitted the latest revisions of the drafts to the Internet-Drafts admin. Copies are also posted at: http://www.hactrn.net/ietf/dns/dnssec-editors/ Please review. Please review. Please review. Along with addressing questions resolved since Vienna, we also reorganized and rewrote portions of the protocol document and added a bunch of new examples. As always, send little stuff to the dnssec-editors list, send anything major to namedroppers. And, oh yeah, did we mention that we'd appreciate it if you'd review the drafts? Thanks. --Rob (on behalf of your friendly neighborhood DNSSEC doc editors) -- to unsubscribe send a message to namedroppers-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 Oct 27 08:16: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 IAA11397 for ; Mon, 27 Oct 2003 08:16:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AE76F-000Bzx-GY for namedroppers-data@psg.com; Mon, 27 Oct 2003 13:07:59 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AE76B-000BzX-In for namedroppers@ops.ietf.org; Mon, 27 Oct 2003 13:07:55 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 0264E4EEC7; Mon, 27 Oct 2003 14:07:55 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 72E8A4EC82 for ; Mon, 27 Oct 2003 14:07:54 +0100 (CET) Received: from x53.ripe.net (x53.ripe.net [193.0.1.53]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id h9RD7sHm030345 for ; Mon, 27 Oct 2003 14:07:54 +0100 Date: Mon, 27 Oct 2003 14:07:54 +0100 (CET) From: Bruce Campbell X-X-Sender: bc@x53.ripe.net To: namedroppers@ops.ietf.org Subject: Re: Draft: non-wildcard bit. In-Reply-To: <20031023224511.20329.qmail@cr.yp.to> Message-ID: References: <20031023224511.20329.qmail@cr.yp.to> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RIPE-Spam-Status: N 0.499998 X-RIPE-Signature: 381efa09e86ca48bdc7b8beeb6a38082 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Last week, various people wrote: > Bruce Campbell writes: > > With all the fuss on the unannounced addition of a wildcard record to the > > .com and .net zones, it is obvious that many applications need a clear and > > reliable method of knowing whether a response is 'real' vix> that's not obvious at all. A lot of the complaints regarding the wildcard deployment can be summed up as 'people do not trust' (verisign). Hence, there is a need for people to have an assurance[1] that they are getting a response that does not point back to a service which is unsuited to their application/customer base/personal preference. ( Or, while wildcards and other synthesis methods are great ways of shooting off feet, one single entity should not be able to make the world dance. ) djb> Exactly which applications are you talking about? I don't think that an 'exact' answer is possible, as the effects of this wildcard deployment has not been understood on all applications. In general terms, I'm presuming that administrators of applications want their applications to either talk only to the expected end host, or fail immediately if a non-existing end host is supplied. They do not want to talk to an arbitary man in the middle in the latter case. ( Or, 'did you mean' is absolutely useless to most services except for those where human eyeballs are involved (web). ) djb> What exactly is the definition of a ``real'' DNS record? In the draft, I've referred to 'real' DNS records as being 'non-synthesised'. In more specific terms, a 'real' DNS record is one which the nameserver software has done a straight read from the zone file/database/etc to find the relevant label, and has not applied any synthesis rules (wildcard processing or something else) to generate the result. ( Or, if someone has manually put it into a file, its real ) djb> What exactly do you want these applications to do with non-``real'' djb> records? 'It depends'. It depends on two things. The specific application in use (eg, user authentication vs random web browsing), and the location in the tree where the wildcard has been detected (*.example.com is ok, *.com.au is not ok). See section 5 of the draft for further commentary on this. In short, for each application, there are good and bad locations for a wildcard, and it is up to each site to define them. -- Bruce Campbell I speak for myself [1] Another way of getting that assurance is to follow the DNSSEC path. -- to unsubscribe send a message to namedroppers-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 Oct 27 09:19: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 JAA14776 for ; Mon, 27 Oct 2003 09:19:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AE89B-000GBT-DQ for namedroppers-data@psg.com; Mon, 27 Oct 2003 14:15:05 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AE895-000GAW-Sg for namedroppers@ops.ietf.org; Mon, 27 Oct 2003 14:14:59 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13866; Mon, 27 Oct 2003 09:14:48 -0500 (EST) Message-Id: <200310271414.JAA13866@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-keyrr-key-signing-flag-11.txt Date: Mon, 27 Oct 2003 09:14:47 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 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 : KEY RR Secure Entry Point Flag Author(s) : O. Kolkman, J. Schlyter, E. Lewis Filename : draft-ietf-dnsext-keyrr-key-signing-flag-11.txt Pages : 10 Date : 2003-10-24 With the Delegation Signer (DS) resource record the concept of a key acting as a secure entry point has been introduced. During key-exchanges with the parent there is a need to differentiate secure entry point keys from other keys in the KEY resource record (RR) set. A flag bit in the KEY RR is defined to indicate that KEY is to be used as a secure entry point. The flag bit is intended to assist in operational procedures to correctly generate DS resource records, or to indicate what keys are intended for static configuration. The flag bit is not to be used in the DNS verification protocol. This document updates RFC 2535 and RFC 3445. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-11.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-keyrr-key-signing-flag-11.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-keyrr-key-signing-flag-11.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-10-24160219.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-keyrr-key-signing-flag-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-24160219.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 Oct 27 09:20: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 JAA14922 for ; Mon, 27 Oct 2003 09:20:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AE8Be-000GNG-OF for namedroppers-data@psg.com; Mon, 27 Oct 2003 14:17:38 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AE8Ba-000GMt-A4 for namedroppers@ops.ietf.org; Mon, 27 Oct 2003 14:17:34 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id h9REFdnl008234 for ; Mon, 27 Oct 2003 09:15:39 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAANYaifq; Mon, 27 Oct 03 09:15:38 -0500 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id h9REGB4u015836; Mon, 27 Oct 2003 09:16:11 -0500 (EST) Date: Mon, 27 Oct 2003 09:16:11 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: David Blacka cc: namedroppers@ops.ietf.org Subject: Re: Wildcard NS and DNSSEC In-Reply-To: <200310241709.05520.davidb@verisignlabs.com> Message-ID: References: <200310241709.05520.davidb@verisignlabs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Additionally, you might be able to see that part of the standard > wildcard validation is missing: proof that (at least) the wildcard > actually exists. Put simply, the parent has no RRSIG on the NS set, and the RRSIG is an integral part of a wildcard proof. > I suppose that it might be possible to handle this by adding another > NSEC record for the wildcard, which may solve some nagging security > issues, but would be a pretty odd special case. Ick. Let's just forbid it and move along. If someone really wants to synthesize delegations, they can sign answers on the fly. To clarify, should a literal * delegation be allowed? (Not a wildcard to be synthesized, just a literal *.example NS?) -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Oct 27 09:21: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 JAA15240 for ; Mon, 27 Oct 2003 09:21:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AE8DN-000GWq-Jf for namedroppers-data@psg.com; Mon, 27 Oct 2003 14:19:25 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AE8DH-000GVx-Ez for namedroppers@ops.ietf.org; Mon, 27 Oct 2003 14:19:19 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14644; Mon, 27 Oct 2003 09:19:07 -0500 (EST) Message-Id: <200310271419.JAA14644@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-dhcid-rr-07.txt Date: Mon, 27 Oct 2003 09:19:07 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 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 : A DNS RR for encoding DHCP information (DHCID RR) Author(s) : M. Stapp, T. Lemon, A. Gustafsson Filename : draft-ietf-dnsext-dhcid-rr-07.txt Pages : 10 Date : 2003-10-24 It is possible for multiple DHCP clients to attempt to update the same DNS FQDN as they obtain DHCP leases. Whether the DHCP server or the clients themselves perform the DNS updates, conflicts can arise. To resolve such conflicts, 'Resolution of DNS Name Conflicts'[1] proposes storing client identifiers in the DNS to unambiguously associate domain names with the DHCP clients to which they refer. This memo defines a distinct RR type for this purpose for use by DHCP clients and servers, the 'DHCID' RR. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dhcid-rr-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dhcid-rr-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dhcid-rr-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-24165651.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dhcid-rr-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dhcid-rr-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-24165651.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 Oct 27 09:28: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 JAA15604 for ; Mon, 27 Oct 2003 09:28:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AE8Hv-000Gz9-UH for namedroppers-data@psg.com; Mon, 27 Oct 2003 14:24:07 +0000 Received: from [131.174.93.58] (helo=hermes.uci.kun.nl) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AE8Ho-000GyN-2B for namedroppers@ops.ietf.org; Mon, 27 Oct 2003 14:24:00 +0000 Received: from elektron.atoom.net (vhe-530008.sshn.net [195.169.222.38]) by hermes.uci.kun.nl (PMDF V6.1 #30689) with ESMTP id <0HNF0002H6OBCW@hermes.uci.kun.nl> for namedroppers@ops.ietf.org; Mon, 27 Oct 2003 15:24:11 +0100 (MET) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.10/8.12.10/Debian-4) with ESMTP id h9REO4kw015192 for ; Mon, 27 Oct 2003 15:24:04 +0100 Received: (from miekg@localhost) by elektron.atoom.net (8.12.10/8.12.10/Debian-4) id h9REO4tH015191 for namedroppers@ops.ietf.org; Mon, 27 Oct 2003 15:24:04 +0100 Date: Mon, 27 Oct 2003 15:24:04 +0100 From: Miek Gieben Subject: Re: Wildcard NS and DNSSEC In-reply-to: To: namedroppers@ops.ietf.org Mail-followup-to: namedroppers@ops.ietf.org Message-id: <20031027142404.GB15077@atoom.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new References: <200310241709.05520.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 27 Oct, @15:16, Samuel wrote in "Re: Wildcard NS and DNSSEC ..."] > > Additionally, you might be able to see that part of the standard > > wildcard validation is missing: proof that (at least) the wildcard > > actually exists. > > Put simply, the parent has no RRSIG on the NS set, and the RRSIG is an > integral part of a wildcard proof. > > > I suppose that it might be possible to handle this by adding another > > NSEC record for the wildcard, which may solve some nagging security > > issues, but would be a pretty odd special case. > > Ick. Let's just forbid it and move along. If someone really wants to I'm in favor of doing that also, grtz Miek -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Oct 27 09:44: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 JAA16494 for ; Mon, 27 Oct 2003 09:44:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AE8ZK-000IVL-3R for namedroppers-data@psg.com; Mon, 27 Oct 2003 14:42:06 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AE8ZH-000IUv-9J for namedroppers@ops.ietf.org; Mon, 27 Oct 2003 14:42:03 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 1A99613966 for ; Mon, 27 Oct 2003 14:42:03 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Draft: non-wildcard bit. In-Reply-To: Message from Bruce Campbell of "Mon, 27 Oct 2003 14:07:54 +0100." X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 27 Oct 2003 14:42:03 +0000 Message-Id: <20031027144203.1A99613966@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > > With all the fuss on the unannounced addition of a wildcard record > > > to the .com and .net zones, it is obvious that many applications > > > need a clear and reliable method of knowing whether a response is > > > 'real' > > vix> that's not obvious at all. about twice a year since 1994 i have begun planning an rfc called "what the dns is not". the opening paragraph always has these words: "DNS is a distributed, hierarchical, reliable, autonomous database. DNS deals in facts, not values, and data carried in the DNS are facts, not opinions." but then i always calm down before i can get the full rant figured, which would include diatribes against DNS NAT and "middleboxes" of all kinds, especially DNS-based load balancing appliances. > A lot of the complaints regarding the wildcard deployment can be > summed up as 'people do not trust' (verisign). Hence, there is a need > for people to have an assurance[1] that they are getting a response > that does not point back to a service which is unsuited to their > application/customer base/personal preference. if the world doesn't trust verisign then the world ought to negotiate a better contract or find a different registry. it's bad enough that BIND now has a feature which allows client-side content editing (delegation-only) but let's not make our situation even worse by complicating the protocol itself to cope with what's actually a layer 9 problem. > In short, for each application, there are good and bad locations for a > wildcard, and it is up to each site to define them. an application should not behave differently because synthesis was used, even if a more robust protocol would in fact move the act of synthesis into the client-side for a number of unrelated but perfectly valid reasons. -- to unsubscribe send a message to namedroppers-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 Oct 27 09:47:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16730 for ; Mon, 27 Oct 2003 09:47:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AE8c3-000Igp-L7 for namedroppers-data@psg.com; Mon, 27 Oct 2003 14:44:55 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AE8c0-000IgQ-ME for namedroppers@ops.ietf.org; Mon, 27 Oct 2003 14:44:52 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id h9REgvbL009220 for ; Mon, 27 Oct 2003 09:42:57 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA1Oaqas; Mon, 27 Oct 03 09:42:56 -0500 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id h9REhTZM017093; Mon, 27 Oct 2003 09:43:29 -0500 (EST) Date: Mon, 27 Oct 2003 14:43:29 +0000 (Africa/Tunis) From: Samuel Weiler X-X-Sender: weiler@filbert To: Bruce Campbell cc: namedroppers@ops.ietf.org Subject: Re: Draft: non-wildcard bit. In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > it is obvious that many applications need a clear and reliable > method of knowing whether a response ... has been synthesised. If zone owners really want to mark synthesized records, the protocol already has a technique for doing that -- it's called signing the zone. I'm not inclined to spend more time developing another one. If there's really demand for flagging synthesized answers, then perhaps we should put forth a document requiring that any zone with wildcards be signed. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Oct 27 10:56:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21416 for ; Mon, 27 Oct 2003 10:56:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AE9ez-000My7-0P for namedroppers-data@psg.com; Mon, 27 Oct 2003 15:52:01 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AE9eo-000Mwi-3F for namedroppers@ops.ietf.org; Mon, 27 Oct 2003 15:51:50 +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 h9RFpM0T002805 for ; Mon, 27 Oct 2003 10:51:22 -0500 (EST) Message-ID: <045b01c39ca2$2d3292f0$b9370681@barnacle> From: "Scott Rose" To: Subject: comment on "DNSSEC Operational Practices" Term Date: Mon, 27 Oct 2003 10:51:25 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-1.5 required=5.0 tests=BAYES_01 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit There is one disagreement between the DNSSEC Operational Practices draft and the DNSSECbis Protocol draft. That is how to classify and handle "BAD" RR sets in responses. The Appendix in the operational draft states that "BAD data is not cached." However, the proto doc states that a resolver may want to have a "BAD" data cache for various reasons. Under normal circumstances, a resolver will not want to cache proven BAD data (however you want to define BAD), but there are cases where it might be useful for the resolver to have a BAD data cache. The punchline: Everyone read the protocol draft and see if you agree with the current wording on sections 3 and 4 regarding caching nameservers and resolvers (please). And read the operational practices draft (please. It is another needed draft IMHO). 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 Mon Oct 27 15:37: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 PAA08108 for ; Mon, 27 Oct 2003 15:37:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEDyy-000Csd-Ie for namedroppers-data@psg.com; Mon, 27 Oct 2003 20:28:56 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEDys-000CsK-Kq for namedroppers@ops.ietf.org; Mon, 27 Oct 2003 20:28:52 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07445; Mon, 27 Oct 2003 15:28:38 -0500 (EST) Message-Id: <200310272028.PAA07445@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-protocol-03.txt Date: Mon, 27 Oct 2003 15:28:37 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Protocol Modifications for the DNS Security Extensions Author(s) : R. Arends Filename : draft-ietf-dnsext-dnssec-protocol-03.txt Pages : 55 Date : 2003-10-27 This document is part of a family of documents which describes the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications which add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-protocol-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-protocol-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-protocol-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-10-27154546.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-protocol-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-protocol-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-27154546.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 Oct 27 15:41: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 PAA08610 for ; Mon, 27 Oct 2003 15:41:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEE4g-000DCz-4r for namedroppers-data@psg.com; Mon, 27 Oct 2003 20:34:50 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEE4c-000DCk-MA for namedroppers@ops.ietf.org; Mon, 27 Oct 2003 20:34:46 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07871; Mon, 27 Oct 2003 15:34:34 -0500 (EST) Message-Id: <200310272034.PAA07871@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-records-05.txt Date: Mon, 27 Oct 2003 15:34:34 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Resource Records for DNS Security Extensions Author(s) : R. Arends Filename : draft-ietf-dnsext-dnssec-records-05.txt Pages : 36 Date : 2003-10-27 This document is part of a family of documents that describes the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existance (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-records-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-records-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-records-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-27155331.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-records-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-records-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-27155331.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 Oct 27 15:44: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 PAA08888 for ; Mon, 27 Oct 2003 15:44:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEE72-000DPD-CK for namedroppers-data@psg.com; Mon, 27 Oct 2003 20:37:16 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEE6r-000DNr-9P for namedroppers@ops.ietf.org; Mon, 27 Oct 2003 20:37:05 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08088; Mon, 27 Oct 2003 15:36:53 -0500 (EST) Message-Id: <200310272036.PAA08088@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dns-threats-04.txt Date: Mon, 27 Oct 2003 15:36:53 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Threat Analysis Of The Domain Name System Author(s) : D. Atkins, R. Austein Filename : draft-ietf-dnsext-dns-threats-04.txt Pages : 15 Date : 2003-10-27 Although the DNS Security Extensions (DNSSEC) have been under development for most of the last decade, the IETF has never written down the specific set of threats against which DNSSEC is designed to protect. Among other drawbacks, this cart-before-the-horse situation has made it difficult to determine whether DNSSEC meets its design goals, since its design goals are not well specified. This note attempts to document some of the known threats to the DNS, and, in doing so, attempts to measure to what extent (if any) DNSSEC is a useful tool in defending against these threats. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-threats-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-dns-threats-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-dns-threats-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-10-27155827.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dns-threats-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dns-threats-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-27155827.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 Oct 27 16:24:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08107 for ; Mon, 27 Oct 2003 15:37:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEDyo-000Cs0-F1 for namedroppers-data@psg.com; Mon, 27 Oct 2003 20:28:46 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEDyd-000CrL-1f for namedroppers@ops.ietf.org; Mon, 27 Oct 2003 20:28:35 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07324; Mon, 27 Oct 2003 15:28:23 -0500 (EST) Message-Id: <200310272028.PAA07324@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-intro-07.txt Date: Mon, 27 Oct 2003 15:28:23 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNS Security Introduction and Requirements Author(s) : R. Arends, R. Austein, D. Massey, M. Larson, S. Rose Filename : draft-ietf-dnsext-dnssec-intro-07.txt Pages : 24 Date : 2003-10-27 The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions, and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the group of documents that collectively describe DNSSEC. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-intro-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-intro-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-intro-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-27154530.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-intro-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-intro-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-27154530.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 Oct 27 17:15:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20292 for ; Mon, 27 Oct 2003 17:15:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEFXv-000IBE-BI for namedroppers-data@psg.com; Mon, 27 Oct 2003 22:09:07 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEFXo-000IAS-FK for namedroppers@ops.ietf.org; Mon, 27 Oct 2003 22:09:01 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18816; Mon, 27 Oct 2003 17:08:47 -0500 (EST) Message-Id: <200310272208.RAA18816@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-keyrr-key-signing-flag-11.txt Date: Mon, 27 Oct 2003 17:08:47 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 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 : KEY RR Secure Entry Point Flag Author(s) : O. Kolkman, J. Schlyter, E. Lewis Filename : draft-ietf-dnsext-keyrr-key-signing-flag-11.txt Pages : 10 Date : 2003-10-24 With the Delegation Signer (DS) resource record the concept of a key acting as a secure entry point has been introduced. During key-exchanges with the parent there is a need to differentiate secure entry point keys from other keys in the KEY resource record (RR) set. A flag bit in the KEY RR is defined to indicate that KEY is to be used as a secure entry point. The flag bit is intended to assist in operational procedures to correctly generate DS resource records, or to indicate what keys are intended for static configuration. The flag bit is not to be used in the DNS verification protocol. This document updates RFC 2535 and RFC 3445. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-11.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-keyrr-key-signing-flag-11.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-keyrr-key-signing-flag-11.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-10-27170857.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-keyrr-key-signing-flag-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-27170857.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 Oct 27 17:15: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 RAA20334 for ; Mon, 27 Oct 2003 17:15:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEFXq-000IAp-Kc for namedroppers-data@psg.com; Mon, 27 Oct 2003 22:09:02 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEFXk-000IA8-1b for namedroppers@ops.ietf.org; Mon, 27 Oct 2003 22:08:56 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18790; Mon, 27 Oct 2003 17:08:42 -0500 (EST) Message-Id: <200310272208.RAA18790@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-dhcid-rr-07.txt Date: Mon, 27 Oct 2003 17:08:41 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 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 : A DNS RR for encoding DHCP information (DHCID RR) Author(s) : M. Stapp, T. Lemon, A. Gustafsson Filename : draft-ietf-dnsext-dhcid-rr-07.txt Pages : 10 Date : 2003-10-24 It is possible for multiple DHCP clients to attempt to update the same DNS FQDN as they obtain DHCP leases. Whether the DHCP server or the clients themselves perform the DNS updates, conflicts can arise. To resolve such conflicts, 'Resolution of DNS Name Conflicts'[1] proposes storing client identifiers in the DNS to unambiguously associate domain names with the DHCP clients to which they refer. This memo defines a distinct RR type for this purpose for use by DHCP clients and servers, the 'DHCID' RR. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dhcid-rr-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dhcid-rr-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dhcid-rr-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-27170849.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dhcid-rr-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dhcid-rr-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-27170849.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Oct 28 03:57: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 DAA10115 for ; Tue, 28 Oct 2003 03:57:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEPaK-000Mfr-EN for namedroppers-data@psg.com; Tue, 28 Oct 2003 08:52:16 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEPaH-000MfR-Br for namedroppers@ops.ietf.org; Tue, 28 Oct 2003 08:52:13 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 414F14FF66; Tue, 28 Oct 2003 09:49:05 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 8DDBD4FF68; Tue, 28 Oct 2003 09:49:04 +0100 (CET) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id h9S8n4Hl031843; Tue, 28 Oct 2003 09:49:04 +0100 Date: Tue, 28 Oct 2003 09:49:04 +0100 From: "Olaf M. Kolkman" To: "Scott Rose" Cc: namedroppers@ops.ietf.org Subject: Re: comment on "DNSSEC Operational Practices" Term Message-Id: <20031028094904.46d73ba8.olaf@ripe.net> In-Reply-To: <045b01c39ca2$2d3292f0$b9370681@barnacle> References: <045b01c39ca2$2d3292f0$b9370681@barnacle> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.6 (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.000131 X-RIPE-Signature: 9397e894ee07f4b1842fbc49d519a502 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 27 Oct 2003 10:51:25 -0500 "Scott Rose" wrote: > The punchline: Everyone read the protocol draft and see if you agree with > the current wording on sections 3 and 4 regarding caching nameservers and > resolvers (please). And read the operational practices draft (please. It is > another needed draft IMHO). FYI that draft is: draft-ietf-dnsop-dnssec-operational-practices-00.txt It is under review in DNSOP. The practices document will need to be in sync with whatever proto sais, not the other way around. -- 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 Tue Oct 28 10: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 KAA27246 for ; Tue, 28 Oct 2003 10:02:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEVEs-000F1l-9F for namedroppers-data@psg.com; Tue, 28 Oct 2003 14:54:30 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEVEm-000F15-Rj for namedroppers@ops.ietf.org; Tue, 28 Oct 2003 14:54:25 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 223954FE93; Tue, 28 Oct 2003 15:54:24 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 69FD14FD1A for ; Tue, 28 Oct 2003 15:54:23 +0100 (CET) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id h9SEsNHl032430 for ; Tue, 28 Oct 2003 15:54:23 +0100 Date: Tue, 28 Oct 2003 15:54:22 +0100 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: DNSSEC nearing last call. Message-Id: <20031028155422.42df3f05.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.6 (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.499797 X-RIPE-Signature: 9d84b8fff036c3c7412df0ed156d6c93 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit namedroppers, Some time ago I mailed a list with open questions to the list (http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01532.html). That list of questions clarified what would be taken as consensus position of the working group if no further discussion took place. I went to the list and marked a large number of questions as resolved because consensus was reached on them; For those questions for which I think their may be confusion on why consensus was called I added a small explanation. One question (Q15) is still open, but has text in the current document set that reflects where I think consensus is going. If no further comments are received on this question it will be marked as resolved shortly after IETF58. Since the intro and records document have been stable for a while I think they are ready for a last call. I'll wait for some feedback on this mail but plan to start a WG Last Call on 'intro' and 'records' before the IETF. The proto document may have some minor nits to be fixed but is good for thorough review. We will decide if proto 03 is ready for last call during IETF58. Comments about the text (spelling, style) can be mailed to dnssec-editors@east.isi.edu. Comments about protocol need to go to the list. !!!!!!!!! Credit goes to the dnssec editors team. !!!!!!!!!!!! For clarity the current document-set is: draft-ietf-dnsext-dnssec-intro-07.txt draft-ietf-dnsext-dnssec-records-05.txt draft-ietf-dnsext-dnssec-protocol-03.txt --Olaf Kolkman DNSEXT Co-chair The list of questions. Q1 - resolved Q2 - resolved Q3 - resolved Q4 - mistake in numbering, there is no Q4 Q5 - resolved (Handled in TCR draft) 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. resolved, for completeness, the new text in -proto draft describes how a caching resolver can have a BAD data cache, and when it is appropriate to use it. Q7 - resolved Q8 - resolved Q9 - resolved Q10 - Since there was no response to my message in which I requested alternative text (http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01851.html) this item is resolved and the text remained as in proto-2 Q11 - resolved DNSKEY RRs allowed at delegation points. After rereading the original threat on this issue we decided that the working group consensus is that DNSKEY RRs not allowed at delegation points. This is reflected in the last line of proto section 2.1. Q12 - resolved Q13 - resolved The silence on the list has been interpreted as consensus for keeping the advice that caching should be atomic (i.e. entire response keyed to a single ) is discussed in protocol draft (as a SHOULD). Q14 - resolved Q15 - Open Should a security-aware stub resolver be allowed to set the CD bit on queries or should this behavior be prohibited? The -proto document now reflects: *It should remain SHOULD NOT. security risk given to state why it is a bad idea for general operation* This will be taken as the consensus position if no further comments are received by the end of IETF58. Q16 - resolved What should a recursive nameserver do if query has flags CD=1, and DO=0? Suggest Text suggested in the original question (http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01559.html). suggested a change in protocol. Working group concensus is against this. In proto the two bits are treated separately and their behavior is 'orthogonal'. Q17 - resolved (the TCR document handles this) -- 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 Tue Oct 28 10:40: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 KAA00890 for ; Tue, 28 Oct 2003 10:40:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEVtn-000I4k-A2 for namedroppers-data@psg.com; Tue, 28 Oct 2003 15:36:47 +0000 Received: from [3ffe:805::230:48ff:fe22:6a53] (helo=karoshi.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEVtj-000I4G-54 for namedroppers@ops.ietf.org; Tue, 28 Oct 2003 15:36:43 +0000 Received: (from bmanning@localhost) by karoshi.com (8.11.6/8.11.6 - yeah right) id h9SFadm27709; Tue, 28 Oct 2003 07:36:39 -0800 From: bmanning@karoshi.com Message-Id: <200310281536.h9SFadm27709@karoshi.com> Subject: Re: comment on "DNSSEC Operational Practices" Term To: scottr@nist.gov (Scott Rose) Date: Tue, 28 Oct 2003 07:36:39 -0800 (PST) Cc: namedroppers@ops.ietf.org In-Reply-To: <045b01c39ca2$2d3292f0$b9370681@barnacle> from "Scott Rose" at Oct 27, 2003 10:51:25 AM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > There is one disagreement between the DNSSEC Operational Practices draft and > the DNSSECbis Protocol draft. That is how to classify and handle "BAD" RR > sets in responses. > > The Appendix in the operational draft states that "BAD data is not cached." > However, the proto doc states that a resolver may want to have a "BAD" data > cache for various reasons. Under normal circumstances, a resolver will not > want to cache proven BAD data (however you want to define BAD), but there > are cases where it might be useful for the resolver to have a BAD data > cache. the protocol draft has it right. --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Oct 28 10:51: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 KAA02044 for ; Tue, 28 Oct 2003 10:51:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEW4H-000Iny-He for namedroppers-data@psg.com; Tue, 28 Oct 2003 15:47:37 +0000 Received: from [131.174.93.58] (helo=hermes.uci.kun.nl) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEW4D-000InS-3G for namedroppers@ops.ietf.org; Tue, 28 Oct 2003 15:47:33 +0000 Received: from elektron.atoom.net (vhe-530008.sshn.net [195.169.222.38]) by hermes.uci.kun.nl (PMDF V6.1 #30689) with ESMTP id <0HNH00B6X57IZQ@hermes.uci.kun.nl> for namedroppers@ops.ietf.org; Tue, 28 Oct 2003 16:47:43 +0100 (MET) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.10/8.12.10/Debian-4) with ESMTP id h9SFlgRb000798; Tue, 28 Oct 2003 16:47:42 +0100 Received: (from miekg@localhost) by elektron.atoom.net (8.12.10/8.12.10/Debian-4) id h9SFlgef000797; Tue, 28 Oct 2003 16:47:42 +0100 Date: Tue, 28 Oct 2003 16:47:42 +0100 From: Miek Gieben Subject: Re: comment on "DNSSEC Operational Practices" Term In-reply-to: <200310281536.h9SFadm27709@karoshi.com> To: bmanning@karoshi.com Cc: Scott Rose , namedroppers@ops.ietf.org Mail-followup-to: bmanning@karoshi.com, Scott Rose , namedroppers@ops.ietf.org Message-id: <20031028154742.GB770@atoom.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new References: <045b01c39ca2$2d3292f0$b9370681@barnacle> <200310281536.h9SFadm27709@karoshi.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 28 Oct, @16:36, bmanning wrote in "Re: comment on "DNSSEC Operati ..."] > > > > There is one disagreement between the DNSSEC Operational Practices draft and > > the DNSSECbis Protocol draft. That is how to classify and handle "BAD" RR > > sets in responses. > > > > The Appendix in the operational draft states that "BAD data is not cached." > > However, the proto doc states that a resolver may want to have a "BAD" data > > cache for various reasons. Under normal circumstances, a resolver will not > > want to cache proven BAD data (however you want to define BAD), but there > > are cases where it might be useful for the resolver to have a BAD data > > cache. > > the protocol draft has it right. ok, to stop this from lingering on, I changed to ops-draft already. Change wil be in 01. 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 Tue Oct 28 14:08: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 OAA17141 for ; Tue, 28 Oct 2003 14:08:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEZ79-0004FP-9n for namedroppers-data@psg.com; Tue, 28 Oct 2003 19:02:47 +0000 Received: from [65.201.175.62] (helo=cliffie.verisignlabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEZ75-0004Ez-4F for namedroppers@ops.ietf.org; Tue, 28 Oct 2003 19:02:43 +0000 Received: from pinion.admin.cto.netsol.com ([::ffff:172.25.170.10]) (AUTH: LOGIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by cliffie.verisignlabs.com with esmtp; Tue, 28 Oct 2003 14:02:42 -0500 From: David Blacka Organization: Verisign, Inc. To: namedroppers@ops.ietf.org Subject: Large typecodes and DNSSEC Date: Tue, 28 Oct 2003 14:02:41 -0500 User-Agent: KMail/1.5.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310281402.41950.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Currently the NSEC record (nee NXT) can only support typecodes up to 127 (dnssec-records-05, section 4.1.2). However, the type field in DNS is actually 16 bits long. While this situation has been true for as long as I've been looking at DNSSEC, and presumably since its inception, this is an issue that seems to have been totally ignored by this WG. I would like to know: * How can we consider DNSSEC complete while it ignores 9 of the 16 bits in the typecode field? * What happens when (or if), after this current DNSSEC spec is widely deployed, we want to define typecode 128? Do we do another typecode rollover? Move the DO bit? add another EDNS flag? In the current form, I feel that DNSSEC will artificially constrain DNS typecodes to no larger than 127, simply because existing implementations of DNSSEC-aware DNS software will not be able to handler larger typecodes, and we all know how much of a PITA getting everyone to roll out new DNS software is. * If the intention is the constrain the typecode field to 7 effective bits, then please explain why. Is the intent to reserve the remaining 65407 types for psuedo types? * Why haven't we already defined the alternate format of the NSEC typecode field? Are we waiting for some future breakthrough that will allow us to handle these giant numbers between 128 and 65535? This WG has spent a fair amount of time on other issues of forward compatibility, but why not this? -- David Blacka Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Oct 28 15:44: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 PAA25308 for ; Tue, 28 Oct 2003 15:44:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEabY-0009LS-RP for namedroppers-data@psg.com; Tue, 28 Oct 2003 20:38:16 +0000 Received: from [2002:425c:4242:0:250:daff:fe82:1c39] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEabU-0009Ks-EJ for namedroppers@ops.ietf.org; Tue, 28 Oct 2003 20:38:12 +0000 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 7A1BB18E2 for ; Tue, 28 Oct 2003 15:38:10 -0500 (EST) Date: Tue, 28 Oct 2003 15:38:09 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Large typecodes and DNSSEC In-Reply-To: <200310281402.41950.davidb@verisignlabs.com> References: <200310281402.41950.davidb@verisignlabs.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: <20031028203810.7A1BB18E2@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Tue, 28 Oct 2003 14:02:41 -0500, David Blacka wrote: >... > * What happens when (or if), after this current DNSSEC spec is > widely deployed, we want to define typecode 128? Do we do another > typecode rollover? Move the DO bit? add another EDNS flag? According to RFC 2335, which DNSSECbis hasn't changed in this regard, we set bit zero of the typecode "bitvector" to one. I put "bitvector" in quotes because I strongly suspect that the actual representation at that point would not be a bitvector. I don't much like this either, but the WG has not chosen to rip the covers off of this particular piece of 2535. > In the current form, I feel that DNSSEC will artificially constrain > DNS typecodes to no larger than 127, simply because existing > implementations of DNSSEC-aware DNS software will not be able to > handler larger typecodes, and we all know how much of a PITA getting > everyone to roll out new DNS software is. Fair point. > * If the intention is the constrain the typecode field to 7 > effective bits, then please explain why. Is the intent to reserve > the remaining 65407 types for psuedo types? I don't think there was any such intention. For historical reasons (having to do with the fact that DNS types and classes were only 8-bit values in the earliest DNS specs), the typecodes allocated so far all happen to fit the bitvector encoding hack proposed in the original DNSSEC specs. The WG chose to go for this hack. > * Why haven't we already defined the alternate format of the NSEC > typecode field? Are we waiting for some future breakthrough that > will allow us to handle these giant numbers between 128 and 65535? Ok, fair enough. With the understanding that I am -not- taking a position on whether the WG should do anything about this at this time, here's a proposed encoding for you to use as a strawcritter. - Bit zero of "bitvector" is a flag bit as described in RFC 2535 and DNSSECbis drafts - Remainder of first octet of "bitvector" is a version number for this encoding format (unless somebody can think of a more important use for those seven bits). This email message defines format zero (ie, all seven of those bits must be zero). - Rest of "bitvector" is an ordered list of 16-bit bigendian unsigned integers. Each integer represents one type present at the owner name. The list must be sorted into ascending order (not strictly necessary, but might simplify some operations and is easy to do). So the "bitvector" would be 2*N+1 octets for a name with N distinct RR types. Not a particularly compact encoding. If the WG decides that it's interested in this subject, somebody should do the numbers to see what this does to typical response sizes, but recall that DNSSECbis requires EDNS0, so we're not limited to 512-octet packets. -- to unsubscribe send a message to namedroppers-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 Oct 28 16:54: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 QAA28506 for ; Tue, 28 Oct 2003 16:54:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEbgr-000D0y-D2 for namedroppers-data@psg.com; Tue, 28 Oct 2003 21:47:49 +0000 Received: from [65.201.175.62] (helo=cliffie.verisignlabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEbgo-000D0j-Ft for namedroppers@ops.ietf.org; Tue, 28 Oct 2003 21:47:46 +0000 Received: from pinion.admin.cto.netsol.com ([::ffff:172.25.170.10]) (AUTH: LOGIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by cliffie.verisignlabs.com with esmtp; Tue, 28 Oct 2003 16:47:45 -0500 From: David Blacka Organization: Verisign, Inc. To: namedroppers@ops.ietf.org Subject: Re: Large typecodes and DNSSEC Date: Tue, 28 Oct 2003 16:47:45 -0500 User-Agent: KMail/1.5.3 References: <200310281402.41950.davidb@verisignlabs.com> <20031028203810.7A1BB18E2@thrintun.hactrn.net> In-Reply-To: <20031028203810.7A1BB18E2@thrintun.hactrn.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310281647.45423.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday 28 October 2003 03:38 pm, Rob Austein wrote: > I don't much like this either, but the WG has not chosen to rip the > covers off of this particular piece of 2535. I guess I'm in the position of arguing that it needs to. > I don't think there was any such intention. For historical reasons > (having to do with the fact that DNS types and classes were only 8-bit > values in the earliest DNS specs), the typecodes allocated so far all > happen to fit the bitvector encoding hack proposed in the original > DNSSEC specs. The WG chose to go for this hack. At this point, having read through long threads discussion what we might have to do if RSA is broken, I am at a loss to understand why this issue hasn't been considered important. Actually, I am at a loss to understand why it wasn't an issue in the first place. It isn't like types where only 8 bits then. > > * Why haven't we already defined the alternate format of the NSEC > > typecode field? Are we waiting for some future breakthrough that > > will allow us to handle these giant numbers between 128 and 65535? > > Ok, fair enough. With the understanding that I am -not- taking a > position on whether the WG should do anything about this at this time, > here's a proposed encoding for you to use as a strawcritter. Why not take a position? I'll take a position: DNSSEC is not complete without the ability to handle types > 127. Just because there aren't any now is no excuse. > - Remainder of first octet of "bitvector" is a version number for this > encoding format (unless somebody can think of a more important use > for those seven bits). This email message defines format zero (ie, > all seven of those bits must be zero). If you define format version, it will either be useless or near-useless due to the difficulty in globally updating DNS software. Unless we go further and define good behavior for when a validator sees an NSEC format it doesn't recognize. But I'm not exactly certain why we would need multiple formats anyway. It isn't like we don't understand this namespace. Here is an alternative strawcritter: - use the remaining 7 bits in the first octet as a count of single-byte typecodes, called N. The next N octets are an ordered list of 8-bit integers representing typecodes <= 255. The remaining RDATA is an ordered list of 16-bit big-endian unsigned integers, each representing one type present. -- David Blacka Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Oct 28 16:56: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 QAA28656 for ; Tue, 28 Oct 2003 16:56:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEbkA-000DCc-TS for namedroppers-data@psg.com; Tue, 28 Oct 2003 21:51:14 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEbk9-000DCL-2c for namedroppers@ops.ietf.org; Tue, 28 Oct 2003 21:51:13 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id DD1351394C for ; Tue, 28 Oct 2003 21:51:12 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Large typecodes and DNSSEC In-Reply-To: Message from Rob Austein of "Tue, 28 Oct 2003 15:38:09 EST." <20031028203810.7A1BB18E2@thrintun.hactrn.net> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 28 Oct 2003 21:51:12 +0000 Message-Id: <20031028215112.DD1351394C@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I don't much like this either, but the WG has not chosen to rip the > covers off of this particular piece of 2535. and yet, can serious deployment (burning of roms containing the software) begin without a defined solution for typecodes above 127? > Ok, fair enough. With the understanding that I am -not- taking a > position on whether the WG should do anything about this at this time, > here's a proposed encoding for you to use as a strawcritter. michael graff and i here at isc have also experimented with several encodings that would support typecodes above 127. is it time for a bake-off? perhaps so, if olaf is rattling the WGLC sabre... -- to unsubscribe send a message to namedroppers-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 Oct 28 17:12: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 RAA00627 for ; Tue, 28 Oct 2003 17:12:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEbzb-000E51-J6 for namedroppers-data@psg.com; Tue, 28 Oct 2003 22:07:11 +0000 Received: from [2002:425c:4242:0:250:daff:fe82:1c39] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEbzY-000E4X-Bb for namedroppers@ops.ietf.org; Tue, 28 Oct 2003 22:07:08 +0000 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 0A54E18E1 for ; Tue, 28 Oct 2003 17:07:07 -0500 (EST) Date: Tue, 28 Oct 2003 17:07:07 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Large typecodes and DNSSEC In-Reply-To: <200310281647.45423.davidb@verisignlabs.com> References: <200310281402.41950.davidb@verisignlabs.com> <20031028203810.7A1BB18E2@thrintun.hactrn.net> <200310281647.45423.davidb@verisignlabs.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: <20031028220707.0A54E18E1@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Tue, 28 Oct 2003 16:47:45 -0500, David Blacka wrote: > > Why not take a position? Waiting to hear what other people have to say, for which reason I'll shut up on this subject for a while after this message. > Here is an alternative strawcritter: > > - use the remaining 7 bits in the first octet as a count of single-byte > typecodes, called N. The next N octets are an ordered list of 8-bit > integers representing typecodes <= 255. The remaining RDATA is an ordered > list of 16-bit big-endian unsigned integers, each representing one type > present. Your strawcritter is better than mine. -- to unsubscribe send a message to namedroppers-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 Oct 28 17:15: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 RAA00966 for ; Tue, 28 Oct 2003 17:15:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEc37-000EMR-2X for namedroppers-data@psg.com; Tue, 28 Oct 2003 22:10:49 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEc35-000EM4-3N for namedroppers@ops.ietf.org; Tue, 28 Oct 2003 22:10:47 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id EC0051394B for ; Tue, 28 Oct 2003 22:10:46 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Large typecodes and DNSSEC In-Reply-To: Message from David Blacka of "Tue, 28 Oct 2003 16:47:45 EST." <200310281647.45423.davidb@verisignlabs.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 28 Oct 2003 22:10:46 +0000 Message-Id: <20031028221046.EC0051394B@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > I don't much like this either, but the WG has not chosen to rip the > > covers off of this particular piece of 2535. > > I guess I'm in the position of arguing that it needs to. i agree. and just to make sure my position is unambiguously clear: > ... I'll take a position: DNSSEC is not complete without the ability > to handle types > 127. Just because there aren't any now is no excuse. i agree with this too. > Here is an alternative strawcritter: sounds like a bakeoff is in order. mister graff, you may fire when ready. -- to unsubscribe send a message to namedroppers-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 Oct 28 18:06: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 SAA05113 for ; Tue, 28 Oct 2003 18:06:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEcmR-000GnB-Sc for namedroppers-data@psg.com; Tue, 28 Oct 2003 22:57:39 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEcmN-000Gmy-9Y for namedroppers@ops.ietf.org; Tue, 28 Oct 2003 22:57:35 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id h9SMtdqV009530 for ; Tue, 28 Oct 2003 17:55:39 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAoWaiNs; Tue, 28 Oct 03 17:55:38 -0500 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id h9SMuDm0005923; Tue, 28 Oct 2003 17:56:13 -0500 (EST) Date: Tue, 28 Oct 2003 23:56:12 +0100 (CET) From: Samuel Weiler X-X-Sender: weiler@filbert To: David Blacka cc: namedroppers@ops.ietf.org Subject: Re: Large typecodes and DNSSEC In-Reply-To: <200310281647.45423.davidb@verisignlabs.com> Message-ID: References: <200310281402.41950.davidb@verisignlabs.com> <20031028203810.7A1BB18E2@thrintun.hactrn.net> <200310281647.45423.davidb@verisignlabs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk NOOOOOOOOOO!!!!!!! > ... having read through long threads discussion what we might > have to do if RSA is broken, ... We tackled "having space to deal with RSA being broken" even though we don't have good alternatives to replace it. We needed to make sure that "safe" failure modes exist and that phase-in of a new algorithm would be possible. In this case, we already have a provision for dealing with bigger typecodes. We don't know how we'll deal with them, but at least the provision is there. > Unless we go further and define good behavior for when a validator > sees an NSEC format it doesn't recognize. Yup -- we need to do that. How's this: If you see the zero bit set AND THE NSEC VALIDATES, treat this name as unsecured unless you have evidence to the contrary (ie. a validated RRset)? Treating the entire name as non-existing is too harsh. This means that a name with that bit set can have its RRs spoofed away, but at least bad data can't be substituted. Paul asks: > can serious deployment (burning of roms containing the software) > begin without a defined solution for typecodes above 127? I think we can get away with putting this off -- we have the extension mechanism in place and can deal with it later. With the current typecode burn rate, the current format will outlast a resolver replacement cycle. Maybe two. But if folks really insist, let's get it done quickly. I'm sure we can settle on a format. Can we get multiple interoperable implementations out the door before Minneapolis? Seriously -- I want to get this rev out. I suggest that the chairs decline the change unless we have two pieces of interoperable code within some short amount of time, perferably pre-MSP. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Oct 28 18:56:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08792 for ; Tue, 28 Oct 2003 18:56:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEdZg-000JIV-8I for namedroppers-data@psg.com; Tue, 28 Oct 2003 23:48:32 +0000 Received: from [65.201.175.62] (helo=cliffie.verisignlabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEdZb-000JI6-7z for namedroppers@ops.ietf.org; Tue, 28 Oct 2003 23:48:27 +0000 Received: from pinion.admin.cto.netsol.com ([::ffff:172.25.170.10]) (AUTH: LOGIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by cliffie.verisignlabs.com with esmtp; Tue, 28 Oct 2003 18:48:26 -0500 From: David Blacka Organization: Verisign, Inc. To: namedroppers@ops.ietf.org Subject: Re: Large typecodes and DNSSEC Date: Tue, 28 Oct 2003 18:48:26 -0500 User-Agent: KMail/1.5.3 References: <200310281402.41950.davidb@verisignlabs.com> <200310281647.45423.davidb@verisignlabs.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310281848.26163.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday 28 October 2003 05:56 pm, Samuel Weiler wrote: > > NOOOOOOOOOO!!!!!!! > > > > ... having read through long threads discussion what we might > > have to do if RSA is broken, ... > > We tackled "having space to deal with RSA being broken" even though > we don't have good alternatives to replace it. We needed to make sure > that "safe" failure modes exist and that phase-in of a new algorithm > would be possible. Yes, I agree. > In this case, we already have a provision for dealing with bigger > typecodes. We don't know how we'll deal with them, but at least the > provision is there. What provision? What we have now is an undefined format, which isn't worth anything. What happens when a validator sees a NSEC record with bit 0 set to one? Who knows? It is "undefined". > > Unless we go further and define good behavior for when a validator > > sees an NSEC format it doesn't recognize. > > Yup -- we need to do that. How's this: If you see the zero bit set > AND THE NSEC VALIDATES, treat this name as unsecured unless you have > evidence to the contrary (ie. a validated RRset)? Treating the entire > name as non-existing is too harsh. This means that a name with that > bit set can have its RRs spoofed away, but at least bad data can't be > substituted. We could do this, and it would work. It is why I mentioned this possibility in the first place. And I think that defining a rule like this is maybe the minimum we can do right now. But it would have to be defined in the DNSSECbis documents. It currently isn't. IMHO, it would be easier to define the alternative format than to work through the security implications of a NSEC RR with an unknown type format. This isn't rocket science. Honestly, I'm baffled that no one has handled this before now. > Paul asks: > > can serious deployment (burning of roms containing the software) > > begin without a defined solution for typecodes above 127? > > I think we can get away with putting this off -- we have the extension > mechanism in place and can deal with it later. With the current > typecode burn rate, the current format will outlast a resolver > replacement cycle. Maybe two. Well, we don't have the extension mechanism in place, which is partially my point. While I may personally believe that we are likely to go through multiple flag-days with DNSSEC, it would be stupid to proceed with that expectation. And who knows what the future "burn rate" on typecodes is? > But if folks really insist, let's get it done quickly. I'm sure we > can settle on a format. Can we get multiple interoperable > implementations out the door before Minneapolis? Seriously -- I want > to get this rev out. I suggest that the chairs decline the change > unless we have two pieces of interoperable code within some short > amount of time, perferably pre-MSP. Yes, I apologize for not bringing this up three years ago. I understand the desire for closure on DNSSEC, but I suggest that we not advance obviously deficient documents. -- David Blacka Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Oct 28 18:57:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08835 for ; Tue, 28 Oct 2003 18:57:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEddU-000JZf-CJ for namedroppers-data@psg.com; Tue, 28 Oct 2003 23:52:28 +0000 Received: from [211.29.193.83] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEddP-000JZG-9K for namedroppers@ops.ietf.org; Tue, 28 Oct 2003 23:52:24 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9p2/8.12.9) with ESMTP id h9SNqI8Y001833 for ; Wed, 29 Oct 2003 10:52:18 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200310282352.h9SNqI8Y001833@drugs.dv.isc.org> To: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Mail-Followup-To: namedroppers@ops.ietf.org Subject: Re: Wildcard NS and DNSSEC In-reply-to: Your message of "Mon, 27 Oct 2003 15:24:04 BST." <20031027142404.GB15077@atoom.net> Date: Wed, 29 Oct 2003 10:52:18 +1100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > [On 27 Oct, @15:16, Samuel wrote in "Re: Wildcard NS and DNSSEC ..."] > > > Additionally, you might be able to see that part of the standard > > > wildcard validation is missing: proof that (at least) the wildcard > > > actually exists. > > > > Put simply, the parent has no RRSIG on the NS set, and the RRSIG is an > > integral part of a wildcard proof. > > > > > I suppose that it might be possible to handle this by adding another > > > NSEC record for the wildcard, which may solve some nagging security > > > issues, but would be a pretty odd special case. > > > > Ick. Let's just forbid it and move along. If someone really wants to > > I'm in favor of doing that also, > > grtz Miek As am I. > > -- > to 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 Oct 28 20:19: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 UAA14196 for ; Tue, 28 Oct 2003 20:19:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEesk-000Nv5-NJ for namedroppers-data@psg.com; Wed, 29 Oct 2003 01:12:18 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEesg-000Nuo-7O for namedroppers@ops.ietf.org; Wed, 29 Oct 2003 01:12:14 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id C96DE5683E for ; Tue, 28 Oct 2003 17:12:11 -0800 (PST) Message-Id: <6.0.0.22.2.20031028183020.032a6d10@localhost> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Tue, 28 Oct 2003 20:11:50 -0500 To: namedroppers@ops.ietf.org From: Mike StJohns Subject: Section 2 of draft-ietf-dnsext-dnssec-protocol-03 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I was originally just going to send these to the editor, but I think there are still a few substantive problems here. (Obviously, these are opinions rather than directives, but its easier to write protocol stuff as directive...:-) Meta comment - much of the language in this section describes operational constraints rather than protocol constraints. This document really needs to describe the behavior of the protocol (e.g. "if the RRSIG is missing then..."), rather than trying to abscribe MUSTs and SHOULDs to the operators (e.g. "the zone must contain an RRSIG for every..."). These are in section order rather than order of importance... 2.1, first para, second sentence beginning: "For each private key...". Instead how about: "For each RRSIG there MUST be a corresponding zone DNSKEY RR. Orphan RRSIG RRs (e.g. those without corresponding DNSKEY RRs) are considered extraneous information and MUST be ignored." 2.1, 1para, 3rd sentence beginning "A zone key..." - delete "to one" - nit - flags are either set or cleared. 2.1 1para, last sentence - replace with "Public keys stored in DNSKEY RRs marked as zone keys SHOULD NOT be used for purposes other than DNS operations. However, enforcement of this restriction is properly left up to the standards which describe those other purposes." 2.1 2nd para, last sentence beginning "This DNSKEY RR..." - DNSKEY signing key doesn't actually appear to be defined in the reference. 2.2, pg 7, 2nd para after the bullets at top beginning "An RRSIG RR...". Replace entirely with: "An RRSIG RR itself SHOULD NOT be signed since signing an RRSIG RR would add no value. RRSIG RRs with a covered type of RRSIG are considered extraneous and MUST be ignored." 2.2 pg 7, 3rd para after bullets. Insert after first sentence: "Zones where the the apex NS RRSet is not validly signed (and should have been based on a validated DS in the parent zone) are considered bogus." [Commentary - there are notionally three states for zones, insecure, secure and bogus. The latter applies only to zones where the resolver was expecting to receive a secure result and did not. Bogus results come from bad signatures, missing signatures, or broken chains from a trust anchor. ] 2.2 pg7, 4th para after bullets beginning "There MUST be..." This continues to feel like the tail wagging the dog. The DS RR was added to prevent the requirement for close consultation between parent and child and this seems to have way too close coordination between parent and child. It also seems strange to require every RRset in a zone to be signed by ALL algorithms... How about: "1) The apex DNSKEY RRset SHOULD be signed by all apex DNSKEYs with both the zone key and SEP key flags set. [General definition of a SEP key is that it signs the zone DNSKEY RRSet] 2) The apex DNSKEY RRSet SHOULD include at least one non-SEP zone DNSKEY with a matching algorithm for each algorithm in the SEP set at the apex. [Need this for flow through since these sign all the non-DNSKEY rrsets] 3) All DS RRsets in a zone SHOULD be signed by at least one non-SEP zone DNSKEY for each algorithm in the apex SEP zone DNSKEY set. [The maintains the algorithm consistency from root to leaf in each zone without requiring all the elements of the zone to be signed by all algorithms.] 4) The DS RRset in the parent SHOULD include pointers to all child apex DNSKEYs with both the zone key and SEP key flags set. 5) The above represents guidance which should be enforced by the tools designed to sign and maintain zones. Failure to enforce these criteria will generally result in the inability to verify the security of a zone. The actual impact of failure to follow such guidance is described later in sections 4 and 5. 6) All resolvers MUST be able to verify RSA and DSA signatures. Signing tools MUST support RSA signatures and MAY support DSA signatures [is this the right order? I forget]" >>>>General comment: the most important thing is that the resolvers know how to resolve all the signature types. If we add additional sig algorithms we will need to update the resolver requirement (6 above) but not the resolution process. Its way too hard to try and enforce the numbers and types of signatures in the actual DNS. Its more than hard to try and do the enforcement between parent and child. The other thing we want to prevent is requiring a parent to do more signatures just because a child does them. But, we still need language in section 5 addressing whether data signed by an algorithm you don't understand is either bogus or insecure - I argue for the latter. Section 2.3 - There's some confusion here. A "glue" address record can be a real record in the zone - e.g. zone example.com, bar.example.com ns foo.example.com, foo.example.com A 1.1.1.1. Given that this is a real A record, I *think* it gets an NSEC RR, but the language in this section suggests otherwise. [I think the fallacious assumption is that zones are either delegation-only, or non-delegation.] Section 2.4 - This should reflect my comment above - item (4) that the DS RRSet should include pointers to all of the SEP keys. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Oct 28 20:57: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 UAA16137 for ; Tue, 28 Oct 2003 20:57:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEfVP-000PiL-8o for namedroppers-data@psg.com; Wed, 29 Oct 2003 01:52:15 +0000 Received: from [2002:425c:4242:0:250:daff:fe82:1c39] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEfVN-000Pi6-5u for namedroppers@ops.ietf.org; Wed, 29 Oct 2003 01:52:13 +0000 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id C24B618DD for ; Tue, 28 Oct 2003 20:52:11 -0500 (EST) Date: Tue, 28 Oct 2003 20:52:11 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Section 2 of draft-ietf-dnsext-dnssec-protocol-03 In-Reply-To: <6.0.0.22.2.20031028183020.032a6d10@localhost> References: <6.0.0.22.2.20031028183020.032a6d10@localhost> 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: <20031029015211.C24B618DD@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Tue, 28 Oct 2003 20:11:50 -0500, Michael StJohns wrote: > ... > Section 2.3 - There's some confusion here. A "glue" address record can be > a real record in the zone - e.g. zone example.com, bar.example.com ns > foo.example.com, foo.example.com A 1.1.1.1. Given that this is a real A > record, I *think* it gets an NSEC RR, but the language in this section > suggests otherwise. If foo.example.com is delegated, then the A RRset for foo.example.com in the example.com zone is glue, and doesn't show up in the NSEC RR at foo.example.com in the example.com zone. If foo.example.com isn't delegated, then the A RRset for foo.example.com isn't glue, and does show up in the NSEC RR. > [I think the fallacious assumption is that zones are either > delegation-only, or non-delegation.] No such assumption. You're just paying the word "glue" extra :). -- to unsubscribe send a message to namedroppers-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 Oct 28 20:58:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16170 for ; Tue, 28 Oct 2003 20:58:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEfSt-000PXr-47 for namedroppers-data@psg.com; Wed, 29 Oct 2003 01:49:39 +0000 Received: from [2002:425c:4242:0:250:daff:fe82:1c39] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEfSr-000PXS-Af for namedroppers@ops.ietf.org; Wed, 29 Oct 2003 01:49:37 +0000 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id C263718DD for ; Tue, 28 Oct 2003 20:28:22 -0500 (EST) Date: Tue, 28 Oct 2003 20:28:22 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Wildcard NS and DNSSEC In-Reply-To: <200310282352.h9SNqI8Y001833@drugs.dv.isc.org> References: <20031027142404.GB15077@atoom.net> <200310282352.h9SNqI8Y001833@drugs.dv.isc.org> 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: <20031029012822.C263718DD@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk just forbid wildcard ns and move along, aye. -- to unsubscribe send a message to namedroppers-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 Oct 28 21:56: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 VAA17502 for ; Tue, 28 Oct 2003 21:56:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEgOe-0003dc-VY for namedroppers-data@psg.com; Wed, 29 Oct 2003 02:49:20 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEgOZ-0003dB-MD for namedroppers@ops.ietf.org; Wed, 29 Oct 2003 02:49:15 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 9A31456842; Tue, 28 Oct 2003 18:49:14 -0800 (PST) Message-Id: <6.0.0.22.2.20031028214004.03478d18@localhost> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Tue, 28 Oct 2003 21:49:13 -0500 To: Rob Austein , namedroppers@ops.ietf.org From: Mike StJohns Subject: Re: Section 2 of draft-ietf-dnsext-dnssec-protocol-03 In-Reply-To: <20031029015211.C24B618DD@thrintun.hactrn.net> References: <6.0.0.22.2.20031028183020.032a6d10@localhost> <20031029015211.C24B618DD@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 08:52 PM 10/28/2003, Rob Austein wrote: >At Tue, 28 Oct 2003 20:11:50 -0500, Michael StJohns wrote: > > ... > > Section 2.3 - There's some confusion here. A "glue" address record can be > > a real record in the zone - e.g. zone example.com, bar.example.com ns > > foo.example.com, foo.example.com A 1.1.1.1. Given that this is a real A > > record, I *think* it gets an NSEC RR, but the language in this section > > suggests otherwise. > >If foo.example.com is delegated, then the A RRset for foo.example.com >in the example.com zone is glue, and doesn't show up in the NSEC RR at >foo.example.com in the example.com zone. Right, but the zone that was delegated in my example was bar.example.com. The A records for one of the name servers actually are in example.com (at foo.example.com) rather than being in the delegated domain (bar.example.com) The problem is the term "glue" I think. When I think of glue, I think of A records not in the zone, in which case its pretty clear that an NSEC record for that type of record shouldn't exist here. The problem is the language at 2.4: "Each owner name IN THE ZONE MUST have an NSEC resource record, except for the owner names of any glue address RRsets." (emphasis mine) E.g. is a true "glue address RRset" in the zone? >If foo.example.com isn't delegated, then the A RRset for >foo.example.com isn't glue, and does show up in the NSEC RR. > > > [I think the fallacious assumption is that zones are either > > delegation-only, or non-delegation.] > >No such assumption. You're just paying the word "glue" extra :). > >-- >to 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 Oct 28 22:15: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 WAA18786 for ; Tue, 28 Oct 2003 22:15:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEgiX-0005Dq-D3 for namedroppers-data@psg.com; Wed, 29 Oct 2003 03:09:53 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEgiU-0005Db-Q1 for namedroppers@ops.ietf.org; Wed, 29 Oct 2003 03:09:50 +0000 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 2E90118E1 for ; Tue, 28 Oct 2003 22:09:40 -0500 (EST) Date: Tue, 28 Oct 2003 22:09:40 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Section 2 of draft-ietf-dnsext-dnssec-protocol-03 In-Reply-To: <6.0.0.22.2.20031028214004.03478d18@localhost> References: <6.0.0.22.2.20031028183020.032a6d10@localhost> <20031029015211.C24B618DD@thrintun.hactrn.net> <6.0.0.22.2.20031028214004.03478d18@localhost> 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: <20031029030940.2E90118E1@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Tue, 28 Oct 2003 21:49:13 -0500, Michael StJohns wrote: > > Right, but the zone that was delegated in my example was > bar.example.com. You said that bar.example.com was delegated. You didn't way whether foo.example.com was delegated or not, so I answered it both ways. > The A records for one of the name servers actually are in > example.com (at foo.example.com) rather than being in the delegated > domain (bar.example.com) So foo.example.com isn't delegated, so it's not glue, hence 2.4 says it should have an NSEC RR. > The problem is the term "glue" I think. When I think of glue, I think of A > records not in the zone, in which case its pretty clear that an NSEC record > for that type of record shouldn't exist here. The problem is the language > at 2.4: > > "Each owner name IN THE ZONE MUST have an NSEC resource record, except for > the owner names of any glue address RRsets." (emphasis mine) After reviewing RFC 2181, I'm inclined to agree that we should just lose the word "glue" entirely here, albiet for slightly different reasons. For the purposes discussed in this section, there are three catagories of data in a zone: - Authoritative data; - Nonauthoritative NS RRsets (the delegations themselves) - All other nonauthoritative data (normally only addresses) RFC 2181 5.4.1 refers to all non-authoritative data in a zone as "glue", including the delegation NS RRsets. So let's just punt the term entirely as too blunt an instrument for this nitpicky level of protocol detail. How about: "Every authoritative RRset or delegation point NS RRset in the zone MUST have an NSEC resource record." -- to unsubscribe send a message to namedroppers-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 Oct 28 23:15: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 XAA22652 for ; Tue, 28 Oct 2003 23:15:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEheL-0009ha-TT for namedroppers-data@psg.com; Wed, 29 Oct 2003 04:09:37 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEheI-0009hG-R4 for namedroppers@ops.ietf.org; Wed, 29 Oct 2003 04:09:34 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id D367B5683E; Tue, 28 Oct 2003 20:09:33 -0800 (PST) Message-Id: <6.0.0.22.2.20031028225911.033ed928@localhost> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Tue, 28 Oct 2003 23:09:20 -0500 To: Rob Austein , namedroppers@ops.ietf.org From: Mike StJohns Subject: Re: Section 2 of draft-ietf-dnsext-dnssec-protocol-03 In-Reply-To: <20031029030940.2E90118E1@thrintun.hactrn.net> References: <6.0.0.22.2.20031028183020.032a6d10@localhost> <20031029015211.C24B618DD@thrintun.hactrn.net> <6.0.0.22.2.20031028214004.03478d18@localhost> <20031029030940.2E90118E1@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 10:09 PM 10/28/2003, Rob Austein wrote: Thanks for reparsing this... > > > > "Each owner name IN THE ZONE MUST have an NSEC resource record, except for > > the owner names of any glue address RRsets." (emphasis mine) > >After reviewing RFC 2181, I'm inclined to agree that we should just >lose the word "glue" entirely here, albiet for slightly different >reasons. > >For the purposes discussed in this section, there are three catagories >of data in a zone: > >- Authoritative data; > >- Nonauthoritative NS RRsets (the delegations themselves) > >- All other nonauthoritative data (normally only addresses) > >RFC 2181 5.4.1 refers to all non-authoritative data in a zone as >"glue", including the delegation NS RRsets. So let's just punt the >term entirely as too blunt an instrument for this nitpicky level of >protocol detail. How about: > >"Every authoritative RRset or delegation point NS RRset in the zone >MUST have an NSEC resource record." I hate terminology... in this case a DS RRset is authoritative because it belongs to the parent even though the name is the apex name of the child zone...right.. I think that's more precise than what's there and less subject to confusion. 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 Wed Oct 29 06:07: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 GAA03018 for ; Wed, 29 Oct 2003 06:07:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEo3z-000IzJ-I9 for namedroppers-data@psg.com; Wed, 29 Oct 2003 11:00:31 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEo3v-000Iyk-Mp for namedroppers@ops.ietf.org; Wed, 29 Oct 2003 11:00:27 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 20C7651C0F; Wed, 29 Oct 2003 12:00:27 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id A0A514FC48 for ; Wed, 29 Oct 2003 12:00:26 +0100 (CET) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id h9TB0QHl001064 for ; Wed, 29 Oct 2003 12:00:26 +0100 Date: Wed, 29 Oct 2003 12:00:26 +0100 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: Re: Large typecodes and DNSSEC Message-Id: <20031029120026.3494e13f.olaf@ripe.net> In-Reply-To: <20031028215112.DD1351394C@sa.vix.com> References: <20031028203810.7A1BB18E2@thrintun.hactrn.net> <20031028215112.DD1351394C@sa.vix.com> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.6 (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.064613 X-RIPE-Signature: 707a96bdc37b9cfdb36ff04aa362202e X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > bake-off? perhaps so, if olaf is rattling the WGLC sabre... As the sabre is being polished we see yet another stain *sigh* (I am tempted to use much bloodier metaphors, but refrain) Sam wrote: > I suggest that the chairs decline the change > unless we have two pieces of interoperable code within some short > amount of time, preferably pre-MSP. Chairs can decline _topics_ out of scope e.g. if they have been discussed at length and declined by the WG before. Hoping my memory is not selective I think that this topic is _not_ out of scope. We need specs, rather before than after IETF58. Running code as proof of concept surely helps to convince the WG. Remember, the RFC2535bis document-set is not intended to change the protocol, it should only clarify, changes go through the IETF seperatly. I think that we can argue that Sam's suggestion is actually a clarification rather than a protocol change so that can go into the documents directly, it describes what to do in the failure state, an omission in 2535, I'll be following this thread with this question in mind: Can the working group consent with Sam's clarification on how to handle when the validated NSEC zero bit is set or is there consent for alternative encoding. -- 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 Wed Oct 29 10:13: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 KAA11828 for ; Wed, 29 Oct 2003 10:13:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AErrg-000Bhl-M6 for namedroppers-data@psg.com; Wed, 29 Oct 2003 15:04:04 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AErrb-000BhB-Ip for namedroppers@ops.ietf.org; Wed, 29 Oct 2003 15:03:59 +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 h9TF3n0T003146 for ; Wed, 29 Oct 2003 10:03:49 -0500 (EST) Message-ID: <01b801c39e2d$de040c30$b9370681@barnacle> From: "Scott Rose" To: References: <6.0.0.22.2.20031028183020.032a6d10@localhost> Subject: Re: Section 2 of draft-ietf-dnsext-dnssec-protocol-03 Date: Wed, 29 Oct 2003 10:03:52 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Mike StJohns" To: Sent: Tuesday, October 28, 2003 8:11 PM Subject: Section 2 of draft-ietf-dnsext-dnssec-protocol-03 > I was originally just going to send these to the editor, but I think there > are still a few substantive problems here. (Obviously, these are opinions > rather than directives, but its easier to write protocol stuff as > directive...:-) > > Meta comment - much of the language in this section describes operational > constraints rather than protocol constraints. This document really needs > to describe the behavior of the protocol (e.g. "if the RRSIG is missing > then..."), rather than trying to abscribe MUSTs and SHOULDs to the > operators (e.g. "the zone must contain an RRSIG for every..."). > > These are in section order rather than order of importance... > > 2.1, first para, second sentence beginning: "For each private > key...". Instead how about: "For each RRSIG there MUST be a corresponding > zone DNSKEY RR. Orphan RRSIG RRs (e.g. those without corresponding DNSKEY > RRs) are considered extraneous information and MUST be ignored." > It is possible to have RRSIGs in a zone and the DNSKEY statically configured, and not in the zone. It is silly, but for some private DNS, it might be desired. > 2.1, 1para, 3rd sentence beginning "A zone key..." - delete "to one" - nit > - flags are either set or cleared. > > 2.1 1para, last sentence - replace with "Public keys stored in DNSKEY RRs > marked as zone keys SHOULD NOT be used for purposes other than DNS > operations. However, enforcement of this restriction is properly left up > to the standards which describe those other purposes." > ack. > 2.1 2nd para, last sentence beginning "This DNSKEY RR..." - DNSKEY signing > key doesn't actually appear to be defined in the reference. > The def is for "key Signing key" - a more general definition. > 2.2, pg 7, 2nd para after the bullets at top beginning "An RRSIG > RR...". Replace entirely with: > "An RRSIG RR itself SHOULD NOT be signed since signing an RRSIG RR would > add no value. RRSIG RRs with a covered type of RRSIG are considered > extraneous and MUST be ignored." > "MUST be ignored" is the phrase that I have a problem with. Ignored by the resolver, or the name server? Forbidding RRSIGs from being signed gets the point across in my opinion. > 2.2 pg 7, 3rd para after bullets. Insert after first sentence: "Zones > where the the apex NS RRSet is not validly signed (and should have been > based on a validated DS in the parent zone) are considered bogus." > > [Commentary - there are notionally three states for zones, insecure, secure > and bogus. The latter applies only to zones where the resolver was > expecting to receive a secure result and did not. Bogus results come from > bad signatures, missing signatures, or broken chains from a trust nchor. ] > > 2.2 pg7, 4th para after bullets beginning "There MUST be..." This > continues to feel like the tail wagging the dog. The DS RR was added to > prevent the requirement for close consultation between parent and child and > this seems to have way too close coordination between parent and child. It > also seems strange to require every RRset in a zone to be signed by ALL > algorithms... > I believe that was to be "every algorithm /present/..." not necessary every algorithm defined for DNSSEC. The child MUST have a RRSIG generated using the same algos as found in the DS set in the parent, plus any other algos found in the child apex and not in the parent's DS set. > How about: > > "1) The apex DNSKEY RRset SHOULD be signed by all apex DNSKEYs with both > the zone key and SEP key flags set. [General definition of a SEP key is > that it signs the zone DNSKEY RRSet] > > 2) The apex DNSKEY RRSet SHOULD include at least one non-SEP zone DNSKEY > with a matching algorithm for each algorithm in the SEP set at the apex. > [Need this for flow through since these sign all the non-DNSKEY rrsets] > > 3) All DS RRsets in a zone SHOULD be signed by at least one non-SEP zone > DNSKEY for each algorithm in the apex SEP zone DNSKEY set. [The maintains > the algorithm consistency from root to leaf in each zone without requiring > all the elements of the zone to be signed by all algorithms.] > > 4) The DS RRset in the parent SHOULD include pointers to all child apex > DNSKEYs with both the zone key and SEP key flags set. > Not sure what you mean here with 4): Both the zone key and the SEP key? That nullifies the idea of having a SEP key different than the zone key. Or all DNSKEY RRs with both the zone and SEP bits set? > 5) The above represents guidance which should be enforced by the tools > designed to sign and maintain zones. Failure to enforce these criteria will > generally result in the inability to verify the security of a zone. The > actual impact of failure to follow such guidance is described later in > sections 4 and 5. > > 6) All resolvers MUST be able to verify RSA and DSA signatures. Signing > tools MUST support RSA signatures and MAY support DSA signatures [is this > the right order? I forget]" RSA/SHA1 is mandatory, DSA is recommended. The records draft states this, but maybe it could be repeated here. I don't think it is a good idea to designate algorithms by name, since RSA/DSA/ECC/ROT13 might be dropped for some reason in the future. Thanks for the input Scott -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Oct 29 10:47: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 KAA14901 for ; Wed, 29 Oct 2003 10:47:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEsSJ-000FHF-HE for namedroppers-data@psg.com; Wed, 29 Oct 2003 15:41:55 +0000 Received: from [216.168.237.102] (helo=heron.verisign.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEsS7-000FGG-1O for namedroppers@ops.ietf.org; Wed, 29 Oct 2003 15:41:43 +0000 Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by heron.verisign.com (8.12.10/8.12.10) with ESMTP id h9TFfgSf001932; Wed, 29 Oct 2003 10:41:42 -0500 (EST) 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 VJP1R0VW; Wed, 29 Oct 2003 10:41:41 -0500 Received: by chinook.rgy.netsol.com (Postfix, from userid 500) id 7B4EB9BE20; Wed, 29 Oct 2003 10:41:41 -0500 (EST) Date: Wed, 29 Oct 2003 10:41:41 -0500 From: Matt Larson To: David Blacka Cc: namedroppers@ops.ietf.org Subject: Re: Large typecodes and DNSSEC Message-ID: <20031029154141.GA27166@chinook.rgy.netsol.com> References: <200310281402.41950.davidb@verisignlabs.com> <200310281647.45423.davidb@verisignlabs.com> <200310281848.26163.davidb@verisignlabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200310281848.26163.davidb@verisignlabs.com> User-Agent: Mutt/1.5.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 28 Oct 2003, David Blacka wrote: > IMHO, it would be easier to define the alternative format than to work > through the security implications of a NSEC RR with an unknown type > format. This isn't rocket science. I agree. The incremental work of defining an encoding can't be much more than punting with language about undefined states, treating as unsecure, etc. > I understand the desire for closure on DNSSEC, but I suggest that we not > advance obviously deficient documents. What Dave said.... Let's define something (sounds like Mr. Graff has a proposal already), put it in the docs and move on. Matt -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Oct 29 11:30: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 LAA17615 for ; Wed, 29 Oct 2003 11:30:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEt8E-000JMB-Q5 for namedroppers-data@psg.com; Wed, 29 Oct 2003 16:25:14 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEt87-000JKd-KJ for namedroppers@ops.ietf.org; Wed, 29 Oct 2003 16:25:07 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 0C0145684D; Wed, 29 Oct 2003 08:25:06 -0800 (PST) Message-Id: <6.0.0.22.2.20031029104228.02f72148@localhost> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 29 Oct 2003 11:25:05 -0500 To: "Scott Rose" , From: Mike StJohns Subject: Re: Section 2 of draft-ietf-dnsext-dnssec-protocol-03 In-Reply-To: <01b801c39e2d$de040c30$b9370681@barnacle> References: <6.0.0.22.2.20031028183020.032a6d10@localhost> <01b801c39e2d$de040c30$b9370681@barnacle> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 10:03 AM 10/29/2003, Scott Rose wrote: >----- Original Message ----- >From: "Mike StJohns" >To: >Sent: Tuesday, October 28, 2003 8:11 PM >Subject: Section 2 of draft-ietf-dnsext-dnssec-protocol-03 > > > > I was originally just going to send these to the editor, but I think there > > are still a few substantive problems here. (Obviously, these are >opinions > > rather than directives, but its easier to write protocol stuff as > > directive...:-) > > > > Meta comment - much of the language in this section describes operational > > constraints rather than protocol constraints. This document really needs > > to describe the behavior of the protocol (e.g. "if the RRSIG is missing > > then..."), rather than trying to abscribe MUSTs and SHOULDs to the > > operators (e.g. "the zone must contain an RRSIG for every..."). > > > > These are in section order rather than order of importance... > > > > 2.1, first para, second sentence beginning: "For each private > > key...". Instead how about: "For each RRSIG there MUST be a >corresponding > > zone DNSKEY RR. Orphan RRSIG RRs (e.g. those without corresponding DNSKEY > > RRs) are considered extraneous information and MUST be ignored." > > > >It is possible to have RRSIGs in a zone and the DNSKEY statically >configured, and not in the zone. It is silly, but for some private DNS, it >might be desired. Let's just say no. The DNSKEY needs to be in the DNS. the static configuration of the trust anchor can refer to that DNSKEY, but can't synthesize it. Reason: Referential integrity. Reason: Simpler if less special cases in the resolver. > > 2.1, 1para, 3rd sentence beginning "A zone key..." - delete "to one" - nit > > - flags are either set or cleared. > > > > 2.1 1para, last sentence - replace with "Public keys stored in DNSKEY RRs > > marked as zone keys SHOULD NOT be used for purposes other than DNS > > operations. However, enforcement of this restriction is properly left up > > to the standards which describe those other purposes." > > > >ack. > > > > 2.1 2nd para, last sentence beginning "This DNSKEY RR..." - DNSKEY signing > > key doesn't actually appear to be defined in the reference. > > >The def is for "key Signing key" - a more general definition. Yup - agreed, but these two need to use the exact same phrase to make sure the link is made. E.g. use "DNSKEY key signing key" instead. > > 2.2, pg 7, 2nd para after the bullets at top beginning "An RRSIG > > RR...". Replace entirely with: > > "An RRSIG RR itself SHOULD NOT be signed since signing an RRSIG RR would > > add no value. RRSIG RRs with a covered type of RRSIG are considered > > extraneous and MUST be ignored." > > > >"MUST be ignored" is the phrase that I have a problem with. Ignored by the >resolver, or the name server? Forbidding RRSIGs from being signed gets the >point across in my opinion. Forbidding RRSIGs signatures is an operational constraint - this document needs to describe what happens if some irrational zone manager actually manages to populate their zone with RRSIG RRSIGs. "MUST be ignored" applies both to the name server and the resolver IMHO. The name server probably shouldn't serve the data (but I don't know that that is a reasonable restriction), but if it does, the resolver shouldn't validate it or cache it. > > 2.2 pg 7, 3rd para after bullets. Insert after first sentence: "Zones > > where the the apex NS RRSet is not validly signed (and should have been > > based on a validated DS in the parent zone) are considered bogus." > > > > [Commentary - there are notionally three states for zones, insecure, >secure > > and bogus. The latter applies only to zones where the resolver was > > expecting to receive a secure result and did not. Bogus results come from > > bad signatures, missing signatures, or broken chains from a trust >nchor. ] > > > > 2.2 pg7, 4th para after bullets beginning "There MUST be..." This > > continues to feel like the tail wagging the dog. The DS RR was added to > > prevent the requirement for close consultation between parent and child >and > > this seems to have way too close coordination between parent and child. >It > > also seems strange to require every RRset in a zone to be signed by ALL > > algorithms... > > > >I believe that was to be "every algorithm /present/..." not necessary every >algorithm defined for DNSSEC. The child MUST have a RRSIG generated using >the same algos as found in the DS set in the parent, plus any other algos >found in the child apex and not in the parent's DS set. Right - but that's the wrong answer I think. If we don't mandate the set of algorithms the resolver has to implement, then its possible that the resolver won't be able to resolve part of the tree if its signed by an algorithm the resolver doesn't understand. Mandating how the tree is signed is the wrong answer - because we can't control what people do. Mandating how the resolver works is the right answer. So: "Resolvers MUST be able to validate and resolve both RSA and DSA signatures. Signing tools MUST be able to sign using RSA and MAY sign using DSA. Signatures using algorithms unknown by the resolver are considered extraneous material and MUST be ignored (e.g. treated as if they didn't exist). Signatures using algorithms known by the resolver, but prohibited by configuration of the resolver are also considered extraneous material and MUST be ignored." If we do this, then it doesn't matter who signs what and we move back from the realm of trying to control human behavior into the realm of controlling protocol behavior. We still have the problem where we add new algorithms, delete old ones and haven't updated the resolvers, but that seems to be a lot less problematic than the current language (e.g. its a "lesser included offense" :-) > > How about: > > > > "1) The apex DNSKEY RRset SHOULD be signed by all apex DNSKEYs with both > > the zone key and SEP key flags set. [General definition of a SEP key is > > that it signs the zone DNSKEY RRSet] > > > > 2) The apex DNSKEY RRSet SHOULD include at least one non-SEP zone DNSKEY > > with a matching algorithm for each algorithm in the SEP set at the apex. > > [Need this for flow through since these sign all the non-DNSKEY rrsets] > > > > 3) All DS RRsets in a zone SHOULD be signed by at least one non-SEP zone > > DNSKEY for each algorithm in the apex SEP zone DNSKEY set. [The maintains > > the algorithm consistency from root to leaf in each zone without requiring > > all the elements of the zone to be signed by all algorithms.] > > > > 4) The DS RRset in the parent SHOULD include pointers to all child apex > > DNSKEYs with both the zone key and SEP key flags set. > > > >Not sure what you mean here with 4): Both the zone key and the SEP key? >That nullifies the idea of having a SEP key different than the zone key. Or >all DNSKEY RRs with both the zone and SEP bits set? What is a non-zone SEP key? Yeah, actually I meant all DNSKEY RRs [at the apex] with both the zone and SEP bits set. > > 5) The above represents guidance which should be enforced by the tools > > designed to sign and maintain zones. Failure to enforce these criteria >will > > generally result in the inability to verify the security of a zone. The > > actual impact of failure to follow such guidance is described later in > > sections 4 and 5. > > > > 6) All resolvers MUST be able to verify RSA and DSA signatures. Signing > > tools MUST support RSA signatures and MAY support DSA signatures [is this > > the right order? I forget]" > >RSA/SHA1 is mandatory, DSA is recommended. The records draft states this, >but maybe it could be repeated here. I don't think it is a good idea to >designate algorithms by name, since RSA/DSA/ECC/ROT13 might be dropped for >some reason in the future. Correct. But they get deprecated, before they get dropped. We will have to mention them by name somewhere as mandatory/recommended. >Thanks for the input > >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: -- to unsubscribe send a message to namedroppers-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 Oct 29 12: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 MAA21716 for ; Wed, 29 Oct 2003 12:26:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEu14-000OSI-Rh for namedroppers-data@psg.com; Wed, 29 Oct 2003 17:21:54 +0000 Received: from [2001:4f8:3:bb:290:27ff:fe73:8215] (helo=farside.isc.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEu10-000ORg-43 for namedroppers@ops.ietf.org; Wed, 29 Oct 2003 17:21:50 +0000 Received: by farside.isc.org (Postfix, from userid 10015) id E8898A862; Wed, 29 Oct 2003 17:21:49 +0000 (UTC) To: namedroppers@ops.ietf.org Subject: Re: Large typecodes and DNSSEC References: <200310281402.41950.davidb@verisignlabs.com> <200310281647.45423.davidb@verisignlabs.com> <200310281848.26163.davidb@verisignlabs.com> <20031029154141.GA27166@chinook.rgy.netsol.com> From: Michael Graff Date: Wed, 29 Oct 2003 17:21:49 +0000 In-Reply-To: <20031029154141.GA27166@chinook.rgy.netsol.com> (Matt Larson's message of "Wed, 29 Oct 2003 10:41:41 -0500") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk And here it is. :) DNSEXT Working Group Michael Graff INTERNET-DRAFT ISC October, 2003 Extensions to NXT records for all rdata types Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document specifies a format for NXT records which allows NXT records to specify any rdata type as covered by the NXT, rather than being limited to the first 127 types. 1 - Rationale and Scope 1.1. Currently, NXT records can only describe the first 127 rdata types (1 through 127.) 1.2. Several rdata types are in use by vendors which cannot be covered by existing NXT records. Additionally, the experimental range cannot be covered. Expires April 2004 FORMFEED[Page 1] INTERNET-DRAFT NXT-EXT October, 2003 1.3. The DNS rdata code space usage is expected to grow. Rolling out new formats for rdata types is difficult operationally. Making the NXT record support the future is important before widespread deployment of DNSSEC prevents such extensions. 1.4. The existing NXT record format allows for extension by setting bit 0 to one. 2 - Affected Protocol Elements 2.1. Bit 0 of the first byte in the NXT record rdata indicates this is an extended NXT record. 3 - Compatibility with existing servers 3.1. Older servers will not understand this format. 3.2. This extension uses the mechanism provided in the NXT rdata format of RFC2535. 4 - Extended NXT rdata format 4.1. The extended NXT rdata begins with the high order bit set in the first byte and the two low-order bits indicate which format the NXT data is encoded using. All other bits MUST be set to zero. +---+---+---+---+---+---+---+---+ 0 | 1 | R | R | R | R | R | R | F | 8 +---+---+---+---+---+---+---+---+ R Reserved bits. MUST be set to 0 when transmitting to allow extensions. F The encoding format used. 0 indicates a simple list of 16-bit type codes. 1 indicates a slightly compressed type code list. 5 - Format 0: 16 bit type code list 5.1. The data is a simple list of 16-bit type codes, listed in increasing value. Expires April 2004 FORMFEED[Page 2] INTERNET-DRAFT NXT-EXT October, 2003 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 0 | RDATA_TYPE | 16 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ RDATA_TYPE The 16-bit type codes defined in various RFCs. 5.2. For example, if a NXT contains SIG (24), NXT (30), A (1), TXT (16), MX (15), and type 0xff45 types, the 16-bit values will be encoded as: 0x0001 0x000f 0x0010 0x0018 0x001e 0xff45 6 - Format 1: compressed type code list 6.1. This format uses a simple compression method to factor out the first 8 bits of a prefix code for a group of codes. This is done by specifying a one-byte count, a one-byte prefix, and "count" bytes of low-order data. +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 0 | COUNT | HIGH-ORDER | 16 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | Data... | ... | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ COUNT This value indicates how many type codes follow which use the high- order value. A count of 0 indicates that no "data" bytes follow but all 256 possible rdata type codes exist for this high-order value. Values between 1 and 128 indicate the types are present, and there are 1 to 128 octets that follow. Values of 129 through 255 indicate that 256 - count octets follow, and they specify type codes NOT present. HIGH-ORDER The upper 8 bits of the type codes, listed in increasing value. Data "count" bytes to supply the low-order type code data, listed in increasing value. Expires April 2004 FORMFEED[Page 3] INTERNET-DRAFT NXT-EXT October, 2003 6.2. For example, the coding for a record containing A, MX, TXT, SIG, NXT, and type 0xff45: 0x05 0x00 0x01 0x0f 0x10 0x18 0x1e 0x01 0xff 0x45 Expires April 2004 FORMFEED[Page 4] INTERNET-DRAFT NXT-EXT October, 2003 7 - References [RFC1035] P. Mockapetris, ``Domain Names - Implementation and Specification,'' RFC 1035, USC/Information Sciences Institute, November 1987. [RFC2535] D. Eastlake, ``Domain Name System Security Extensions,'' RFC 2535, IBM, March 1999. 8 - Author's Address Michael Graff Internet Software Consortium 950 Charter Street Redwood City, CA 94063 +1 650.423.1304 Expires April 2004 FORMFEED[Page 5] -- to unsubscribe send a message to namedroppers-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 Oct 29 12:46: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 MAA22685 for ; Wed, 29 Oct 2003 12:46:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEuKE-0000Mm-MU for namedroppers-data@psg.com; Wed, 29 Oct 2003 17:41:42 +0000 Received: from [2001:4f8:3:bb:290:27ff:fe73:8215] (helo=farside.isc.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEuKC-0000MU-JJ for namedroppers@ops.ietf.org; Wed, 29 Oct 2003 17:41:40 +0000 Received: by farside.isc.org (Postfix, from userid 10015) id 625AAA867; Wed, 29 Oct 2003 17:41:40 +0000 (UTC) To: Michael Graff Cc: namedroppers@ops.ietf.org Subject: Re: Large typecodes and DNSSEC References: <200310281402.41950.davidb@verisignlabs.com> <200310281647.45423.davidb@verisignlabs.com> <200310281848.26163.davidb@verisignlabs.com> <20031029154141.GA27166@chinook.rgy.netsol.com> From: Michael Graff Date: Wed, 29 Oct 2003 17:41:40 +0000 In-Reply-To: (Michael Graff's message of "Wed, 29 Oct 2003 17:21:49 +0000") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk And of course, please s/NXT/NSEC/ -- this was written before the proposed typecode roll names were set in mud. --Michael -- to unsubscribe send a message to namedroppers-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 Oct 29 13:21:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24628 for ; Wed, 29 Oct 2003 13:21:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEut2-0003cS-Tb for namedroppers-data@psg.com; Wed, 29 Oct 2003 18:17:40 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEusy-0003by-IM for namedroppers@ops.ietf.org; Wed, 29 Oct 2003 18:17:36 +0000 Received: by shell-ng.nominum.com (Postfix, from userid 11053) id 36D8B5685F; Wed, 29 Oct 2003 10:17:36 -0800 (PST) Date: Wed, 29 Oct 2003 10:17:36 -0800 From: Stephen Jacob To: Michael Graff Cc: namedroppers@ops.ietf.org Subject: Re: Large typecodes and DNSSEC Message-ID: <20031029181736.GB50160@shell-ng.nominum.com> References: <200310281402.41950.davidb@verisignlabs.com> <200310281647.45423.davidb@verisignlabs.com> <200310281848.26163.davidb@verisignlabs.com> <20031029154141.GA27166@chinook.rgy.netsol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-message-flag: MS Outlook sucks. If you must use Windows, try Eudora. X-URI: http://www.nominum.com/ Organization: Nominum, Inc. X-URI-Personal: http://www.sjacob.org/ User-Agent: Mutt/1.5.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hi Michael, On Wed, Oct 29, 2003 at 05:21:49PM +0000, Michael Graff wrote: > 4.1. The extended NXT rdata begins with the high order bit set in the > first byte and the two low-order bits indicate which format the NXT data > is encoded using. All other bits MUST be set to zero. > > +---+---+---+---+---+---+---+---+ > 0 | 1 | R | R | R | R | R | R | F | 8 > +---+---+---+---+---+---+---+---+ > > > R Reserved bits. MUST be set to 0 when transmitting to allow > extensions. > > F The encoding format used. 0 indicates a simple list of 16-bit type > codes. 1 indicates a slightly compressed type code list. Is the text correct or is the diagram correct? I think the diagram is correct, based on the subsequent text, but the text in the initial paragraph of 4.1 says, "...the two low-order bits indicate which format...", but it seems to be suggested elsewhere that this should be, "...the low-order bit indicates which format...". Actually, to me "most significant bit" and "least significant bit" are clearer than "high[est]-order bit" or "low[est]-order bit". > 6 - Format 1: compressed type code list > > 6.1. This format uses a simple compression method to factor out the > first 8 bits of a prefix code for a group of codes. This is done by > specifying a one-byte count, a one-byte prefix, and "count" bytes of > low-order data. > > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > 0 | COUNT | HIGH-ORDER | 16 > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > | Data... | ... | > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ Since the "Data..." are specifically 8-bit quantities, and not variable bit-length quantities, it might be better to re-do this figure. Perhaps something like: +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 0 | COUNT | HIGH-ORDER | 16 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | DATA | DATA | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | DATA | ... +---+---+---+---+---+---+---+---+ Or perhaps better (since showing it as 16 bits wide might suggest that there had to be an even number of data), something like: +---+---+---+---+---+---+---+---+ 0 | COUNT | 8 +---+---+---+---+---+---+---+---+ | HIGH-ORDER | +---+---+---+---+---+---+---+---+ | DATA | +---+---+---+---+---+---+---+---+ | DATA | +---+---+---+---+---+---+---+---+ . . . . . . +---+---+---+---+---+---+---+---+ Regards, sj -- Stephen Jacob | Stephen.Jacob@nominum.com | +1 650 381 6051 Nominum, Inc. | http://www.nominum.com/ | "Communication by Name" -- to unsubscribe send a message to namedroppers-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 Oct 29 13:38: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 NAA25496 for ; Wed, 29 Oct 2003 13:38:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEv8W-0004uU-WB for namedroppers-data@psg.com; Wed, 29 Oct 2003 18:33:40 +0000 Received: from [2001:4f8:3:bb:290:27ff:fe73:8215] (helo=farside.isc.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEv8T-0004u6-OP for namedroppers@ops.ietf.org; Wed, 29 Oct 2003 18:33:37 +0000 Received: by farside.isc.org (Postfix, from userid 10015) id 7E74CA85D; Wed, 29 Oct 2003 18:33:37 +0000 (UTC) To: Stephen Jacob Cc: namedroppers@ops.ietf.org Subject: Re: Large typecodes and DNSSEC References: <200310281402.41950.davidb@verisignlabs.com> <200310281647.45423.davidb@verisignlabs.com> <200310281848.26163.davidb@verisignlabs.com> <20031029154141.GA27166@chinook.rgy.netsol.com> <20031029181736.GB50160@shell-ng.nominum.com> From: Michael Graff Date: Wed, 29 Oct 2003 18:33:37 +0000 In-Reply-To: <20031029181736.GB50160@shell-ng.nominum.com> (Stephen Jacob's message of "Wed, 29 Oct 2003 10:17:36 -0800") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Stephen Jacob writes: > Is the text correct or is the diagram correct? I think the diagram > is correct, based on the subsequent text, but the text in the initial > paragraph of 4.1 says, "...the two low-order bits indicate which > format...", but it seems to be suggested elsewhere that this should > be, "...the low-order bit indicates which format...". The diagram is correct. There used to be additional encodings, but they didn't seem worth it for how complicated they became. > Actually, to me "most significant bit" and "least significant bit" > are clearer than "high[est]-order bit" or "low[est]-order bit". Noted. > Since the "Data..." are specifically 8-bit quantities, and not > variable bit-length quantities, it might be better to re-do this > figure. Perhaps something like: Thanks much. I'll see what I can do there. :) --Michael -- to unsubscribe send a message to namedroppers-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 Oct 29 14:42: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 OAA00762 for ; Wed, 29 Oct 2003 14:42:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEw72-000APn-30 for namedroppers-data@psg.com; Wed, 29 Oct 2003 19:36:12 +0000 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEw6x-000APF-82 for namedroppers@ops.ietf.org; Wed, 29 Oct 2003 19:36:07 +0000 Received: from latte (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.10/8.12.10) with ESMTP id h9TJa21e019669; Wed, 29 Oct 2003 20:36:04 +0100 To: David Blacka Cc: namedroppers@ops.ietf.org Subject: Re: Large typecodes and DNSSEC References: <200310281402.41950.davidb@verisignlabs.com> From: Simon Josefsson X-Payment: hashcash 1.2 0:031029:davidb@verisignlabs.com:e273a20d16d5b43c X-Hashcash: 0:031029:davidb@verisignlabs.com:e273a20d16d5b43c X-Payment: hashcash 1.2 0:031029:namedroppers@ops.ietf.org:dc8f90dc6c5ea593 X-Hashcash: 0:031029:namedroppers@ops.ietf.org:dc8f90dc6c5ea593 Date: Wed, 29 Oct 2003 20:35:54 +0100 In-Reply-To: <200310281402.41950.davidb@verisignlabs.com> (David Blacka's message of "Tue, 28 Oct 2003 14:02:41 -0500") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk David Blacka writes: > Currently the NSEC record (nee NXT) can only support typecodes up to > 127 (dnssec-records-05, section 4.1.2). However, the type field in > DNS is actually 16 bits long. > > While this situation has been true for as long as I've been looking at > DNSSEC, and presumably since its inception, this is an issue that > seems to have been totally ignored by this WG. The now expired proposed NXT replacement draft at address that problem, and a few other problems with NXT that haven't been addressed (nor firmly acknowledged as problems, for that matter). Thanks, Simon -- to unsubscribe send a message to namedroppers-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 Oct 29 15: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 PAA04538 for ; Wed, 29 Oct 2003 15:31:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEws6-000Es7-6j for namedroppers-data@psg.com; Wed, 29 Oct 2003 20:24:50 +0000 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEws3-000Erv-De for namedroppers@ops.ietf.org; Wed, 29 Oct 2003 20:24:47 +0000 Received: from isi.edu (wireless225.east.isi.edu [65.123.202.225]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id h9TKOXj09699; Wed, 29 Oct 2003 12:24:34 -0800 (PST) Date: Wed, 29 Oct 2003 15:24:41 -0500 Subject: Re: Large typecodes and DNSSEC Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Daniel Massey , namedroppers@ops.ietf.org To: Michael Graff From: Daniel Massey In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, October 29, 2003, at 12:21 PM, Michael Graff wrote: > > 3 - Compatibility with existing servers > > 3.1. Older servers will not understand this format. > > 3.2. This extension uses the mechanism provided in the NXT rdata > format > of RFC2535. > > 4 - Extended NXT rdata format > > 4.1. The extended NXT rdata begins with the high order bit set in > the > first byte and the two low-order bits indicate which format the NXT > data > is encoded using. All other bits MUST be set to zero. > > I think there is a basic problem with having multiple formats. Consider the following: Query: www.example. A Response: NO DATA www.example. NSEC with zero bit set to 1 (format whatever) www.example. SIG(NSEC) by example DNSKEY The SIG authenticates the NSEC, but the resolver doesn't understand the format.... what happens? Note the resolver is just asking for a plain old A record. The server had to use one of the alternate formats since some RR type > 127 is present at www.example and setting zero bit = 0 was not an option at the server. The resolver has no way of knowing whether this response proves no A RR exists. (it could be an attacker is sending the NSEC proving the A RR **does** exist, knowing the resolver doesn't understand the extended format). I think what you will find is that in the current term, very few people implement the alternate formats for what to do if RR types > 127. Fewer still will have really tested these formats so we know they work.... As a result when someone adds the first type >127, queries for things like A records and DS records can stop working. If large vendor X has failed to implement the >127 type map or discovers it has a flaw in this type second (or third or fourth) type map, what do you do? the software won't even be stressed in real conditions until years from now... I have yet another alternate suggestion that handles all type codes, but ensures that the process rules for the current types < 127 never change: Type 128 is the FOO record. The FOO record MUST be present at a name if any RR type greater than 128 exists at that name and this record lists the types greater than 128 stored at this name. The FOO record MUST NOT be present at a name if no type greater than 128 exists at that name. The format of the FOO record is to be defined by a standards action if/when the RR type space exceeds 128. If the query type < 127, do what protocol doc currently says. If the query type > 127 and the answer is no data, do what the protocol do c currently says and also the server SHOULD include the FOO RR in the response. If the NSEC zero bit is set in the response, RR types greater than 128 are present at this name. If these types are meaningful to the resolver, the FOO record indicates which types >127 are present at this name. Queries for types less than 127 are still authenticated according the rules above. If a query that requests types greater than 127 and the answer is no data, the FOO record is used to prove the requested type does not exist. For the current doc set, issue done. Anyone with strong opinions on how to encode the type field for types beyond 128, write a FOO record draft, but we don't need FOO defined to advance this doc set. If no one writes the FOO record, somewhere down the road the first person to define a type greater than 128 is stuck with defining the FOO RR :) Note software that has been upgraded to understand the new type > 128 will need to also be upgraded to understand the new FOO record. Old software (ie today's stuff) will always be able to work fine for all types < 128 and will be backwards compatible. For example, with the FOO RR: Query: www.example. A Response: NO DATA www.example. NSEC with zero bit set to 1 www.example. SIG(NSEC) by example DNSKEY A resolver looking for the A record can doesn't care the zero bit is set to 1. The current bit map indicates no A record exists. This will always work regardless of what happens due to any increase in the type space. Query: www.example type150 Response: NO DATA www.example. NSEC with zero bit set to 1. www.example. SIG(NSEC) by example DNSKEY www.example. FOO (indicating what types > 127 exist at www.example) www.example. SIG(FOO) by example DNSKEY A resolver looking for the type150 record needs to understand the FOO RR. Dan -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Oct 29 15:32:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04606 for ; Wed, 29 Oct 2003 15:32:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEwvR-000F6w-KZ for namedroppers-data@psg.com; Wed, 29 Oct 2003 20:28:17 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEwvP-000F6d-Fe for namedroppers@ops.ietf.org; Wed, 29 Oct 2003 20:28:15 +0000 Received: from incognito.ddns.nominum.com (dhcp-101.wl.nominum.com [81.200.65.101]) by shell-ng.nominum.com (Postfix) with ESMTP id D2BD05684F for ; Wed, 29 Oct 2003 12:28:14 -0800 (PST) Received: from incognito.ddns.nominum.com (localhost [127.0.0.1]) by incognito.ddns.nominum.com (8.12.8/8.12.8) with ESMTP id h9TKSEsl008244; Wed, 29 Oct 2003 12:28:14 -0800 Received: from localhost (bwelling@localhost) by incognito.ddns.nominum.com (8.12.8/8.12.8/Submit) with ESMTP id h9TKSDLC008240; Wed, 29 Oct 2003 12:28:13 -0800 X-Authentication-Warning: incognito.ddns.nominum.com: bwelling owned process doing -bs Date: Wed, 29 Oct 2003 12:28:13 -0800 (PST) From: Brian Wellington X-X-Sender: bwelling@incognito.ddns.nominum.com To: Michael Graff Cc: namedroppers@ops.ietf.org Subject: Re: Large typecodes and DNSSEC In-Reply-To: Message-ID: References: <200310281402.41950.davidb@verisignlabs.com> <200310281647.45423.davidb@verisignlabs.com> <200310281848.26163.davidb@verisignlabs.com> <20031029154141.GA27166@chinook.rgy.netsol.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 29 Oct 2003, Michael Graff wrote: > And of course, please s/NXT/NSEC/ -- this was written before the > proposed typecode roll names were set in mud. Given that the typecodes are being rolled, we might want to consider removing the old format completely, and coming up with a new, sane format that doesn't have any problem representing all types within the type code space. The compressed format in this document seems like it does that, and it's fairly efficient for typical cases. Do we really need multiple encodings, and backwards compatibility with a record of a different type? I propose that we standardize on this (or something better, if anyone has a better idea) as the only format and get rid of versioning. Brian -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Oct 29 15:47: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 PAA05395 for ; Wed, 29 Oct 2003 15:47:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEx7s-000GLd-PU for namedroppers-data@psg.com; Wed, 29 Oct 2003 20:41:08 +0000 Received: from [216.168.237.102] (helo=heron.verisign.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEx7p-000GLA-0m for namedroppers@ops.ietf.org; Wed, 29 Oct 2003 20:41:05 +0000 Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by heron.verisign.com (8.12.10/8.12.10) with ESMTP id h9TKf1mM010596; Wed, 29 Oct 2003 15:41:01 -0500 (EST) 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 VJP1SGZR; Wed, 29 Oct 2003 15:41:00 -0500 Received: by chinook.rgy.netsol.com (Postfix, from userid 500) id 4989C9BE20; Wed, 29 Oct 2003 15:41:01 -0500 (EST) Date: Wed, 29 Oct 2003 15:41:01 -0500 From: Matt Larson To: Daniel Massey Cc: Michael Graff , namedroppers@ops.ietf.org Subject: Re: Large typecodes and DNSSEC Message-ID: <20031029204101.GC31459@chinook.rgy.netsol.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 29 Oct 2003, Daniel Massey wrote: > The SIG authenticates the NSEC, but the resolver doesn't understand the > format.... what happens? I believe this issue will be taken care of by rolling the type codes and the RFC2535bis documents. The new documents will specify the new behavior, which any RFC2535bis-compliant implementation will have to follow. We've already sacrificed any backward compatibility and a fully specified NSEC record that can handle typecodes past 128 is just another backward incompatibility. > Type 128 is the FOO record. The FOO record MUST be present at a name > if any RR type greater than 128 exists at that name and this record > lists the types greater than 128 stored at this name. This idea is an ingenious way to cope with the current situation, but it's a terrible hack. Let's spend the effort to fix NSEC instead. Matt -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Oct 29 15:49: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 PAA05477 for ; Wed, 29 Oct 2003 15:49:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AExAA-000GZd-9Q for namedroppers-data@psg.com; Wed, 29 Oct 2003 20:43:30 +0000 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AExA7-000GZH-69 for namedroppers@ops.ietf.org; Wed, 29 Oct 2003 20:43:27 +0000 Received: from isi.edu (wireless225.east.isi.edu [65.123.202.225]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id h9TKhPj26728; Wed, 29 Oct 2003 12:43:25 -0800 (PST) Date: Wed, 29 Oct 2003 15:43:32 -0500 Subject: Re: Large typecodes and DNSSEC Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Michael Graff , namedroppers@ops.ietf.org To: Daniel Massey From: Daniel Massey In-Reply-To: Message-Id: <8F2EA9A2-0A50-11D8-A3BA-000393C783A2@isi.edu> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, After some discussions, here is a summary of the various previously proposed solutions for large typecodes: fixed limit options: a NSEC only covers up to 127 (by fiat) [0] b NSEC expands bit mask to 512/1024 or some other higher number. [3] order list options c NSEC covers 1-127 with bit mask and "ordered list" after that. [4] d NSEC with bit 0 set is turned into "ordered list" [1] e NSECbis has "ordered list" and replaces NSEC [2] other extensions f NSEC covers types 1-127 and a FOO extends coverage for 129-n [5] Historical Footnotes: [0] The bit field was proposed for efficiency reasons. [1] This is what Andreas proposed in 1997, [2] This was proposed to Sam when he started the TCR draft. [3] Original DNSSEC spec had typecode bitmap unrestricted, due to [1] and size concerns related to Truncation and OS vendor use of types in the 64xxx space, the restriction and bit 0 was put in. [4] This was also proposed in the 1997 after [3] was put forward. [5] This is yet another option from the previous message. To close the records and protocol doc, consensus on one option is needed. From a document editing perspective, quick consensus would be very very welcome. (Note prior to this, last call seemed in sight for the records doc) In my personal view.... One fundamental problem is that if there are multiple type field variations, it is possible implementations will not understand them all and it is probable that the code path for one of the type fields has a bug. In particular, suppose we allow multiple type fields and someone implements only the 127 bit format current in records (or implements the other fields incorrectly, but it is not tested since types are < 127). Everything works great for now with types < 127, but when the first RR type greater than 127 is added, suddenly the altnerate NSEC RR formats are needed to correctly process A record queries. types will roll.... My plea is we pick an encoding of the type field such that there is one and only one method to authenticate non-existence of the good old A record (as well as other current types like DS records). this method must work now and still work if the type space exceeds 127. For the ordered list options, I would also hope that the ordering is not overly complex. The type space may grow, but hopefully the number of records types at a given name will not stretch in into the thousands or even dozens. A simple list is more likely be done correctly. Under these criteria, option c, e and f work. options a and b postpone the problem to when the space type space grows large. option d creates multiple code paths for authenticated denial of existence for the good old A record. Dan -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Oct 29 15:56: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 PAA05706 for ; Wed, 29 Oct 2003 15:56:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AExJ9-000Haq-L1 for namedroppers-data@psg.com; Wed, 29 Oct 2003 20:52:47 +0000 Received: from [2001:4f8:3:ba:2d0:a8ff:fe00:5581] (helo=gusto.araneus.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AExJ4-000HaB-2M for namedroppers@ops.ietf.org; Wed, 29 Oct 2003 20:52:42 +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.10/8.12.9) with ESMTP id h9TKqe8V020689; Wed, 29 Oct 2003 12:52:40 -0800 (PST) Received: from guava.araneus.fi (localhost [127.0.0.1]) by guava.araneus.fi (8.12.10/8.11.6) with ESMTP id h9TKqeUo000032; Wed, 29 Oct 2003 12:52:40 -0800 (PST) Received: (from gson@localhost) by guava.araneus.fi (8.12.10/8.12.6/Submit) id h9TKqbAp016451; Wed, 29 Oct 2003 12:52:37 -0800 (PST) Date: Wed, 29 Oct 2003 12:52:37 -0800 (PST) Message-Id: <200310292052.h9TKqbAp016451@guava.araneus.fi> To: namedroppers@ops.ietf.org Subject: Re: Large typecodes and DNSSEC In-Reply-To: References: <200310281402.41950.davidb@verisignlabs.com> <200310281647.45423.davidb@verisignlabs.com> <200310281848.26163.davidb@verisignlabs.com> <20031029154141.GA27166@chinook.rgy.netsol.com> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_RFCI autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Brian Wellington writes: > Given that the typecodes are being rolled, we might want to consider > removing the old format completely, and coming up with a new, sane format > that doesn't have any problem representing all types within the type > code space. > > The compressed format in this document seems like it does that, and it's > fairly efficient for typical cases. > [...] > I propose that we standardize on this (or something better, if anyone has > a better idea) as the only format and get rid of versioning. I agree. Given that the RR type is changing, keeping the old format is pointless. There is also the issue that any scheme that allows the server to freely choose between multiple alternative wire encodings will not actually work. This is because DNSSEC signatures are calculated by hashing the wire-format data, under the assumption that every RR has a single, unique wire encoding. If you allow multiple alternative encodings, you can end up with a situation where the signer calculates the signatures using one encoding but the name server sends the NSEC records using a different encoding, and the signatures will fail to match. -- Andreas Gustafsson, gson@nominum.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Oct 29 17:41:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11805 for ; Wed, 29 Oct 2003 17:41:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEytz-000Pri-7J for namedroppers-data@psg.com; Wed, 29 Oct 2003 22:34:55 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEytw-000PrT-Tp for namedroppers@ops.ietf.org; Wed, 29 Oct 2003 22:34:53 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id h9TMWus3008162 for ; Wed, 29 Oct 2003 17:32:56 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA8Yai8p; Wed, 29 Oct 03 17:32:55 -0500 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id h9TMXSl7000267; Wed, 29 Oct 2003 17:33:28 -0500 (EST) Date: Wed, 29 Oct 2003 23:33:28 +0100 (CET) From: Samuel Weiler X-X-Sender: weiler@filbert To: Daniel Massey cc: Michael Graff , namedroppers@ops.ietf.org Subject: Re: Large typecodes and DNSSEC In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Type 128 is the FOO record. The FOO record MUST be present at a name How do you prove that there should or shouldn't be a FOO? And the FOO would have to be added to wildcard proofs, too. This is too messy. Let's just change the NSEC format. -- 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 Wed Oct 29 18:26:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14655 for ; Wed, 29 Oct 2003 18:26:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEzdf-00029k-S1 for namedroppers-data@psg.com; Wed, 29 Oct 2003 23:22:07 +0000 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEzdc-00029W-Ay for namedroppers@ops.ietf.org; Wed, 29 Oct 2003 23:22:04 +0000 Received: from isi.edu (wireless225.east.isi.edu [65.123.202.225]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id h9TNLtj22296; Wed, 29 Oct 2003 15:21:56 -0800 (PST) Date: Wed, 29 Oct 2003 18:22:03 -0500 Subject: Re: Large typecodes and DNSSEC Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Daniel Massey , namedroppers@ops.ietf.org To: Samuel Weiler From: Daniel Massey In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, October 29, 2003, at 05:33 PM, Samuel Weiler wrote: >> Type 128 is the FOO record. The FOO record MUST be present at a >> name > > How do you prove that there should or shouldn't be a FOO? this is bit zero in the NSIG. bit zero = 1 proves there are types greater than 127 at this name (and proves there is a FOO RR that lists these types) bit zero = 0 proves there are no type greater than 127 at this name (and proves there is no FOO RR at the name) > And the FOO > would have to be added to wildcard proofs, too. the wildcard proof still relies on NSEC records. You use the algorithm discussed the current protocol draft to prove whether the name exists/whether the wildcard applies. At the end of the current NSEC proof, if the answer you seek is type > 127, you need the FOO RR to prove the type does/does not exist. > This is too messy. > Let's just change the NSEC format. > > it is unquestionably ugly. the intent is to make things work in the scenario that says: use format X if all type codes at this name are less than 127, use format Y if some types codes at this name are above 127, use format Z the zone is signed on tuesday, your master server has a black case, and your favorite type number is 3 this way lies madness and FOO RRs :) but this is also the current approach and the FOO RR is intended only to make that madness work. the clean fix is to scrap the existing format and define a **single** format for the NSEC type field that works for all RR types. Dan -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Oct 29 19:04: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 TAA15968 for ; Wed, 29 Oct 2003 19:04:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AF0Dc-0003kc-6Y for namedroppers-data@psg.com; Wed, 29 Oct 2003 23:59:16 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AF0DZ-0003kQ-JB for namedroppers@ops.ietf.org; Wed, 29 Oct 2003 23:59:13 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id h9TMiFXo008587 for ; Wed, 29 Oct 2003 17:44:15 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA7OaqXq; Wed, 29 Oct 03 17:44:15 -0500 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id h9TMimRK000750; Wed, 29 Oct 2003 17:44:48 -0500 (EST) Date: Wed, 29 Oct 2003 23:44:48 +0100 (CET) From: Samuel Weiler X-X-Sender: weiler@filbert To: Andreas Gustafsson cc: namedroppers@ops.ietf.org Subject: Re: Large typecodes and DNSSEC In-Reply-To: <200310292052.h9TKqbAp016451@guava.araneus.fi> Message-ID: References: <200310281402.41950.davidb@verisignlabs.com> <200310281647.45423.davidb@verisignlabs.com> <200310281848.26163.davidb@verisignlabs.com> <20031029154141.GA27166@chinook.rgy.netsol.com> <200310292052.h9TKqbAp016451@guava.araneus.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > There is also the issue that any scheme that allows the server to > freely choose between multiple alternative wire encodings will not > actually work. This is because DNSSEC signatures are calculated by If Andreas is right, and I think he is, then David's strawcritter: > - use the remaining 7 bits in the first octet as a count of > single-byte typecodes, called N. The next N octets are an ordered > list of 8-bit integers representing typecodes <= 255. The remaining > RDATA is an ordered list of 16-bit big-endian unsigned integers, > each representing one type present. may open the door to ambiguity -- can one set N=0 and list codes 3, 5, and 7 in the 16-bit portion? Micheal's format 1 may have the same problem. Is there anything wrong with the ordered list of 16-bit values proposed separately by Rob and Micheal (format 0)? Since the bits for NSEC and RRSIG then take up space, do we want to make them implicit? We could turn the silly-state language around and say "if either of these typecodes is explicitly listed, treat this name as unsecured". -- 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 Wed Oct 29 20:26: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 UAA18716 for ; Wed, 29 Oct 2003 20:26:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AF1TO-00082s-7c for namedroppers-data@psg.com; Thu, 30 Oct 2003 01:19:38 +0000 Received: from [2002:425c:4242:0:250:daff:fe82:1c39] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AF1TK-00081w-RW for namedroppers@ops.ietf.org; Thu, 30 Oct 2003 01:19:35 +0000 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 2887D18F3 for ; Wed, 29 Oct 2003 20:19:33 -0500 (EST) Date: Wed, 29 Oct 2003 20:19:33 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Large typecodes and DNSSEC In-Reply-To: <200310292052.h9TKqbAp016451@guava.araneus.fi> References: <200310281402.41950.davidb@verisignlabs.com> <200310281647.45423.davidb@verisignlabs.com> <200310281848.26163.davidb@verisignlabs.com> <20031029154141.GA27166@chinook.rgy.netsol.com> <200310292052.h9TKqbAp016451@guava.araneus.fi> 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: <20031030011933.2887D18F3@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Wed, 29 Oct 2003 12:52:37 -0800 (PST), Andreas Gustafsson wrote: > ... > There is also the issue that any scheme that allows the server to > freely choose between multiple alternative wire encodings will not > actually work. This is because DNSSEC signatures are calculated by > hashing the wire-format data, under the assumption that every RR has a > single, unique wire encoding. If you allow multiple alternative > encodings, you can end up with a situation where the signer calculates > the signatures using one encoding but the name server sends the NSEC > records using a different encoding, and the signatures will fail to > match. You appear to be assuming some form of RDATA transcoding. We have that problem for certain well-known types containing DNS names due to ancient history, but I don't understand why we would allow it here. So long as the RRset received matches the RRset sent, the signatures should match. sig(2) == sig(2). sig(ii) == sig(ii). The fact that "2" and "ii" are different ways of writing the number two shouldn't matter unless somebody's translating from arabic to roman numbering en route. At least one of us is confused. -- to unsubscribe send a message to namedroppers-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 Oct 29 20:56:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20001 for ; Wed, 29 Oct 2003 20:56:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AF1zW-0009el-Fl for namedroppers-data@psg.com; Thu, 30 Oct 2003 01:52:50 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AF1zT-0009eY-QJ for namedroppers@ops.ietf.org; Thu, 30 Oct 2003 01:52:47 +0000 Received: from incognito.ddns.nominum.com (dhcp-101.wl.nominum.com [81.200.65.101]) by shell-ng.nominum.com (Postfix) with ESMTP id E55135683D for ; Wed, 29 Oct 2003 17:52:46 -0800 (PST) Received: from incognito.ddns.nominum.com (localhost [127.0.0.1]) by incognito.ddns.nominum.com (8.12.8/8.12.8) with ESMTP id h9U1qksl005252; Wed, 29 Oct 2003 17:52:46 -0800 Received: from localhost (bwelling@localhost) by incognito.ddns.nominum.com (8.12.8/8.12.8/Submit) with ESMTP id h9U1qj5G005248; Wed, 29 Oct 2003 17:52:45 -0800 X-Authentication-Warning: incognito.ddns.nominum.com: bwelling owned process doing -bs Date: Wed, 29 Oct 2003 17:52:45 -0800 (PST) From: Brian Wellington X-X-Sender: bwelling@incognito.ddns.nominum.com To: Samuel Weiler Cc: namedroppers@ops.ietf.org Subject: Re: Large typecodes and DNSSEC In-Reply-To: Message-ID: References: <200310281402.41950.davidb@verisignlabs.com> <200310281647.45423.davidb@verisignlabs.com> <200310281848.26163.davidb@verisignlabs.com> <20031029154141.GA27166@chinook.rgy.netsol.com> <200310292052.h9TKqbAp016451@guava.araneus.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 29 Oct 2003, Samuel Weiler wrote: > > There is also the issue that any scheme that allows the server to > > freely choose between multiple alternative wire encodings will not > > actually work. This is because DNSSEC signatures are calculated by > > If Andreas is right, and I think he is, then David's strawcritter: > > > - use the remaining 7 bits in the first octet as a count of > > single-byte typecodes, called N. The next N octets are an ordered > > list of 8-bit integers representing typecodes <= 255. The remaining > > RDATA is an ordered list of 16-bit big-endian unsigned integers, > > each representing one type present. > > may open the door to ambiguity -- can one set N=0 and list codes 3, 5, > and 7 in the 16-bit portion? Micheal's format 1 may have the same > problem. Both of the formats in Michael's proposal include the phrase 'in increasing value.' This should make the representation unique, as long as only one format is chosen. > Is there anything wrong with the ordered list of 16-bit values > proposed separately by Rob and Micheal (format 0)? Since the bits for > NSEC and RRSIG then take up space, do we want to make them implicit? > We could turn the silly-state language around and say "if either of > these typecodes is explicitly listed, treat this name as unsecured". Adding special cases for RRSIG and NSEC is confusing. Using a 16 bit value is fine also. The only difference is that the compressed method allows all combinations of the 64K type codes to be represented without exceeding the 64K limit for rdata, not that this really matters. Brian -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Oct 29 21:23: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 VAA20840 for ; Wed, 29 Oct 2003 21:23:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AF2Og-000AyL-Gq for namedroppers-data@psg.com; Thu, 30 Oct 2003 02:18:50 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AF2OW-000Axx-Dj for namedroppers@ops.ietf.org; Thu, 30 Oct 2003 02:18:40 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 6233A1395D for ; Thu, 30 Oct 2003 01:45:43 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Large typecodes and DNSSEC In-Reply-To: Message from Rob Austein of "Wed, 29 Oct 2003 20:19:33 EST." <20031030011933.2887D18F3@thrintun.hactrn.net> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 30 Oct 2003 01:45:43 +0000 Message-Id: <20031030014543.6233A1395D@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > You appear to be assuming some form of RDATA transcoding. ... yes. > sig(2) == sig(2). sig(ii) == sig(ii). The fact that "2" and "ii" are > different ways of writing the number two shouldn't matter unless > somebody's translating from arabic to roman numbering en route. a cache who converted an rdata from wire format to host-byte-order and regenerated the wire format when queried for it could have that property. -- to unsubscribe send a message to namedroppers-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 Oct 29 21:49: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 VAA21544 for ; Wed, 29 Oct 2003 21:49:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AF2oU-000CR6-5e for namedroppers-data@psg.com; Thu, 30 Oct 2003 02:45:30 +0000 Received: from [65.201.175.62] (helo=cliffie.verisignlabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AF2oQ-000CQm-52 for namedroppers@ops.ietf.org; Thu, 30 Oct 2003 02:45:26 +0000 Received: from [192.168.1.13] ([::ffff:68.48.27.14]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by cliffie.verisignlabs.com with esmtp; Wed, 29 Oct 2003 21:45:25 -0500 Mime-Version: 1.0 (Apple Message framework v606) In-Reply-To: <20031030011933.2887D18F3@thrintun.hactrn.net> References: <200310281402.41950.davidb@verisignlabs.com> <200310281647.45423.davidb@verisignlabs.com> <200310281848.26163.davidb@verisignlabs.com> <20031029154141.GA27166@chinook.rgy.netsol.com> <200310292052.h9TKqbAp016451@guava.araneus.fi> <20031030011933.2887D18F3@thrintun.hactrn.net> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1C36E0D0-0A83-11D8-B7A1-000393A3322E@verisignlabs.com> Content-Transfer-Encoding: 7bit From: David Blacka Subject: Re: Large typecodes and DNSSEC Date: Wed, 29 Oct 2003 21:45:23 -0500 To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.606) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Oct 29, 2003, at 8:19 PM, Rob Austein wrote: > At Wed, 29 Oct 2003 12:52:37 -0800 (PST), Andreas Gustafsson wrote: >> ... >> There is also the issue that any scheme that allows the server to >> freely choose between multiple alternative wire encodings will not >> actually work. This is because DNSSEC signatures are calculated by >> hashing the wire-format data, under the assumption that every RR has a >> single, unique wire encoding. If you allow multiple alternative >> encodings, you can end up with a situation where the signer calculates >> the signatures using one encoding but the name server sends the NSEC >> records using a different encoding, and the signatures will fail to >> match. > > You appear to be assuming some form of RDATA transcoding. We have > that problem for certain well-known types containing DNS names due to > ancient history, but I don't understand why we would allow it here. > So long as the RRset received matches the RRset sent, the signatures > should match. > > sig(2) == sig(2). sig(ii) == sig(ii). The fact that "2" and "ii" are > different ways of writing the number two shouldn't matter unless > somebody's translating from arabic to roman numbering en route. > > At least one of us is confused. I think what Andreas is talking about is this: If there are two equally valid wire representations of the same record, there exists a possibility for say, the signer to do it one way, and the nameserver to encode it another. Since the textual representation is the same either way, there is nothing to prevent this. However, having multiple NSEC typecode formats is not a problem per se. The issue is that all DNSSEC software must encode a particular NSEC record the exact same way. This could be accomplished by saying something like: use format 1 when no typecodes > 127, format 2 otherwise. But, that being said, I can see no good reason for having more than one format in any case. I think what we are looking for in a format is: * easy to understand. * easy to implement. * reasonably space efficient for "common" cases. -- David Blacka Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Oct 29 21:49: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 VAA21564 for ; Wed, 29 Oct 2003 21:49:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AF2nV-000CMB-Dz for namedroppers-data@psg.com; Thu, 30 Oct 2003 02:44:29 +0000 Received: from [2001:4f8:3:ba:2d0:a8ff:fe00:5581] (helo=gusto.araneus.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AF2nS-000CLl-SR for namedroppers@ops.ietf.org; Thu, 30 Oct 2003 02:44: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.10/8.12.9) with ESMTP id h9U2iK8V020751; Wed, 29 Oct 2003 18:44:20 -0800 (PST) Received: from guava.araneus.fi (localhost [127.0.0.1]) by guava.araneus.fi (8.12.10/8.11.6) with ESMTP id h9U2iLUo017219; Wed, 29 Oct 2003 18:44:21 -0800 (PST) Received: (from gson@localhost) by guava.araneus.fi (8.12.10/8.12.6/Submit) id h9U2iKSx023479; Wed, 29 Oct 2003 18:44:20 -0800 (PST) Date: Wed, 29 Oct 2003 18:44:20 -0800 (PST) Message-Id: <200310300244.h9U2iKSx023479@guava.araneus.fi> To: Rob Austein Cc: namedroppers@ops.ietf.org Subject: Re: Large typecodes and DNSSEC In-Reply-To: <20031030011933.2887D18F3@thrintun.hactrn.net> References: <200310281402.41950.davidb@verisignlabs.com> <200310281647.45423.davidb@verisignlabs.com> <200310281848.26163.davidb@verisignlabs.com> <20031029154141.GA27166@chinook.rgy.netsol.com> <200310292052.h9TKqbAp016451@guava.araneus.fi> <20031030011933.2887D18F3@thrintun.hactrn.net> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_RFCI autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Rob Austein writes: > At Wed, 29 Oct 2003 12:52:37 -0800 (PST), Andreas Gustafsson wrote: > > There is also the issue that any scheme that allows the server to > > freely choose between multiple alternative wire encodings will not > > actually work. This is because DNSSEC signatures are calculated by > > hashing the wire-format data, under the assumption that every RR has a > > single, unique wire encoding. If you allow multiple alternative > > encodings, you can end up with a situation where the signer calculates > > the signatures using one encoding but the name server sends the NSEC > > records using a different encoding, and the signatures will fail to > > match. > > You appear to be assuming some form of RDATA transcoding. We have > that problem for certain well-known types containing DNS names due to > ancient history, but I don't understand why we would allow it here. > So long as the RRset received matches the RRset sent, the signatures > should match. I'm not sure what you mean by "transcoding". The RRset received is identical to the one sent. The problem is that the sequence of bytes over which the DNSSEC signer calculates the signature when signing the zone can be different from the sequence of bytes over which the resolver calculates the signature when validating a response. For example, suppose we have a domain name "zz." which is the last name in the root zone, with only an A record and (after signing) an NSEC record. Then the DNSSEC signer will insert an NSEC record of the form zz. NSEC . A NSEC Suppose the signer chooses to represent this using the classic RFC2535 bitmap representation. Then it will internally create an NSEC RDATA containing the bytes 00 40 00 00 00 00 00 80 and SIG NSEC record containing the signature of those bytes. The signer writes the NSEC and SIG NSEC records to a signed master file. The signed master file is then loaded by a master server. Suppose the master server chooses to represent this same NSEC record using Michael Graff's uncompressed 16-bit wire format. When queried, it will send an NSEC RR with an RDATA of 00 80 00 01 00 30 along with a SIG NSEC record that was calculated by the signer under the assumption that the RDATA is 00 40 00 00 00 00 00 80. When the resolver attempts to validate the response, it calculates a signature over the bytes 00 80 00 01 00 30. This signature will then fail to match the one in the SIG NSEC. The byte sequences in the example above were constructed by hand in a hurry and may not have all the right bits set, but that should not detract from my point, that the signatures calculated by different parties of the protocol can end up being different. -- Andreas Gustafsson, gson@nominum.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Oct 29 23:19: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 XAA24007 for ; Wed, 29 Oct 2003 23:19:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AF4AX-000GfI-Js for namedroppers-data@psg.com; Thu, 30 Oct 2003 04:12:21 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AF4AU-000Gf2-T6 for namedroppers@ops.ietf.org; Thu, 30 Oct 2003 04:12:19 +0000 Received: (qmail 6838 invoked from network); 30 Oct 2003 04:15:39 -0000 Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp) (131.112.32.134) by necom830.hpcl.titech.ac.jp with SMTP; 30 Oct 2003 04:15:39 -0000 Message-ID: <3FA08FF3.2000708@necom830.hpcl.titech.ac.jp> Date: Thu, 30 Oct 2003 13:13:39 +0900 From: masataka ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Rob Austein CC: namedroppers@ops.ietf.org Subject: Reality check (was Re: Wildcard NS and DNSSEC) References: <20031027142404.GB15077@atoom.net> <200310282352.h9SNqI8Y001833@drugs.dv.isc.org> <20031029012822.C263718DD@thrintun.hactrn.net> In-Reply-To: <20031029012822.C263718DD@thrintun.hactrn.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Rob Austein; > just forbid wildcard ns and move along, aye. I do love simple approaches. However, in this case, the complexity is not in wildcard but in DNSSEC. So, the proper question is do we need DNSSEC? and the reality is that we don't. Just discard DNSSEC and move along. 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 Thu Oct 30 00:06: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 AAA25787 for ; Thu, 30 Oct 2003 00:06:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AF4xQ-000IZl-NV for namedroppers-data@psg.com; Thu, 30 Oct 2003 05:02:52 +0000 Received: from [2002:425c:4242:0:250:daff:fe82:1c39] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AF4xK-000IZS-2W for namedroppers@ops.ietf.org; Thu, 30 Oct 2003 05:02:46 +0000 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 4CBCC18DD for ; Wed, 29 Oct 2003 23:32:29 -0500 (EST) Date: Wed, 29 Oct 2003 23:32:29 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Large typecodes and DNSSEC In-Reply-To: <200310300244.h9U2iKSx023479@guava.araneus.fi> References: <200310281402.41950.davidb@verisignlabs.com> <200310281647.45423.davidb@verisignlabs.com> <200310281848.26163.davidb@verisignlabs.com> <20031029154141.GA27166@chinook.rgy.netsol.com> <200310292052.h9TKqbAp016451@guava.araneus.fi> <20031030011933.2887D18F3@thrintun.hactrn.net> <200310300244.h9U2iKSx023479@guava.araneus.fi> 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: <20031030043229.4CBCC18DD@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Ok, I was the one who was confused. Right, if the signer and the name server use different encodings, it doesn't work. Thanks. -- to unsubscribe send a message to namedroppers-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 Oct 30 12:23:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01529 for ; Thu, 30 Oct 2003 12:23:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFGLh-000Nej-GV for namedroppers-data@psg.com; Thu, 30 Oct 2003 17:12:41 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFGLf-000NeV-4h for namedroppers@ops.ietf.org; Thu, 30 Oct 2003 17:12:39 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id h9UHAgni003749 for ; Thu, 30 Oct 2003 12:10:42 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA0eayuh; Thu, 30 Oct 03 12:10:40 -0500 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id h9UHBETw015215; Thu, 30 Oct 2003 12:11:14 -0500 (EST) Date: Thu, 30 Oct 2003 18:11:14 +0100 (CET) From: Samuel Weiler X-X-Sender: weiler@filbert To: David Blacka cc: namedroppers@ops.ietf.org Subject: Re: Large typecodes and DNSSEC In-Reply-To: <1C36E0D0-0A83-11D8-B7A1-000393A3322E@verisignlabs.com> Message-ID: References: <200310281402.41950.davidb@verisignlabs.com> <200310281647.45423.davidb@verisignlabs.com> <200310281848.26163.davidb@verisignlabs.com> <20031029154141.GA27166@chinook.rgy.netsol.com> <200310292052.h9TKqbAp016451@guava.araneus.fi> <20031030011933.2887D18F3@thrintun.hactrn.net> <1C36E0D0-0A83-11D8-B7A1-000393A3322E@verisignlabs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Discussion seems to have died down. David's criteria seem reasonable: > * easy to understand. > * easy to implement. > * reasonably space efficient for "common" cases. So I'll ask the following again: 1) Is there anything wrong with the ordered list of 16-bit values proposed separately by Rob and Micheal (format 0)? 2) Since the bits for NSEC and RRSIG then take up space, do we want to make them implicit? (Brian has said "no", I say "yes" -- any others want to speak up?) 3) If so, do we turn the silly-state language around and say "if either of these typecodes is explicitly listed, treat this name as unsecured"? -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Oct 30 12: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 MAA02034 for ; Thu, 30 Oct 2003 12:35:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFGbx-000OQH-EB for namedroppers-data@psg.com; Thu, 30 Oct 2003 17:29:29 +0000 Received: from [65.201.175.62] (helo=cliffie.verisignlabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFGbt-000OQ1-Ps for namedroppers@ops.ietf.org; Thu, 30 Oct 2003 17:29:25 +0000 Received: from pinion.admin.cto.netsol.com ([::ffff:172.25.170.10]) (AUTH: LOGIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by cliffie.verisignlabs.com with esmtp; Thu, 30 Oct 2003 12:29:25 -0500 From: David Blacka Organization: Verisign, Inc. To: namedroppers@ops.ietf.org Subject: Re: Large typecodes and DNSSEC Date: Thu, 30 Oct 2003 12:29:24 -0500 User-Agent: KMail/1.5.3 References: <200310281402.41950.davidb@verisignlabs.com> <200310292052.h9TKqbAp016451@guava.araneus.fi> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310301229.24579.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday 29 October 2003 05:44 pm, Samuel Weiler wrote: > > There is also the issue that any scheme that allows the server to > > freely choose between multiple alternative wire encodings will not > > actually work. This is because DNSSEC signatures are calculated by > > If Andreas is right, and I think he is, then David's strawcritter: > > > - use the remaining 7 bits in the first octet as a count of > > single-byte typecodes, called N. The next N octets are an ordered > > list of 8-bit integers representing typecodes <= 255. The remaining > > RDATA is an ordered list of 16-bit big-endian unsigned integers, > > each representing one type present. > > may open the door to ambiguity -- can one set N=0 and list codes 3, 5, > and 7 in the 16-bit portion? Micheal's format 1 may have the same > problem. Hah. Now that it seems somewhat OK to ditch the bit map, I can improve my strawcritter: Use the first octet as a count of typecodes < 256, called N. The next N octets are an ascending list of 8-bit integers representing typecodes < 256. The remaining RDATA is an ascending list of 16-bit big-endian unsigned integers greater than 255 representing typecodes > = 256. Actually, this isn't all that different from Michael's "compressed" format, except that it doesn't have any flag fields, and it doesn't attempt to compress larger typecodes, which would also probably be OK. -- David Blacka Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Oct 30 12:41: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 MAA02357 for ; Thu, 30 Oct 2003 12:41:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFGiw-000Op0-Ow for namedroppers-data@psg.com; Thu, 30 Oct 2003 17:36:42 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFGiu-000Ooi-79 for namedroppers@ops.ietf.org; Thu, 30 Oct 2003 17:36:40 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 3E3E65684D for ; Thu, 30 Oct 2003 09:36:39 -0800 (PST) Message-Id: <6.0.0.22.2.20031030121608.033ec788@localhost> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 30 Oct 2003 12:36:28 -0500 To: namedroppers@ops.ietf.org From: Mike StJohns Subject: Section 4 of dnssec-protocol-03 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Comments: Section 4, page 20. "Trusted starting point". A more precise term might be "trust anchor". Page 20, para beginning "A security-aware resolver..." delete "MUST be capable....key, and" - the latter clause includes the meaning of the indicated clause. Add at end of para "However, such mechanisms are out of scope for this document." And the meat of the matter: Would it make sense to add a second bit mirroring the DO bit to indicate a new DNSSEC query rather than an old DNSSEC query? DO would indicate an old DNSSEC query, DX would indicate a new query. E.g. how do we handle the legacy case? *sigh* Mike -- to unsubscribe send a message to namedroppers-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 Oct 30 14:22:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05512 for ; Thu, 30 Oct 2003 14:22:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFII4-0003TY-D6 for namedroppers-data@psg.com; Thu, 30 Oct 2003 19:17:04 +0000 Received: from [2001:4f8:3:bb:290:27ff:fe73:8215] (helo=farside.isc.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFIHs-0003SE-4p for namedroppers@ops.ietf.org; Thu, 30 Oct 2003 19:16:52 +0000 Received: by farside.isc.org (Postfix, from userid 10015) id C5E2DA863; Thu, 30 Oct 2003 19:16:51 +0000 (UTC) To: Brian Wellington Cc: Samuel Weiler , namedroppers@ops.ietf.org Subject: Re: Large typecodes and DNSSEC References: <200310281402.41950.davidb@verisignlabs.com> <200310281647.45423.davidb@verisignlabs.com> <200310281848.26163.davidb@verisignlabs.com> <20031029154141.GA27166@chinook.rgy.netsol.com> <200310292052.h9TKqbAp016451@guava.araneus.fi> From: Michael Graff Date: Thu, 30 Oct 2003 19:16:51 +0000 In-Reply-To: (Brian Wellington's message of "Wed, 29 Oct 2003 17:52:45 -0800 (PST)") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Brian Wellington writes: > Adding special cases for RRSIG and NSEC is confusing. Using a 16 bit > value is fine also. The only difference is that the compressed method > allows all combinations of the 64K type codes to be represented without > exceeding the 64K limit for rdata, not that this really matters. I personally like the idea of being able to represent many types, so I'd rather see the compressed format move forward and the 16-bit values method go away. --Michael -- to unsubscribe send a message to namedroppers-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 Oct 30 14:36: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 OAA06497 for ; Thu, 30 Oct 2003 14:36:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFIX2-0004VQ-Oa for namedroppers-data@psg.com; Thu, 30 Oct 2003 19:32:32 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFIWw-0004Ui-RT for namedroppers@ops.ietf.org; Thu, 30 Oct 2003 19:32:28 +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 h9UIRP0T009089 for ; Thu, 30 Oct 2003 13:27:25 -0500 (EST) Message-ID: <061f01c39f13$78666f80$b9370681@barnacle> From: "Scott Rose" To: References: <6.0.0.22.2.20031030121608.033ec788@localhost> Subject: Re: Section 4 of dnssec-protocol-03 Date: Thu, 30 Oct 2003 13:27:26 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Mike StJohns" > > And the meat of the matter: Would it make sense to add a second bit > mirroring the DO bit to indicate a new DNSSEC query rather than an old > DNSSEC query? DO would indicate an old DNSSEC query, DX would indicate a > new query. E.g. how do we handle the legacy case? *sigh* > The typecode draft/RFC (hopefully soon) discussed that idea. Servers and resolvers are supposed to ignore pre-DS DNSSEC RRs and not use them. It would also be good not to condone a "dual world" DNSSEC. One with KEY/SIG/NXT and one with the new typecodes. Right now, RFC2535 security aware resolver wouldn't be able to verify the RRSIGs, but would not be able to follow secure delegations anyway (DS RR). Having the option of allowing "2535" DNSSEC means there would have to be the same 2535-DNSSEC security chain with parent SIGs in the child zone. Basically, there is not a lot of danger in just ignoring the legacy case. DNSSEC is not widely deployed to warrent a lot of backwards compatibility. Scott > Mike > > > -- > to 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 Oct 30 14:53: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 OAA07412 for ; Thu, 30 Oct 2003 14:53:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFImh-0005V0-35 for namedroppers-data@psg.com; Thu, 30 Oct 2003 19:48:43 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFIme-0005Ui-Ow for namedroppers@ops.ietf.org; Thu, 30 Oct 2003 19:48:40 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 089951395D for ; Thu, 30 Oct 2003 18:42:11 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Large typecodes and DNSSEC In-Reply-To: Message from Samuel Weiler of "Thu, 30 Oct 2003 18:11:14 +0100." X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 30 Oct 2003 18:42:11 +0000 Message-Id: <20031030184211.089951395D@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > 1) Is there anything wrong with the ordered list of 16-bit values > proposed separately by Rob and Micheal (format 0)? nope. > 2) Since the bits for NSEC and RRSIG then take up space, do we want to > make them implicit? (Brian has said "no", I say "yes" -- any others > want to speak up?) implicit is bad. the space savings is negligible compared to the size of the signature and key blobs. explicit is less error prone, or rather, will lead to earlier signalling of logic/protocol errors, compared to implicit. > 3) If so, do we turn the silly-state language around and say "if > either of these typecodes is explicitly listed, treat this name as > unsecured"? no. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Oct 30 16:08: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 QAA11688 for ; Thu, 30 Oct 2003 16:08:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFJx4-00096e-87 for namedroppers-data@psg.com; Thu, 30 Oct 2003 21:03:30 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFJx1-00096S-OQ for namedroppers@ops.ietf.org; Thu, 30 Oct 2003 21:03:27 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id B7A9A5684A; Thu, 30 Oct 2003 13:03:26 -0800 (PST) Message-Id: <6.0.0.22.2.20031030153413.033ffe40@localhost> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 30 Oct 2003 16:03:25 -0500 To: "Scott Rose" , From: Mike StJohns Subject: Re: Section 4 of dnssec-protocol-03 In-Reply-To: <061f01c39f13$78666f80$b9370681@barnacle> References: <6.0.0.22.2.20031030121608.033ec788@localhost> <061f01c39f13$78666f80$b9370681@barnacle> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 01:27 PM 10/30/2003, Scott Rose wrote: >----- Original Message ----- >From: "Mike StJohns" > > > > And the meat of the matter: Would it make sense to add a second bit > > mirroring the DO bit to indicate a new DNSSEC query rather than an old > > DNSSEC query? DO would indicate an old DNSSEC query, DX would indicate a > > new query. E.g. how do we handle the legacy case? *sigh* > > > >The typecode draft/RFC (hopefully soon) discussed that idea. Servers and >resolvers are supposed to ignore pre-DS DNSSEC RRs and not use them. Actually, I think the issue is pre-DS security aware stub resolvers talking to post-DS resolvers or vice versa. As it stands, a pre-DS aware resolver setting the DO bit can get post-DS answers that it doesn't have a clue of how to use. >Basically, there is not a lot of danger in just ignoring the legacy case. >DNSSEC is not widely deployed to warrent a lot of backwards compatibility. >Scott I think I mostly agree with this. On the other hand, we changed all the type codes to prevent problems with legacy systems - might it not make sense to make the hard separation include stub to recursive resolver signalling? Its one bit in the EDNS0 header. > > Mike > > > > > > -- > > to 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 Thu Oct 30 16: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 QAA14132 for ; Thu, 30 Oct 2003 16:35:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFKO5-000BBR-Bg for namedroppers-data@psg.com; Thu, 30 Oct 2003 21:31:25 +0000 Received: from [2002:425c:4242:0:250:daff:fe82:1c39] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFKO2-000BB5-Gr for namedroppers@ops.ietf.org; Thu, 30 Oct 2003 21:31:22 +0000 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id C03B318DD for ; Thu, 30 Oct 2003 16:31:20 -0500 (EST) Date: Thu, 30 Oct 2003 16:31:20 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Section 4 of dnssec-protocol-03 In-Reply-To: <6.0.0.22.2.20031030153413.033ffe40@localhost> References: <6.0.0.22.2.20031030121608.033ec788@localhost> <061f01c39f13$78666f80$b9370681@barnacle> <6.0.0.22.2.20031030153413.033ffe40@localhost> 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: <20031030213120.C03B318DD@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Thu, 30 Oct 2003 16:03:25 -0500, Michael StJohns wrote: > > Actually, I think the issue is pre-DS security aware stub resolvers talking > to post-DS resolvers or vice versa. As it stands, a pre-DS aware resolver > setting the DO bit can get post-DS answers that it doesn't have a clue of > how to use. > ... > I think I mostly agree with this. On the other hand, we changed all the > type codes to prevent problems with legacy systems - might it not make > sense to make the hard separation include stub to recursive resolver > signalling? Its one bit in the EDNS0 header. I don't feel strongly about this, but here's my take, for what it's worth. The primary purpose of the DO bit is to keep old buggy code from dumping core upon seeing DNSSEC records (by keeping said buggy code from ever seeing DNSSEC). I have not seen this happen myself, but I've been assured that this was a real problem for some old buggy implementations. Nobody ever claimed that this was anything but broken behavior on the part of the old code, but it was a real operational problem that stood in the way of deployment, and this seemed the least bad answer to it. The situation with pre-DS and post-DS DNSSEC is not analagous, unless somebody steps forward to claim that there's code deployed now that will is ok with pre-DS DNSSEC but dumps core upon seeing post-DS DNSSEC. While I suppose that's possible, it seems less likely, and I haven't heard anybody make such a claim. So I conclude that we probably don't need another bit. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Oct 30 18:31: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 SAA20396 for ; Thu, 30 Oct 2003 18:31:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFMAM-000IPO-46 for namedroppers-data@psg.com; Thu, 30 Oct 2003 23:25:22 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFMAK-000IPA-Cj for namedroppers@ops.ietf.org; Thu, 30 Oct 2003 23:25:20 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 018131396A for ; Thu, 30 Oct 2003 22:55:42 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Section 4 of dnssec-protocol-03 In-Reply-To: Message from Rob Austein of "Thu, 30 Oct 2003 16:31:20 EST." <20031030213120.C03B318DD@thrintun.hactrn.net> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 30 Oct 2003 22:55:42 +0000 Message-Id: <20031030225542.018131396A@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ... > So I conclude that we probably don't need another bit. Me, too! -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Oct 31 10:51: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 KAA04540 for ; Fri, 31 Oct 2003 10:51:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFbQj-000Njx-Mt for namedroppers-data@psg.com; Fri, 31 Oct 2003 15:43:17 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFbQX-000Nix-Jl for namedroppers@ops.ietf.org; Fri, 31 Oct 2003 15:43:05 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id h9VFSEDd014222 for ; Fri, 31 Oct 2003 10:28:14 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAx2aGXB; Fri, 31 Oct 03 10:28:12 -0500 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id h9VFSjLR009561; Fri, 31 Oct 2003 10:28:45 -0500 (EST) Date: Fri, 31 Oct 2003 16:28:44 +0100 (CET) From: Samuel Weiler X-X-Sender: weiler@filbert To: Mike StJohns cc: namedroppers@ops.ietf.org Subject: Re: Section 4 of dnssec-protocol-03 In-Reply-To: <6.0.0.22.2.20031030153413.033ffe40@localhost> Message-ID: References: <6.0.0.22.2.20031030121608.033ec788@localhost> <061f01c39f13$78666f80$b9370681@barnacle> <6.0.0.22.2.20031030153413.033ffe40@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 30 Oct 2003, Mike StJohns wrote: > ... we changed all the type codes to prevent problems with legacy > systems - might it not make sense to make the hard separation > include stub to recursive resolver signalling? Its one bit in the > EDNS0 header. I find it interesting how questions that have been discussed at length, including in last-called and IESG-approved documents (albeit ones not yet out of the RFC editor's queue), keep getting raised. See section 2.3 of the TCR draft, which went to IETF last call on July 16th and was approved for publication on 21 August. If the standards process is letting documents through with too little review, then we have bigger problems than a header bit will fix. -- 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 Oct 31 11:23:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05773 for ; Fri, 31 Oct 2003 11:23:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFc1E-0000K9-UV for namedroppers-data@psg.com; Fri, 31 Oct 2003 16:21:00 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFc1A-0000Jm-Q3 for namedroppers@ops.ietf.org; Fri, 31 Oct 2003 16:20:56 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 4200D5684F for ; Fri, 31 Oct 2003 08:20:55 -0800 (PST) Message-Id: <6.0.0.22.2.20031031104821.03555cb8@localhost> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 31 Oct 2003 11:20:55 -0500 To: namedroppers@ops.ietf.org From: Mike StJohns Subject: Re: Section 4 of dnssec-protocol-03 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_390180760==.ALT" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --=====================_390180760==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 10:36 AM 10/31/2003, Mike StJohns wrote: >At 10:28 AM 10/31/2003, Samuel Weiler wrote: >>On Thu, 30 Oct 2003, Mike StJohns wrote: >> >> > ... we changed all the type codes to prevent problems with legacy >> > systems - might it not make sense to make the hard separation >> > include stub to recursive resolver signalling? Its one bit in the >> > EDNS0 header. >> >>I find it interesting how questions that have been discussed at >>length, including in last-called and IESG-approved documents (albeit >>ones not yet out of the RFC editor's queue), keep getting raised. Yup. But this document is supposed to represent a complete compilation of all the little twiddles in the virtual forest of documents making up the DNSSEC stuff. And a *replacement* for those documents - e.g. when complete, this document will represent ground truth and the other documents will be deprecated. So by the normal standards process, its legitimate to give this a second look. I don't mind treating it as settled though - I mentioned it because it seemed strange to change one thing without changing the other. So leave it as is and lets move on. >>See section 2.3 of the TCR draft, which went to IETF last call on July >>16th and was approved for publication on 21 August. If the standards >>process is letting documents through with too little review, then we >>have bigger problems than a header bit will fix. Actually, what the current -05 version of this (-03 was what was submitted to the IESG) says is " It could, though, be considered in addition to changing the RR type codes." referring to adding a second DO type bit. It didn't actually make a decision except by not mentioning it further. >>-- Sam --=====================_390180760==.ALT Content-Type: text/html; charset="us-ascii" At 10:36 AM 10/31/2003, Mike StJohns wrote:
At 10:28 AM 10/31/2003, Samuel Weiler wrote:
On Thu, 30 Oct 2003, Mike StJohns wrote:

> ... we changed all the type codes to prevent problems with legacy
> systems - might it not make sense to make the hard separation
> include stub to recursive resolver signalling?  Its one bit in the
> EDNS0 header.

I find it interesting how questions that have been discussed at
length, including in last-called and IESG-approved documents (albeit
ones not yet out of the RFC editor's queue), keep getting raised.

Yup.  But this document is supposed to represent a complete compilation of all the little twiddles in the virtual forest of documents making up the DNSSEC stuff.  And a *replacement* for those documents - e.g. when complete, this document will represent ground truth and the other documents will be deprecated.  So by the normal standards process, its legitimate to give this a second look.  I don't mind treating it as settled though - I mentioned it because it seemed strange to change one thing without changing the other.  So leave it as is and lets move on.



See section 2.3 of the TCR draft, which went to IETF last call on July
16th and was approved for publication on 21 August.  If the standards
process is letting documents through with too little review, then we
have bigger problems than a header bit will fix.

Actually, what the current -05 version of this (-03 was what was submitted to the IESG) says is "
It could, though,
   be considered in addition to changing the RR type
codes."
referring to adding a second DO type bit.  It didn't actually make a decision except by not mentioning it further.


-- Sam
--=====================_390180760==.ALT-- -- to unsubscribe send a message to namedroppers-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 Oct 31 11:59: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 LAA08150 for ; Fri, 31 Oct 2003 11:59:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFcY4-0002qN-5F for namedroppers-data@psg.com; Fri, 31 Oct 2003 16:54:56 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFcXx-0002pk-Jo for namedroppers@ops.ietf.org; Fri, 31 Oct 2003 16:54:49 +0000 Received: by sa.vix.com (Postfix, from userid 716) id 6B63F1394C; Fri, 31 Oct 2003 16:54:49 +0000 (GMT) To: namedroppers@ops.ietf.org Subject: Re: Section 4 of dnssec-protocol-03 References: From: Paul Vixie Date: 31 Oct 2003 16:54:49 +0000 In-Reply-To: Message-ID: Lines: 10 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ... But this document is supposed to represent a complete compilation of > all the little twiddles in the virtual forest of documents making up the > DNSSEC stuff. And a *replacement* for those documents - e.g. when > complete, this document will represent ground truth and the other documents > will be deprecated. really? the last thing i heard from -editors was that it was all about clarifying 2535. apparently then, rolling up TCR et al will come later? -- Paul Vixie -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Oct 31 11:59:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08166 for ; Fri, 31 Oct 2003 11:59:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFcXi-0002oZ-6w for namedroppers-data@psg.com; Fri, 31 Oct 2003 16:54:34 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFcXe-0002o5-5V for namedroppers@ops.ietf.org; Fri, 31 Oct 2003 16:54:30 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id h9VGqWli018390 for ; Fri, 31 Oct 2003 11:52:32 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAt7aG6J; Fri, 31 Oct 03 11:52:31 -0500 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id h9VGr84l012922; Fri, 31 Oct 2003 11:53:08 -0500 (EST) Date: Fri, 31 Oct 2003 17:53:07 +0100 (CET) From: Samuel Weiler X-X-Sender: weiler@filbert To: David Blacka cc: namedroppers@ops.ietf.org Subject: Re: Large typecodes and DNSSEC In-Reply-To: <200310301229.24579.davidb@verisignlabs.com> Message-ID: References: <200310281402.41950.davidb@verisignlabs.com> <200310292052.h9TKqbAp016451@guava.araneus.fi> <200310301229.24579.davidb@verisignlabs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Use the first octet as a count of typecodes < 256, called N. The next N > octets are an ascending list of 8-bit integers representing typecodes < > 256. The remaining RDATA is an ascending list of 16-bit big-endian > unsigned integers greater than 255 representing typecodes > = 256. I like this strawcritter. Are we completely ditching the first octet for format/reserved bits? If so, we're breaking the "first bit set means alternate format", but I think that's a safe thing to do, given the type code roll. If not, we need a rule for what happens when the version is greater than what the resolver groks. Adapting the text I sent on Tuesday: "If you don't have a validated positive answer and the NSEC validates and you don't understand the NSEC format version, treat the name as unsecured." -- 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 Oct 31 13:01: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 NAA10804 for ; Fri, 31 Oct 2003 13:01:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFdV0-0008LB-W8 for namedroppers-data@psg.com; Fri, 31 Oct 2003 17:55:50 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFdUy-0008Ks-76 for namedroppers@ops.ietf.org; Fri, 31 Oct 2003 17:55:48 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id B3F721390E; Fri, 31 Oct 2003 17:55:37 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Samuel Weiler Cc: David Blacka , namedroppers@ops.ietf.org Subject: Re: Large typecodes and DNSSEC In-Reply-To: Message from Samuel Weiler of "Fri, 31 Oct 2003 17:53:07 +0100." X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 31 Oct 2003 17:55:37 +0000 Message-Id: <20031031175537.B3F721390E@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > Use the first octet as a count of typecodes < 256, called N. The next N > > octets are an ascending list of 8-bit integers representing typecodes < > > 256. The remaining RDATA is an ascending list of 16-bit big-endian > > unsigned integers greater than 255 representing typecodes > = 256. > > I like this strawcritter. i don't. on a strictly puritanical basis, we need a format which can represent all rrtypes, just in case 65535 of them are ever known to exist and all 65535 happen to be in use at a name. the above format is clean but since both a DNS message and an RDATA are limited to 64K octets, and an RDATA probably shares its containing DNS message with some other data an RDATA is probably limited to a size slightly smaller than 64K octets. a bit map of 64K bits would fit. michael's compressed format would fit, even in the corner case of every-other-typecode in use. if we can find something clean that is also pure, then so much the better. > Are we completely ditching the first octet for format/reserved bits? > If so, we're breaking the "first bit set means alternate format", but > I think that's a safe thing to do, given the type code roll. yes. > If not, we need a rule for what happens when the version is greater > than what the resolver groks. Adapting the text I sent on Tuesday: > "If you don't have a validated positive answer and the NSEC validates > and you don't understand the NSEC format version, treat the name as > unsecured." let's avoid optional behaviour and format versioning. -- to unsubscribe send a message to namedroppers-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 Oct 31 14:02: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 OAA13605 for ; Fri, 31 Oct 2003 14:02:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFeSN-000DLe-7p for namedroppers-data@psg.com; Fri, 31 Oct 2003 18:57:11 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFeS6-000DKQ-1k for namedroppers@ops.ietf.org; Fri, 31 Oct 2003 18:56:54 +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 h9VIuL0T014384 for ; Fri, 31 Oct 2003 13:56:22 -0500 (EST) Message-ID: <010e01c39fe0$ad7766c0$b9370681@barnacle> From: "Scott Rose" To: Subject: Q18: TTL values for RRSIG vs. RFC2181 Date: Fri, 31 Oct 2003 13:56:22 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-1.5 required=5.0 tests=BAYES_01 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Q-18: Chance for conflict with RFC 2181 and RRSIG RRs. Should RRSIG RRs be allowed to have TTL values different from each other, if the RR sets they cover have different TTL values? Background RFC2181 section 5.2: "Consequently the use of differing TTLs in an RRSet is hereby deprecated, the TTLs of all RRs in an RRSet must be the same." dnssec records 5 section 3 "The TTL value of an RRSIG RR SHOULD match the TTL value of the RRset it covers." Now consider this zone fragment: efnet.example.com. 300 IN A 10.14.88.25 300 SIG A 5 3 300 20031128150903 ( 20031029150903 11576 ... ) 3600 AAAA 2001:7b8:3:3f:201:2ff:fef6:574e 3600 SIG AAAA 5 3 3600 20031128150903 ( 20031029150903 11576 ... ) 3600 NXT ega.example.com. A SIG AAAA NXT 3600 SIG NXT 5 3 3600 20031128150903 ( 20031029150903 11576 ... ) The RRSIG RR set has different TTL values, while they cover RRsets with different TTL values. The proposed solution is to add text to the DNSSECbis protocol draft stating that RRSIG RRs are different than other RR sets in that they must have the same TTL value as the set they cover. Even if that means different values for the TTL for RRSIG RRs with the same owner name. This is an exception to the specification in RFC2181 that states that all RRs in an RRset must have the same TTL value. There is no proposed text as yet, but it will go along the lines of the section above. Hopefully in more clear text than mine. Alternatives are welcome, as well as any statement as to why we shouldn't allow this. DNSSECbis editors -- to unsubscribe send a message to namedroppers-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 Oct 31 15:09: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 PAA17403 for ; Fri, 31 Oct 2003 15:09:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFfVC-000Ig1-NG for namedroppers-data@psg.com; Fri, 31 Oct 2003 20:04:10 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFfVA-000Ifd-8E for namedroppers@ops.ietf.org; Fri, 31 Oct 2003 20:04:08 +0000 Received: from ENGILL.ogud.com (ns.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id h9VK27uG083399; Fri, 31 Oct 2003 15:02:07 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.0.0.22.2.20031031145555.0285c848@localhost> X-Sender: post@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 31 Oct 2003 15:03:58 -0500 To: "Scott Rose" , From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: Q18: TTL values for RRSIG vs. RFC2181 In-Reply-To: <010e01c39fe0$ad7766c0$b9370681@barnacle> References: <010e01c39fe0$ad7766c0$b9370681@barnacle> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 13:56 2003-10-31, Scott Rose wrote: >Q-18: Chance for conflict with RFC 2181 and RRSIG RRs. Should RRSIG RRs be >allowed to have TTL values different from each other, if the RR sets they >cover have different TTL values? IMHO it is more important that the RRSIG be cached for the same time as the RRset it is covering, than having purity among the TTL's of all the RRSIG's for one name. >Background >RFC2181 section 5.2: > > "Consequently the use of differing TTLs in an RRSet is hereby > deprecated, the TTLs of all RRs in an RRSet must be the same." > >dnssec records 5 section 3 > "The TTL value of an RRSIG RR SHOULD match the TTL value of the RRset > it covers." How about: The TTL value of an RRSIG RR SHOULD match the TTL value of the RRset it covers. Note this may lead to an apparent violation of RFC2181 section 5.2, but the RRSIG is a meta type and each RRSIG is related to a RRset and it is important that the RRSIG be cached for the same time as the RRset covered. 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 Oct 31 15:33: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 PAA18973 for ; Fri, 31 Oct 2003 15:33:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFfsI-000KrK-BW for namedroppers-data@psg.com; Fri, 31 Oct 2003 20:28:02 +0000 Received: from [2002:425c:4242:0:210:5aff:fe86:1f54] (helo=cyteen.hactrn.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFfrz-000KpW-4Z for namedroppers@ops.ietf.org; Fri, 31 Oct 2003 20:27:43 +0000 Received: from thangorodrim.hactrn.net (unknown [10.0.1.249]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "thangorodrim.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id 8F59F1DB for ; Fri, 31 Oct 2003 15:27:41 -0500 (EST) Received: from thangorodrim.hactrn.net (localhost [::1]) by thangorodrim.hactrn.net (Postfix) with ESMTP id 783AA20B9 for ; Fri, 31 Oct 2003 20:27:39 +0000 (UTC) Date: Fri, 31 Oct 2003 20:27:38 +0000 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Q18: TTL values for RRSIG vs. RFC2181 In-Reply-To: <6.0.0.22.2.20031031145555.0285c848@localhost> References: <010e01c39fe0$ad7766c0$b9370681@barnacle> <6.0.0.22.2.20031031145555.0285c848@localhost> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20031031202739.783AA20B9@thangorodrim.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Fri, 31 Oct 2003 15:03:58 -0500, Olafur Gudmundsson wrote: > > > IMHO it is more important that the RRSIG be cached for the same time > as the RRset it is covering, than having purity among the TTL's > of all the RRSIG's for one name. I agree. RRSIG RRs are bags hanging on the side of the covered RRset, and for practical purposes RRSIG RRs just don't form normal RRsets. > How about: > The TTL value of an RRSIG RR SHOULD match the TTL value of the RRset > it covers. Note this may lead to an apparent violation of RFC2181 > section 5.2, but the RRSIG is a meta type and each RRSIG is related to > a RRset and it is important that the RRSIG be cached for the same time as > the RRset covered. I don't like "meta type" ('cause then we'd have to explain what it means, which would almost certainly be harder than just saying whatever it is that we do mean in the first place...), but I think that the editors can handle the wordsmithing unless the WG feels a strong need to constrain us to specific text. The question before the WG is whether we've understood the content issue correctly. -- to unsubscribe send a message to namedroppers-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 Oct 31 17:12: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 RAA22461 for ; Fri, 31 Oct 2003 17:12:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFhQm-0003Bq-HU for namedroppers-data@psg.com; Fri, 31 Oct 2003 22:07:44 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFhQh-0003BS-SX for namedroppers@ops.ietf.org; Fri, 31 Oct 2003 22:07:39 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 973BE56890; Fri, 31 Oct 2003 14:07:38 -0800 (PST) Message-Id: <6.0.0.22.2.20031031165826.0374d8b0@localhost> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 31 Oct 2003 17:07:39 -0500 To: Paul Vixie , namedroppers@ops.ietf.org From: Mike StJohns Subject: Re: Section 4 of dnssec-protocol-03 In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:54 AM 10/31/2003, Paul Vixie wrote: > > ... But this document is supposed to represent a complete compilation of > > all the little twiddles in the virtual forest of documents making up the > > DNSSEC stuff. And a *replacement* for those documents - e.g. when > > complete, this document will represent ground truth and the other > documents > > will be deprecated. > >really? the last thing i heard from -editors was that it was all about >clarifying 2535. apparently then, rolling up TCR et al will come later? If this is what they said, I would venture that they have a much broader definition of "clarify" than I do. Clarify implies "what we really meant was..." not "we need to change some things because they didn't work". DS triggered TCR and both of those are covered within this document. With respect to the current item, there is nothing in TCR that isn't dnssec-protocol-03 and having two active standards track RFCs addressing the exact same thing seems to me to be inviting more confusion. At a minimum, when dnssec-protocol-03 is published, 2535, TCR, DS, and the original DO RFC should probably be considered superceeded and no longer authoritative for protocol purposes. >-- >Paul Vixie > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to namedroppers-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 Oct 31 17:17: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 RAA22629 for ; Fri, 31 Oct 2003 17:16:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFhWZ-0003dp-SK for namedroppers-data@psg.com; Fri, 31 Oct 2003 22:13:43 +0000 Received: from [2001:470:1f00:820:208:74ff:fe9f:eeae] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFhWW-0003dM-Kx for namedroppers@ops.ietf.org; Fri, 31 Oct 2003 22:13:40 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9p2/8.12.9) with ESMTP id h9VMDRCh006818; Sat, 1 Nov 2003 09:13:29 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200310312213.h9VMDRCh006818@drugs.dv.isc.org> To: Rob Austein Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: Q18: TTL values for RRSIG vs. RFC2181 In-reply-to: Your message of "Fri, 31 Oct 2003 20:27:38 -0000." <20031031202739.783AA20B9@thangorodrim.hactrn.net> Date: Sat, 01 Nov 2003 09:13:27 +1100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > At Fri, 31 Oct 2003 15:03:58 -0500, Olafur Gudmundsson wrote: > > > > > > IMHO it is more important that the RRSIG be cached for the same time > > as the RRset it is covering, than having purity among the TTL's > > of all the RRSIG's for one name. > > > > I agree. RRSIG RRs are bags hanging on the side of the covered RRset, > and for practical purposes RRSIG RRs just don't form normal RRsets. > > > > > How about: > > The TTL value of an RRSIG RR SHOULD match the TTL value of the RRset > > it covers. Note this may lead to an apparent violation of RFC2181 > > section 5.2, but the RRSIG is a meta type and each RRSIG is related to > > a RRset and it is important that the RRSIG be cached for the same time as > > the RRset covered. > > > > I don't like "meta type" ('cause then we'd have to explain what it > means, which would almost certainly be harder than just saying > whatever it is that we do mean in the first place...), but I think > that the editors can handle the wordsmithing unless the WG feels a > strong need to constrain us to specific text. > > The question before the WG is whether we've understood the content > issue correctly. > > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: The other solution to making this a exception is the SIG bit in the type code. The TTLs on SIGRR subtypes should be identical. -- 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 Oct 31 20:16: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 UAA27594 for ; Fri, 31 Oct 2003 20:16:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFkGd-000HON-Ve for namedroppers-data@psg.com; Sat, 01 Nov 2003 01:09:27 +0000 Received: from [202.97.224.98] (helo=mail.hl.cn) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AFkGY-000HNX-Qc for namedroppers@ops.ietf.org; Sat, 01 Nov 2003 01:09:23 +0000 Received: from mail.hl.cn([127.0.0.1]) by mail.hl.cn(AIMC 2.9.5.6) with SMTP id jmc3fa362b2; Sat, 01 Nov 2003 08:58:02 +0800 Received: from asgard.ietf.org([132.151.6.40]) by mail.hl.cn(AIMC 2.9.5.6) with SMTP id jm473f9e23b5; Tue, 28 Oct 2003 14:57:10 +0800 Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1AEJrk-0003ug-Nd for ietf-announce-list@asgard.ietf.org; Mon, 27 Oct 2003 21:45:52 -0500 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1AEFXs-00086t-1u for all-ietf@asgard.ietf.org; Mon, 27 Oct 2003 17:09:04 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18816; Mon, 27 Oct 2003 17:08:47 -0500 (EST) Message-Id: <200310272208.RAA18816@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-keyrr-key-signing-flag-11.txt Date: Mon, 27 Oct 2003 17:08:47 -0500 X-AIMC-AUTH: (null) X-AIMC-MAILFROM: owner-ietf-announce@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-3.3 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME,RCVD_IN_DSBL,RCVD_IN_NJABL,RCVD_IN_NJABL_RELAY, RCVD_IN_RFCI autolearn=no version=2.60 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 : KEY RR Secure Entry Point Flag Author(s) : O. Kolkman, J. Schlyter, E. Lewis Filename : draft-ietf-dnsext-keyrr-key-signing-flag-11.txt Pages : 10 Date : 2003-10-24 With the Delegation Signer (DS) resource record the concept of a key acting as a secure entry point has been introduced. During key-exchanges with the parent there is a need to differentiate secure entry point keys from other keys in the KEY resource record (RR) set. A flag bit in the KEY RR is defined to indicate that KEY is to be used as a secure entry point. The flag bit is intended to assist in operational procedures to correctly generate DS resource records, or to indicate what keys are intended for static configuration. The flag bit is not to be used in the DNS verification protocol. This document updates RFC 2535 and RFC 3445. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-11.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-keyrr-key-signing-flag-11.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-keyrr-key-signing-flag-11.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-10-27170857.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-keyrr-key-signing-flag-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-27170857.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 Oct 31 20:32: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 UAA27806 for ; Fri, 31 Oct 2003 20:32:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFkYj-000IUj-Cg for namedroppers-data@psg.com; Sat, 01 Nov 2003 01:28:09 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFkYf-000IUH-Kf for namedroppers@ops.ietf.org; Sat, 01 Nov 2003 01:28:05 +0000 Received: from ENGILL.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id hA11Q6uG084141 for ; Fri, 31 Oct 2003 20:26:06 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.0.0.22.2.20031031200314.02641df8@wheresmymailserver.com> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 31 Oct 2003 20:23:11 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: DNSSEC editing process (Periodic posting) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable The DNSEXT working group has started a rewrite of the DNSSEC specification into a documents that better reflect the protocol and allow a test plan to be constructed from the specification. To accomplish this, a team of volunteers has been formed to generate the documents. The document editing team is tasked with documenting the protocol as specified in RFC's generated by this group and id's that have been passed on by the working group to the IESG. The editors are NOT ALLOWED to make ANY changes in the protocol. If clarifications are needed due to conflicting definitions, imprecise specification, omission or other reason, the editors MUST bring these issues to the attention of the working group on the namedroppers mailing list. To assist the editors, a small group of people with good understanding of DNSSEC have been recruited to review document drafts and answer questions that the editors have. For simplified communication a mailing list has been created, anyone can send messages to the editors via this mailing list DNSSEC-editors@east.isi.edu. Archive of this mailing list will be made available. Please send minor corrections, comments, suggestions about the DNSSECbis documents to dnssec-editors@east.isi.edu. All major issues should be brought up on namedroppers, editors MAY forward any correspondence to namedroppers, without asking permission, if they deem the issues raised require wider attention. DNSEXT chairs Olaf Kolkman and =D3lafur Gu=F0mundsson approve new members= on the dnssec-editors malling list. DNSSEC-editors is NOT a design group, it is a document maintenance group. The current members of the mailing list are: Editors: Roy Arends Rob Austein Matt Larson Dan Massey Scott Rose =09 Advisors: Donald Eastlake Brian Wellington Edward Lewis Olafur Gudmundsson The current set of documents produced by dnssec-editors is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-intro-07.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-records-05.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-protocol-03.txt Supporting documents include: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-threats-04.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2536bis-dsa-03.txt All the documents will be undergoing rapid updates during the next few= months, please review new version as they become available. =09 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 Fri Oct 31 22:03: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 WAA29548 for ; Fri, 31 Oct 2003 22:03:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFlzh-000NpX-9b for namedroppers-data@psg.com; Sat, 01 Nov 2003 03:00:05 +0000 Received: from randy by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFlzd-000Nop-18 for namedroppers@ops.ietf.org; Sat, 01 Nov 2003 03:00:01 +0000 To: namedroppers@ops.ietf.org Subject: list policy Message-Id: From: Randy Bush Date: Sat, 01 Nov 2003 03:00:01 +0000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk - List Purpose namedroppers@ops.ietf.org is the mailing list for the IETF DNSEXT working group. 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. - Specific items that are not not appropriate for posting 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, pleas for help with specific implementations, etc. should be done on mailing lists for the particular implementations. There is a working group for dns operational practice, DNSOP, whose charter can be found at . Items relevant to the DNSOP charter are to be discussed on the DNSOP mailinglist. Discussion about the quality of implementations is outside the scope of this list. - Moderation Moderation is based on "subscriber-only with spam filter". 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 - Issue Tracker As of October 2003 this group will use an issue tracker. This is to better organize the work-flow, maintain overview over, and focus the discussions to the working group documents. Please stick to the following procedure when discussing working group work documents. == The system The issue tracker can be found at: https://roundup.machshav.com/dnsext/index The chairs are responsible for maintaining the data in the issue tracker. That task may be delegated to document editors. If a document editor prefers other tracking systems they are free to coordinate that with the chairs. == Creating a new issue. New Issue tickets are only created for working group document. If you have an issue a document please sent in a mail with a subject header of the following format ISSUE: Where <NAME> is taken from the I-D's file name draft-ietf-dnsext-<name>-<version> and the <title> is a short description of the issue presented. Please use the following template to submit an issue: To: namedroppers@ops.ietf.org Cc: document-editor@foo.example Subject: FOO-RR-PROCESSING ISSUE: BLA-bit vs FOO-flag interop problem One line description of issue name: Your_Name_Here email: Your_Email_Address_Here Date: Insert_Date_Here Reference: URL to e-mail describing problem, if available Type: ['T'echnical | 'E'ditorial] Priority: ['C'ritical | 'U'rgent | 'B'ug | 'F'eature | 'W'ish ] Document: draft-ietf-dnsext-<name>-<version> Section: Insert_Section_Number_Here Rationale/Explanation of issue: Length description of problem Requested change: Proposal The proposal for the requested change is the most important bit of the issue. Providing a proposed text will focus discussion and relieves the document-editors. A new issue MUST therefore contain a text in the 'requested change' field. Once a new "ISSUE" message is received on the list the chairs or document editors will add the issue to the document tracker and reply to the list providing a URL and a relevant issue identifier. == Discussion of issues. Discussion of issues takes place on the list. Please reply 'in-thread' when discussing an issue and try to stay within scope of the issue at hand. The chairs or the document editors will copy relevant messages, or abstracts thereof to the issue tracker so that the gist of the discussion can be followed using the tracker. There may be a few days lag between the list and the tracker. The archive remains the authoritative log for the discussion. == Bouncing of issues The chairs may decide not to create a entry in the issue tracker if an issue does not relate to a working group document; the issue has already been discussed and the issue has been closed; if there is no proposed change or; if the issue is irrelevant to any of the working group documents. == Discussion of matters not in the issue tracker. Feel free to bring up matters that are not related to working group documents (but appropriate to the group); they do not need an issue tracking number. == Closing of issues. Chairs or document editors will close issues once resolved. In the tracking system a note will be made in which document version the issue was resolved. --- 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. ---------------------------------------------------------------------- $Id: dnsext-list-policy.txt,v 1.4 2003/09/25 08:26:13 olaf Exp $ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/>