From owner-namedroppers@ops.ietf.org Fri Oct 1 02:40:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27670 for ; Fri, 1 Oct 2004 02:40:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CDH1H-000PNH-WF for namedroppers-data@psg.com; Fri, 01 Oct 2004 06:35:56 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CDH16-000PMn-Jw for namedroppers@ops.ietf.org; Fri, 01 Oct 2004 06:35:45 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id B161C55CA8; Fri, 1 Oct 2004 08:35:02 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 1A40F4E375 for ; Fri, 1 Oct 2004 08:35:02 +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 ESMTP id i916Z2rL031689 for ; Fri, 1 Oct 2004 08:35:02 +0200 Received: (from olaf@localhost) by x50.ripe.net (8.12.10/8.12.6) id i916Z1vG012963 for namedroppers@ops.ietf.org; Fri, 1 Oct 2004 08:35:01 +0200 Date: Fri, 1 Oct 2004 08:35:01 +0200 From: Olaf Kolkman Message-Id: <200410010635.i916Z1vG012963@x50.ripe.net> To: namedroppers@ops.ietf.org Subject: DNSEXT list policy X-RIPE-Spam-Status: U 0.497145 / 0.0 / 0.0 / disabled X-RIPE-Signature: a829b03bc9e3e64fcdd07f8d1c9c8aeb X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 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". To counter a certain class of spam mails messages over 20000 characters, originating from list subscribers, will be held for moderations. 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.7 2004/05/17 12:46:38 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/> From owner-namedroppers@ops.ietf.org Fri Oct 1 06:45:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16191 for <dnsext-archive@lists.ietf.org>; Fri, 1 Oct 2004 06:45:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CDKpU-0003ku-JG for namedroppers-data@psg.com; Fri, 01 Oct 2004 10:40:00 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CDKpI-0003k1-Hu for namedroppers@ops.ietf.org; Fri, 01 Oct 2004 10:39:49 +0000 Received: from delta.noi.kre.to (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id i91AddW08936; Fri, 1 Oct 2004 17:39:41 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i91AdWve024773; Fri, 1 Oct 2004 17:39:35 +0700 (ICT) From: Robert Elz <kre@munnari.OZ.AU> To: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> cc: namedroppers@ops.ietf.org Subject: Re: still not sure In-Reply-To: <200409301214.i8UCE0T26715@grimsvotn.TechFak.Uni-Bielefeld.DE> References: <200409301214.i8UCE0T26715@grimsvotn.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 01 Oct 2004 17:39:32 +0700 Message-ID: <12436.1096627172@munnari.OZ.AU> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Thu, 30 Sep 2004 14:14:00 +0200 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Message-ID: <200409301214.i8UCE0T26715@grimsvotn.TechFak.Uni-Bielefeld.DE> | However, with regards to kre, a "MUST be allowed (anticipated) in a query" | might conflict with ``check-names'' like features, which have nothing to do | with wildcards, but lot to do with A or AAAA queries. So, in general, they | should be allowed but I'd rather not see this as an argument that '*' must | be accepted in a ``hostname''. Sites are free to use whatever hostnames they want to use, and if your choice of hostnames forbids '*' in the name (an entirely rational choice I might add) that's just fine. If you need your nameserver software to tell you when you have accidentally violated one of your own rules like that, that's fine too. None of this has anything in the slightest to do with what a nameserver should do when someone who doesn't adopt that policy decides that they do want a '*' label in a domain name (which is not necessarily one that is being used as a host name). 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Oct 1 06:51:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16672 for <dnsext-archive@lists.ietf.org>; Fri, 1 Oct 2004 06:51:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CDKy7-0004sC-Rh for namedroppers-data@psg.com; Fri, 01 Oct 2004 10:48:55 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CDKxo-0004qa-Ej for namedroppers@ops.ietf.org; Fri, 01 Oct 2004 10:48:37 +0000 Received: from delta.noi.kre.to (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id i91Am3W09334; Fri, 1 Oct 2004 17:48:04 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i91Am0ve012482; Fri, 1 Oct 2004 17:48:01 +0700 (ICT) From: Robert Elz <kre@munnari.OZ.AU> To: Samuel Weiler <weiler@tislabs.com> cc: namedroppers@ops.ietf.org, dnssec-editors@east.isi.edu Subject: Re: bis inconsistency: grandparent problem In-Reply-To: <Pine.GSO.4.55.0409301343200.26585@filbert> References: <Pine.GSO.4.55.0409301343200.26585@filbert> <a0602040bbd808b0ce5af@[192.136.136.113]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 01 Oct 2004 17:48:00 +0700 Message-ID: <11680.1096627680@munnari.OZ.AU> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Thu, 30 Sep 2004 13:47:45 -0400 (EDT) From: Samuel Weiler <weiler@tislabs.com> Message-ID: <Pine.GSO.4.55.0409301343200.26585@filbert> | -protocol section C.8 suggests Sorry, I'm not sure what doc you're meaning here (I assume, since your message is cc'd to dnssec-editors, it is one of the "dnssec" type ones, which I would rarely read), but this in your message caught my eye... | Section 4.2 of the same document suggests using NS queries. Anything in any doc that is even suggesting that anything should ever do an NS query (for any purpose other than debugging, or checking DNS delegation consistency, etc) should be expunged from the face of the universe as rapidly as we can find it. NS records get used as a side effect of the normal lookup procedures, they shouldn't ever be sought explicitly as part of any algorithm, doing so requires guessing where zone cuts actually happen, for which there is neither any sane method defined (until after the NS records are already known anyway), nor any need. 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Oct 1 11:16:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08931 for <dnsext-archive@lists.ietf.org>; Fri, 1 Oct 2004 11:16:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CDP4o-000HhP-FU for namedroppers-data@psg.com; Fri, 01 Oct 2004 15:12:06 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CDP4d-000Hg1-LG for namedroppers@ops.ietf.org; Fri, 01 Oct 2004 15:11:55 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i91F8qSb001744 for <namedroppers@ops.ietf.org>; Fri, 1 Oct 2004 11:08:52 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAL_aGyd; Fri, 1 Oct 04 11:08:50 -0400 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id i91FANPM016686; Fri, 1 Oct 2004 11:10:23 -0400 (EDT) Date: Fri, 1 Oct 2004 11:10:23 -0400 (EDT) From: Samuel Weiler <weiler@tislabs.com> X-X-Sender: weiler@filbert To: Robert Elz <kre@munnari.OZ.AU> cc: namedroppers@ops.ietf.org Subject: Re: bis inconsistency: grandparent problem In-Reply-To: <11680.1096627680@munnari.OZ.AU> Message-ID: <Pine.GSO.4.55.0410011021270.14026@filbert> References: <Pine.GSO.4.55.0409301343200.26585@filbert> <a0602040bbd808b0ce5af@[192.136.136.113]> <11680.1096627680@munnari.OZ.AU> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > | -protocol section C.8 suggests draft-ietf-dnsext-dnssec-protocol-08.txt > | Section 4.2 of the same document suggests using NS queries. ... > NS records get used as a side effect of the normal lookup > procedures, they shouldn't ever be sought explicitly as part of any > algorithm, doing so requires guessing where zone cuts actually > happen, for which there is neither any sane method defined (until > after the NS records are already known anyway), nor any need. Actually, DS, as the only RR type existing only at the parent side of a zone cut, creates such a need to guess where zone cuts are. There is a method defined (in the -protocol document, sections 4.2 and C,8, and in RFC3658, section 2.2.1.2); you can decide for yourself whether or not it's sane. This was introduced in response to the "DS grandparent" or "DS ancestor" problem, a relative of another protocol bug, colloquially called the "DS Lameness Bug", discovered during a workshop at ISI East in August 2002. The problem there was that properly-signed zones could be (made) invisible to certain legacy resolvers. It made signing unsafe -- would you sign your zone if it meant you could easily be knocked off the net? http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01535.html Unfortunately, the chosen fix to the DS Lameness Bug created a problem when a zone and it's non-parent ancestor share an authoritative server. (ie. root-servers.net and the root being served by a server that is not also authoritative for net) We discovered that particular ugliness in the fall of 2002, it got some airing at the workshop in Atlanta, and version 12 of the DS draft proposed an algorithm for addressing it. Here's a lengthier discussion of it: http://www.cafax.se/dnssec/maillist/2002-11/msg00030.html And here's another proposed fix for both problems that was rejected: http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01901.html http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01663.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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Oct 1 11:27:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10772 for <dnsext-archive@lists.ietf.org>; Fri, 1 Oct 2004 11:27:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CDPGz-000Jsc-Qi for namedroppers-data@psg.com; Fri, 01 Oct 2004 15:24:41 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CDPGp-000JrM-0V for namedroppers@ops.ietf.org; Fri, 01 Oct 2004 15:24:31 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 181B214402C; Fri, 1 Oct 2004 11:01:52 -0400 (EDT) Received: from mercury.arin.net (mercury.arin.net [192.149.252.131]) by smtp2.arin.net (Postfix) with ESMTP id 87178143FA8; Fri, 1 Oct 2004 11:01:51 -0400 (EDT) Received: from [192.136.136.113] (mercury.arin.net [127.0.0.1]) by mercury.arin.net (Postfix) with ESMTP id AA3CACF3A8; Fri, 1 Oct 2004 11:24:29 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a06020406bd8324579eb1@[192.136.136.113]> Date: Fri, 1 Oct 2004 11:24:27 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis <edlewis@arin.net> Subject: progress on wcard draft Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I'm finally started in on an update of the document. While I'm reconstructing it based on discussions over the past month or so, I have one more open question: Can an NS record be synthesized? E.g., (assuming [Q]CLASS=IN for all) example. SOA ... NS ns1.example. NS ns2.example. * NS ns3.example. NS ns4.example. ns1 A 192.0.4.1 ns2 A 192.0.4.2 ns3 A 192.0.4.3 ns4 A 192.0.4.4 QNAME=bar.example. QTYPE=NS Option1 ------- Synthesize "bar.example. NS ns3.example." and "bar.example. NS ns4.example." Downside: Non-authority is doing the synthesis. (In making the NS records, the zone/server is delegating away the right to make them.) Option2 ------- No answer - (name error) or (no error and answer count = 0) Downside: Making an exception to the (virtual?) rule in RFC 1034/sect 4.3.2/step 3/part c/last paragraph governing matching of types. Option3 ------- Return code of something like "not implemented" Downside: it's "giving up" on answering this. -------- Of the three options, #1 is probably the easiest to defend as there's always been a debate on the meaning of "authority" for NS records even if RFC 2181 gives parental NS's lower cred than child NS's. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to 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/> From owner-namedroppers@ops.ietf.org Fri Oct 1 12:30:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21492 for <dnsext-archive@lists.ietf.org>; Fri, 1 Oct 2004 12:30:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CDQGZ-0005F1-1s for namedroppers-data@psg.com; Fri, 01 Oct 2004 16:28:19 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CDQGN-0005Dr-8H for namedroppers@ops.ietf.org; Fri, 01 Oct 2004 16:28:08 +0000 Received: from delta.noi.kre.to (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id i91GS3W26496; Fri, 1 Oct 2004 23:28:03 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i91GRxve028394; Fri, 1 Oct 2004 23:28:00 +0700 (ICT) From: Robert Elz <kre@munnari.OZ.AU> To: Edward Lewis <edlewis@arin.net> cc: namedroppers@ops.ietf.org Subject: Re: progress on wcard draft In-Reply-To: <a06020406bd8324579eb1@[192.136.136.113]> References: <a06020406bd8324579eb1@[192.136.136.113]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 01 Oct 2004 23:27:59 +0700 Message-ID: <6607.1096648079@munnari.OZ.AU> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Fri, 1 Oct 2004 11:24:27 -0400 From: Edward Lewis <edlewis@arin.net> Message-ID: <a06020406bd8324579eb1@[192.136.136.113]> | Can an NS record be synthesized? For this particular query (only a query with QTYPE=NS), yes. | QNAME=bar.example. QTYPE=NS | | Option1 | ------- | | Synthesize "bar.example. NS ns3.example." and "bar.example. NS ns4.example." Yes, that's what needs to happen. | Of the three options, #1 is probably the easiest to defend as there's | always been a debate on the meaning of "authority" for NS records | even if RFC 2181 gives parental NS's lower cred than child NS's. But in this case the answer is authoritative, whereas normally an NS answer returned from the parent would not be. There's no delegation here, just NS records being returned in response to an NS query (the same as if they were any other record type). This is a particularly weird, but totally harmless and irrelevant side issue - I agree we should be precise in what happens (though this is another place where I wouldn't object too much to saying "server dependent" or "undefined behaviour") but in practice, no-one should ever care, as no-one is really likely to ever have '* NS' - given that the chances of anyone ever using '*' as a label in a domain name other than with the intent of it being a wildcard is close to 0, and '* NS' simply doesn't work as a wildcard for any useful purpose. 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Oct 1 13:13:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26510 for <dnsext-archive@lists.ietf.org>; Fri, 1 Oct 2004 13:13:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CDQvd-000Bdz-Hw for namedroppers-data@psg.com; Fri, 01 Oct 2004 17:10:45 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CDQuY-000BQO-TZ for namedroppers@ops.ietf.org; Fri, 01 Oct 2004 17:09:38 +0000 Received: from stjohns-lap2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 045B55687E; Fri, 1 Oct 2004 10:09:37 -0700 (PDT) (envelope-from Mike.StJohns@nominum.com) Message-Id: <6.1.2.0.2.20041001130913.0767fae0@localhost> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 01 Oct 2004 13:09:38 -0400 To: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com>, namedroppers@ops.ietf.org From: Mike StJohns <Mike.StJohns@nominum.com> Subject: Re: Fw: Approval to Post Version -00 Internet-Drafts for the 61st IETF Meeting in Washington, DC, USA In-Reply-To: <6.1.2.0.2.20040927111425.02b87ec0@localhost> References: <20040927135346.7a0641fd.olaf@ripe.net> <6.1.2.0.2.20040927110541.02957ec0@localhost> <6.1.2.0.2.20040927111425.02b87ec0@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.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Without objection - I'll post my draft as a working group draft by the end= =20 of the week. At 11:24 AM 9/27/2004, =D3lafur Gudmundsson/DNSEXT co-chair wrote: >At 11:07 27/09/2004, Mike StJohns wrote: >>Is there agreement to accept=20 >>http://www.ietf.org/internet-drafts/draft-stjohns-dnssec-trustupdate-01.tx= t=20 >>"Automated Updates of DNSSEC Trust Anchors" as a WG draft? If so, I'll=20 >>repost it as draft-ietf-dnsext-dnssec-trustupdate-00.txt. > >Does anyone in the working group object that we admit the this document and >the Threshold key validation schema described in >http://www.ietf.org/internet-drafts/draft-ihren-dnsext-threshold-validation= -01.txt?=20 > > >It was the sense of the room in San Diego to admit these documents >as working group items, but we chairs forgot to officially ask this >question on the mailing list. > >The reason to do this work in DNSEXT is that one or both these >proposals want to use bits in the DNSKEY record for signaling of >state change(s). > > 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: <http://ops.ietf.org/lists/namedroppers/> -- to 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/> From owner-namedroppers@ops.ietf.org Fri Oct 1 14:24:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04201 for <dnsext-archive@lists.ietf.org>; Fri, 1 Oct 2004 14:24:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CDS0w-000L5a-Gq for namedroppers-data@psg.com; Fri, 01 Oct 2004 18:20:18 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CDS0d-000L3M-PZ for namedroppers@ops.ietf.org; Fri, 01 Oct 2004 18:20:00 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id D5014144205; Fri, 1 Oct 2004 13:57:18 -0400 (EDT) Received: from mercury.arin.net (mercury.arin.net [192.149.252.131]) by smtp2.arin.net (Postfix) with ESMTP id 54D2B143F96; Fri, 1 Oct 2004 13:57:18 -0400 (EDT) Received: from [192.136.136.113] (mercury.arin.net [127.0.0.1]) by mercury.arin.net (Postfix) with ESMTP id 671D3CF3A8; Fri, 1 Oct 2004 14:19:58 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a0602040ebd834e8a674e@[192.136.136.113]> In-Reply-To: <6607.1096648079@munnari.OZ.AU> References: <a06020406bd8324579eb1@[192.136.136.113]> <6607.1096648079@munnari.OZ.AU> Date: Fri, 1 Oct 2004 14:19:57 -0400 To: Robert Elz <kre@munnari.OZ.AU> From: Edward Lewis <edlewis@arin.net> Subject: Re: progress on wcard draft Cc: Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 23:27 +0700 10/1/04, Robert Elz wrote: >But in this case the answer is authoritative, whereas normally an NS >answer returned from the parent would not be. There's no delegation >here, just NS records being returned in response to an NS query (the >same as if they were any other record type). Thanks for your patience - I recall you've said this before, last week in fact. I ask the ({WG} - {kre}) "any other comments?" Are you (Robert) saying that, like the question of "does a name exist" is relative to whether the point of view is the server or the client? If the server synthesizes the records, the client will think there's a delegation. Or, when you say "There's no delegation, just NS records" do you mean that "in reality, there's no place to go anyway" even though the servers tells the client that there is? >This is a particularly weird, but totally harmless and irrelevant side >issue - I agree we should be precise in what happens (though this is another >place where I wouldn't object too much to saying "server dependent" or >"undefined behaviour") but in practice, no-one should ever care, as >no-one is really likely to ever have '* NS' - given that the chances of >anyone ever using '*' as a label in a domain name other than with the >intent of it being a wildcard is close to 0, and '* NS' simply doesn't work >as a wildcard for any useful purpose. Well, there are a lot of "particularly weird, but totally harmless" members of the WG. ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to 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/> From owner-namedroppers@ops.ietf.org Fri Oct 1 16:53:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16435 for <dnsext-archive@lists.ietf.org>; Fri, 1 Oct 2004 16:53:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CDUKy-000H2G-QZ for namedroppers-data@psg.com; Fri, 01 Oct 2004 20:49:08 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CDUKo-000H1Y-4j for namedroppers@ops.ietf.org; Fri, 01 Oct 2004 20:48:58 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 2AE0967502 for <namedroppers@ops.ietf.org>; Fri, 1 Oct 2004 20:48:56 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.11/8.12.11) with ESMTP id i91KmWj4094810; Sat, 2 Oct 2004 06:48:33 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200410012048.i91KmWj4094810@drugs.dv.isc.org> To: Robert Elz <kre@munnari.OZ.AU> Cc: Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: progress on wcard draft In-reply-to: Your message of "Fri, 01 Oct 2004 23:27:59 +0700." <6607.1096648079@munnari.OZ.AU> Date: Sat, 02 Oct 2004 06:48:32 +1000 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Date: Fri, 1 Oct 2004 11:24:27 -0400 > From: Edward Lewis <edlewis@arin.net> > Message-ID: <a06020406bd8324579eb1@[192.136.136.113]> > > | Can an NS record be synthesized? > > For this particular query (only a query with QTYPE=NS), yes. > > | QNAME=bar.example. QTYPE=NS > | > | Option1 > | ------- > | > | Synthesize "bar.example. NS ns3.example." and "bar.example. NS ns4.exampl > e." > > Yes, that's what needs to happen. > > | Of the three options, #1 is probably the easiest to defend as there's > | always been a debate on the meaning of "authority" for NS records > | even if RFC 2181 gives parental NS's lower cred than child NS's. > > But in this case the answer is authoritative, whereas normally an NS > answer returned from the parent would not be. There's no delegation > here, just NS records being returned in response to an NS query (the > same as if they were any other record type). > > This is a particularly weird, but totally harmless and irrelevant side > issue - I agree we should be precise in what happens (though this is another > place where I wouldn't object too much to saying "server dependent" or > "undefined behaviour") but in practice, no-one should ever care, as > no-one is really likely to ever have '* NS' - given that the chances of > anyone ever using '*' as a label in a domain name other than with the > intent of it being a wildcard is close to 0, and '* NS' simply doesn't work > as a wildcard for any useful purpose. Well I've seen *.123.123.in-addr.arpa used in the wild as an attempt to delegate to 0.123.123.in-addr.arpa ... 255.123.123.in-addr.arpa. It didn't work very well. > kre > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> -- Mark Andrews, ISC 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Oct 1 17:02:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18304 for <dnsext-archive@lists.ietf.org>; Fri, 1 Oct 2004 17:02:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CDUVu-000J5X-Qs for namedroppers-data@psg.com; Fri, 01 Oct 2004 21:00:26 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CDUVh-000J3h-PJ for namedroppers@ops.ietf.org; Fri, 01 Oct 2004 21:00:16 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 08EDD1442DC; Fri, 1 Oct 2004 16:37:31 -0400 (EDT) Received: from mercury.arin.net (mercury.arin.net [192.149.252.131]) by smtp2.arin.net (Postfix) with ESMTP id 71F041442C0; Fri, 1 Oct 2004 16:37:30 -0400 (EDT) Received: from [192.136.136.113] (mercury.arin.net [127.0.0.1]) by mercury.arin.net (Postfix) with ESMTP id 4C808CF3A8; Fri, 1 Oct 2004 17:00:12 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a06020416bd83737b0fba@[192.136.136.113]> In-Reply-To: <200410012048.i91KmWj4094810@drugs.dv.isc.org> References: <200410012048.i91KmWj4094810@drugs.dv.isc.org> Date: Fri, 1 Oct 2004 17:00:11 -0400 To: Mark Andrews <Mark_Andrews@isc.org> From: Edward Lewis <edlewis@arin.net> Subject: Re: progress on wcard draft Cc: Robert Elz <kre@munnari.OZ.AU>, Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 6:48 +1000 10/2/04, Mark Andrews wrote: > Well I've seen *.123.123.in-addr.arpa used in the wild as an > attempt to delegate to 0.123.123.in-addr.arpa ... > 255.123.123.in-addr.arpa. It didn't work very well. Like I said "particularly weird" folks do run DNS servers. It's pretty clear that trying to synthesize a zone is dicey, but that's not the issue here. Assuming that a server serves one zone, and that zone has a "* NS" in it, should the server return a synthesized referral message? no error/no data? not implemented? It doesn't matter at this juncture (being that we are defining a client-server protocol) whether the first option leaves us with something sensible. If we decide that the parent is authorized to synthesize the NS set, it'll be up to the client to deal with this. Who knows, maybe I will have a server that is able to conjure up zones on the fly? 'Course, it would only really be interesting if "* NS" reacted as a referral in step 3b of RFC 1034 s4.3.2. Perhaps the client has a goofy resolver that looks for NS's before determining if it has the sight server. What I'm trying to say is that if we ignore the motivation for the query, we might be able to hammer this out. Is the nonsensical answer worse than saying "no answer, no data" as if there were no records to synthesize from? I know that we question the sanity of anyone who does this - but there are folks that do. What should be written about the situation. I'm also not demanding to be able to specify this as in MUST/SHOULD/etc. These are engineering documents, not specifications, so words of guidance would be sufficient. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to 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/> From owner-namedroppers@ops.ietf.org Sun Oct 3 19:36:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27531 for <dnsext-archive@lists.ietf.org>; Sun, 3 Oct 2004 19:36:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CE1An-000GrL-Sz for namedroppers-data@psg.com; Sun, 03 Oct 2004 07:52:49 +0000 Received: from [203.96.144.16] (helo=gw.zl2tnm.gen.nz) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CE1Am-000Gr0-MR for namedroppers@ops.ietf.org; Sun, 03 Oct 2004 07:52:49 +0000 Received: from toybsd.zl2tnm.gen.nz (toybsd.zl2tnm.gen.nz [192.168.153.14]) by gw.zl2tnm.gen.nz (8.9.3/8.9.3) with ESMTP id UAA12716 for <namedroppers@ops.ietf.org>; Sun, 3 Oct 2004 20:52:46 +1300 Received: from toybsd.zl2tnm.gen.nz (don@localhost [127.0.0.1]) by toybsd.zl2tnm.gen.nz (8.12.9/8.12.9) with ESMTP id i937qkGK034932 for <namedroppers@ops.ietf.org>; Sun, 3 Oct 2004 20:52:46 +1300 (NZDT) (envelope-from don@toybsd.zl2tnm.gen.nz) To: namedroppers@ops.ietf.org Subject: Re: progress on wcard draft In-Reply-To: Your message of "Fri, 01 Oct 2004 11:24:27 -0400." <a06020406bd8324579eb1@[192.136.136.113]> From: Don Stokes <don@plugh.daedalus.co.nz> Date: Sun, 03 Oct 2004 20:52:46 +1300 Message-ID: <34931.1096789966@toybsd.zl2tnm.gen.nz> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward Lewis <edlewis@arin.net> wrote: >I'm finally started in on an update of the document. While I'm >reconstructing it based on discussions over the past month or so, I >have one more open question: > >Can an NS record be synthesized? > >E.g., (assuming [Q]CLASS=IN for all) > > example. SOA ... > NS ns1.example. > NS ns2.example. > * NS ns3.example. > NS ns4.example. > ns1 A 192.0.4.1 > ns2 A 192.0.4.2 > ns3 A 192.0.4.3 > ns4 A 192.0.4.4 > >QNAME=bar.example. QTYPE=NS > >Option1 >------- > >Synthesize "bar.example. NS ns3.example." and "bar.example. NS ns4.example." > >Downside: Non-authority is doing the synthesis. (In making the NS >records, the zone/server is delegating away the right to make them.) To me, example. SOA ... * NS ns3.example. NS ns4.example. says "delegate anything below example. that we don't otherwise know about to ns3 & ns4.example.", which I think is exactly what you're suggesting. Any other interpretation is putting different behaviour on an above-zone-cut NS, even if it does (probably) mean a special case in the wildcard processing of the server handling the wildcard. This is quite at odds with a strict reading of RFC 1034 sec 4.3.2, which would suggest returning a synthesised answer for an explicit NS query, but never responding with a delegation response to any other query. In effect, this is reversing steps 3b and 3c, making the wildcard decision before the zone cut decision. >Of the three options, #1 is probably the easiest to defend as there's >always been a debate on the meaning of "authority" for NS records >even if RFC 2181 gives parental NS's lower cred than child NS's. -- don -- to 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/> From owner-namedroppers@ops.ietf.org Tue Oct 5 10:49:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04963 for <dnsext-archive@lists.ietf.org>; Tue, 5 Oct 2004 10:49:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CEqXU-000Hay-Hh for namedroppers-data@psg.com; Tue, 05 Oct 2004 14:43:40 +0000 Received: from [192.150.250.67] (helo=fuchsia.home) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CEqXQ-000HZ4-9I for namedroppers@ops.ietf.org; Tue, 05 Oct 2004 14:43:39 +0000 Received: from delta.noi.kre.to (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id i92M4mIn010047; Sun, 3 Oct 2004 05:05:54 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i92FDNcu006237; Sat, 2 Oct 2004 22:13:50 +0700 (ICT) From: Robert Elz <kre@munnari.OZ.AU> To: Edward Lewis <edlewis@arin.net> cc: Mark Andrews <Mark_Andrews@isc.org>, namedroppers@ops.ietf.org Subject: Re: progress on wcard draft In-Reply-To: <a06020416bd83737b0fba@[192.136.136.113]> References: <a06020416bd83737b0fba@[192.136.136.113]> <200410012048.i91KmWj4094810@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 02 Oct 2004 22:13:23 +0700 Message-ID: <20008.1096730003@munnari.OZ.AU> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Fri, 1 Oct 2004 17:00:11 -0400 From: Edward Lewis <edlewis@arin.net> Message-ID: <a06020416bd83737b0fba@[192.136.136.113]> | Like I said "particularly weird" folks do run DNS servers. Yes - which is why we need to make it clear what works, and from what follows, it is clear to me that it is (not yet) clear to you, or perhaps, somewhere analytically, you know what actually works, but sub-consciously you're still flirting with ... | It's pretty clear that trying to synthesize a zone is dicey, No, not "dicey", impossible - the DNS lookup algorithm does not allow it to function. | Assuming that a server serves one zone, and that zone has a "* NS" in | it, should the server return a | | synthesized referral message? Never. | no error/no data? This depends upon the query and what else is in the zone. | not implemented? I assume we're talking about opcode==0 ? How can that possibly be "not implemented" in any server relevant to what we're discussing? If the server doesn't implement queries, then what it does with wildcards cannot possibly be relevant to us. Note there's no "breakout point" in the lookup algorithm for the server to give up and say "too hard for me...". Even if the server is deficient, and doesn't implement wildcards at all (which is certainly something I can imagine existing), "not implemented" cannot possibly be a rational answer to any query - the client has just asked about some particular name, doing a perfectly normal query, it cannot possibly be expected to assume that a server deciding to send back "not implemented" to its query happens to mean "well, there's this thing that looks like a wildcard in the zone, but I don't have the wildcard algorithm implemented, so I can't give you the correct answer" - that's absurd. What the server needs to answer in this case is NXDOMAIN if there was no wildcard in the zone file, the name doesn't exist, and it needs to object to '*' labels (and abandon the zone completely) if it finds one, (a '*' label in the zone that is) as it is unable to process it correctly, and in that case reply 'server failed". Note, in this message you didn't say what query we're talking about. It cannot be the one from the earlier message QNAME=bar.example. QTYPE=NS as you talk about a referral as one of the possible answers. The answer to that particular question isn't a referral, it is an answer. That is, the synthesised NS records go in the answer section. In a referral, the NS records (which can never be synthesised) go in the authority section - the two are totally different things. (Incidentally, I suspect that for a "normal" NS record, a QTYPE=NS query asked of the parent server, not also being a server for the delegated zone, should really result in a referral, rather than an answer, but I suspect that isn't what happens in most cases, but I am temporarily out of contact with all nameservers, everywhere, and can't check a few different versions to verify it - the drawbacks of answering mail from a laptop...) | If we decide that the parent is authorized to | synthesize the NS set, it'll be up to the client to deal with this. Yes, but note this only happens with clients that send NS queries, which is no normal resolver. | Who knows, maybe I will have a server that is able to conjure up | zones on the fly? Whether you do or not, it is irrelevant, as there's no way in the lookup algorithm for a '* NS' record to generate dynamically created referrals. People have from time to time fantasised about this happening, but to allow it, we'd need to make a major change to the DNS. It won't, and cannot, happen according to the algorithms in 1034. On the other hand, if you do have a server that conjures up zones on the fly, it can also conjure up explicit NS records to accompany the zone, and no-one can really tell that the zone was created during the microsecond between receiving the query, and sending the reply, rather than 5 minutes earlier - wildcard records would be irrelevant to this however. | 'Course, it would only really be interesting if "* NS" reacted as a | referral in step 3b of RFC 1034 s4.3.2. Which it doesn't. 3b only gets used when there has been a name match. Wildcards only get looked at in 3c, which only happens when there is no name match. The two cases are exclusive. | Perhaps the client has a goofy resolver that looks for NS's | before determining if it has the sight server. For that it would first need to figure out NS's for what domain name. This isn't easy. Resolvers doing lookups simply do not ask for NS records -- the most you might expect as an outside possibility, would be, having been given a referral, the resolver may check the servers to which it has been referred, to get the auth list of NS records - but this only happens (can only happen) when there has been a genuine referral to start with, which implies NS records owned by an explicit name that exactly matched some trailing part of the QNAME (including the whole thing of course). | What I'm trying to say is that if we ignore the motivation for the | query, we might be able to hammer this out. Which query are we back to now? This looks as if you're back to the QTYPE=NS query, in which case, the answer is "synthesise away". | Is the nonsensical answer worse than saying "no answer, no data" as | if there were no records to synthesize from? Which is "the nonsensical answer" ?? if I have "* NS foo." in my example. zone file, and someone does "QNAME bar.example. QTYPE=NS", then returning "bar.example. NS foo." isn't "nonsensical", it is exacly what I told my server it was required to return. Telling it that might be stupid on my part, but the answer itself is 100% correct (and required). | I know that we question the sanity of anyone who does this - but | there are folks that do. What should be written about the situation. Just tell them that it cannot work as a wildcard delegation, as the * isn't ever used in referrals. That is, as in the case Mark mentioned, it simply does not, and cannot, work the way they were hoping it might work. We need to make that clear. Whether we shouldbother confusing the issue by saying anything at all about QTYPE=NS queries I am less certain. A good argument could be made for simply "forgetting" to cover this case, and then referring anyone who actually tries it back to 1034 when they ask. And back to one part of an earlier message ... edlewis@arin.net said in <a0602040ebd834e8a674e@[192.136.136.113]>: | Are you (Robert) saying that, like the question of "does a name exist" is | relative to whether the point of view is the server or the client? No, of course not. If there is a wildcard, then all direct sub-domains exist. That is, treating letters as representing a single label (of any length) and dots ('.') as being a divider between labels, and '*' as itself, then if "x." exists, and "*.x." exists, then "a.x." exists for every possible a. (Which is explicitly not saying anything about "b.a.x."). Now whether "a.x." exists because that name is explicitly configured into the DNS, or whether it exists because of the wildcard doesn't matter here (it will matter, I assume, to the decision of what dnssec type RR's need to be included to prove the name exists) - but it exists. It might, or might not, have any resource records attached to it. edlewis@arin.net said (same message): | If the server synthesizes the records, the client will think there's a | delegation. No, it won't. Or, perhaps better, "no, it shouldn't". If it got a referral, then it could imply there's a delegation. But from getting answers in the answer section, even of type NS, all it can conclude is that there are NS records for the name queried. Of course, the client in reality isn't doing QTYPE=NS, so this isn't a very serious question. edlewis@arin.net said: | Or, when you say "There's no delegation, just NS records" do you mean that | "in reality, there's no place to go anyway" even though the servers tells | the client that there is? No, I mean there is no delegation (from either the server, or clients point of view), and getting NS records in the answer section does not imply referral, or that there is any delegation. NS records normally only appear in replies in the authority section. There they are (or can be) a referral, but a wildcard '* NS' record will never cause them to get put there (other than as an explicit '* NS' if the referral is literally for the '*' sub-domain itself). I know this is kind of mind blowing in a way - which is why (as I said earlier, in this message, and others) that just leaving all this as undefined, or forgetting to mention it at all, or ... wouldn't bother me too much, as it isn't something that makes a difference in real life. Unless someone is dumb enough to actually have a '*' zone, and delegate it, no-one is going to have '* NS' records, if this doc does a good enough job of explaining that they won't do what people are hoping they will achieve when they attempt it now. Even if they do have '* NS' records, nothing actually does QTYPE=NS queries, to hit the corner case. kre ps: it is possible that you're getting no other comments, because in general we agree on what the rules should be, and there is no-one out there who disagrees, so no-one is bothering to say anything. -- to 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/> From owner-namedroppers@ops.ietf.org Tue Oct 5 17:38:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14472 for <dnsext-archive@lists.ietf.org>; Tue, 5 Oct 2004 17:38:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CEww2-000CqO-Hk for namedroppers-data@psg.com; Tue, 05 Oct 2004 21:33:26 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CEww1-000Cq2-JT for namedroppers@ops.ietf.org; Tue, 05 Oct 2004 21:33:25 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 8749A143B5A; Tue, 5 Oct 2004 17:33:24 -0400 (EDT) Received: from mercury.arin.net (mercury.arin.net [192.149.252.131]) by smtp2.arin.net (Postfix) with ESMTP id 8FA2D143EE8; Tue, 5 Oct 2004 17:33:22 -0400 (EDT) Received: from [192.136.136.113] (mercury.arin.net [127.0.0.1]) by mercury.arin.net (Postfix) with ESMTP id 3EEA31FE5E; Tue, 5 Oct 2004 17:33:22 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a06020418bd88c2194f5c@[192.136.136.113]> In-Reply-To: <34931.1096789966@toybsd.zl2tnm.gen.nz> References: <34931.1096789966@toybsd.zl2tnm.gen.nz> Date: Tue, 5 Oct 2004 17:33:21 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis <edlewis@arin.net> Subject: Re: progress on wcard draft Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Looking at Don's (quoted below) and Robert's last responses: >In effect, this is reversing steps 3b and 3c, making the wildcard >decision before the zone cut decision. First, the caution has gone out that the algorithm in 4.3.2 isn't pseudocode, so the ordering isn't important. E.g., 3b and 3c aren't meant to be in any specific order, so there's no need to "reverse the order." But, there's something more significant from that comment. Once we've arrives at step 3, only one of part a, part b and part c can be executed. So, let's say we have a '* NS' and the query is for NS and an owner name that results in wildcard processing. In this instance, the fact that we are synthesizing a cut point is immaterial because we've already committed to part c. I.e., as we've said before, we don't jump from one part to another mid-processing. Ergo, I think we can explain ourselves out of having a special case here. That is, once the parent synthesizes something, it has determined it is authoritative for whatever it's about to synthesize. I don't think this (pretty much useless) case matters, but at least we can explain it with making a special (and pretty much useless) case out of it. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to 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/> From owner-namedroppers@ops.ietf.org Tue Oct 5 18:36:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19167 for <dnsext-archive@lists.ietf.org>; Tue, 5 Oct 2004 18:36:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CExsh-000Jai-Lu for namedroppers-data@psg.com; Tue, 05 Oct 2004 22:34:03 +0000 Received: from [192.150.250.67] (helo=fuchsia.home) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CExsf-000JaS-OX for namedroppers@ops.ietf.org; Tue, 05 Oct 2004 22:34:02 +0000 Received: from delta.noi.kre.to (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id i95MXqIj012264; Wed, 6 Oct 2004 05:33:52 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i95MXmaJ004722; Wed, 6 Oct 2004 05:33:50 +0700 (ICT) From: Robert Elz <kre@munnari.OZ.AU> To: Edward Lewis <edlewis@arin.net> cc: namedroppers@ops.ietf.org Subject: Re: progress on wcard draft In-Reply-To: <a06020418bd88c2194f5c@[192.136.136.113]> References: <a06020418bd88c2194f5c@[192.136.136.113]> <34931.1096789966@toybsd.zl2tnm.gen.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Oct 2004 05:33:48 +0700 Message-ID: <24415.1097015628@munnari.OZ.AU> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Tue, 5 Oct 2004 17:33:21 -0400 From: Edward Lewis <edlewis@arin.net> Message-ID: <a06020418bd88c2194f5c@[192.136.136.113]> | I don't think this (pretty much useless) case matters, but at least | we can explain it with making a special (and pretty much useless) | case out of it. Yes. Or in other words, 1034 is already explicit on all of this, though it does take careful reading. We should really be spending more effort on killing the myths than on worrying about this very unusual situation. That is, whatever an implementation does in this case, isn't really going to make a difference that anyone (anyone sane Bill... - sorry for the aside, response to a private message) will ever even notice, much less care about. Make it plain that wildcards are not pattern matching on queries, and that it is impossible to wildcard delegate, and most of what is really needed here will be done. 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Oct 5 18:49:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20155 for <dnsext-archive@lists.ietf.org>; Tue, 5 Oct 2004 18:49:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CEy56-000LAu-2d for namedroppers-data@psg.com; Tue, 05 Oct 2004 22:46:52 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CEy55-000LAh-9R for namedroppers@ops.ietf.org; Tue, 05 Oct 2004 22:46:51 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id A903567502 for <namedroppers@ops.ietf.org>; Tue, 5 Oct 2004 22:46:50 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.11/8.12.11) with ESMTP id i95MkNwf002262; Wed, 6 Oct 2004 08:46:23 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200410052246.i95MkNwf002262@drugs.dv.isc.org> To: Robert Elz <kre@munnari.OZ.AU> Cc: Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: progress on wcard draft In-reply-to: Your message of "Wed, 06 Oct 2004 05:33:48 +0700." <24415.1097015628@munnari.OZ.AU> Date: Wed, 06 Oct 2004 08:46:23 +1000 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Date: Tue, 5 Oct 2004 17:33:21 -0400 > From: Edward Lewis <edlewis@arin.net> > Message-ID: <a06020418bd88c2194f5c@[192.136.136.113]> > > | I don't think this (pretty much useless) case matters, but at least > | we can explain it with making a special (and pretty much useless) > | case out of it. > > Yes. > > Or in other words, 1034 is already explicit on all of this, though it > does take careful reading. > > We should really be spending more effort on killing the myths > than on worrying about this very unusual situation. That is, whatever > an implementation does in this case, isn't really going to make a difference > that anyone (anyone sane Bill... - sorry for the aside, response to a > private message) will ever even notice, much less care about. > > Make it plain that wildcards are not pattern matching on queries, and > that it is impossible to wildcard delegate, and most of what is really > needed here will be done. So you would have no objection to a implementation refusing to load a zone with wildcard NS records? Since they can't work it is better to report the error immediately. Similarly "* DNAME" cannot work. > 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: <http://ops.ietf.org/lists/namedroppers/> -- Mark Andrews, ISC 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Oct 5 19:06:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21844 for <dnsext-archive@lists.ietf.org>; Tue, 5 Oct 2004 19:06:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CEyMg-000O7f-VD for namedroppers-data@psg.com; Tue, 05 Oct 2004 23:05:02 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CEyMg-000O7A-48 for namedroppers@ops.ietf.org; Tue, 05 Oct 2004 23:05:02 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id BE4B013E12 for <namedroppers@ops.ietf.org>; Tue, 5 Oct 2004 23:05:01 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: progress on wcard draft In-Reply-To: Message from Mark Andrews <Mark_Andrews@isc.org> of "Wed, 06 Oct 2004 08:46:23 +1000." <200410052246.i95MkNwf002262@drugs.dv.isc.org> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 05 Oct 2004 23:05:01 +0000 Message-Id: <20041005230501.BE4B013E12@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > Make it plain that wildcards are not pattern matching on queries, and > > that it is impossible to wildcard delegate, and most of what is really > > needed here will be done. > > So you would have no objection to a implementation refusing > to load a zone with wildcard NS records? i would. > Since they can't work it is better to report the error immediately. just because they aren't wildcards doesn't mean they can't work. someone may want to create a zone called *.VIX.COM some day. it won't be a wild card, but a literal label of "*" is nowhere invalidated as a zone name, nor is a literal domain name of "FOO.*.VIX.COM" invalid (even though it would not be allowed as a hostname or mailname). > Similarly "* DNAME" cannot work. documenting the cases that are different, like "*" labels that won't have wildcard-like effects, is a good idea. insisting that valid labels and valid domain names be rejected just because they happen not to have the usual meaning in some context, is not a good idea. -- to 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/> From owner-namedroppers@ops.ietf.org Tue Oct 5 19:49:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25698 for <dnsext-archive@lists.ietf.org>; Tue, 5 Oct 2004 19:49:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CEz1A-0003Fw-1A for namedroppers-data@psg.com; Tue, 05 Oct 2004 23:46:52 +0000 Received: from [192.150.250.67] (helo=fuchsia.home) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CEz18-0003FV-08 for namedroppers@ops.ietf.org; Tue, 05 Oct 2004 23:46:51 +0000 Received: from delta.noi.kre.to (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id i95NjMIj018638; Wed, 6 Oct 2004 06:45:22 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i95NjKaJ028341; Wed, 6 Oct 2004 06:45:22 +0700 (ICT) From: Robert Elz <kre@munnari.OZ.AU> To: Mark Andrews <Mark_Andrews@isc.org> cc: Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org Subject: Re: progress on wcard draft In-Reply-To: <200410052246.i95MkNwf002262@drugs.dv.isc.org> References: <200410052246.i95MkNwf002262@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Oct 2004 06:45:20 +0700 Message-ID: <17020.1097019920@munnari.OZ.AU> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Wed, 06 Oct 2004 08:46:23 +1000 From: Mark Andrews <Mark_Andrews@isc.org> Message-ID: <200410052246.i95MkNwf002262@drugs.dv.isc.org> | So you would have no objection to a implementation refusing | to load a zone with wildcard NS records? Since they can't | work it is better to report the error immediately. I wouldn't use such an implementation, just like I wouldn't use one that refuses to load zones containing "peculiar" names - but others apparently like such things, so whatever... But they do "work" and work just fine (or should - the definition of what should be done is clear at least, so they can work in a bug free implementation). What they don't do is what (many) people expect them to do - which is an entirely different thing entirely. This is much the same as sticking an IPv4 address as the RDATA of an MX record. It is perfectly legal - the address looks just like a domain name, but it doesn't work (except by accident due to buggy implementations of various things). A server could look for that, and refuse to load a zone containing such a record - but shouldn't, as you never know when someone is going to do that who actually knows what they're doing. As in name IN MX 10 1.2.3.4 1.2.3.4 IN A 126.0.0.1 which should all work just fine, ignoring implementations with bugs (here, both DNS & MTA implementations.) | Similarly "* DNAME" cannot work. DNAME isn't in 1034, and my memory of just how it is defined, and how it alters the lookup algorithm isn't that good, so I won't comment on that one for now. 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Oct 5 20:13:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28936 for <dnsext-archive@lists.ietf.org>; Tue, 5 Oct 2004 20:13:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CEzNa-0006mg-7k for namedroppers-data@psg.com; Wed, 06 Oct 2004 00:10:02 +0000 Received: from [129.9.168.76] (helo=shvirpr4.extra.daimlerchrysler.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CEzNZ-0006mN-96 for namedroppers@ops.ietf.org; Wed, 06 Oct 2004 00:10:01 +0000 Received: from shnavip4-bak.shdc.chrysler.com (unknown [53.231.128.173]) by shvirpr4.extra.daimlerchrysler.com (Postfix) with SMTP id BB45E10FE9B for <namedroppers@ops.ietf.org>; Tue, 5 Oct 2004 20:10:00 -0400 (EDT) Received: from wokcdts1.is.chrysler.com ([53.230.102.252]) by shnavip4-bak.shdc.chrysler.com (SMSSMTP 4.0.0.59) with SMTP id M2004100520095732634 for <namedroppers@ops.ietf.org>; Tue, 05 Oct 2004 20:09:57 -0400 Received: from daimlerchrysler.com (wokcdts1.is.chrysler.com [53.230.102.252]) by wokcdts1.is.chrysler.com (8.11.7+Sun/8.9.1) with ESMTP id i9609qS21949 for <namedroppers@ops.ietf.org>; Tue, 5 Oct 2004 20:09:52 -0400 (EDT) Message-ID: <416337D0.9030706@daimlerchrysler.com> Date: Tue, 05 Oct 2004 20:09:52 -0400 From: Kevin Darcy <kcd@daimlerchrysler.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: progress on wcard draft References: <a06020416bd83737b0fba@[192.136.136.113]> <200410012048.i91KmWj4094810@drugs.dv.isc.org> <20008.1096730003@munnari.OZ.AU> In-Reply-To: <20008.1096730003@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Robert Elz wrote: > Date: Fri, 1 Oct 2004 17:00:11 -0400 > From: Edward Lewis <edlewis@arin.net> > Message-ID: <a06020416bd83737b0fba@[192.136.136.113]> > > > | 'Course, it would only really be interesting if "* NS" reacted as a > | referral in step 3b of RFC 1034 s4.3.2. > >Which it doesn't. 3b only gets used when there has been a name match. >Wildcards only get looked at in 3c, which only happens when there is no >name match. The two cases are exclusive. > There's nothing in 3b which says that it only applies to a full match of QNAME. 3b gets invoked when "a match would take us out of the authoritative data", which is certainly true if one presumes that wildcard NSes constitute delegations, and that the answering server happens to not be authoritative for the "synthetically" delegated subzone. Yes, that's circular, but so is the result if one makes the opposite presumption. Whether the lookup algorithm allows or precludes (wildcard NSes == delegation) depends entirely on whether one presumes at the outset that it does or does not. My point here is that the lookup algorithm does not _ipso_facto_ preclude wildcard NSes from serving as delegations. One has to look to the definitions (such as they are) of "delegation" and/or "zone cut" to determine that. And as far as I can tell, there's nothing there to say definitively that the owner names of delegating NS records have to *literally* match the name of the subzone they are delegating. The text can just as easily be read to say that anything suffices which is *understandable* as delegating one or more subzones, e.g. wildcards, potentially. The *intent* of a wildcard NS to delegate is quite clear, so I think the burden of proof should be on those wishing to deny that intent to show why it is specifically excluded. Section 4.2.2 doesn't help, since it says only that the delegation NS RRs and glue RRs "necessary to make the delegation effective" are required in the parent zone. That's very soft language. Wildcard NSes can "effectively" delegate subzones, as long as one does not read the RFC with the presumption that they cannot. Similarly, Section 4.2.1 refers to "data that describes delegated subzones". Certainly, wildcard NSes can "describe" delegated subzones, without actually having owner names which are literally, bit-for-bit equivalent to the names of those subzones (just as I can "describe" a house without actually using the word "house"). The text admits of multiple interpretations. If the intent is -- do we have rough WG consensus on this? -- to exclude wildcard NSes from functioning as delegations, I think the proper way would be to go back and tighten the definitions of "delegation" and/or "zone cut" as they relate to wildcards, or _vice_versa_. I don't see how a dissection of the lookup algorithm yields that result in any non-tautological way. Nor, of course, is the absence of any wildcard delegations from Section 6 dispositive proof that they are forbidden... - Kevin -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Oct 5 20:17:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29533 for <dnsext-archive@lists.ietf.org>; Tue, 5 Oct 2004 20:17:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CEzT9-0007Ti-Vg for namedroppers-data@psg.com; Wed, 06 Oct 2004 00:15:47 +0000 Received: from [203.96.144.16] (helo=gw.zl2tnm.gen.nz) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CEzT8-0007SY-R5 for namedroppers@ops.ietf.org; Wed, 06 Oct 2004 00:15:47 +0000 Received: from toybsd.zl2tnm.gen.nz (toybsd.zl2tnm.gen.nz [192.168.153.14]) by gw.zl2tnm.gen.nz (8.9.3/8.9.3) with ESMTP id NAA23672 for <namedroppers@ops.ietf.org>; Wed, 6 Oct 2004 13:15:45 +1300 Received: from toybsd.zl2tnm.gen.nz (don@localhost [127.0.0.1]) by toybsd.zl2tnm.gen.nz (8.12.9/8.12.9) with ESMTP id i960FjGK055028 for <namedroppers@ops.ietf.org>; Wed, 6 Oct 2004 13:15:45 +1300 (NZDT) (envelope-from don@toybsd.zl2tnm.gen.nz) To: namedroppers@ops.ietf.org Subject: Re: progress on wcard draft In-Reply-To: Your message of "Tue, 05 Oct 2004 17:33:21 EDT." <a06020418bd88c2194f5c@[192.136.136.113]> From: Don Stokes <don@plugh.daedalus.co.nz> Date: Wed, 06 Oct 2004 13:15:45 +1300 Message-ID: <55027.1097021745@toybsd.zl2tnm.gen.nz> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward Lewis <edlewis@arin.net> wrote: >In this instance, the fact that we are synthesizing a cut point is >immaterial because we've already committed to part c. I.e., as we've >said before, we don't jump from one part to another mid-processing. Sure. My reading of 1034 sec 4.3.2 is that you can't use a wildcard NS to synthesise a referral, so if referral synthesis is codified, we need to realise that this would supersede the algorithm specified in 1034. >Ergo, I think we can explain ourselves out of having a special case >here. That is, once the parent synthesizes something, it has >determined it is authoritative for whatever it's about to synthesize. > >I don't think this (pretty much useless) case matters, but at least >we can explain it with making a special (and pretty much useless) >case out of it. Before we abandon synthesised referrals completely, consider this possible configuration. I have two sets of name servers, one set, call them A & B, as the delegated name servers for a domain. I have two more, C & D, for "customer" domains. A & B have: $ORIGIN foo.example. @ SOA ... NS a NS b A 10.0.0.99 a A 10.0.0.1 b A 172.16.0.1 c A 10.0.0.3 d A 10.0.0.4 mail MX 10.0.0.99 www A 10.0.0.99 * NS c NS d C & D carry customer domains within foo.example. They are not BIND servers (I can think of a way to do this using BIND, but it's messy and would confuse the issue), but respond with authoritative, synthesised data for <whatever>.foo.example, e.g. given queries for bar.foo.example, they would return: $ORIGIN bar.foo.example. @ SOA ... NS c.foo.example. d.foo.example. MX 0 mail.foo.example. A 10.0.0.101 www A 10.0.0.101 plus -- and this is important -- any other records specific to the customer, e.g. myhost A 192.168.1.2 Now, sure, this could all be done using normal referrals, but to do so, A & B need to have information about the customer domains on C & D. Simply referring all queries for <whatever>.foo.example to C & D allows the sub-zones to be carried by C & D, while keeping parent data on A & B. For this to work, A & B really have to synthesise referrals for the * NS records. If the word is that wildcard NS records don't provide wildcard referrals, then another way would have to be found to do this, at least if the parent domain was to be secondaried on standards-compliant platforms. -- don -- to 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/> From owner-namedroppers@ops.ietf.org Tue Oct 5 20:20:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29893 for <dnsext-archive@lists.ietf.org>; Tue, 5 Oct 2004 20:20:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CEzW4-0007qN-Cv for namedroppers-data@psg.com; Wed, 06 Oct 2004 00:18:48 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CEzW3-0007q8-Lb for namedroppers@ops.ietf.org; Wed, 06 Oct 2004 00:18:47 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 35E8667503 for <namedroppers@ops.ietf.org>; Wed, 6 Oct 2004 00:18:47 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.11/8.12.11) with ESMTP id i960IVRh050419; Wed, 6 Oct 2004 10:18:31 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200410060018.i960IVRh050419@drugs.dv.isc.org> To: Robert Elz <kre@munnari.OZ.AU> Cc: Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: progress on wcard draft In-reply-to: Your message of "Wed, 06 Oct 2004 06:45:20 +0700." <17020.1097019920@munnari.OZ.AU> Date: Wed, 06 Oct 2004 10:18:31 +1000 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Date: Wed, 06 Oct 2004 08:46:23 +1000 > From: Mark Andrews <Mark_Andrews@isc.org> > Message-ID: <200410052246.i95MkNwf002262@drugs.dv.isc.org> > > | So you would have no objection to a implementation refusing > | to load a zone with wildcard NS records? Since they can't > | work it is better to report the error immediately. > > I wouldn't use such an implementation, just like I wouldn't use > one that refuses to load zones containing "peculiar" names - but > others apparently like such things, so whatever... > > But they do "work" and work just fine (or should - the definition of > what should be done is clear at least, so they can work in a bug free > implementation). What they don't do is what (many) people expect > them to do - which is an entirely different thing entirely. > > This is much the same as sticking an IPv4 address as the RDATA of an > MX record. It is perfectly legal - the address looks just like a > domain name, but it doesn't work (except by accident due to buggy > implementations of various things). > > A server could look for that, and refuse to load a zone containing > such a record - but shouldn't, as you never know when someone is > going to do that who actually knows what they're doing. As in > > name IN MX 10 1.2.3.4 > 1.2.3.4 IN A 126.0.0.1 > > which should all work just fine, ignoring implementations with bugs > (here, both DNS & MTA implementations.) As it should. However emitting a warning (with knob to disable) on this (and similarly NS rdata) when it contains a IP address (w/ or w/o the terminating period) is quite reasonable to do as is a common mis-configuration. -- Mark Andrews, ISC 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Oct 5 20:46:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02108 for <dnsext-archive@lists.ietf.org>; Tue, 5 Oct 2004 20:46:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CEzve-000AsR-2k for namedroppers-data@psg.com; Wed, 06 Oct 2004 00:45:14 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CEzvd-000AsE-5E for namedroppers@ops.ietf.org; Wed, 06 Oct 2004 00:45:13 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 310B267502 for <namedroppers@ops.ietf.org>; Wed, 6 Oct 2004 00:45:11 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.11/8.12.11) with ESMTP id i960j5l3050535; Wed, 6 Oct 2004 10:45:05 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200410060045.i960j5l3050535@drugs.dv.isc.org> To: Kevin Darcy <kcd@daimlerchrysler.com> Cc: namedroppers@ops.ietf.org From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: progress on wcard draft In-reply-to: Your message of "Tue, 05 Oct 2004 20:09:52 -0400." <416337D0.9030706@daimlerchrysler.com> Date: Wed, 06 Oct 2004 10:45:05 +1000 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Robert Elz wrote: > > > Date: Fri, 1 Oct 2004 17:00:11 -0400 > > From: Edward Lewis <edlewis@arin.net> > > Message-ID: <a06020416bd83737b0fba@[192.136.136.113]> > > > > > > | 'Course, it would only really be interesting if "* NS" reacted as a > > | referral in step 3b of RFC 1034 s4.3.2. > > > >Which it doesn't. 3b only gets used when there has been a name match. > >Wildcards only get looked at in 3c, which only happens when there is no > >name match. The two cases are exclusive. > > > There's nothing in 3b which says that it only applies to a full match of > QNAME. 3b gets invoked when "a match would take us out of the > authoritative data", which is certainly true if one presumes that > wildcard NSes constitute delegations, and that the answering server > happens to not be authoritative for the "synthetically" delegated > subzone. Yes, that's circular, but so is the result if one makes the > opposite presumption. Whether the lookup algorithm allows or precludes > (wildcard NSes == delegation) depends entirely on whether one presumes > at the outset that it does or does not. > > My point here is that the lookup algorithm does not _ipso_facto_ > preclude wildcard NSes from serving as delegations. One has to look to > the definitions (such as they are) of "delegation" and/or "zone cut" to > determine that. And as far as I can tell, there's nothing there to say > definitively that the owner names of delegating NS records have to > *literally* match the name of the subzone they are delegating. The text > can just as easily be read to say that anything suffices which is > *understandable* as delegating one or more subzones, e.g. wildcards, > potentially. The *intent* of a wildcard NS to delegate is quite clear, > so I think the burden of proof should be on those wishing to deny that > intent to show why it is specifically excluded. Section 4.2.2 doesn't > help, since it says only that the delegation NS RRs and glue RRs > "necessary to make the delegation effective" are required in the parent > zone. That's very soft language. Wildcard NSes can "effectively" > delegate subzones, as long as one does not read the RFC with the > presumption that they cannot. Similarly, Section 4.2.1 refers to "data > that describes delegated subzones". Certainly, wildcard NSes can > "describe" delegated subzones, without actually having owner names which > are literally, bit-for-bit equivalent to the names of those subzones > (just as I can "describe" a house without actually using the word > "house"). The text admits of multiple interpretations. > > If the intent is -- do we have rough WG consensus on this? -- to exclude > wildcard NSes from functioning as delegations, I think the proper way > would be to go back and tighten the definitions of "delegation" and/or > "zone cut" as they relate to wildcards, or _vice_versa_. I don't see how > a dissection of the lookup algorithm yields that result in any > non-tautological way. > > Nor, of course, is the absence of any wildcard delegations from Section > 6 dispositive proof that they are forbidden... > > - Kevin > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> Does a "* NS" match only one label? (This would usually be the intent.) Does a "* NS" match multiple labels? (This is what RFC 1034 would imply.) Can you sub delegate from a wild card delegation? (This would require single label match sematics.) How is this going react with anti-cache poisoning code? (Especially if you have multiple match.) Do you get a consistant namespace from all servers involved without adding additional constraints? (e.g. child server must have a copy of the parent zone.) Does the zone lookup algorithm process the wildcard (child servers)? Once you allow "* NS" to wildcard match you have to decide how to answer these and other similar questions. Mark -- Mark Andrews, ISC 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Oct 6 03:50:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29016 for <dnsext-archive@lists.ietf.org>; Wed, 6 Oct 2004 03:50:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CF6Uw-000Eqd-Ha for namedroppers-data@psg.com; Wed, 06 Oct 2004 07:46:06 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CF6Uv-000EqQ-Rz for namedroppers@ops.ietf.org; Wed, 06 Oct 2004 07:46:06 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 5839C4EEFB; Wed, 6 Oct 2004 09:46:05 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id E950E4EECF; Wed, 6 Oct 2004 09:46:04 +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 i967k4rL017078; Wed, 6 Oct 2004 09:46:04 +0200 Date: Wed, 6 Oct 2004 09:46:04 +0200 From: "Olaf M. Kolkman" <olaf@ripe.net> To: Kevin Darcy <kcd@daimlerchrysler.com> Cc: namedroppers@ops.ietf.org Subject: Re: progress on wcard draft Message-Id: <20041006094604.52ba5abe.olaf@ripe.net> In-Reply-To: <416337D0.9030706@daimlerchrysler.com> References: <a06020416bd83737b0fba@[192.136.136.113]> <200410012048.i91KmWj4094810@drugs.dv.isc.org> <20008.1096730003@munnari.OZ.AU> <416337D0.9030706@daimlerchrysler.com> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.11 (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.000003 / 0.0 / 0.0 / disabled X-RIPE-Signature: c02436411b43a4c1fbb3399ff79fbdaa X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 05 Oct 2004 20:09:52 -0400 Kevin Darcy <kcd@daimlerchrysler.com> wrote: > If the intent is -- do we have rough WG consensus on this? -- to exclude > wildcard NSes from functioning as delegations, We don't. Iff the scripture can be interpreted unambiguosly we do not have to get consensus on this. We just need consensus on the fact that everybody reads the same. You just argued that there are multiple interpretations possible. If there is consensus that the text can be interpreted in two ways than we have to make the choice on what the sensible thing is. (One of the options is to clarify that both interpretations are possible and that therefore interoperabillity cannot be expected.) -- 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Oct 6 05:47:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06954 for <dnsext-archive@lists.ietf.org>; Wed, 6 Oct 2004 05:47:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CF8Ll-00055p-Fl for namedroppers-data@psg.com; Wed, 06 Oct 2004 09:44:45 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CF8Lk-00055b-II for namedroppers@ops.ietf.org; Wed, 06 Oct 2004 09:44:44 +0000 Received: from [193.133.15.218] (ben-xp2.ben.algroup.co.uk [193.133.15.218]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 89444107837; Wed, 6 Oct 2004 09:44:43 +0000 (GMT) Message-ID: <4163BE8D.6000706@algroup.co.uk> Date: Wed, 06 Oct 2004 10:44:45 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: DNSEXT WG <namedroppers@ops.ietf.org>, dnsop@lists.uoregon.edu Subject: Key Distribution I-D X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The I-D editors seem to be sitting on it, so here's my copy... http://www.links.org/dnssec/draft-laurie-dnssec-key-distribution-00.txt http://www.links.org/dnssec/draft-laurie-dnssec-key-distribution-00.html Abstract: Until DNSSEC is fully deployed, so-called "islands of trust" will exist. This will lead to a large number of keys with no method within DNSSEC to manage the keys. This proposal seeks to address that issue using existing mechanisms to allow cross-signing of root (i.e. roots of islands) keys. This cross-signing of keys creates a non-hierarchical web of trust which permits the efficient gathering and validation of trust anchors. Comments welcome, of course. Not sure whether it belongs in DNSOP or DNSEXT, hence the crossposting. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to 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/> From owner-namedroppers@ops.ietf.org Wed Oct 6 06:18:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09111 for <dnsext-archive@lists.ietf.org>; Wed, 6 Oct 2004 06:18:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CF8qj-00095g-6K for namedroppers-data@psg.com; Wed, 06 Oct 2004 10:16:45 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CF8qi-00095L-E2 for namedroppers@ops.ietf.org; Wed, 06 Oct 2004 10:16:44 +0000 Received: from [193.133.15.218] (ben-xp2.ben.algroup.co.uk [193.133.15.218]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id BAA63107837 for <namedroppers@ops.ietf.org>; Wed, 6 Oct 2004 10:16:43 +0000 (GMT) Message-ID: <4163C60D.4080003@algroup.co.uk> Date: Wed, 06 Oct 2004 11:16:45 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: DNSEXT WG <namedroppers@ops.ietf.org> Subject: Requirments Question X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit As has been requested, I am constructing a matrix of compatibility between requirements in the requirements I-D. Whilst doing so, I realise I don't understand one of them: 23. Coexistence with NSEC NSEC++ should be designed to coexist with NSEC. Contributor: Ed Lewis What is this supposed to mean in practice? Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to 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/> From owner-namedroppers@ops.ietf.org Wed Oct 6 09:06:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21422 for <dnsext-archive@lists.ietf.org>; Wed, 6 Oct 2004 09:06:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CFBQA-0004RY-0J for namedroppers-data@psg.com; Wed, 06 Oct 2004 13:01:30 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CFBQ6-0004Qu-2H for namedroppers@ops.ietf.org; Wed, 06 Oct 2004 13:01:26 +0000 Received: from [193.133.15.218] (ben-xp2.ben.algroup.co.uk [193.133.15.218]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 66570107837 for <namedroppers@ops.ietf.org>; Wed, 6 Oct 2004 13:01:25 +0000 (GMT) Message-ID: <4163ECA7.8050404@algroup.co.uk> Date: Wed, 06 Oct 2004 14:01:27 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: DNSEXT WG <namedroppers@ops.ietf.org> Subject: Requirements Matrix X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I have uploaded my first cut at a compatibility matrix for NSEC++ requirements. It is available as both a spreadsheet and a web page: http://www.links.org/dnssec/requirements-matrix.htm http://www.links.org/dnssec/requirements-matrix.xls I'm sure I've got some of them wrong, so please take a look. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to 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/> From owner-namedroppers@ops.ietf.org Wed Oct 6 10:18:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00493 for <dnsext-archive@lists.ietf.org>; Wed, 6 Oct 2004 10:18:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CFCaL-000EUZ-HB for namedroppers-data@psg.com; Wed, 06 Oct 2004 14:16:05 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CFCaJ-000EUA-VO for namedroppers@ops.ietf.org; Wed, 06 Oct 2004 14:16:04 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 2DD941440CD; Wed, 6 Oct 2004 10:15:53 -0400 (EDT) Received: from mercury.arin.net (mercury.arin.net [192.149.252.131]) by smtp2.arin.net (Postfix) with ESMTP id 9733B144095; Wed, 6 Oct 2004 10:15:52 -0400 (EDT) Received: from [192.136.136.113] (mercury.arin.net [127.0.0.1]) by mercury.arin.net (Postfix) with ESMTP id CF9961FE5E; Wed, 6 Oct 2004 10:15:51 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a0602041ebd89a81b0e12@[192.136.136.113]> In-Reply-To: <55027.1097021745@toybsd.zl2tnm.gen.nz> References: <55027.1097021745@toybsd.zl2tnm.gen.nz> Date: Wed, 6 Oct 2004 10:15:17 -0400 To: Don Stokes <don@plugh.daedalus.co.nz> From: Edward Lewis <edlewis@arin.net> Subject: Re: progress on wcard draft Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 13:15 +1300 10/6/04, Don Stokes wrote: > >For this to work, A & B really have to synthesise referrals for the * NS >records. If the word is that wildcard NS records don't provide wildcard >referrals, then another way would have to be found to do this, at least >if the parent domain was to be secondaried on standards-compliant >platforms. The way I see Step 3 now reading, in summary fashion is: a) if there is an exact match with a CNAME, restart the process with the new search name. b) if you run across a cut point, you issue a referral. c) if you find an exact match not a CNAME, you answer from that otherwise, you look for the wildcard (set) that equals the QTYPE. The WG has already moved to amend the above to add to make step c: c) if you find an exact match not a CNAME, you answer from that otherwise, you look for the wildcard (set) that equals the QTYPE, OR you look for a wildcard CNAME and you restart the process with the new search name. What is proposed above would make c: c) if you find an exact match not a CNAME, you answer from that otherwise, you look for the wildcard (set) that equals the QTYPE, OR you look for a wildcard CNAME and you restart the process with the new search name OR you look for a wildcard NS (set) and synthesize a referral message. Does that sound like a decent categorization of the proposal? Does that sound reasonable? BTW - "exact match" in step a means strict DNS label equality, not a match by wildcard rule. This may not be the right interpretation. If we take the word "match" in the original part a to mean "by wildcard rule" then the three parts could be seen as: a) if there is an exact or wildcard match with a CNAME, restart the process with the new search name. b) if you run across a cut point, you issue a referral. c) if you find an exact match not a CNAME, you answer from that otherwise, you look for the wildcard (set) that equals the QTYPE, OR you look for a wildcard NS (set) and synthesize a referral message. All this does is move one clause of C to A - which is the justification for changing C to "chase" the CNAME. Then again, b uses "match" too, so maybe we could read the three parts as: a) if there is an exact or wildcard match with a CNAME, restart the process with the new search name. b) if there is an exact or wildcard match with an NS, you issue a referral. (The one exception is that the sought name (SNAME) is not the zone's SOA owner name/apex.) c) otherwise you answer from the exact or wildcard matching name. In a way - re-interpreting "match" makes the three parts balance better - we no longer have a and b with specific rules and c having multiple parts. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to 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/> From owner-namedroppers@ops.ietf.org Wed Oct 6 10:19:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00579 for <dnsext-archive@lists.ietf.org>; Wed, 6 Oct 2004 10:19:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CFCaC-000ETd-LM for namedroppers-data@psg.com; Wed, 06 Oct 2004 14:15:56 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CFCa9-000ETB-Ns for namedroppers@ops.ietf.org; Wed, 06 Oct 2004 14:15:55 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 99D681440AE; Wed, 6 Oct 2004 10:15:51 -0400 (EDT) Received: from mercury.arin.net (mercury.arin.net [192.149.252.131]) by smtp2.arin.net (Postfix) with ESMTP id D4664144095; Wed, 6 Oct 2004 10:15:50 -0400 (EDT) Received: from [192.136.136.113] (mercury.arin.net [127.0.0.1]) by mercury.arin.net (Postfix) with ESMTP id C52051FE5E; Wed, 6 Oct 2004 10:15:50 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a0602041dbd89a3a90382@[192.136.136.113]> In-Reply-To: <416337D0.9030706@daimlerchrysler.com> References: <a06020416bd83737b0fba@[192.136.136.113]> <200410012048.i91KmWj4094810@drugs.dv.isc.org> <20008.1096730003@munnari.OZ.AU> <416337D0.9030706@daimlerchrysler.com> Date: Wed, 6 Oct 2004 09:47:42 -0400 To: Kevin Darcy <kcd@daimlerchrysler.com> From: Edward Lewis <edlewis@arin.net> Subject: Re: progress on wcard draft Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 20:09 -0400 10/5/04, Kevin Darcy wrote: >There's nothing in 3b which says that it only applies to a full match of >QNAME. 3b gets invoked when "a match would take us out of the authoritative >data", which is certainly true if one presumes that wildcard NSes constitute >delegations, and that the answering server happens to not be authoritative for >the "synthetically" delegated subzone. Yes, that's circular, but so is the >result if one makes the opposite presumption. Whether the lookup algorithm >allows or precludes (wildcard NSes == delegation) depends entirely on whether >one presumes at the outset that it does or does not. (Speaking as the document editor:) You are hitting on the one issue that keeps me up at night, the lack of attention paid to what it means to "match." (As I said, this as editor. As me, I really do sleep quite well.) >My point here is that the lookup algorithm does not _ipso_facto_ preclude What does "ipso facto" mean? The only times I've heard it is a comedy when the character wants to sound like a lunatic professor. ;) (Not that I am attaching any of that characterization to *anyone* on this list.) >wildcard NSes from serving as delegations. One has to look to the definitions >(such as they are) of "delegation" and/or "zone cut" to determine that. And as >far as I can tell, there's nothing there to say definitively that the owner >names of delegating NS records have to *literally* match the name of the >subzone they are delegating. The text can just as easily be read to say that >anything suffices which is *understandable* as delegating one or more >subzones, e.g. wildcards, potentially. The *intent* of a wildcard NS to >delegate is quite clear, so I think the burden of proof should be on those >wishing to deny that intent to show why it is specifically excluded. Section >4.2.2 doesn't help, since it says only that the delegation NS RRs and glue RRs >"necessary to make the delegation effective" are required in the parent zone. >That's very soft language. Wildcard NSes can "effectively" delegate subzones, >as long as one does not read the RFC with the presumption that they cannot. >Similarly, Section 4.2.1 refers to "data that describes delegated subzones". >Certainly, wildcard NSes can "describe" delegated subzones, without actually >having owner names which are literally, bit-for-bit equivalent to the names of >those subzones (just as I can "describe" a house without actually using the >word "house"). The text admits of multiple interpretations. This is where the word "match" becomes the problem. As in "c. If at some label, a match is impossible (i.e., the corresponding label does not exist)" - I have taken a match to be 1) case-folded bitwise sameness (equality). Also, 2) the matches are done on what is in the tree, and the synthesized names are not. 'Course, that has been my interpretation. I guess I didn't figure it enough of an issue to raise the meaning of "match" as an issue. In the next version of the doc I plan to include an ASCII-art rendition of a small example zone to illustrate the tree concept. Looking at it that way gives the strong impression that "if at some label, a match" refers to just the nodes as they sit in the tree, not as if they might match. OTOH, there is "is impossible" which opens the question of what are the possibilities for matching. And, OTOF (foot) - I'm quoting from step 3 part c - the exact match/wildcard step and not from step 3 part b - which is where the question of zone cut (or delegation point) arises. >If the intent is -- do we have rough WG consensus on this? -- to exclude >wildcard NSes from functioning as delegations, I think the proper way would be >to go back and tighten the definitions of "delegation" and/or "zone cut" as >they relate to wildcards, or _vice_versa_. I don't see how a dissection of the >lookup algorithm yields that result in any non-tautological way. I'm not the chair, but as editor, I don't think I have a clear enough consensus to have faith that the document is "done." I hope to have a draft out last week, err, this week, and will have something by next week (IETF deadline) - just to have a draft active for the meeting in November. >Nor, of course, is the absence of any wildcard delegations from Section 6 >dispositive proof that they are forbidden... Well, if it did, the wcard clarification document would be a lot shorter. ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to 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/> From owner-namedroppers@ops.ietf.org Wed Oct 6 12:45:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11620 for <dnsext-archive@lists.ietf.org>; Wed, 6 Oct 2004 12:45:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CFEqx-000CIu-Rh for namedroppers-data@psg.com; Wed, 06 Oct 2004 16:41:23 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CFEqw-000CIU-5h for namedroppers@ops.ietf.org; Wed, 06 Oct 2004 16:41:22 +0000 Received: from delta.noi.kre.to (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id i96GfJG15743; Wed, 6 Oct 2004 23:41:19 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i96GfG8S022978; Wed, 6 Oct 2004 23:41:18 +0700 (ICT) From: Robert Elz <kre@munnari.OZ.AU> To: Kevin Darcy <kcd@daimlerchrysler.com> cc: namedroppers@ops.ietf.org Subject: Re: progress on wcard draft In-Reply-To: <416337D0.9030706@daimlerchrysler.com> References: <416337D0.9030706@daimlerchrysler.com> <a06020416bd83737b0fba@[192.136.136.113]> <200410012048.i91KmWj4094810@drugs.dv.isc.org> <20008.1096730003@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Oct 2004 23:41:16 +0700 Message-ID: <16999.1097080876@munnari.OZ.AU> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Tue, 05 Oct 2004 20:09:52 -0400 From: Kevin Darcy <kcd@daimlerchrysler.com> Message-ID: <416337D0.9030706@daimlerchrysler.com> | There's nothing in 3b which says that it only applies to a full match of | QNAME. I didn't say "full match of a QNAME" I said "name match", and perhaps should have instead said "label match". | 3b gets invoked when "a match would take us out of the | authoritative data", which is certainly true if one presumes that | wildcard NSes constitute delegations, No, it isn't - wildcards are not matches - they're *never* matches. (a '*' label might be a match to a '*' label in a query, but then it isn't a wildcard - or isn't acting as one for this query). Just look at 3c, it clearly says, if there is no match, then look for a '*' label - it doesn't say that makes a match, instead, it says to synthesise records (if there's an appropriate RR type at '*'), stick them in the answer section, and goto 6 (ie: get out of here). That is, once you have used the wildcard, the algorithm is quite explicit, you're done, and there's no way to add a referral to the reply ('6' actually is where additional info records get added, but they affect nothing). This really is very clear. | Whether the lookup algorithm allows or precludes | (wildcard NSes == delegation) depends entirely on whether one presumes | at the outset that it does or does not. No, it doesn't. I know that, because I presumed at the outset that it did (allow them), having listened to people go on and on for years about wildcard delegations, and zone synthesis, and stuff, as if they were expected to happen (and just no-one had bothered to implement them, and perhaps they were a crazy idea anyway - the big question always seemed to be how we would get them onto he secondary servers). Then I actually read the text in 1034 carefully. That changed my mind. There is definitely no way to synthesise zones (using the wildcard algorithm in 1034 - servers could do it other ways, or even by perverting wildcards). | My point here is that the lookup algorithm does not _ipso_facto_ | preclude wildcard NSes from serving as delegations. Maybe I'm a lunatic professor, but I know what ipso facto is, and you're wrong, the lookup algorithm does preclude them. Where you go wrong is in treating wildcards as if they're matching something. They don't, and never did. It's a great pity that '*' was used as the wildcard character, given its use in regular expressions, and "glob" patterns, but we can't do anything about that now. | The *intent* of a wildcard NS to delegate is quite clear, You mean the intent of people who use the things - yes, it probably is, in almost every case. The intent of the standard in '* NS' is just to delegate the '*' name (literally) however - and that really probably only because it is a legal name itself, as well as being a wildcard, just as is everything else (between 1 & 63 octets). 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Oct 6 12:46:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11684 for <dnsext-archive@lists.ietf.org>; Wed, 6 Oct 2004 12:46:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CFEsk-000CbN-FU for namedroppers-data@psg.com; Wed, 06 Oct 2004 16:43:14 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CFEsj-000CaU-24 for namedroppers@ops.ietf.org; Wed, 06 Oct 2004 16:43:13 +0000 Received: from delta.noi.kre.to (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id i96Gh9G15810; Wed, 6 Oct 2004 23:43:10 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i96Gh48S023495; Wed, 6 Oct 2004 23:43:09 +0700 (ICT) From: Robert Elz <kre@munnari.OZ.AU> To: Mark Andrews <Mark_Andrews@isc.org> cc: Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org Subject: Re: progress on wcard draft In-Reply-To: <200410060018.i960IVRh050419@drugs.dv.isc.org> References: <200410060018.i960IVRh050419@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Oct 2004 23:43:04 +0700 Message-ID: <24744.1097080984@munnari.OZ.AU> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Wed, 06 Oct 2004 10:18:31 +1000 From: Mark Andrews <Mark_Andrews@isc.org> Message-ID: <200410060018.i960IVRh050419@drugs.dv.isc.org> | However emitting a warning (with knob to disable) on this | (and similarly NS rdata) when it contains a IP address (w/ | or w/o the terminating period) is quite reasonable to do | as is a common mis-configuration. Yes, as I said - implementations can do whatever hand holding for the "average" user they like - but if they're to be generally used, they also need to be able to handle all the weird cases. Most certainly any such knob needs to affect only locally loaded zones (primary server stuff) - not AXFR transferred data. 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Oct 6 13:34:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15569 for <dnsext-archive@lists.ietf.org>; Wed, 6 Oct 2004 13:34:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CFFal-000Jjh-HI for namedroppers-data@psg.com; Wed, 06 Oct 2004 17:28:43 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CFFak-000Jib-Ou for namedroppers@ops.ietf.org; Wed, 06 Oct 2004 17:28:42 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 8704813E42 for <namedroppers@ops.ietf.org>; Wed, 6 Oct 2004 17:28:42 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: progress on wcard draft In-Reply-To: Message from "Olaf M. Kolkman" <olaf@ripe.net> of "Wed, 06 Oct 2004 09:46:04 +0200." <20041006094604.52ba5abe.olaf@ripe.net> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 06 Oct 2004 17:28:42 +0000 Message-Id: <20041006172842.8704813E42@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > If the intent is -- do we have rough WG consensus on this? -- to > > exclude wildcard NSes from functioning as delegations, > > We don't. > > Iff the scripture can be interpreted unambiguosly we do not have to > get consensus on this. We just need consensus on the fact that > everybody reads the same. You just argued that there are multiple > interpretations possible. i do not agree with kevin's multiple-interpretation assertion. the document is unambiguous as written, and the best we can do is clarify that wildcard NS's are not supported by the present specifications. > If there is consensus that the text can be interpreted in two ways > than we have to make the choice on what the sensible thing is. (One of > the options is to clarify that both interpretations are possible and > that therefore interoperabillity cannot be expected.) ouch. i hope not. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Oct 6 14:08:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17976 for <dnsext-archive@lists.ietf.org>; Wed, 6 Oct 2004 14:08:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CFGAg-000PE5-QF for namedroppers-data@psg.com; Wed, 06 Oct 2004 18:05:50 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CFGAg-000PDo-1j for namedroppers@ops.ietf.org; Wed, 06 Oct 2004 18:05:50 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 3BFFA144167; Wed, 6 Oct 2004 14:05:49 -0400 (EDT) Received: from mercury.arin.net (mercury.arin.net [192.149.252.131]) by smtp2.arin.net (Postfix) with ESMTP id A6D4F1440CD; Wed, 6 Oct 2004 14:05:48 -0400 (EDT) Received: from [192.136.136.113] (mercury.arin.net [127.0.0.1]) by mercury.arin.net (Postfix) with ESMTP id BB6161FE68; Wed, 6 Oct 2004 14:05:48 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a06020426bd89e0734301@[192.136.136.113]> In-Reply-To: <24744.1097080984@munnari.OZ.AU> References: <200410060018.i960IVRh050419@drugs.dv.isc.org> <24744.1097080984@munnari.OZ.AU> Date: Wed, 6 Oct 2004 13:50:52 -0400 To: Robert Elz <kre@munnari.OZ.AU> From: Edward Lewis <edlewis@arin.net> Subject: Re: progress on wcard draft Cc: Mark Andrews <Mark_Andrews@isc.org>, Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 23:43 +0700 10/6/04, Robert Elz wrote: > Date: Wed, 06 Oct 2004 10:18:31 +1000 > From: Mark Andrews <Mark_Andrews@isc.org> > Message-ID: <200410060018.i960IVRh050419@drugs.dv.isc.org> > > | However emitting a warning (with knob to disable) on this > | (and similarly NS rdata) when it contains a IP address (w/ > | or w/o the terminating period) is quite reasonable to do > | as is a common mis-configuration. > >Yes, as I said - implementations can do whatever hand holding for the >"average" user they like - but if they're to be generally used, they also >need to be able to handle all the weird cases. > >Most certainly any such knob needs to affect only locally loaded zones >(primary server stuff) - not AXFR transferred data. Although I did at one time mention logging an event, which I did to provide an example of courses of actions, I don't think any statements on logging belong in a DNS "specification" document. Logging is good, logging is admirable, but as far as DNS is concerned, it is not an interoperability issue. (Perhaps to SYSLOG WG or some-such.) Unless there's sentiment otherwise, I plan to omit any discussion of logging from the wcard clarification document. But - discuss away anyhow. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to 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/> From owner-namedroppers@ops.ietf.org Wed Oct 6 15:16:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24878 for <dnsext-archive@lists.ietf.org>; Wed, 6 Oct 2004 15:16:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CFHBc-0008EH-H2 for namedroppers-data@psg.com; Wed, 06 Oct 2004 19:10:52 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CFHBa-0008E2-HH for namedroppers@ops.ietf.org; Wed, 06 Oct 2004 19:10:51 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id ABD22C2DA8; Wed, 6 Oct 2004 20:10:48 +0100 (BST) Date: Wed, 06 Oct 2004 20:10:37 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: Ben Laurie <ben@algroup.co.uk>, DNSEXT WG <namedroppers@ops.ietf.org> Cc: Alex Bligh <alex@alex.org.uk> Subject: Re: Requirements Matrix Message-ID: <55A312B840C3132BF37F4AE8@[192.168.100.25]> In-Reply-To: <4163ECA7.8050404@algroup.co.uk> References: <4163ECA7.8050404@algroup.co.uk> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 06 October 2004 14:01 +0100 Ben Laurie <ben@algroup.co.uk> wrote: > I have uploaded my first cut at a compatibility matrix for NSEC++ > requirements. It is available as both a spreadsheet and a web page: > > http://www.links.org/dnssec/requirements-matrix.htm > http://www.links.org/dnssec/requirements-matrix.xls > > I'm sure I've got some of them wrong, so please take a look. OK some comments mainly on the red & yellow areas: [ I may have misunderstood (27) but I took it to mean "I can sign some intervals as non-existing without revealing ANYTHING about other names - not only what they are, but not (necessarily) whether they exist or not" - IE a combination of non-enumerability and support for intervals which did not deny existence at all (a la 26). ] Inconsistencies within the Matrix ================================= I did a matrix transpose and found out what happened: 17 is marked as incompatible with 7, but 7 is marked as compatible with 17. I don't think they are incompatible. 7 is marked compatible with 10, but 10 is marked incompatible with 7. I don't think they are incompatible. 9 is marked compatible with 10, but 10 is marked incompatible with 9. I don't think they are per-se incompatible but I'm not sure. Compatibility ============= Requirements 20 & 21 which say: "NSEC++ should not introduce changes incompatible with NSEC." & "NSEC++ should differ from NSEC in a way that is transparent to the resolver or validator." are marked as incompatible with (in essence) the zone non-enumeration requirements and the 27 (called protocol design but essentially about partially signed zones or at least zones only partially signed for non-existence which I think is the same thing or very nearly). I think there is a possible interpretation problem here, to do with mandatory and option support. It is possible to read the zone enumeration requirements as mandatorily applying to all zones, AND to read "incompatible" (in 26) as meaning "if any resolver implementing DNSSECbis NSEC only - not NSEC++ - cannot interpret the responses then it's failed the test" THEN clearly we have a problem. If that's what the red square means, I understand it, but it's not particularly useful. However, I do not think it is necessarily impossible to have (for instance) * NSEC / NSEC++ / unsigned zones as alternatives on the server side * NSEC++ designed such that it looks like an unsigned zone to resolvers supporting NSEC but not NSEC++ If that's what you meant by the red square Ben, I'd ask why. It /might/ be possible (in essence through permitting responses currently prohibited by DNSSEC-bis in a manner which cannot harm any compliant DNSSEC-bis resolver) to have a zone constructed for NSEC++ signing still return authenticated records other than NSEC records for resolvers supporting DNSSEC-bis (& NSEC) but not NSEC++. I am not saying it *is* possible, I just don't think anyone's conclusively demonstrated that it's not. Requirement 19 - Replay Attacks =============================== I am going to stick my neck out and say I think the problem of replay attacks IS soluble even in the theoretical case less likely than meteor destroying the earth (etc.). I think I've said this before and haven't been contradicted. You can solve this by two measures, each of which solves separate issues. Firstly, prior to signing, choose a hash such that no LABEL's hash collides with any other LABEL's hash, and such that no LABEL's hash collides with any other LABEL. As I think I've shown, this can be done with minimum computational effort. Next you have the problem that a QNAME's hash may still collide with a LABEL's hash (i.e. the server is asked to deny the existence of a LABEL with the same hash as a label that does exist) - in the conventional analyses submitted thusfar you either can't do that, or leave yourself vulnerable to a replay attack (depending on whether you return an error or an NSEC++ record respectively). If you wanted to solve the problem completely (i.e. introduce support for SHA-256 hash collisions!), you can solve the second issue by allowing multiple TYPES of hash in the NSEC++ record, and insist that support of the identity hash (i.e. the output of the hash is the same as the input) is mandatory. This will enable a server worried about denying the existence of colliding QNAMES to return an NSEC++ record using the identity hash (which can never collide, being a bijective function - or apply common sense :-) ) IF AND ONLY IF the QNAME they get ACTUALLY collides with an existing hash for a LABEL that does not correspond to that QNAME. This would allow zone enumerability at as fast a rate as you can produce SHA-256 hashes (i.e. never for most definitions of never, or extremely slowly for those worried about such things). This mechanism has the additional advantage that it relies on no more than support for multiple hash mechanisms which are probably a good thing for the following other mechanism: (a) if one hash turns out to be flawed, we have alternatives (b) people may be interested in different hash lengths to minimize bandwidth or because necessary hash length might vary according to zone size. (c) it allows the concept of deliberately short weak hashes which might "inevitably" produce the odd collision - in case there are those who want to make zone enumeration slightly harder than it is with NSEC, but nowhere near impossible if they are very concerned about zone-size (I have no idea if this constituency exists). This would also let us test collision handling. Requirement 7 - Zone Size ========================= This becomes slightly less difficult to reconcile with zone enumberability requirements in zones which are only partially signed for non-existence (i.e. with requirement 26) as there is no way of telling how many entries there are in an interval where which is signed but does not specify nonexistence (assuming the way this is done is two types of NSEC++ - denying existence in the interval, and being silent as to existence in the interval). An attacker might estimate that the density of labels in a hash interval is constant, and this will be true with a good hash, but quite possibly untrue with the identity hash or NSEC. So what I'm saying is that non-obvious zone size estimates could possibly live with NSEC++ if you were using NSEC++ only for partially signed zones, so I'm not sure the clash marked with (say) 27 is correct. Somewhat trivially, those building zone files at the server end can introduce as many NULL records as they like (and thus cause any estimate to be an overestimate) where the zone does not contain wildcards. It might be possible to allow abutting NSEC++ records (without an intervening real label) to perform the same task without the wildcard problem. Requirement 18 - Purity ======================= "The name space should not be muddied with fake names or data sets." This can mean two things: a) There should not be fake names in the sense of synthesized names, (IE deny existence between name N and name N+1 - the next possible name only) - in which case I think your analysis is correct, or b) The above, but also count hash labels as "fake names or data sets" in which case I think it may be possible to keep these out of the normal name-space, but (i) they'll be in there somewhere, and (ii) it requires mucking around with wildcard queries and QTYPE=ANY queries to exclude NSEC++ records if you are going to do it properly. Alex -- to 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/> From owner-namedroppers@ops.ietf.org Wed Oct 6 15:34:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26709 for <dnsext-archive@lists.ietf.org>; Wed, 6 Oct 2004 15:34:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CFHTd-000AGp-36 for namedroppers-data@psg.com; Wed, 06 Oct 2004 19:29:29 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CFHTc-000AGc-98 for namedroppers@ops.ietf.org; Wed, 06 Oct 2004 19:29:28 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 1415B13951 for <namedroppers@ops.ietf.org>; Wed, 6 Oct 2004 19:29:28 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: Requirments Question In-Reply-To: Message from Ben Laurie <ben@algroup.co.uk> of "Wed, 06 Oct 2004 11:16:45 +0100." <4163C60D.4080003@algroup.co.uk> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 06 Oct 2004 19:29:28 +0000 Message-Id: <20041006192928.1415B13951@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >> 23. Coexistence with NSEC >> >> NSEC++ should be designed to coexist with NSEC. >> >> Contributor: Ed Lewis > > What is this supposed to mean in practice? see <http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00967.html>. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Oct 6 15:50:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28928 for <dnsext-archive@lists.ietf.org>; Wed, 6 Oct 2004 15:50:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CFHlZ-000CtV-Lg for namedroppers-data@psg.com; Wed, 06 Oct 2004 19:48:01 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CFHlY-000CtD-OZ for namedroppers@ops.ietf.org; Wed, 06 Oct 2004 19:48:00 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id B1CD214417A; Wed, 6 Oct 2004 15:47:59 -0400 (EDT) Received: from mercury.arin.net (mercury.arin.net [192.149.252.131]) by smtp2.arin.net (Postfix) with ESMTP id 2F8F614417B; Wed, 6 Oct 2004 15:47:59 -0400 (EDT) Received: from [192.136.136.113] (mercury.arin.net [127.0.0.1]) by mercury.arin.net (Postfix) with ESMTP id 3D6601FE68; Wed, 6 Oct 2004 15:47:59 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a0602043ebd89fb7196a6@[192.136.136.113]> In-Reply-To: <4163C60D.4080003@algroup.co.uk> References: <4163C60D.4080003@algroup.co.uk> Date: Wed, 6 Oct 2004 15:47:57 -0400 To: Ben Laurie <ben@algroup.co.uk> From: Edward Lewis <edlewis@arin.net> Subject: Re: Requirments Question Cc: DNSEXT WG <namedroppers@ops.ietf.org> Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:16 +0100 10/6/04, Ben Laurie wrote: >As has been requested, I am constructing a matrix of compatibility >between requirements in the requirements I-D. > >Whilst doing so, I realise I don't understand one of them: > >23. Coexistence with NSEC > > NSEC++ should be designed to coexist with NSEC. > > Contributor: Ed Lewis > >What is this supposed to mean in practice? E.g., number registries won't get any benefit from NSEC++ beyond what NSEC offers. Therefore, if NSEC++ means more work than NSEC, then NSEC++ is a net loss to the number registries. Ergo - the number registries would be better off with NSEC - so it's important that NSEC and NSEC++ coexist. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to 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/> From owner-namedroppers@ops.ietf.org Wed Oct 6 18:43:53 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26528 for <dnsext-archive@lists.ietf.org>; Wed, 6 Oct 2004 18:43:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CFKS8-0009Xo-EE for namedroppers-data@psg.com; Wed, 06 Oct 2004 22:40:08 +0000 Received: from [129.9.167.81] (helo=odvirpr4.extra.daimlerchrysler.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CFKS7-0009XR-PF for namedroppers@ops.ietf.org; Wed, 06 Oct 2004 22:40:07 +0000 Received: from odnavip4-hme0.oddc.chrysler.com (unknown [53.231.71.96]) by odvirpr4.extra.daimlerchrysler.com (Postfix) with SMTP id 3D6F74CBC for <namedroppers@ops.ietf.org>; Wed, 6 Oct 2004 18:40:07 -0400 (EDT) Received: from wokcdts1.is.chrysler.com ([53.230.102.252]) by odnavip4-hme0.oddc.chrysler.com (SMSSMTP 4.0.0.59) with SMTP id M2004100618400700029 for <namedroppers@ops.ietf.org>; Wed, 06 Oct 2004 18:40:07 -0400 Received: from daimlerchrysler.com (wokcdts1.is.chrysler.com [53.230.102.252]) by wokcdts1.is.chrysler.com (8.11.7+Sun/8.9.1) with ESMTP id i96Me6S03868 for <namedroppers@ops.ietf.org>; Wed, 6 Oct 2004 18:40:07 -0400 (EDT) Message-ID: <41647446.1060706@daimlerchrysler.com> Date: Wed, 06 Oct 2004 18:40:06 -0400 From: Kevin Darcy <kcd@daimlerchrysler.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: progress on wcard draft References: <20041006172842.8704813E42@sa.vix.com> In-Reply-To: <20041006172842.8704813E42@sa.vix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: >>>If the intent is -- do we have rough WG consensus on this? -- to >>>exclude wildcard NSes from functioning as delegations, >>> >>> >>We don't. >> >>Iff the scripture can be interpreted unambiguosly we do not have to >>get consensus on this. We just need consensus on the fact that >>everybody reads the same. You just argued that there are multiple >>interpretations possible. >> >> > >i do not agree with kevin's multiple-interpretation assertion. the >document is unambiguous as written, and the best we ca > I withdraw my assertion that wildcard NSes could be reasonably interpreted under RFC 1034 to be capable of functioning as delegations. Upon re-reading Section 4.3.3, I notice that wildcards "should be in the authoritative data of the zone", so that, in my opinion, is dispositive: delegating NS records are not in the authoritative data of the zone they delegate, therefore wildcard NSes cannot (legally) have a delegating function. Sorry for the confusion. I still maintain, however, that a) It is 4.3.3 that bars this, not the lookup algorithm specification (4.3.2), and b) there is too much disharmony/disjointedness between the "structural" description of "wildcards" in 4.3.3 and the "functional" description of how asterisk-labels work in the context of the lookup algorithm (4.3.2). Hopefully the wcard-clarify draft can improve on this. - Kevin -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Oct 6 20:30:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03407 for <dnsext-archive@lists.ietf.org>; Wed, 6 Oct 2004 20:30:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CFM8c-000Ocb-KY for namedroppers-data@psg.com; Thu, 07 Oct 2004 00:28:06 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CFM8b-000OcH-D9 for namedroppers@ops.ietf.org; Thu, 07 Oct 2004 00:28:05 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i970P2AM005776 for <namedroppers@ops.ietf.org>; Wed, 6 Oct 2004 20:25:02 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAiZaqrl; Wed, 6 Oct 04 20:25:00 -0400 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id i970QTPE010629; Wed, 6 Oct 2004 20:26:29 -0400 (EDT) Date: Wed, 6 Oct 2004 20:26:28 -0400 (EDT) From: Samuel Weiler <weiler@tislabs.com> X-X-Sender: weiler@filbert To: Ben Laurie <ben@algroup.co.uk> cc: DNSEXT WG <namedroppers@ops.ietf.org>, dnsop@lists.uoregon.edu Subject: Re: Key Distribution I-D In-Reply-To: <4163BE8D.6000706@algroup.co.uk> Message-ID: <Pine.GSO.4.55.0410061958060.6628@filbert> References: <4163BE8D.6000706@algroup.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk General thoughts: This is an interesting proposal. It moves the trust anchor distribution out of band and uses X.509 certificate chains for authentication. I have concerns about going out of band (mostly having to do with reachability and scaling -- I'd want to be able to take advantage of DNS's caching infrastructure), but this is probably a very good approach. One of the important questions when I look at a proposal like this is: "how does a resolver determine which zones it should expect to be signed"? Or perhaps "how can a resolver determine whether a given response should be signed"? This proposal seems to do this by precomputation: a resolver (previously) downloaded a list of all Island Roots trusted by its preferred IRCA, recursed, applied some trust relationships, and determined which set of zones should be signed. And unless the resolver has done that prefetching and precomputation, it looks like there's no immediate and efficient way, given a particular query/answer, to determine whether it should be signed. Another question I tend to ask is: what hoops must a signed zone (or IRCA) jump through to change its own keys or to roll back to insecure? It looks like this proposal is very egalitarian: any zone wishing to be a secure entry point also becomes an IRCA, capable of publishing its own list of signed certs. (Have I got that right?) It also looks like there's no way for an IRCA to know what other IRCAs have created and published certs for it, which makes it hard to roll keys or move back to insecure, since the IRCA doesn't necessarily know who to talk to. And there's nothing to help a zone that, while the top of an island of security, really doesn't want its keys to be statically configured in many places. I'm not sure where the tradeoff here should fall. Feel free to tell me if I've gotten something wrong here... Nit: It's not until section 6 that it becomes clear that an HTTP URL (and not, say, an IMAP URL) is being used. Prior to that, it looks like any URL could be used. (gopher? finger? SMTP? LDAP?) Security considerations should acknowledge the presumable dependency of the HTTP lookup on DNS. Yes, the data is secured, but there still _appears_ to be a circular dependence. Might as well proactively avoid that criticism. Meta: Since it appears not to touch the DNS protocols, this proposal looks like it belongs in DNSOP. I know of other proposals that do very similar things but which touch DNS enough to belong in DNSEXT. Perhaps we should declare one home for all of them, whether or not they're mucking with bits on port 53? -- 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Oct 6 21:57:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10343 for <dnsext-archive@lists.ietf.org>; Wed, 6 Oct 2004 21:57:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CFNTK-000All-Ia for namedroppers-data@psg.com; Thu, 07 Oct 2004 01:53:34 +0000 Received: from [203.96.144.16] (helo=gw.zl2tnm.gen.nz) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CFNTJ-000AlS-82 for namedroppers@ops.ietf.org; Thu, 07 Oct 2004 01:53:33 +0000 Received: from toybsd.zl2tnm.gen.nz (toybsd.zl2tnm.gen.nz [192.168.153.14]) by gw.zl2tnm.gen.nz (8.9.3/8.9.3) with ESMTP id OAA29110 for <namedroppers@ops.ietf.org>; Thu, 7 Oct 2004 14:53:31 +1300 Received: from toybsd.zl2tnm.gen.nz (don@localhost [127.0.0.1]) by toybsd.zl2tnm.gen.nz (8.12.9/8.12.9) with ESMTP id i971rVGK045148 for <namedroppers@ops.ietf.org>; Thu, 7 Oct 2004 14:53:31 +1300 (NZDT) (envelope-from don@toybsd.zl2tnm.gen.nz) To: namedroppers@ops.ietf.org Subject: Re: progress on wcard draft In-Reply-To: Your message of "Wed, 06 Oct 2004 10:15:17 EDT." <a0602041ebd89a81b0e12@[192.136.136.113]> From: Don Stokes <don@plugh.daedalus.co.nz> Date: Thu, 07 Oct 2004 14:53:31 +1300 Message-ID: <45147.1097114011@toybsd.zl2tnm.gen.nz> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward Lewis <edlewis@arin.net> wrote: >What is proposed above would make c: > > c) if you find an exact match not a CNAME, you answer from that > otherwise, you look for the wildcard (set) that equals the QTYPE, > OR you look for a wildcard CNAME and you restart the process with > the new search name OR you look for a wildcard NS (set) and > synthesize a referral message. > >Does that sound like a decent categorization of the proposal? Does >that sound reasonable? I think so. Note that c is pretty heavily overloaded -- it actually describes quite a number of possible outcomes. Perhaps it should be subdivided into: i * does not exist ii * CNAME exists iii * NS exists iv * <some other type> exists >BTW - "exact match" in step a means strict DNS label equality, not a >match by wildcard rule. This may not be the right interpretation. >If we take the word "match" in the original part a to mean "by >wildcard rule" then the three parts could be seen as: My interpretation of sec 4.3.2 is that "match" always means by strict equality. Wildcard processing is described explicitly as looking for a "*" label *after* a "match" has failed -- I think that makes it pretty clear that a "match" does not include a wildcard match. Therefore I think it's a pretty big stretch to assume that "match" could imply wildcard matches as well as strict ones. Using the phrase "exact match" would help avoid incorrect interpretations, but either way, I don't see any ambiguity in the existing text. >Then again, b uses "match" too, so maybe we could read the three parts as: > > a) if there is an exact or wildcard match with a CNAME, restart the > process with the new search name. > > b) if there is an exact or wildcard match with an NS, you issue a > referral. (The one exception is that the sought name (SNAME) is > not the zone's SOA owner name/apex.) > > c) otherwise you answer from the exact or wildcard matching name. > >In a way - re-interpreting "match" makes the three parts balance >better - we no longer have a and b with specific rules and c having >multiple parts. I think that will get ugly. What constitutes a "wildcard match" is well defined in 3c, and trying to redefine the word "match" gets messy, especially since 3a divides the matching process up into matching the QNAME, and then matching the QTYPE. 3c deals with no QNAME match, but does look for a QTYPE match, while 3b matches the node only. Thus I think simply adding the case for * NS as a referral in 3c will be much tidier. -- don -- to 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/> From owner-namedroppers@ops.ietf.org Thu Oct 7 08:02:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08010 for <dnsext-archive@lists.ietf.org>; Thu, 7 Oct 2004 08:02:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CFWsU-000K8x-Os for namedroppers-data@psg.com; Thu, 07 Oct 2004 11:56:10 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CFWsR-000K7x-F2 for namedroppers@ops.ietf.org; Thu, 07 Oct 2004 11:56:07 +0000 Received: from [193.133.15.218] (ben-xp2.ben.algroup.co.uk [193.133.15.218]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 5636A107C21; Thu, 7 Oct 2004 11:56:06 +0000 (GMT) Message-ID: <41652ED9.6080101@algroup.co.uk> Date: Thu, 07 Oct 2004 12:56:09 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Edward Lewis <edlewis@arin.net> Cc: DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: Requirments Question References: <4163C60D.4080003@algroup.co.uk> <a0602043ebd89fb7196a6@[192.136.136.113]> In-Reply-To: <a0602043ebd89fb7196a6@[192.136.136.113]> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward Lewis wrote: > At 11:16 +0100 10/6/04, Ben Laurie wrote: > >> As has been requested, I am constructing a matrix of compatibility >> between requirements in the requirements I-D. >> >> Whilst doing so, I realise I don't understand one of them: >> >> 23. Coexistence with NSEC >> >> NSEC++ should be designed to coexist with NSEC. >> >> Contributor: Ed Lewis >> >> What is this supposed to mean in practice? > > > E.g., number registries won't get any benefit from NSEC++ beyond what > NSEC offers. Therefore, if NSEC++ means more work than NSEC, then > NSEC++ is a net loss to the number registries. Ergo - the number > registries would be better off with NSEC - so it's important that NSEC > and NSEC++ coexist. Then this is actually the same as: 24. Coexistence with NSEC II NSEC++ should be optional, allowing NSEC to be used instead. yes? Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to 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/> From owner-namedroppers@ops.ietf.org Thu Oct 7 08:45:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11857 for <dnsext-archive@lists.ietf.org>; Thu, 7 Oct 2004 08:45:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CFXb2-0001Cx-61 for namedroppers-data@psg.com; Thu, 07 Oct 2004 12:42:12 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CFXak-0001Ad-9P for namedroppers@ops.ietf.org; Thu, 07 Oct 2004 12:41:55 +0000 Received: from [193.133.15.218] (ben-xp2.ben.algroup.co.uk [193.133.15.218]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 66EA4107C21; Thu, 7 Oct 2004 12:41:53 +0000 (GMT) Message-ID: <41653994.6030801@algroup.co.uk> Date: Thu, 07 Oct 2004 13:41:56 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Bligh <alex@alex.org.uk> Cc: DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: Requirements Matrix References: <4163ECA7.8050404@algroup.co.uk> <55A312B840C3132BF37F4AE8@[192.168.100.25]> In-Reply-To: <55A312B840C3132BF37F4AE8@[192.168.100.25]> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Alex Bligh wrote: > --On 06 October 2004 14:01 +0100 Ben Laurie <ben@algroup.co.uk> wrote: >> I have uploaded my first cut at a compatibility matrix for NSEC++ >> requirements. It is available as both a spreadsheet and a web page: >> >> http://www.links.org/dnssec/requirements-matrix.htm >> http://www.links.org/dnssec/requirements-matrix.xls >> >> I'm sure I've got some of them wrong, so please take a look. > > > OK some comments mainly on the red & yellow areas: > > [ I may have misunderstood (27) but I took it to mean "I can sign some > intervals as non-existing without revealing ANYTHING about other names - > not only what they are, but not (necessarily) whether they exist or not" - > IE a combination of non-enumerability and support for intervals which did > not deny existence at all (a la 26). ] Good point. Taken literally, that would seem a correct interpretation. > Inconsistencies within the Matrix > ================================= > > I did a matrix transpose and found out what happened: > > 17 is marked as incompatible with 7, but 7 is marked as compatible with > 17. I don't think they are incompatible. I think they are, in the sense that no proposal that I've seen satisfies both (hmmm, possibly Bellovin's Bloom filters do, I'm not sure), and I can't think of one that does. Note that synthesized "point" denials probably do, but they are currently illegal. I also had marked 17/9 as incompatible, in error. > 7 is marked compatible with 10, but 10 is marked incompatible with 7. > I don't think they are incompatible. Again, I think they are. > 9 is marked compatible with 10, but 10 is marked incompatible with 9. > I don't think they are per-se incompatible but I'm not sure. Again, in the sense that no proposal reconciles them, they are. > Compatibility > ============= > > Requirements 20 & 21 which say: "NSEC++ should not introduce changes > incompatible with NSEC." & "NSEC++ should differ from NSEC in a way that is > transparent to the resolver or validator." are marked as incompatible with > (in essence) the zone non-enumeration requirements and the 27 (called > protocol design but essentially about partially signed zones or at least > zones only partially signed for non-existence which I think is the same > thing or very nearly). I think there is a possible interpretation problem > here, to do with mandatory and option support. > > It is possible to read the zone enumeration requirements as mandatorily > applying to all zones, AND to read "incompatible" (in 26) as meaning "if > any resolver implementing DNSSECbis NSEC only - not NSEC++ - cannot > interpret the responses then it's failed the test" THEN clearly we have a > problem. If that's what the red square means, I understand it, but it's not > particularly useful. It is what it means, IMO. > However, I do not think it is necessarily impossible to have (for instance) > * NSEC / NSEC++ / unsigned zones as alternatives on the server side * > NSEC++ designed such that it looks like an unsigned zone to resolvers > supporting NSEC but not NSEC++ If that's what you meant by the red square > Ben, I'd ask why. It is not what I meant. The essence here is that these points are meant to convey the idea that it would be nice if we could do NSEC++ without having to change the world. I do not believe that is (currently) possible. > It /might/ be possible (in essence through permitting responses currently > prohibited by DNSSEC-bis in a manner which cannot harm any compliant > DNSSEC-bis resolver) to have a zone constructed for NSEC++ signing still > return authenticated records other than NSEC records for resolvers > supporting DNSSEC-bis (& NSEC) but not NSEC++. I am not saying it *is* > possible, I just don't think anyone's conclusively demonstrated that it's > not. This point I don't understand. I have a version of BIND running that does exactly this - i.e. returns NSEC2 records. An "old" resolver will not understand the responses, and so will treat NXDOMAIN/NODATA as unauthenticated denials. > Requirement 19 - Replay Attacks > =============================== > > I am going to stick my neck out and say I think the problem of replay > attacks IS soluble even in the theoretical case less likely than meteor > destroying the earth (etc.). I think I've said this before and haven't been > contradicted. You can solve this by two measures, each of which solves > separate issues. Firstly, prior to signing, choose a hash such that no > LABEL's hash collides with any other LABEL's hash, and such that no LABEL's > hash collides with any other LABEL. As I think I've shown, this can be done > with minimum computational effort. Next you have the problem that a QNAME's > hash may still collide with a LABEL's hash (i.e. the server is asked to > deny the existence of a LABEL with the same hash as a label that does > exist) - in the conventional analyses submitted thusfar you either can't do > that, or leave yourself vulnerable to a replay attack (depending on whether > you return an error or an NSEC++ record respectively). If you wanted to > solve the problem completely (i.e. introduce support for SHA-256 hash > collisions!), you can solve the second issue by allowing multiple TYPES of > hash in the NSEC++ record, and insist that support of the identity hash > (i.e. the output of the hash is the same as the input) is mandatory. This > will enable a server worried about denying the existence of colliding > QNAMES to return an NSEC++ record using the identity hash (which can never > collide, being a bijective function - or apply common sense :-) ) IF AND > ONLY IF the QNAME they get ACTUALLY collides with an existing hash for a > LABEL that does not correspond to that QNAME. This would allow zone > enumerability at as fast a rate as you can produce SHA-256 hashes (i.e. > never for most definitions of never, or extremely slowly for those worried > about such things). > > This mechanism has the additional advantage that it relies on no more > than support for multiple hash mechanisms which are probably a good > thing for the following other mechanism: > (a) if one hash turns out to be flawed, we have alternatives > (b) people may be interested in different hash lengths to minimize > bandwidth or because necessary hash length might vary > according to zone size. > (c) it allows the concept of deliberately short weak hashes which > might "inevitably" produce the odd collision - in case there are > those who want to make zone enumeration slightly harder than > it is with NSEC, but nowhere near impossible if they are very > concerned about zone-size (I have no idea if this constituency > exists). This would also let us test collision handling. I think you are missing an essential point. The server does not get to choose what is returned in a replay attack, the attacker does. So, the logical consequence of your argument is that the server would always have to use the "identity" hash (since it cannot know what the QNAME is), i.e. NSEC, and that makes it incompatible, as stated. > Requirement 7 - Zone Size > ========================= > > This becomes slightly less difficult to reconcile with zone enumberability > requirements in zones which are only partially signed for non-existence > (i.e. with requirement 26) as there is no way of telling how many > entries there are in an interval where which is signed but does > not specify nonexistence (assuming the way this is done is two types > of NSEC++ - denying existence in the interval, and being silent > as to existence in the interval). An attacker might estimate that the > density of labels in a hash interval is constant, and this will be > true with a good hash, but quite possibly untrue with the identity > hash or NSEC. So what I'm saying is that non-obvious zone size estimates > could possibly live with NSEC++ if you were using NSEC++ only for > partially signed zones, so I'm not sure the clash marked with (say) 27 > is correct. Then the size of the signed zone would be apparent, which I believe is in the spirit of the requirement. > Somewhat trivially, those building zone files at the server end can > introduce as many NULL records as they like (and thus cause any estimate to > be an overestimate) where the zone does not contain wildcards. It might be > possible to allow abutting NSEC++ records (without an intervening real > label) to perform the same task without the wildcard problem. This would be incompatible with 18 :-) > Requirement 18 - Purity > ======================= > > "The name space should not be muddied with fake names or data sets." > > This can mean two things: > a) There should not be fake names in the sense of synthesized names, > (IE deny existence between name N and name N+1 - the next possible > name only) - in which case I think your analysis is correct, or > b) The above, but also count hash labels as "fake names or data sets" > in which case I think it may be possible to keep these out of > the normal name-space, but (i) they'll be in there somewhere, and > (ii) it requires mucking around with wildcard queries and QTYPE=ANY > queries to exclude NSEC++ records if you are going to do it properly. Indeed, if one is prepared to change the rules for searching, then one can exclude hashes from the namespace, and this fixes the problem. "Not changing the search algorithm" was not included as a requirement, but I have heard the sentiment expressed, and so it probably should have been. Another issue is that sometimes incompatibilities only exist when more than two requirements are grouped, this being a good example - "Purity of namespace" and "don't change searches" are incompatible with "zone enumeration", but only when paired (modulo meteor-strike probabilities). I can fix this by introducing new lines for such pairings, I guess. But only ones specifically requested, I don't think a 650x650 matrix is what people want! Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to 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/> From owner-namedroppers@ops.ietf.org Thu Oct 7 09:39:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15872 for <dnsext-archive@lists.ietf.org>; Thu, 7 Oct 2004 09:39:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CFYS4-0009pS-Ai for namedroppers-data@psg.com; Thu, 07 Oct 2004 13:37:00 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CFYS3-0009pC-LO for namedroppers@ops.ietf.org; Thu, 07 Oct 2004 13:36:59 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id C49BCC2DA5; Thu, 7 Oct 2004 14:36:58 +0100 (BST) Date: Thu, 07 Oct 2004 14:36:45 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: Edward Lewis <edlewis@arin.net>, Ben Laurie <ben@algroup.co.uk> Cc: DNSEXT WG <namedroppers@ops.ietf.org>, Alex Bligh <alex@alex.org.uk> Subject: Re: Requirments Question Message-ID: <55E556700DFF1A1115DFD80D@[192.168.100.25]> In-Reply-To: <a0602043ebd89fb7196a6@[192.136.136.113]> References: <4163C60D.4080003@algroup.co.uk> <a0602043ebd89fb7196a6@[192.136.136.113]> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 06 October 2004 15:47 -0400 Edward Lewis <edlewis@arin.net> wrote: > so it's important that NSEC and NSEC++ coexist. IE that servers should be permitted to use either scheme, and resolvers which are NSEC++ compatible should also support NSEC. Alex -- to 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/> From owner-namedroppers@ops.ietf.org Thu Oct 7 10:03:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17147 for <dnsext-archive@lists.ietf.org>; Thu, 7 Oct 2004 10:03:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CFYpP-000Ds9-SV for namedroppers-data@psg.com; Thu, 07 Oct 2004 14:01:07 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CFYpL-000Dr3-RP for namedroppers@ops.ietf.org; Thu, 07 Oct 2004 14:01:04 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 9CDF2C2DA5; Thu, 7 Oct 2004 15:01:00 +0100 (BST) Date: Thu, 07 Oct 2004 15:00:49 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: Ben Laurie <ben@algroup.co.uk> Cc: DNSEXT WG <namedroppers@ops.ietf.org>, Alex Bligh <alex@alex.org.uk> Subject: Re: Requirements Matrix Message-ID: <6F936124E48E2E71F58327C0@[192.168.100.25]> In-Reply-To: <41653994.6030801@algroup.co.uk> References: <4163ECA7.8050404@algroup.co.uk> <55A312B840C3132BF37F4AE8@[192.168.100.25]> <41653994.6030801@algroup.co.uk> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ben, >> I did a matrix transpose and found out what happened: OK you disagreed with my three guesses as to what the correct states were here, but that still means you have to fix the transpose entry. EG if 17 is indeed incompatible with 7, 7 should be marked as incompatible with 17 (it isn't), ditto for 7/10 and 9/10 (i.e. they should be resolved the same way whichevever is on the H&V axes). On the substantive points: > Again, in the sense that no proposal reconciles them, they are. OK I had read "No proposal exists to reconcile these two, nor is it obvious they can be" to mean "No proposal exists to reconcile these two, nor is it obvious that any route exists unknown or otherwise to reconcile them" (i.e. that whilst we haven't proved they are incompatible, it seems pretty unlikely they will be). Perhaps I misread. It might be clearer if you said "Reconciliation is non-obvious and currently unknown, but may be possible" - i.e. you mean "these are work items" not "don't bother to dig here". >> It is possible to read the zone enumeration requirements as mandatorily >> applying to all zones, AND to read "incompatible" (in 26) as meaning "if >> any resolver implementing DNSSECbis NSEC only - not NSEC++ - cannot >> interpret the responses then it's failed the test" THEN clearly we have a >> problem. If that's what the red square means, I understand it, but it's >> not particularly useful. > > It is what it means, IMO. OK - from my "zone enumeration requirement" (and I thought from Nominet's) I did NOT mean "no zones should be enumerable", I meant "the server operator should have the option of preventing given zones being enumerable). This then is not incompatible with (say) 20 (NSEC compatibility) as it can be achieved by making use of NSEC++ optional, and mandating that resolvers that support NSEC++ also support NSEC. > The essence here is that these points are meant to convey the idea that > it would be nice if we could do NSEC++ without having to change the > world. I do not believe that is (currently) possible. OK, that's "compatibility with NSEC only resolvers" not "compatibility with NSEC only servers". >> It /might/ be possible (in essence through permitting responses currently >> prohibited by DNSSEC-bis in a manner which cannot harm any compliant >> DNSSEC-bis resolver) to have a zone constructed for NSEC++ signing still >> return authenticated records other than NSEC records for resolvers >> supporting DNSSEC-bis (& NSEC) but not NSEC++. I am not saying it *is* >> possible, I just don't think anyone's conclusively demonstrated that it's >> not. > > This point I don't understand. I have a version of BIND running that does > exactly this - i.e. returns NSEC2 records. An "old" resolver will not > understand the responses, and so will treat NXDOMAIN/NODATA as > unauthenticated denials. That's because of how you implemented it! In a handwaving way (deliberately to avoid details :-) ) if it were the case that an NSEC++ supporting resolver made queries in a different way to servers in such a way as to flag their support for NSEC++, then an NSEC++ supporting server could return a) NSEC++ records for NSEC++ supporting resolverd b) for non-supporting resolvers, either: i) NSEC records (if people don't care about zone enumeration) or ii) pretend to be a non-DNSSEC-bis server (if people do care about zone enumeration). What I'm saying /might/ be possible (under b(ii)) is to pretend to have a split personality - as a dreadful hack, for instance, return the correct records for records that exist, and return SERVFAIL instead of NSEC where things don't exist (yuck!). As an NSEC (not NSEC++) resolver has to cope with SERVFAIL anyway, it's not going to break any compliant resolver. I know SERVFAIL isn't the way to do it, but what I'm saying is I don't think it's been shown there is NO way to do b(ii). > I think you are missing an essential point. The server does not get to > choose what is returned in a replay attack, the attacker does. So, the > logical consequence of your argument is that the server would always have > to use the "identity" hash (since it cannot know what the QNAME is), i.e. > NSEC, and that makes it incompatible, as stated. Why can the server not know what the QNAME is, if you so design the protocol? You are assuming the server is ONLY passed the hashed value, and not (hashedvalue,QNAME). I am not making that assumption. That may be undesirable for other reasons (granted), but my point is that solving the problem is not impossible. >> So >> what I'm saying is that non-obvious zone size estimates could possibly >> live with NSEC++ if you were using NSEC++ only for partially signed >> zones, so I'm not sure the clash marked with (say) 27 is correct. > > Then the size of the signed zone would be apparent, which I believe is in > the spirit of the requirement. I'm missing something: why would the size of the zone be apparent (or rather any more apparent) if you were using NSEC++ only to implement partially signed zones (i.e. used identity hashes)? You get no more information than out of NSEC records - in fact you get rather less as the zone is only partially signed. You assertion is only correct if the ONLY usage of NSEC++ is non-enumerability, which the reqs doc clearly says it isn't! Alex -- to 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/> From owner-namedroppers@ops.ietf.org Thu Oct 7 12:40:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03289 for <dnsext-archive@lists.ietf.org>; Thu, 7 Oct 2004 12:40:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CFbG1-000EqW-Rd for namedroppers-data@psg.com; Thu, 07 Oct 2004 16:36:45 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CFbFy-000Epu-3r for namedroppers@ops.ietf.org; Thu, 07 Oct 2004 16:36:42 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id B0A081441C1; Thu, 7 Oct 2004 12:36:40 -0400 (EDT) Received: from mercury.arin.net (mercury.arin.net [192.149.252.131]) by smtp2.arin.net (Postfix) with ESMTP id B595A144095; Thu, 7 Oct 2004 12:36:39 -0400 (EDT) Received: from [192.136.136.113] (mercury.arin.net [127.0.0.1]) by mercury.arin.net (Postfix) with ESMTP id 75BCA1FE6A; Thu, 7 Oct 2004 12:36:39 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a0602040fbd8b1f93f565@[192.136.136.113]> Date: Thu, 7 Oct 2004 12:36:41 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis <edlewis@arin.net> Subject: wcard draft Cc: edlewis@arin.net, edlewisjr@cox.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Once again I'm promising a new version. ;) The next version is going to be quite different from past versions because of the discussions that have gone on. I'm going to try to remove the "requirements" language to enforce the view that this is a clarification and not a new definition. If folks think that's not a good idea, the requirements language can be put back in. The reason I'm going to the lengths I am in saying this is that I also need to let y'all know I need drop off namedroppers for a weekend or so. (And my current account will go away Friday.) If the WG members can hold off comments until after the weekend, that would be really convenient for me - I can check the archives, but it's not the same. It's a weekend anyway. ;) I'm sure y'all will hear from me when I'm back on-list. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to 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/> From owner-namedroppers@ops.ietf.org Thu Oct 7 16:07:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18792 for <dnsext-archive@lists.ietf.org>; Thu, 7 Oct 2004 16:07:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CFeTG-000OK9-62 for namedroppers-data@psg.com; Thu, 07 Oct 2004 20:02:38 +0000 Received: from [193.0.3.26] (helo=ernie.secret-wg.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CFeTF-000OJp-9I for namedroppers@ops.ietf.org; Thu, 07 Oct 2004 20:02:37 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by ernie.secret-wg.org (Postfix) with ESMTP id 78C294AE493; Thu, 7 Oct 2004 22:02:51 +0200 (CEST) Message-ID: <4165A0EB.4060504@ripe.net> Date: Thu, 07 Oct 2004 22:02:51 +0200 From: "Olaf M. Kolkman" <olaf@ripe.net> User-Agent: Mozilla Thunderbird 0.7.1 (Macintosh/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Bligh <alex@alex.org.uk> Cc: Edward Lewis <edlewis@arin.net>, Ben Laurie <ben@algroup.co.uk>, DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: Requirments Question References: <4163C60D.4080003@algroup.co.uk> <a0602043ebd89fb7196a6@[192.136.136.113]> <55E556700DFF1A1115DFD80D@[192.168.100.25]> In-Reply-To: <55E556700DFF1A1115DFD80D@[192.168.100.25]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Alex Bligh wrote: > > > --On 06 October 2004 15:47 -0400 Edward Lewis <edlewis@arin.net> wrote: > >> so it's important that NSEC and NSEC++ coexist. > > > IE that servers should be permitted to use either scheme, and resolvers > which are NSEC++ compatible should also support NSEC. to be even more verbose... And a server that only support NSEC should tread NSEC++ as "non-secured data" and not choke. Besides it should be possible to go from a NSEC signed parent (the root that has no zone enumerations problems) to a NSEC++ child for both a NSEC only and an NSEC and NSEC++ aware validating resolver. The NSEC only aware resolver should see this as "leaving" the secure island (the child being verifyably unsecure). While for the NSEC + '++' resolver you'd go from one secure zone to another. There is no requirement (except if there is a requirement to migrate from one scheme to another without being "unsecure") to have both NSEC and NSEC++ in the same zone. (Where I read "NSEC++" as a mechanism to precompute and sign non-existence statements, possibly hashed based :-) ) --Olaf namedropper. -- to 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/> From owner-namedroppers@ops.ietf.org Fri Oct 8 12:15:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08194 for <dnsext-archive@lists.ietf.org>; Fri, 8 Oct 2004 12:15:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CFxJ7-000BZx-PB for namedroppers-data@psg.com; Fri, 08 Oct 2004 16:09:25 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CFxJ6-000BZS-B6 for namedroppers@ops.ietf.org; Fri, 08 Oct 2004 16:09:25 +0000 Received: from [193.133.15.218] (ben-xp2.ben.algroup.co.uk [193.133.15.218]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 4D002107C22; Fri, 8 Oct 2004 16:09:23 +0000 (GMT) Message-ID: <4166BBB8.7090309@algroup.co.uk> Date: Fri, 08 Oct 2004 17:09:28 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Samuel Weiler <weiler@tislabs.com> Cc: DNSEXT WG <namedroppers@ops.ietf.org>, dnsop@lists.uoregon.edu Subject: Re: Key Distribution I-D References: <4163BE8D.6000706@algroup.co.uk> <Pine.GSO.4.55.0410061958060.6628@filbert> In-Reply-To: <Pine.GSO.4.55.0410061958060.6628@filbert> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Samuel Weiler wrote: > General thoughts: > > This is an interesting proposal. It moves the trust anchor > distribution out of band and uses X.509 certificate chains for > authentication. I have concerns about going out of band (mostly > having to do with reachability and scaling -- I'd want to be able to > take advantage of DNS's caching infrastructure), but this is probably > a very good approach. > > One of the important questions when I look at a proposal like this is: > "how does a resolver determine which zones it should expect to be > signed"? Or perhaps "how can a resolver determine whether a given > response should be signed"? > > This proposal seems to do this by precomputation: a resolver > (previously) downloaded a list of all Island Roots trusted by its > preferred IRCA, recursed, applied some trust relationships, and > determined which set of zones should be signed. And unless the > resolver has done that prefetching and precomputation, it looks like > there's no immediate and efficient way, given a particular > query/answer, to determine whether it should be signed. Correct, this was intended as a bootstrapping protocol, not a way to handle arbitrary queries. So, the answer would be "it should be signed if you have trusted keys for the zone as a result of using this mechanism". > Another question I tend to ask is: what hoops must a signed zone (or > IRCA) jump through to change its own keys or to roll back to insecure? > It looks like this proposal is very egalitarian: any zone wishing to > be a secure entry point also becomes an IRCA, capable of publishing > its own list of signed certs. (Have I got that right?) Yes. Of course, it is up to the user to choose which IRCAs they trust. > It also looks like there's no way for an IRCA to know what other IRCAs have created > and published certs for it, which makes it hard to roll keys or move > back to insecure, since the IRCA doesn't necessarily know who to talk > to. And there's nothing to help a zone that, while the top of an > island of security, really doesn't want its keys to be statically > configured in many places. I'm not sure where the tradeoff here > should fall. Well, first off, the process for signing keys should be such that any IRCA that has signed your keys that you don't know about is one that nobody should trust. So, I'd tend to discount that possibility. However, once a certificate for a key has been generated, its certainly true that you can't get it back again. This is why we have CRLs and OCSP. I haven't addressed those yet, but I certainly have to. This is also why I suggest you use a key that you apply a very high level of security to for the IRCA certificates. > Feel free to tell me if I've gotten something wrong here... > > Nit: > > It's not until section 6 that it becomes clear that an HTTP URL (and > not, say, an IMAP URL) is being used. Prior to that, it looks like > any URL could be used. (gopher? finger? SMTP? LDAP?) Any URL that gets you data should work fine, I'm not really depending on HTTP. LDAP was even designed for the purpose! > Security considerations should acknowledge the presumable dependency > of the HTTP lookup on DNS. Yes, the data is secured, but there still > _appears_ to be a circular dependence. Might as well proactively > avoid that criticism. I did address that in the section "Security Non-issues", didn't I? > Meta: > > Since it appears not to touch the DNS protocols, this proposal looks > like it belongs in DNSOP. I know of other proposals that do very > similar things but which touch DNS enough to belong in DNSEXT. > Perhaps we should declare one home for all of them, whether or not > they're mucking with bits on port 53? It doesn't make sense to me to have them in different homes, that's for sure. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to 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/> From owner-namedroppers@ops.ietf.org Sun Oct 10 05:14:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25569 for <dnsext-archive@lists.ietf.org>; Sun, 10 Oct 2004 05:14:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CGZgf-000FGR-Bj for namedroppers-data@psg.com; Sun, 10 Oct 2004 09:08:17 +0000 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CGZge-000FG3-GP for namedroppers@ops.ietf.org; Sun, 10 Oct 2004 09:08:16 +0000 Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:250:daff:fe82:1c39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id D3BA727E for <namedroppers@ops.ietf.org>; Sun, 10 Oct 2004 05:08:15 -0400 (EDT) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 2C35C42B5 for <namedroppers@ops.ietf.org>; Sun, 10 Oct 2004 05:08:15 -0400 (EDT) Date: Sun, 10 Oct 2004 05:08:15 -0400 From: Rob Austein <sra@isc.org> To: namedroppers@ops.ietf.org Subject: New versions of DNSSECbis drafts posted MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20041010090815.2C35C42B5@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk New versions of the DNSSECbis drafts have just been sent off to the Internet-Drafts coordinator. Copies (and htmlwdiff output) are also available on the web at: http://www.hactrn.net/ietf/dns/dnssec-editors/ These versions incorporate minor changes in response to review by the IESG. As far as the editors know, we're done, and these drafts are now ready to be tossed over the wall to the RFC Editor. As always, please send minor comments to dnssec-editors@east.isi.edu, substantive issues to namedroppers. --Rob (on behalf of your friendly neighborhood DNSSEC 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sun Oct 10 17:32:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15631 for <dnsext-archive@lists.ietf.org>; Sun, 10 Oct 2004 17:32:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CGlE5-000AYf-9k for namedroppers-data@psg.com; Sun, 10 Oct 2004 21:27:33 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CGlE4-000AYS-Df for namedroppers@ops.ietf.org; Sun, 10 Oct 2004 21:27:32 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id i9ALR71j062489 for <namedroppers@ops.ietf.org>; Sun, 10 Oct 2004 17:27:07 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.1.2.0.2.20041010170952.02eeb338@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 10 Oct 2004 17:27:07 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> Subject: Re: New versions of DNSSECbis drafts posted In-Reply-To: <20041010090815.2C35C42B5@thrintun.hactrn.net> References: <20041010090815.2C35C42B5@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.44 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 05:08 10/10/2004, Rob Austein wrote: >New versions of the DNSSECbis drafts have just been sent off to the >Internet-Drafts coordinator. Copies (and htmlwdiff output) are also >available on the web at: > > http://www.hactrn.net/ietf/dns/dnssec-editors/ > >These versions incorporate minor changes in response to review by the >IESG. > >As far as the editors know, we're done, and these drafts are now ready >to be tossed over the wall to the RFC Editor. We the chairs want to thank the editors and our AD for quick and through work in resolving issues identified during the IETF Last call and IESG review. The changes in the documents are minor here are the highlights: All documents spell out names of DNSSEC RR types at least one now, as well as use the Type mnemonic. Intro contains two new definitions that where used but have not been formally defined anywhere: "Zone Apex" and "Authorative RRset". Please check out these definitions and send comments to namedroppers if there is mistake in the definitions. Intro in section 6 rewords and clarifies issues related to inability to get DNSSEC RR types in certain cases. Protocol Section 3 has modified text related to IPv6 fragmentation issue. Records clarifies that type code numbers base (decimal). Records and Protocol have small text changes related to authentication actions that better express intent. >As always, please send minor comments to dnssec-editors@east.isi.edu, >substantive issues to namedroppers. If we hear nothing by Wed editors will hand documents over to RFC-editor. Note: small changes can be handled during the RFC editing process so keep them coming to dnssec-editors. >--Rob (on behalf of your friendly neighborhood DNSSEC editors) thanks Olafur (on behalf of your DNSEXT chairs) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Oct 11 11:09:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13031 for <dnsext-archive@lists.ietf.org>; Mon, 11 Oct 2004 11:09:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CH1i9-000PgJ-0e for namedroppers-data@psg.com; Mon, 11 Oct 2004 15:03:41 +0000 Received: from [131.254.254.26] (helo=smtp.irisa.fr) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CH1i7-000Pg1-Pj for namedroppers@ops.ietf.org; Mon, 11 Oct 2004 15:03:39 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by localhost.irisa.fr (Postfix) with ESMTP id 86724FAAC; Mon, 11 Oct 2004 17:03:38 +0200 (CEST) Received: from smtp.irisa.fr ([131.254.254.26]) by localhost (meli.irisa.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02897-02; Mon, 11 Oct 2004 17:03:38 +0200 (CEST) Received: from [131.254.70.6] (moulis.irisa.fr [131.254.70.6]) by smtp.irisa.fr (Postfix) with ESMTP id 0B8F9FAC5; Mon, 11 Oct 2004 17:03:38 +0200 (CEST) Message-ID: <416AA0CA.5050008@irisa.fr> Date: Mon, 11 Oct 2004 17:03:38 +0200 From: David Fort <david.fort@irisa.fr> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: fr-fr, fr, en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Cc: dnsop@lists.uoregon.edu Subject: [announce] libsresolv Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at irisa.fr X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit The IDsA project is proud to announce the first release of 'libsresolv'. 'libsresolv' is a DNSSEC resolver/validator library built with the BIND/libbind toolkit. It comes as patch over the BIND 9.3 sources. More infos can be found here: http://idsa.irisa.fr/index.php?page=libsresolv&lang=en -- Fort David, Projet IDsA IRISA-INRIA, Campus de Beaulieu, 35042 Rennes cedex, France Tél: +33 (0) 2 99 84 71 33 -- to 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/> From owner-namedroppers@ops.ietf.org Mon Oct 11 15:42:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09253 for <dnsext-archive@lists.ietf.org>; Mon, 11 Oct 2004 15:41:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CH60D-0007nv-1v for namedroppers-data@psg.com; Mon, 11 Oct 2004 19:38:37 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CH60C-0007ng-0F for namedroppers@ops.ietf.org; Mon, 11 Oct 2004 19:38:36 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08928; Mon, 11 Oct 2004 15:38:32 -0400 (EDT) Message-Id: <200410111938.PAA08928@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-records-11.txt Date: Mon, 11 Oct 2004 15:38:32 -0400 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.64 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 the DNS Security Extensions Author(s) : R. Arends, et al. Filename : draft-ietf-dnsext-dnssec-records-11.txt Pages : 33 Date : 2004-10-11 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 existence (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-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-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-dnssec-records-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: <2004-10-11155153.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-records-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-records-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-11155153.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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Oct 11 15:42:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09311 for <dnsext-archive@lists.ietf.org>; Mon, 11 Oct 2004 15:42:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CH603-0007mw-EP for namedroppers-data@psg.com; Mon, 11 Oct 2004 19:38:27 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CH602-0007ma-Ck for namedroppers@ops.ietf.org; Mon, 11 Oct 2004 19:38:26 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08904; Mon, 11 Oct 2004 15:38:23 -0400 (EDT) Message-Id: <200410111938.PAA08904@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-intro-13.txt Date: Mon, 11 Oct 2004 15:38:23 -0400 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.64 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, et al. Filename : draft-ietf-dnsext-dnssec-intro-13.txt Pages : 26 Date : 2004-10-11 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-13.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-13.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-intro-13.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-11155141.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-intro-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-intro-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-11155141.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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Oct 11 15:43:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09388 for <dnsext-archive@lists.ietf.org>; Mon, 11 Oct 2004 15:43:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CH607-0007nR-IH for namedroppers-data@psg.com; Mon, 11 Oct 2004 19:38:31 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CH606-0007nC-Bu for namedroppers@ops.ietf.org; Mon, 11 Oct 2004 19:38: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 PAA08921; Mon, 11 Oct 2004 15:38:28 -0400 (EDT) Message-Id: <200410111938.PAA08921@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-protocol-09.txt Date: Mon, 11 Oct 2004 15:38:28 -0400 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Protocol Modifications for the DNS Security Extensions Author(s) : R. Arends, et al. Filename : draft-ietf-dnsext-dnssec-protocol-09.txt Pages : 58 Date : 2004-10-11 This document is part of a family of documents which describe 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-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-protocol-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-11155147.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-protocol-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-protocol-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-11155147.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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Oct 11 15:44:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09449 for <dnsext-archive@lists.ietf.org>; Mon, 11 Oct 2004 15:44:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CH5zz-0007mN-VW for namedroppers-data@psg.com; Mon, 11 Oct 2004 19:38:23 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CH5zy-0007lo-Ji for namedroppers@ops.ietf.org; Mon, 11 Oct 2004 19:38:22 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08897; Mon, 11 Oct 2004 15:38:20 -0400 (EDT) Message-Id: <200410111938.PAA08897@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-wcard-clarify-03.txt Date: Mon, 11 Oct 2004 15:38:19 -0400 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Clarifying the Role of Wild Card Domains in the Domain Name System Author(s) : E. Lewis Filename : draft-ietf-dnsext-wcard-clarify-03.txt Pages : 18 Date : 2004-10-11 The definition of wild cards is recast from the original in RFC 1034, in words that are more specific and in line with RFC 2119. This document is meant to supplement the definition in RFC 1034 and to alter neither the spirit nor intent of that definition. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-wcard-clarify-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-wcard-clarify-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-wcard-clarify-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: <2004-10-11155131.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-wcard-clarify-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-wcard-clarify-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-11155131.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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Oct 11 21:47:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19618 for <dnsext-archive@lists.ietf.org>; Mon, 11 Oct 2004 21:47:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CHBi7-000MOQ-U4 for namedroppers-data@psg.com; Tue, 12 Oct 2004 01:44:19 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CHBi6-000MO3-S1 for namedroppers@ops.ietf.org; Tue, 12 Oct 2004 01:44:19 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id i9C1hoEV067726 for <namedroppers@ops.ietf.org>; Mon, 11 Oct 2004 21:43:50 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.1.2.0.2.20041011160917.070d8ec0@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 11 Oct 2004 21:43:52 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> Subject: IETF-61 DNSEXT agenda items Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.44 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Please send them into to me. Agenda items we know about are: DNS Wildcard clarification document Negative Answer Requirements Key Management New Charter send in other items. Olaf & 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Oct 12 04:09:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27891 for <dnsext-archive@lists.ietf.org>; Tue, 12 Oct 2004 04:09:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CHHf7-000FwQ-KH for namedroppers-data@psg.com; Tue, 12 Oct 2004 08:05:37 +0000 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CHHf6-000Fw8-Ld for namedroppers@ops.ietf.org; Tue, 12 Oct 2004 08:05:36 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 66C8726C09D; Tue, 12 Oct 2004 10:05:35 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 1262A26C09C; Tue, 12 Oct 2004 10:05:34 +0200 (CEST) Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id i9C85X8q801059; Tue, 12 Oct 2004 10:05:33 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 88767FB6E; Tue, 12 Oct 2004 10:05:33 +0200 (CEST) Date: Tue, 12 Oct 2004 10:05:33 +0200 From: Stephane Bortzmeyer <bortzmeyer@nic.fr> To: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> Cc: namedroppers@ops.ietf.org, spf-discuss@v2.listbox.com Subject: Re: IETF-61 DNSEXT agenda items Message-ID: <20041012080533.GA17012@nic.fr> References: <6.1.2.0.2.20041011160917.070d8ec0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6.1.2.0.2.20041011160917.070d8ec0@localhost> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.26-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040818i X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit On Mon, Oct 11, 2004 at 09:43:52PM -0400, Ólafur Gudmundsson/DNSEXT co-chair <ogud@ogud.com> wrote a message of 19 lines which said: > Please send them into to me. > > Agenda items we know about are: Following the closure of the MARID Working Group (http://www.imc.org/ietf-mxcomp/mail-archive/msg05054.html), an independent effort is going on to submit an Internet-Draft about SPF as a future Experimental RFC (as Ted Hardie requested in the above message). The version -00 of the draft, edited by Mark Lentczner, is ready (see a preliminary version at http://www.ozonehouse.com/mark/spf/draft-lentczner-spf-00pre2.{html,txt}) and will be formally submitted tomorrow. Since this I-D creates a new RR type (see http://www.ozonehouse.com/mark/spf/draft-lentczner-spf-00pre2.html#anchor14), I believe it would be a good idea to discuss it in a small slot of DNSext. What do you think of it? I do not know if Mark Lentczner will be there. If not, I can present the issue. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Oct 12 10:18:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22179 for <dnsext-archive@lists.ietf.org>; Tue, 12 Oct 2004 10:18:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CHNPZ-0006h4-1f for namedroppers-data@psg.com; Tue, 12 Oct 2004 14:13:57 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CHNPX-0006gq-W3 for namedroppers@ops.ietf.org; Tue, 12 Oct 2004 14:13:56 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id i9CEDBfo070073; Tue, 12 Oct 2004 10:13:24 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.1.2.0.2.20041012100511.0766efd0@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 12 Oct 2004 10:13:10 -0400 To: Stephane Bortzmeyer <bortzmeyer@nic.fr> From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> Subject: Re: IETF-61 DNSEXT agenda items Cc: namedroppers@ops.ietf.org, spf-discuss@v2.listbox.com In-Reply-To: <20041012080533.GA17012@nic.fr> References: <6.1.2.0.2.20041011160917.070d8ec0@localhost> <20041012080533.GA17012@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.44 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable At 04:05 12/10/2004, Stephane Bortzmeyer wrote: >On Mon, Oct 11, 2004 at 09:43:52PM -0400, > =D3lafur Gudmundsson/DNSEXT co-chair <ogud@ogud.com> wrote > a message of 19 lines which said: > > > Please send them into to me. > > > > Agenda items we know about are: > >Following the closure of the MARID Working Group >(http://www.imc.org/ietf-mxcomp/mail-archive/msg05054.html), an >independent effort is going on to submit an Internet-Draft about SPF >as a future Experimental RFC (as Ted Hardie requested in the above >message). > >The version -00 of the draft, edited by Mark Lentczner, is ready (see >a preliminary version at >http://www.ozonehouse.com/mark/spf/draft-lentczner-spf-00pre2.{html,txt}) >and will be formally submitted tomorrow. > >Since this I-D creates a new RR type (see >http://www.ozonehouse.com/mark/spf/draft-lentczner-spf-00pre2.html#anchor14= ), >I believe it would be a good idea to discuss it in a small slot of >DNSext. What do you think of it? > >I do not know if Mark Lentczner will be there. If not, I can present >the issue. Section 3 of the document is relevant for DNSEXT and will at some point require review by DNSEXT. The rest of the document is outside our charter and scope. We are fully aware there is no WG home for this proposal at this point. Members of the working group please read section #3 of the document after it is published and send comments to editors. The chairs will take this request under consideration and co-ordinate with AD on how to treat this request. Olafur =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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Oct 13 03:29:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27514 for <dnsext-archive@lists.ietf.org>; Wed, 13 Oct 2004 03:29:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CHdX4-000DlS-2m for namedroppers-data@psg.com; Wed, 13 Oct 2004 07:26:46 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CHdX3-000DlD-2v for namedroppers@ops.ietf.org; Wed, 13 Oct 2004 07:26:45 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 829A95DC57; Wed, 13 Oct 2004 09:26:44 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 401EF5DC34 for <namedroppers@ops.ietf.org>; Wed, 13 Oct 2004 09:26:44 +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 i9D7Qix1009718 for <namedroppers@ops.ietf.org>; Wed, 13 Oct 2004 09:26:44 +0200 Date: Wed, 13 Oct 2004 09:26:44 +0200 From: "Olaf M. Kolkman" <olaf@ripe.net> To: namedroppers@ops.ietf.org Subject: Fw: I-D ACTION:draft-iab-dns-choices-00.txt Message-Id: <20041013092644.60106e56.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.11 (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.108678 / 0.0 / 0.0 / disabled X-RIPE-Signature: 51504ccc72eeb87f9e801bceab4eeb27 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is relevant to this group. Title : Design Choices When Expanding DNS Author(s) : P. Faltstrom, R. Austein Filename : draft-iab-dns-choices-00.txt Pages : 12 Date : 2004-10-22 This note discusses how to extend the DNS with new data for a new application. DNS extension discussion too often circulate around reuse of the TXT record. This document lists different mechanisms to accomplish the extension to DNS, and comes to the conclusion use of a new RR Type is the best solution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-iab-dns-choices-00.txt --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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Oct 13 03:29:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27538 for <dnsext-archive@lists.ietf.org>; Wed, 13 Oct 2004 03:29:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CHdUT-000DQz-Nt for namedroppers-data@psg.com; Wed, 13 Oct 2004 07:24:05 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CHdUS-000DQj-J4 for namedroppers@ops.ietf.org; Wed, 13 Oct 2004 07:24:05 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 071B055FF2; Wed, 13 Oct 2004 09:24:04 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 5EDAD55F8C for <namedroppers@ops.ietf.org>; Wed, 13 Oct 2004 09:24: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 ESMTP id i9D7O3x1009202 for <namedroppers@ops.ietf.org>; Wed, 13 Oct 2004 09:24:03 +0200 Received: (from olaf@localhost) by x50.ripe.net (8.12.10/8.12.6) id i9D7O3bB018998 for namedroppers@ops.ietf.org; Wed, 13 Oct 2004 09:24:03 +0200 Received: from [204.127.198.35] (helo=rwcrmhc11.comcast.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CHYdz-0008RA-Ig for namedroppers@ops.ietf.org; Wed, 13 Oct 2004 02:13:35 +0000 Received: from localhost.localdomain (h00095bc05ec9.ne.client2.attbi.com[24.62.71.160]) by comcast.net (rwcrmhc11) with ESMTP id <2004101302133401300cf5a7e>; Wed, 13 Oct 2004 02:13:35 +0000 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.11/8.12.11) with ESMTP id i9D2815q008002 for <namedroppers@ops.ietf.org>; Tue, 12 Oct 2004 22:08:01 -0400 Received: from localhost (dee3@localhost) by localhost.localdomain (8.12.11/8.12.11/Submit) with ESMTP id i9D281vv007999 for <namedroppers@ops.ietf.org>; Tue, 12 Oct 2004 22:08:01 -0400 Date: Tue, 12 Oct 2004 22:08:01 -0400 (EDT) From: dee3@pothole.com X-X-Sender: dee3@localhost.localdomain To: namedroppers@ops.ietf.org Subject: draft-ietf-dnsext-tsig-sha-00.txt & draft-ietf-dnsext-ecc-key-05.txt In-Reply-To: <6.1.2.0.2.20041012100511.0766efd0@localhost> Message-ID: <Pine.LNX.4.60.0410122203200.7318@localhost.localdomain> References: <6.1.2.0.2.20041011160917.070d8ec0@localhost> <20041012080533.GA17012@nic.fr> <6.1.2.0.2.20041012100511.0766efd0@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-RIPE-Spam-Status: U 0.463729 / 0.0 / 0.0 / disabled X-RIPE-Signature: 18b34418f2bb91ec78553bc459454cfa X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: This post needed manual approval. Either it was posted by a non-subscribed address, or the posting was too large ( > 20000bytes ) for this list. With the massive amount of spam, it is easy to miss and therefore delete posts that need manual approval. Please use your subscribed address to post, or shorten your postings by using links instead of attachments. ] Hi, Please post any comments on these two drafts. I gave brief presentations on them at the last IETF and plan to do so again next month. If there are no substantial comments, I will ask that they be working group Last Called right after the upcoming meeting. Thanks, Donald PS: It would be preferable if you use only the name of the draft you are commenting in the subject line... ====================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 155 Beaver Street +1-508-634-2066(h) +1-508-786-7554(w) Milford, MA 01757 USA Donald.Eastlake@motorola.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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Oct 14 04:10:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17554 for <dnsext-archive@lists.ietf.org>; Thu, 14 Oct 2004 04:10:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CI0XU-000ANV-Pq for namedroppers-data@psg.com; Thu, 14 Oct 2004 08:00:44 +0000 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CI0XT-000ANA-Rm for namedroppers@ops.ietf.org; Thu, 14 Oct 2004 08:00:44 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 5E16626C096; Thu, 14 Oct 2004 10:00:42 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 526FD26C092; Thu, 14 Oct 2004 10:00:41 +0200 (CEST) Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id i9E80e8q911145; Thu, 14 Oct 2004 10:00:40 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 48AC1FB6E; Thu, 14 Oct 2004 10:00:40 +0200 (CEST) Date: Thu, 14 Oct 2004 10:00:40 +0200 From: Stephane Bortzmeyer <bortzmeyer@nic.fr> To: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> Cc: Stephane Bortzmeyer <bortzmeyer@nic.fr>, namedroppers@ops.ietf.org, spf-discuss@v2.listbox.com Subject: Re: IETF-61 DNSEXT agenda items Message-ID: <20041014080040.GA13148@nic.fr> References: <6.1.2.0.2.20041011160917.070d8ec0@localhost> <20041012080533.GA17012@nic.fr> <6.1.2.0.2.20041012100511.0766efd0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6.1.2.0.2.20041012100511.0766efd0@localhost> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.26-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040818i X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit On Tue, Oct 12, 2004 at 10:13:10AM -0400, Ólafur Gudmundsson/DNSEXT co-chair <ogud@ogud.com> wrote a message of 42 lines which said: > Members of the working group please read section #3 of the document > after it is published and send comments to editors. It is published: Title : Sender Policy Framework: Authorizing Use of Domains in MAIL FROM Author(s) : M. Lentczner, M. Wong Filename : draft-lentczner-spf-00.txt Pages : 46 Date : 2004-10-13 What about the slot? -- to 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/> From owner-namedroppers@ops.ietf.org Fri Oct 15 11:27:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12707 for <dnsext-archive@lists.ietf.org>; Fri, 15 Oct 2004 11:27:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CITvU-000CKo-U3 for namedroppers-data@psg.com; Fri, 15 Oct 2004 15:23:28 +0000 Received: from [132.151.6.71] (helo=megatron.ietf.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CITvQ-000CKK-EQ for namedroppers@ops.ietf.org; Fri, 15 Oct 2004 15:23:24 +0000 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1CITmN-00028N-Ni; Fri, 15 Oct 2004 11:14:03 -0400 X-test-idtracker: no From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> Cc: Internet Architecture Board <iab@iab.org>, RFC Editor <rfc-editor@rfc-editor.org>, dnsext mailing list <namedroppers@ops.ietf.org>, dnsext chair <ogud@ogud.com>, dnsext chair <okolkman@ripe.net> Subject: Protocol Action: 'DNS Security Introduction and Requirements' to Proposed Standard Message-Id: <E1CITmN-00028N-Ni@megatron.ietf.org> Date: Fri, 15 Oct 2004 11:14:03 -0400 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The IESG has approved the following documents: - 'DNS Security Introduction and Requirements ' <draft-ietf-dnsext-dnssec-intro-13.txt> as a Proposed Standard - 'Protocol Modifications for the DNS Security Extensions ' <draft-ietf-dnsext-dnssec-protocol-09.txt> as a Proposed Standard - 'Resource Records for the DNS Security Extensions ' <draft-ietf-dnsext-dnssec-records-11.txt> as a Proposed Standard These documents are products of the DNS Extensions Working Group. The IESG contact persons are Thomas Narten and Margaret Wasserman. Technical Summary 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. The document series consists out of 3 documents: + DNS Security Introduction and Requirements ([dnssec-intro]) + Protocol Modifications for the DNS Security Extensions ([dnssec-proto]) + Resource Records for the DNS Security Extensions ([dnssec-records]) [dnssec-intro] introduces the DNS security extensions, and describes their capabilities and limitations. [dnssec-intro] also discusses the services that the DNS security extensions do and do not provide. [dnssec-intro] describes the interrelationships between the group of documents that collectively describe DNSSEC. [dnssec-proto] describes the DNSSEC protocol modifications. [dnssec-proto] 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. [dnssec-records] defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given. Working Group Summary There was consensus within the working group to publish the document as Proposed Standard. Protocol Quality The following quote from draft-ietf-dnsext-dnssec-intro-11.txt is relevant: "The specification in the DNSSEC document set defines the behavior for zone signers and security-aware name servers and resolvers in such a way that the validating entities can unambiguously determine the state of the data. (...) A method for signaling advanced error codes and policy between a security aware stub resolver and security aware recursive nameservers is a topic for future work, as is the interface between a security aware resolver and the applications that use it. Note, however, that the lack of the specification of such communication does not prohibit deployment of signed zones or the deployment of security aware recursive name servers that prohibit propagation of bogus data to the applications." (end quote) Various parts of the specification have been implemented. There are (at least) 2 signer implementations There are (at least) 2 authoritative server implementations There is (at least) 1 verifying recursive nameserver (hence a verifying resolver) implementation. There are various troubleshooting tools that have partial or full verification capabilities. These implementations have been used in several workshops and have been found to inter-operate. This document has been reviewed for the IESG by Thomas Narten. -- to 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/> From owner-namedroppers@ops.ietf.org Fri Oct 15 15:43:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03284 for <dnsext-archive@lists.ietf.org>; Fri, 15 Oct 2004 15:43:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CIXuV-000BXo-Cb for namedroppers-data@psg.com; Fri, 15 Oct 2004 19:38:43 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CIXuK-000BWe-R9 for namedroppers@ops.ietf.org; Fri, 15 Oct 2004 19:38:33 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02917; Fri, 15 Oct 2004 15:38:28 -0400 (EDT) Message-Id: <200410151938.PAA02917@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-tkey-renewal-mode-05.txt Date: Fri, 15 Oct 2004 15:38:28 -0400 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : TKEY Secret Key Renewal Mode Author(s) : Y. Kamite, M. Nakayama Filename : draft-ietf-dnsext-tkey-renewal-mode-05.txt Pages : 23 Date : 2004-10-15 This document defines a new mode in TKEY and proposes an atomic method for changing secret keys used for TSIG periodically. Originally, TKEY provides methods of setting up shared secrets other than manual exchange, but it cannot control timing of key renewal very well though it can add or delete shared keys separately. This proposal is a systematical key renewal procedure intended for preventing signing DNS messages with old and non-safe keys permanently. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tkey-renewal-mode-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-tkey-renewal-mode-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-tkey-renewal-mode-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: <2004-10-15154026.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-tkey-renewal-mode-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-tkey-renewal-mode-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-15154026.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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Oct 15 15:43:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03302 for <dnsext-archive@lists.ietf.org>; Fri, 15 Oct 2004 15:43:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CIXu9-000BVu-5s for namedroppers-data@psg.com; Fri, 15 Oct 2004 19:38:21 +0000 Received: from [65.205.251.74] (helo=colibri.verisign.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CIXu5-000BVA-2M for namedroppers@ops.ietf.org; Fri, 15 Oct 2004 19:38:17 +0000 Received: from mou1wnexc01.vcorp.ad.vrsn.com (mailer4.verisign.com [65.205.251.53]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i9FJcGCH016597 for <namedroppers@ops.ietf.org>; Fri, 15 Oct 2004 12:38:16 -0700 (PDT) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <4761G8M3>; Fri, 15 Oct 2004 12:38:16 -0700 Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BEC8F@mou1wnexm05.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" <pbaker@verisign.com> To: namedroppers@ops.ietf.org Subject: RE: I-D ACTION:draft-iab-dns-choices-00.txt Date: Fri, 15 Oct 2004 12:38:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The claims made in section 3.2 (below) do not accurately reflect the situation with wildcards. The conclusion of MARID was that wildcards are actually irrelevant as specified since they do not in fact work for any of the use cases. The DNS really needs at least two wildcard types, * The current wildcard, if www.example.com exists the wildcard *.example.com will NOT match for ANY record. *? The wildcard people think they have and mostly want, TXT/*.example.com will match iff www.example.com exists but has no other TXT record. As a matter of history quite a few DNS servers have actually implemented the nonstandard *? wildcard which is one reason for the confusion. The use cases given in the MARID case did not work, in particular is was not possible to construct a wildcard to say 'this machine does not send mail' since *.example.com will not match phill.example.com if there is ANY record for the node. The use case is real but it cannot be met without *? style wildcards. A wildcard properly understood is merely a notational convention that is used in the configuration of the server. In the absence of DNSSEC there is no real interoperability issue. Even _WITH_ DNSSEC a server can implement *? wildcards synthetically, it just means enumerating the additional records for the nodes. To make the prefix scheme work completely all that is needed is to allow for midpoint wildcards, i.e. match on _prefix.*.example.com and _prefix.*?.example.com Fixing the NSEC/NXT record to meet these needs is not at all difficult. If these changes are deployed then the RR type becomes merely a syntax container and an infinite (OK 2^124) number of semantics may be bound thereto by defining new prefixes. It is now possible to deploy new RR semantics without the need to upgrade ANY infrastructure whatsoever, everything flows through the existing infrastructure. The only parties that need to change are those who choose to use wildcards and even for them the software change is a one time affair. The difference in implementation cost is vast. Even with DNSEXT new RRs will require new software for any party deploying them. In the real world 'stick hex values in the config file' is just not a viable solution. The RR architecture conflates syntax and semantics. The view of RR as being a syntax container whose semantics are defined by means of a prefix has already been established by SRV and NAPTR. Section 3.5 Fails to tell the reader that a majority of deployed DNS servers do not in fact provide support for new DNS records. The claims that Windows platform DNS servers provide support neglect to mention the lack of support for creitical features such as the ability to remember settings after a restart and the ability to do zone transfers. The draft admits in section 4 that the purpose of the controls is political and not technical. As such the draft is naive, in order to maintain control it places a ridiculous and unnecessary burden on proposals. This only encourages parties with an alternative view of how the DNS should work to seek other venues and receive endorsement and approval in those venues. The W3C has already defined SRV entry points for protocols on an ad hoc basis. The statement made in section 5 that recent surveys show that deplyoment of a new RR are practical is factually incorrect. The survey if it is the one I beleive is refered to (no citations are given) actually states the reverse As a matter of organization there are two sections purporting to be conclusions, both of which introduce new claims to support the argument in an ad hoc fashion, mostly without references. The only disadvantage of prefixed TXT records is the loss of wildcarding. The disadvantage of a new RR is serious, the majority of the deployed DNS base does not support that application and this will not change for at least a product cycle, which means three years. Application developers should be allowed to decide if the deployment advantage of prefixed DNS records outweighs the loss of wildcards. It is an entirely reasonable engineering decision. If wildcarding is so spectacularly important then the group will of course be anxious to fix it. ----Excerpt--- Add a prefix to the owner name By adding an application-specific prefix to a domain name, we will get different name/class/type triples, and therefore different RRsets. The problem with adding prefixes has to do with wildcards, especially if one has records like *.example.com. IN MX 1 mail.example.com. and one wants records tied to those names. Suppose one creates the prefix "_mail". One would then have to say something like _mail.*.example.com. IN X-FOO A B C D but DNS wildcards only work with the "*" as the leftmost token in the domain name. Even when a specific prefix is chosen, the data will still have to be stored in some RR type. This RR type can either be a "kitchen-sink record" or a new RR type. This implies that some other mechanism has to be applied as well, with implications detailed in other parts of this note (see also draft-ietf-dnsext-wcard-clarify [wcardclarify] -- to 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/> From owner-namedroppers@ops.ietf.org Fri Oct 15 16:10:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07052 for <dnsext-archive@lists.ietf.org>; Fri, 15 Oct 2004 16:10:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CIYLZ-000EtI-Hn for namedroppers-data@psg.com; Fri, 15 Oct 2004 20:06:41 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CIYLY-000Esz-Lh for namedroppers@ops.ietf.org; Fri, 15 Oct 2004 20:06:40 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 65FE9C2DA9; Fri, 15 Oct 2004 21:06:39 +0100 (BST) Date: Fri, 15 Oct 2004 21:06:36 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: "Hallam-Baker, Phillip" <pbaker@verisign.com>, namedroppers@ops.ietf.org Cc: Alex Bligh <alex@alex.org.uk> Subject: RE: I-D ACTION:draft-iab-dns-choices-00.txt Message-ID: <41C1931FFF182259217229B9@[192.168.100.25]> In-Reply-To: <C6DDA43B91BFDA49AA2F1E473732113E010BEC8F@mou1wnexm05.vcorp.ad.vrsn.com> References: <C6DDA43B91BFDA49AA2F1E473732113E010BEC8F@mou1wnexm05.vcorp.ad.v rsn.com> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 15 October 2004 12:38 -0700 "Hallam-Baker, Phillip" <pbaker@verisign.com> wrote: > * The current wildcard, if www.example.com exists the > wildcard *.example.com will NOT match for ANY record. > > *? The wildcard people think they have and mostly want, > TXT/*.example.com will match iff www.example.com exists > but has no other TXT record. > > As a matter of history quite a few DNS servers have actually > implemented the nonstandard *? wildcard which is one reason > for the confusion. > > The use cases given in the MARID case did not work, in particular > is was not possible to construct a wildcard to say 'this machine > does not send mail' since *.example.com will not match > phill.example.com if there is ANY record for the node. The > use case is real but it cannot be met without *? style wildcards. Does the latter (*?) actually need any protocol-level specification? By which I mean is it not possible to a) On a strictly conformant server, emulate *? with a macro (or similar), so *? IN TXT foo a IN TXT bar b IN MX baz becomes * IN TXT foo a IN TXT bar b IN MX baz b IN MX bar b) If one wants to implement a server where * means "the other thing", i.e. *? (and you note some servers have done this), say "* in a zone file means *?" (and preferably provide a way to get *). Alex -- to 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/> From owner-namedroppers@ops.ietf.org Fri Oct 15 18:19:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29854 for <dnsext-archive@lists.ietf.org>; Fri, 15 Oct 2004 18:19:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CIaM3-0001Yo-JS for namedroppers-data@psg.com; Fri, 15 Oct 2004 22:15:19 +0000 Received: from [80.91.229.2] (helo=main.gmane.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CIaM2-0001YJ-E1 for namedroppers@ops.ietf.org; Fri, 15 Oct 2004 22:15:18 +0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CIaM0-0000L4-00 for <namedroppers@ops.ietf.org>; Sat, 16 Oct 2004 00:15:16 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <namedroppers@ops.ietf.org>; Sat, 16 Oct 2004 00:15:16 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <namedroppers@ops.ietf.org>; Sat, 16 Oct 2004 00:15:16 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org From: Simon Josefsson <jas@extundo.com> Subject: RFC 2538bis Date: Sat, 16 Oct 2004 00:14:57 +0200 Lines: 20 Message-ID: <ilu8ya7tyqm.fsf@latte.josefsson.org> References: <200410151949.PAA03947@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:riSchh/c7qyfwugm+j+EV7T1xtA= X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Dear All, To ease review of the differences between RFC 2538 and the draft below, I have created <http://josefsson.org/rfc2538bis/>. You may send me suggestions and thoughts related to 2538. Thanks, Simon > Title : Storing Certificates in the Domain Name System (DNS) > Filename : draft-josefsson-rfc2538bis-00.txt > > Cryptographic public key are frequently published and their > authenticity demonstrated by certificates. A CERT resource record > (RR) is defined so that such certificates and related certificate > revocation lists can be stored in the Domain Name System (DNS). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-josefsson-rfc2538bis-00.txt -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sun Oct 17 19:42:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05042 for <dnsext-archive@lists.ietf.org>; Sun, 17 Oct 2004 19:42:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CJKUQ-0008sy-BB for namedroppers-data@psg.com; Sun, 17 Oct 2004 23:31:02 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CJKUP-0008rJ-4r for namedroppers@ops.ietf.org; Sun, 17 Oct 2004 23:31:01 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.11/8.12.11) with ESMTP id i9HNUrVR066647 for <namedroppers@ops.ietf.org>; Sun, 17 Oct 2004 19:30:53 -0400 (EDT) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.12.11/8.12.11/Submit) id i9HNUrVG066646 for namedroppers@ops.ietf.org; Sun, 17 Oct 2004 19:30:53 -0400 (EDT) (envelope-from namedroppers) Received: from [131.107.3.124] (helo=mail2.microsoft.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CJDy6-000FPk-Rk for namedroppers@ops.ietf.org; Sun, 17 Oct 2004 16:33:14 +0000 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Sun, 17 Oct 2004 09:33:14 -0700 Received: from red-hub-02.redmond.corp.microsoft.com ([157.54.7.100]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 17 Oct 2004 09:31:31 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 17 Oct 2004 09:33:13 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Sun, 17 Oct 2004 09:33:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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: I-D ACTION:draft-iab-dns-choices-00.txt Date: Sun, 17 Oct 2004 09:33:06 -0700 Message-ID: <DAC3FCB50E31C54987CD10797DA511BA0B794D57@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: I-D ACTION:draft-iab-dns-choices-00.txt Thread-Index: AcSy82RXhLL1JE0HRmeWop4+Esse8wBboIng From: "Christian Huitema" <huitema@windows.microsoft.com> To: <namedroppers@ops.ietf.org> X-OriginalArrivalTime: 17 Oct 2004 16:33:14.0226 (UTC) FILETIME=[FFAABD20:01C4B466] X-Scanned-By: MIMEDefang 2.44 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] Having a document like that is very useful, and the arguments are well put, but I find three weaknesses in this version: unsubstantiated claims about TCP, too much emphasis on wild cards in the analysis of the "name prefix" solution, and a failure to acknowledge the potential desire of implementers to avoid the IETF process. Throughout the document, there are claims that having large records or large record sets increases the risk of using TCP, which is true, and that using TCP would be a catastrophe, which is dubious. In the draft, the main argument against TCP for DNS is one of server performance. The draft says that a TCP based operation causes 3 times more traffic, but this is merely three types as many packets, not bytes. It also says that the server load will be much increased, since processing UDP packets is "much simpler". However, the TCP code paths are much optimized in modern servers, and there is little performance penalty of serving a request over TCP versus UDP.=20 TCP has other advantages. Commercial load balancing solutions in large server farms are designed for TCP, not UDP. The three way handshake in TCP enables a potent defense against denial of service attacks, and makes some spoofing attacks much harder. In fact, this group should probably reconsider its stance versus TCP. The main argument against the name prefix solution is its incompatibility with wild cards. Without going in a deep analysis of wild card usage, I note that we have some experience with using name prefixes for SRV records, and that the mail logs are not full of complaints about incompatibility between SRV and wild cards. In most cases, applications know exactly which domain name should be extended, and do not need the wild card facility. The wild card problem may exist in theory, but it is seldom encountered in practice, and there are obvious workarounds. The document does not discuss the role of the IETF in the record type creation process. This is an important issue for implementers. Although the RR type field has the same size as the TCP port numbers, they are not allocated in the same way. RFC 2929 lists record type numbers 4096-65535 as "available for assignment", but the IANA has no "Online Application for a User (Registered) DNS Record Type Number". In practice, record types can only be created by "IETF Consensus", which takes a long time. This contributes to the public perception that creating a record type is hard. This working group should either open the current IANA procedures, or keep them while acknowledging that record type creation is hard. -- Christian Huitema -- to 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/> From owner-namedroppers@ops.ietf.org Mon Oct 18 09:41:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16477 for <dnsext-archive@lists.ietf.org>; Mon, 18 Oct 2004 09:41:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CJXgN-000NQr-EL for namedroppers-data@psg.com; Mon, 18 Oct 2004 13:36:15 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CJXgG-000NQ3-4c for namedroppers@ops.ietf.org; Mon, 18 Oct 2004 13:36:08 +0000 Received: from [192.35.166.53] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id i9IDZrhT069356; Mon, 18 Oct 2004 09:35:59 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a06110401bd9975bf2a08@[192.35.166.53]> Date: Mon, 18 Oct 2004 09:35:55 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis <Ed.Lewis@neustar.biz> Subject: wcard draft out there... Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.44 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk ...in case no one noticed. ;) http://www.ietf.org/internet-drafts/draft-ietf-dnsext-wcard-clarify-03.txt I'd like to be able to refresh the draft by the deadline - if not just to update the editor contact info - so comments would be appreciated this week. I don't think there are any outstanding substantive questions. The document was greatly reorganized, there are a lot of rough wording edges that'll need to be smoothed, if nothing else. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar "Now under neu management" -- to 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/> From owner-namedroppers@ops.ietf.org Mon Oct 18 12:11:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28212 for <dnsext-archive@lists.ietf.org>; Mon, 18 Oct 2004 12:11:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CJZzN-000IOY-Q4 for namedroppers-data@psg.com; Mon, 18 Oct 2004 16:04:01 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CJZz7-000IN4-6F for namedroppers@ops.ietf.org; Mon, 18 Oct 2004 16:03:51 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.11/8.12.11) with ESMTP id i9IG3JC3071195 for <namedroppers@ops.ietf.org>; Mon, 18 Oct 2004 12:03:20 -0400 (EDT) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.12.11/8.12.11/Submit) id i9IG3JW7071194 for namedroppers@ops.ietf.org; Mon, 18 Oct 2004 12:03:19 -0400 (EDT) (envelope-from namedroppers) Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CJL5t-000DKJ-1I for namedroppers@ops.ietf.org; Mon, 18 Oct 2004 00:09:45 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id C340B13E12 for <namedroppers@ops.ietf.org>; Mon, 18 Oct 2004 00:09:44 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-iab-dns-choices-00.txt In-Reply-To: Message from "Christian Huitema" <huitema@windows.microsoft.com> of "Sun, 17 Oct 2004 09:33:06 MST." <DAC3FCB50E31C54987CD10797DA511BA0B794D57@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 18 Oct 2004 00:09:44 +0000 Message-Id: <20041018000944.C340B13E12@sa.vix.com> X-Scanned-By: MIMEDefang 2.44 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] > ... find three weaknesses in this version: unsubstantiated claims about TCP > ... > Throughout the document, there are claims that having large records or > large record sets increases the risk of using TCP, which is true, and > that using TCP would be a catastrophe, which is dubious. In the draft, > the main argument against TCP for DNS is one of server performance. The > draft says that a TCP based operation causes 3 times more traffic, but > this is merely three types as many packets, not bytes. It also says that > the server load will be much increased, since processing UDP packets is > "much simpler". However, the TCP code paths are much optimized in modern > servers, and there is little performance penalty of serving a request > over TCP versus UDP. you are wrong. speaking for f-root, if we had to build a protocol control block for each of the 5000 to 10000 queries that came in every second, and exchange packets between our state machine and remote state machine, before finally sending the response and reclaiming the state-memory, we'd need a lot more hardware than we have today. it's not the bytes, or the packets-- those we can provision easily. it's the state-memory occupancy time that would dominate. i'm not saying it can't be done. our headroom would allow this to happen overnight... but then we'd have to start provisioning more headroom. the claims in this document are accurate. tcp is more expensive than udp for dns. making a decision that would require all high volume nameservers in the internet to jump curves wrt headroom and provisioning is what's "dubious". > TCP has other advantages. Commercial load balancing solutions in large > server farms are designed for TCP, not UDP. The three way handshake in > TCP enables a potent defense against denial of service attacks, and > makes some spoofing attacks much harder. In fact, this group should > probably reconsider its stance versus TCP. why stop there? xml has a lot of advantages -- maybe dns should stop using binary packet formats and just use html. this would make internationalization easier, for one thing. for that matter, why use a dedicated protocol for dns when we could use sunrpc, or ldap, or SMB/CIFS, or SQL? (note to the humour-challenged, this is Sarcasm on my part.) -- to 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/> From owner-namedroppers@ops.ietf.org Mon Oct 18 13:10:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02541 for <dnsext-archive@lists.ietf.org>; Mon, 18 Oct 2004 13:10:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CJayy-0001T3-W6 for namedroppers-data@psg.com; Mon, 18 Oct 2004 17:07:41 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CJayx-0001Sd-LH for namedroppers@ops.ietf.org; Mon, 18 Oct 2004 17:07:40 +0000 Received: from delta.noi.kre.to (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id i9IH7bZ22233; Tue, 19 Oct 2004 00:07:37 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i9IH7XLi027748; Tue, 19 Oct 2004 00:07:34 +0700 (ICT) From: Robert Elz <kre@munnari.OZ.AU> To: Edward Lewis <Ed.Lewis@neustar.biz> cc: namedroppers@ops.ietf.org Subject: Re: wcard draft out there... In-Reply-To: <a06110401bd9975bf2a08@[192.35.166.53]> References: <a06110401bd9975bf2a08@[192.35.166.53]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Oct 2004 00:07:33 +0700 Message-ID: <11673.1098119253@munnari.OZ.AU> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,BIZ_TLD autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Mon, 18 Oct 2004 09:35:55 -0400 From: Edward Lewis <Ed.Lewis@neustar.biz> Message-ID: <a06110401bd9975bf2a08@[192.35.166.53]> | I don't think there are any outstanding substantive questions. The | document was greatly reorganized, there are a lot of rough wording | edges that'll need to be smoothed, if nothing else. I see nothing in there that's wrong, but there are LOTS of little things that need fixing (from typos to poor explanations). I'll try to send a list tonight (if not, nothing from me before the deadline), but just reading the thing makes most of them jump out and hit you... 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Oct 18 13:10:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02564 for <dnsext-archive@lists.ietf.org>; Mon, 18 Oct 2004 13:10:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CJawr-000198-Na for namedroppers-data@psg.com; Mon, 18 Oct 2004 17:05:29 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CJawq-00016u-Bg for namedroppers@ops.ietf.org; Mon, 18 Oct 2004 17:05:28 +0000 Received: from delta.noi.kre.to (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id i9IH5PZ22173; Tue, 19 Oct 2004 00:05:25 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i9IH5ILi007624; Tue, 19 Oct 2004 00:05:19 +0700 (ICT) From: Robert Elz <kre@munnari.OZ.AU> To: Paul Vixie <paul@vix.com> cc: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-iab-dns-choices-00.txt In-Reply-To: <20041018000944.C340B13E12@sa.vix.com> References: <20041018000944.C340B13E12@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Oct 2004 00:05:18 +0700 Message-ID: <16841.1098119118@munnari.OZ.AU> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Mon, 18 Oct 2004 00:09:44 +0000 From: Paul Vixie <paul@vix.com> Message-ID: <20041018000944.C340B13E12@sa.vix.com> | if we had to build a protocol control | block for each of the 5000 to 10000 queries that came in every second, It is worse than that. TIME_WAIT state (in addition to be required somewhere, consuming resources - but that's probably at the client) limits the number of TCP transactions/second between a client+server pair (where the server port is fixed, as it is here) very severely, it turns into just 100's a second (depending upon the packet TTLs, and so what the MSL is). That's insufficient for many DNS applications - which means that they'd need to re-use connections - which means leaving connections alive on the off chance they'll be needed again soon after. That means that all that state either hangs around much longer than you'd really want it to, or the server needs to close down the connections, which means that it is the system that ends up in TIME_WAIT, and that means a minumum of a couple of minutes per connection in idle state. TCP just isn't an option for transaction services, like the DNS. We could switch to using T/TCP, but we'd have to find something in widespread use that actually has that available first... (and that still means lots of connection setup). On one of Christian's other points ... | The main argument against the name prefix solution is its | incompatibility with wild cards. The main argument against it should be that domain names don't belong to the IETF, they belong to whoever registered the domain, and the IETF has no business whatever stealing names from organisations' domains. 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Oct 18 13:10:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02632 for <dnsext-archive@lists.ietf.org>; Mon, 18 Oct 2004 13:10:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CJazA-0001Uh-3Y for namedroppers-data@psg.com; Mon, 18 Oct 2004 17:07:52 +0000 Received: from [65.205.251.75] (helo=robin.verisign.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CJaz9-0001UL-2X for namedroppers@ops.ietf.org; Mon, 18 Oct 2004 17:07:51 +0000 Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i9IH7m6Q014991; Mon, 18 Oct 2004 10:07:48 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <VCCW893H>; Mon, 18 Oct 2004 10:07:48 -0700 Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BECA0@mou1wnexm05.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" <pbaker@verisign.com> To: "'Alex Bligh'" <alex@alex.org.uk>, "Hallam-Baker, Phillip" <pbaker@verisign.com>, namedroppers@ops.ietf.org Subject: RE: I-D ACTION:draft-iab-dns-choices-00.txt Date: Mon, 18 Oct 2004 10:07:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > -----Original Message----- > From: Alex Bligh [mailto:alex@alex.org.uk] On 15 October 2004 12:38 -0700 "Hallam-Baker, Phillip" > <pbaker@verisign.com> wrote: > > > * The current wildcard, if www.example.com exists the > > wildcard *.example.com will NOT match for ANY record. > > > > *? The wildcard people think they have and mostly want, > > TXT/*.example.com will match iff www.example.com exists > > but has no other TXT record. > Does the latter (*?) actually need any protocol-level specification? > > By which I mean is it not possible to > a) On a strictly conformant server, emulate *? with a macro > (or similar), All that is required is to document the wildcard usage and to define an interchange format for it so that it can be used in zone transfers and an appropriate NXT/NSEC usage. The same applies for mid-level wildcards, _marid.*.example.com. It is not rocket science. I find it objectionable that we have people saying that the only alternatives that can be considered here are prefixes without wildcards or waiting for DNSEXT to deploy. There has been a real alternative on the table that makes prefixes work as well as new RRs but with a significantly lower impact on the deployed infrastructure. Only parties that need wildcards need to upgrade their servers. I propose that the draft authors be asked to address these issues. -- to 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/> From owner-namedroppers@ops.ietf.org Mon Oct 18 13:24:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03892 for <dnsext-archive@lists.ietf.org>; Mon, 18 Oct 2004 13:24:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CJbBx-0003Jy-BY for namedroppers-data@psg.com; Mon, 18 Oct 2004 17:21:05 +0000 Received: from [65.205.251.75] (helo=robin.verisign.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CJbBw-0003Jl-FS for namedroppers@ops.ietf.org; Mon, 18 Oct 2004 17:21:04 +0000 Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i9IHL3uR017166; Mon, 18 Oct 2004 10:21:04 -0700 (PDT) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <476CW4DS>; Mon, 18 Oct 2004 10:21:03 -0700 Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BECA1@mou1wnexm05.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" <pbaker@verisign.com> To: "'Paul Vixie'" <paul@vix.com>, namedroppers@ops.ietf.org Subject: RE: I-D ACTION:draft-iab-dns-choices-00.txt Date: Mon, 18 Oct 2004 10:20:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > you are wrong. speaking for f-root, if we had to build a > protocol control > block for each of the 5000 to 10000 queries that came in > every second, and > exchange packets between our state machine and remote state > machine, before > finally sending the response and reclaiming the state-memory, > we'd need a > lot more hardware than we have today. it's not the bytes, or > the packets-- > those we can provision easily. it's the state-memory > occupancy time that > would dominate. The problem is not so much building a protocol control block as routing. As soon as you have to maintain state you have to make sure that all the requests that require access to that state occur in the same memory partition. This is where you start to see somewhat subtle performance issues on multi-way CPU boxes. Memory shared for read is easy, the state control blocks have to be R/W shared and you cache goes sour. > > TCP has other advantages. Commercial load balancing > solutions in large > > server farms are designed for TCP, not UDP. The three way > handshake in > > TCP enables a potent defense against denial of service attacks, and > > makes some spoofing attacks much harder. In fact, this group should > > probably reconsider its stance versus TCP. There is a reason that commercial loadbalancing is designed for TCP, that is where you need it! If you do not have to deal with state then you can deal with routing in a much simpler and more brutal fashion. > why stop there? xml has a lot of advantages -- maybe dns should stop > using binary packet formats and just use html. this would make > internationalization easier, for one thing. for that matter, > why use a > dedicated protocol for dns when we could use sunrpc, or ldap, or > SMB/CIFS, or SQL? (note to the humour-challenged, this is Sarcasm on > my part.) Binary coded XML is a very good idea, it can be at least as efficient as the DNS encoding. Web Services require a policy layer. There are two routes forward from here. One is to try to use UDDI and watch that become the naming infrastructure. The second is to extend the existing DNS since the policy layer is no more complex than existing SRV and NAPTR schemes. -- to 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/> From owner-namedroppers@ops.ietf.org Mon Oct 18 13:37:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04998 for <dnsext-archive@lists.ietf.org>; Mon, 18 Oct 2004 13:37:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CJbPo-0005Nl-0b for namedroppers-data@psg.com; Mon, 18 Oct 2004 17:35:24 +0000 Received: from [65.205.251.74] (helo=colibri.verisign.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CJbPk-0005N1-0O for namedroppers@ops.ietf.org; Mon, 18 Oct 2004 17:35:20 +0000 Received: from mou1wnexc01.vcorp.ad.vrsn.com (mailer4.verisign.com [65.205.251.53]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i9IHZCGe015240; Mon, 18 Oct 2004 10:35:12 -0700 (PDT) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <VCDJWRTF>; Mon, 18 Oct 2004 10:35:12 -0700 Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BECA2@mou1wnexm05.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" <pbaker@verisign.com> To: "'Robert Elz'" <kre@munnari.OZ.AU>, Paul Vixie <paul@vix.com> Cc: namedroppers@ops.ietf.org Subject: RE: I-D ACTION:draft-iab-dns-choices-00.txt Date: Mon, 18 Oct 2004 10:35:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > On one of Christian's other points ... > > | The main argument against the name prefix solution is its > | incompatibility with wild cards. > > The main argument against it should be that domain names don't belong > to the IETF, they belong to whoever registered the domain, > and the IETF > has no business whatever stealing names from organisations' domains. Names such as _MARID.example.com are unusable for DNS as machine names. It is already agreed that names of some form --xxx will be assigned for internationalization use. So whats this with calling it 'stealling'? Christian is making an important point. The reason SPF is written to the bare TXT record without a prefix is that the people behind it had no way to get themselves a RR without waiting for two years before they could start deployment. Sure they have asked for a RR, but they have absolutely no intention of ever using it or participating in a migration to it. We are back with the X-Header problem of RFC 822, only worse because the unprefixed TXT record is going to become useless for other purposes. As Alex points out most applications do not require wildcards at all, merely server side macros that expand to the appropriate entries. The wildcard issue is thus irrelevant wrt prefixes, it can be solved by a single site deployment that has no impact on the rest of the infrastructure. -- to 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/> From owner-namedroppers@ops.ietf.org Mon Oct 18 13:42:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05419 for <dnsext-archive@lists.ietf.org>; Mon, 18 Oct 2004 13:42:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CJbU4-0005va-20 for namedroppers-data@psg.com; Mon, 18 Oct 2004 17:39:48 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CJbTw-0005uh-7z for namedroppers@ops.ietf.org; Mon, 18 Oct 2004 17:39:40 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 4188CC2DA4; Mon, 18 Oct 2004 18:39:39 +0100 (BST) Date: Mon, 18 Oct 2004 18:39:30 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: Christian Huitema <huitema@windows.microsoft.com>, namedroppers@ops.ietf.org Cc: Alex Bligh <alex@alex.org.uk> Subject: RE: I-D ACTION:draft-iab-dns-choices-00.txt Message-ID: <6DA92ED4B773C80CE37A297B@[192.168.100.25]> In-Reply-To: <DAC3FCB50E31C54987CD10797DA511BA0B794D57@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> References: <DAC3FCB50E31C54987CD10797DA511BA0B794D57@WIN-MSG-10.wingroup.wi ndeploy.ntdev.microsoft.com> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 17 October 2004 09:33 -0700 Christian Huitema <huitema@windows.microsoft.com> wrote: > TCP has other advantages. Commercial load balancing solutions in large > server farms are designed for TCP, not UDP. Aside from all the other arguments per Paul and Co, this is a real false syllogism I can't let rest. It is true that (most) commercial load balancing solutions in large server farms are designed for TCP not UDP; however, this is because: (a) the most frequently used (by requirement for load sharing) protocols use TCP (e.g. HTTP); and (b) Anycast is so easy it doesn't require a "commercial load balancing solution" the same way TCP does, because it does not need to record state. Indeed your premise could more validly be used as a counter-argument: load sharing over TCP is sufficiently difficult that large server farms require deployment of commercial load balancing solutions to do it, whereas effective load balancing on UDP can be deployed using far more lightweight technology such as anycast. Thus by switching to TCP you are increasing the cost of load-balanced DNS (by your own thesis and apart from Paul's and Phill's observations). Alex -- to 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/> From owner-namedroppers@ops.ietf.org Mon Oct 18 13:45:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05688 for <dnsext-archive@lists.ietf.org>; Mon, 18 Oct 2004 13:45:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CJbXL-0006jM-8R for namedroppers-data@psg.com; Mon, 18 Oct 2004 17:43:11 +0000 Received: from [65.205.251.75] (helo=robin.verisign.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CJbXK-0006j9-EK for namedroppers@ops.ietf.org; Mon, 18 Oct 2004 17:43:10 +0000 Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i9IHh9ri018840; Mon, 18 Oct 2004 10:43:09 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <VCCW9CQ8>; Mon, 18 Oct 2004 10:43:09 -0700 Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BECA3@mou1wnexm05.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" <pbaker@verisign.com> To: "'Edward Lewis'" <Ed.Lewis@neustar.biz>, namedroppers@ops.ietf.org Subject: RE: wcard draft out there... Date: Mon, 18 Oct 2004 10:43:06 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,BIZ_TLD autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk It would be very helpful if the draft made plain that it is discussing only the interpretation of 'wildcards' insofar as they must be understood in communications between DNS servers, i.e. zone transfers and NSEC type records. A DNS server may effectively support any configuration language it chooses and support 'macros' that expand according to any semantics that are useful to the sysadmin. So *.example.com is a DNS wildcard. But a server may implement a configuration language that supports _ssh._tcp.?.example.com if it chooses to. Or for that matter matches of the form www?.example.com if it choose to. A standard definition of such macros might help understanding but is not necessary for interoperability. * - matches only nodes that do NOT exist ? - matches only nodes that do exist *? - matches all nodes. > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Edward Lewis > Sent: Monday, October 18, 2004 9:36 AM > To: namedroppers@ops.ietf.org > Cc: ed.lewis@neustar.biz > Subject: wcard draft out there... > > > ...in case no one noticed. ;) > > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-wcard-cl > arify-03.txt > > I'd like to be able to refresh the draft by the deadline - if > not just to > update the editor contact info - so comments would be > appreciated this week. > > I don't think there are any outstanding substantive questions. The > document was greatly reorganized, there are a lot of rough wording > edges that'll need to be smoothed, if nothing else. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > -=-=-=-=- > Edward Lewis > +1-571-434-5468 > NeuStar > > "Now under neu management" > > -- > to 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/> > -- to 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/> From owner-namedroppers@ops.ietf.org Mon Oct 18 14:02:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07179 for <dnsext-archive@lists.ietf.org>; Mon, 18 Oct 2004 14:02:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CJbnF-0009M8-Gb for namedroppers-data@psg.com; Mon, 18 Oct 2004 17:59:37 +0000 Received: from [129.46.51.58] (helo=numenor.qualcomm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CJbnE-0009Lt-Ig for namedroppers@ops.ietf.org; Mon, 18 Oct 2004 17:59:36 +0000 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i9IHxVHC020976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 18 Oct 2004 10:59:31 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i9IHxSIj005366; Mon, 18 Oct 2004 10:59:29 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: <p06110403bd99b2b48271@[129.46.227.161]> In-Reply-To: <C6DDA43B91BFDA49AA2F1E473732113E010BECA2@mou1wnexm05.vcorp.ad.vrsn.com> References: <C6DDA43B91BFDA49AA2F1E473732113E010BECA2@mou1wnexm05.vcorp.ad.vrsn.com> Date: Mon, 18 Oct 2004 10:59:26 -0700 To: "Hallam-Baker, Phillip" <pbaker@verisign.com>, "'Robert Elz'" <kre@munnari.oz.au>, Paul Vixie <paul@vix.com> From: Ted Hardie <hardie@qualcomm.com> Subject: RE: I-D ACTION:draft-iab-dns-choices-00.txt Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 10:35 AM -0700 10/18/04, Hallam-Baker, Phillip wrote: >Christian is making an important point. The reason SPF is written >to the bare TXT record without a prefix is that the people behind >it had no way to get themselves a RR without waiting for two years >before they could start deployment. While Christian's point is important, I note that BCP 42 actually distinguishes among various ranges: 1 - 127 0x0001 - 0x007F - remaining TYPEs in this range are assigned for data TYPEs by IETF Consensus. 128 - 255 0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and Meta TYPEs by IETF Consensus. 256 - 32767 0x0100 - 0x7FFF - assigned for data, Q, or Meta TYPE use by IETF Consensus. 32768 - 65279 0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434]. 65280 - 65535 0xFF00 - 0xFFFF - Private Use. Using a code from the "private use" range for SPF might have been a bit of stretch, but "specification required" would have been possible with far less of a barrier than a two-year consensus process. I believe the fundamental reason these folks chose TXT was that existing libraries understood TXT records well enough. The ease of parsing these records was the second factor, again, in my opinion. If folks thing BCP 42 needs an update, or that IANA needs new processes to handle requests in the various ranges, I think now might be a good time to send text. Since RFC 3597 is now a proposed standard, we can hope for more complete libraries, and I suspect we will see more requests for new RRs. Just my opinion, regards, Ted -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Oct 18 14:30:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09854 for <dnsext-archive@lists.ietf.org>; Mon, 18 Oct 2004 14:30:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CJcD7-000D5o-HJ for namedroppers-data@psg.com; Mon, 18 Oct 2004 18:26:21 +0000 Received: from [65.205.251.75] (helo=robin.verisign.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CJcCx-000D4w-BH for namedroppers@ops.ietf.org; Mon, 18 Oct 2004 18:26:11 +0000 Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i9IIQ62U021842; Mon, 18 Oct 2004 11:26:06 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <VCCW91S7>; Mon, 18 Oct 2004 11:26:06 -0700 Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BECA8@mou1wnexm05.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" <pbaker@verisign.com> To: "'Ted Hardie'" <hardie@qualcomm.com>, "Hallam-Baker, Phillip" <pbaker@verisign.com>, "'Robert Elz'" <kre@munnari.oz.au>, Paul Vixie <paul@vix.com> Cc: namedroppers@ops.ietf.org Subject: RE: I-D ACTION:draft-iab-dns-choices-00.txt Date: Mon, 18 Oct 2004 11:26:03 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Using a code from the "private use" range for SPF might have been > a bit of stretch, but "specification required" would have > been possible > with far less of a barrier than a two-year consensus process. If we are talking about anything less than a two year consensus process then the text should not be talking about protecting the DNS from maluse or baddly thought out proposals since that is not going to be addressed by the process. If that claim is going to be raised at all it should be substantiated with empirical evidence rather than introduced for the first time in one of the conclusions sections. We already have an example of a record that has deliberately set to evade the review process. I beleive that if the data is fairly interpreted then the only significant difference between prefixes and new RRs is the extent of the review process. It is a logically consistent, albeit naive, point of view that the review process might save the DNS from a destructive record definition. But this point of view is not consistent with RRs being readily available. If the 'specification only' RRs are in fact issued then there will be a new problem, nobody will ever want to use a standards process RR again unless there is an inescapable loss of backwards compatibililty anyway. Since the proposals will start with a specification only number and have no incentive ever to change. Rather than fixating on the MARID and MASS proposals as a means of deploying DNSEXT there are far more effective means available. For example, lets try to address the problem of DNS spoofing without insisting on resort to crypto. All that is really needed is a somewhat longer response cookie. So we create a DNS query that is defined to result in the query data being returned. Everyone who deploys MASS and MARID is going to want that capability to talk to accreditation services. The value of DNSSEC is going to come in authenticating policy publication, in particular security policy such as MASS, MARID and others to come in the future. Phill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Oct 18 14:41:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11034 for <dnsext-archive@lists.ietf.org>; Mon, 18 Oct 2004 14:41:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CJcPC-000EhX-QW for namedroppers-data@psg.com; Mon, 18 Oct 2004 18:38:50 +0000 Received: from [66.45.230.132] (helo=spike.gnomon.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CJcP0-000EgC-Po for namedroppers@ops.ietf.org; Mon, 18 Oct 2004 18:38:39 +0000 Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i9IIl4ws028586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <namedroppers@ops.ietf.org>; Mon, 18 Oct 2004 18:47:09 GMT (envelope-from roy+dated+1100716711.f9216d@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i9IIcVoV083663 for <namedroppers@ops.ietf.org>; Mon, 18 Oct 2004 19:38:31 +0100 (BST) (envelope-from roy+dated+1100716711.f9216d@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i9IIcVtm083662 for namedroppers@ops.ietf.org; Mon, 18 Oct 2004 19:38:31 +0100 (BST) (envelope-from roy+dated+1100716711.f9216d@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Mon, 18 Oct 2004 19:38:15 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16756.3478.675039.839347@giles.gnomon.org.uk> Date: Mon, 18 Oct 2004 19:38:14 +0100 To: Ted Hardie <hardie@qualcomm.com> Cc: "Hallam-Baker, Phillip" <pbaker@verisign.com>, "'Robert Elz'" <kre@munnari.oz.au>, Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org Subject: RE: I-D ACTION:draft-iab-dns-choices-00.txt In-Reply-To: <p06110403bd99b2b48271@[129.46.227.161]> References: <C6DDA43B91BFDA49AA2F1E473732113E010BECA2@mou1wnexm05.vcorp.ad.vrsn.com> <p06110403bd99b2b48271@[129.46.227.161]> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami <roy@gnomon.org.uk> X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Ted" == Ted Hardie <hardie@qualcomm.com> writes: Ted> I believe the fundamental reason these folks chose TXT was Ted> that existing libraries understood TXT records well enough. Ted> The ease of parsing these records was the second factor, Ted> again, in my opinion. My understanding is that the SPF folks chose TXT because of problems with some widely-deployed DNS servers and proxy firewalls that don't support unknown record types, and also to allow records to be published by people using ISP-hosted DNS with a web-based management interface (which typically will not provide any way to create unknown record types). -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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Oct 18 14:47:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11793 for <dnsext-archive@lists.ietf.org>; Mon, 18 Oct 2004 14:47:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CJcVL-000FcJ-5S for namedroppers-data@psg.com; Mon, 18 Oct 2004 18:45:11 +0000 Received: from [64.233.170.204] (helo=mproxy.gmail.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CJcVH-000FWU-7x for namedroppers@ops.ietf.org; Mon, 18 Oct 2004 18:45:07 +0000 Received: by mproxy.gmail.com with SMTP id 79so228639rnl for <namedroppers@ops.ietf.org>; Mon, 18 Oct 2004 11:45:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=Fs/VDRsErjHFMWKj81HWfWoce3YKUyXkJfLZr/CMAX/NPmMZuRXbQyTPrbyTi9I+wdO7JRaYpzCNOTVTHWAAVvOxLrxs/T2Vvm0PylnnVfScy4XH/wkyP4pbvbjbwUmXoXl+FoFrjURC6v2weTJkWIrcQoDhWUNNNhiTNgnePug Received: by 10.38.77.61 with SMTP id z61mr1662829rna; Mon, 18 Oct 2004 11:45:06 -0700 (PDT) Received: by 10.38.79.29 with HTTP; Mon, 18 Oct 2004 11:45:06 -0700 (PDT) Message-ID: <2bcdc7c404101811451a456942@mail.gmail.com> Date: Mon, 18 Oct 2004 11:45:06 -0700 From: James Snell <jasnell@gmail.com> Reply-To: James Snell <jasnell@gmail.com> To: namedroppers@ops.ietf.org Subject: I-D ACTION:draft-iab-dns-choices-00.txt In-Reply-To: <2bcdc7c404101811431f4137b8@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <C6DDA43B91BFDA49AA2F1E473732113E010BECA2@mou1wnexm05.vcorp.ad.vrsn.com> <p06110403bd99b2b48271@129.46.227.161> <2bcdc7c404101811431f4137b8@mail.gmail.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 18 Oct 2004 10:59:26 -0700, Ted Hardie <hardie@qualcomm.com> wrote: > I believe the fundamental reason these folks chose TXT was that > existing libraries understood TXT records well enough. The > ease of parsing these records was the second factor, again, > in my opinion. I can collaborate this thought. In a couple of days a new I-D should be published that describes a couple of new resource record types we've been working on. In our initial passes at these records we had intended to use TXT records precisely for the reasons given above. We ultimately decided against their use because of the problems inherent in their ambiguity. It simply made more sense to create specific record types to handle the data we needed, despite the process required to get those types officially allocated. For our private work-in-progress prototype implementations of the I-D, we have chosen two numbers from the private range. -- - James Snell IBM, Emerging Technologies jasnell@gmail.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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Oct 18 15:06:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13618 for <dnsext-archive@lists.ietf.org>; Mon, 18 Oct 2004 15:06:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CJcmC-000IUD-Nf for namedroppers-data@psg.com; Mon, 18 Oct 2004 19:02:36 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CJclu-000IRq-Ia for namedroppers@ops.ietf.org; Mon, 18 Oct 2004 19:02:19 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 4C593C2DA4; Mon, 18 Oct 2004 20:02:13 +0100 (BST) Date: Mon, 18 Oct 2004 20:02:06 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: Edward Lewis <Ed.Lewis@neustar.biz>, namedroppers@ops.ietf.org Cc: Alex Bligh <alex@alex.org.uk> Subject: Re: wcard draft out there... Message-ID: <C698988A96218261329BA647@[192.168.100.25]> In-Reply-To: <a06110401bd9975bf2a08@[192.35.166.53]> References: <a06110401bd9975bf2a08@[192.35.166.53]> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,BIZ_TLD autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 18 October 2004 09:35 -0400 Edward Lewis <Ed.Lewis@neustar.biz> wrote: > I'd like to be able to refresh the draft by the deadline - if not just to > update the editor contact info - so comments would be appreciated this > week. Comments included below as a diff - almost entirely typographical or orthographical. I have added a couple of extra examples or explanations when it wasn't immediately obvious to me which point the example was making - and by dint of that you should check them! Alex --- wcard-clarify Mon Oct 18 18:51:06 2004 +++ wcard-clarify-amb Mon Oct 18 19:56:01 2004 @@ -1,3 +1,6 @@ +Inconsistent use of "RR's" and "RRs" throughout document + + DNSEXT Working Group E. Lewis INTERNET DRAFT NeuStar Expiration Date: April 2005 October 2004 @@ -57,15 +60,15 @@ 1.1 Motivation Over time many implementations have diverged in different ways from - the original definition, or at least what had been intended. Although + the original definition, or at least from what had been intended. Although there is clearly a need to clarify the original documents in light of this, the impetus for this document lay in the engineering of the DNS security extensions [RFC TBD]. With an unclear definition - of wildcards the design of authenticated denial became entangled. + of wildcards, the design of authenticated denial became entangled. Although this document is motivated by DNSSEC and the need to have a separate document passed for the sake of DNSSEC, other - motivations have risen. The renewed understanding of wildcards gained + motivations have arisen. The renewed understanding of wildcards gained is worthy of being documented. 1.2 The Original Definition @@ -95,15 +98,17 @@ is clearly defined to be a resource record. In the next sentence the term is shifted to be an adjective, the first step on the path to overloading the term. Wildcard has also been used to - refer to domain names that begin with a "*". + refer to domain names whose first (i.e. left most or least + significant) label consists of a "*". 1.3 The Clarification - The clarification effort can be divided into three sections. One - is the use of new terminology to better describe wildcards. Changes - to words in RFC 1034 that have resulted by discovering conflicting - concepts are presented. Descriptions of special type records in the - context of being wildcards is discussed. + The clarification effort can be divided into three sections: + 1. the use of new terminology to describe wildcards better; + 2. changes to words in RFC 1034 that have resulted from discovering + conflicting concepts; and + 3. descriptions of special type records in the context of being + wildcards is. 1.3.1 New Terms @@ -137,14 +142,21 @@ 1034. A summary of the changes appear next and will be fully covered in later sections. + Note that labels other than the Asterisk Label which contain + asterisks have no special significance or terminology in this + document; thus the fact that a domain names starts with an + asterisk is also of no special significance (and has no special + terminology) unless its first label is the Asterisk Label, i.e. + "*foo.example.com" has no special significance). + 1.3.2 Changed Text The definition of "existence" is changed, superficially, to exclude empty domains that have no subdomains with resource records. This - change will not be apparent to implementations, it is needed to + change will not be apparent to implementations; it is needed to make descriptions more concise. - In RFC 1034, there is text that seems to bar having two Asterisk + In RFC 1034, there is text that seems to prohibit having two Asterisk Labels in a Wild Card Domain Name. There is no further discussion, no prescribed error handling, nor enforcement described. In this document, the use of such names will be discouraged, but implementations @@ -159,13 +171,13 @@ This clarification will describe in some detail the semantics of wildcard CNAME RRs, wildcard NS RRs, wildcard SOA RR's, - wildcard DNAME RRs [RFC wxyz], and empty, non-terminal wildcards. + wildcard DNAME RRs [RFC wxyz], and empty non-terminal wildcards. Understanding these types in the context of wildcards has been clouded because these types incur special processing if they are the result of an exact match. By the definition in RFC 1034, there can be no empty, non-terminal - "wildcards", but in the algorithm, it is possible that an empty + "wildcards". However, in the algorithm, it is possible that an empty non-terminal is sought as the potential owner of a "wildcard." This is one example of why the ordering of the discussion in RFC 1034 is confusing. @@ -191,10 +203,10 @@ Tackling the latter first, there are two objectives in defining a means to identify a resource record set as a source of synthesis. - First is the desire to maintain all DNS data in a consistent manner. - Avoiding the need for implementations to have many internal data - structures is a good thing. Not that this means limiting quantity, - but rather types of data. The second objective impacts interoperability, + First, the desire to maintain all DNS data in a consistent manner: + avoiding the need for implementations to have many internal data + structures is a good thing, i.e. limiting the number of types of + data (as opposed to quantity of data). The second objective impacts interoperability, that is a master server of one implementation has to be able to send the synthesis instructions to the slaves. Although there are alternatives to the use of zone transfers via port 53, a truly @@ -213,7 +225,8 @@ 2.1.1 Wild Card Domain Name and Asterisk Label - A "Wild Card Domain Name" is defined by having its initial label be: + A "Wild Card Domain Name" is defined by having its initial + (i.e. left-most, or least significant) label being: 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal) @@ -224,7 +237,7 @@ character encoding. A descriptive name of a label equaling that value is an "Asterisk - Label." + Label.". RFC 1034's definition of wildcard would be "a resource record owned by a Wild Card Domain Name." This is mentioned to help maintain some @@ -235,6 +248,9 @@ 2.1.2 Variations on Wild Card Domain Names + Labels other than the Asterisk Label which contain the + ASCII representation of the asterisk (0x2a) have no significance + for the purposes of this document. RFC 1034 and RFC 1035 do not explicitly mention the case in which a domain name might be something like "the*.example.com." The interpretation is that this domain name in a zone would only match @@ -248,13 +264,22 @@ [Ed note: the above paragraph reads too strong. The intent ought to be that such names do not fall under the rules of wildcards. The intent is not to bar any future attempts to define other forms of - synthesis - nor is the intent to encourage them.] - - The interpretation of a wild card domain specification which is not a - leaf domain is not clearly defined in RFC 1034. E.g., sub.*.example., + synthesis - nor is the intent to encourage them. + AB - I thought it's OK but perhaps the addition of the first + sentence suggested puts it into context - i.e. nothing to do with us] + + The interpretation of a domain name containing an Asterisk Label otherwise + than as a leaf domain is not clearly defined in RFC 1034. + [AB - you have defined Wild card domain name to be the case where it *is* + a leaf so previously this was a contradiction in terms] + E.g., sub.*.example.com., is not discussed, not barred. In wanting to minimize changes from the original specification, such names are permitted. Although - "sub.*.example." is not a Wild Card Domain Name, "*.example." is. + "sub.*.example.com." is not a Wild Card Domain Name, "*.example.com." is, + as are "*.sub.*.example.com.", and "*.*.example.com." (though for + the latter two cases see 2.1.3 below). + [AB - Right? Per your definition above, they are still Wild Card Domain + Names notwithstanding 2.1.3]. RRSets used to synthesize records can be owned by a Wild Card Domain Name that has subdomains. @@ -287,6 +312,11 @@ (See the upcoming sections on empty non-terminals.) In this case, the lookup will terminate as would any empty non-terminal match. + Similarly, both server and resolver implementations ought to accept domain names with + Asterisk Labels in positions other than the left most (least significant) + label though they should not attribute any special meaning to such + labels. + 2.2 Existence Rules The notion that a domain name 'exists' arises numerous times in @@ -345,7 +375,7 @@ | | _ssh _ssh - The following queries would be synthesized from the wild card: + The following queries would be synthesized from one of the wild cards: QNAME=host3.example. QTYPE=MX, QCLASS=IN the answer will be a "host3.example. IN MX ..." @@ -360,7 +390,7 @@ the answer will be "foo.bar.example. IN TXT ..." because bar.example. does not exist, but the wildcard does. - The following queries would not be synthesized from the wild card: + The following queries would not be synthesized from either wild card: QNAME=host1.example., QTYPE=MX, QCLASS=IN because host1.example. exists @@ -385,7 +415,7 @@ 2.2.2 Empty Non-terminals Empty non-terminals are domain names that own no resource records but - have subdomains which do. This is defined in section 3.1 of RFC 1034: + have subdomains that do. This is defined in section 3.1 of RFC 1034: # The domain name space is a tree structure. Each node and leaf on the # tree corresponds to a resource set (which may be empty). The domain @@ -449,7 +479,7 @@ When a Wild Card Domain Name appears in a message's query section, no special processing occurs. Asterisk Labels in such a context - only Label Matches other Asterisk Labels in the existing zone tree + only Label Matche other Asterisk Labels in the existing zone tree when the 4.3.2 algorithm is being followed. When a Wild Card Domain Name appears in the resource data of a @@ -468,7 +498,7 @@ There is a documentation issue deserving some explanation. The algorithm in RFC 1034, section 4.3.2. is not intended to be pseudo - code, i.e., it's steps are not intended to be followed in strict + code, i.e., its steps are not intended to be followed in strict order. The "algorithm" is a suggestion. As such, in step 3, parts a, b, and c, do not have to be implemented in that order. @@ -496,40 +526,41 @@ There are two reasons to repeat this. One is that this means all of step 3 is done within the context of a zone, which will constrain the discussion. The other is the though behind synthesizing entire - zones and the use of Wild Card Domain Names to do so. + zones and the use of Wild Card Domain Names to do so. [This sentence + makes no sense - I think there's a word missing - AB] 3.2 Step 3 - Step 3 is dominated by three parts, labelled a, b, and c. But the + Step 3 is dominated by three parts, labelled 'a', 'b', and 'c'. But the beginning of the Step is important and needs explanation. # 3. Start matching down, label by label, in the zone. The # matching process can terminate several ways: - The word matching in this care refers to Label Matching. The concept + The word matching in this case refers to Label Matching. The concept is based in the view of the zone as the tree of existing names. The Query Name is considered to be an ordered sequence of labels - as if the name were a path from the root to the owner of the desired data. The process of Label Matching ends in one of three choices, the parts - a, b, and c. Once one of the parts is chosen, the other parts are + 'a', 'b', and 'c'. Once one of the parts is chosen, the other parts are not considered. (E.g., do not execute part c and then change the - execution path to finish in part b.) The process of Label Matching - is also done independent of the Query Type. + execution path to finish in part 'b'.) The process of Label Matching + is also done independently of the Query Type. - Parts a and b are not an issue for this clarification as they do not - relate to record synthesis. Part a generally covers a situation in + Parts 'a' and 'b' are not an issue for this clarification as they do not + relate to record synthesis. Part 'a' generally covers a situation in which all of the labels in the search (query) name have been matched - down the tree, e.g., the sought name exists as an exact Label Match. - Part b generally covers a situation in which any label in the sought - name Label Matches a tree label and the tree label has a NS RRSet. + down the tree, e.g., the name being sought exists as an exact Label Match. + Part 'b' generally covers a situation in which any label in the name being + sought Label Matches a tree label, and the tree label has a NS RRSet. 3.3 Part 'c' The context of part 'c' is that the process of Label Matching the - labels in the sought name has resulted in a situation in which there - is nothing corresponding in the tree. It is as if the lookup has + labels in the name being sought has resulted in a situation in which there + is no corresponding entry in the tree. It is as if the lookup has "fallen off the tree." # c. If at some label, a match is impossible (i.e., the @@ -546,34 +577,36 @@ The "Closest Encloser" is the node in the zone's tree of existing domain names that is has the most matching labels with the sought name. Each match is a "Label Match" and the order of the labels - is also the same. The Closest Encloser is an existing name in the - zone, it may be an empty non-terminal, it may even be a Wild Card + is also the same. The Closest Encloser is by definition an existing name in the + zone. It may be an empty non-terminal. It may even be a Wild Card Domain Name itself. In no circumstances is the Closest Encloser - the used to synthesize records though. + used to synthesize records though. A "Source of Synthesis" is defined in the context of a lookup process as the Wild Card Domain Name immediately descending from - the Closest Encloser provided the Wild Card Domain Name exists. + the Closest Encloser, provided the Wild Card Domain Name exists. + If the Wild Card Domain Name does not exist, there is no + Source of Synthesis. [AB: Correct?] A Source of Synthesis does not guarantee having a RRSet to use - for synthesis, a Source of Synthesis may even be an empty + for synthesis; a Source of Synthesis may even be an empty non-terminal. If a Source of Synthesis exists, it will be the Wild Card Domain Name that is identified by an Asterisk Label below the Closest Encloser. E.g., "<Asterisk Label>.<Closest Encloser> or "*.<Closest Encloser>." If the Source of Synthesis does not exist (not on the domain tree), - there will be no wildcard synthesis + there will be no wildcard synthesis. The important concept is that for any given lookup process, there is at most one place at which wildcard synthetic records can be obtained. If the Source of Synthesis does not exist, the lookup - terminates, the lookup does not look for other wildcard records. + terminates; the lookup does not look for other wildcard records. Other terms have been coined on the mailing list in the past. E.g., it has been said that existing names block the application of wildcard records. This is still an appropriate viewpoint, but replacing this notion with the Closest Encloser and Source of - Synthesis the depiction of the wildcard process is clearer. + Synthesis terminology depicts the wildcard process more clearly. 3.3.2 Closest Encloser and Source of Synthesis Examples @@ -593,6 +626,7 @@ The fact that a closest encloser will be the only superdomain that can have a candidate wild card will have an impact when it comes to designing pre-calculated authenticated denial of existence proofs. + [Insert Reference to DNSSEC-bis] 3.3.3 Non-existent Source of Synthesis @@ -613,7 +647,7 @@ 3.3.4 Type Matching - RFC 1034 concludes part c with this: + RFC 1034 concludes part 'c' with this: # If the "*" label does exist, match RRs at that node # against QTYPE. If any match, copy them into the answer @@ -623,15 +657,15 @@ This final paragraph covers the role of the QTYPE in the lookup process. - Based on implementation feedback and similarities between step a and - step c a change to this passage a change has been made. + Based on implementation feedback and similarities between step 'a' and + step 'c', a change to this passage a change has been made. The change is to add the following text: If the data at the source of synthesis is a CNAME, and QTYPE doesn't match CNAME, copy the CNAME RR into the answer section of the response changing the owner name - to the QNAME, change QNAME to the canonical name in the + to the QNAME, change QNAME to the canonical name in the CNAME RR, and go back to step 1. This is essentially the same text in step a covering the processing of @@ -663,10 +697,13 @@ Domain Name is if the QNAME is in a domain below the zone's name. E.g., if *.example. has an SOA record, then only a query like - QNAME=*.example., QTYPE=A, QCLASS=IN would see it. As another + QNAME=*.example., QTYPE=A, QCLASS=IN would see it. QNAME=*.example.com, QTYPE=SOA, QLASS=IN + would also see the SOA record, but QNAME=foo.example.com, QTYPE=SOA, QCLASS=IN + would not. As another example, a QNAME of www.*.example. would also result in passing through the zone. + 4.2. NS RR's at a Wild Card Domain Name @@ -697,6 +734,9 @@ to consider the name delegated away. I.e., the server is not synthesizing a record (the NS RRSet) that means the server does not have the right to synthesize. + + [I think it would be useful to comment that thus NS RR's are + unlikely to work as expected, which is (I think) the case - AB] 4.3. CNAME RR's at a Wild Card Domain 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Oct 18 15:24:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15785 for <dnsext-archive@lists.ietf.org>; Mon, 18 Oct 2004 15:24:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CJd4i-000M5i-D3 for namedroppers-data@psg.com; Mon, 18 Oct 2004 19:21:44 +0000 Received: from [192.150.250.67] (helo=fuchsia.home) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CJd4g-000M5S-8u for namedroppers@ops.ietf.org; Mon, 18 Oct 2004 19:21:43 +0000 Received: from delta.noi.kre.to (delta.wi0.home [192.168.192.32]) by fuchsia.home with ESMTP id i9IJLYIj013875; Tue, 19 Oct 2004 02:21:35 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i9IJLRJV000868; Tue, 19 Oct 2004 02:21:28 +0700 (ICT) From: Robert Elz <kre@munnari.OZ.AU> To: "Hallam-Baker, Phillip" <pbaker@verisign.com> cc: "'Alex Bligh'" <alex@alex.org.uk>, namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-iab-dns-choices-00.txt In-Reply-To: <C6DDA43B91BFDA49AA2F1E473732113E010BECA0@mou1wnexm05.vcorp.ad.vrsn.com> References: <C6DDA43B91BFDA49AA2F1E473732113E010BECA0@mou1wnexm05.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Oct 2004 02:21:27 +0700 Message-ID: <13712.1098127287@munnari.OZ.AU> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Mon, 18 Oct 2004 10:07:47 -0700 From: "Hallam-Baker, Phillip" <pbaker@verisign.com> Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BECA0@mou1wnexm05.vcorp.ad.vrsn.com> | > By which I mean is it not possible to | > a) On a strictly conformant server, emulate *? with a macro | > (or similar), | | All that is required is to document the wildcard usage and to define | an interchange format for it so that it can be used in zone transfers | and an appropriate NXT/NSEC usage. The point is that there's no need for that - if we know what names exist (which seems to be the case "people" actually want) then it's trivial to pre-process the zone file and include whatever records that are wanted. That is, the only issue here is saving typing time in the zone file, which is a fine goal, but needs exactly no changes to the DNS to satisfy (doesn't even require changes to DNS server implementations, all of this can be done with a preprocessor tool, perhaps something similar to the dns zone signer application(s)). | The same applies for mid-level wildcards, _marid.*.example.com. It is not | rocket science. When you start looking at the the corner cases that need to be dealt with to really make that work (cases which perhaps don't matter much to most practical uses, but which need to be defined if anything like this was to be added) you'll find that it isn't nearly as simple as it seems (to even just be explicit about what this is really intended to mean, let alone how to specify that precisely). 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Oct 18 15:47:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17291 for <dnsext-archive@lists.ietf.org>; Mon, 18 Oct 2004 15:47:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CJdPE-000P11-Ln for namedroppers-data@psg.com; Mon, 18 Oct 2004 19:42:56 +0000 Received: from [65.205.251.75] (helo=robin.verisign.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CJdP2-000P0N-Ta for namedroppers@ops.ietf.org; Mon, 18 Oct 2004 19:42:44 +0000 Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i9IJgeoX026818; Mon, 18 Oct 2004 12:42:40 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <VCCW92JH>; Mon, 18 Oct 2004 12:42:40 -0700 Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BECA9@mou1wnexm05.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" <pbaker@verisign.com> To: "'Robert Elz'" <kre@munnari.OZ.AU>, "Hallam-Baker, Phillip" <pbaker@verisign.com> Cc: "'Alex Bligh'" <alex@alex.org.uk>, namedroppers@ops.ietf.org Subject: RE: I-D ACTION:draft-iab-dns-choices-00.txt Date: Mon, 18 Oct 2004 12:42:37 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > The point is that there's no need for that - if we know what > names exist > (which seems to be the case "people" actually want) then it's trivial > to pre-process the zone file and include whatever records > that are wanted. Robert, We are in violent agreement here. I believe that there is not, nor ever has been a requirement for wildcards to support the prefix modes. The only requirement in this regard that has been raised is satisfied by MACROS which do not require any change to the infrastructure. If we keep in mind the wildcard/macros distinction everything starts to work out fine. -- to 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/> From owner-namedroppers@ops.ietf.org Mon Oct 18 16:26:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20174 for <dnsext-archive@lists.ietf.org>; Mon, 18 Oct 2004 16:26:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CJe2Z-0005BT-Cf for namedroppers-data@psg.com; Mon, 18 Oct 2004 20:23:35 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CJe2W-0005Ai-8A for namedroppers@ops.ietf.org; Mon, 18 Oct 2004 20:23:34 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id i9IKMxKa026796; Mon, 18 Oct 2004 20:23:04 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id i9IKMn6o026791; Mon, 18 Oct 2004 20:22:49 GMT Date: Mon, 18 Oct 2004 20:22:49 +0000 From: bmanning@vacation.karoshi.com To: "Hallam-Baker, Phillip" <pbaker@verisign.com> Cc: "'Ted Hardie'" <hardie@qualcomm.com>, "'Robert Elz'" <kre@munnari.oz.au>, Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-iab-dns-choices-00.txt Message-ID: <20041018202249.GC26518@vacation.karoshi.com.> References: <C6DDA43B91BFDA49AA2F1E473732113E010BECA8@mou1wnexm05.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <C6DDA43B91BFDA49AA2F1E473732113E010BECA8@mou1wnexm05.vcorp.ad.vrsn.com> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > The value of DNSSEC is going to come in authenticating policy > publication, in particular security policy such as MASS, MARID > and others to come in the future. > > > Phill clearly you and i do not share a common perception of value wrt DNSSEC. one may reasonably ask if we are two of the blind men trying to describe an elephant. --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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Oct 18 16:32:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17290 for <dnsext-archive@lists.ietf.org>; Mon, 18 Oct 2004 15:47:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CJdQc-000PBQ-7f for namedroppers-data@psg.com; Mon, 18 Oct 2004 19:44:22 +0000 Received: from [192.150.250.67] (helo=fuchsia.home) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CJdQN-000P8u-VY for namedroppers@ops.ietf.org; Mon, 18 Oct 2004 19:44:09 +0000 Received: from delta.noi.kre.to (delta.wi0.home [192.168.192.32]) by fuchsia.home with ESMTP id i9IJi8Ij016078; Tue, 19 Oct 2004 02:44:08 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i9IJi1JV009365; Tue, 19 Oct 2004 02:44:02 +0700 (ICT) From: Robert Elz <kre@munnari.OZ.AU> To: "Hallam-Baker, Phillip" <pbaker@verisign.com> cc: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-iab-dns-choices-00.txt In-Reply-To: <C6DDA43B91BFDA49AA2F1E473732113E010BECA2@mou1wnexm05.vcorp.ad.vrsn.com> References: <C6DDA43B91BFDA49AA2F1E473732113E010BECA2@mou1wnexm05.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Oct 2004 02:44:01 +0700 Message-ID: <4452.1098128641@munnari.OZ.AU> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Mon, 18 Oct 2004 10:35:09 -0700 From: "Hallam-Baker, Phillip" <pbaker@verisign.com> Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BECA2@mou1wnexm05.vcorp.ad.vrsn.com> | Names such as _MARID.example.com are unusable for DNS as machine | names. That's simply wrong to start with, there are a few protocols that forbid such names, but for most just about anything goes. And quite apart from that, who says what I am putting in my domain is machine names - it is mine, I'll put there whatever I want to put there. | Christian is making an important point. The reason SPF is written | to the bare TXT record without a prefix is that the people behind | it had no way to get themselves a RR without waiting for two years | before they could start deployment. Yes, that point of his I agree with, it is hard to get a new RR currently. Part of that problem, of course, is that no-one has really been willing to really trust that unknown RR types are really handled correctly by all the existing servers out there. 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Oct 18 16:58:04 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22683 for <dnsext-archive@lists.ietf.org>; Mon, 18 Oct 2004 16:58:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CJeVN-0009Gd-T2 for namedroppers-data@psg.com; Mon, 18 Oct 2004 20:53:21 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1CJeVG-0009Fe-Ug for namedroppers@ops.ietf.org; Mon, 18 Oct 2004 20:53:15 +0000 Received: (qmail 21608 invoked by uid 1016); 18 Oct 2004 20:53:34 -0000 Date: 18 Oct 2004 20:53:34 -0000 Message-ID: <20041018205334.21606.qmail@cr.yp.to> From: "D. J. Bernstein" <djb@cr.yp.to> To: namedroppers@ops.ietf.org Subject: Don't be fooled by draft-iab-dns-choices-00.txt References: <C6DDA43B91BFDA49AA2F1E473732113E010BECA2@mou1wnexm05.vcorp.ad.vrsn.com> <p06110403bd99b2b48271@[129.46.227.161]> <16756.3478.675039.839347@giles.gnomon.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Roy Badami writes: > My understanding is that the SPF folks chose TXT because of problems > with some widely-deployed DNS servers and proxy firewalls that don't > support unknown record types Yes. A huge fraction of the DNS deployments on the Internet are BIND versions that can't handle unknown record types. Every new record type immediately encounters massive interoperability failures. Removing those failures means updating BIND and waiting _years_ for BIND redeployment. (BIND 9.1.0 finally fixed this bug---but a May 2004 survey of *.com, *.net, *.org, *.info, and *.biz found 11 million second-level names published by servers running BIND 8. Redeployment takes a long time.) In contrast, TXT works. Yes, it requires coordination to avoid name clashes; yes, it has space limits; but at least it succeeds in distributing data to every interested client. ---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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Oct 18 18:04:58 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28610 for <dnsext-archive@lists.ietf.org>; Mon, 18 Oct 2004 18:04:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CJfW8-000H8f-V9 for namedroppers-data@psg.com; Mon, 18 Oct 2004 21:58:12 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CJfW8-000H8P-5a for namedroppers@ops.ietf.org; Mon, 18 Oct 2004 21:58:12 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 2B2A9677E9 for <namedroppers@ops.ietf.org>; Mon, 18 Oct 2004 21:58:10 +0000 (UTC) (envelope-from marka@drugs.dv.isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id i9ILw1dq025859; Tue, 19 Oct 2004 07:58:02 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200410182158.i9ILw1dq025859@drugs.dv.isc.org> To: "Hallam-Baker, Phillip" <pbaker@verisign.com> Cc: "'Alex Bligh'" <alex@alex.org.uk>, namedroppers@ops.ietf.org From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: I-D ACTION:draft-iab-dns-choices-00.txt In-reply-to: Your message of "Mon, 18 Oct 2004 10:07:47 MST." <C6DDA43B91BFDA49AA2F1E473732113E010BECA0@mou1wnexm05.vcorp.ad.vrsn.com> Date: Tue, 19 Oct 2004 07:58:01 +1000 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > -----Original Message----- > > From: Alex Bligh [mailto:alex@alex.org.uk] > On 15 October 2004 12:38 -0700 "Hallam-Baker, Phillip" > > <pbaker@verisign.com> wrote: > > > > > * The current wildcard, if www.example.com exists the > > > wildcard *.example.com will NOT match for ANY record. > > > > > > *? The wildcard people think they have and mostly want, > > > TXT/*.example.com will match iff www.example.com exists > > > but has no other TXT record. > > Does the latter (*?) actually need any protocol-level specification? > > > > By which I mean is it not possible to > > a) On a strictly conformant server, emulate *? with a macro > > (or similar), > > All that is required is to document the wildcard usage and to define > an interchange format for it so that it can be used in zone transfers > and an appropriate NXT/NSEC usage. > > The same applies for mid-level wildcards, _marid.*.example.com. It is not > rocket science. > > I find it objectionable that we have people saying that the only > alternatives that can be considered here are prefixes without > wildcards or waiting for DNSEXT to deploy. There has been a real > alternative on the table that makes prefixes work as well as > new RRs but with a significantly lower impact on the deployed > infrastructure. Only parties that need wildcards need to upgrade > their servers. What happens when you have a thousand such records for different protocols. You then have to find each and every potential LHS and try to match those against the query. THIS DOES NOT SCALE. > I propose that the draft authors be asked to address these issues. > > > -- > to 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/> -- Mark Andrews, ISC 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Oct 18 18:06:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28885 for <dnsext-archive@lists.ietf.org>; Mon, 18 Oct 2004 18:06:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CJfcy-000IEG-4J for namedroppers-data@psg.com; Mon, 18 Oct 2004 22:05:16 +0000 Received: from [65.205.251.75] (helo=robin.verisign.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CJfcx-000IDy-Ah for namedroppers@ops.ietf.org; Mon, 18 Oct 2004 22:05:15 +0000 Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i9IM5652006605; Mon, 18 Oct 2004 15:05:10 -0700 (PDT) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <476CW7YC>; Mon, 18 Oct 2004 15:05:06 -0700 Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BECAB@mou1wnexm05.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" <pbaker@verisign.com> To: "'Mark Andrews'" <Mark_Andrews@isc.org>, "Hallam-Baker, Phillip" <pbaker@verisign.com> Cc: "'Alex Bligh'" <alex@alex.org.uk>, namedroppers@ops.ietf.org Subject: RE: I-D ACTION:draft-iab-dns-choices-00.txt Date: Mon, 18 Oct 2004 15:05:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,UPPERCASE_25_50 autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > What happens when you have a thousand such records for > different protocols. You then have to find each and every > potential LHS and try to match those against the query. > > THIS DOES NOT SCALE. Of course it does, same way it works for any other DNS zone with a thousand entries. WRITING IN CAPITALS DOES NOT CONSTITUTE AN ARGUMENT. -- to 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/> From owner-namedroppers@ops.ietf.org Mon Oct 18 18:15:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29823 for <dnsext-archive@lists.ietf.org>; Mon, 18 Oct 2004 18:15:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CJfl5-000JLx-Ie for namedroppers-data@psg.com; Mon, 18 Oct 2004 22:13:39 +0000 Received: from [65.205.251.74] (helo=colibri.verisign.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CJfl4-000JLe-Qb for namedroppers@ops.ietf.org; Mon, 18 Oct 2004 22:13:38 +0000 Received: from mou1wnexc02.vcorp.ad.vrsn.com (mailer5.verisign.com [65.205.251.54]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i9IMDZwO004243; Mon, 18 Oct 2004 15:13:35 -0700 (PDT) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <VDJ2P4WF>; Mon, 18 Oct 2004 15:13:35 -0700 Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BECAC@mou1wnexm05.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" <pbaker@verisign.com> To: "'bmanning@vacation.karoshi.com'" <bmanning@vacation.karoshi.com>, "Hallam-Baker, Phillip" <pbaker@verisign.com> Cc: "'Ted Hardie'" <hardie@qualcomm.com>, "'Robert Elz'" <kre@munnari.oz.au>, Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org Subject: RE: I-D ACTION:draft-iab-dns-choices-00.txt Date: Mon, 18 Oct 2004 15:13:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Bill writes: > > The value of DNSSEC is going to come in authenticating policy > > publication, in particular security policy such as MASS, MARID > > and others to come in the future. > > > > clearly you and i do not share a common perception of > value wrt DNSSEC. one may reasonably ask if we are two > of the blind men trying to describe an elephant. Not necessarily, I was referring to the killer application for DNSSEC which is not necessarily the same as the main use it eventually finds. A killer application is the one that creates the demand to build infrastructure. Word processing was NOT the killer app for the PC, the spreadsheet was. No manager would touch a keyboard in the 80s, certainly not to type their own correspondence. The first PCs were bought to do engineering spreadsheets. The opportunity to establish a killer app is a narrow one. Having blown opportunity after opportunity securing policy is the next killer app opportunity that will be open for the next 18 months or so. If you try to sell DNSSEC as spoof protection at this point you are not addressing a currently visible pain point and will not get on network managers radar screens. -- to 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/> From owner-namedroppers@ops.ietf.org Mon Oct 18 18:35:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01385 for <dnsext-archive@lists.ietf.org>; Mon, 18 Oct 2004 18:35:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CJg2m-000Lfv-MF for namedroppers-data@psg.com; Mon, 18 Oct 2004 22:31:56 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CJg2l-000Lfi-T8 for namedroppers@ops.ietf.org; Mon, 18 Oct 2004 22:31:55 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id A14DC13E14 for <namedroppers@ops.ietf.org>; Mon, 18 Oct 2004 22:31:55 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-iab-dns-choices-00.txt In-Reply-To: Message from Roy Badami <roy@gnomon.org.uk> of "Mon, 18 Oct 2004 19:38:14 +0100." <16756.3478.675039.839347@giles.gnomon.org.uk> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 18 Oct 2004 22:31:55 +0000 Message-Id: <20041018223155.A14DC13E14@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > My understanding is that the SPF folks chose TXT because of problems > with some widely-deployed DNS servers and proxy firewalls that don't > support unknown record types, and also to allow records to be > published by people using ISP-hosted DNS with a web-based management > interface (which typically will not provide any way to create unknown > record types). nothing so grand. he originally chose TXT because he didn't know any better, and by the time he got any help, there was already both code and data deployed that made TXT hard to change. only microsoft could have forced a mind-change or format-change, and they (microsoft) blew their chance due to IPR policies. plz don't make this sound more complicated, or more considered, than 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Oct 18 19:29:04 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05772 for <dnsext-archive@lists.ietf.org>; Mon, 18 Oct 2004 19:29:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CJgsz-0001xA-3f for namedroppers-data@psg.com; Mon, 18 Oct 2004 23:25:53 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CJgsy-0001wx-7d for namedroppers@ops.ietf.org; Mon, 18 Oct 2004 23:25:52 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 5B7EC677E3 for <namedroppers@ops.ietf.org>; Mon, 18 Oct 2004 23:25:51 +0000 (UTC) (envelope-from marka@drugs.dv.isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id i9INPhtf074117; Tue, 19 Oct 2004 09:25:44 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200410182325.i9INPhtf074117@drugs.dv.isc.org> To: "Hallam-Baker, Phillip" <pbaker@verisign.com> Cc: "'Alex Bligh'" <alex@alex.org.uk>, namedroppers@ops.ietf.org From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: I-D ACTION:draft-iab-dns-choices-00.txt In-reply-to: Your message of "Mon, 18 Oct 2004 15:05:01 MST." <C6DDA43B91BFDA49AA2F1E473732113E010BECAB@mou1wnexm05.vcorp.ad.vrsn.com> Date: Tue, 19 Oct 2004 09:25:43 +1000 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > > What happens when you have a thousand such records for > > different protocols. You then have to find each and every > > potential LHS and try to match those against the query. > > > > THIS DOES NOT SCALE. > > Of course it does, same way it works for any other DNS zone > with a thousand entries. > > WRITING IN CAPITALS DOES NOT CONSTITUTE AN ARGUMENT. Well the firsting you have to get agreement on is how many labels does * match in a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.*.example.net A 127.0.0.1 a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.*.example.net A 127.0.0.2 a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.*.example.net A 127.0.0.3 a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.*.example.net A 127.0.0.4 a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.*.example.net A 127.0.0.5 a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.*.example.net A 127.0.0.6 a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.*.example.net A 127.0.0.7 a.a.a.a.a.a.a.a.a.a.a.a.a.a.*.example.net A 127.0.0.8 a.a.a.a.a.a.a.a.a.a.a.a.a.*.example.net A 127.0.0.10 a.a.a.a.a.a.a.a.a.a.a.a.*.example.net A 127.0.0.11 a.a.a.a.a.a.a.a.a.a.a.*.example.net A 127.0.0.12 a.a.a.a.a.a.a.a.a.a.*.example.net A 127.0.0.13 a.a.a.a.a.a.a.a.a.*.example.net A 127.0.0.14 a.a.a.a.a.a.a.a.*.example.net A 127.0.0.15 a.a.a.a.a.a.a.*.example.net A 127.0.0.16 a.a.a.a.a.a.*.example.net A 127.0.0.17 a.a.a.a.a.*.example.net A 127.0.0.19 a.a.a.a.*.example.net A 127.0.0.20 a.a.a.*.example.net A 127.0.0.21 a.a.*.example.net A 127.0.0.22 a.*.example.net A 127.0.0.24 *.example.net A 127.0.0.25 with a query of a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.example.net is it *.example.net A 127.0.0.25 or a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.*.example.net A 127.0.0.1 or a random one from above or all of them .... Allowing * to expand in the middle creates large search spaces. -- Mark Andrews, ISC 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Oct 18 19:33:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06013 for <dnsext-archive@lists.ietf.org>; Mon, 18 Oct 2004 19:33:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CJgyj-0002aH-1D for namedroppers-data@psg.com; Mon, 18 Oct 2004 23:31:49 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CJgyi-0002Zz-38 for namedroppers@ops.ietf.org; Mon, 18 Oct 2004 23:31:48 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id i9INVAKa027310; Mon, 18 Oct 2004 23:31:25 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id i9INUoJs027304; Mon, 18 Oct 2004 23:30:50 GMT Date: Mon, 18 Oct 2004 23:30:49 +0000 From: bmanning@vacation.karoshi.com To: "Hallam-Baker, Phillip" <pbaker@verisign.com> Cc: "'bmanning@vacation.karoshi.com'" <bmanning@vacation.karoshi.com>, "'Ted Hardie'" <hardie@qualcomm.com>, "'Robert Elz'" <kre@munnari.oz.au>, Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-iab-dns-choices-00.txt Message-ID: <20041018233049.GB27162@vacation.karoshi.com.> References: <C6DDA43B91BFDA49AA2F1E473732113E010BECAC@mou1wnexm05.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <C6DDA43B91BFDA49AA2F1E473732113E010BECAC@mou1wnexm05.vcorp.ad.vrsn.com> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Hallam-Baker, Phillip wrote: > > Bill writes: > > > Hallam-Baker, Phillip wrote: > > > The value of DNSSEC is going to come in authenticating policy > > > publication, in particular security policy such as MASS, MARID > > > and others to come in the future. > > > > clearly you and i do not share a common perception of > > value wrt DNSSEC. one may reasonably ask if we are two > > of the blind men trying to describe an elephant. > > The opportunity to establish a killer app is a narrow one. Having > blown opportunity after opportunity securing policy is the next > killer app opportunity that will be open for the next 18 months > or so. again, you see this elephant differently. i'm not persuaded that the DNS is the right place to encode policy...(Hey.. lets reuse TXT for that!!!) although it is a where it might be done (and $DEITY knows I've tried, ref: RIDE, IRRd, RPSL in the DNS, et.al. from the previous decade) - pretending that DNSSEC would be able to authenticate such a publication method or to "secure policy" requires that you share more information about your presumptions on DNSSEC capabilities. to paraphrase an old saying; "I hope you brought enough drugs for the whole class". Or maybe I'm just too slow to keep up? Perhaps you might take this offline and help me understand what you are trying to acheive here? > If you try to sell DNSSEC as spoof protection at this point you > are not addressing a currently visible pain point and will not > get on network managers radar screens. thats not the selling point i'd make, even if i thought dnssec was operationally feasable. -- to 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/> From owner-namedroppers@ops.ietf.org Mon Oct 18 19:44:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06764 for <dnsext-archive@lists.ietf.org>; Mon, 18 Oct 2004 19:44:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CJh8D-0003j9-UV for namedroppers-data@psg.com; Mon, 18 Oct 2004 23:41:37 +0000 Received: from [65.205.251.74] (helo=colibri.verisign.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CJh8D-0003iw-5e for namedroppers@ops.ietf.org; Mon, 18 Oct 2004 23:41:37 +0000 Received: from mou1wnexc02.vcorp.ad.vrsn.com (mailer5.verisign.com [65.205.251.54]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i9INfY0g009338; Mon, 18 Oct 2004 16:41:34 -0700 (PDT) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <VDJ2PX97>; Mon, 18 Oct 2004 16:41:34 -0700 Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BECAE@mou1wnexm05.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" <pbaker@verisign.com> To: "'Paul Vixie'" <paul@vix.com>, namedroppers@ops.ietf.org Subject: RE: I-D ACTION:draft-iab-dns-choices-00.txt Date: Mon, 18 Oct 2004 16:41:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > nothing so grand. he originally chose TXT because he didn't > know any better, > and by the time he got any help, there was already both code > and data deployed > that made TXT hard to change. only microsoft could have > forced a mind-change > or format-change, and they (microsoft) blew their chance due > to IPR policies. This is factually inaccurate, SPF acknowledged the RMX draft from Hadmut, the use of TXT was an entirely deliberate design decision. Do not confuse your advice being rejected and the advice being unheard. In this case the deployment issues with new records were understood and discussed at length. Microsoft was planning to put XML records in the DNS and they were planning to use a prefixed TXT record to do so. -- to 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/> From owner-namedroppers@ops.ietf.org Mon Oct 18 19:54:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07400 for <dnsext-archive@lists.ietf.org>; Mon, 18 Oct 2004 19:54:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CJhJO-00058t-4a for namedroppers-data@psg.com; Mon, 18 Oct 2004 23:53:10 +0000 Received: from [65.205.251.74] (helo=colibri.verisign.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CJhJN-00058b-4I for namedroppers@ops.ietf.org; Mon, 18 Oct 2004 23:53:09 +0000 Received: from mou1wnexc01.vcorp.ad.vrsn.com (mailer4.verisign.com [65.205.251.53]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i9INr6QA009998; Mon, 18 Oct 2004 16:53:06 -0700 (PDT) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <VCDJXGBR>; Mon, 18 Oct 2004 16:53:06 -0700 Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BECAF@mou1wnexm05.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" <pbaker@verisign.com> To: "'Mark Andrews'" <Mark_Andrews@isc.org>, "Hallam-Baker, Phillip" <pbaker@verisign.com> Cc: "'Alex Bligh'" <alex@alex.org.uk>, namedroppers@ops.ietf.org Subject: RE: I-D ACTION:draft-iab-dns-choices-00.txt Date: Mon, 18 Oct 2004 16:53:06 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mark writes > > WRITING IN CAPITALS DOES NOT CONSTITUTE AN ARGUMENT. > > Well the firsting you have to get agreement on is how many > labels does * match in > > a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.*.example.net > A 127.0.0.1 > a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.*.example.net A > 127.0.0.2 > a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.*.example.net A 127.0.0.3 > a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.*.example.net A 127.0.0.4 > a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.*.example.net A 127.0.0.5 > a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.*.example.net A 127.0.0.6 > a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.*.example.net A 127.0.0.7 > a.a.a.a.a.a.a.a.a.a.a.a.a.a.*.example.net A 127.0.0.8 > a.a.a.a.a.a.a.a.a.a.a.a.a.*.example.net A 127.0.0.10 > a.a.a.a.a.a.a.a.a.a.a.a.*.example.net A 127.0.0.11 > a.a.a.a.a.a.a.a.a.a.a.*.example.net A 127.0.0.12 > a.a.a.a.a.a.a.a.a.a.*.example.net A 127.0.0.13 > a.a.a.a.a.a.a.a.a.*.example.net A 127.0.0.14 > a.a.a.a.a.a.a.a.*.example.net A 127.0.0.15 > a.a.a.a.a.a.a.*.example.net A 127.0.0.16 > a.a.a.a.a.a.*.example.net A 127.0.0.17 > a.a.a.a.a.*.example.net A 127.0.0.19 > a.a.a.a.*.example.net A 127.0.0.20 > a.a.a.*.example.net A 127.0.0.21 > a.a.*.example.net A 127.0.0.22 > a.*.example.net A 127.0.0.24 > *.example.net A 127.0.0.25 > > with a query of > > > a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a. > a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a. > a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a. > example.net > > is it *.example.net A 127.0.0.25 > or > a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.*.example.net A 127.0.0.1 > or a random one from above or all of them .... > > Allowing * to expand in the middle creates large search spaces. Not at all, since we are talking about macros not wildcards there is no reason why this has to be standardized and there is no reason why servers need to provide unbounded matches. Even on the entirely artificial example you give there is a simple rule that can be applied, take the most specific match, starting with the RHS, then take the LHS. So that gives you 127.0.0.1. The matching rule is no worse for the LHS than the RHS. Its a straight FSM with a very tightly bounded complexity. You only start creating problems if you allow multi-level macro wildcards which nobody has asked for. And even that is not really a major problem, even 1970s technology like UNIX could handle matches on a*b*c. Its undergrad intro to parser theory 101. All the algorithms are nice and regular. Please take a look at your examples and spend some time thinking about them in future before telling us in all caps that there is a problem. Phill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Oct 18 20:41:04 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11211 for <dnsext-archive@lists.ietf.org>; Mon, 18 Oct 2004 20:41:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CJi07-000Ah6-Bn for namedroppers-data@psg.com; Tue, 19 Oct 2004 00:37:19 +0000 Received: from [205.150.200.161] (helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CJi05-000Agf-Vd for namedroppers@ops.ietf.org; Tue, 19 Oct 2004 00:37:18 +0000 Received: from road.marajade.sandelman.ca (marajade.sandelman.ottawa.on.ca [205.150.200.247]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i9J0R1H05152 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Mon, 18 Oct 2004 20:27:01 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1]) by road.marajade.sandelman.ca (8.12.11/8.12.3/Debian-6.6) with ESMTP id i9J0R1j3013008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Oct 2004 20:27:01 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.11/8.12.3/Debian-6.6) with ESMTP id i9J0Qwj9013005; Mon, 18 Oct 2004 20:26:58 -0400 To: "Hallam-Baker, Phillip" <pbaker@verisign.com> cc: "'Mark Andrews'" <Mark_Andrews@isc.org>, "'Alex Bligh'" <alex@alex.org.uk>, namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-iab-dns-choices-00.txt In-Reply-To: Message from "Hallam-Baker, Phillip" <pbaker@verisign.com> of "Mon, 18 Oct 2004 16:53:06 PDT." <C6DDA43B91BFDA49AA2F1E473732113E010BECAF@mou1wnexm05.vcorp.ad.vrsn.com> References: <C6DDA43B91BFDA49AA2F1E473732113E010BECAF@mou1wnexm05.vcorp.ad.vrsn.com> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 15) Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 18 Oct 2004 20:26:58 -0400 Message-ID: <13004.1098145618@marajade.sandelman.ottawa.on.ca> From: Michael Richardson <mcr@sandelman.ottawa.on.ca> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Hallam-Baker," == Hallam-Baker, Phillip <pbaker@verisign.com> writes: >> Allowing * to expand in the middle creates large search spaces. Hallam-Baker> Not at all, since we are talking about macros not Hallam-Baker> wildcards there is no reason why this has to be Hallam-Baker> standardized and there is no reason why servers need Hallam-Baker> to provide unbounded matches. So, you don't mind if your secondary servers answer differently than your primaries? Or do we have to run the same software everywhere? I like diversity. - -- ] "Elmo went to the wrong fundraiser" - The Simpson | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQXRfUIqHRg3pndX9AQEiDgQA0mmz+Dqa2vgFFooV+VNyYmbcEg728/70 GmrCq86udDZIyWdOLWhQtcdEzlJqxky1k+zlAxqp3aGCohApd5ssSwXbN0zVbHe2 7CyhvuT8VxeBYhsmgHKMCtMJmxgg8hkgtZ0u3+G6BI78WwzRCYYfCCc6IdD4XGy4 wOvjHJkz2Yc= =a6bF -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Oct 18 20:44:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11590 for <dnsext-archive@lists.ietf.org>; Mon, 18 Oct 2004 20:44:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CJi5r-000BSK-Mi for namedroppers-data@psg.com; Tue, 19 Oct 2004 00:43:15 +0000 Received: from [65.205.251.74] (helo=colibri.verisign.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CJi5q-000BRz-RO for namedroppers@ops.ietf.org; Tue, 19 Oct 2004 00:43:14 +0000 Received: from mou1wnexc01.vcorp.ad.vrsn.com (mailer4.verisign.com [65.205.251.53]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i9J0hCMO012604; Mon, 18 Oct 2004 17:43:12 -0700 (PDT) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <VCDJXH5B>; Mon, 18 Oct 2004 17:43:12 -0700 Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BECB0@mou1wnexm05.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" <pbaker@verisign.com> To: "'Michael Richardson'" <mcr@sandelman.ottawa.on.ca>, "Hallam-Baker, Phillip" <pbaker@verisign.com> Cc: "'Mark Andrews'" <Mark_Andrews@isc.org>, "'Alex Bligh'" <alex@alex.org.uk>, namedroppers@ops.ietf.org Subject: RE: I-D ACTION:draft-iab-dns-choices-00.txt Date: Mon, 18 Oct 2004 17:43:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > >>>>> "Hallam-Baker," == Hallam-Baker, Phillip > <pbaker@verisign.com> writes: > >> Allowing * to expand in the middle creates large search spaces. > > Hallam-Baker> Not at all, since we are talking about macros not > Hallam-Baker> wildcards there is no reason why this has to be > Hallam-Baker> standardized and there is no reason why servers need > Hallam-Baker> to provide unbounded matches. > > So, you don't mind if your secondary servers answer differently than > your primaries? Or the primary can expand out the macros and generate the closures. Logically the only match that is needed for midpoint matches is for nodes that exist. Nodes that existeth not are not going to be needing services to have policy published. About all that can be said for them is that they existeth not. > Or do we have to run the same software everywhere? > I like diversity. I am quite willing to sacrifice diversity in order to avoid the need to persuade this group to take action. If people beleive that diversity is desirable then its a simple enough problem to specify what has to be done to support it. Regardless of whether _MARID or _MASS comes into existence there are already plenty of SRV entry points and these are going to proliferate further and macros would really be quite handy. -- to 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/> From owner-namedroppers@ops.ietf.org Mon Oct 18 22:58:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22967 for <dnsext-archive@lists.ietf.org>; Mon, 18 Oct 2004 22:58:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CJk5T-000PsV-Gi for namedroppers-data@psg.com; Tue, 19 Oct 2004 02:50:59 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CJk5R-000Ps4-12 for namedroppers@ops.ietf.org; Tue, 19 Oct 2004 02:50:58 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.11/8.12.11) with ESMTP id i9J2oijI073877 for <namedroppers@ops.ietf.org>; Mon, 18 Oct 2004 22:50:44 -0400 (EDT) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.12.11/8.12.11/Submit) id i9J2oiRu073876 for namedroppers@ops.ietf.org; Mon, 18 Oct 2004 22:50:44 -0400 (EDT) (envelope-from namedroppers) Received: from [192.150.250.67] (helo=fuchsia.home) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CJfV1-000Gwr-Nd for namedroppers@ops.ietf.org; Mon, 18 Oct 2004 21:57:12 +0000 Received: from delta.noi.kre.to (delta.wi0.home [192.168.192.32]) by fuchsia.home with ESMTP id i9ILutIj002132; Tue, 19 Oct 2004 04:56:55 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i9ILulJV022909; Tue, 19 Oct 2004 04:56:48 +0700 (ICT) From: Robert Elz <kre@munnari.OZ.AU> To: Edward Lewis <Ed.Lewis@neustar.biz> cc: namedroppers@ops.ietf.org Subject: Re: wcard draft out there... In-Reply-To: <a06110401bd9975bf2a08@[192.35.166.53]> References: <a06110401bd9975bf2a08@[192.35.166.53]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Oct 2004 04:56:47 +0700 Message-ID: <18917.1098136607@munnari.OZ.AU> X-Scanned-By: MIMEDefang 2.44 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] OK, here are some comments interspersed with the text (with many parts deleted where there's nothing to say) | 1.2 The Original Definition | This document is intended to not make changes. To reinforce Actually, it is intended to make one change (CNAME) - you really shouldn't say that there will be none, and then make one anyway. | This passage appears after the algorithm in which they are used is | presented. The terminology is not consistent, the word "wildcard" | is clearly defined to be a resource record. In the next sentence | the term is shifted to be an adjective, the first step on the That's going way overboard in looking for something to worry about. Just delete the bit that relates to adjectives as an attempt to show that there are problems in 1034 (there really aren't many, 1034 isn't bad in this area, it just isn't obvious). | Label Match - two labels are equivalent if the label type and label | length are the same bit sequence and if the name is the label is | equivalent bit wise after down casing all of the ASCII characters. | [Ed note: do we still call them ASCII?] Yes, we do, but "down casing" isn't he right way to describe how names are matches, it is just a case-independent comparison, just as the DNS RFCs describe it, in this doc there's no need to add confusion by describing things in a different way. | In RFC 1034, there is text that seems to bar having two Asterisk | Labels in a Wild Card Domain Name. There is no further discussion, | no prescribed error handling, nor enforcement described. In this | document, the use of such names will be discouraged, but implementations | will have to account for the possibility of such a name's use. What you mean to say here is that they are to be allowed. Just say it, there's no need to side-step around it by telling implementations that they have to allow for it, without actually saying that it is OK. | 1.3.3 Considerations with Special Types | This clarification will describe in some detail the semantics of | wildcard CNAME RRs, wildcard NS RRs, wildcard SOA RR's, | wildcard DNAME RRs [RFC wxyz], and empty, non-terminal wildcards. It would probably be a good idea to also describe the semantics for a representative "normal" (ie: easy) RR type (say MX, or A) just so the normal case doesn't need to be inferred from what's done with the odd ones. | By the definition in RFC 1034, there can be no empty, non-terminal | "wildcards", I'm not sure I agree with that. I think you're reading the description in 1034 as if it was considering the text input format, rather than the domain tree, but I don't think it is. | 2 "Wildcard" [...] | Avoiding the need for implementations to have many internal data | structures is a good thing. Huh? What's that supposed to be about. There's no foundation I can find for referring to these data structures. | Not that this means limiting quantity, but rather types of data. I have no idea what that is trying to say either. | 2.1.1 Wild Card Domain Name and Asterisk Label | A "Wild Card Domain Name" is defined by having its initial label be: (in the format used in DNS packets) | 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal) | RFC 1034's definition of wildcard would be "a resource record owned | by a Wild Card Domain Name." This is mentioned to help maintain some | orientation between this clarification and RFC 1034. Keep in mind, | that in "Clarifications to the DNS Specification" [RFC 2181] the name need a ref (in ref's section) for 2181 if you're going to mention it. | 2.1.2 Variations on Wild Card Domain Names | RFC 1034 and RFC 1035 do not explicitly mention the case in which a | domain name might be something like "the*.example.com." The | interpretation is that this domain name in a zone would only match | queries for "the*.example.com" and not have any other role. An | asterisk ('*') occurring other than as the sole character in | a label is simply a character forming part of the label and has no | special meaning. This is not an Asterisk Label, simply a label | an asterisk in it. The same is true for "**.example.com." and | "*the.example.com." | [Ed note: the above paragraph reads too strong. No it doesn't, that one is fine as it is. | The intent ought to | be that such names do not fall under the rules of wildcards. The | intent is not to bar any future attempts to define other forms of | synthesis - nor is the intent to encourage them.] First, nothing we do can "bar any future standards" from anything, there's no point worrying about that. Just be very clear (which the above is) what the current state of the world is, and allow the future look after itself. (It would perhaps be different if there was already an extension planned, or commonly used or something, but there isn't.) | The interpretation of a wild card domain specification which is not a | leaf domain is not clearly defined in RFC 1034. Actually, it is. It just isn't explicit. No-where does it say anything about sub-domains of wildcards. The reason is that they're simply not relevant to anything. There shouldn't have ever been any need to say anything about them at all. The only reason we need to cover this now is that people have started to (very badly) misunderstand the way wildcards work, and because of that to imagine semantics for such things which don't exist. | 2.1.3 Non-terminal Wild Card Domain Names [...] | The recommendation is that implementations ought to anticipate the | appearance of such names but generally discourage their use in | operations. It isn't really applications, but DNS operators - the people who decide what names to stick in zone files, where this should be discouraged. | No standards statement, such as "MAY NOT" or "SHOULD NOT" | is made here. You probably should use MUST NOT rather than MAY NOT here, MAY NOT is a useless specification (it turns out to mean exactly the same as MAY, though with perhaps a slightly different slant). | The interpretation of this is, when seeking a Wild Card Domain Name | for the purposes of record synthesis, an implementation ought not to | check the domain name for subdomains. Rather than tell implementations what to do, just say what is required. Here, after the second ',', "the existence (or not) of sub-domains of the Wild Card Domain Name is irrelevant." | 2.2 Existence Rules | The notion that a domain name 'exists' arises numerous times in | discussions about the wildcard concept. Really? In the dnssec context perhaps, but not just wildcard discussions did it? | RFC 1034 raises the issue | of existence in a number of places, usually in reference to | non-existence and in reference to processing involving wildcards. | RFC 1034 contains algorithms that describe how domain names impact | the preparation of an answer and does define wildcards as a means of | synthesizing answers. Because of this a discussion on wildcards | needs to cover a definition of existence. I'm not sure I agree, but it seems that people want it, so whatever... | To help clarify the topic of wild cards, a positive definition of | existence is needed. Complicating matters, though, is the | realization that existence is relative. To an authoritative server, | a domain name exists if the domain name plays a role following the | algorithms of preparing a response. To a resolver, a domain name | exists if there is any data available corresponding to the name. Really: if it doesn't get an error from an attempt to resolve the name. The resolver usually has no clue whether "any data" is available or not, just the particular data type it asked about. To an application, names "exist" (in some sense, not really relevant here) if the particular data they need to operate exists for the name, but that's not really true for resolvers (and certainly wouldn't be for dnssec aware resolvers). | For the purposes of this document, the point of view of an | authoritative server is more interesting. What does it matter what is "interesting". What matters is what is necessary to define in order for it to be able to be used in this doc. Just define the term and use it, please try and avoid being "chatty". | QNAME=_telnet._tcp.host2.example., QTYPE=SRV, QCLASS=IN | because host2.example. exists (without data) But _tcp.host2.example. exists as well, what's the difference between this example and the previous (host1) example?? [Aside: you don't really need the $ORIGIN in the zone file segment, there are no unqualified domain names present, so what the origin is doesn't really matter.] You could possibly further clarity "exist" here by noting that to "exist" the domain name must appear somewhere in a textual representation of a domain name. If you want to get into the real weird cases, one to worry about is whether or not a PTR record RDATA can ever cause a name to "exist". While the most reasonable answer is probably "no, of course not", it isn't really necessarily quite that clear. | 2.2.3 Yet Another Definition of Existence | RFC1034's wording is clarified by the following paragraph: | A node is considered to have an impact on the algorithms of | 4.3.2 if it is a leaf node with any resource sets or an interior | node (with or without a resource set) that has a subdomain that | is a leaf node with a resource set. A QNAME and QCLASS matching | an existing node never results in a response code of | authoritative name error (RCODE==3). What's a "resource set"? Please be consistent in the terminology, you mean a "resource record set" (or RRset if you want to save bytes). | Summarizing the discussion on existence in non-RFC1034 words: | An authoritative server is to treat a domain name as existing | during the execution of the algorithms in RFC 1034 when the | domain name conforms to the following definition. A domain name | is defined to exist if the domain name owns data or has a | subdomain that exists, or both. I'm not sure this is quite clear enough - that is, a synthesised domain from a wildcard "owns data" (in some sense anyway) (assuming the appropriate record type exists at the wildcard). | 2.3 When does a Wild Card Domain Name not own a wildcard (record) | When a Wild Card Domain Name appears in a message's query section, | no special processing occurs. Asterisk Labels in such a context | only Label Matches other Asterisk Labels in the existing zone tree | when the 4.3.2 algorithm is being followed. I have no idea what that sentence says. Maybe "Label Matches" is just meant to be "match" ?? Assuming it is, it might be worth pointing out that a '*' in a QNAME can never generate synthesised domain names, as if there's a wildcard that could ever apply to it, it always matches explicitly instead (makes no difference to the answer generated, just semantics, but it is something that needs to be understood.) | There is a documentation issue deserving some explanation. The | algorithm in RFC 1034, section 4.3.2. is not intended to be pseudo | code, i.e., it's steps are not intended to be followed in strict | order. The "algorithm" is a suggestion. As such, in step 3, parts | a, b, and c, do not have to be implemented in that order. It really doesn't matter - implementations never need to follow the exact order of pseudo-code, even if that is what it is - all that's required is to have the same effect. Since 'a' 'b' and 'c' are mutually exclusive, it can't possibly make a difference what order they're implemented, nor whether 4.3.2 is pseudo-code or not. There's no need to make an issue of this. | Another issue needing explanation is that RFC 1034 is a full | standard. There is another RFC, RFC 2672, which makes, or proposes | an adjustment to RFC 1034's section 4.3.2 for the sake of the DNAME | RR. RFC 2672 is a proposed standard. The dilemma in writing these | clarifications is knowing which document is the one being clarified. | Fortunately, the difference between RFC 1034 and RFC 2672 is not | significant with respect to wild card synthesis, so this document | will continue to state that it is clarifying RFC 1034. If RFC 2672 | progresses along the standards track, it will need to refer to | modifying RFC 1034's algorithm as amended here. Then, if 2672 progresses, it would be DS, most likely while this doc remains PS, so why should it not do exactly the same as you're doing, and simply ignore the "lower status" doc? Avoid that issue, just delete all the text about the various status of RFCs. If nothing in 2672 is adversely affected by anything that's here, which is what I'd expect, as I doubt 2672 is attempting to mis-use wildcards, then there's no issue at all, and we just clarify both together. On the other hand, if we're changing something that 2672 is assuming, then we need to be explicit about what the result is to be - otherwise we end up with two PS docs that are conflicting with each other, and with the later one not being clear what this really all means (obviously the earlier one cannot be). | In this step, the most appropriate zone for the response is chosen. | There are two reasons to repeat this. One is that this means all | of step 3 is done within the context of a zone, which will constrain | the discussion. The other is the though behind synthesizing entire | zones and the use of Wild Card Domain Names to do so. What's a "though" ? "thought"? Still doesn't really make sense. Maybe "attempt to" (in place of "though behind")? Do we really even want to mention this? | The word matching in this care refers to Label Matching. Here you need to make it very clear that the only "matching" that happens is string equality (case independent) - there's absolutely no "pattern matching" being done. My impression is that this the the biggest source of misunderstanding - people see "match", they leap to "pattern match" and then "*" means "match anything". | The concept | is based in the view of the zone as the tree of existing names. The | Query Name is considered to be an ordered sequence of labels - as | if the name were a path from the root to the owner of the desired | data. "as if" ?? Isn't that exactly what it is? | The process of Label Matching ends in one of three choices, the parts | a, b, and c. "always ends in exactly one of" | # c. If at some label, a match is impossible (i.e., the | # corresponding label does not exist), look to see if a | # the "*" label exists. It may be worth explaining here, very explicitly, that the '*' does not "match" anything in the QNAME - quite the contrary, we're here precisely because nothing matches ("a match is impossible"), and yet (assuming the '*' does exist) the '*' label is there. | To help describe the process of looking "to see is a the [sic] | label exists" a term has been coined to describe the last label | matched. The term is "Closest Encloser." You put in "[sic]" but then added a typo "is" rather than "if" making the [sic] incorrect... | 3.3.1 Closest Encloser and the Source of Synthesis | The "Closest Encloser" is the node in the zone's tree of existing | domain names that is has the most matching labels with the sought | name. Just use QNAME rather than "sought name" - if necessary, somewhere, say what "QNAME" means. And not "most matching labels", then if the QNAME were "a.b.c.d.e.f.g." and the "g." zone contains "a.b.c.d.e.g." then there could be considered to be 5 matching labels in the zone (not counting the 'g'). In reality, there are none, as there's no 'f' there - what we want is the most consecutive trailing matching labels. | A "Source of Synthesis" is defined in the context of a lookup | process as the Wild Card Domain Name immediately descending from | the Closest Encloser provided the Wild Card Domain Name exists. s/the Wild/that Wild/ | If a Source of Synthesis exists, it will be the Wild Card Domain Name | that is identified by an Asterisk Label below the Closest Encloser. s/below the/as a sub-domain of/ Stick to DNS terminology. | E.g., "<Asterisk Label>.<Closest Encloser> or "*.<Closest Encloser>." Surely "ie" not "eg" - this isn't an example, this is *it*. | If the Source of Synthesis does not exist (not on the domain tree), | there will be no wildcard synthesis (missing '.' at the end of that sentence). "on the domain tree" ? I guess that's OK, but "in" is more common isn't it? You may want to say something like "Other Wild Card Domain Names are irrelevant and can never play any part in synthesis, regardless of where they appear in the DNS tree." | The important concept is that for any given lookup process, there | is at most one place at which wildcard synthetic records can be | obtained. If the Source of Synthesis does not exist, the lookup | terminates, the lookup does not look for other wildcard records. This is a slightly milder form of what I'd say. | Other terms have been coined on the mailing list in the past. E.g., | it has been said that existing names block the application of | wildcard records. This is still an appropriate viewpoint, but | replacing this notion with the Closest Encloser and Source of | Synthesis the depiction of the wildcard process is clearer. Delete that paragraph, there's no useful information there. | 3.3.2 Closest Encloser and Source of Synthesis Examples | To illustrate, using the example zone in section 2.2.1 of this document, | the following chart shows QNAMEs and the closest enclosers. | QNAME Closest Encloser Source of Synthesis | host3.example. example. *.example. | _telnet._tcp.host1.example. _tcp.host1.example. no source | _telnet._tcp.host2.example. host2.example. no source _tcp.host2.example. | _telnet._tcp.host3.example. example. *.example. | _chat._udp.host3.example. example. *.example. | The fact that a closest encloser will be the only superdomain that | can have a candidate wild card will have an impact when it comes to | designing pre-calculated authenticated denial of existence proofs. Do we need to include that? We're not designing denial of existence proofs here, are we? Stick to the topic, don't wander. | 3.3.4 Type Matching | RFC 1034 concludes part c with this: | 4.1. SOA RR's at a Wild Card Domain Name | A Wild Card Domain Name owning an SOA RRSet means that the domain | is at the root of the zone (apex). The domain can not be a Source of | Synthesis because that is, but definition, a descendent node (of s/but/by/ | the Closest Encloser) and a zone apex is at the top of the zone. | Although a Wild Card Domain Name can not be a Source of Synthesis, "for SOA records" and I'd use "never" instead of "not" to make it clearer that it is simply impossible, rather than an imposed restriction. | there is no reason to forbid the ownership of an SOA RRSet. This | means that zones with names like "*.<Parent Zone>.", and even | "*.<Parent Sublabels>.<Parent Zone>." That last sentence looks incomplete. Means what? | Step 2 (section 3.1) does not provide a means to specify a means to | synthesize a zone. too many "means", make the second "method" | Therefore, according to the rules there, the | only way in which a zone that has a name which is a Wild Card | Domain Name is if the QNAME is in a domain below the zone's name. I suspect that sentence means something, but I don't know what. But how can the name of a zone possibly depend upon what happens to be in some particular query? The zone exists (and is named) first, queries come later. | E.g., if *.example. has an SOA record, then only a query like | QNAME=*.example., QTYPE=A, QCLASS=IN would see it. But it wouldn't - or not directly - a QTYPE=A isn't going to result in a SOA being returned. (And yes, I know it gets added to the auth section to provide cache info, but I don't think we should descend there). Just make the QTYPE be SOA, it already says "like" so it isn't saying that's the only way to ever get the SOA record back anywhere, but it is the only way to get it as the answer. | As another | example, a QNAME of www.*.example. would also result in passing | through the zone. "passing through"? Is this relevant? We'd have to define what that actually means (this is supposed to be clarifications, not confusifications). | 4.2. NS RR's at a Wild Card Domain Name | The semantics of a Wild Card Domain Name ownership of a NS RRSet | has been unclear. s/has/have/ And "unclear" isn't really correct/ They are clear. What they've been is misunderstood. | Looking through RFC 1034, Who's looking? Why is that phrase needed? | the recommendation | is to have the NS RRSet act the same a any non-special type, e.g., | like an A RR. What recommendation? From 1034, a new one here, or ?? Why do we need a recommendation anyway, can't be just be excplicit and concise, and state the fact: An NS RRSet acts the same as any other type. | In any other case, the Wild Card Domain Name owned NS RRSet would | be the only RRSet (prior to changes instituted by DNSSEC) at the | node by DNS rules. You probably need to refer to just what DNS rules they are. | Note that there is no synthesis of records in the authority section | because part 'b' does not account for synthesis. Rather than "does not account for synthesis", "applies only when there is a name match, no records are synthesised" | If the QNAME is not the same as the Wild Card Domain Name nor a | subdomain of it, then part 'c' of Step 3 has been triggered. Once | part 'c' is entered, there is no reverting to part 'b' - i.e., | once an NS RRSet is synthesized it does not mean that the server has | to consider the name delegated away. I.e., the server is not | synthesizing a record (the NS RRSet) that means the server does not | have the right to synthesize. I can't interpret the final sentence. Here you might want to quite more of 'c', including in particular, the "goto 6", with a note that that means that the whole process is effectively over. | 4.4. DNAME RR's at a Wild Card Domain Name | The specification of the DNAME RR, which is at the proposed level of | standardization, is not as mature as the full standard in RFC 1034. Drop that. | Because of this, or the reason for this is, there appears to be a | a number of issues with that definition and it's rewrite of the algorithm | in 4.3.2. If there are issues, we should be fixing them. What are these issues? Don't beat about the bush - be clear. | For the time being, when it comes to wild card processing Why "for the time being" - when does that time end? 6 months? If another draft later wants to change things, then that's fine. But until then, we just say what we want to be the state of the world. | 4.5 Empty Non-terminal Wild Card Domain Name | If a Source of Synthesis is an empty non-terminal, then the response | will be one of no error in the return code and no RRSet in the answer | section. It might be worth pointing out here that this is just a not-very-interesting case of there being no RRs that are of the QTYPE requested - it really doesn't matter that there are also no other RRs at the node, or lots of other RRs - everything is the same. No RRs match QTYPE -> empty answer. | 5. Security Considerations | This document is refining the specifications to make it more likely | that security can be added to DNS. No functional additions are being | made, just refining what is considered proper to allow the DNS, | security of the DNS, and extending the DNS to be more predictable. There is a "functional addition" - wildcard CNAME. Don't misprepresent. | 6. References Probably need BCP78 & BCP79 - they're referred to in the IP noise. Do need 2181. | 7. Others Contributing to This Document | Others who have been editors of this document: Bob Halley and Robert Elz. I wasn't there long enough to count, just delete me. kre ps: I have seen Alex's comments - I don't think there's a need to go overboard adding "(i.e. left most or least significant)" everywhere the text talks about the leftmost domain name. Once perhaps, but I think that's there already. And ... A descriptive name of a label equaling that value is an "Asterisk - Label." + Label.". is simply wrong. + as are "*.sub.*.example.com.", and "*.*.example.com." (though for + the latter two cases see 2.1.3 below). + [AB - Right? Per your definition above, they are still Wild Card Domain + Names notwithstanding 2.1.3]. *.*.example.com. actually contains 2 different Wild Card Domain Names. (Recall that for any domain name that exists, all of its parents must also exist, and are all domain names themselves). -- to 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/> From owner-namedroppers@ops.ietf.org Tue Oct 19 08:30:58 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18425 for <dnsext-archive@lists.ietf.org>; Tue, 19 Oct 2004 08:30:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CJszk-0006WA-Kd for namedroppers-data@psg.com; Tue, 19 Oct 2004 12:21:40 +0000 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CJszd-0006Vd-Lo for namedroppers@ops.ietf.org; Tue, 19 Oct 2004 12:21:33 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 896A526C079; Tue, 19 Oct 2004 14:21:32 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 3925226C077; Tue, 19 Oct 2004 14:21:31 +0200 (CEST) Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id i9JCLU8q890938; Tue, 19 Oct 2004 14:21:31 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id CE5EBFACE; Tue, 19 Oct 2004 14:21:30 +0200 (CEST) Date: Tue, 19 Oct 2004 14:21:30 +0200 From: Stephane Bortzmeyer <bortzmeyer@nic.fr> To: Paul Vixie <paul@vix.com> Cc: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-iab-dns-choices-00.txt Message-ID: <20041019122130.GA13615@nic.fr> References: <16756.3478.675039.839347@giles.gnomon.org.uk> <20041018223155.A14DC13E14@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041018223155.A14DC13E14@sa.vix.com> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.26-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040818i X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, Oct 18, 2004 at 10:31:55PM +0000, Paul Vixie <paul@vix.com> wrote a message of 18 lines which said: > nothing so grand. he originally chose TXT because he didn't know > any better, and by the time he got any help, there was already both > code and data deployed that made TXT hard to change. Not really true, I think. Roy Badami gave a better description (http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01912.html). Some elements: * Every MS-Windows computer has a problem with unknown record types, according to Microsoft itself. See http://www.imc.org/ietf-mxcomp/mail-archive/msg01517.html and http://www.imc.org/ietf-mxcomp/mail-archive/msg01511.html. * Many "firewall appliances" have a problem when relaying DNS with unknown record types. * Many "registrars" or other DNS providers give you access to the zone contents only through an "user-friendly" interface. Not everyone edits the zone file with vi or emacs. The problem is so common that there is a list of DNS providers that *do* allow you to create TXT records (http://archives.listbox.com/spf-discuss@v2.listbox.com/200407/0933.html), not to mention unknown record types. I do not ask you to adopt TXT records (you could say that Microsoft OS is hopelessly broken and I would agree) but do not think the choice of the SPF people was careless. [Reminder: the issue of the new RR type for SPF - draft-lentczner-spf-00.txt - will be discussed in Washington.] -- to 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/> From owner-namedroppers@ops.ietf.org Tue Oct 19 09:15:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22511 for <dnsext-archive@lists.ietf.org>; Tue, 19 Oct 2004 09:15:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CJtiN-000B2v-Cf for namedroppers-data@psg.com; Tue, 19 Oct 2004 13:07:47 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CJtiM-000B2O-B2 for namedroppers@ops.ietf.org; Tue, 19 Oct 2004 13:07:46 +0000 Received: from [192.35.166.53] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id i9JD7a3h075925; Tue, 19 Oct 2004 09:07:40 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 (Unverified) Message-Id: <a06110401bd9abf641fdc@[192.35.166.53]> In-Reply-To: <DAC3FCB50E31C54987CD10797DA511BA0B794D57@WIN-MSG-10.wingroup.windeploy.nt dev.microsoft.com> References: <DAC3FCB50E31C54987CD10797DA511BA0B794D57@WIN-MSG-10.wingroup.windeploy.nt dev.microsoft.com> Date: Tue, 19 Oct 2004 09:00:42 -0400 To: Christian Huitema <huitema@windows.microsoft.com> From: Edward Lewis <Ed.Lewis@neustar.biz> Subject: RE: I-D ACTION:draft-iab-dns-choices-00.txt Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.44 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In May I did a presentation based on an earlier version of this document to an audience that wasn't wholly receptive. The topics of contention are nicely covered in Christian's message with one exception. The audience did not raise the issues with the TCP arguments. But the audience did also refuse to acknowledge the problems with name prefixes given the success of srv records and the poor track record in defining new RR types. At 12:33 -0400 10/17/04, Christian Huitema wrote: ... >Throughout the document, there are claims that having large records or >large record sets increases the risk of using TCP, which is true, and >that using TCP would be a catastrophe, which is dubious... >The main argument against the name prefix solution is its >incompatibility with wild cards. Without going in a deep analysis of >wild card usage, I note that we have some experience with using name >prefixes for SRV records, and that the mail logs are not full of >complaints about incompatibility between SRV and wild cards... >The document does not discuss the role of the IETF in the record type >creation process... >-- Christian Huitema -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar "Now under neu management" -- to 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/> From owner-namedroppers@ops.ietf.org Tue Oct 19 09:22:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23033 for <dnsext-archive@lists.ietf.org>; Tue, 19 Oct 2004 09:22:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CJtr3-000Buk-Tw for namedroppers-data@psg.com; Tue, 19 Oct 2004 13:16:45 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CJtqz-000Btb-U1 for namedroppers@ops.ietf.org; Tue, 19 Oct 2004 13:16:42 +0000 Received: from [192.168.0.16] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 09795C2DA6; Tue, 19 Oct 2004 14:16:41 +0100 (BST) Date: Tue, 19 Oct 2004 14:14:53 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: Stephane Bortzmeyer <bortzmeyer@nic.fr>, Paul Vixie <paul@vix.com> Cc: namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> Subject: Re: I-D ACTION:draft-iab-dns-choices-00.txt Message-ID: <1E357E7BA785EFB0D7718B31@[192.168.0.16]> In-Reply-To: <20041019122130.GA13615@nic.fr> References: <16756.3478.675039.839347@giles.gnomon.org.uk> <20041018223155.A14DC13E14@sa.vix.com> <20041019122130.GA13615@nic.fr> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 19 October 2004 14:21 +0200 Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote: > I do not ask you to adopt TXT records (you could say that Microsoft OS > is hopelessly broken and I would agree) but do not think the choice of > the SPF people was careless. Seems to me there is a bit of a chicken & egg argument going on here. If you don't make it clear that the preferred way to incorporate new DNS features is new RR Types, then people will continue to ship broken operating systems / UIs etc. on the basis that new DNS features will use TXT. That does *not* mean (IMHO) that the early decision to use TXT for SPF etc. was careless / dumb (whatever), it merely means it was taken (a) in the absence of guidance as being proposed by draft-iab-dns-choices, and (b) in the absence of the effect of guidance such as in draft-iab-dns-choices on the various DNS-speaking servers/appliances/UIs. IE if everyone (SPF folks included) were already following draft-iab-dns-choices, there would be no need for it. So the fact that people aren't following draft-iab-dns-choices (or producing compatible OS's and appliances etc.) is a justification FOR having it, not against having it; not should it serve to criticize people who've made other decisions in the past (which is not I think what Paul meant, but...) Alex -- to 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/> From owner-namedroppers@ops.ietf.org Tue Oct 19 13:40:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20100 for <dnsext-archive@lists.ietf.org>; Tue, 19 Oct 2004 13:40:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CJxqT-000ERM-JQ for namedroppers-data@psg.com; Tue, 19 Oct 2004 17:32:25 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1CJxqS-000ER8-LZ for namedroppers@ops.ietf.org; Tue, 19 Oct 2004 17:32:24 +0000 Received: (qmail 87622 invoked by uid 1016); 19 Oct 2004 17:32:46 -0000 Date: 19 Oct 2004 17:32:46 -0000 Message-ID: <20041019173246.87621.qmail@cr.yp.to> From: "D. J. Bernstein" <djb@cr.yp.to> To: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-iab-dns-choices-00.txt References: <16756.3478.675039.839347@giles.gnomon.org.uk> <20041018223155.A14DC13E14@sa.vix.com> <20041019122130.GA13615@nic.fr> <1E357E7BA785EFB0D7718B31@[192.168.0.16]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I fully agree that DNS implementations should support all record types. As RFC 1034 says: ``Researchers are continuously proposing, implementing and experimenting with new data types ... experimental behavior should always be expected in extensions beyond the official protocol.'' As RFC 1123 says: ``DNS software ... SHOULD be written to minimize the trauma associated with the introduction of new well-known types and local experimentation with non-standard types.'' My DNS software has always handled the complete 16-bit range of possible record types. The reality, however, is that certain implementors have screwed this up horribly. A large part of the Domain Name System, as it actually exists on the Internet today, fails to deliver records whose types aren't on a very short list. Fixing this will take years. We have to be honest about this when we're talking to people writing software that uses DNS. Alex Bligh writes: > If you don't make it clear that the preferred way to incorporate new > DNS features is new RR Types For anyone who cares about interoperability, new RR types are _not_ the preferred way to incorporate new DNS features. The preferred way is TXT records. TXT records, unlike new RR types, succeed in delivering the data to every interested client. The problem here is not a failure to communicate the advice. The problem is that the advice is wrong. Anyone who is suckered into following the advice in draft-iab-dns-choices will suffer massive real-world interoperability problems---and will then switch to TXT records, throwing draft-iab-dns-choices away. > the effect of guidance such as in draft-iab-dns-choices on the various > DNS-speaking servers/appliances/UIs. This draft isn't talking to the DNS implementors. It's talking to the DNS users. It's giving amazingly bad advice to the DNS users. ---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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Oct 19 14:19:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25340 for <dnsext-archive@lists.ietf.org>; Tue, 19 Oct 2004 14:19:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CJyXT-000JEa-S0 for namedroppers-data@psg.com; Tue, 19 Oct 2004 18:16:51 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CJyXM-000JDx-J8 for namedroppers@ops.ietf.org; Tue, 19 Oct 2004 18:16:45 +0000 Received: from [192.35.166.53] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id i9JIGcC4077359 for <namedroppers@ops.ietf.org>; Tue, 19 Oct 2004 14:16:39 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a06110402bd9b075a315a@[192.35.166.53]> In-Reply-To: <20041019173246.87621.qmail@cr.yp.to> References: <20041019173246.87621.qmail@cr.yp.to> Date: Tue, 19 Oct 2004 14:16:43 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis <Ed.Lewis@neustar.biz> Subject: Re: I-D ACTION:draft-iab-dns-choices-00.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.44 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.8 required=5.0 tests=AWL,BAYES_00, NEW_DOMAIN_EXTENSIONS autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 13:32 -0400 10/19/04, D. J. Bernstein wrote: >For anyone who cares about interoperability, new RR types are _not_ the >preferred way to incorporate new DNS features. The preferred way is TXT >records. TXT records, unlike new RR types, succeed in delivering the >data to every interested client. On the one hand I agree with Dan. On the other hand I disagree with Dan. (I am glad I do not have three hands.) "In the moment" there are realities that cripple efforts to roll out new RR types, resulting in the use of the TXT RR as a crutch. Dan is right about that. One could react to this with a resigned countenance and go along with the crowd. One could also decide to take an activist posture and try to fix the world, one application at a time. I am making this suggestion (for the document) - which I have heard from someone else. Encourage the use of new RR types as an extension mechanism for the DNS while noting a (potential) need to develop a transition mechanism that makes use of types that are in current widespread use - e.g., TXT. My motivation is not to do this for the sake of academic protocol/architectural purity. My motivation is to move the DNS into position for future efforts (via having a pure protocol/architecture). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar "Now under neu management" -- to 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/> From owner-namedroppers@ops.ietf.org Tue Oct 19 14:26:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25792 for <dnsext-archive@lists.ietf.org>; Tue, 19 Oct 2004 14:26:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CJydE-000Jip-Og for namedroppers-data@psg.com; Tue, 19 Oct 2004 18:22:48 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CJycm-000Jg0-LM for namedroppers@ops.ietf.org; Tue, 19 Oct 2004 18:22:20 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id BB853C2DA6; Tue, 19 Oct 2004 19:22:16 +0100 (BST) Date: Tue, 19 Oct 2004 19:22:09 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: "D. J. Bernstein" <djb@cr.yp.to>, namedroppers@ops.ietf.org Cc: Alex Bligh <alex@alex.org.uk> Subject: Re: I-D ACTION:draft-iab-dns-choices-00.txt Message-ID: <5A4B5BBC14254F3C218BD764@[192.168.100.25]> In-Reply-To: <20041019173246.87621.qmail@cr.yp.to> References: <16756.3478.675039.839347@giles.gnomon.org.uk> <20041018223155.A14DC13E14@sa.vix.com> <20041019122130.GA13615@nic.fr> <1E357E7BA785EFB0D7718B31@[192.168.0.16]> <20041019173246.87621.qmail@cr.yp.to> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 19 October 2004 17:32 +0000 "D. J. Bernstein" <djb@cr.yp.to> wrote: > For anyone who cares about interoperability, new RR types are _not_ the > preferred way to incorporate new DNS features. The preferred way is TXT > records. TXT records, unlike new RR types, succeed in delivering the > data to every interested client. > > The problem here is not a failure to communicate the advice. The problem > is that the advice is wrong. Anyone who is suckered into following the > advice in draft-iab-dns-choices will suffer massive real-world > interoperability problems---and will then switch to TXT records, > throwing draft-iab-dns-choices away. Last time I looked there was no defined format for TXT records either, also leading to real world interoperability problems the first time two implementations collide, or versioning problems. It may be (de-facto) true that most DNS speaking devices do not support the extensibility required by the protocol definitions. The answer to this (at a protocol definition level) would not appear to be "throw away the extensible protocol and go to freeform text records". Clearly, at an implementation design level, it's going to be pragmatically necessary to work around widescale deployment bugs. It's not the first time that has happened. I don't really see why implementations should not for instance try their new RR type and if it's absent (or they get an error) fall back to TXT. But unless you are proposing defining (at a protocol level) what goes into a TXT record, that would seem to be an implementation issue, not a protocol issue. Putting it right in the protocol means there will be encouragement to fix all these buggy implementations. Alex -- to 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/> From owner-namedroppers@ops.ietf.org Tue Oct 19 22:50:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19394 for <dnsext-archive@lists.ietf.org>; Tue, 19 Oct 2004 22:50:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CK6Sc-000LMQ-2R for namedroppers-data@psg.com; Wed, 20 Oct 2004 02:44:22 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CK6Sb-000LMD-2F for namedroppers@ops.ietf.org; Wed, 20 Oct 2004 02:44:21 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 2E2E2677E9 for <namedroppers@ops.ietf.org>; Wed, 20 Oct 2004 02:44:19 +0000 (UTC) (envelope-from marka@drugs.dv.isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id i9K2iGcR038318 for <namedroppers@ops.ietf.org>; Wed, 20 Oct 2004 12:44:17 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200410200244.i9K2iGcR038318@drugs.dv.isc.org> To: namedroppers@ops.ietf.org From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: I-D ACTION:draft-iab-dns-choices-00.txt In-reply-to: Your message of "19 Oct 2004 17:32:46 GMT." <20041019173246.87621.qmail@cr.yp.to> Date: Wed, 20 Oct 2004 12:44:16 +1000 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > The reality, however, is that certain implementors have screwed this up > horribly. A large part of the Domain Name System, as it actually exists > on the Internet today, fails to deliver records whose types aren't on a > very short list. Fixing this will take years. We have to be honest about > this when we're talking to people writing software that uses DNS. FUD. You have to be able to publish the record. You have to be able retrieve the record. Depending upon which end(s) you are on you have control to upgrade any servers which don't support the new type, either directly or via finacial mean. The same goes for any middleware interfering with the DNS traffic. If you choose not to exercise that control don't complain. It's not like there isn't a existing solution space to the problem. The solution space exists and is well populated by mutiple vendors whether the problem is the nameserver, middleware or ISP. In most cases your existing vendor already has a fix or can implement a fix and if they don't change vendor. The main reason nameservers are not upgraded is because they perform adequately enough for their users. All you are seeing is sites that haven't yet seen the need to upgrade. A nameserver doesn't have to be able to publish a MX record if it will never be asked to publish one. Lots of load balancers arn't capable of publishing a MX record and no one cares about that. A nameserver has to be able to return a valid negative answer when asked about a MX record. Some load balancers fail to do this correctly and people do care about that. The real litmus test is how many nameservers return a invalid negative answer when asked about a new RR type not how many are capable of serving the new RR type or even fetching the new RR type. The later two will be addressed by direct consumer presure. Only in the first case has a real negative impact on deploying new RR types and in my experience there are only handfuls of servers that fail to return valid negative answers. Mark -- Mark Andrews, ISC 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Oct 20 01:04:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28564 for <dnsext-archive@lists.ietf.org>; Wed, 20 Oct 2004 01:04:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CK8ZC-0009rc-14 for namedroppers-data@psg.com; Wed, 20 Oct 2004 04:59:18 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1CK8ZB-0009qX-3H for namedroppers@ops.ietf.org; Wed, 20 Oct 2004 04:59:17 +0000 Received: (qmail 29932 invoked by uid 1016); 20 Oct 2004 04:59:37 -0000 Date: 20 Oct 2004 04:59:37 -0000 Message-ID: <20041020045937.29931.qmail@cr.yp.to> From: "D. J. Bernstein" <djb@cr.yp.to> To: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-iab-dns-choices-00.txt References: <16756.3478.675039.839347@giles.gnomon.org.uk> <20041018223155.A14DC13E14@sa.vix.com> <20041019122130.GA13615@nic.fr> <1E357E7BA785EFB0D7718B31@[192.168.0.16]> <20041019173246.87621.qmail@cr.yp.to> <5A4B5BBC14254F3C218BD764@[192.168.100.25]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Alex Bligh writes: > Last time I looked there was no defined format for TXT records either, > also leading to real world interoperability problems the first time > two implementations collide, or versioning problems. Seems to me that we're doing just fine defining TXT-record formats and avoiding TXT interoperability problems. Of course, this success comes from open, honest communication among implementors---the sort of thing that IETF used to promote and now actively interferes with. The bottom line is that TXT succeeds in delivering the data to every interested client, whereas new record types are a miserable failure. > I don't really see why implementations should not for instance try > their new RR type and if it's absent (or they get an error) fall back > to TXT. That's a much worse solution than pure TXT records, for several obvious reasons: (1) for interoperability, everyone will have to provide TXT records anyway, so the new RR type is extra work for the administrator; (2) the new-then-TXT approach is more work for software authors than pure TXT; (3) when networks are overloaded, the new-then-TXT approach fails more often than pure TXT; (4) the new-then-TXT approach is often slower, and never faster, than pure TXT. > Putting it right in the protocol means there will be encouragement to fix > all these buggy implementations. We already have encouragement. I already quoted the relevant sections of RFC 1034 and RFC 1123. I wouldn't object to yet another document making crystal clear that BIND and NSD and Microsoft screwed up and that we really want to get rid of this problem before 2010. However, until the bug has actually been fixed on every machine we can see, it's irresponsible to tell people to use new record types. ---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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Oct 20 03:39:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07922 for <dnsext-archive@lists.ietf.org>; Wed, 20 Oct 2004 03:39:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKAyu-0000w4-7r for namedroppers-data@psg.com; Wed, 20 Oct 2004 07:34:00 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKAyt-0000vk-0J for namedroppers@ops.ietf.org; Wed, 20 Oct 2004 07:33:59 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9K7Xol05803; Wed, 20 Oct 2004 10:33:52 +0300 Date: Wed, 20 Oct 2004 10:33:50 +0300 (EEST) From: Pekka Savola <pekkas@netcore.fi> To: "D. J. Bernstein" <djb@cr.yp.to> cc: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-iab-dns-choices-00.txt In-Reply-To: <20041020045937.29931.qmail@cr.yp.to> Message-ID: <Pine.LNX.4.44.0410201026260.5296-100000@netcore.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On 20 Oct 2004, D. J. Bernstein wrote: > We already have encouragement. I already quoted the relevant sections of > RFC 1034 and RFC 1123. I wouldn't object to yet another document making > crystal clear that BIND and NSD and Microsoft screwed up and that we > really want to get rid of this problem before 2010. > > However, until the bug has actually been fixed on every machine we can > see, it's irresponsible to tell people to use new record types. FWIW, Depending on what we want to achieve, defining new RR's might make perfect sense. If a lot of prominent operators started using MARID-like techniques using those RRs, this would actually provide a really significant incentives for the vendors and the operators of broken equipment to get their act together and fix their crap. Unless we use it, nothing is going to change in the next 10 years. There's a lot evidence that things just don't get fixed unless there is some pressure (examples: firewalls breaking on ECN, servers/balancers mistreating AAAA records, etc.). Maybe this would be a good apportunity to get that broken gear fixed. By the way, as it appears a lot of people are breaking DNS specifications pretty badly, I wonder if it would make sense to try to come up with some kind DNS implementation requirements document, similar to "host requirements" a long time ago, but updated with respect to new specs.. this would be a lot of work, but it might be worth it if we want to decrease the amount of completely broken DNS implementations out there. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Oct 20 04:01:58 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08785 for <dnsext-archive@lists.ietf.org>; Wed, 20 Oct 2004 04:01:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKBNu-0003ux-UZ for namedroppers-data@psg.com; Wed, 20 Oct 2004 07:59:50 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKBNu-0003uW-0N for namedroppers@ops.ietf.org; Wed, 20 Oct 2004 07:59:50 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 183A0C2DA9; Wed, 20 Oct 2004 08:59:46 +0100 (BST) Date: Wed, 20 Oct 2004 08:59:36 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: "D. J. Bernstein" <djb@cr.yp.to>, namedroppers@ops.ietf.org Cc: Alex Bligh <alex@alex.org.uk> Subject: Re: I-D ACTION:draft-iab-dns-choices-00.txt Message-ID: <BF8DC5F26DDCE25E5E8E6E89@[192.168.100.25]> In-Reply-To: <20041020045937.29931.qmail@cr.yp.to> References: <16756.3478.675039.839347@giles.gnomon.org.uk> <20041018223155.A14DC13E14@sa.vix.com> <20041019122130.GA13615@nic.fr> <1E357E7BA785EFB0D7718B31@[192.168.0.16]> <20041019173246.87621.qmail@cr.yp.to> <5A4B5BBC14254F3C218BD764@[192.168.100.25]> <20041020045937.29931.qmail@cr.yp.to> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 20 October 2004 04:59 +0000 "D. J. Bernstein" <djb@cr.yp.to> wrote: > That's a much worse solution than pure TXT records, for several obvious > reasons: (1) for interoperability, everyone will have to provide TXT > records anyway I don't see lots of people providing both A records and MX records for this purpose (now). > so the new RR type is extra work for the administrator; > (2) the new-then-TXT approach is more work for software authors than > pure TXT; (3) when networks are overloaded, the new-then-TXT approach > fails more often than pure TXT; (4) the new-then-TXT approach is often > slower, and never faster, than pure TXT. I think the point is that you only try one if the other fails. Therefore it can only be faster and MORE resilient to network congestion (etc.), EXCEPT in the case of non-existent records, which I would suggest are the minority. Alex -- to 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/> From owner-namedroppers@ops.ietf.org Wed Oct 20 09:36:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02650 for <dnsext-archive@lists.ietf.org>; Wed, 20 Oct 2004 09:36:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKGa6-000J05-EW for namedroppers-data@psg.com; Wed, 20 Oct 2004 13:32:46 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKGa5-000Izo-Bj for namedroppers@ops.ietf.org; Wed, 20 Oct 2004 13:32:45 +0000 Received: from [192.35.166.53] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id i9KDWZ7s081855 for <namedroppers@ops.ietf.org>; Wed, 20 Oct 2004 09:32:39 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 (Unverified) Message-Id: <a06110400bd9c18432b0f@[192.168.1.100]> In-Reply-To: <BF8DC5F26DDCE25E5E8E6E89@[192.168.100.25]> References: <BF8DC5F26DDCE25E5E8E6E89@[192.168.100.25]> Date: Wed, 20 Oct 2004 09:32:37 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis <Ed.Lewis@neustar.biz> Subject: Re: I-D ACTION:draft-iab-dns-choices-00.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.44 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 3:59 -0400 10/20/04, Alex Bligh wrote: >I think the point is that you only try one if the other fails. Therefore >it can only be faster and MORE resilient to network congestion (etc.), >EXCEPT in the case of non-existent records, which I would suggest are >the minority. Speaking from the experience of talking with the MARID group and also from observing the behavior of one popular DNS implementation, relying on a strategy of "try one, if it fails, try the other" is not going to be well received. The problem is that this causes a latency hit for the application. Packets and bandwidth are cheap, a user's time isn't. Application designers want to avoid long activity-dependency chains. When searching for glue records, one DNS implementation asks for AAAA and asks for A simultaneously at all steps. There's no real alternative - it's not like you can ask for just the A and then get the AAAA when you get an authoritative answer (positive or negative) - or vice versa. That's because it's a waste of sending the last query, especially when the domain name sought has just one or the other address type. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar "Now under neu management" -- to 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/> From owner-namedroppers@ops.ietf.org Wed Oct 20 09:36:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02649 for <dnsext-archive@lists.ietf.org>; Wed, 20 Oct 2004 09:36:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKGXT-000IcW-JZ for namedroppers-data@psg.com; Wed, 20 Oct 2004 13:30:03 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKGXM-000Ib9-Jq for namedroppers@ops.ietf.org; Wed, 20 Oct 2004 13:29:56 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 5594113E15 for <namedroppers@ops.ietf.org>; Wed, 20 Oct 2004 13:29:56 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-iab-dns-choices-00.txt In-Reply-To: Message from Alex Bligh <alex@alex.org.uk> of "Wed, 20 Oct 2004 08:59:36 +0100." <BF8DC5F26DDCE25E5E8E6E89@[192.168.100.25]> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 20 Oct 2004 13:29:56 +0000 Message-Id: <20041020132956.5594113E15@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk if new rr's take too long on deployment to be useful for new globally deployed services and service models to be practical, somebody had better tell microsoft that using SRV was a mistake. (and, note: we've cut the time down by a lot since then.) -- to 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/> From owner-namedroppers@ops.ietf.org Wed Oct 20 09:52:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03788 for <dnsext-archive@lists.ietf.org>; Wed, 20 Oct 2004 09:52:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKGrm-000L8N-DB for namedroppers-data@psg.com; Wed, 20 Oct 2004 13:51:02 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKGrl-000L7z-Kt for namedroppers@ops.ietf.org; Wed, 20 Oct 2004 13:51:01 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 6AE5A13E12 for <namedroppers@ops.ietf.org>; Wed, 20 Oct 2004 13:51:01 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-iab-dns-choices-00.txt In-Reply-To: Message from Edward Lewis <Ed.Lewis@neustar.biz> of "Wed, 20 Oct 2004 09:32:37 -0400." <a06110400bd9c18432b0f@[192.168.1.100]> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 20 Oct 2004 13:51:01 +0000 Message-Id: <20041020135101.6AE5A13E12@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > When searching for glue records, one DNS implementation asks for AAAA and > asks for A simultaneously at all steps. There's no real alternative - it's > not like you can ask for just the A and then get the AAAA when you get an > authoritative answer (positive or negative) - or vice versa. That's > because it's a waste of sending the last query, especially when the domain > name sought has just one or the other address type. this is why, back in the days of rfc1886, i argued that the additional-data processing for AAAA should be to "add any A RRs matching the same qname". this is also why, back in the days of rfc2672, i argued that qdcount>1 should be made meaningful, so as to allow several qtypes to be looked up for the given qname/qclass. in both cases the WG said "that's more complicated than the payback is worth." what do you all think NOW? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Oct 20 09:53:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03823 for <dnsext-archive@lists.ietf.org>; Wed, 20 Oct 2004 09:53:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKGsL-000LEW-5q for namedroppers-data@psg.com; Wed, 20 Oct 2004 13:51:37 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKGsA-000LCS-7O for namedroppers@ops.ietf.org; Wed, 20 Oct 2004 13:51:28 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id i9KDpFKa000516; Wed, 20 Oct 2004 13:51:20 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id i9KDpB7O000513; Wed, 20 Oct 2004 13:51:11 GMT Date: Wed, 20 Oct 2004 13:51:11 +0000 From: bmanning@vacation.karoshi.com To: "D. J. Bernstein" <djb@cr.yp.to> Cc: namedroppers@ops.ietf.org Subject: the uberTXT Message-ID: <20041020135111.GA32727@vacation.karoshi.com.> References: <16756.3478.675039.839347@giles.gnomon.org.uk> <20041018223155.A14DC13E14@sa.vix.com> <20041019122130.GA13615@nic.fr> <1E357E7BA785EFB0D7718B31@[192.168.0.16]> <20041019173246.87621.qmail@cr.yp.to> <5A4B5BBC14254F3C218BD764@[192.168.100.25]> <20041020045937.29931.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041020045937.29931.qmail@cr.yp.to> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mr D.J. Bernstein, Associate Professor, Dpt of Mathmatics, Statistics, and Computer Science, University of Illinois at Chicago, will not receive my reply due to his local policy on acceptance of email. My reply talks to local policy as well as pointing out a possibly defective line of reasoning in his assertions. For the record. > Seems to me that we're doing just fine defining TXT-record formats and > avoiding TXT interoperability problems. Of course, this success comes > from open, honest communication among implementors---the sort of thing > that IETF used to promote and now actively interferes with. sub-typing inside the RDATA section... cool. move the problem from unknown RRtypes to unknown RDATA types.. :) who gets to keep track of the "open honest communication" about the various sub-typing formats so that future implementors can know what do do w/ the contents of RDATA? Must be the IANA. > The bottom line is that TXT succeeds in delivering the data to every > interested client, whereas new record types are a miserable failure. this line of thinking should raise the question - why keep any of the other, now vestigal, RR types... anything we want can be done in the TXT RR. right? > That's a much worse solution than pure TXT records, for several obvious > reasons: (1) for interoperability, everyone will have to provide TXT > records anyway, so the new RR type is extra work for the administrator; er... no. I -dont- have to provide or support TXT records. My zone, my data... > ---D. J. Bernstein, Associate Professor, Department of Mathematics, > Statistics, and Computer Science, University of Illinois at Chicago > -- --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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Oct 20 10:28:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08506 for <dnsext-archive@lists.ietf.org>; Wed, 20 Oct 2004 10:28:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKHPs-0000ZT-Qi for namedroppers-data@psg.com; Wed, 20 Oct 2004 14:26:16 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKHPr-0000YZ-KY for namedroppers@ops.ietf.org; Wed, 20 Oct 2004 14:26:16 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07863; Wed, 20 Oct 2004 10:26:08 -0400 (EDT) Message-Id: <200410201426.KAA07863@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-trustupdate-threshold-00.txt Date: Wed, 20 Oct 2004 10:26:08 -0400 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.64 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 : An In-Band Rollover Mechanism and an Out-Of-Band Priming Method for DNSSEC Trust Anchors. Author(s) : J. Ihren, et al. Filename : draft-ietf-dnsext-trustupdate-threshold-00.txt Pages : 24 Date : 2004-10-19 The DNS Security Extensions (DNSSEC) works by validating so called chains of authority. The start of these chains of authority are usually public keys that are anchored in the DNS clients. These keys are known as the so called trust anchors. This memo describes a method how these client trust anchors can be replaced using the DNS validation and querying mechanisms (in-band) when the key pairs used for signing by zone owner are rolled. This memo also describes a method to establish the validity of trust anchors for initial configuration, or priming, using out of band mechanisms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-trustupdate-threshold-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-trustupdate-threshold-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-trustupdate-threshold-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-20104703.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-trustupdate-threshold-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-trustupdate-threshold-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-20104703.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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Oct 20 11:21:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14132 for <dnsext-archive@lists.ietf.org>; Wed, 20 Oct 2004 11:21:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKIEc-0008K7-5d for namedroppers-data@psg.com; Wed, 20 Oct 2004 15:18:42 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKIEb-0008Jk-1e for namedroppers@ops.ietf.org; Wed, 20 Oct 2004 15:18:41 +0000 Received: from [192.35.166.53] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id i9KFIRo9082323; Wed, 20 Oct 2004 11:18:29 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a06110402bd9c27abc7b2@[192.35.166.53]> In-Reply-To: <20041020135101.6AE5A13E12@sa.vix.com> References: <20041020135101.6AE5A13E12@sa.vix.com> Date: Wed, 20 Oct 2004 11:17:59 -0400 To: Paul Vixie <paul@vix.com> From: Edward Lewis <Ed.Lewis@neustar.biz> Subject: Re: I-D ACTION:draft-iab-dns-choices-00.txt Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.44 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 9:51 -0400 10/20/04, Paul Vixie wrote: >what do you all think NOW? Since you've asked. ;) I think that it's not all bad. The current practice does achieve the goals of minimizing latency, allowing the migration from v4 to v6 (and vice versa) to occur at the edges, is backward compatible with older software, and is resilient. That's a lot of good. There is that nasty cost of double the traffic though, that's a waste. Hindsight isn't always 20-20. Had we pursued multiple queries in a message, we'd have had to deal with the issue of partial results - like, if one query was for (foo.example. IN A) and the other was for (bar.example. IN A) and foo.example. existed and bar.example. did not, how is a half name error returned? Who knows - had we travelled down that road would the WG be wrapped around the axle over AAAAbis by now? Had we thrown the AAAA in the additional section, we may have had problems with the older pass-through servers that might not have known to add the AAAA's when it was needed (answering from a non-authoritative source). We'd have been creating a new type with "special considerations." Summarizing the above - we now have empirical evidence of a pitfall of the option chosen (which I prefer over anticipated concerns) and we have two other options that haven't faced a test. One untried option is a new RR type (e.g., NSADDR) which may have all the glue in one RDATA (one large RDATA section). EDNS0 solves size problems and we could do this as a "try this one, then fallback" for backwards compat. Oops - there's that phrase "then fallback". Maybe not wise course either. I'd say that I'm happy with the bird in hand, even if it leaves me with guano, than the two birds in the tree. I would be happier with the two birds in the tree, but I have to keep asking if the effort to obtain them is worth it considering what I already have. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar "Now under neu management" -- to 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/> From owner-namedroppers@ops.ietf.org Wed Oct 20 11:41:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15545 for <dnsext-archive@lists.ietf.org>; Wed, 20 Oct 2004 11:40:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKIXY-000B9U-8o for namedroppers-data@psg.com; Wed, 20 Oct 2004 15:38:16 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKIXP-000B8L-0X for namedroppers@ops.ietf.org; Wed, 20 Oct 2004 15:38:07 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id C2B9913E12 for <namedroppers@ops.ietf.org>; Wed, 20 Oct 2004 15:38:06 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <vixie@vix.com> To: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-iab-dns-choices-00.txt In-Reply-To: Message from Edward Lewis <Ed.Lewis@neustar.biz> of "Wed, 20 Oct 2004 11:17:59 -0400." <a06110402bd9c27abc7b2@[192.35.166.53]> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 20 Oct 2004 15:38:06 +0000 Message-Id: <20041020153806.C2B9913E12@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > >what do you all think NOW? > > Since you've asked. ;) > > I think that it's not all bad. The current practice does achieve the > goals of minimizing latency, allowing the migration from v4 to v6 (and > vice versa) to occur at the edges, is backward compatible with older > software, and is resilient. if a AAAA response comes in without A RRs in the additional data section and you happen to need them then (and only then) do you have to do another query (for the A RRset). if the servers you're talking to don't support qdcount>1 then you'll have to do multiple queries. both proposals were opportunistic and ended in good balance other than the leftover complexity of having to support qdcount>1 even after IPv4's dead; however, other possibilities exist, like querying for both MX+AAAA, or SRV+AAAA, in various applications like mail transports. so the complexity would not have been truly wasted even after IPv4's dead. > Had we pursued multiple queries in a message, we'd have had to deal with > the issue of partial results - like, if one query was for (foo.example. IN > A) and the other was for (bar.example. IN A) and foo.example. existed and > bar.example. did not, how is a half name error returned? Who knows - had > we travelled down that road would the WG be wrapped around the axle over > AAAAbis by now? the proposal was for qdcount>1, all qname's the same, all qclass's the same, and variant qtype. so your multiple-qname scenario was under prior restraint. > Had we thrown the AAAA in the additional section, we may have had problems > with the older pass-through servers that might not have known to add the > AAAA's when it was needed (answering from a non-authoritative source). > We'd have been creating a new type with "special considerations." the proposal didn't put the AAAA into the additional section, it put A RR's there on qtype=AAAA. just like A RR's go into the additional section on qtype=MX (though there it's the target rather than the owner name). are you reading what i'm writing, ed? > Summarizing the above - we now have empirical evidence of a pitfall of the > option chosen (which I prefer over anticipated concerns) and we have two > other options that haven't faced a test. i don't like your summary. "fear was mongered, several good solutions were quashed, and we got our comeuppance" is a much better summary. but it's just possible that i'm bitter about this, or twisted, or perhaps both. > One untried option is a new RR type (e.g., NSADDR) which may have all > the glue in one RDATA (one large RDATA section). EDNS0 solves size > problems and we could do this as a "try this one, then fallback" for > backwards compat. Oops - there's that phrase "then fallback". Maybe > not wise course either. > > I'd say that I'm happy with the bird in hand, even if it leaves me with > guano, than the two birds in the tree. I would be happier with the two > birds in the tree, but I have to keep asking if the effort to obtain them > is worth it considering what I already have. there are really two questions here. one is just out of bitterness and it goes something "did we do the right thing?" and we all agree it's irrelevant. the other question, though, is relevant: "should we do something different?" with that in mind, here's the current EDNS1 draft, last revised two years ago, containing the qdcount>1 proposal. the historians among y'all know that this text was excised from EDNS0 in order to trim down EDNS0 into something the world could understand and agree on. i apologize for the length -- it's three pages. but the third page is just the references. note that ISC's name has changed since this was last troff'd. --- DNSIND Working Group Paul Vixie INTERNET-DRAFT ISC <draft-ietf-dnsext-edns1-03.txt> August, 2002 Extensions to DNS (EDNS1) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document specifies a number of extensions within the Extended DNS framework defined by [EDNS0], including several new extended label types and the ability to ask multiple questions in a single request. 1 - Rationale and Scope 1.1. EDNS (see [RFC2671]) specifies an extension mechanism to DNS (see [RFC1035]) which provides for larger message sizes, additional label types, and new message flags. 1.2. This document makes use of the EDNS extension mechanisms to add the ability to ask multiple questions in a single request. Expires March 2003 [Page 1] INTERNET-DRAFT EDNS1 August, 2002 2 - Affected Protocol Elements 2.1. Multiple queries in a question section have not been supported in DNS due the applicability of some DNS Message Header flags (such as AA) and of the RCODE field only to a single QNAME, QTYPE, and QCLASS. Multiple questions per request are desirable, and some way of asking them must be made available. 3 - OPT pseudo-RR Flags and Options 3.1. The extended RCODE and flags are structured as follows: +0 (MSB) +1 (LSB) +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 0: | extended-rcode | VERSION | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2: |md |FM |RRD|lm | z | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ VERSION Indicates the implementation level of whoever sets it. Full conformance with the draft standard version of this specification is version ``1.'' Note that both requestors and responders should set this to the highest level they implement, that responders should send back RCODE=BADVERS and that requestors should be prepared to probe using lower version numbers if they receive an RCODE=BADVERS. FM ``First match'' flag. Notable only when multiple questions are present. If set in a request, questions will be processed in wire order and the first question whose answer would have NOERROR AND ANCOUNT>0 is treated as if it were the only question in the query message. Otherwise, questions can be processed in any order and all possible answer records will be included in the response. Response FM should be ignored by requestors. RRD ``Recursion really desired'' flag. Notable only when a request is processed by an intermediate name server (``forwarder'') who is not authoritative for the zone containing QNAME, and where QTYPE=ANY or QDCOUNT>1. If set in a request, the intermediate name server can only answer using unexpired cached answers (either positive or negative) which were atomically acquired using (a) the same QTYPE or set of QTYPEs present in the current question and whose TTLs were each minimized to the Expires March 2003 [Page 2] INTERNET-DRAFT EDNS1 August, 2002 smallest among them when first cached, and (b) the same FM and LM settings present in the current question. Z Set to zero by senders and ignored by receivers, unless modified in a subsequent specification. 4 - Multiple Questions for QUERY 4.1. If QDCOUNT>1, multiple questions are present. All questions must be for the same QNAME and QCLASS; only the QTYPE is allowed to vary. It is an error for QDCOUNT>1 and any QTYPE=ANY or QCLASS=ANY. 4.2. RCODE and AA apply to all RRs in the answer section having the QNAME that is shared by all questions in the question section. AA applies to all matching answers, and will not be set unless the exact original request was processed by an authoritative server and the response forwarded in its entirety. 4.3. If a multiple question request is processed by an intermediate server and the authority server does not support multiple questions, the intermediate server must generate an answer iteratively by making multiple requests of the authority server. In this case, AA must never be set in the final answer due to lack of atomicity of the contributing authoritative responses. 4.4. If iteratively processing a multiple question request using an authority server which can only process single question requests, if any contributing request generates a SERVFAIL response, then the final response's RCODE should be SERVFAIL. 4.5. An authority server processing a query for which QDCOUNT>1 will respond with a delegation or referral if any of the multiple QTYPEs present would yield such a response when QDCOUNT==1. 4.6. An initiator can infer the absence of any RRs for one of the QTYPEs where QDCOUNT>1 if the response contains no RRs of that type but some RRs for one of the other QTYPEs present. Expires March 2003 [Page 3] INTERNET-DRAFT EDNS1 August, 2002 5 - References [RFC1035] P. Mockapetris, ``Domain Names - Implementation and Specification,'' RFC 1035, USC/Information Sciences Institute, November 1987. [RFC2671] P. Vixie, ``Extension mechanisms for DNS (EDNS0),'' RFC 2671, IETF DNSIND, September 1998 6 - Author's Address Paul Vixie Internet Software Consortium 950 Charter Street Redwood City, CA 94063 +1.650.779.7001 <vixie@isc.org> Expires March 2003 [Page 4] --- -- to 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/> From owner-namedroppers@ops.ietf.org Wed Oct 20 11:45:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16157 for <dnsext-archive@lists.ietf.org>; Wed, 20 Oct 2004 11:45:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKIcO-000BsS-05 for namedroppers-data@psg.com; Wed, 20 Oct 2004 15:43:16 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKIcM-000Bs7-QK for namedroppers@ops.ietf.org; Wed, 20 Oct 2004 15:43:15 +0000 Received: from [192.35.166.53] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id i9KFh8ir082435 for <namedroppers@ops.ietf.org>; Wed, 20 Oct 2004 11:43:09 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a06110405bd9c34b2735b@[192.35.166.53]> In-Reply-To: <20041020135111.GA32727@vacation.karoshi.com.> References: <20041020135111.GA32727@vacation.karoshi.com.> Date: Wed, 20 Oct 2004 11:43:14 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis <Ed.Lewis@neustar.biz> Subject: Re: the uberTXT Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.44 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >> The bottom line is that TXT succeeds in delivering the data to every >> interested client, whereas new record types are a miserable failure. > > this line of thinking should raise the question - why keep > any of the other, now vestigal, RR types... anything we want > can be done in the TXT RR. right? Peace folks. The argument here is not head to head. One set of words reflects the way it is now. The other set of words is motivated by what may lie ahead. I really want to encourage the continual movement towards an architectural correct DNS. Without that, the system will become unmanageable and will be forced into stagnation from an engineering viewpoint. But reformation comes at a cost - we can't shutdown the DNS for a week, have a flag day, instructing all uses of DNS software upgrade on a dime. For this, we have to give a nod to doing some undesirable things, undesirable from the point of view of an architectural purist. What's missing from the discussion is how the DNS engineering community helps lead the communities using DNS to reform their ways when it comes to using DNS. (E.g., what can be done to get application developers to not hold DNS data beyond the TTL recommendation?) This is the answer to the "we gotta use TXT cause it works today," not retorting with "relying on the TXT means we can remove all other types." I can't imagine any engineer worth their salt would want a system to stagnate. I can imagine an engineer doing everything possible to continue to offer support to users, even if this means stagnation might look like the best approach. That is why I think the draft ought to recognize that it is preferable to extend via new types and ought to acknowledge that reusing TXT, although discouraged, has a legitimate role in DNS work. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar "Now under neu management" -- to 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/> From owner-namedroppers@ops.ietf.org Wed Oct 20 12:02:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17535 for <dnsext-archive@lists.ietf.org>; Wed, 20 Oct 2004 12:02:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKItJ-000F01-QA for namedroppers-data@psg.com; Wed, 20 Oct 2004 16:00:45 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKItI-000Ezj-O0 for namedroppers@ops.ietf.org; Wed, 20 Oct 2004 16:00:45 +0000 Received: from [192.35.166.53] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id i9KG0crd082514 for <namedroppers@ops.ietf.org>; Wed, 20 Oct 2004 12:00:39 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a06110406bd9c394c873d@[192.35.166.53]> In-Reply-To: <20041020153806.C2B9913E12@sa.vix.com> References: <20041020153806.C2B9913E12@sa.vix.com> Date: Wed, 20 Oct 2004 12:00:45 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis <Ed.Lewis@neustar.biz> Subject: A/AAAA was Re: I-D ACTION:draft-iab-dns-choices-00.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.44 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:38 -0400 10/20/04, Paul Vixie wrote: >the proposal didn't put the AAAA into the additional section, it put A RR's >there on qtype=AAAA. just like A RR's go into the additional section on >qtype=MX (though there it's the target rather than the owner name). are >you reading what i'm writing, ed? Yes. Although I was around during the discussions then, I didn't get all that into the topic. After starting in on DNSSEC in 1996 (and having a history in other lookup systems), I can now say that I didn't really come to understand the DNS protocol until about 2002 or 2003. I'm still not sure I really understand all of it now. I mention this to say that I don't bear scars of those discussions. I may have caused some. >i don't like your summary. "fear was mongered, several good solutions were >quashed, and we got our comeuppance" is a much better summary. but it's >just possible that i'm bitter about this, or twisted, or perhaps both. And that may well be - and for justifiable reasons. What I've learned is to have a short memory when it comes to the debate over arriving at a solution. A decision was made a while back. It's water under the bridge. The question that we need to focus on is, as always in engineering "where do we go from here?" Do we want to revive the effort to "fix" the situation? Do we want to revive the effort to "fix" the situation *now*? Personally - I think the answer to the last question is no - not *now* - as we try to determine if DNSSECbis is a success. I think we can live with the hit we see now. (But that is not what tipped off the thread.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar "Now under neu management" -- to 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/> From owner-namedroppers@ops.ietf.org Thu Oct 21 14:27:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02667 for <dnsext-archive@lists.ietf.org>; Thu, 21 Oct 2004 14:27:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKhYw-000Fnh-1T for namedroppers-data@psg.com; Thu, 21 Oct 2004 18:21:22 +0000 Received: from [65.205.251.74] (helo=colibri.verisign.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKhYv-000FnN-43 for namedroppers@ops.ietf.org; Thu, 21 Oct 2004 18:21:21 +0000 Received: from mou1wnexc01.vcorp.ad.vrsn.com (mailer4.verisign.com [65.205.251.53]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i9LILKRW006366 for <namedroppers@ops.ietf.org>; Thu, 21 Oct 2004 11:21:20 -0700 (PDT) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <VCDJ7HCM>; Thu, 21 Oct 2004 11:21:20 -0700 Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E01BD5782@mou1wnexm05.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" <pbaker@verisign.com> To: namedroppers@ops.ietf.org Subject: RE: I-D ACTION:draft-iab-dns-choices-00.txt Date: Thu, 21 Oct 2004 11:21:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Ed Lewis writes: > My motivation is not to do this for the sake of academic > protocol/architectural purity. My motivation is to move the DNS into > position for future efforts (via having a pure protocol/architecture). This is my motivation as well. But I believe I am starting from a considerably wider view of what that oppportunity is and how we can best get there. I am viewing the problem in terms of critical paths. If the DNSEXT group insists on placing deployment on my critical path then I am going to do everything I can to prevent their advice being taken. I would hope that most people would understand why I am not going to allow IPv6 to be placed in my critical path. New RRs fall in the same category. However much you like them they do nothing for me and it is my community that has the pain points and the industry consensus that are the ingredients of a killer app. The document is a rather transparent attempt to try recourse to authority. To play that game you should really understand what your hand is. I don't claim to be the best engineer here. But I am a whole lot more experienced at communicating with the people who have the decision power which is not the IESG or the IAB. >Speaking from the experience of talking with the MARID group and also >from observing the behavior of one popular DNS implementation, >relying on a strategy of "try one, if it fails, try the other" is not >going to be well received. Ed tried his best, but the agreement in the room for Ted's proposal was on the understanding on the part of the implementors that it would change nothing in practice. Nobody expected a significant number of sites to use the new RR for at least ten years. And regardless of what the spec said nobody seriously intended to implement a serial scheme where the RR is tried first with fallback to TXT. At best the systems would do it in parallel. If you think it terrible that people would ignore authority in this way then ask yourself what was ever done to justify that authority. Dan Bernstein writes: >We already have encouragement. I already quoted the relevant sections of >RFC 1034 and RFC 1123. I wouldn't object to yet another document making >crystal clear that BIND and NSD and Microsoft screwed up and that we >really want to get rid of this problem before 2010. Is that what people would consider a reasonable data for requiring servers to deploy new RR types? I am not opposed to the use of new RR types, in fact there are some proposals in that regard that I do want to make - XML resource records for example. Pekka writes: >Unless we use it, nothing is going to change in the next 10 years. So, that does not give you the right to tie your ornaments to my Christmass tree. And that is the precise analogy I have been raising in the policy area. >By the way, as it appears a lot of people are breaking DNS >specifications pretty badly, I wonder if it would make sense to try to >come up with some kind DNS implementation requirements document, >similar to "host requirements" a long time ago, but updated with >respect to new specs.. this would be a lot of work, but it might be >worth it if we want to decrease the amount of completely broken DNS >implementations out there. I do not believe yet another document will do anything. What we need is compliance testing. The failure of the IETF to address this area is understandable, hey testing is what real engineers do, it does not get you tenure. But that is what is needed in the real world. Paul writes: > if new rr's take too long on deployment to be useful for new globally > deployed services and service models to be practical, somebody had > better tell microsoft that using SRV was a mistake. Microsofts use is a bad example. Microsoft use SRV to configure windows in an environment where Windows is the infrastructure. To take advantage of the SRV all your infrastructure has to have been upgraded already. -- to 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/> From owner-namedroppers@ops.ietf.org Thu Oct 21 15:38:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11319 for <dnsext-archive@lists.ietf.org>; Thu, 21 Oct 2004 15:38:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKihA-0002Pc-4V for namedroppers-data@psg.com; Thu, 21 Oct 2004 19:33:56 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKih9-0002PM-2E for namedroppers@ops.ietf.org; Thu, 21 Oct 2004 19:33:55 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10889; Thu, 21 Oct 2004 15:33:51 -0400 (EDT) Message-Id: <200410211933.PAA10889@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-mdns-37.txt Date: Thu, 21 Oct 2004 15:33:51 -0400 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Linklocal Multicast Name Resolution (LLMNR) Author(s) : L. Esibov, et al. Filename : draft-ietf-dnsext-mdns-37.txt Pages : 26 Date : 2004-10-21 Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a Domain Name System (DNS) server. The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache. Since LLMNR only operates on the local link, it cannot be considered a substitute for DNS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-37.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-mdns-37.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-mdns-37.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: <2004-10-21154037.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-37.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-37.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-21154037.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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Oct 21 19:01:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22289 for <dnsext-archive@lists.ietf.org>; Thu, 21 Oct 2004 19:01:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKlrh-0008wK-Pm for namedroppers-data@psg.com; Thu, 21 Oct 2004 22:57:01 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKlrh-0008w1-1h for namedroppers@ops.ietf.org; Thu, 21 Oct 2004 22:57:01 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 60742677E9 for <namedroppers@ops.ietf.org>; Thu, 21 Oct 2004 22:57:00 +0000 (UTC) (envelope-from marka@drugs.dv.isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id i9LMuug5041828 for <namedroppers@ops.ietf.org>; Fri, 22 Oct 2004 08:56:57 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200410212256.i9LMuug5041828@drugs.dv.isc.org> To: namedroppers@ops.ietf.org From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: I-D ACTION:draft-iab-dns-choices-00.txt In-reply-to: Your message of "Thu, 21 Oct 2004 11:21:15 MST." <C6DDA43B91BFDA49AA2F1E473732113E01BD5782@mou1wnexm05.vcorp.ad.vrsn.com> Date: Fri, 22 Oct 2004 08:56:56 +1000 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Hallam-Baker, Phillip" writes: > Paul writes: > > if new rr's take too long on deployment to be useful for new globally > > deployed services and service models to be practical, somebody had > > better tell microsoft that using SRV was a mistake. > > Microsofts use is a bad example. Microsoft use SRV to configure windows > in an environment where Windows is the infrastructure. To take > advantage of the SRV all your infrastructure has to have been > upgraded already. Well lets look at another example AAAA. The ends that wanted to use AAAA upgraded their servers and apart from a few load balancers, which also usually didn't handle SOA/NS/MX records, there were no major problems. AAAA as we know required much more than just adding a new rdata type. AAAA deployment has also weeded out most of the bad servers so later deployment of new types should go smoother. I don't know about the other developers but BIND 9 is designed to allow for the easy addition of new RR types. Write a pair of files (.c,.h) that describe the wire and text formats, additional processing rules etc. Recompile and you are done. IPSECKEY did just that to test out the new RR type. Mark -- Mark Andrews, ISC 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Oct 22 09:04:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00717 for <dnsext-archive@lists.ietf.org>; Fri, 22 Oct 2004 09:04:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKz1E-000Nnf-2X for namedroppers-data@psg.com; Fri, 22 Oct 2004 12:59:44 +0000 Received: from [65.205.251.75] (helo=robin.verisign.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKz1D-000NnO-BU for namedroppers@ops.ietf.org; Fri, 22 Oct 2004 12:59:43 +0000 Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i9MCxfrZ010045; Fri, 22 Oct 2004 05:59:42 -0700 (PDT) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <476C5G7K>; Fri, 22 Oct 2004 05:59:41 -0700 Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BECBD@mou1wnexm05.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" <pbaker@verisign.com> To: "'Mark Andrews'" <Mark_Andrews@isc.org>, namedroppers@ops.ietf.org Subject: RE: I-D ACTION:draft-iab-dns-choices-00.txt Date: Fri, 22 Oct 2004 05:59:35 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Mark Andrews > "Hallam-Baker, Phillip" writes: > > Paul writes: > > > if new rr's take too long on deployment to be useful for > new globally > > > deployed services and service models to be practical, somebody had > > > better tell microsoft that using SRV was a mistake. > > > > Microsofts use is a bad example. Microsoft use SRV to > configure windows > > in an environment where Windows is the infrastructure. To take > > advantage of the SRV all your infrastructure has to have been > > upgraded already. > > Well lets look at another example AAAA. The ends that > wanted to use AAAA upgraded their servers and apart from a > few load balancers, which also usually didn't handle SOA/NS/MX > records, there were no major problems. AAAA as we know > required much more than just adding a new rdata type. If it is that easy then why don't you go get everyone to deploy and let me know when you are finished. Just get off my critical path until you are done. If Ipv6 is the best example you can propose then I guess we don't need to argue this any more. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Oct 22 09:19:53 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01863 for <dnsext-archive@lists.ietf.org>; Fri, 22 Oct 2004 09:19:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKzHe-00019L-Od for namedroppers-data@psg.com; Fri, 22 Oct 2004 13:16:42 +0000 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKzHd-000193-Ri for namedroppers@ops.ietf.org; Fri, 22 Oct 2004 13:16:42 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 8A35C26C098; Fri, 22 Oct 2004 15:16:40 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 3A4C826C0A4; Fri, 22 Oct 2004 15:16:39 +0200 (CEST) Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id i9MDGd8q949298; Fri, 22 Oct 2004 15:16:39 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 01021FE5C; Fri, 22 Oct 2004 15:16:38 +0200 (CEST) Date: Fri, 22 Oct 2004 15:16:38 +0200 From: Stephane Bortzmeyer <bortzmeyer@nic.fr> To: "Hallam-Baker, Phillip" <pbaker@verisign.com> Cc: "'Mark Andrews'" <Mark_Andrews@isc.org>, namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-iab-dns-choices-00.txt Message-ID: <20041022131638.GA21498@nic.fr> References: <C6DDA43B91BFDA49AA2F1E473732113E010BECBD@mou1wnexm05.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <C6DDA43B91BFDA49AA2F1E473732113E010BECBD@mou1wnexm05.vcorp.ad.vrsn.com> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.26-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040818i X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, Oct 22, 2004 at 05:59:35AM -0700, Hallam-Baker, Phillip <pbaker@verisign.com> wrote a message of 38 lines which said: > > Well lets look at another example AAAA. ... > If Ipv6 is the best example you can propose then I guess > we don't need to argue this any more. Mark Andrews mentioned the deployment of AAAA-capable servers and clients (which is quite advanced), not the deployment of IPv6-capable hosts and routers, which is far from being 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Oct 22 10:24:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08290 for <dnsext-archive@lists.ietf.org>; Fri, 22 Oct 2004 10:24:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CL0Hk-000CjB-NT for namedroppers-data@psg.com; Fri, 22 Oct 2004 14:20:52 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CL0Hf-000Cie-W4 for namedroppers@ops.ietf.org; Fri, 22 Oct 2004 14:20:48 +0000 Received: from [193.133.15.218] (ben-xp2.ben.algroup.co.uk [193.133.15.218]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 19B028B825; Fri, 22 Oct 2004 14:20:47 +0000 (GMT) Message-ID: <41791746.4070804@algroup.co.uk> Date: Fri, 22 Oct 2004 15:20:54 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Bligh <alex@alex.org.uk> Cc: DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: Requirements Matrix References: <4163ECA7.8050404@algroup.co.uk> <55A312B840C3132BF37F4AE8@[192.168.100.25]> <41653994.6030801@algroup.co.uk> <6F936124E48E2E71F58327C0@[192.168.100.25]> In-Reply-To: <6F936124E48E2E71F58327C0@[192.168.100.25]> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Apologies for the delay. I am now updating the requirements I-D and matrix. Alex Bligh wrote: > Ben, > >>> I did a matrix transpose and found out what happened: > > > OK you disagreed with my three guesses as to what the correct states > were here, but that still means you have to fix the transpose entry. > EG if 17 is indeed incompatible with 7, 7 should be marked as > incompatible with 17 (it isn't), ditto for 7/10 and 9/10 (i.e. > they should be resolved the same way whichevever is on the H&V axes). Indeed, I have updated the matrix. > On the substantive points: > >> Again, in the sense that no proposal reconciles them, they are. > > OK I had read "No proposal exists to reconcile these two, nor is it obvious > they can be" to mean "No proposal exists to reconcile these two, nor is it > obvious that any route exists unknown or otherwise to reconcile them" (i.e. > that whilst we haven't proved they are incompatible, it seems pretty > unlikely they will be). Perhaps I misread. It might be clearer if you > said "Reconciliation is non-obvious and currently unknown, but may > be possible" - i.e. you mean "these are work items" not "don't bother > to dig here". No, I meant what you said. >>> It is possible to read the zone enumeration requirements as mandatorily >>> applying to all zones, AND to read "incompatible" (in 26) as meaning "if >>> any resolver implementing DNSSECbis NSEC only - not NSEC++ - cannot >>> interpret the responses then it's failed the test" THEN clearly we >>> have a >>> problem. If that's what the red square means, I understand it, but it's >>> not particularly useful. >> >> It is what it means, IMO. > > OK - from my "zone enumeration requirement" (and I thought from > Nominet's) I did NOT mean "no zones should be enumerable", I meant > "the server operator should have the option of preventing given > zones being enumerable). This then is not incompatible with (say) > 20 (NSEC compatibility) as it can be achieved by making use of NSEC++ > optional, and mandating that resolvers that support NSEC++ also > support NSEC. That would be a "change incompatible with NSEC" (i.e. 20). >> The essence here is that these points are meant to convey the idea that >> it would be nice if we could do NSEC++ without having to change the >> world. I do not believe that is (currently) possible. > > OK, that's "compatibility with NSEC only resolvers" not "compatibility > with NSEC only servers". Well, since the requirement was "compatability with NSEC", I think we can take that to mean both clients and servers. >>> It /might/ be possible (in essence through permitting responses >>> currently >>> prohibited by DNSSEC-bis in a manner which cannot harm any compliant >>> DNSSEC-bis resolver) to have a zone constructed for NSEC++ signing still >>> return authenticated records other than NSEC records for resolvers >>> supporting DNSSEC-bis (& NSEC) but not NSEC++. I am not saying it *is* >>> possible, I just don't think anyone's conclusively demonstrated that >>> it's >>> not. >> >> This point I don't understand. I have a version of BIND running that does >> exactly this - i.e. returns NSEC2 records. An "old" resolver will not >> understand the responses, and so will treat NXDOMAIN/NODATA as >> unauthenticated denials. > > > That's because of how you implemented it! > > In a handwaving way (deliberately to avoid details :-) ) if it were > the case that an NSEC++ supporting resolver made queries in a different > way to servers in such a way as to flag their support for NSEC++, > then an NSEC++ supporting server could return > a) NSEC++ records for NSEC++ supporting resolverd > b) for non-supporting resolvers, either: > i) NSEC records (if people don't care about zone enumeration) or > ii) pretend to be a non-DNSSEC-bis server (if people do care > about zone enumeration). > > What I'm saying /might/ be possible (under b(ii)) is to pretend to > have a split personality - as a dreadful hack, for instance, return > the correct records for records that exist, and return SERVFAIL > instead of NSEC where things don't exist (yuck!). As an NSEC (not > NSEC++) resolver has to cope with SERVFAIL anyway, it's not going > to break any compliant resolver. I know SERVFAIL isn't the way to do > it, but what I'm saying is I don't think it's been shown there is > NO way to do b(ii). Then you still have old resolvers getting unauthenticated denials. >> I think you are missing an essential point. The server does not get to >> choose what is returned in a replay attack, the attacker does. So, the >> logical consequence of your argument is that the server would always have >> to use the "identity" hash (since it cannot know what the QNAME is), i.e. >> NSEC, and that makes it incompatible, as stated. > > Why can the server not know what the QNAME is, if you so design the > protocol? You are assuming the server is ONLY passed the hashed value, > and not (hashedvalue,QNAME). I am not making that assumption. That > may be undesirable for other reasons (granted), but my point is that > solving the problem is not impossible. The point is that you are attempting to protect against a replay attack. In a replay attack, the attacker chooses the response, so the server is not at liberty to formulate a response based on the QNAME in the query. >>> So >>> what I'm saying is that non-obvious zone size estimates could possibly >>> live with NSEC++ if you were using NSEC++ only for partially signed >>> zones, so I'm not sure the clash marked with (say) 27 is correct. >> >> Then the size of the signed zone would be apparent, which I believe is in >> the spirit of the requirement. > > > I'm missing something: why would the size of the zone be apparent (or > rather any more apparent) if you were using NSEC++ only to implement > partially signed zones (i.e. used identity hashes)? You get no more > information than out of NSEC records - in fact you get rather less > as the zone is only partially signed. The size of the _signed_ part of the zone would be apparent. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to 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/> From owner-namedroppers@ops.ietf.org Fri Oct 22 10:52:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11352 for <dnsext-archive@lists.ietf.org>; Fri, 22 Oct 2004 10:52:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CL0jp-000Hrz-EZ for namedroppers-data@psg.com; Fri, 22 Oct 2004 14:49:53 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CL0jo-000Hri-CH for namedroppers@ops.ietf.org; Fri, 22 Oct 2004 14:49:52 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 5154F677EF for <namedroppers@ops.ietf.org>; Fri, 22 Oct 2004 14:49:51 +0000 (UTC) (envelope-from marka@drugs.dv.isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id i9MEnlTk036799; Sat, 23 Oct 2004 00:49:47 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200410221449.i9MEnlTk036799@drugs.dv.isc.org> To: "Hallam-Baker, Phillip" <pbaker@verisign.com> Cc: namedroppers@ops.ietf.org From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: I-D ACTION:draft-iab-dns-choices-00.txt In-reply-to: Your message of "Fri, 22 Oct 2004 05:59:35 MST." <C6DDA43B91BFDA49AA2F1E473732113E010BECBD@mou1wnexm05.vcorp.ad.vrsn.com> Date: Sat, 23 Oct 2004 00:49:47 +1000 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > > > From: owner-namedroppers@ops.ietf.org > > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Mark Andrews > > > "Hallam-Baker, Phillip" writes: > > > Paul writes: > > > > if new rr's take too long on deployment to be useful for > > new globally > > > > deployed services and service models to be practical, somebody had > > > > better tell microsoft that using SRV was a mistake. > > > > > > Microsofts use is a bad example. Microsoft use SRV to > > configure windows > > > in an environment where Windows is the infrastructure. To take > > > advantage of the SRV all your infrastructure has to have been > > > upgraded already. > > > > Well lets look at another example AAAA. The ends that > > wanted to use AAAA upgraded their servers and apart from a > > few load balancers, which also usually didn't handle SOA/NS/MX > > records, there were no major problems. AAAA as we know > > required much more than just adding a new rdata type. > > If it is that easy then why don't you go get everyone to > deploy and let me know when you are finished. Just get off > my critical path until you are done. > > If Ipv6 is the best example you can propose then I guess > we don't need to argue this any more. I choose AAAA because it was a example where there are literally millions of clients making queries today and there is basically no problems despite clients making queries to servers that don't know how to serve AAAA. Every time we add a new RR type people say it can't be done. It will take to long to upgrade all the servers. Guess what you don't have to upgrade all the servers. Guess what you get servers capable of serving the new type in weeks, if not days or earlier of the type definition being finalised. After that it is up to the people who want to use the type to upgrade there servers. I've never been worried about the ability to deploy new types. We did it wrong the first few times by allowing compression of rdata but we are well past that now. If we had listened to the naysayers none of RP, AFSDB, X25, ISDN, RT, NSAP, NSAP-PTR, SIG, KEY PX, GPOS, AAAA, LOC, NXT, EID, NIMLOC, SRV, ATMA, NAPTR, DNSKEY, NSEC and RRSIG would have deployed. Some of them are not used much but there are servers available for all of them. As for marid the people you need to convince are the SMTP developers. You need to convince them to move to a new type *and* to rip out the old TXT based code. If you don't do the later changover will take a long time as people will continue to use the TXT based crutch. Pull the crutch away and they will use the new type. I realise that by doing this forgeries will get through that would otherwise be caught but a little short term pain is better that a long drawn out transition. I'm seeing the same thing w/ the IP6.INT -> IP6.ARPA transition. It is taking a long time because people left the IP6.INT crutch in place. We really should not be shipping resolvers that use IP6.INT. Stop making the old lookups and the new records will appear. Mark -- Mark Andrews, ISC 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Oct 22 11:09:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12391 for <dnsext-archive@lists.ietf.org>; Fri, 22 Oct 2004 11:09:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CL0za-000LOD-Vv for namedroppers-data@psg.com; Fri, 22 Oct 2004 15:06:10 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CL0zW-000LMd-VT for namedroppers@ops.ietf.org; Fri, 22 Oct 2004 15:06:07 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id i9MF63wP008931; Fri, 22 Oct 2004 15:06:03 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id i9MF63et008928; Fri, 22 Oct 2004 15:06:03 GMT Date: Fri, 22 Oct 2004 15:06:03 +0000 From: bmanning@vacation.karoshi.com To: Mark Andrews <Mark_Andrews@isc.org> Cc: "Hallam-Baker, Phillip" <pbaker@verisign.com>, namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-iab-dns-choices-00.txt Message-ID: <20041022150603.GA8910@vacation.karoshi.com.> References: <C6DDA43B91BFDA49AA2F1E473732113E010BECBD@mou1wnexm05.vcorp.ad.vrsn.com> <200410221449.i9MEnlTk036799@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200410221449.i9MEnlTk036799@drugs.dv.isc.org> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I'm seeing the same thing w/ the IP6.INT -> IP6.ARPA > transition. It is taking a long time because people left > the IP6.INT crutch in place. We really should not be > shipping resolvers that use IP6.INT. Stop making the old > lookups and the new records will appear. > > Mark Andrews, ISC actually, when the queries stop (e.g. the old resolvers are upgraded) the servers will be turned off. the new delegations (and by extention RR types) need to be visable first. --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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Oct 22 12:20:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17656 for <dnsext-archive@lists.ietf.org>; Fri, 22 Oct 2004 12:20:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CL24j-0008KF-F0 for namedroppers-data@psg.com; Fri, 22 Oct 2004 16:15:33 +0000 Received: from [65.205.251.75] (helo=robin.verisign.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CL24c-0008JP-KU for namedroppers@ops.ietf.org; Fri, 22 Oct 2004 16:15:26 +0000 Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i9MGFNuk021440; Fri, 22 Oct 2004 09:15:23 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <VCCX1K6Y>; Fri, 22 Oct 2004 09:15:23 -0700 Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BECBE@mou1wnexm05.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" <pbaker@verisign.com> To: "'bmanning@vacation.karoshi.com'" <bmanning@vacation.karoshi.com>, Mark Andrews <Mark_Andrews@isc.org> Cc: "Hallam-Baker, Phillip" <pbaker@verisign.com>, namedroppers@ops.ietf.org Subject: RE: I-D ACTION:draft-iab-dns-choices-00.txt Date: Fri, 22 Oct 2004 09:15:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > -----Original Message----- > From: bmanning@vacation.karoshi.com > > I'm seeing the same thing w/ the IP6.INT -> IP6.ARPA > > transition. It is taking a long time because people left > > the IP6.INT crutch in place. We really should not be > > shipping resolvers that use IP6.INT. Stop making the old > > lookups and the new records will appear. > > > > Mark Andrews, ISC > > actually, when the queries stop (e.g. the old resolvers > are upgraded) the servers will be turned off. the new > delegations (and by extention RR types) need to be visable > first. The community that is doing deployment of IPv6 is somewhat more technically astute than the average ISP netop. If you are suggesting kicking away crutches from people who need them then you really are not going to be much help. Outside MIT LCS/AI and the IETF the idea of making a specification into an intelligence test is not very popular. The timescale that a solution has to be deployed in is very tight, we have a large number of criminal gangs that are stealing the life savings of seniors, many of whom do not exactly have the best mental faculties at this point. The reason that we have to redo PGP and S/MIME in the first place is that people were desiging systems to amuse themselves not protect real people from real risks. I am dealling with security for real people, not for geeks. -- to 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/> From owner-namedroppers@ops.ietf.org Fri Oct 22 16:09:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06153 for <dnsext-archive@lists.ietf.org>; Fri, 22 Oct 2004 16:09:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CL5dO-00034j-RC for namedroppers-data@psg.com; Fri, 22 Oct 2004 20:03:34 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CL5dN-00034I-M0 for namedroppers@ops.ietf.org; Fri, 22 Oct 2004 20:03:33 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05457; Fri, 22 Oct 2004 16:03:32 -0400 (EDT) Message-Id: <200410222003.QAA05457@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-signed-nonexistence-requirements-01.txt Date: Fri, 22 Oct 2004 16:03:31 -0400 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.64 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 : Requirements related to DNSSEC Signed Proof of Non-Existence Author(s) : B. Laurie, R. Loomis Filename : draft-ietf-dnsext-signed-nonexistence-requirements-01.txt Pages : 11 Date : 2004-10-22 DNSSEC-bis uses the NSEC record to provide authenticated denial of existence of RRsets. NSEC also has the side-effect of permitting zone enumeration, even if zone transfers have been forbidden. Because some see this as a problem, this document has been assembled to detail the possible requirements for denial of existence A/K/A signed proof of non-existence. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-signed-nonexistence-requirements-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-22161747.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-signed-nonexistence-requirements-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-22161747.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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Oct 22 17:38:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22733 for <dnsext-archive@lists.ietf.org>; Fri, 22 Oct 2004 17:38:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CL73N-000JGT-Hy for namedroppers-data@psg.com; Fri, 22 Oct 2004 21:34:29 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CL73M-000JGG-OD for namedroppers@ops.ietf.org; Fri, 22 Oct 2004 21:34:28 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 0053E677EC for <namedroppers@ops.ietf.org>; Fri, 22 Oct 2004 21:34:27 +0000 (UTC) (envelope-from marka@drugs.dv.isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id i9MLYMdd039419; Sat, 23 Oct 2004 07:34:22 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200410222134.i9MLYMdd039419@drugs.dv.isc.org> To: bmanning@vacation.karoshi.com Cc: "Hallam-Baker, Phillip" <pbaker@verisign.com>, namedroppers@ops.ietf.org From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: I-D ACTION:draft-iab-dns-choices-00.txt In-reply-to: Your message of "Fri, 22 Oct 2004 15:06:03 GMT." <20041022150603.GA8910@vacation.karoshi.com.> Date: Sat, 23 Oct 2004 07:34:22 +1000 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > I'm seeing the same thing w/ the IP6.INT -> IP6.ARPA > > transition. It is taking a long time because people left > > the IP6.INT crutch in place. We really should not be > > shipping resolvers that use IP6.INT. Stop making the old > > lookups and the new records will appear. > > > > Mark Andrews, ISC > > actually, when the queries stop (e.g. the old resolvers > are upgraded) the servers will be turned off. the new > delegations (and by extention RR types) need to be visable > first. > > --bill The problem is that new resolvers try IP6.ARPA then if they don't get a answer they try IP6.INT. You will never see the IP6.INT queries drop off as there will always be a significant number of addresses that have neither a IP6.ARPA or IP6.INT PTR record. The only way out of this is for OS vendors to be brave enough to stop using IP6.INT as a crutch or for someone to be brave enough to put in "IP6.INT DNAME IP6.ARPA". Once that is done you can say to the OS vendors that it is now pointless to try IP6.INT if you don't get a IP6.ARPA response and the later can't exist. Look like KAME has bitten the bullet. Hopefully the rest will follow. The following is from FreeBSD. Note: I havn't checked any of the others. MFC: now e.f.f.3.ip6.arpa is delegated, we no longer need to query ip6.int Mark -- Mark Andrews, ISC 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Oct 22 18:03:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27853 for <dnsext-archive@lists.ietf.org>; Fri, 22 Oct 2004 18:03:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CL7SS-000NWP-8n for namedroppers-data@psg.com; Fri, 22 Oct 2004 22:00:24 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CL7SR-000NW9-Db for namedroppers@ops.ietf.org; Fri, 22 Oct 2004 22:00:23 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 648EB677ED for <namedroppers@ops.ietf.org>; Fri, 22 Oct 2004 22:00:22 +0000 (UTC) (envelope-from marka@drugs.dv.isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id i9MM0JdD039675; Sat, 23 Oct 2004 08:00:20 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200410222200.i9MM0JdD039675@drugs.dv.isc.org> To: "Hallam-Baker, Phillip" <pbaker@verisign.com> Cc: "'bmanning@vacation.karoshi.com'" <bmanning@vacation.karoshi.com>, namedroppers@ops.ietf.org From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: I-D ACTION:draft-iab-dns-choices-00.txt In-reply-to: Your message of "Fri, 22 Oct 2004 09:15:21 MST." <C6DDA43B91BFDA49AA2F1E473732113E010BECBE@mou1wnexm05.vcorp.ad.vrsn.com> Date: Sat, 23 Oct 2004 08:00:19 +1000 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > -----Original Message----- > > From: bmanning@vacation.karoshi.com > > > I'm seeing the same thing w/ the IP6.INT -> IP6.ARPA > > > transition. It is taking a long time because people left > > > the IP6.INT crutch in place. We really should not be > > > shipping resolvers that use IP6.INT. Stop making the old > > > lookups and the new records will appear. > > > > > > Mark Andrews, ISC > > > > actually, when the queries stop (e.g. the old resolvers > > are upgraded) the servers will be turned off. the new > > delegations (and by extention RR types) need to be visable > > first. > > The community that is doing deployment of IPv6 is somewhat more > technically astute than the average ISP netop. > > If you are suggesting kicking away crutches from people who need > them then you really are not going to be much help. Outside MIT > LCS/AI and the IETF the idea of making a specification into > an intelligence test is not very popular. We are not making it a intellegence test. It will be the same as it is today. You will go to a site and follow the instructions there. How to publish. * Upgrade your nameserver to one which is XXXX capable Here is a list of servers which are capable. <list of nameservers> If you are running the following OS the nameserver that ships with the OS is XXXX capable. <list of OS's> * use our tool to create the relevent record and add it to the zone. How to use * Upgrade you mail server to a XXXX capable server <list of MTA> Most caching servers out there today are capable of handling the new record type. Once you have setup your MTA here is a email address that will attempt to send you a fake email. It will have the following content. If it gets through you have misconfigured your mail server or you need to upgrade your nameserver. > The timescale that a solution has to be deployed in is very > tight, we have a large number of criminal gangs that are stealing > the life savings of seniors, many of whom do not exactly have the > best mental faculties at this point. > > The reason that we have to redo PGP and S/MIME in the first place > is that people were desiging systems to amuse themselves not protect > real people from real risks. I am dealling with security for real > people, not for geeks. The longer you debate whether it can be done or not just increases the amount of work that has to be redone. You seem to be your own worse enemy here. Mark -- Mark Andrews, ISC 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Oct 22 19:36:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13874 for <dnsext-archive@lists.ietf.org>; Fri, 22 Oct 2004 19:36:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CL8tx-000Cq5-52 for namedroppers-data@psg.com; Fri, 22 Oct 2004 23:32:53 +0000 Received: from [65.205.251.75] (helo=robin.verisign.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CL8tw-000Cpq-8y for namedroppers@ops.ietf.org; Fri, 22 Oct 2004 23:32:52 +0000 Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i9MNWpiR017614; Fri, 22 Oct 2004 16:32:51 -0700 (PDT) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <476C5WT5>; Fri, 22 Oct 2004 16:32:51 -0700 Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BECCA@mou1wnexm05.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" <pbaker@verisign.com> To: "'Mark Andrews'" <Mark_Andrews@isc.org>, "Hallam-Baker, Phillip" <pbaker@verisign.com> Cc: "'bmanning@vacation.karoshi.com'" <bmanning@vacation.karoshi.com>, namedroppers@ops.ietf.org Subject: RE: I-D ACTION:draft-iab-dns-choices-00.txt Date: Fri, 22 Oct 2004 16:32:43 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > From: marka@isc.org [mailto:marka@isc.org]On Behalf Of Mark Andrews > > The reason that we have to redo PGP and S/MIME in the first place > > is that people were desiging systems to amuse themselves not protect > > real people from real risks. I am dealling with security for real > > people, not for geeks. > > The longer you debate whether it can be done or not just > increases the amount of work that has to be redone. You > seem to be your own worse enemy here. No, the debate is not delaying my plans in the slightest which are unchanged and will continue to use prefixed TXT records. This debate is most useful in helping clarify the situation with respect to venue. The more intransigent this group is in demanding that deployment of a new RR be in the critical path without giving any valid technical justification then the easier it will be to persuade other parties to consider non-IETF venues. -- to 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/> From owner-namedroppers@ops.ietf.org Fri Oct 22 20:26:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16397 for <dnsext-archive@lists.ietf.org>; Fri, 22 Oct 2004 20:26:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CL9fk-000LU9-UL for namedroppers-data@psg.com; Sat, 23 Oct 2004 00:22:16 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CL9fk-000LTv-3R for namedroppers@ops.ietf.org; Sat, 23 Oct 2004 00:22:16 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 620C667503 for <namedroppers@ops.ietf.org>; Sat, 23 Oct 2004 00:22:15 +0000 (UTC) (envelope-from marka@drugs.dv.isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id i9N0MAfs087850; Sat, 23 Oct 2004 10:22:10 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200410230022.i9N0MAfs087850@drugs.dv.isc.org> To: "Hallam-Baker, Phillip" <pbaker@verisign.com> Cc: namedroppers@ops.ietf.org From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: I-D ACTION:draft-iab-dns-choices-00.txt In-reply-to: Your message of "Fri, 22 Oct 2004 16:32:43 MST." <C6DDA43B91BFDA49AA2F1E473732113E010BECCA@mou1wnexm05.vcorp.ad.vrsn.com> Date: Sat, 23 Oct 2004 10:22:10 +1000 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > > From: marka@isc.org [mailto:marka@isc.org]On Behalf Of Mark Andrews > > > The reason that we have to redo PGP and S/MIME in the first place > > > is that people were desiging systems to amuse themselves not protect > > > real people from real risks. I am dealling with security for real > > > people, not for geeks. > > > > The longer you debate whether it can be done or not just > > increases the amount of work that has to be redone. You > > seem to be your own worse enemy here. > > No, the debate is not delaying my plans in the slightest which > are unchanged and will continue to use prefixed TXT records. > > This debate is most useful in helping clarify the situation > with respect to venue. The more intransigent this group is > in demanding that deployment of a new RR be in the critical > path without giving any valid technical justification then > the easier it will be to persuade other parties to consider > non-IETF venues. The valid technical arguement is that there is no way to safely sub-type TXT. As a proof of concept TXT works. It's time to take it from the proof of concept stage to production. -- Mark Andrews, ISC 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Oct 22 20:31:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17071 for <dnsext-archive@lists.ietf.org>; Fri, 22 Oct 2004 20:31:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CL9n5-000Mc0-PZ for namedroppers-data@psg.com; Sat, 23 Oct 2004 00:29:51 +0000 Received: from [65.205.251.74] (helo=colibri.verisign.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CL9n4-000Mbn-Tx for namedroppers@ops.ietf.org; Sat, 23 Oct 2004 00:29:51 +0000 Received: from mou1wnexc01.vcorp.ad.vrsn.com (mailer4.verisign.com [65.205.251.53]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i9N0TleB014070; Fri, 22 Oct 2004 17:29:50 -0700 (PDT) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <VCDJ9YFB>; Fri, 22 Oct 2004 17:29:47 -0700 Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BECCC@mou1wnexm05.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" <pbaker@verisign.com> To: "'Mark Andrews'" <Mark_Andrews@isc.org>, "Hallam-Baker, Phillip" <pbaker@verisign.com> Cc: namedroppers@ops.ietf.org Subject: RE: I-D ACTION:draft-iab-dns-choices-00.txt Date: Fri, 22 Oct 2004 17:29:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > The valid technical arguement is that there is no way > to safely sub-type TXT. That claim is utterly untrue. Prefixed TXT records are perfectly safe, nobody has tried to make the claim that there is any risk involved. The only claim made is that certain wildcard features don't work in the optimal way in the legacy servers. That is certainly not a safety argument and trying FUD will not help. -- to 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/> From owner-namedroppers@ops.ietf.org Fri Oct 22 22:41:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06032 for <dnsext-archive@lists.ietf.org>; Fri, 22 Oct 2004 22:41:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CLBla-000H6J-JY for namedroppers-data@psg.com; Sat, 23 Oct 2004 02:36:26 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CLBlZ-000H66-RK for namedroppers@ops.ietf.org; Sat, 23 Oct 2004 02:36:25 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 30749677EC for <namedroppers@ops.ietf.org>; Sat, 23 Oct 2004 02:36:24 +0000 (UTC) (envelope-from marka@drugs.dv.isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id i9N2aJF1036070; Sat, 23 Oct 2004 12:36:20 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200410230236.i9N2aJF1036070@drugs.dv.isc.org> To: "Hallam-Baker, Phillip" <pbaker@verisign.com> Cc: namedroppers@ops.ietf.org From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: I-D ACTION:draft-iab-dns-choices-00.txt In-reply-to: Your message of "Fri, 22 Oct 2004 17:29:47 MST." <C6DDA43B91BFDA49AA2F1E473732113E010BECCC@mou1wnexm05.vcorp.ad.vrsn.com> Date: Sat, 23 Oct 2004 12:36:19 +1000 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > > The valid technical arguement is that there is no way > > to safely sub-type TXT. > > That claim is utterly untrue. Prefixed TXT records are > perfectly safe, nobody has tried to make the claim that > there is any risk involved. > > The only claim made is that certain wildcard features > don't work in the optimal way in the legacy servers. > > That is certainly not a safety argument and trying FUD > will not help. You are confused about what I mean by sub-type. SIG and RRSIG are example of sub-typing. The rdata contains sub-type information. The proof of concept tried to sub-type TXT by having a prefix string in the record. Mark -- Mark Andrews, ISC 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Oct 23 10:51:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00977 for <dnsext-archive@lists.ietf.org>; Sat, 23 Oct 2004 10:51:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CLNAO-000DQb-5I for namedroppers-data@psg.com; Sat, 23 Oct 2004 14:46:48 +0000 Received: from [65.205.251.75] (helo=robin.verisign.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CLNAN-000DQO-AW for namedroppers@ops.ietf.org; Sat, 23 Oct 2004 14:46:47 +0000 Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i9NEkjBY026223; Sat, 23 Oct 2004 07:46:46 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <VCCXF405>; Sat, 23 Oct 2004 07:46:45 -0700 Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BECCF@mou1wnexm05.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" <pbaker@verisign.com> To: "'Mark Andrews'" <Mark_Andrews@isc.org>, "Hallam-Baker, Phillip" <pbaker@verisign.com> Cc: namedroppers@ops.ietf.org Subject: RE: I-D ACTION:draft-iab-dns-choices-00.txt Date: Sat, 23 Oct 2004 07:46:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk So you are referring to a proposal that isn't being made rather than the proposal that has been made. So now we have that sorted out we can take it that your objections are withdrawn or can at any rate be ignored. > -----Original Message----- > From: marka@isc.org [mailto:marka@isc.org]On Behalf Of Mark Andrews > Sent: Friday, October 22, 2004 10:36 PM > To: Hallam-Baker, Phillip > Cc: namedroppers@ops.ietf.org > Subject: Re: I-D ACTION:draft-iab-dns-choices-00.txt > > > > > > > > The valid technical arguement is that there is no way > > > to safely sub-type TXT. > > > > That claim is utterly untrue. Prefixed TXT records are > > perfectly safe, nobody has tried to make the claim that > > there is any risk involved. > > > > The only claim made is that certain wildcard features > > don't work in the optimal way in the legacy servers. > > > > That is certainly not a safety argument and trying FUD > > will not help. > > You are confused about what I mean by sub-type. SIG and > RRSIG are example of sub-typing. The rdata contains sub-type > information. > > The proof of concept tried to sub-type TXT by having a > prefix string in the record. > > Mark > -- > Mark Andrews, ISC > 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Oct 23 18:26:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28561 for <dnsext-archive@lists.ietf.org>; Sat, 23 Oct 2004 18:26:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CLUF8-000Ebg-Mg for namedroppers-data@psg.com; Sat, 23 Oct 2004 22:20:10 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CLUF7-000EbS-U2 for namedroppers@ops.ietf.org; Sat, 23 Oct 2004 22:20:09 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 46E54677EC for <namedroppers@ops.ietf.org>; Sat, 23 Oct 2004 22:20:08 +0000 (UTC) (envelope-from marka@drugs.dv.isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id i9NMK37T055605; Sun, 24 Oct 2004 08:20:04 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200410232220.i9NMK37T055605@drugs.dv.isc.org> To: "Hallam-Baker, Phillip" <pbaker@verisign.com> Cc: namedroppers@ops.ietf.org From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: I-D ACTION:draft-iab-dns-choices-00.txt In-reply-to: Your message of "Sat, 23 Oct 2004 07:46:44 MST." <C6DDA43B91BFDA49AA2F1E473732113E010BECCF@mou1wnexm05.vcorp.ad.vrsn.com> Date: Sun, 24 Oct 2004 08:20:03 +1000 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > So you are referring to a proposal that isn't being made > rather than the proposal that has been made. > > So now we have that sorted out we can take it that your > objections are withdrawn or can at any rate be ignored. No. Even with a prefix you still have the sub-type problem. With a prefix you have the problem that you can't implement this with every possible mta name. You have the problem that it doesn't work with wildcards (your own admission). These prefix problems will not go away with time. Nor will the fact that none of use owns the namespace once it has been delegated. We made a mistake with SRV, we are trying not to compound that mistake. You started with the premise that adding a new type would take a long time and looked for a solution that didn't involve a new type. I think I have proved that your initial premise was based on FUD. It can be also demonstated that a new type is a technically superior solution to sub-type / prefix. Mark -- Mark Andrews, ISC 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Oct 23 21:18:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05404 for <dnsext-archive@lists.ietf.org>; Sat, 23 Oct 2004 21:18:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CLWyV-000MX9-LA for namedroppers-data@psg.com; Sun, 24 Oct 2004 01:15:11 +0000 Received: from [65.205.251.75] (helo=robin.verisign.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CLWyU-000MWv-QA for namedroppers@ops.ietf.org; Sun, 24 Oct 2004 01:15:10 +0000 Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i9O1EZdZ022344; Sat, 23 Oct 2004 18:14:35 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <VCCXGB4Z>; Sat, 23 Oct 2004 18:14:35 -0700 Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BECD0@mou1wnexm05.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" <pbaker@verisign.com> To: "'Mark Andrews'" <Mark_Andrews@isc.org>, "Hallam-Baker, Phillip" <pbaker@verisign.com> Cc: namedroppers@ops.ietf.org Subject: RE: I-D ACTION:draft-iab-dns-choices-00.txt Date: Sat, 23 Oct 2004 18:14:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > So you are referring to a proposal that isn't being made > > rather than the proposal that has been made. > > > > So now we have that sorted out we can take it that your > > objections are withdrawn or can at any rate be ignored. > > No. Even with a prefix you still have the sub-type problem. > > With a prefix you have the problem that you can't implement > this with every possible mta name. What on earth do you mean here? If you mean that it uses underscores its irrelevant now, the underscore is unusable for A record names due to the infrastructure. Grow up. > You have the problem that > it doesn't work with wildcards (your own admission). No, I said that the wildcard support does not work according to the requirements for any extension mechanism, including new RRs. You have to fix the servers with a macro capability either way. Compared to the fact that 50% of the DNS infrastructure does not support new RRs in any shape or form these problems are minor and irrelevant. > You started with the premise that adding a new type would > take a long time and looked for a solution that didn't > involve a new type. I think I have proved that your initial > premise was based on FUD. No, you did nothing of the sort. > It can be also demonstated that > a new type is a technically superior solution to sub-type / > prefix. Assertion and restatement of assertion does not constitute an argument. -- to 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/> From owner-namedroppers@ops.ietf.org Mon Oct 25 04:29:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00750 for <dnsext-archive@lists.ietf.org>; Mon, 25 Oct 2004 04:29:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CM08V-000Jl4-Kh for namedroppers-data@psg.com; Mon, 25 Oct 2004 08:23:27 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CM08U-000Jkc-Lz for namedroppers@ops.ietf.org; Mon, 25 Oct 2004 08:23:26 +0000 Received: (debugging) helo=deneb.enyo.de ip=212.9.189.171 name=deneb.enyo.de Received: from deneb.enyo.de ([212.9.189.171]) by mail.enyo.de with esmtp id 1CM08O-00082W-C5; Mon, 25 Oct 2004 10:23:20 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.34) id 1CM08N-0001Aw-Oq; Mon, 25 Oct 2004 10:23:20 +0200 To: namedroppers@ops.ietf.org Cc: rfc@stuartcheshire.org, marc@apple.com Subject: Multicast DNS and .local From: Florian Weimer <fw@deneb.enyo.de> Date: Mon, 25 Oct 2004 10:23:19 +0200 Message-ID: <874qkjjjew.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Is there any specific reason why .local is used in draft-cheshire-dnsext-multicastdns instead of (for example) .local.arpa, which is far less prone to accidental collisions? -- to 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/> From owner-namedroppers@ops.ietf.org Mon Oct 25 07:57:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18418 for <dnsext-archive@lists.ietf.org>; Mon, 25 Oct 2004 07:57:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CM3OS-000OU0-N2 for namedroppers-data@psg.com; Mon, 25 Oct 2004 11:52:08 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CM3OR-000OTj-Nt for namedroppers@ops.ietf.org; Mon, 25 Oct 2004 11:52:07 +0000 Received: from [193.133.15.218] (ben-xp2.ben.algroup.co.uk [193.133.15.218]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 0839A107D1B; Mon, 25 Oct 2004 11:52:07 +0000 (GMT) Message-ID: <417CE8F1.6090107@algroup.co.uk> Date: Mon, 25 Oct 2004 12:52:17 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hallam-Baker, Phillip" <pbaker@verisign.com> Cc: "'bmanning@vacation.karoshi.com'" <bmanning@vacation.karoshi.com>, Mark Andrews <Mark_Andrews@isc.org>, namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-iab-dns-choices-00.txt References: <C6DDA43B91BFDA49AA2F1E473732113E010BECBE@mou1wnexm05.vcorp.ad.vrsn.com> In-Reply-To: <C6DDA43B91BFDA49AA2F1E473732113E010BECBE@mou1wnexm05.vcorp.ad.vrsn.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hallam-Baker, Phillip wrote: > If you are suggesting kicking away crutches from people who need > them then you really are not going to be much help. Outside MIT > LCS/AI and the IETF the idea of making a specification into > an intelligence test is not very popular. Have you ever read the X.509 or ASN.1 specs? -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to 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/> From owner-namedroppers@ops.ietf.org Mon Oct 25 11:07:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02787 for <dnsext-archive@lists.ietf.org>; Mon, 25 Oct 2004 11:07:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CM6Kd-0001wz-Rk for namedroppers-data@psg.com; Mon, 25 Oct 2004 15:00:23 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CM6KY-0001w7-9x for namedroppers@ops.ietf.org; Mon, 25 Oct 2004 15:00:20 +0000 Received: from [10.31.32.74] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id i9PExmXP009079; Mon, 25 Oct 2004 11:00:03 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a06110401bda2c0a1105f@[192.168.1.100]> Date: Mon, 25 Oct 2004 10:50:48 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis <Ed.Lewis@neustar.biz> Subject: update of wcard submitted Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.44 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I managed to get around to an update of the wcard draft. I made updates based on notes from Alex and Robert. I didn't make all the updates, nor did I manage time to even reread the whole thing myself. In a few days, or perhaps at the meeting, I'll send in any substantive questions based on the comments received. In general, the comments were about wording and not concepts as were any reactions I had. Mostly, I wanted to keep the draft "chatty" because this is supposed to be a clarificiation and not a "dry" specification (countering some recommendations from Robert). I still don't consider the draft well-written, nor set in type. I guess I do have one more headache - whether or not to discuss DS and NSEC types at the parent. I kind of have one foot into that rat hole when speaking about the NS types. I'm not sure if I should pull my foot out or dive in with the second foot. If we're mentioning DNAME, why not DS and NSEC? OTOH, if this document sticks with 1034 topics, mayne all of DNAME is dropped. I suppose it's debate over whether this is an strict update of 1034 or is an update on the concept of (1034:) wildcards. BTW - As far as comments form Phill Halem-Baker, this draft is only a clarification of the documented status quo. This document's expansion into other forms of synthesis is not appropriate - if the desire is there, then a new draft is needed that will update other documents. This document can't endorse the new efforts, it can hint at requirements for them. If it comes across as prohibiting them (e.g., the*.example. does not pattern match), that's because the current specs also "prohibit" the expansion - but don't take this as a "rejection with prejudice." (Meaning - not allowed now, but proposals are welcome.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar "Now under neu management" -- to 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/> From owner-namedroppers@ops.ietf.org Mon Oct 25 14:11:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20296 for <dnsext-archive@lists.ietf.org>; Mon, 25 Oct 2004 14:11:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CM9GB-0005GB-9t for namedroppers-data@psg.com; Mon, 25 Oct 2004 18:07:59 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CM9GA-0005Fl-96 for namedroppers@ops.ietf.org; Mon, 25 Oct 2004 18:07:58 +0000 Received: from [193.133.15.218] (ben-xp2.ben.algroup.co.uk [193.133.15.218]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 6E44F107D1B for <namedroppers@ops.ietf.org>; Mon, 25 Oct 2004 18:07:57 +0000 (GMT) Message-ID: <417D4108.5020705@algroup.co.uk> Date: Mon, 25 Oct 2004 19:08:08 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-signed-nonexistence-requirements-01.txt References: <200410222003.QAA05457@ietf.org> In-Reply-To: <200410222003.QAA05457@ietf.org> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Internet-Drafts@ietf.org wrote: > 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 : Requirements related to DNSSEC Signed Proof of Non-Existence > Author(s) : B. Laurie, R. Loomis > Filename : draft-ietf-dnsext-signed-nonexistence-requirements-01.txt > Pages : 11 > Date : 2004-10-22 I also updated the matrix. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to 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/> From owner-namedroppers@ops.ietf.org Mon Oct 25 16:16:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02288 for <dnsext-archive@lists.ietf.org>; Mon, 25 Oct 2004 16:16:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CMBAj-000MqB-BF for namedroppers-data@psg.com; Mon, 25 Oct 2004 20:10:29 +0000 Received: from [64.233.184.206] (helo=wproxy.gmail.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CMBAi-000Mpw-Cv for namedroppers@ops.ietf.org; Mon, 25 Oct 2004 20:10:28 +0000 Received: by wproxy.gmail.com with SMTP id 71so91581wri for <namedroppers@ops.ietf.org>; Mon, 25 Oct 2004 13:10:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=sjl1GMkxajrnnBrwML3CBdRj9uFG/W+JrDW8A3T80mUlpgbFm93K09XJHCP4f3JdnQHQOpCw4ZYT5CFMLZaLxtfTtKLWOotGCy21JoxvinkR5+K7cy1VeSzkdufDDzLKrgpnsXGw7kSyEmkV8F1WpuOdrI/fcsqGv5WIsB/bt7M= Received: by 10.38.82.27 with SMTP id f27mr15352rnb; Mon, 25 Oct 2004 13:10:21 -0700 (PDT) Received: by 10.38.79.29 with HTTP; Mon, 25 Oct 2004 13:10:21 -0700 (PDT) Message-ID: <2bcdc7c404102513103b6b1891@mail.gmail.com> Date: Mon, 25 Oct 2004 13:10:21 -0700 From: James Snell <jasnell@gmail.com> Reply-To: James Snell <jasnell@gmail.com> To: namedroppers@ops.ietf.org Subject: New Internet-Draft: DNS-Endpoint Discovery (http://www.ietf.org/internet-drafts/draft-snell-dnsepd-00.txt) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I wanted to drop a quick note about a new Internet-Draft I and my colleague Andrew Donoho have submitted that we would like to discuss both here on the list and at the upcoming face-to-face in Washington D.C. The DNS Endpoint Discovery, or DNS-EPD (http://www.ietf.org/internet-drafts/draft-snell-dnsepd-00.txt) draft proposes two new resource records used for the purpose of advertising and discovering Web service endpoints using DNS. The intro section of the draft provides some of the background and motivation for the spec so I'll skip that part of the discussion here. There are two new RR's proposed, one representing a Web service "Endpoint Reference" and the other allowing well-formed XML documents to be stored in DNS. Examples of both are included below: stockquotes._ws.example.com EPR 111 0 0 services.example.com /services/sq {urn:myservices}MyStockQuotes http://services.example.com/services/sq.wsdl stockquotes._ws.example.com XML 0 <EndpointReference xmlns="..." /> In the Web services world, an "Endpoint Reference" is a well known construct that points to the network location where a Web service is deployed and provides information about the service interface exposed at that location. The EPR record presented above provides a) the location of the service expressed in terms of A/AAAA/SRV records, an identifier for the service interface, and an indicator that more information is available in the form of a WSDL document and an XML RR. The XML RR is a straightforward record whose RDATA consists of two fields. The first is an unsigned byte whose value indicates the encoding of the XML. UTF-8 character encoding is the default. The second field is a well-formed XML document that is subject to certain formatting restrictions (designed to minimize wasted space). In many respects the XML record shares the same basic semantics as the TXT record with the exception that it is limited specifically to XML data. Please refer to the I-D for specifics on how the XML record is used and interpreted in relation to DNS-EPD. Our goal in submitting this draft is to begin the process of securing feedback from the DNS expert community in order to determine: 1. Does the DNS expert community feel that it makes sense to leverage DNS in this way 2. Does our design approach makes sense in terms of using new resource records as opposed to using TXT records (I've been following the recent discussions on this topic with great interest). Thanks, - James Snell IBM, Emerging Technologies jasnell@gmail.com jasnell@us.ibm.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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Oct 25 16:42:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06942 for <dnsext-archive@lists.ietf.org>; Mon, 25 Oct 2004 16:42:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CMBcm-0000Oc-FJ for namedroppers-data@psg.com; Mon, 25 Oct 2004 20:39:28 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CMBci-0000O3-Jd for namedroppers@ops.ietf.org; Mon, 25 Oct 2004 20:39:24 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id i9PKdIwP025161; Mon, 25 Oct 2004 20:39:18 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id i9PKdHc8025158; Mon, 25 Oct 2004 20:39:17 GMT Date: Mon, 25 Oct 2004 20:39:17 +0000 From: bmanning@vacation.karoshi.com To: Edward Lewis <Ed.Lewis@neustar.biz> Cc: namedroppers@ops.ietf.org Subject: Re: update of wcard submitted Message-ID: <20041025203917.GA25118@vacation.karoshi.com.> References: <a06110401bda2c0a1105f@[192.168.1.100]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <a06110401bda2c0a1105f@[192.168.1.100]> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk doing a document recovery intervention and this came up.... :) Internet Experiment Note 116 - Internet Name Server August 1979 - Jon Postel has an extensive treatment of wildcards. If you wnat a copy I'll be happy to post it. Granted, this predates the DNS... --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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Oct 25 16:58:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08650 for <dnsext-archive@lists.ietf.org>; Mon, 25 Oct 2004 16:58:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CMBsQ-0002nk-W7 for namedroppers-data@psg.com; Mon, 25 Oct 2004 20:55:38 +0000 Received: from [65.205.251.75] (helo=robin.verisign.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CMBsP-0002nJ-Vj for namedroppers@ops.ietf.org; Mon, 25 Oct 2004 20:55:38 +0000 Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i9PKtSwQ026901; Mon, 25 Oct 2004 13:55:28 -0700 (PDT) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <476C7PPW>; Mon, 25 Oct 2004 13:55:28 -0700 Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BECD4@mou1wnexm05.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" <pbaker@verisign.com> To: "'Ben Laurie'" <ben@algroup.co.uk>, "Hallam-Baker, Phillip" <pbaker@verisign.com> Cc: "'bmanning@vacation.karoshi.com'" <bmanning@vacation.karoshi.com>, Mark Andrews <Mark_Andrews@isc.org>, namedroppers@ops.ietf.org Subject: RE: I-D ACTION:draft-iab-dns-choices-00.txt Date: Mon, 25 Oct 2004 13:55:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > From: Ben Laurie [mailto:ben@algroup.co.uk] > Hallam-Baker, Phillip wrote: > > > If you are suggesting kicking away crutches from people who need > > them then you really are not going to be much help. Outside MIT > > LCS/AI and the IETF the idea of making a specification into > > an intelligence test is not very popular. > > Have you ever read the X.509 or ASN.1 specs? My theory is that the party that wrote the ASN.1 spec wanted to stop the use of civilian cryptography, thats why the name is 1.NSA backwards. -- to 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/> From owner-namedroppers@ops.ietf.org Mon Oct 25 17:05:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09389 for <dnsext-archive@lists.ietf.org>; Mon, 25 Oct 2004 17:05:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CMByn-0003wg-W8 for namedroppers-data@psg.com; Mon, 25 Oct 2004 21:02:13 +0000 Received: from [66.45.230.132] (helo=spike.gnomon.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CMByn-0003wH-0K for namedroppers@ops.ietf.org; Mon, 25 Oct 2004 21:02:13 +0000 Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i9PL2xCu066658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <namedroppers@ops.ietf.org>; Mon, 25 Oct 2004 21:03:05 GMT (envelope-from roy+dated+1101330124.fed6cb@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i9PL24Gn027093 for <namedroppers@ops.ietf.org>; Mon, 25 Oct 2004 22:02:04 +0100 (BST) (envelope-from roy+dated+1101330124.fed6cb@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i9PL24fB027092 for namedroppers@ops.ietf.org; Mon, 25 Oct 2004 22:02:04 +0100 (BST) (envelope-from roy+dated+1101330124.fed6cb@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Mon, 25 Oct 2004 22:02:03 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16765.27083.439598.69624@giles.gnomon.org.uk> Date: Mon, 25 Oct 2004 22:02:03 +0100 To: bmanning@vacation.karoshi.com Cc: Edward Lewis <Ed.Lewis@neustar.biz>, namedroppers@ops.ietf.org Subject: Re: update of wcard submitted In-Reply-To: <20041025203917.GA25118@vacation.karoshi.com.> References: <a06110401bda2c0a1105f@[192.168.1.100]> <20041025203917.GA25118@vacation.karoshi.com.> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami <roy@gnomon.org.uk> X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit bmanning> has an extensive treatment of wildcards. If you wnat bmanning> a copy I'll be happy to post it. Granted, this predates bmanning> the DNS... Many IEN's (including this one) are available on RFC Editor's FTP site: ftp://ftp.rfc-editor.org/in-notes/ien/ien116.txt -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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Oct 25 19:02:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08933 for <dnsext-archive@lists.ietf.org>; Mon, 25 Oct 2004 19:02:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CMDmn-000Jij-A4 for namedroppers-data@psg.com; Mon, 25 Oct 2004 22:57:57 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CMDmm-000Jhw-2V for namedroppers@ops.ietf.org; Mon, 25 Oct 2004 22:57:56 +0000 Received: from [192.168.1.100] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id i9PMvivD011714; Mon, 25 Oct 2004 18:57:45 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a06110403bda3344a44fe@[192.168.1.100]> In-Reply-To: <20041025203917.GA25118@vacation.karoshi.com.> References: <20041025203917.GA25118@vacation.karoshi.com.> Date: Mon, 25 Oct 2004 18:57:34 -0400 To: bmanning@vacation.karoshi.com From: Edward Lewis <Ed.Lewis@neustar.biz> Subject: Re: update of wcard submitted Cc: Edward Lewis <Ed.Lewis@neustar.biz>, namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.44 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 16:39 -0400 10/25/04, bmanning@vacation.karoshi.com wrote: > doing a document recovery intervention and this came up.... :) > > Internet Experiment Note 116 - Internet Name Server > August 1979 - Jon Postel > > has an extensive treatment of wildcards. If you wnat a copy > I'll be happy to post it. Granted, this predates the DNS... To quote a friend, Bill, "Don't *make* me hurt you!" -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar "Now under neu management" -- to 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/> From owner-namedroppers@ops.ietf.org Tue Oct 26 07:19:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24517 for <dnsext-archive@lists.ietf.org>; Tue, 26 Oct 2004 07:19:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CMPHH-000CPh-KJ for namedroppers-data@psg.com; Tue, 26 Oct 2004 11:14:11 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CMPHG-000CPU-Qz for namedroppers@ops.ietf.org; Tue, 26 Oct 2004 11:14:10 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id B9CD6C2DA7; Tue, 26 Oct 2004 12:14:09 +0100 (BST) Date: Tue, 26 Oct 2004 12:14:06 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: Edward Lewis <Ed.Lewis@neustar.biz>, namedroppers@ops.ietf.org Cc: Alex Bligh <alex@alex.org.uk> Subject: Re: update of wcard submitted Message-ID: <1C531C747FE51060CF2ABE90@[192.168.100.25]> In-Reply-To: <a06110401bda2c0a1105f@[192.168.1.100]> References: <a06110401bda2c0a1105f@[192.168.1.100]> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,BIZ_TLD autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ed, --On 25 October 2004 10:50 -0400 Edward Lewis <Ed.Lewis@neustar.biz> wrote: > I suppose it's debate over whether this is an strict update of 1034 or is > an update on the concept of (1034:) wildcards. You made it pretty clear in the draft you were NOT intending to update (read: 'obselete') RFC 1034. If you were trying to do this, I think the draft is too chatty etc. I proposed a pile of changes which I backed out when I realized what you were trying to do (or thought I had). What I *thought* you were trying to do was issue a clarifying document detailing how wildcards should work in RFC1034. It is not designed (as far as I can see) to be a change of protocol to 1034 (or only the minimum change necessary to disambiguate it). Therefore I see no reason which you shouldn't add DS etc. to the draft, and make it clear for DNSSECbis etc. If you were trying to update RFC1034, I'd think differently (i.e. I'd drop the word update entirely and use the word "clarify"). Alex -- to 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/> From owner-namedroppers@ops.ietf.org Tue Oct 26 07:59:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28714 for <dnsext-archive@lists.ietf.org>; Tue, 26 Oct 2004 07:59:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CMPwT-0003j5-To for namedroppers-data@psg.com; Tue, 26 Oct 2004 11:56:45 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CMPwS-0003iW-JQ for namedroppers@ops.ietf.org; Tue, 26 Oct 2004 11:56:45 +0000 Received: from [10.31.32.74] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id i9QBuXHj014684; Tue, 26 Oct 2004 07:56:34 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a06110402bda3e8ded29b@[10.31.32.74]> In-Reply-To: <1C531C747FE51060CF2ABE90@[192.168.100.25]> References: <1C531C747FE51060CF2ABE90@[192.168.100.25]> Date: Tue, 26 Oct 2004 07:56:33 -0400 To: Alex Bligh <alex@alex.org.uk> From: Edward Lewis <Ed.Lewis@neustar.biz> Subject: Re: update of wcard submitted Cc: Edward Lewis <Ed.Lewis@neustar.biz>, namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.44 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 7:14 -0400 10/26/04, Alex Bligh wrote: >You made it pretty clear in the draft you were NOT intending to update >(read: 'obselete') RFC 1034. If you were trying to do this, I think >the draft is too chatty etc. I proposed a pile of changes which I backed >out when I realized what you were trying to do (or thought I had). The history of the draft is about 18 months long. Originally it was to figure out what was meant by RFC 1034 and how this impacted RFC 2535. Then it became an attempt to add strictness to the language without modifications (i.e., add MUST, SHOULD). At one time there was a highly mathematical proof backing the assertions made about authenticated denial - contributed by Bob Halley. At some point (IETF in SF, March 2003) the document became a WG item. At about this time we stripped out all references to DNSSEC and went back to just clarifying RFC 1034, with formal language. The change to the CNAME processing in part 'c' came as a result of WG discussion in summer 2003 (surrounding the Vienna IETF). When the document was individual, I was not about to make any non-wording changes. But since the group asked for the change (and I was now an editor, not an author), the change is in. From Summer 2003-Summer 2004 I was tied up with other duties. In returning to the task at hand, during the recent discussions it has dawned on me to remove the MUST/SHOULD requirements and return to an engineering document (as opposed to a specification) - in the same frame of mind of RFC 1034/RFC 1035. I was convinced of this by the comments from Robert Elz - pointing out that adding strict rules at this point may introduce hidden problems with implementations that may have correctly interpreted passages in RFC 1034, albeit in original ways. >What I *thought* you were trying to do was issue a clarifying document >detailing how wildcards should work in RFC1034. It is not designed >(as far as I can see) to be a change of protocol to 1034 (or only >the minimum change necessary to disambiguate it). Therefore I see >no reason which you shouldn't add DS etc. to the draft, and make >it clear for DNSSECbis etc. The WG ought to talk then about the impacts of NSEC and DS at a source of synthesis. With the upcoming meeting, maybe that could be done in person as well as on the list. >If you were trying to update RFC1034, I'd think differently (i.e. >I'd drop the word update entirely and use the word "clarify"). Hmmm. The only part(s) of the wcard draft that "overwrite" RFC 1034 is the addition of "CNAME chasing" in part 'c' and the general discussion/terminology work. Only the former has real impact on implementation, the latter is for the benefit of net bureaucrats. I hate to haggle over document politics, its like teaching implementers to sing. It doesn't work and it annoys the implementers. (;)) I'd just say that this document clarifies and updates 1034 - clarifies wording and updates one step in the algorithm, in the vein of the DNAME standard. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar "Now under neu management" -- to 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/> From owner-namedroppers@ops.ietf.org Wed Oct 27 00:56:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03859 for <dnsext-archive@lists.ietf.org>; Wed, 27 Oct 2004 00:56:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CMflL-000Akg-4K for namedroppers-data@psg.com; Wed, 27 Oct 2004 04:50:19 +0000 Received: from [128.250.1.44] (helo=delta.noi.kre.to) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CMflJ-000AkI-Tz for namedroppers@ops.ietf.org; Wed, 27 Oct 2004 04:50:18 +0000 Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i9QE9rn9013992; Tue, 26 Oct 2004 21:09:53 +0700 (ICT) From: Robert Elz <kre@munnari.OZ.AU> To: Edward Lewis <Ed.Lewis@neustar.biz> cc: namedroppers@ops.ietf.org Subject: Re: update of wcard submitted In-Reply-To: <a06110401bda2c0a1105f@[192.168.1.100]> References: <a06110401bda2c0a1105f@[192.168.1.100]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 26 Oct 2004 21:09:53 +0700 Message-ID: <1263.1098799793@munnari.OZ.AU> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=BAYES_00,BIZ_TLD, DATE_IN_PAST_12_24 autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Mon, 25 Oct 2004 10:50:48 -0400 From: Edward Lewis <Ed.Lewis@neustar.biz> Message-ID: <a06110401bda2c0a1105f@[192.168.1.100]> | Mostly, I wanted to keep the draft "chatty" because | this is supposed to be a clarificiation and not a "dry" specification | (countering some recommendations from Robert). I haven't had a chance to read the new one yet (and am not currently connected, so I can't even fetch it - didn't know it existed till I saw this message) - but this I suspect means that we differ over what "clarification" means. I take it to indicate a tightly written doc which is very precise, and makes absolutely clear any doubtful aspects of the specification being clarified. I would contrast that to an "explanation" which would be just fine as a chatty doc - where the purpose is to explain why the world is the way it is, so people understand the reasoning. While the latter is a fine thing to have, it isn't what I think is really needed here - that is, it isn't the crucial requirement. | I guess I do have one more headache - whether or not to discuss DS | and NSEC types at the parent. Is there anything about them, given their normal processing (that is, as they are currently specified to be processed) that in any way differs from, or complicates, the wildcard clarification? I wouldn't have expected so - sire they (well, DS particularly) are "different" when it comes to normal DNS message processing, but I wouldn't have thought that they'd affect the wildcard processing in any very peculiar way. | I suppose it's debate over whether this is an strict update of 1034 | or is an update on the concept of (1034:) wildcards. It needs to be a clarification of the DNS as it is defined. But it is just a clarification, not a re-specification of everything (it isn't DNS'). kre ps: bmanning@vacation.karoshi.com said: | Internet Experiment Note 116 - Internet Name Server | August 1979 - Jon Postel | has an extensive treatment of wildcards. I don't have a copy of the IEN's on my laptop either, so I can't go read that (again - I'm sure I have in the past) - but I'd use care making any use or reference at all to pre-1034 DNS related stuff, other than perhaps to explain the historical environment (which I don't think is appropriate in a clarifications doc). Even 882/883 are quite different than 1034/5 when it comes to wildcards - this is an area that was changed during DNS development. -- to 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/> From owner-namedroppers@ops.ietf.org Thu Oct 28 03:41:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15305 for <dnsext-archive@lists.ietf.org>; Thu, 28 Oct 2004 03:41:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CN4mI-000CdA-H6 for namedroppers-data@psg.com; Thu, 28 Oct 2004 07:32:58 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CN4mH-000Ccv-7c for namedroppers@ops.ietf.org; Thu, 28 Oct 2004 07:32:57 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 8DE994FEF9; Thu, 28 Oct 2004 09:32:56 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 5E4014FEF4 for <namedroppers@ops.ietf.org>; Thu, 28 Oct 2004 09:32:55 +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 i9S7Wtx1032657 for <namedroppers@ops.ietf.org>; Thu, 28 Oct 2004 09:32:55 +0200 Date: Thu, 28 Oct 2004 09:32:52 +0200 From: "Olaf M. Kolkman" <olaf@ripe.net> To: namedroppers@ops.ietf.org Subject: Denial Of Existence: Way Forward Message-Id: <20041028093252.2f23c23d.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.11 (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.000585 / 0.0 / 0.0 / disabled X-RIPE-Signature: 9e61b743d908ebd0a1fa53dd6f63d377 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,OPT_IN autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit == Denial of Existence and zone enumeration and a way forward. Now the discussion is less heated and we are nearing a face to face meeting we want to try to summarize where we are and how to proceed as a working group. == Is the problem real? We have seen long e-mail threads on the reality of the problem of zone enumeration. The summary of those discussion is that there are two views on this issue: 1) DNS is a public database, if one has something to hide one should not put it into the DNS. 2) NSEC walk makes the zone content fully enumerable, policy forbids us to deploy such mechanism. There is definitely no consensus on either of these two views being "the Truth (TM)". Supporters of '1' have tried to convince supporters of '2' that their policies are "broken". It is clear that they have not, and will not succeed. One has to agree on disagreement. Therefore we are faced with the fact that that major players (a hand full of large TLDs) will not deploy DNSSEC while NSEC walk is possible. For them the NSEC walk is a real problem and they have asked the IETF to engineer a way around the problem. We do not know if there are more "players" that have enumeration policies that would prevent them from rolling out DNSSEC. == Should the DNSEXT WG do this work This is a problem that needs engineering, it is within scope of the DNSEXT charter so the short answer is "yes". The somewhat longer answer is that there are costs associated with this. It will cost time and money to develop specs, develop the software and do tests. It is not realistic to think that we can develop a good solution within a few months. Given our experience with the rewrite of the DNSSEC specifications a 2 year cycle seems like a realistic estimate. In that time (members of) the working group will need to come up with specs and running code. In order to do the work we will need a "critical mass" of interested individuals that can commit their resources in writing specs and code and a superset of individuals that can commit to review. In order to pursue this work as a working group item we will _not_ ask the question "Does the group want to see this as a working group item" but will ask: 1) Who will commit to producing specifications for a denial of existence method that does not allow for zone enumeration; We would like to see at least 3 people, which will be assigned an editors function, to commit. 2) Who will commit on writing an implementation We would like to see at least 1 individual or group committing to develop (or fund development) of an implementation. 3) Who will commit on reviewing the material We would like to see a set of people, different from the set of editors, to commit to review throughout the development of the specification. The intend of this exercise is to see if there is sufficient critical mass for this work to go forward. Please let us know if you can commit to 1,2 and/or 3. == Way forward There are two (known) ways to approach denial of existence proofs. a. Dynamically generated NSEC RRs b. Pre computed "NSEC++" RRs that use some hash scheme to obscure the namespace The requirements document that we have is implicitly based on 'b' type solutions and can be used for further development. We have heard about 'a' type solutions but have not seen them documented. These type of solutions, that require on-line keys, may provide fine interim solutions but unless they are documented in an I-D we cannot consider them. Therefore we propose that the working group, iff there is critical mass, continues by merging the two NSEC++ proposals and produces one document. This will be a task on the editors team. However to be able to progress we really need to have to understand the (conflicting) requirements and set some priority in order to get to a set of requirements that the group can consent with and on which editors can base their work.. We feel that the requirement matrix has not yet received sufficient review and would like this group to look at the requirement document and the requirement matrix [1]. Please ask questions. (e.g. how come (11,17) is green?) and make your comments. If possible people should argue their preference for requirements that cannot be reconciled (e.g. the opt-in type 11 is preferred over complete non-existence from 17). With any luck we can compose a list of "reconcilable requirements". We hope that this summary provides sufficient ground for a constructive and cooperative way forward. Olaf and Olafur DNSEXT Co-Chairs. [1] requirement matrix is at: http://www.links.org/dnssec/requirements-matrix.htm For fun, amusement and astonishment, slightly related to this topic: http://lists.gnu.org/archive/html/savannah-hackers/2004-10/msg00770.html -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Oct 28 03:51:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16152 for <dnsext-archive@lists.ietf.org>; Thu, 28 Oct 2004 03:51:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CN50h-000EBY-AI for namedroppers-data@psg.com; Thu, 28 Oct 2004 07:47:51 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CN50g-000EBI-79 for namedroppers@ops.ietf.org; Thu, 28 Oct 2004 07:47:50 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 9DEF44FEFF; Thu, 28 Oct 2004 09:47:49 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 824924FF00; Thu, 28 Oct 2004 09:47:48 +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 i9S7lmx1005395; Thu, 28 Oct 2004 09:47:48 +0200 Date: Thu, 28 Oct 2004 09:47:48 +0200 From: "Olaf M. Kolkman" <olaf@ripe.net> To: namedroppers@ops.ietf.org Cc: agenda@ietf.org Subject: DNSEXT Agenda IETF 61 Message-Id: <20041028094748.7062b360.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.11 (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.000004 / 0.0 / 0.0 / disabled X-RIPE-Signature: d4747595984194e8700df969ab671539 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear Colleagues, Below is a _draft_ agenda for the DNSEXT WG session. We are happy to have moved from Friday to the Wednesday afternoon session. It did cost us 30 minutes of meeting time and the schedule is therefore very tight. We would like to ask the presenters to keep their presentation short and to the point so that we have time for discussion. --Olaf ------------------------------------------------------------ DRAFT DNSEXT Agenda IETF 61. WEDNESDAY, November 10, 2004 1300-1500 Afternoon Sessions I - WG Administrivia (approx 15 minutes) + Session administration - Appointment Scribes - Agenda Bashing - Previous Minutes http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01628.html + Document Status + Charter Review - 2538bis Request for input (approx 3 minutes) proxy: Olafur Gudmundsson draft-josefsson-rfc2538bis-00.txt - QR clarification (approx 5 minutes) Roy Arends draft-arends-dnsext-qr-clarification-00.txt - Key crypto (approx 5 minutes) Donald Eastlake draft-ietf-dnsext-ecc-key-05 and draft-ietf-dnsext-tsig-sha-00 - Wildcard clarification (approx 15 minutes) Ed Lewis + draft-ietf-dnsext-wcard-clarify-03.txt - DNSSEC keymanagement issues (approx 20 minutes) Johan Ihren draft-ietf-dnsext-trustupdate-threshold-00.txt Mike StJohns Ben Laurie draft-laurie-dnssec-key-distribution-00.txt - Requirements for future work on Denial of Existence (approx 20 minutes) Loomis/Laurie: Requirements overview + draft-ietf-dnsext-dnssec-trans-01.txt - Cross fertilization (DNS related work in other groups that needs review) James Snell draft-snell-dnsepd-00.txt (approx 10 minutes) draft-iab-dns-choices-00.txt (approx 10 minutes) TENTATIVE DNS issues in SPF (approx 10 minutes) TENTATIVE This session is parallel to: APP geopriv Geographic Location/Privacy WG GEN newtrk New IETF Standards Track WG INT nemo Network Mobility WG OPS opsarea Operations & Management Open Area Meeting RTG manet Mobile Ad-hoc Networks WG SEC pkix Public-Key Infrastructure (X.5 ------------------------------------------------------------ $Id: agenda.txt,v 1.2 2004/10/28 07:42:24 olaf Exp $ ------------------------------------------------------------ -- ---------------------------------| 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Oct 28 06:33:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28549 for <dnsext-archive@lists.ietf.org>; Thu, 28 Oct 2004 06:33:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CN7WU-0005T5-RL for namedroppers-data@psg.com; Thu, 28 Oct 2004 10:28:50 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CN7WU-0005Ss-2H for namedroppers@ops.ietf.org; Thu, 28 Oct 2004 10:28:50 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 06393C2DA4; Thu, 28 Oct 2004 11:28:49 +0100 (BST) Date: Thu, 28 Oct 2004 11:28:43 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: "Olaf M. Kolkman" <olaf@ripe.net>, namedroppers@ops.ietf.org Cc: Alex Bligh <alex@alex.org.uk> Subject: Re: Denial Of Existence: Way Forward Message-ID: <9F54AB1A23C290B14DA2D366@[192.168.100.25]> In-Reply-To: <20041028093252.2f23c23d.olaf@ripe.net> References: <20041028093252.2f23c23d.olaf@ripe.net> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00,OPT_IN_CAPS autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Olaf, --On 28 October 2004 09:32 +0200 "Olaf M. Kolkman" <olaf@ripe.net> wrote: > == Denial of Existence and zone enumeration and a way forward. Thanks for your note, none of which I disagree with. However, there is one other item that I *think* has now become entangled with zone enumeration (and should probably stay entangled). This is support of unsigned portions within a signed zone file (i.e. proposals giving similar functionality to OPTIN). Having gone around the "why do people want protection against zone enumeration" loop, it seems that there may well be a large overlap in people who want that protection and those who want support of unsigned portions of a zone file; and further, that if the solution to zone enumeration is introducing a new NSEC variant, this could be fixed at the same time. It is, after all, in the requirements document. I therefore wonder whether, when considering your questions (1)-(3), whether they should not be asked in the context of zone enumeration protection and (perhaps) optional support for unsigned areas of zone. This may produce more people willing to commit resource. Alex -- to 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/> From owner-namedroppers@ops.ietf.org Thu Oct 28 07:58:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05005 for <dnsext-archive@lists.ietf.org>; Thu, 28 Oct 2004 07:58:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CN8oo-000ETy-Iz for namedroppers-data@psg.com; Thu, 28 Oct 2004 11:51:50 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CN8ok-000ETZ-MK for namedroppers@ops.ietf.org; Thu, 28 Oct 2004 11:51:46 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 1374B4FF95; Thu, 28 Oct 2004 13:51:46 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id E66244FF98; Thu, 28 Oct 2004 13:51:43 +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 i9SBphx1023348; Thu, 28 Oct 2004 13:51:43 +0200 Date: Thu, 28 Oct 2004 13:51:42 +0200 From: "Olaf M. Kolkman" <olaf@ripe.net> To: Alex Bligh <alex@alex.org.uk> Cc: namedroppers@ops.ietf.org Subject: Non-existence requirement: Completeness Message-Id: <20041028135142.21e258a6.olaf@ripe.net> In-Reply-To: <9F54AB1A23C290B14DA2D366@[192.168.100.25]> References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.11 (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.000008 / -5.9 X-RIPE-Signature: 021d3c5f3502e8fdda7e1e63553fbd3e X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00,OPT_IN_CAPS autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a reply to "Re: Denial Of Existence: Way Forward" Note the subject change though. Alex Bligh <alex@alex.org.uk> wrote about introduction of "OPT-IN" mechanisms. > solution to zone enumeration is introducing a new NSEC variant, this could > be fixed at the same time. It is, after all, in the requirements document. Correct, but we also have a requirement for "Completeness", hence my hint on the square (11,17) being green in my previous message. However, after your post I reread section 17 and I think that "should be possible" phrase in 17 does explain the green square. I am still not enthusiastic about fully dropping the denial of existence in a secured zone. And I think I should have worded requirement 17 stronger: In a secured zone proof is available for the non-existence of all names that do not exist in the zone. The main reason for this requirement is that as a "client" of DNSSEC I do not want to be confronted with two security models. DNSSEC today buys me the non-existence proof. As a client of the DNS I want all or nothing. (I understand that all kind of client policy knobs can be introduced but I do not think that is a good idea). This is slightly different from having two ways (NSEC and NSEC++) to deny existence of data. They do not alter the securtity properties for the client (only for the zone owner; obsuration of content). -- Olaf namedropper (hats off). ---------------------------------| 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Oct 28 08:09:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05788 for <dnsext-archive@lists.ietf.org>; Thu, 28 Oct 2004 08:09:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CN91O-000Gat-1i for namedroppers-data@psg.com; Thu, 28 Oct 2004 12:04:50 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CN91J-000GYz-MN for namedroppers@ops.ietf.org; Thu, 28 Oct 2004 12:04:46 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 6EDDFC2DA9; Thu, 28 Oct 2004 13:04:42 +0100 (BST) Date: Thu, 28 Oct 2004 13:04:36 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: "Olaf M. Kolkman" <olaf@ripe.net> Cc: namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> Subject: Re: Non-existence requirement: Completeness Message-ID: <DB9856F9513FB218A8EAC3FC@[192.168.100.25]> In-Reply-To: <20041028135142.21e258a6.olaf@ripe.net> References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <20041028135142.21e258a6.olaf@ripe.net> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,OPT_IN autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Olaf, --On 28 October 2004 13:51 +0200 "Olaf M. Kolkman" <olaf@ripe.net> wrote: > I am still not enthusiastic about fully dropping the denial of > existence in a secured zone. I am not advocating dropping it - I am advocating making it optional for parts of the zone (e.g. by having NSECx point the "next secure" name and have an additional bit saying "between here and there there may be zero or more insecure names"). > And I think I should have worded > requirement 17 stronger: > > In a secured zone proof is available for the non-existence of all > names that do not exist in the zone. You are back then to saying does 17 as reworded preclude the existence of a partially secured zone? > The main reason for this requirement is that as a "client" of DNSSEC I > do not want to be confronted with two security models. DNSSEC today > buys me the non-existence proof. As a client of the DNS I want all or > nothing. (I understand that all kind of client policy knobs can be > introduced but I do not think that is a good idea). 1. I am not suggesting it be compulsory :-) However, some people want incompletely signed zone-files because they are delegation only and 99% of the delegated zones are not secure - think of a TLD adopting DNSSEC - and they want to minimize the expansion in zone size and signing requirements. 2. I agree that it is not nice to have to cope with 2 security models. However, we already have that problem. If org.uk is signed (completely, i.e. without anything like opt-in), but alex.org.uk is unsigned, a client resolving www.alex.org.uk already has the problem of a return code that is "partially" secure - which it then has to treat as an insecure response - what the application does with it is up to the application. So I don't see any particular extension of the yuckiness if www.alex.org.uk returns an insecure result, www.abcd.org.uk returns a secure result, www.defg.org.uk returns a secure denial of existence, and www.hijk.org.uk returns an insecure denial of existence. IE as you've got to cope with unsigned names anyway, and insecure denial of existence anyway, I don't think there are additional client policy knobs to be introduced beyond what we've already got stuck with. Alex -- to 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/> From owner-namedroppers@ops.ietf.org Thu Oct 28 10:10:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15271 for <dnsext-archive@lists.ietf.org>; Thu, 28 Oct 2004 10:10:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNAtw-0004IN-AP for namedroppers-data@psg.com; Thu, 28 Oct 2004 14:05:16 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNAtv-0004H5-E1 for namedroppers@ops.ietf.org; Thu, 28 Oct 2004 14:05:15 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 2EEBE13E1B for <namedroppers@ops.ietf.org>; Thu, 28 Oct 2004 14:05:15 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: Denial Of Existence: Way Forward In-Reply-To: Message from "Olaf M. Kolkman" <olaf@ripe.net> of "Thu, 28 Oct 2004 09:32:52 +0200." <20041028093252.2f23c23d.olaf@ripe.net> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 28 Oct 2004 14:05:15 +0000 Message-Id: <20041028140515.2EEBE13E1B@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,OPT_IN autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ... > == Should the DNSEXT WG do this work > ... > In order to pursue this work as a working group item we will _not_ > ask the question > > "Does the group want to see this as a working group item" > > but will ask: > > 1) Who will commit to producing specifications for a denial of existence > method that does not allow for zone enumeration; > ... > 2) Who will commit on writing an implementation > ... > 3) Who will commit on reviewing the material > ... > The intend of this exercise is to see if there is sufficient > critical mass for this work to go forward. Please let us know if you > can commit to 1,2 and/or 3. isc has been asked for a proposal covering the above items, and so, you can count isc as having committed to all three. side note: i don't agree with alex that any of this touches on opt-in. while i was a strong proponent of opt-in, it's only a performance problem not a data visibility problem. i don't see any groundswell of support around the idea that operators of large zones shouldn't have to buy faster computers to sign their zones, and larger computers to serve those zones; only that changing the visibility of subdomain data was an unintended consequence of dnssec-bis that should now be undone somehow. -- to 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/> From owner-namedroppers@ops.ietf.org Thu Oct 28 10:38:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18333 for <dnsext-archive@lists.ietf.org>; Thu, 28 Oct 2004 10:38:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNB6F-0005nT-Jp for namedroppers-data@psg.com; Thu, 28 Oct 2004 14:17:59 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNB6E-0005nA-Gk for namedroppers@ops.ietf.org; Thu, 28 Oct 2004 14:17:58 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id E18434E1A7; Thu, 28 Oct 2004 16:17:57 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 8D2604FFC3; Thu, 28 Oct 2004 16:17:55 +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 i9SEHtx1013561; Thu, 28 Oct 2004 16:17:55 +0200 Date: Thu, 28 Oct 2004 16:17:55 +0200 From: "Olaf M. Kolkman" <olaf@ripe.net> To: Alex Bligh <alex@alex.org.uk> Cc: namedroppers@ops.ietf.org Subject: Re: Non-existence requirement: Completeness Message-Id: <20041028161755.6d0a5a46.olaf@ripe.net> In-Reply-To: <DB9856F9513FB218A8EAC3FC@[192.168.100.25]> References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <20041028135142.21e258a6.olaf@ripe.net> <DB9856F9513FB218A8EAC3FC@[192.168.100.25]> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.11 (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.004589 / -5.9 X-RIPE-Signature: 115117115992413c2e72631f9580eac8 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.4 required=5.0 tests=AWL,BAYES_00,OPT_IN, OPT_IN_CAPS autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I am not advocating dropping it - I am advocating making it optional > for parts of the zone (e.g. by having NSECx point the "next secure" > name and have an additional bit saying "between here and there there > may be zero or more insecure names"). I think that we would agree on the security property of this: any name that could exist between here and there cannot be securelly denied. > You are back then to saying does 17 as reworded preclude the existence > of a partially secured zone? Yes that is the effect of the rewording. The reworded text is was what I had in mind when I submitted the requirement. Only now I realize that it was not worded strong enough. > 1. I am not suggesting it be compulsory :-) However, some people want > incompletely signed zone-files because they are delegation only > and 99% of the delegated zones are not secure - think of a TLD > adopting DNSSEC - and they want to minimize the expansion in zone > size and signing requirements. I understand that argument. I also understand the pain of having to generateand sign a huge number or NSEC[++] records. While we had this discussion during the OPT-IN debate I suggested that I could live with OPT-IN for delegating zones only. After saying that I was taught that DNS protocol dependency on zone content is bad design. And I have been convinced that that is indeed the case. > 2. I agree that it is not nice to have to cope with 2 security models. > However, we already have that problem. If org.uk is signed > (completely, i.e. without anything like opt-in), but alex.org.uk > is unsigned, a client resolving www.alex.org.uk already has the > problem of a return code that is "partially" secure - which it > then has to treat as an insecure response - what the application > does with it is up to the application. So I don't see any particular > extension of the yuckiness if www.alex.org.uk returns an insecure > result, www.abcd.org.uk returns a secure result, www.defg.org.uk > returns a secure denial of existence, and www.hijk.org.uk returns > an insecure denial of existence. IE as you've got to cope with > unsigned names anyway, and insecure denial of existence anyway, > I don't think there are additional client > policy knobs to be introduced beyond what we've already got stuck > with. I am not sure if I understand this argument. The security model is on a per zone basis. In org.uk the situation is unambiguous and so is the situation in alex.org.uk. One could argue that there is little added value to DNSSEC in a delegation-only zone as long as the children are not secure (Roy is much better at arguing that than I am :-) ). But, the point is that once we allow for an OPT-IN mechanism you could deploy that mechanism on alex.org.uk and my resolver has to deal with the possibility that a franction of your zone is not secured. In other words, we have to assume that the solution that we design for TLDs will be used throughout the DNS tree. -- Olaf namedropper (no hats). ---------------------------------| 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Oct 28 10:42:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18750 for <dnsext-archive@lists.ietf.org>; Thu, 28 Oct 2004 10:42:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNBRd-0008CU-0M for namedroppers-data@psg.com; Thu, 28 Oct 2004 14:40:05 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNBRb-0008Bt-TO for namedroppers@ops.ietf.org; Thu, 28 Oct 2004 14:40:04 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18512; Thu, 28 Oct 2004 10:40:01 -0400 (EDT) Message-Id: <200410281440.KAA18512@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-trustupdate-timers-00.txt Date: Thu, 28 Oct 2004 10:40:01 -0400 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.64 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 : Automated Updates of DNSSEC Trust Anchors Author(s) : M. StJohns Filename : draft-ietf-dnsext-trustupdate-timers-00.txt Pages : 13 Date : 2004-10-27 This document describes a means for automated, authenticated and authorized updating of DNSSEC "trust anchors". The method provides protection against single key compromise of a key in the trust point key set. Based on the trust established by the presence of a current anchor, other anchors may be added at the same place in the hierarchy, and, ultimately, supplant the existing anchor. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-trustupdate-timers-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-trustupdate-timers-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-trustupdate-timers-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-28105539.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-trustupdate-timers-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-trustupdate-timers-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-28105539.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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Oct 28 10:43:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18834 for <dnsext-archive@lists.ietf.org>; Thu, 28 Oct 2004 10:43:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNBS6-0008HA-G5 for namedroppers-data@psg.com; Thu, 28 Oct 2004 14:40:34 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNBS5-0008Go-Be for namedroppers@ops.ietf.org; Thu, 28 Oct 2004 14:40:33 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18582; Thu, 28 Oct 2004 10:40:30 -0400 (EDT) Message-Id: <200410281440.KAA18582@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-trans-01.txt Date: Thu, 28 Oct 2004 10:40:30 -0400 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.64 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 : Evaluating DNSSEC Transition Mechanisms Author(s) : R. Arends, et al. Filename : draft-ietf-dnsext-dnssec-trans-01.txt Pages : 13 Date : 2004-10-27 This document collects and summarizes different proposals for alternative and additional strategies for authenticated denial in DNS responses, evaluates these proposals and gives a recommendation for a way forward. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-trans-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-trans-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-trans-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-28105545.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-trans-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-trans-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-28105545.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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Oct 28 11:09:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22969 for <dnsext-archive@lists.ietf.org>; Thu, 28 Oct 2004 11:09:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNBpu-000Bbg-67 for namedroppers-data@psg.com; Thu, 28 Oct 2004 15:05:10 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNBpm-000BaU-Nd for namedroppers@ops.ietf.org; Thu, 28 Oct 2004 15:05:03 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 90D54C2DA4; Thu, 28 Oct 2004 16:05:01 +0100 (BST) Date: Thu, 28 Oct 2004 16:04:55 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: "Olaf M. Kolkman" <olaf@ripe.net> Cc: namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> Subject: Re: Non-existence requirement: Completeness Message-ID: <984957C23DE0364B2EF70DB3@[192.168.100.25]> In-Reply-To: <20041028161755.6d0a5a46.olaf@ripe.net> References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <20041028135142.21e258a6.olaf@ripe.net> <DB9856F9513FB218A8EAC3FC@[192.168.100.25]> <20041028161755.6d0a5a46.olaf@ripe.net> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00,OPT_IN_CAPS autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 28 October 2004 16:17 +0200 "Olaf M. Kolkman" <olaf@ripe.net> wrote: >> I am not advocating dropping it - I am advocating making it optional >> for parts of the zone (e.g. by having NSECx point the "next secure" >> name and have an additional bit saying "between here and there there >> may be zero or more insecure names"). > > I think that we would agree on the security property of this: any name > that could exist between here and there cannot be securelly denied. Yes. Though a name that does exist could have this fact securely verified. > I am not sure if I understand this argument. The security model is on > a per zone basis. In org.uk the situation is unambiguous and so is the > situation in alex.org.uk. OK let me rephrase - always possible I'm missing the point. Assume org.uk is delegation only. Assume secure.org.uk is secure (i.e. DNSSEC-bis), and insecure.org.uk is not. Further, assume www.secure.org.uk, www.insecure.org.uk exist, and vvv.secure.org.uk, vvv.insecure.org.uk don't exist. At an API level (and I think this is what we are talking about), WITHOUT INTRODUCING PARTIALLY SIGNED ZONES (i.e. assume org.uk is DNSSEC-bis signed), you have the following results of a query (say) for an A record: www.secure.org.uk - secure, exists vvv.secure.org.uk - authenticated denial www.insecure.org.uk - insecure exists vvv.insecure.org.uk - unauthenticated denial (*) So the poor application / resolved library already has to adopt policy for authenticated and unauthenticated existence and non-existence. So, if partially signed zones were added, and a query was made for and org.uk was instead signed that way, and notthere.org.uk falls into an unsigned interval (see above) and does not exist, then a response for a query of www.notthere.org.uk of "unauthenticated denial" is going to come back. The policy logic for handling this I think already has to be there to cope with vvv.insecure.org.uk. I'm making an assumption here which is that at API/resolver library level people only care whether or not something exists (and whether or not that can be securely authenticated) - not why they don't exist. IE www.notthere.org.uk is the "same" to an application as vvv.insecure.org.uk, though the reason for the failure is different. > One could argue that there is little added value to DNSSEC in a > delegation-only zone as long as the children are not secure (Roy is > much better at arguing that than I am :-) ). But, the point is that > once we allow for an OPT-IN mechanism you could deploy that mechanism > on alex.org.uk and my resolver has to deal with the possibility that a > franction of your zone is not secured. > > In other words, we have to assume that the solution that we design for > TLDs will be used throughout the DNS tree. Yes, though I don't see how that changes things. Alex -- to 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/> From owner-namedroppers@ops.ietf.org Thu Oct 28 11:12:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23568 for <dnsext-archive@lists.ietf.org>; Thu, 28 Oct 2004 11:12:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNBtm-000C4y-Cc for namedroppers-data@psg.com; Thu, 28 Oct 2004 15:09:10 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNBtl-000C4b-Fb for namedroppers@ops.ietf.org; Thu, 28 Oct 2004 15:09:09 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id ACD30C2DA4; Thu, 28 Oct 2004 16:09:08 +0100 (BST) Date: Thu, 28 Oct 2004 16:09:03 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org Cc: Alex Bligh <alex@alex.org.uk> Subject: Re: Denial Of Existence: Way Forward Message-ID: <9B6CE64A6268BD5EC9EB2A56@[192.168.100.25]> In-Reply-To: <20041028140515.2EEBE13E1B@sa.vix.com> References: <20041028140515.2EEBE13E1B@sa.vix.com> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,OPT_IN autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 28 October 2004 14:05 +0000 Paul Vixie <paul@vix.com> wrote: > side note: i don't agree with alex that any of this touches on opt-in. I'm not going to die in a ditch over it. My main point is that opt-in is in the requirements matrix. If we are agreeing what this work item is (in forms 1, 2, and 3) we should at least be explicit whether or not opt-in is part of it, rather than be silent on the issue. A "third way" is to design an NSEC+ such that it intervals lacking authenticated denial can exist, but prohibit their use unless and until the security model / policy bit is sorted out. Given this requires putting in one bit and marking it reserved, it should not (surely) be too contentious. This at least means that if one ever decided to introduce opt-in, it's impact on the on-the-wire protocol would be minimal. Alex -- to 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/> From owner-namedroppers@ops.ietf.org Thu Oct 28 11:22:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25739 for <dnsext-archive@lists.ietf.org>; Thu, 28 Oct 2004 11:22:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNC46-000DIO-03 for namedroppers-data@psg.com; Thu, 28 Oct 2004 15:19:50 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNC45-000DI9-4b for namedroppers@ops.ietf.org; Thu, 28 Oct 2004 15:19:49 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id E436A13E12 for <namedroppers@ops.ietf.org>; Thu, 28 Oct 2004 15:19:48 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: Denial Of Existence: Way Forward In-Reply-To: Message from Alex Bligh <alex@alex.org.uk> of "Thu, 28 Oct 2004 16:09:03 +0100." <9B6CE64A6268BD5EC9EB2A56@[192.168.100.25]> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 28 Oct 2004 15:19:48 +0000 Message-Id: <20041028151948.E436A13E12@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,OPT_IN autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > side note: i don't agree with alex that any of this touches on opt-in. > > I'm not going to die in a ditch over it. My main point is that opt-in > is in the requirements matrix. If we are agreeing what this work > item is (in forms 1, 2, and 3) we should at least be explicit whether > or not opt-in is part of it, rather than be silent on the issue. then let's make it explicit in the way of olaf's strengthened language, which is to say, let's outlaw it. we cannot live through another round of opt-in debate, and i say that speaking as someone who thinks the last debate ended wrongly. > A "third way" is to design an NSEC+ such that it intervals lacking > authenticated denial can exist, but prohibit their use unless and > until the security model / policy bit is sorted out. Given this > requires putting in one bit and marking it reserved, it should not > (surely) be too contentious. This at least means that if one ever > decided to introduce opt-in, it's impact on the on-the-wire protocol > would be minimal. in order to reserve a bit, you have to describe client behaviour during the time when you're not yet sure what the bit means. you can say "interrim clients shall pay no attention to this bit" or "interrim clients shall treat responses having this bit set as being undefined, and drop them", or any number of things in between those fenceposts. my bet is that there is no definition of interrim client behaviour that will be useful to the future definition of opt-in, unless you can propose a versioning mechanism, such as EDNS(x=n). if you're going to propose a versioning mechanism, then you're already finished, since in EDNS(x<n) already reserves all unused bits. -- to 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/> From owner-namedroppers@ops.ietf.org Thu Oct 28 12:01:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06347 for <dnsext-archive@lists.ietf.org>; Thu, 28 Oct 2004 12:01:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNCel-000HZR-EU for namedroppers-data@psg.com; Thu, 28 Oct 2004 15:57:43 +0000 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNCek-000HZ6-Bd for namedroppers@ops.ietf.org; Thu, 28 Oct 2004 15:57:42 +0000 Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.12.11/8.12.11/TechFak/2004/05/05/sjaenick) with ESMTP id i9SFvePe025765 for <namedroppers@ops.ietf.org>; Thu, 28 Oct 2004 17:57:41 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id i9SFve612828 for <namedroppers@ops.ietf.org>; Thu, 28 Oct 2004 17:57:40 +0200 (MEST) Message-Id: <200410281557.i9SFve612828@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-dnssec-trans-01.txt In-reply-to: Your message of "Thu, 28 Oct 2004 10:40:30 EDT." <200410281440.KAA18582@ietf.org> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12825.1098979058.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Thu, 28 Oct 2004 17:57:40 +0200 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Title : Evaluating DNSSEC Transition Mechanisms > Author(s) : R. Arends, et al. > Filename : draft-ietf-dnsext-dnssec-trans-01.txt due to an editing 'malfunction' on my side this is just a resend with the new boilerplate text. An updated version will follow after IETF 61. Sorry, Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Oct 28 22:12:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21759 for <dnsext-archive@lists.ietf.org>; Thu, 28 Oct 2004 22:12:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNMAm-0001IM-P6 for namedroppers-data@psg.com; Fri, 29 Oct 2004 02:07:24 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNMAl-0001I2-P4 for namedroppers@ops.ietf.org; Fri, 29 Oct 2004 02:07:23 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i9T24FdN017345 for <namedroppers@ops.ietf.org>; Thu, 28 Oct 2004 22:04:15 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA6KaG1H; Thu, 28 Oct 04 22:04:08 -0400 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id i9T25ksH003300; Thu, 28 Oct 2004 22:05:46 -0400 (EDT) Date: Thu, 28 Oct 2004 22:05:45 -0400 (EDT) From: Samuel Weiler <weiler@tislabs.com> X-X-Sender: weiler@filbert To: "Olaf M. Kolkman" <olaf@ripe.net> cc: namedroppers@ops.ietf.org Subject: Re: Denial Of Existence: Way Forward In-Reply-To: <20041028093252.2f23c23d.olaf@ripe.net> Message-ID: <Pine.GSO.4.55.0410282149080.2892@filbert> References: <20041028093252.2f23c23d.olaf@ripe.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,OPT_IN autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Olaf writes: > If possible people should argue their preference for requirements > that cannot be reconciled (e.g. the opt-in type 11 is preferred over > complete non-existence from 17). With any luck we can compose a list > of "reconcilable requirements". I think there's a more productive direction to work from. About a month ago, I posted a message saying: > Given the potential for conflicting requirements, I'd find it useful > to see what sets of requirements go together. We might find that > there are multiple disjoint sets of users with confliciting > requirements, but that we can design a solution that works for each > set (or at least some of the sets). Does your raw source material > give you enough data to start constructing that matrix? The current matrix tells us what we can achieve, but it doesn't tell us what users (registries) want. We have a list of all of the requirements, but we don't have sets (i.e. user X has requirements 3, 10, 14, and 15). In particular, today's opt-in discussion has me wondering whether having a subset of a zone (the secured names) be ennumerable would present a problem for most of the users driving this work. If so, we need a solution that doesn't let that ennumeration happen. If enough users are okay with having all secured names ennumerable, perhaps we can just use the old opt-in (alone or in combination with another solution, like on-line signing). I'm hoping that by looking at the sets, we can say "solution X will help users 1,2,3", "Y will help 4,5,6", "Z will help 2 and 5", and "we have nothing to help user 7". Then we can decide to do X and Y and let user 7 suffer. -- 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Oct 29 04:18:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06570 for <dnsext-archive@lists.ietf.org>; Fri, 29 Oct 2004 04:18:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNRqa-0003Je-BU for namedroppers-data@psg.com; Fri, 29 Oct 2004 08:10:56 +0000 Received: from [81.91.161.3] (helo=smtp.denic.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNRqZ-0003JI-AJ for namedroppers@ops.ietf.org; Fri, 29 Oct 2004 08:10:55 +0000 Received: from notes.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1CNRqY-00021o-9f; Fri, 29 Oct 2004 10:10:54 +0200 In-Reply-To: <20041028093252.2f23c23d.olaf@ripe.net> To: "Olaf M. Kolkman" <olaf@ripe.net> Cc: namedroppers@ops.ietf.org Subject: Re: Denial Of Existence: Way Forward MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Marcos Sanz/Denic <sanz@denic.de> Message-ID: <OFEF8336D8.22F56BDC-ONC1256F3C.002C9E80-C1256F3C.002CEEB9@notes.denic.de> Date: Fri, 29 Oct 2004 10:10:46 +0200 X-MIMETrack: Serialize by Router on notes/Denic(Release 6.5.2|June 01, 2004) at 29.10.2004 10:10:54, Serialize complete at 29.10.2004 10:10:54 Content-Type: text/plain; charset="US-ASCII" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Olaf, > 1) Who will commit to producing specifications for a denial of existence > method that does not allow for zone enumeration; > [...] > 2) Who will commit on writing an implementation > [...] > 3) Who will commit on reviewing the material There are individuals more capable than me to achieve 1), thus I am personally committing to 3). Best, Marcos -- to 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/> From owner-namedroppers@ops.ietf.org Fri Oct 29 05:08:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09829 for <dnsext-archive@lists.ietf.org>; Fri, 29 Oct 2004 05:08:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNSgC-000Acc-U8 for namedroppers-data@psg.com; Fri, 29 Oct 2004 09:04:16 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNSgC-000AcC-0D for namedroppers@ops.ietf.org; Fri, 29 Oct 2004 09:04:16 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 7385FC2DA6; Fri, 29 Oct 2004 10:04:12 +0100 (BST) Date: Fri, 29 Oct 2004 10:04:05 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: Samuel Weiler <weiler@tislabs.com>, "Olaf M. Kolkman" <olaf@ripe.net> Cc: namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> Subject: Re: Denial Of Existence: Way Forward Message-ID: <D9B44B3886A2EEB6A3CCBFA9@[192.168.100.25]> In-Reply-To: <Pine.GSO.4.55.0410282149080.2892@filbert> References: <20041028093252.2f23c23d.olaf@ripe.net> <Pine.GSO.4.55.0410282149080.2892@filbert> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,OPT_IN autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > In particular, today's opt-in discussion has me wondering whether > having a subset of a zone (the secured names) be ennumerable would > present a problem for most of the users driving this work. It would for us. Non-enumerability of all names (secured and unsecured) is what we need. opt-in would be a "nice to have" (in terms of reducing zone expansion) but if it's extremely difficult / divisive etc. (I hear it is, don't understand why, but wasn't on namedroppers at the time) it's not a must-have. Alex -- to 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/> From owner-namedroppers@ops.ietf.org Fri Oct 29 05:28:04 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11213 for <dnsext-archive@lists.ietf.org>; Fri, 29 Oct 2004 05:28:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNSzi-000Dzg-Pl for namedroppers-data@psg.com; Fri, 29 Oct 2004 09:24:26 +0000 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNSzh-000DzK-Rd for namedroppers@ops.ietf.org; Fri, 29 Oct 2004 09:24:26 +0000 Received: from notes1.nominet.org.uk (wds1.dhcp.nominet.org.uk [213.248.197.128]) by mx1.nominet.org.uk (Postfix) with ESMTP id 865F6E7E50; Fri, 29 Oct 2004 10:24:24 +0100 (BST) In-Reply-To: <20041028093252.2f23c23d.olaf@ripe.net> To: "Olaf M. Kolkman" <olaf@ripe.net> Cc: namedroppers@ops.ietf.org Subject: Re: Denial Of Existence: Way Forward MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: <OF0E0D7110.AF4B47A4-ON80256F3C.00333BCA-80256F3C.0033BE00@nominet.org.uk> From: Jay Daley <td@nominet.org.uk> Date: Fri, 29 Oct 2004 10:26:31 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5|September 26, 2003) at 10/29/2004 10:26:31 AM, Serialize complete at 10/29/2004 10:26:31 AM Content-Type: text/plain; charset="US-ASCII" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Olaf > 1) Who will commit to producing specifications for a denial of existence > method that does not allow for zone enumeration; > > We would like to see at least 3 people, which will be assigned an > editors function, to commit. > > 2) Who will commit on writing an implementation > > We would like to see at least 1 individual or group committing to > develop (or fund development) of an implementation. We can certainly commit to doing and/or funding these two. > > > 3) Who will commit on reviewing the material > > We would like to see a set of people, different from the set of > editors, to commit to review throughout the development of the > specification. As this is a function that is probably best separated from 1) and 2) above all I will say is that, if needed, we can support someone independent doing this. We can also commit to doing and/or funding: 4) Interoperability testing between different implementations. Jay Daley Nominet UK -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Oct 29 07:02:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17167 for <dnsext-archive@lists.ietf.org>; Fri, 29 Oct 2004 07:02:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNUSF-000NM7-C6 for namedroppers-data@psg.com; Fri, 29 Oct 2004 10:57:59 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNUSE-000NLf-41 for namedroppers@ops.ietf.org; Fri, 29 Oct 2004 10:57:58 +0000 Received: from [193.133.15.218] (ben-xp2.ben.algroup.co.uk [193.133.15.218]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 7B26D107C2A; Fri, 29 Oct 2004 10:57:57 +0000 (GMT) Message-ID: <41822245.6020408@algroup.co.uk> Date: Fri, 29 Oct 2004 11:58:13 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Bligh <alex@alex.org.uk> Cc: "Olaf M. Kolkman" <olaf@ripe.net>, namedroppers@ops.ietf.org Subject: Re: Denial Of Existence: Way Forward References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> In-Reply-To: <9F54AB1A23C290B14DA2D366@[192.168.100.25]> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.5 required=5.0 tests=AWL,BAYES_00,OPT_IN, OPT_IN_CAPS autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Alex Bligh wrote: > Olaf, > > --On 28 October 2004 09:32 +0200 "Olaf M. Kolkman" <olaf@ripe.net> wrote: > >> == Denial of Existence and zone enumeration and a way forward. > > > Thanks for your note, none of which I disagree with. > > However, there is one other item that I *think* has now become entangled > with zone enumeration (and should probably stay entangled). This is support > of unsigned portions within a signed zone file (i.e. proposals giving > similar functionality to OPTIN). Having gone around the "why do people want > protection against zone enumeration" loop, it seems that there may well be > a large overlap in people who want that protection and those who want > support of unsigned portions of a zone file; and further, that if the > solution to zone enumeration is introducing a new NSEC variant, this could > be fixed at the same time. It is, after all, in the requirements document. > > I therefore wonder whether, when considering your questions (1)-(3), > whether they should not be asked in the context of zone enumeration > protection and (perhaps) optional support for unsigned areas of zone. > This may produce more people willing to commit resource. FWIW, this would be a natural outcome of the merging of the two NSEC++ documents (which I am partway through and would be happy to complete a first cut). I see from later discussion that some are not in favour of this, which leaves me unsure how to proceed. If opt-in is dropped, then (from memory), the only remaining point is whether hashing is done per-label or over the whole name. The obvious issue with per-label hashing is that it makes the hashed name even longer, and length is already a problem. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to 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/> From owner-namedroppers@ops.ietf.org Fri Oct 29 07:02:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17205 for <dnsext-archive@lists.ietf.org>; Fri, 29 Oct 2004 07:02:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNUUC-000Nfl-1W for namedroppers-data@psg.com; Fri, 29 Oct 2004 11:00:00 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNUUB-000NfM-3W for namedroppers@ops.ietf.org; Fri, 29 Oct 2004 10:59:59 +0000 Received: from [193.133.15.218] (ben-xp2.ben.algroup.co.uk [193.133.15.218]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 72EF2107C2A; Fri, 29 Oct 2004 10:59:58 +0000 (GMT) Message-ID: <418222BE.9080705@algroup.co.uk> Date: Fri, 29 Oct 2004 12:00:14 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Olaf M. Kolkman" <olaf@ripe.net> Cc: namedroppers@ops.ietf.org Subject: Re: Denial Of Existence: Way Forward References: <20041028093252.2f23c23d.olaf@ripe.net> In-Reply-To: <20041028093252.2f23c23d.olaf@ripe.net> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Olaf M. Kolkman wrote: > == Way forward > > There are two (known) ways to approach denial of existence proofs. > > a. Dynamically generated NSEC RRs > b. Pre computed "NSEC++" RRs that use some hash scheme to > obscure the namespace > > The requirements document that we have is implicitly based on 'b' > type solutions and can be used for further development. I don't agree with this. The requirements are applicable to both scenarios, though clearly each one satisfies a different subset of the requirements. If it would be useful, I can document those subsets. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to 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/> From owner-namedroppers@ops.ietf.org Fri Oct 29 16:40:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08262 for <dnsext-archive@lists.ietf.org>; Fri, 29 Oct 2004 16:40:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNdRd-000OkH-QO for namedroppers-data@psg.com; Fri, 29 Oct 2004 20:33:57 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNdRc-000Oju-Oz for namedroppers@ops.ietf.org; Fri, 29 Oct 2004 20:33:56 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i9TKUlKK008743 for <namedroppers@ops.ietf.org>; Fri, 29 Oct 2004 16:30:47 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA6maWcr; Fri, 29 Oct 04 16:30:43 -0400 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id i9TKWMpP026754 for <namedroppers@ops.ietf.org>; Fri, 29 Oct 2004 16:32:22 -0400 (EDT) Date: Fri, 29 Oct 2004 16:32:22 -0400 (EDT) From: Samuel Weiler <weiler@tislabs.com> X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org Subject: Re: Denial Of Existence: Way Forward In-Reply-To: <41822245.6020408@algroup.co.uk> Message-ID: <Pine.GSO.4.55.0410291610461.25617@filbert> References: <20041028093252.2f23c23d.olaf@ripe.net> <9F54AB1A23C290B14DA2D366@[192.168.100.25]> <41822245.6020408@algroup.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,OPT_IN autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 29 Oct 2004, Ben Laurie wrote: > If opt-in is dropped, then (from memory), the only remaining point > is whether hashing is done per-label or over the whole name. In San Diego, I did presentation comparing the two NSEC++ proposals, but I don't think a summary ever made it to the list (sorry about that). The slides are in the meeting proceedings: http://www.ietf.org/proceedings/04aug/slides/dnsext-7.pdf To summarize, in addition to the choice of whether hashing is per-label or not [1], the two proposals had three "options": opt-in, allowing hash iterations, and defining a null hash function. I think we can pick and choose among these, and I think both the iteration option and the null hash option are pretty trivial, but I don't recall us making any decisions about them. In my presentation, I also faulted both proposals for not describing how to change hash functions or salts (or number of iterations) and for not going into enough detail about wildcard processing. Both of those need to be addressed. I also worried about hash collisions, though people keep trying to convince me that the probabilities of a collision can be made vanishingly small. I'd rather see a mechanism for rolling (or allowing for coexistence of multiple) hashs and/or salts, but I'm willing to drop the collision concern. -- Sam [1] The choice of whether to do per-label or whole-name hashing could require the introduction of an EXIST RR and other changes to wildcard processing rules. Each choice also reveals different information about the zone: whole-name hashing (NSEC2) exposes the names of empty non-terminals (via the EXIST RR); per-label hashing (DNSNR/NSEC3) exposes the structure of the zone but not the names. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Oct 29 16:47:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09914 for <dnsext-archive@lists.ietf.org>; Fri, 29 Oct 2004 16:47:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNdcQ-00011K-1t for namedroppers-data@psg.com; Fri, 29 Oct 2004 20:45:06 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNdcO-00010e-V6 for namedroppers@ops.ietf.org; Fri, 29 Oct 2004 20:45:05 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i9TKfttC010256 for <namedroppers@ops.ietf.org>; Fri, 29 Oct 2004 16:41:55 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA3Waqbu; Fri, 29 Oct 04 16:41:53 -0400 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id i9TKhRXr027196; Fri, 29 Oct 2004 16:43:27 -0400 (EDT) Date: Fri, 29 Oct 2004 16:43:23 -0400 (EDT) From: Samuel Weiler <weiler@tislabs.com> X-X-Sender: weiler@filbert To: Ben Laurie <ben@algroup.co.uk> cc: namedroppers@ops.ietf.org Subject: Re: Denial Of Existence: Way Forward In-Reply-To: <418222BE.9080705@algroup.co.uk> Message-ID: <Pine.GSO.4.55.0410291609460.25617@filbert> References: <20041028093252.2f23c23d.olaf@ripe.net> <418222BE.9080705@algroup.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 29 Oct 2004, Ben Laurie wrote: > > The requirements are applicable to both scenarios, though clearly > each one satisfies a different subset of the requirements. If it > would be useful, I can document those subsets. I think this will be useful -- it will help us compare the requirements sets (see my message from yesterday) to the solutions. Also, I apologize for not being clearer in my original request for the requirements sets. -- 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: <http://ops.ietf.org/lists/namedroppers/>