From owner-namedroppers@ops.ietf.org Fri Apr 1 01:41:23 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27676 for ; Fri, 1 Apr 2005 01:41:22 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DHFkI-0007cC-8H for namedroppers-data@psg.com; Fri, 01 Apr 2005 06:35:06 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DHFkG-0007b5-25 for namedroppers@ops.ietf.org; Fri, 01 Apr 2005 06:35:04 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 5785523FA8; Fri, 1 Apr 2005 08:35:03 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 61DE825012 for ; Fri, 1 Apr 2005 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 j316Z2et007148 for ; Fri, 1 Apr 2005 08:35:02 +0200 Received: (from olaf@localhost) by x50.ripe.net (8.12.10/8.12.6) id j316Z19e026928 for namedroppers@ops.ietf.org; Fri, 1 Apr 2005 08:35:01 +0200 Date: Fri, 1 Apr 2005 08:35:01 +0200 From: Olaf Kolkman Message-Id: <200504010635.j316Z19e026928@x50.ripe.net> To: namedroppers@ops.ietf.org Subject: DNSEXT list policy X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: U 0.490845 / -5.9 X-RIPE-Signature: e2c4431c0b37637cff030963d80beb73 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 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 --- 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.8 2005/01/12 15:54:51 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: From owner-namedroppers@ops.ietf.org Fri Apr 1 04:53:33 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07297 for ; Fri, 1 Apr 2005 04:53:32 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DHImx-0004G9-DJ for namedroppers-data@psg.com; Fri, 01 Apr 2005 09:50:03 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DHImt-0004Ef-1U for namedroppers@ops.ietf.org; Fri, 01 Apr 2005 09:49:59 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 1EE61C2DA8; Fri, 1 Apr 2005 10:49:58 +0100 (BST) Date: Fri, 01 Apr 2005 10:49:51 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Edward Lewis Cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: NSEC3-01 - more wildcard nits Message-ID: <31D419785141EF1A7568BC2C@[192.168.100.25]> In-Reply-To: References: <60B518B2765E3A4DD5D8F060@[192.168.100.25]> X-Mailer: Mulberry/4.0.0a5 (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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> Sure, zone publishers will need to pick a day when they don't want to >> support old NSEC anymore. But why an internet wide flag day? > > Fair 'nuf question. This is what I'm thinking. > > The problem I can't get over is that I presume that admins using NSEC* > are the ones that don't want to use NSEC. It's not like NSEC* adopters > will be happy to also do NSEC. Although the two do not interfere, the > reason for NSEC* is that NSEC shouldn't exist. Nit: Some NSEC* adopters may be happy to do NSEC initially. IE some existing NSEC operators may adopt NSEC* either to get (for instance) opt-in (to reduce zone file size), because they don't like enumeration but can live with it, because they know all resolvers will eventually go NSEC* only, etc. - but the common theme here is they'll all want to get rid of NSEC support eventually. > Assuming there will be NSEC-era validators out there before NSEC* gets > rolling, once there are NSEC* zones out there, these validators will see > the NSEC* zones as broken because there are no NSEC records there. I think the NSEC-era validators will see such NSEC* zones as insecure. Just like they do now. Worst case, they will not understand the DNSSEC-ter records at all, and will see vanilla DNS records. If there are DNSSEC-bis records there too then they'll use them (but as you point out, at least a subset of NSEC* adopters will not have such records, and the remainder will want to get rid of them). > All > of the NSEC-era validators would have to be replaced - that's the flag > day or event - because in the meantime, the "extra secure" NSEC* zones > may just be cut off if these zones are judged to be broken. Yes, they will have to be replaced. But I don't see why it's a flag day (i.e. a single event) - until they are replaced, the NSEC* zones will just appear insecure ("oooh look this zone has a bunch of RR types I don't understand"). > Maybe its only negative answers that will be broken. Questions remain. Worst case TCR etc. may break authenticated positive answers too. I still don't see why it's a flag day. Perhaps we mean different things by "flag day". 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: From owner-namedroppers@ops.ietf.org Fri Apr 1 05:07:21 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07958 for ; Fri, 1 Apr 2005 05:07:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DHJ1c-0006nH-CV for namedroppers-data@psg.com; Fri, 01 Apr 2005 10:05:12 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DHJ1a-0006mh-54 for namedroppers@ops.ietf.org; Fri, 01 Apr 2005 10:05:10 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 15A6133C6B; Fri, 1 Apr 2005 11:05:08 +0100 (BST) Message-ID: <424D1C5A.1080804@algroup.co.uk> Date: Fri, 01 Apr 2005 11:03:06 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Bligh Cc: Edward Lewis , namedroppers@ops.ietf.org Subject: Re: NSEC3-01 - more wildcard nits References: <60B518B2765E3A4DD5D8F060@[192.168.100.25]> <31D419785141EF1A7568BC2C@[192.168.100.25]> In-Reply-To: <31D419785141EF1A7568BC2C@[192.168.100.25]> X-Enigmail-Version: 0.89.6.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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Alex Bligh wrote: >>> Sure, zone publishers will need to pick a day when they don't want to >>> support old NSEC anymore. But why an internet wide flag day? >> >> >> Fair 'nuf question. This is what I'm thinking. >> >> The problem I can't get over is that I presume that admins using NSEC* >> are the ones that don't want to use NSEC. It's not like NSEC* adopters >> will be happy to also do NSEC. Although the two do not interfere, the >> reason for NSEC* is that NSEC shouldn't exist. > > > Nit: Some NSEC* adopters may be happy to do NSEC initially. IE some > existing NSEC operators may adopt NSEC* either to get (for instance) > opt-in (to reduce zone file size), because they don't like enumeration > but can live with it, because they know all resolvers will eventually > go NSEC* only, etc. - but the common theme here is they'll all want > to get rid of NSEC support eventually. Note that we have never suggested that NSEC++ should replace NSEC - it is an alternative which can be used, or not, at the operators discretion. >> Assuming there will be NSEC-era validators out there before NSEC* gets >> rolling, once there are NSEC* zones out there, these validators will see >> the NSEC* zones as broken because there are no NSEC records there. > > I think the NSEC-era validators will see such NSEC* zones as insecure. Just > like they do now. Worst case, they will not understand the DNSSEC-ter > records at all, and will see vanilla DNS records. If there are DNSSEC-bis > records there too then they'll use them (but as you point out, at least > a subset of NSEC* adopters will not have such records, and the remainder > will want to get rid of them). > >> All >> of the NSEC-era validators would have to be replaced - that's the flag >> day or event - because in the meantime, the "extra secure" NSEC* zones >> may just be cut off if these zones are judged to be broken. > > > Yes, they will have to be replaced. But I don't see why it's a flag > day (i.e. a single event) - until they are replaced, the NSEC* zones > will just appear insecure ("oooh look this zone has a bunch of RR types > I don't understand"). Failure to understand RR types does not make a zone insecure. What will appear insecure in negative responses, which will lack the appropriate proof. -- 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: From owner-namedroppers@ops.ietf.org Fri Apr 1 05:14:14 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08548 for ; Fri, 1 Apr 2005 05:14:13 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DHJ7f-00087M-KI for namedroppers-data@psg.com; Fri, 01 Apr 2005 10:11:27 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DHJ7e-000877-Mh for namedroppers@ops.ietf.org; Fri, 01 Apr 2005 10:11:26 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 140A433C74; Fri, 1 Apr 2005 11:11:25 +0100 (BST) Message-ID: <424D1DD3.10800@algroup.co.uk> Date: Fri, 01 Apr 2005 11:09:23 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Edward Lewis Cc: Alex Bligh , namedroppers@ops.ietf.org Subject: Re: NSEC3-01 - more wildcard nits References: In-Reply-To: X-Enigmail-Version: 0.89.6.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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward Lewis wrote: > PS I still have my doubts about finding a successor to NSEC. A flag day > would be needed to erase existing NSEC from the DNS and be seamless. > Even if the thought is that "NSEC-era" verifiers will be upgraded to > overcome this, that's the flag day. Remember that the plan does not include erasing NSEC. -- 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: From owner-namedroppers@ops.ietf.org Fri Apr 1 05:14:20 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08592 for ; Fri, 1 Apr 2005 05:14:19 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DHJ7l-00087j-JW for namedroppers-data@psg.com; Fri, 01 Apr 2005 10:11:33 +0000 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DHJ7i-00087U-PK for namedroppers@ops.ietf.org; Fri, 01 Apr 2005 10:11:30 +0000 Received: by mx1.nominet.org.uk (Postfix, from userid 65536) id 2DCC5E7E59; Fri, 1 Apr 2005 11:11:30 +0100 (BST) To: namedroppers@ops.ietf.org Subject: Re: NSEC3-01 - more wildcard nits In-Reply-To: <31D419785141EF1A7568BC2C@[192.168.100.25]> Message-Id: <20050401101130.2DCC5E7E59@mx1.nominet.org.uk> Date: Fri, 1 Apr 2005 11:11:30 +0100 (BST) From: geoff@nominet.org.uk (Geoffrey Sisson) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,BIZ_TLD autolearn=no version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward Lewis : > Although the two do not interfere, the > reason for NSEC* is that NSEC shouldn't exist. As I see it the reason for NSEC* is that enumeration is an issue for some (maybe many) DNS operators, but certainly not all. I don't see why multiple denial of existence methods can't coexist. NSEC3 requires authoritative name servers to do more work (hashing QNAMEs), so if enumeration isn't an issue then NSEC would be the method of choice. Regards Geoff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 1 05:17:33 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08829 for ; Fri, 1 Apr 2005 05:17:33 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DHJBH-0008aN-8I for namedroppers-data@psg.com; Fri, 01 Apr 2005 10:15:11 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DHJBE-0008Zp-6P for namedroppers@ops.ietf.org; Fri, 01 Apr 2005 10:15:08 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 5D6E8C2DA8; Fri, 1 Apr 2005 11:15:07 +0100 (BST) Date: Fri, 01 Apr 2005 11:15:00 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Ben Laurie Cc: Edward Lewis , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: NSEC3-01 - more wildcard nits Message-ID: In-Reply-To: <424D1C5A.1080804@algroup.co.uk> References: <60B518B2765E3A4DD5D8F060@[192.168.100.25]> <31D419785141EF1A7568BC2C@[192.168.100.25]> <424D1C5A.1080804@algroup.co.uk> X-Mailer: Mulberry/4.0.0a5 (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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 01 April 2005 11:03 +0100 Ben Laurie wrote: > Failure to understand RR types does not make a zone insecure. What will > appear insecure in negative responses, which will lack the appropriate > proof. Clarification: I was being lazy in expressing my argument. If you can get away with "just" impacting negative answers, then fine (that's introducing another RR type for NSEC3 only). Ed says (putting words into his mouth) "this may cause problems - perhaps for instance a resolver might adversely treat answers from a server that never gave NSEC responses, because that's currently a 'MUST'" (I take it that's what he meant by 'questions remain'). My response to this is "OK, so worst case, you make new type codes for ALL the DNSSEC stuff, so we have RRSIG3 etc. which have to be present with NSEC3 records - then any NSEC-era resolver will see a NSEC3 zone that does not also have NSEC records as also lacking (for instance) RRSIG records (coz it would have RRSIG3 instead), and hence treat the entire zone as insecure". Now I'm not suggesting we do the above if we can avoid it, but it seems better than avoiding a flag day. Personally I think Ed's question is valid one to ask, because the corollary of the "well of course there is no problem" response is that those who don't want to deploy NSEC could *currently* deploy DNSSECbis omitting the NSEC records, and no harm would come except for the lack of authenticated denial. Lots of people on this list said this would be a bad thing (TM) not so long ago. But it's exactly the position we'd find ourselves in with respect to NSEC-era resolvers if NSEC3 was 'merely' a new RR type code. Again, apologies precaffeinated post. 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: From owner-namedroppers@ops.ietf.org Fri Apr 1 05:27:49 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09528 for ; Fri, 1 Apr 2005 05:27:49 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DHJKd-0009zI-94 for namedroppers-data@psg.com; Fri, 01 Apr 2005 10:24:51 +0000 Received: from [195.54.233.67] (helo=shaun.rfc1035.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DHJKb-0009yv-O4 for namedroppers@ops.ietf.org; Fri, 01 Apr 2005 10:24:50 +0000 Received: from shaun.rfc1035.com (shaun.rfc1035.com [195.54.233.67]) by shaun.rfc1035.com (8.12.10/8.12.10) with ESMTP id j31AOcGW005285; Fri, 1 Apr 2005 11:24:38 +0100 (BST) To: Alex Bligh cc: Edward Lewis , namedroppers@ops.ietf.org Subject: Re: NSEC3-01 - more wildcard nits In-Reply-To: Message from Alex Bligh of "Fri, 01 Apr 2005 10:49:51 BST." <31D419785141EF1A7568BC2C@[192.168.100.25]> Date: Fri, 01 Apr 2005 11:24:38 +0100 Message-ID: <5284.1112351078@shaun.rfc1035.com> From: Jim Reid X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Alex" == Alex Bligh writes: Alex> Nit: Some NSEC* adopters may be happy to do NSEC Alex> initially. Alex> ...... but the common theme here is they'll all want Alex> to get rid of NSEC support eventually. They may *want* to. Whether they can is another matter. Our DNS zoo has many strange beasts. Some of those are dinosaurs that query for long deprecated RR types, can't do negative cacheing, don't understand ENDS0, misbehave when they see an unknown (to them) RRtype, etc, etc. Getting those beasties upgraded or killed off isn't always possible even if there was a protocol police that had the power and resources to do that. Once NSEC is in use it will be very hard to get that particular genie back in its bottle. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 1 05:29:16 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09659 for ; Fri, 1 Apr 2005 05:29:15 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DHJN1-000ANx-NA for namedroppers-data@psg.com; Fri, 01 Apr 2005 10:27:19 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DHJMy-000ANQ-V3 for namedroppers@ops.ietf.org; Fri, 01 Apr 2005 10:27:17 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id E72BBC2DA8; Fri, 1 Apr 2005 11:27:13 +0100 (BST) Date: Fri, 01 Apr 2005 11:27:08 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Geoffrey Sisson , namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: NSEC3-01 - more wildcard nits Message-ID: <0F9BE67DEAF5D5090F776C06@[192.168.100.25]> In-Reply-To: <20050401101130.2DCC5E7E59@mx1.nominet.org.uk> References: <20050401101130.2DCC5E7E59@mx1.nominet.org.uk> X-Mailer: Mulberry/4.0.0a5 (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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 01 April 2005 11:11 +0100 Geoffrey Sisson wrote: >> Although the two do not interfere, the >> reason for NSEC* is that NSEC shouldn't exist. > > As I see it the reason for NSEC* is that enumeration is an issue for > some (maybe many) DNS operators, but certainly not all. I don't see > why multiple denial of existence methods can't coexist. NSEC3 requires > authoritative name servers to do more work (hashing QNAMEs), so if > enumeration isn't an issue then NSEC would be the method of choice. NSEC3 with an identity hash algorithm would fulfil that goal. We already have other reasons to do that (see my post re long names). (that doesn't mean they *can't* coexist of course, I'm just not yet sure they need to). 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: From owner-namedroppers@ops.ietf.org Fri Apr 1 05:31:34 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09867 for ; Fri, 1 Apr 2005 05:31:34 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DHJPI-000Ala-RE for namedroppers-data@psg.com; Fri, 01 Apr 2005 10:29:40 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DHJPH-000Al1-0K for namedroppers@ops.ietf.org; Fri, 01 Apr 2005 10:29:39 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 509A3C2DA8; Fri, 1 Apr 2005 11:29:38 +0100 (BST) Date: Fri, 01 Apr 2005 11:29:32 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Jim Reid Cc: Edward Lewis , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: NSEC3-01 - more wildcard nits Message-ID: <77CA0CBA3E261D5287DA8019@[192.168.100.25]> In-Reply-To: <5284.1112351078@shaun.rfc1035.com> References: <5284.1112351078@shaun.rfc1035.com> X-Mailer: Mulberry/4.0.0a5 (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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 01 April 2005 11:24 +0100 Jim Reid wrote: > They may *want* to. Whether they can is another matter. > > Our DNS zoo has many strange beasts. Some of those are dinosaurs that > query for long deprecated RR types, can't do negative cacheing, don't > understand ENDS0, misbehave when they see an unknown (to them) RRtype, > etc, etc. Getting those beasties upgraded or killed off isn't always > possible even if there was a protocol police that had the power and > resources to do that. Once NSEC is in use it will be very hard to get > that particular genie back in its bottle. Agree, but those who start using (i.e. publishing) NSEC then, then add NSEC*, then at some stage stop using NSEC, are in no worse position than those who who never used NSEC and went straight to 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: From owner-namedroppers@ops.ietf.org Fri Apr 1 05:48:15 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11141 for ; Fri, 1 Apr 2005 05:48:15 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DHJeR-000Ck5-Kr for namedroppers-data@psg.com; Fri, 01 Apr 2005 10:45:19 +0000 Received: from [195.54.233.67] (helo=shaun.rfc1035.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DHJeO-000Cji-FP for namedroppers@ops.ietf.org; Fri, 01 Apr 2005 10:45:16 +0000 Received: from shaun.rfc1035.com (shaun.rfc1035.com [195.54.233.67]) by shaun.rfc1035.com (8.12.10/8.12.10) with ESMTP id j31AjEGW005316; Fri, 1 Apr 2005 11:45:14 +0100 (BST) To: geoff@nominet.org.uk (Geoffrey Sisson) cc: namedroppers@ops.ietf.org Subject: Re: NSEC3-01 - more wildcard nits In-Reply-To: Message from geoff@nominet.org.uk (Geoffrey Sisson) of "Fri, 01 Apr 2005 11:11:30 BST." <20050401101130.2DCC5E7E59@mx1.nominet.org.uk> Date: Fri, 01 Apr 2005 11:45:14 +0100 Message-ID: <5315.1112352314@shaun.rfc1035.com> From: Jim Reid X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Geoffrey" == Geoffrey Sisson writes: Geoffrey> I don't see why multiple denial of existence methods Geoffrey> can't coexist. Well for starters, there's the extra complexity for implementors and applications developers. Not to mention the additional complexity in configuring and operating name servers. This then creates added administrative and policy problems: what does something do if a zone is signed but not with its preferred (only?) DoE method? What if a zone gets (accidentally?) signed using multiple DoE methods -- silly I know -- assuming they aren't mutually exclusive (syntactically or semantically)? Or will it be one zone, one method? How many DoE methods is "too many": 2? 10? 100? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 1 05:55:32 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11688 for ; Fri, 1 Apr 2005 05:55:32 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DHJlE-000DYa-CC for namedroppers-data@psg.com; Fri, 01 Apr 2005 10:52:20 +0000 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DHJlD-000DYA-M6 for namedroppers@ops.ietf.org; Fri, 01 Apr 2005 10:52:19 +0000 Received: by mx1.nominet.org.uk (Postfix, from userid 65536) id 470E8E7E71; Fri, 1 Apr 2005 11:52:18 +0100 (BST) To: namedroppers@ops.ietf.org Subject: Re: NSEC3-01 - more wildcard nits In-Reply-To: <0F9BE67DEAF5D5090F776C06@[192.168.100.25]> Message-Id: <20050401105218.470E8E7E71@mx1.nominet.org.uk> Date: Fri, 1 Apr 2005 11:52:18 +0100 (BST) From: geoff@nominet.org.uk (Geoffrey Sisson) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Alex Bligh writes: > NSEC3 with an identity hash algorithm would fulfil that goal. We already > have other reasons to do that (see my post re long names). (that doesn't > mean they *can't* coexist of course, I'm just not yet sure they need to). I should have qualified that as "NSEC3 as per the current draft". NSEC has other advantages: better transparency (easier to troubleshoot) and (probably) more compact replies. But I agree that the main advantage goes away if something like the identity hash algorithm can be made to work with a hash-based NSEC*. Regards Geoff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 1 06:09:12 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08545 for ; Fri, 1 Apr 2005 05:14:13 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DHJ8Y-0008Cw-Gv for namedroppers-data@psg.com; Fri, 01 Apr 2005 10:12:22 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DHJ8X-0008Cf-JR for namedroppers@ops.ietf.org; Fri, 01 Apr 2005 10:12:21 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id E082A33C5F; Fri, 1 Apr 2005 11:12:19 +0100 (BST) Message-ID: <424D1E0A.7090504@algroup.co.uk> Date: Fri, 01 Apr 2005 11:10:18 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Edward Lewis Cc: Samuel Weiler , namedroppers@ops.ietf.org Subject: Re: Two more NSEC++ proposals References: In-Reply-To: X-Enigmail-Version: 0.89.6.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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward Lewis wrote: > At 16:14 -0500 3/31/05, Samuel Weiler wrote: > >> Proposal 1: >> >> One could also create a delegation within the zone to keep these >> names in one place: > > > It is not wise to propose a new TLD in a protocol document. What TLD? None was proposed that I can see. >> Proposal 2: > > >> The authoritative server keeps a table of these and selects the >> right one, along with its RRSIG, whenever needed. > > > This is broken on so many levels. For one, database coherency. Why? -- 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: From owner-namedroppers@ops.ietf.org Fri Apr 1 06:38:47 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15002 for ; Fri, 1 Apr 2005 06:38:47 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DHKRz-000K7A-Jh for namedroppers-data@psg.com; Fri, 01 Apr 2005 11:36:31 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DHKRy-000K6x-Mi for namedroppers@ops.ietf.org; Fri, 01 Apr 2005 11:36:30 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j31BZJZZ016852; Fri, 1 Apr 2005 06:35:19 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <424D1E0A.7090504@algroup.co.uk> References: <424D1E0A.7090504@algroup.co.uk> Date: Fri, 1 Apr 2005 06:31:20 -0500 To: Ben Laurie From: Edward Lewis Subject: Re: Two more NSEC++ proposals Cc: Edward Lewis , Samuel Weiler , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:10 +0100 4/1/05, Ben Laurie wrote: >Edward Lewis wrote: >> At 16:14 -0500 3/31/05, Samuel Weiler wrote: >> >>> Proposal 1: >>> >>> One could also create a delegation within the zone to keep these >>> names in one place: >> >> It is not wise to propose a new TLD in a protocol document. > >What TLD? None was proposed that I can see. "The zone" -> it that's the root, the "create a delegation" is a new TLD. This has been raised before. >>> Proposal 2: >> >>> The authoritative server keeps a table of these and selects the >>> right one, along with its RRSIG, whenever needed. >> >> This is broken on so many levels. For one, database coherency. > >Why? For one, this breaks the RRSet rules in RFC 2181. You have authoritative servers giving different RRs for the same (OWNER, TYPE, CLASS) triple. What's a cache to do? It's not going to combine them... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 1 06:50:16 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15922 for ; Fri, 1 Apr 2005 06:50:16 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DHKdB-000Lju-91 for namedroppers-data@psg.com; Fri, 01 Apr 2005 11:48:05 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DHKd8-000Lic-5Q for namedroppers@ops.ietf.org; Fri, 01 Apr 2005 11:48:02 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 678D933C45; Fri, 1 Apr 2005 12:48:00 +0100 (BST) Message-ID: <424D3477.6090704@algroup.co.uk> Date: Fri, 01 Apr 2005 12:45:59 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Edward Lewis Cc: Samuel Weiler , namedroppers@ops.ietf.org Subject: Re: Two more NSEC++ proposals References: <424D1E0A.7090504@algroup.co.uk> In-Reply-To: X-Enigmail-Version: 0.89.6.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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward Lewis wrote: > At 11:10 +0100 4/1/05, Ben Laurie wrote: > >> Edward Lewis wrote: >> >>> At 16:14 -0500 3/31/05, Samuel Weiler wrote: >>> >>>> Proposal 1: >>>> >>>> One could also create a delegation within the zone to keep these >>>> names in one place: >>> >>> >>> It is not wise to propose a new TLD in a protocol document. >> >> >> What TLD? None was proposed that I can see. > > > "The zone" -> it that's the root, the "create a delegation" is a new > TLD. This has been raised before. I don't think the root cares about enumeration :-) >>>> Proposal 2: >>> >>> >>>> The authoritative server keeps a table of these and selects the >>>> right one, along with its RRSIG, whenever needed. >>> >>> >>> This is broken on so many levels. For one, database coherency. >> >> >> Why? > > > For one, this breaks the RRSet rules in RFC 2181. > > You have authoritative servers giving different RRs for the same (OWNER, > TYPE, CLASS) triple. > > What's a cache to do? It's not going to combine them... Cache's are already supposed to store negative responses against the query triple, so I don't see why this is an issue? Cheers, Ben. -- 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: From owner-namedroppers@ops.ietf.org Fri Apr 1 07:02:40 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16660 for ; Fri, 1 Apr 2005 07:02:39 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DHKnm-000NRZ-VM for namedroppers-data@psg.com; Fri, 01 Apr 2005 11:59:02 +0000 Received: from [202.12.73.64] (helo=fivedots.coe.psu.ac.th) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DHKnj-000NQu-2Z for namedroppers@ops.ietf.org; Fri, 01 Apr 2005 11:58:59 +0000 Received: from delta.coe.psu.ac.th ([172.30.0.98] helo=delta.noi.kre.to) by fivedots.coe.psu.ac.th with esmtp (Exim 3.36 #1 (Debian)) id 1DHKnf-000528-00; Fri, 01 Apr 2005 18:58:55 +0700 Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.11/8.11.6) with ESMTP id j31Bwbnh004908; Fri, 1 Apr 2005 18:58:37 +0700 (ICT) From: Robert Elz To: Edward Lewis cc: namedroppers@ops.ietf.org Subject: Re: wcard discussions in Minneapolis In-Reply-To: References: <200503291826.j2TIQ0o03847@zeder.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 01 Apr 2005 18:58:37 +0700 Message-ID: <27172.1112356717@munnari.OZ.AU> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,BIZ_TLD autolearn=no version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Tue, 29 Mar 2005 13:57:25 -0500 From: Edward Lewis Message-ID: | How about we document that there are inconsistencies in the | definition of DNS which lead to unclear semantics when asterisk | labels are delegation points or DNAME rewrite points. I'm going to skip DNAME for a minute, since I don't recall its spec well enough to comment, But for NS, I don't understand this at all, nor most of the other comments on this thread (the ones I've just read, which isn't all of them). Everyone seems to be assuming that there's something undefined about "* NS". Nonsense. What's there now is perfectly well specified. It's useless, and a bit bizarre, but undefined it isn't. Much of the "it is undefined" can be traced back to really meaning "it isn't defined to do what I think it should do" (which is perfectly possible, but utterly irrelevant), or "when I skimmed the RFC it wasn't obvious to me what happens" which is also possible, and is (part of) what the wildcard clarify doc is supposed to be fixing. I fully understand that lots of people don't like having it defined as it is currently, and making it be undefined would be a fine first step in later being able to supply a definition (different than the current one). But if that's to happen, everyone needs to be very clear, that what is happening is a change to the DNS - an explicit and deliberate change, not just a clarification or fixup of what has been there for decades now. That might be OK (after all, the WG did decide to change the definition of "* CNAME" - and recognised it as being an actual change). Just please, when considering this question, don't start out from "it is undefined" or "it is ambiguous" or anything else like that, because it isn't. What is there now is perfectly well defined, and 100% useless for anything. In some sense, all the wcard clarifications doc really needs to say is that - just make it clear to everyone that "* NS" isn't going to produce any meaningful result (in the wildcard sense). Even explaining why that's true probably isn't required. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 1 07:38:52 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18973 for ; Fri, 1 Apr 2005 07:38:52 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DHLNT-0002Y6-TF for namedroppers-data@psg.com; Fri, 01 Apr 2005 12:35:55 +0000 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.44 (FreeBSD)) id 1DHLNS-0002Xl-5M for namedroppers@ops.ietf.org; Fri, 01 Apr 2005 12:35:54 +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/2005/03/01/sjaenick) with ESMTP id j31CZqsr001054 for ; Fri, 1 Apr 2005 14:35:52 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id j31CZq612147 for ; Fri, 1 Apr 2005 14:35:52 +0200 (MEST) Message-Id: <200504011235.j31CZq612147@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org Subject: Re: wcard discussions in Minneapolis In-reply-to: Your message of "Wed, 30 Mar 2005 10:45:03 +0200." <20050330104503.35033402.olaf@ripe.net> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-ID: <12142.1112358951.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Content-Transfer-Encoding: quoted-printable Date: Fri, 01 Apr 2005 14:35:52 +0200 From: Peter Koch X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Olaf M. Kolkman wrote: > > of their being inconsistencies, i.e., no right and wrong, no best = > > current practice, we declare that we are not going to delineate rules = > > at this time. = > Sounds like a fair approach to me. Anybody not agreeing raise your voice= s. it's less than we had achieved and I'd rather not lose those results. If I remember correctly, we agreed that "* NS" would never lead to the "na=EFve" result, i.e. it won't create all the zones/delegations on the fl= y. It would be helpful to document that, at the very least in a non-normative appendix. The two remaining options were treating "* NS" as a normal label= , which would, however, require a change to DNSSEC-bis or to disallow it, with interoperability problems if servers inconsistently chose to accept or reject a zone containing * NS. So, a zone maintainer should never expect any useful results, even if their DNS server software is homogeneou= s. Wildcard "clarify" is not only targeted at implementors, so the more guida= nce there is, the better. That's also true for documenting - again, in an appe= ndix - corner cases like those names below a '*' that are not covered by the wild= card. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 1 10:36:55 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05467 for ; Fri, 1 Apr 2005 10:36:54 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DHO8B-00035T-Hm for namedroppers-data@psg.com; Fri, 01 Apr 2005 15:32:19 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DHO8A-00035D-EP for namedroppers@ops.ietf.org; Fri, 01 Apr 2005 15:32:18 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j31FW4N0017581; Fri, 1 Apr 2005 10:32:04 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <27172.1112356717@munnari.OZ.AU> References: <200503291826.j2TIQ0o03847@zeder.TechFak.Uni-Bielefeld.DE> <27172.1112356717@munnari.OZ.AU> Date: Fri, 1 Apr 2005 10:32:11 -0500 To: Robert Elz From: Edward Lewis Subject: Re: wcard discussions in Minneapolis Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 18:58 +0700 4/1/05, Robert Elz wrote: >Everyone seems to be assuming that there's something undefined about >"* NS". Nonsense. What's there now is perfectly well specified. > >It's useless, and a bit bizarre, but undefined it isn't. I have to respectively disagree on that. '* NS' was once well defined, but then two things happened. 1) The arm wrestling over the legitimacy of synthesizing a name that you are delegating away. - As one of my co-bar patrons says, it's not the NS that indicates delegation, but the SOA. I don't agree, I still think it's the parent's placement of an NS set. (The parent is authoritative for the existence of the NS, but not the contents.) - This arm wrestling was purely an academic exercise until: 2) DNSSEC is picky about legitimacy of data. The problem is that by following rules regarding who's authoritative for data and therefore who can sign and following rules for synthesizing records, we hit a discontinuity in the domain-zone continuum. ...what this situation make me think about is the appearance of RFC 2136 and the profound impact it has on the definition of DNS even though what it is adding is somewhat "window dressing" and is only moderately deployed. (I mean Dynamic Update.) I.e., DNSSEC and Dynamic Update have both uncovered dirtly little incompletenesses in the original specifications. Where once we were confident we knew DNS, we are not always so sure. That's why I am disagreeing. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 1 10:37:20 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05488 for ; Fri, 1 Apr 2005 10:37:20 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DHOAd-0003SQ-JS for namedroppers-data@psg.com; Fri, 01 Apr 2005 15:34:51 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DHOAc-0003S8-GU for namedroppers@ops.ietf.org; Fri, 01 Apr 2005 15:34:50 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j31FXe06017588; Fri, 1 Apr 2005 10:33:41 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <424D3477.6090704@algroup.co.uk> References: <424D1E0A.7090504@algroup.co.uk> <424D3477.6090704@algroup.co.uk> Date: Fri, 1 Apr 2005 10:33:47 -0500 To: Ben Laurie From: Edward Lewis Subject: Re: Two more NSEC++ proposals Cc: Edward Lewis , Samuel Weiler , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 12:45 +0100 4/1/05, Ben Laurie wrote: >I don't think the root cares about enumeration :-) A zone is a zone is a zone. DNS is one protocol. We can't survive dialects. >Cache's are already supposed to store negative responses against the query >triple, so I don't see why this is an issue? RFC 2181. RRSets, RRSets, RRSets. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 1 10:42:26 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05941 for ; Fri, 1 Apr 2005 10:42:26 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DHOFZ-0004Db-5z for namedroppers-data@psg.com; Fri, 01 Apr 2005 15:39:57 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DHOFP-0004C0-3U for namedroppers@ops.ietf.org; Fri, 01 Apr 2005 15:39:47 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 2511833C6B; Fri, 1 Apr 2005 16:39:45 +0100 (BST) Message-ID: <424D6AC8.5090801@algroup.co.uk> Date: Fri, 01 Apr 2005 16:37:44 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Edward Lewis Cc: Samuel Weiler , namedroppers@ops.ietf.org Subject: Re: Two more NSEC++ proposals References: <424D1E0A.7090504@algroup.co.uk> <424D3477.6090704@algroup.co.uk> In-Reply-To: X-Enigmail-Version: 0.89.6.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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward Lewis wrote: > At 12:45 +0100 4/1/05, Ben Laurie wrote: > >> I don't think the root cares about enumeration :-) > > > A zone is a zone is a zone. DNS is one protocol. We can't survive > dialects. Hmmm. RFC 2782? >> Cache's are already supposed to store negative responses against the >> query >> triple, so I don't see why this is an issue? > > RFC 2181. RRSets, RRSets, RRSets. 5.3. DNSSEC Special Cases Two of the record types added by DNS Security (DNSSEC) [RFC2065] require special attention when considering the formation of Resource Record Sets. Those are the SIG and NXT records. It should be noted that DNS Security is still very new, and there is, as yet, little experience with it. Readers should be prepared for the information related to DNSSEC contained in this document to become outdated as the DNS Security specification matures. -- 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: From owner-namedroppers@ops.ietf.org Fri Apr 1 11:06:08 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08422 for ; Fri, 1 Apr 2005 11:06:08 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DHOcc-0007rK-5y for namedroppers-data@psg.com; Fri, 01 Apr 2005 16:03:46 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DHOca-0007qz-UC for namedroppers@ops.ietf.org; Fri, 01 Apr 2005 16:03:45 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j31G2YE7017709; Fri, 1 Apr 2005 11:02:35 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <424D6AC8.5090801@algroup.co.uk> References: <424D1E0A.7090504@algroup.co.uk> <424D3477.6090704@algroup.co.uk> <424D6AC8.5090801@algroup.co.uk> Date: Fri, 1 Apr 2005 11:02:42 -0500 To: Ben Laurie From: Edward Lewis Subject: Re: Two more NSEC++ proposals Cc: Edward Lewis , Samuel Weiler , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 16:37 +0100 4/1/05, Ben Laurie wrote: >Edward Lewis wrote: >> At 12:45 +0100 4/1/05, Ben Laurie wrote: >> >>> I don't think the root cares about enumeration :-) >> >> A zone is a zone is a zone. DNS is one protocol. We can't >>survive dialects. > >Hmmm. RFC 2782? What about it? (If you are referring to "Name" vs. the owner name, see the comments in the current version of the wcard draft.) >>> Cache's are already supposed to store negative responses against the query >>> triple, so I don't see why this is an issue? >> RFC 2181. RRSets, RRSets, RRSets. > >5.3. DNSSEC Special Cases > > Two of the record types added by DNS Security (DNSSEC) [RFC2065] > require special attention when considering the formation of Resource > Record Sets. Those are the SIG and NXT records. It should be noted > that DNS Security is still very new, and there is, as yet, little > experience with it. Readers should be prepared for the information > related to DNSSEC contained in this document to become outdated as > the DNS Security specification matures. The point is that in 2181 we finally realized the sanctity of the RRSet and formalized it. A fundamental principle is that no matter where you ask the global DNS for (QNAME, QTYPE, QCLASS) you should get the same RRSet in response. Of course, given things like the finite speed of light, there will be times where propagation delays cause schisms. That's life when you deal with loosely coupled systems. (There's a lot to understand about the tradeoffs of loosely coupled and tightly couple system design. 10-15 years ago we had a lot of tightly coupled distributed applications products that have migrated to using loosely coupled underlayers, including DNS - which is why you see 2782, 3401-4, etc. This is too large a topic to cover here.) Telling the authoritative servers to answer differently *at the source* for an RRSet - granted one not asked for in this case, but one expected in a name error response - is not even giving the basic principle of coherency a chance. You see Vixie's reply to changing the search algorithm. Don't go lightly into suggesting changes there, even if the wcard is proposing a change to CNAME at *. Yeah, there's a subjective line between what's okay to diddle with and what's not. Because it's subjective, it's difficult to relay what the criteria are. 2181 is right to be afraid of DNSSEC. There were two DNSSEC's after that. But even DNSSEC has to stay within the bounds of the spirit of DNS lest DNSSEC kill DNS off. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 1 17:41:20 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28924 for ; Fri, 1 Apr 2005 17:41:20 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DHUjo-000D4a-1j for namedroppers-data@psg.com; Fri, 01 Apr 2005 22:35:36 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DHUjl-000D4F-FJ for namedroppers@ops.ietf.org; Fri, 01 Apr 2005 22:35:34 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 2BA3133C6B; Fri, 1 Apr 2005 23:35:31 +0100 (BST) Message-ID: <424DCC3A.9090203@algroup.co.uk> Date: Fri, 01 Apr 2005 23:33:30 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Edward Lewis Cc: Samuel Weiler , namedroppers@ops.ietf.org Subject: Re: Two more NSEC++ proposals References: <424D1E0A.7090504@algroup.co.uk> <424D3477.6090704@algroup.co.uk> <424D6AC8.5090801@algroup.co.uk> In-Reply-To: X-Enigmail-Version: 0.89.6.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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward Lewis wrote: > At 16:37 +0100 4/1/05, Ben Laurie wrote: > >> Edward Lewis wrote: >> >>> At 12:45 +0100 4/1/05, Ben Laurie wrote: >>> >>>> I don't think the root cares about enumeration :-) >>> >>> >>> A zone is a zone is a zone. DNS is one protocol. We can't survive >>> dialects. >> >> >> Hmmm. RFC 2782? > > > What about it? (If you are referring to "Name" vs. the owner name, see > the comments in the current version of the wcard draft.) It creates new TLDs, that's what about it. We seem to have survived the experience. >>>> Cache's are already supposed to store negative responses against >>>> the query >>>> triple, so I don't see why this is an issue? >>> >>> RFC 2181. RRSets, RRSets, RRSets. >> >> >> 5.3. DNSSEC Special Cases >> >> Two of the record types added by DNS Security (DNSSEC) [RFC2065] >> require special attention when considering the formation of Resource >> Record Sets. Those are the SIG and NXT records. It should be noted >> that DNS Security is still very new, and there is, as yet, little >> experience with it. Readers should be prepared for the information >> related to DNSSEC contained in this document to become outdated as >> the DNS Security specification matures. > > > The point is that in 2181 we finally realized the sanctity of the RRSet > and formalized it. A fundamental principle is that no matter where you > ask the global DNS for (QNAME, QTYPE, QCLASS) you should get the same > RRSet in response. Of course, given things like the finite speed of > light, there will be times where propagation delays cause schisms. > That's life when you deal with loosely coupled systems. (There's a lot > to understand about the tradeoffs of loosely coupled and tightly couple > system design. 10-15 years ago we had a lot of tightly coupled > distributed applications products that have migrated to using loosely > coupled underlayers, including DNS - which is why you see 2782, 3401-4, > etc. This is too large a topic to cover here.) > > Telling the authoritative servers to answer differently *at the source* > for an RRSet - granted one not asked for in this case, but one expected > in a name error response - is not even giving the basic principle of > coherency a chance. > > You see Vixie's reply to changing the search algorithm. Don't go > lightly into suggesting changes there, even if the wcard is proposing a > change to CNAME at *. Yeah, there's a subjective line between what's > okay to diddle with and what's not. Because it's subjective, it's > difficult to relay what the criteria are. > > 2181 is right to be afraid of DNSSEC. There were two DNSSEC's after > that. But even DNSSEC has to stay within the bounds of the spirit of > DNS lest DNSSEC kill DNS off. The proposal does not cause you to get different RRSets depending on where you make the query. I'm totally missing what your problem is here. -- 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: From owner-namedroppers@ops.ietf.org Sun Apr 3 09:24:31 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23007 for ; Sun, 3 Apr 2005 09:24:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DI50F-0008qd-Tm for namedroppers-data@psg.com; Sun, 03 Apr 2005 13:18:59 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DI50E-0008pz-R5 for namedroppers@ops.ietf.org; Sun, 03 Apr 2005 13:18:59 +0000 Received: from [200.47.114.131] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j33DIiVj026235; Sun, 3 Apr 2005 09:18:49 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <424DCC3A.9090203@algroup.co.uk> References: <424D1E0A.7090504@algroup.co.uk> <424D3477.6090704@algroup.co.uk> <424D6AC8.5090801@algroup.co.uk> <424DCC3A.9090203@algroup.co.uk> Date: Sun, 3 Apr 2005 10:18:42 -0300 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: Two more NSEC++ proposals Cc: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 23:33 +0100 4/1/05, Ben Laurie wrote: >It creates new TLDs, that's what about it. We seem to have survived >the experience. No, we haven't. In the past a similar proposal was floated (for separating the hashes from the zone contents). The outcome was that we decided that the data in the tree, or the "shape of the tree" should be constrained by the protocol definition. I haven't found any pointers to this discussion, so I'll add the following two items: There is document being floated by the IAB (draft-iab-dns-choices-00.txt, expiring on April 11), in particular a section 3.2 called "Add a prefix to the owner name." There is a policy bound body whose job it is to decide the shape of the DNS tree, it is ICANN. If you get a taste of ICANN you will see the difference between protocol engineering and data policy. >The proposal does not cause you to get different RRSets depending on where >you make the query. I'm totally missing what your problem is here. It seems to me it does. I ask for foo.example and get back "example. NoNames A B" and then I ask for bar.example and get "example. NoNames C D". Which is it? Which RRSet is the one? IMHO, messing with the search algorithm is going to burn us. It's not just the problem at the authoritative servers, but at the caches and anyother element that is concerned with persistence of DNS data. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Apr 3 10:12:11 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27528 for ; Sun, 3 Apr 2005 10:12:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DI5nG-000Fg0-1a for namedroppers-data@psg.com; Sun, 03 Apr 2005 14:09:38 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DI5nC-000Ffb-T8 for namedroppers@ops.ietf.org; Sun, 03 Apr 2005 14:09:35 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 64EC833C45; Sun, 3 Apr 2005 15:09:33 +0100 (BST) Message-ID: <424FF8A5.40709@algroup.co.uk> Date: Sun, 03 Apr 2005 15:07:33 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: Two more NSEC++ proposals References: <424D1E0A.7090504@algroup.co.uk> <424D3477.6090704@algroup.co.uk> <424D6AC8.5090801@algroup.co.uk> <424DCC3A.9090203@algroup.co.uk> In-Reply-To: X-Enigmail-Version: 0.89.6.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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward Lewis wrote: > At 23:33 +0100 4/1/05, Ben Laurie wrote: > >> It creates new TLDs, that's what about it. We seem to have survived >> the experience. > > No, we haven't. We haven't? So are you saying RFC 2782 should be abolished? > In the past a similar proposal was floated (for separating the hashes > from the zone contents). The outcome was that we decided that the data > in the tree, or the "shape of the tree" should be constrained by the > protocol definition. I haven't found any pointers to this discussion, > so I'll add the following two items: > > There is document being floate draft-iab-dns-choices-00.txt, expiring on April 11), in particular a > section 3.2 called "Add a prefix to the owner name." We're obviously in red herring city here. What does this have to do with the discussion? > There is a policy bound body whose job it is to decide the shape of the > DNS tree, it is ICANN. If you get a taste of ICANN you will see the > difference between protocol engineering and data policy. Hah. If you want me to swallow this FUD, you're going to have to dig up some evidence. >> The proposal does not cause you to get different RRSets depending on >> where >> you make the query. I'm totally missing what your problem is here. > > > It seems to me it does. I ask for foo.example and get back "example. > NoNames A B" and then I ask for bar.example and get "example. NoNames C > D". Which is it? Which RRSet is the one? These are different queries. The principle you were worried about was this: "A fundamental principle is that no matter where you ask the global DNS for (QNAME, QTYPE, QCLASS) you should get the same RRSet in response." It does not seem to me that this principle is violated. > IMHO, messing with the search algorithm is going to burn us. It's not > just the problem at the authoritative servers, but at the caches and > anyother element that is concerned with persistence of DNS data. As already discussed, we already require caches to only serve cached negative responses in response to identical queries. NSEC++ does not change this. Cheers, Ben. -- 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: From owner-namedroppers@ops.ietf.org Sun Apr 3 11:31:55 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03226 for ; Sun, 3 Apr 2005 11:31:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DI70V-000OFd-HF for namedroppers-data@psg.com; Sun, 03 Apr 2005 15:27:23 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DI70U-000OFM-0g for namedroppers@ops.ietf.org; Sun, 03 Apr 2005 15:27:22 +0000 Received: from [200.47.114.131] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j33FQ0rn026563; Sun, 3 Apr 2005 11:26:04 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <424FF8A5.40709@algroup.co.uk> References: <424D1E0A.7090504@algroup.co.uk> <424D3477.6090704@algroup.co.uk> <424D6AC8.5090801@algroup.co.uk> <424DCC3A.9090203@algroup.co.uk> <424FF8A5.40709@algroup.co.uk> Date: Sun, 3 Apr 2005 12:25:57 -0300 To: Ben Laurie From: Edward Lewis Subject: Re: Two more NSEC++ proposals Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 15:07 +0100 4/3/05, Ben Laurie wrote: >Edward Lewis wrote: >> At 23:33 +0100 4/1/05, Ben Laurie wrote: >> >>> It creates new TLDs, that's what about it. We seem to have survived >>> the experience. >> No, we haven't. > >We haven't? So are you saying RFC 2782 should be abolished? Please read the wcard draft and see the text it currently has. I don't know what else you may be referring to. I.e., RFC 2782 doesn't propose using prefixes as a way to solve DNS problems. It proposes them as a way to solve an application's problems. That's the comment about the RFC mixing specification and use case. >> There is document being floate draft-iab-dns-choices-00.txt, expiring >>on April 11), in particular a section 3.2 called "Add a prefix to the owner >>name." > >We're obviously in red herring city here. What does this have to do with >the discussion? Red herring? This document is germane as the first proposal is to separate all of the hashes by "creat[ing] a delegation within the zone to keep these names in one place." That sounds like what the draft, section 3.2 is arguing against - shaping the tree for a particular purpose. BTW, you can't "delegate within a zone". I assume the intention is to "create a subdomain within the zone". >> There is a policy bound body whose job it is to decide the shape of the DNS >>tree, it is ICANN. If you get a taste of ICANN you will see the difference >>between protocol engineering and data policy. > >Hah. If you want me to swallow this FUD, you're going to have to dig up >some evidence. E.g., the recommendation issued this week by the US National Academy of Sciences on the DNS and Internet Navigation. From a presentation I attended last week, the recommendation was to limit the addition of new entries in the root because of all of the manual review of the zone. E.g., the amount of diligent review studying the deployment of DNSSEC in the root zone. Discussions toward this end have taken years. Does this clear up any uncertainty of the scale of the problem? Well the problem of doing this for the root? >>> The proposal does not cause you to get different RRSets depending on where >>> you make the query. I'm totally missing what your problem is here. >> >> It seems to me it does. I ask for foo.example and get back "example. >>No Names A B" and then I ask for bar.example and get "example. NoNames C D". >>Which is it? Which RRSet is the one? > >These are different queries. The principle you were worried about was this: > >"A fundamental principle is that no matter where you ask the global DNS for >(QNAME, QTYPE, QCLASS) you should get the same RRSet in response." > >It does not seem to me that this principle is violated. True, but think of it from the side of the recipient of the data. When I am presented with different values for the same owner name, type, and class, I'm not going to hold both. >As already discussed, we already require caches to only serve cached negative >responses in response to identical queries. NSEC++ does not change this. I'm not sure of this...you are still proposing to pass inconsistent data through the DNS. Remember that what's in a protocol message is the issue (or an issue), not how implementations store the data. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Apr 3 12:31:00 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06578 for ; Sun, 3 Apr 2005 12:31:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DI7wZ-0005w5-Ad for namedroppers-data@psg.com; Sun, 03 Apr 2005 16:27:23 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DI7wX-0005vT-8g for namedroppers@ops.ietf.org; Sun, 03 Apr 2005 16:27:21 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 9316933C33; Sun, 3 Apr 2005 17:27:14 +0100 (BST) Message-ID: <425018EA.1060401@algroup.co.uk> Date: Sun, 03 Apr 2005 17:25:14 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: Two more NSEC++ proposals References: <424D1E0A.7090504@algroup.co.uk> <424D3477.6090704@algroup.co.uk> <424D6AC8.5090801@algroup.co.uk> <424DCC3A.9090203@algroup.co.uk> <424FF8A5.40709@algroup.co.uk> In-Reply-To: X-Enigmail-Version: 0.89.6.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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward Lewis wrote: > I'm not sure of this...you are still proposing to pass inconsistent data > through the DNS. _I'm_ not proposing anything! I'm discussing someone else's proposals. Cheers, Ben. -- 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: From owner-namedroppers@ops.ietf.org Mon Apr 4 08:23:44 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25317 for ; Mon, 4 Apr 2005 08:23:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DIQXR-0005QY-Cy for namedroppers-data@psg.com; Mon, 04 Apr 2005 12:18:41 +0000 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.44 (FreeBSD)) id 1DIQXP-0005QA-UO for namedroppers@ops.ietf.org; Mon, 04 Apr 2005 12:18:40 +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/2005/03/01/sjaenick) with ESMTP id j34CIbDs005885 for ; Mon, 4 Apr 2005 14:18:37 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id j34CIaJ16076 for ; Mon, 4 Apr 2005 14:18:37 +0200 (MEST) Message-Id: <200504041218.j34CIaJ16076@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: Use same server after truncated response? X-PGP-Fingerprint: 85 89 64 AD 73 79 92 1F C8 76 95 2D 15 09 19 93 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: <16071.1112617116.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Mon, 04 Apr 2005 14:18:36 +0200 From: Peter Koch X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Our nameserver was hit by a noticeable number of TCP queries due to an IN-ADDR.ARPA zone containing an entry with lots of PTR RRs. However, the truncated responses were not sent by our server (the delegation happened to be lame), so why did we see the TCP queries at all (the other delegees were authoritatively responsive over both UDP and TCP)? RFC 2181 says: Where TC is set, the partial RRSet that would not completely fit may be left in the response. When a DNS client receives a reply with TC set, it should ignore that response, and query again, using a mechanism, such as a TCP connection, that will permit larger replies. All misconfigurations involved in this particular case set aside, would it be safe to assume that a resolver should "retry" via TCP only the server that provided the TC response? -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Apr 4 09:17:09 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04065 for ; Mon, 4 Apr 2005 09:17:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DIRP0-000Cwb-B5 for namedroppers-data@psg.com; Mon, 04 Apr 2005 13:14:02 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DIROy-000CwC-NC for namedroppers@ops.ietf.org; Mon, 04 Apr 2005 13:14:00 +0000 Received: from deneb.enyo.de ([212.9.189.171]) by albireo.enyo.de with esmtp id 1DIROv-0001Bv-O2; Mon, 04 Apr 2005 15:13:57 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.50) id 1DIROv-0002Rg-1X; Mon, 04 Apr 2005 15:13:57 +0200 From: Florian Weimer To: Peter Koch Cc: namedroppers@ops.ietf.org Subject: Re: Use same server after truncated response? References: <200504041218.j34CIaJ16076@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Mon, 04 Apr 2005 15:13:57 +0200 In-Reply-To: <200504041218.j34CIaJ16076@grimsvotn.TechFak.Uni-Bielefeld.DE> (Peter Koch's message of "Mon, 04 Apr 2005 14:18:36 +0200") Message-ID: <877jji3cru.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk * Peter Koch: > All misconfigurations involved in this particular case set aside, would > it be safe to assume that a resolver should "retry" via TCP only the > server that provided the TC response? No, because only a subset of the authoritative servers might provide TCP service. This is not an uncommon (mis)configuration, AFAIK. It's also wrong to assume that TCP fallback only occurs due to truncated responses. A resolver might detect that is subject to a blind spoofing (or even a DoS) attack, and fallback to TCP to thwart it. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Apr 4 09:28:25 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04866 for ; Mon, 4 Apr 2005 09:28:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DIRZX-000E2Q-Uh for namedroppers-data@psg.com; Mon, 04 Apr 2005 13:24:55 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1DIRZW-000E2C-KX for namedroppers@ops.ietf.org; Mon, 04 Apr 2005 13:24:54 +0000 Received: (qmail 21706 invoked from network); 4 Apr 2005 14:16:05 -0000 Received: from yahoobb219178198104.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.104) by necom830.hpcl.titech.ac.jp with SMTP; 4 Apr 2005 14:16:05 -0000 Message-ID: <42514026.1070309@necom830.hpcl.titech.ac.jp> Date: Mon, 04 Apr 2005 22:24:54 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Peter Koch CC: namedroppers@ops.ietf.org Subject: Re: Use same server after truncated response? References: <200504041218.j34CIaJ16076@grimsvotn.TechFak.Uni-Bielefeld.DE> In-Reply-To: <200504041218.j34CIaJ16076@grimsvotn.TechFak.Uni-Bielefeld.DE> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Peter Koch wrote: > RFC 2181 says: > > Where TC is set, the partial RRSet that would not completely fit may > be left in the response. When a DNS client receives a reply with TC > set, it should ignore that response, and query again, using a > mechanism, such as a TCP connection, that will permit larger replies. > > All misconfigurations involved in this particular case set aside, would > it be safe to assume that a resolver should "retry" via TCP only the > server that provided the TC response? Interesting phenomena. Given that TC is set only if there is insufficient room to answer a required query, it is reasonable to use TCP for any other server. However, as a client considers the server originally returned TC best, there is no good reason to retry the server other than the original. So far, your assumption seems to be safe. Then, because of overloading, rate limiting on TCP query or something else on the original, the TCP retry can fail. Now, other servers should be tried. However, there is no reason to try UDP even though it is assured to be retried by TCP. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Apr 4 09:58:59 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09035 for ; Mon, 4 Apr 2005 09:58:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DIS46-000IEk-7c for namedroppers-data@psg.com; Mon, 04 Apr 2005 13:56:30 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DIS45-000IE4-7x for namedroppers@ops.ietf.org; Mon, 04 Apr 2005 13:56:29 +0000 Received: from [200.47.114.131] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j34Dt4SW003722; Mon, 4 Apr 2005 09:55:13 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <425018EA.1060401@algroup.co.uk> References: <424D1E0A.7090504@algroup.co.uk> <424D3477.6090704@algroup.co.uk> <424D6AC8.5090801@algroup.co.uk> <424DCC3A.9090203@algroup.co.uk> <424FF8A5.40709@algroup.co.uk> <425018EA.1060401@algroup.co.uk> Date: Mon, 4 Apr 2005 10:55:02 -0300 To: Ben Laurie From: Edward Lewis Subject: Re: Two more NSEC++ proposals Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 17:25 +0100 4/3/05, Ben Laurie wrote: >Edward Lewis wrote: >> I'm not sure of this...you are still proposing to pass inconsistent >>data through the DNS. > >_I'm_ not proposing anything! I'm discussing someone else's proposals. The royal "you." ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance is bliss. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Apr 4 11:56:11 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21079 for ; Mon, 4 Apr 2005 11:56:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DITrj-0006Qf-45 for namedroppers-data@psg.com; Mon, 04 Apr 2005 15:51:51 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DITri-0006QS-DL for namedroppers@ops.ietf.org; Mon, 04 Apr 2005 15:51:50 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 0E52813971 for ; Mon, 4 Apr 2005 15:51:50 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Use same server after truncated response? In-Reply-To: Message from Florian Weimer of "Mon, 04 Apr 2005 15:13:57 +0200." <877jji3cru.fsf@deneb.enyo.de> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 04 Apr 2005 15:51:50 +0000 Message-Id: <20050404155150.0E52813971@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > It's also wrong to assume that TCP fallback only occurs due to > truncated responses. A resolver might detect that is subject to a > blind spoofing (or even a DoS) attack, and fallback to TCP to thwart > it. in particular, i've been on hotel wireless nets that captured, rewrote, and otherwise spoofed udp/53, but which were fully transparent to tcp/53, and i've occasionally therefore configured my resolver to "always use tcp". -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Apr 4 20:02:52 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27696 for ; Mon, 4 Apr 2005 20:02:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DIbSm-000FsC-Hn for namedroppers-data@psg.com; Mon, 04 Apr 2005 23:58:36 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1DIbSl-000Frt-Fq for namedroppers@ops.ietf.org; Mon, 04 Apr 2005 23:58:35 +0000 Received: (qmail 39985 invoked by uid 1016); 4 Apr 2005 23:58:56 -0000 Date: 4 Apr 2005 23:58:56 -0000 Message-ID: <20050404235856.39984.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: Use same server after truncated response? References: <200504041218.j34CIaJ16076@grimsvotn.TechFak.Uni-Bielefeld.DE> <42514026.1070309@necom830.hpcl.titech.ac.jp> <200504041218.j34CIaJ16076@grimsvotn.TechFak.Uni-Bielefeld.DE> <877jji3cru.fsf@deneb.enyo.de> <200504041218.j34CIaJ16076@grimsvotn.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Peter Koch writes: > All misconfigurations involved in this particular case set aside, would > it be safe to assume that a resolver should "retry" via TCP only the > server that provided the TC response? No. Stop and think about your assumption for a moment: what happens if the TCP query fails? Failing to try another server would be a serious reliability mistake. Trying another server by UDP first would be silly. Florian Weimer writes: > It's also wrong to assume that TCP fallback only occurs due to > truncated responses. No, it isn't wrong. RFC 1123, section 6.1.2.3, specifically requires all clients and caches to start with UDP. TCP is allowed if a UDP response says TC, and TCP is allowed by ``private agreement,'' but starting with TCP to an unknown server is a protocol violation. You lose access to an increasingly large portion of the DNS tree if you screw this up. Masataka Ohta writes: > a client considers the server originally returned TC best Some clients work that way. Others don't. (The ``best server'' approach does a poor job of balancing loads, although this particular aspect of the approach is relatively harmless.) ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Apr 4 20:56:54 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01379 for ; Mon, 4 Apr 2005 20:56:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DIcJX-000M0Y-0o for namedroppers-data@psg.com; Tue, 05 Apr 2005 00:53:07 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DIcJV-000Lzu-Gl for namedroppers@ops.ietf.org; Tue, 05 Apr 2005 00:53:05 +0000 Received: from deneb.enyo.de ([212.9.189.171]) by albireo.enyo.de with esmtp id 1DIcJS-0000US-WE for namedroppers@ops.ietf.org; Tue, 05 Apr 2005 02:53:03 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.50) id 1DIcJQ-0005IY-Ft for namedroppers@ops.ietf.org; Tue, 05 Apr 2005 02:53:00 +0200 From: Florian Weimer To: namedroppers@ops.ietf.org Subject: Re: Use same server after truncated response? References: <200504041218.j34CIaJ16076@grimsvotn.TechFak.Uni-Bielefeld.DE> <42514026.1070309@necom830.hpcl.titech.ac.jp> <200504041218.j34CIaJ16076@grimsvotn.TechFak.Uni-Bielefeld.DE> <877jji3cru.fsf@deneb.enyo.de> <200504041218.j34CIaJ16076@grimsvotn.TechFak.Uni-Bielefeld.DE> <20050404235856.39984.qmail@cr.yp.to> Date: Tue, 05 Apr 2005 02:53:00 +0200 In-Reply-To: <20050404235856.39984.qmail@cr.yp.to> (D. J. Bernstein's message of "4 Apr 2005 23:58:56 -0000") Message-ID: <87sm26oxhv.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk * D. J. Bernstein: > No, it isn't wrong. RFC 1123, section 6.1.2.3, specifically requires all > clients and caches to start with UDP. The next paragraph (in section 6.1.3.2) implies that servers SHOULD reply to TCP-only queries nevertheless, so I don't see a problem. (BIND follows the SHOULD, or SHOULD NOT in the wording of the RFC.) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 5 00:38:20 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15815 for ; Tue, 5 Apr 2005 00:38:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DIfWf-000KeX-60 for namedroppers-data@psg.com; Tue, 05 Apr 2005 04:18:53 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1DIfWe-000KeJ-2y for namedroppers@ops.ietf.org; Tue, 05 Apr 2005 04:18:52 +0000 Received: (qmail 2591 invoked by uid 1016); 5 Apr 2005 04:19:14 -0000 Date: 5 Apr 2005 04:19:13 -0000 Message-ID: <20050405041913.2590.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: Use same server after truncated response? References: <200504041218.j34CIaJ16076@grimsvotn.TechFak.Uni-Bielefeld.DE> <42514026.1070309@necom830.hpcl.titech.ac.jp> <200504041218.j34CIaJ16076@grimsvotn.TechFak.Uni-Bielefeld.DE> <877jji3cru.fsf@deneb.enyo.de> <200504041218.j34CIaJ16076@grimsvotn.TechFak.Uni-Bielefeld.DE> <20050404235856.39984.qmail@cr.yp.to> <87sm26oxhv.fsf@deneb.enyo.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Florian Weimer writes: > servers SHOULD reply to TCP-only queries The spec recommends that servers respond to TCP. Some servers have local data that requires TCP; other servers don't. Some DNS administrators turn on TCP; some don't. (Even at BIND sites, TCP can be firewalled.) Meanwhile, except when there's a ``private agreement'' with the server, the spec REQUIRES that clients and caches start with UDP. Starting with TCP means violating the protocol. This protocol violation would produce frequent interoperability failures if anyone were dumb enough to do it. > so I don't see a problem The problem is that you're advocating interoperability failures. New DNS implementors might not have the experience necessary to realize that your advice is bogus. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 5 04:59:25 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25218 for ; Tue, 5 Apr 2005 04:59:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DIjqI-0003Dp-7q for namedroppers-data@psg.com; Tue, 05 Apr 2005 08:55:26 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DIjqH-0003DW-8w for namedroppers@ops.ietf.org; Tue, 05 Apr 2005 08:55:25 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 89E752699C; Tue, 5 Apr 2005 10:55:24 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id B68A22692F for ; Tue, 5 Apr 2005 10:55:23 +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 j358tNet015370 for ; Tue, 5 Apr 2005 10:55:23 +0200 Date: Tue, 5 Apr 2005 10:55:23 +0200 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: Alea iacta est Message-Id: <20050405105523.5316ad29.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 1.0.3 (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-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.000000 / -5.9 X-RIPE-Signature: b23c8cce472563689d1369de531dd6bb X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear colleagues, RFC 4033, 4034 and 4035, specifying the DNSSEC bis protocol have been published and announced. The publication of these RFCs have been a major milestone for this group and we are happy to see that we have been able to produce a high quality document set. DNSSEC remains a work item for this group. But it has a very solid, and deployable, foundation. That it took 10 years to develop is regrettable but we feel that the dnssec-bis editors team have given a good example on how editors can determine the pace of the work in a working group. In addition to the work by the editors it was the constructive and consensus seeking approach of the working group members, seen over the last years, that helped us produce a high quality document. Thanks for your efforts; We are proud to be a part of this development. Olaf and Olafur. DNSEXT Chairs. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 5 12:34:19 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06902 for ; Tue, 5 Apr 2005 12:34:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DIqtn-00048l-38 for namedroppers-data@psg.com; Tue, 05 Apr 2005 16:27:31 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DIqtl-00047v-AO for namedroppers@ops.ietf.org; Tue, 05 Apr 2005 16:27:29 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 7A5E413971 for ; Tue, 5 Apr 2005 16:27:28 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Alea iacta est In-Reply-To: Message from "Olaf M. Kolkman" of "Tue, 05 Apr 2005 10:55:23 +0200." <20050405105523.5316ad29.olaf@ripe.net> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Date: Tue, 05 Apr 2005 16:27:28 +0000 Message-Id: <20050405162728.7A5E413971@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --=-=-= > RFC 4033, 4034 and 4035, specifying the DNSSEC bis protocol have been > published and announced. The publication of these RFCs have been a > major milestone for this group and we are happy to see that we have > been able to produce a high quality document set. me too. and i want to thank the dnssec-editors group, with special attention to rob austein, for their efforts toward this milestone. however, i have some disagreements as to how history should be written: > DNSSEC remains a work item for this group. But it has a very solid, > and deployable, foundation. i don't think that's true. a number of TLDs have said that without opt-in and/or without protection against zonewalking, dnssec-bis is undeployable; these are "foundational" issues and the fixes for them could mean it'll take dnssec-ter (and another flag day) before this functionality will be globally deployed. > That it took 10 years to develop is regrettable it would be, even if it were only 10 years. but 11 years ago on this date, jim galvin (then WG chair of the dns-security working group) published meeting minutes from the seattle ietf meeting in march 1994. (see attached; it's fascinating reading for protocol history buffs.) > but we feel that the dnssec-bis editors team have given a good example > on how editors can determine the pace of the work in a working group. if by that damningly faint praise you mean that setting up an editors subgroup to try to make more rapid and focused progress didn't work out like randy and olafur hoped, and that individual authors and design teams have not been discredited as the right/best way to make stuff like this happen, and that the need for DNS-MODA is more urgent now than ever, i agree. if you mean pretty much anything else, then i don't understand. > In addition to the work by the editors it was the constructive and > consensus seeking approach of the working group members, seen over the > last years, that helped us produce a high quality document. given that we would have had opt-in, and therefore a high likelihood of a known deployment horizon in certain huge TLD's, if not for the destructive and unilateral actions and words of a few working group members, we're really hanging on the "last years" qualifier here, right? > Thanks for your efforts; We are proud to be a part of this development. > > Olaf and Olafur. > DNSEXT Chairs. me too, in spite of everything. but i'm reminded of a well known quote: "Laws are like sausages. It's better not to see them being made." Otto Von Bismarck 1815 - 1898. oh and here's the 11-year-old WG summary i promised: --=-=-= Content-Type: message/rfc822 Content-Disposition: attachment; filename=76 Received: from sol.tis.com by magellan.TIS.COM id aa05108; 5 Apr 94 13:40 EDT Received: from magellan.tis.com by tis.com (4.1/SUN-5.64) id AA29889; Tue, 5 Apr 94 13:40:02 EDT Message-Id: <9404051740.AA29889@tis.com> Reply-To: James M Galvin To: dns-security@tis.com Subject: DRAFT Minutes of DNS Security March 1994 (Seattle) Meeting Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-Id: <5096.765567591.0@tis.com> Date: Tue, 05 Apr 1994 13:40:10 -0400 From: James M Galvin ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5096.765567591.1@tis.com> Enclosed below is my record of the meeting held during the last IETF meeting. Corrections from those who attended the meeting are hereby solicited. In particular, there is one issue that I had regarded on the slides for which I can not remember either the context or the resolution. I'd appreciate if someone could remind me. I will submit the revised minutes for the record on Monday, April 11 (or these if I get no comments). Thanks, Jim ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5096.765567591.2@tis.com> Content-Description: Meeting Minutes DNS Security WG Meeting Minutes March 1994 Seattle Recorded by Jim Galvin, Chair The DNS Security Working Group met on Tuesday morning for a 2.5 hour meeting. Charlie Kaufman and Donald Eastlake had previously submitted a proposal (as an internet draft) for enhancing the DNS to support a digital signature security service. This meeting was dedicated to a review of that proposal. The meeting began with a review of the desired requirements identified at the BOF meeting held at the November 1993 Houston meeting. Charlie and Donald then led a presentation and discussion of their proposal. The following issues were discussed and resolved as indicated. o choice of algorithm The proposal currently specifies the SHA and RSA algorithms. It was agreed to replace SHA with MD5, the current Internet preference. o revisit DNS architecture The addition of SIG RRs increases the probability that the maximum UDP payload per packet may be exceeded. The requirement that we remain backward compatible with the existing installed base and the lack of empirical data to support the premise caused us to agree to leave the DNS architecture alone. o where do SIG RRs go in the reply A question was raised as to whether which section of the reply the SIG RRs should be placed. This is an issue because it was noted that, if necessary, implementations may ignore (and truncate) the additional records portion of a reply. It was agreed to query Paul Mockapetris in particular and to followup on the mailing list. o key per zone or key per server The proposal currently specifies that a public/private key pair is assigned to a zone, which is responsible for signing its data. In this way the data may be distributed by any server and, in fact, the actual signing of the data may (and should) occur as an off-line function. In addition, a specification is included for servers to optionally sign responses to queries. At this time it was agreed to leave the optional alternative in the document. We will revisit this issue after we have some implementation experience. o split the document It was suggested that the document may be better organized as several related documents. It was agreed Donald and/or Charlie would initiate a discussion of this issue on the mailing list. o use of the NTP time service The proposal currently emphasizes (if not requires) the use of a reliable time service, in particular NTP. It was agreed that DNS should not depend on synchronized clocks. The authors agreed to rework this aspect of the proposal to not depend on synchronized clocks. o partial and/or hash records (** HELP HERE **) I have this item recorded on the slides but I don't recall the issue or the resolution. Can someone provide some context, please? o key management It was observed that an integral part of the proposal is the specification of a key management protocol. As the new security area director was present at the meeting he was asked if the security area believed it was appropriate to specify another key management protocol, observing that both PEM and SNMP Security have also specified key management protocols. The response was that this key management protocol was sufficiently different from the other two that it was valuable in its own right and should remain part of the proposal. The meeting concluded with Jim Galvin noting that TIS would be implementing the proposal using the bind implementation of the DNS as a baseline. This software would be openly available to the Internet community. This group expects to meet in Toronto. ------- =_aaaaaaaaaa0-- --=-=-=-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Apr 7 10:39:36 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29174 for ; Thu, 7 Apr 2005 10:39:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJY3s-000DSk-Vr for namedroppers-data@psg.com; Thu, 07 Apr 2005 14:32:48 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DJY3Y-000DQg-9j for namedroppers@ops.ietf.org; Thu, 07 Apr 2005 14:32:28 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 84E1D2552C; Thu, 7 Apr 2005 16:31:29 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id EA00D2552B for ; Thu, 7 Apr 2005 16:31:27 +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 j37EVRet019558 for ; Thu, 7 Apr 2005 16:31:27 +0200 Received: (from olaf@localhost) by x50.ripe.net (8.12.10/8.12.6) id j37EVREh013707 for namedroppers@ops.ietf.org; Thu, 7 Apr 2005 16:31:27 +0200 Received: from [157.185.61.2] (helo=M4.sparta.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DJXju-000Atm-Gn for namedroppers@ops.ietf.org; Thu, 07 Apr 2005 14:12:10 +0000 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.1/8.13.1) with ESMTP id j37EC9hj015397 for ; Thu, 7 Apr 2005 09:12:09 -0500 Received: from columbia.sparta.com ([157.185.80.32]) by Beta5.sparta.com (8.12.11/8.12.11) with ESMTP id j37EC8sk018415 for ; Thu, 7 Apr 2005 09:12:09 -0500 Received: from [157.185.80.167] (abhijit.columbia.sparta.com [157.185.80.167]) by columbia.sparta.com (8.12.10+Sun/8.12.10) with ESMTP id j37EC86h004637 for ; Thu, 7 Apr 2005 10:12:08 -0400 (EDT) Message-ID: <42553F8B.3030908@sparta.com> Date: Thu, 07 Apr 2005 10:11:23 -0400 From: Abhijit Hayatnagarkar Organization: SPARTA, Inc. User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: RFC 4034 typographical error ? X-Enigmail-Version: 0.90.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RIPE-Spam-Tests: BAYES_00 X-RIPE-Spam-Status: N 0.000425 / -2.6 X-RIPE-Signature: a97bfdea1e8cfd41526dae442e0d76ca X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ 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. ] Appendix B.1 of RFC 4034 says: " For a DNSKEY RR with algorithm 1, the key tag is defined to be the most significant 16 bits of the least significant 24 bits in the public key modulus (in other words, the 4th to last and 3rd to last octets of the public key modulus). " Thus, if the last 4 octets of the public key modulus are 0x11223344, then this would mean that the keytag will have the value 0x2233. If so, should the part in parenthesis be changed to "(in other words, the 3rd to last and 2nd to last octets of the public key modulus) " ? Thanks, Abhijit Hayatngarkar Senior Engineer SPARTA, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Apr 7 11:18:55 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03881 for ; Thu, 7 Apr 2005 11:18:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJYjt-000J4g-9n for namedroppers-data@psg.com; Thu, 07 Apr 2005 15:16:13 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DJYjh-000J2F-0o for namedroppers@ops.ietf.org; Thu, 07 Apr 2005 15:16:05 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j37FCGF3026158 for ; Thu, 7 Apr 2005 11:12:16 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAj1aOfZ; Thu, 7 Apr 05 11:12:14 -0400 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j37FE5Q8021659; Thu, 7 Apr 2005 11:14:05 -0400 (EDT) Date: Thu, 7 Apr 2005 11:14:05 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@filbert To: Paul Vixie cc: namedroppers@ops.ietf.org Subject: Re: Alea iacta est In-Reply-To: <20050405162728.7A5E413971@sa.vix.com> Message-ID: References: <20050405162728.7A5E413971@sa.vix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 5 Apr 2005, Paul Vixie wrote: > > DNSSEC remains a work item for this group. But it has a very solid, > > and deployable, foundation. > > i don't think that's true. a number of TLDs have said that without > opt-in and/or without protection against zonewalking, dnssec-bis is > undeployable; these are "foundational" issues and the fixes for them > could mean it'll take dnssec-ter (and another flag day) before this > functionality will be globally deployed. The argument that "fixing" zone walking could require a flag day is at odds with this WG's informed decsion last summer that gentle transition mechanisms are likely to work. If you would like to suggest that the WG reconsider that decision, a deeper technical analysis would be helpful. http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00824.html http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01231.html On the other hand, I suppose you could have been using "globablly deployed" to mean "every DNS-capable device groks DNSSEC", in which case I agree that a flag day will be needed. That said, I don't think this WG has ever dreamed that DNSSEC (-bis, -ter, or otherwise) will be "globally deployed", in part because we've felt that having a flag day is unrealistic. DNSSECbis doesn't need one. The type code roll (RFC3755) helped sidestep any need for a flag day -- it just left 2535-aware code behind. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Apr 7 11:34:15 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05591 for ; Thu, 7 Apr 2005 11:34:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJYzG-000Kot-8g for namedroppers-data@psg.com; Thu, 07 Apr 2005 15:32:06 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DJYzF-000Koc-5E for namedroppers@ops.ietf.org; Thu, 07 Apr 2005 15:32:05 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id DBDA913971 for ; Thu, 7 Apr 2005 15:32:04 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Alea iacta est In-Reply-To: Message from Samuel Weiler of "Thu, 07 Apr 2005 11:14:05 -0400." X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 07 Apr 2005 15:32:04 +0000 Message-Id: <20050407153204.DBDA913971@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > ... could mean it'll take dnssec-ter (and another flag day) before ... > > The argument that "fixing" zone walking could require a flag day is at > odds with this WG's informed decsion last summer that gentle > transition mechanisms are likely to work. If you would like to > suggest that the WG reconsider that decision, a deeper technical > analysis would be helpful. i think the operative word in my text that you quoted is: "could". > http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00824.html > http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01231.html i don't see any larch proofs in either of those messages. if you have any kind of rigorous proof that a zonewalking fix exists and is implementable and will not have a flag day, you should share that, it'll save time. all we know at the moment is that informed objective experts in the subject matter agree that such a solution can be found. but since we're the same people who passed RFC 2065 and RFC 2535 up to the IESG, i don't trust us, and so, my choice of words, very careful in this case, was the word: "could." > On the other hand, I suppose you could have been using "globablly > deployed" to mean "every DNS-capable device groks DNSSEC", in which > case I agree that a flag day will be needed. That said, I don't think > this WG has ever dreamed that DNSSEC (-bis, -ter, or otherwise) will > be "globally deployed", in part because we've felt that having a flag > day is unrealistic. DNSSECbis doesn't need one. The type code roll > (RFC3755) helped sidestep any need for a flag day -- it just left > 2535-aware code behind. let me be clearer, then. dnssec-ter might not be backward compatible with dnssec-bis, thus invalidating all dnssec-bis deployment up to that date, which is not precisely a "flag day" since the dnssec-bis empire will not end on that day. but dnssec-ter may end up having to be a parallel infrastructure. note the operative word "might" which is equivilent in this case to my earlier use of the word "could". that having been said, my own course (and isc's course) will be as follows: 1. push bind9's dnssec-bis implementation toward completeness and usability and deployment. this includes making DLV happen, sadly. 2. work with anyone interested in resolving the zone walking problem, with as little insertion force as possible, preserving as much of the dnssec-bis code and protocol and installed base as possible. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From azelrnaeiilj@gamedev.net Thu Apr 7 14:07:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21269; Thu, 7 Apr 2005 14:07:50 -0400 (EDT) Date: Thu, 7 Apr 2005 14:07:50 -0400 (EDT) Received: from gen92-4-82-235-10-136.fbx.proxad.net ([82.235.10.136]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DJbYZ-0004wz-Lu; Thu, 07 Apr 2005 14:16:45 -0400 Received: from duopoly.gamedev.net ([208.254.3.160]) by lykes.free-hosting.lt (InterMail vK.4.04.00.00 976-723-645 license 135078mi97wl1tul7mq336b3b32z3f95) with ESMTP id <20035034726418.YETO827.lykes@duopoly.gamedev.net> for ; Thu, 07 Apr 2005 13:07:39 -0600 Received: from diaphragm (primacy.gamedev.net [209.157.71.50]) by duopoly.gamedev.net (Mirapoint Messaging Server MOS 3.3.8-GR) with SMTP id CAI01150; Thu, 07 Apr 2005 16:03:39 -0300 (IST) Date: Thu, 07 Apr 2005 13:07:39 -0600 From: Kellie Goss Subject: Online Pharmacy To: References: In-Reply-To: Message-ID: <241426768379.DGS10886@freeze.com>primacy.gamedev.net> Message-ID: <241426768379.DGS10886@freeze.com> MIME-version: 1.0 Content-Type: multipart/alternative; boundary="----_001_4274_36P90VY2.90HF9876" X-Mailer: CommuniGate Pro WebUser Interface v.4.1.6 X-Spam-Score: 3.4 (+++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a This is a multi-part message in MIME format. ------_001_4274_36P90VY2.90HF9876 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Hi, You can buy the most wanted medications from our site. we sell ViCODiN(179 $),VALiUM(169 $) and ViAGRA(199 $) at a very reasonable price. we ship worldwide and no prescription is needed. http://www.grx-meds.com/scripts/default.asp?idaff=110 Cheapest Online Pharmacy ------_001_4274_36P90VY2.90HF9876 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7Bit Hi,
You can buy the most wanted medications from our site.
we sell ViCODiN(179 $),VALiUM(169 $) and ViAGRA(199 $) at a very reasonable price.
we ship worldwide and no prescription is needed.
Cheapest Online Pharmacy ------_001_4274_36P90VY2.90HF9876-- From owner-namedroppers@ops.ietf.org Thu Apr 7 14:43:41 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25379 for ; Thu, 7 Apr 2005 14:43:41 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJbuy-000Ioj-3w for namedroppers-data@psg.com; Thu, 07 Apr 2005 18:39:52 +0000 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.44 (FreeBSD)) id 1DJbun-000ImK-1i for namedroppers@ops.ietf.org; Thu, 07 Apr 2005 18:39:41 +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/2005/03/01/sjaenick) with ESMTP id j37Idchk015447 for ; Thu, 7 Apr 2005 20:39:39 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id j37Idc122520 for ; Thu, 7 Apr 2005 20:39:38 +0200 (MEST) Message-Id: <200504071839.j37Idc122520@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: Use same server after truncated response? In-reply-to: Your message of "04 Apr 2005 23:58:56 -0000." <20050404235856.39984.qmail@cr.yp.to> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22514.1112899176.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Thu, 07 Apr 2005 20:39:38 +0200 From: Peter Koch X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "D. J. Bernstein" wrote: > No. Stop and think about your assumption for a moment: what happens if > the TCP query fails? Failing to try another server would be a serious > reliability mistake. Trying another server by UDP first would be silly. I agree that totally failing to try another server would be unwise, but here are two reasons for trying UDP first anyway: 1) The server might be delegated lame and that can be communicated cheaper in UDP 2) This particular server might not provide a truncated response, e.g. because it responds with a referral since it is not authoritative for that zone while the first server (giving TC/UDP) was authoritative for both the child and the parent. Admittedly it's arguable which strategy is more cost effective in the long run. In the particular case I mentioned it was a firewall at the resolver side that prevented the TCP queries from being established, so the resolver hit us with TCP (attempts) although it hat received the truncated packet from elsewhere. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Apr 10 23:08:51 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14561 for ; Sun, 10 Apr 2005 23:08:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DKpBY-000CEf-La for namedroppers-data@psg.com; Mon, 11 Apr 2005 03:02:00 +0000 Received: from [144.189.100.102] (helo=motgate4.mot.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DKpBS-000CDr-Fo for namedroppers@ops.ietf.org; Mon, 11 Apr 2005 03:01:58 +0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id j3B36u01004595 for ; Sun, 10 Apr 2005 20:06:56 -0700 (MST) Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id j3B33qKh027996 for ; Sun, 10 Apr 2005 22:03:53 -0500 (CDT) Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.72) id <1LP6WVKK>; Sun, 10 Apr 2005 23:01:49 -0400 Message-ID: <62173B970AE0A044AED8723C3BCF238105CD46A1@ma19exm01.e6.bcs.mot.com> From: Eastlake III Donald-LDE008 To: "'Abhijit Hayatnagarkar'" Cc: namedroppers@ops.ietf.org Subject: RE: RFC 4034 typographical error ? Date: Sun, 10 Apr 2005 23:01:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is indeed a typo. It should be the 3rd and 2nd to last octets. When I designed the key tag for RSA, I didn't want to use the bottom octet as the bottom bit is always on and their might be other patterns in the relative occurance of values in the bottom octet. So I decided to ignore the bottom octet and take the next two. Thanks, Donald -----Original Message----- From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Abhijit Hayatnagarkar Sent: Thursday, April 07, 2005 10:11 AM To: namedroppers@ops.ietf.org Subject: RFC 4034 typographical error ? [ 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. ] Appendix B.1 of RFC 4034 says: " For a DNSKEY RR with algorithm 1, the key tag is defined to be the most significant 16 bits of the least significant 24 bits in the public key modulus (in other words, the 4th to last and 3rd to last octets of the public key modulus). " Thus, if the last 4 octets of the public key modulus are 0x11223344, then this would mean that the keytag will have the value 0x2233. If so, should the part in parenthesis be changed to "(in other words, the 3rd to last and 2nd to last octets of the public key modulus) " ? Thanks, Abhijit Hayatngarkar Senior Engineer SPARTA, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Apr 11 15:44:03 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13599 for ; Mon, 11 Apr 2005 15:44:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DL4lC-000Bi7-Rq for namedroppers-data@psg.com; Mon, 11 Apr 2005 19:39:50 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DL4lA-000Bhq-Ou for namedroppers@ops.ietf.org; Mon, 11 Apr 2005 19:39:49 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13162; Mon, 11 Apr 2005 15:39:45 -0400 (EDT) Message-Id: <200504111939.PAA13162@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-tsig-sha-03.txt Date: Mon, 11 Apr 2005 15:39:45 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.1 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 : HMAC SHA TSIG Algorithm Identifiers Author(s) : D. Eastlake 3rd Filename : draft-ietf-dnsext-tsig-sha-03.txt Pages : 10 Date : 2005-4-11 Use of the TSIG DNS resource record requires specification of a cryptographic message authentication code. Currently identifiers have been specified only for the HMAC-MD5 and GSS TSIG algorithms. This document standardizes identifiers and implementation requirements for additional HMAC SHA TSIG algorithms and standardizes how to specify and handle the truncation of HMAC values. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tsig-sha-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-tsig-sha-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-tsig-sha-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: <2005-4-11161224.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-tsig-sha-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-tsig-sha-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-4-11161224.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 15 10:08:13 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02758 for ; Fri, 15 Apr 2005 10:08:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DMRP3-0006A4-Dg for namedroppers-data@psg.com; Fri, 15 Apr 2005 14:02:37 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DMRP2-00069h-8w for namedroppers@ops.ietf.org; Fri, 15 Apr 2005 14:02:36 +0000 Received: from [10.31.32.242] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j3FE2SEV051750; Fri, 15 Apr 2005 10:02:29 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Fri, 15 Apr 2005 10:02:31 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Wild Card DNAMEs Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Once again with the wild cards... From RFC 2672 which proposes changes to 1034/4.3.2/Step 3 like this... # c. If at some label, a match is impossible (i.e., the # corresponding label does not exist), look to see whether the # last label matched has a DNAME record. ... text on what to do for an exact DNAME application... # If there was no DNAME record, look to see if the "*" label # exists. The impact of "* DNAME" would only be felt in two ways. One is if the QNAME had a "*" in the middle of it, running across the * DNAME along the way. In this case, it's not a wild card (synthesis) situation. The other way is if the QTYPE is "DNAME" or "ANY" and the QNAME leads to a source of synthesis. Thinking of the latter I have to question the elided text from the quote above: # If a DNAME record exists at that point, copy that record into # the answer section. If substitution of its for its # in QNAME would overflow the legal size for a , set RCODE to YXDOMAIN [DNSUPD] and exit; otherwise # perform the substitution and continue. If the query was not # extended [EDNS0] with a Version indicating understanding of the # DNAME record, the server SHOULD synthesize a CNAME record as # described above and include it in the answer section. Go back # to step 1. What if the QTYPE was DNAME? Why continue? Why include the CNAME if it's the DNAME I want? Once again, I find so many holes with RFC 2672...how do you clarify it? (Yes, I know that DNAME's "work." But I am beginning to think that there are too many rough edges in the definition - what makes rough edges acceptable here but not in other applications?) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 15 12:02:22 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16621 for ; Fri, 15 Apr 2005 12:02:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DMTEK-000KWM-B3 for namedroppers-data@psg.com; Fri, 15 Apr 2005 15:59:40 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DMTEJ-000KVk-7y for namedroppers@ops.ietf.org; Fri, 15 Apr 2005 15:59:39 +0000 Received: from [10.31.32.242] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j3FFxVoe052153; Fri, 15 Apr 2005 11:59:32 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Fri, 15 Apr 2005 11:52:48 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Who hates the DNAME? Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk After trying over and over to "clarify" DNAMEs and wild cards, I have come to have a complete dislike for the DNAME. Not just the document but also the idea. For one, DNAME violates principles that have been voiced in opposition to things like NSEC3 and proposals to put application data in the DNS. In short, denying current proposals via criteria that the DNAME "breaks" is rather hypocritical. Worse, I take this to mean that perhaps the DNAME is a suspect extension. It is said that DNAME works. But it only works within certain bounds, i.e., not with wild cards. If that's the case, then other extensions ought to be allowed if they are used within their bounds. Specifically, I am troubled by the changes to the search algorithm in the DNAME RFC (RFC 2672). Not only is part 'c' of step 3 incompletely updated (it says nothing of what happens when the QTYPE is any or DNAME), but it also modifies the search in the cache. Specifically, the cache now takes on a role that is otherwise reserved for the authoritative data - a "search" having knowledge of the tree structure. (NSEC3 proposes changing the search algorithm, this has been cited as bad: http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00685.html) How many implementations have the DNAME processing in them - in the recursive server, doing step 4? I suppose BIND does, but do any others? (Has interoperability been achieved?) How widespread is the use of DNAME? There's an ISC report on how to do it, but is it common enough? If there is interoperability and widespread use, then the RFC ought to be amended for completeness. If not, I'd like to put forward the idea of obsoleting the record. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 15 12:32:35 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19382 for ; Fri, 15 Apr 2005 12:32:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DMThz-000Nt3-R6 for namedroppers-data@psg.com; Fri, 15 Apr 2005 16:30:19 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DMThx-000Nsp-QO for namedroppers@ops.ietf.org; Fri, 15 Apr 2005 16:30:17 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 831B213971 for ; Fri, 15 Apr 2005 16:30:17 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Who hates the DNAME? In-Reply-To: Message from Edward Lewis of "Fri, 15 Apr 2005 11:52:48 -0400." X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 15 Apr 2005 16:30:17 +0000 Message-Id: <20050415163017.831B213971@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > After trying over and over to "clarify" DNAMEs and wild cards, I have > come to have a complete dislike for the DNAME. Not just the document > but also the idea. it's a mindbender, no question. but the reason we didn't cast it aside when we killed bitstring labels is that it has a lot of good uses. > For one, DNAME violates principles that have been voiced in opposition > to things like NSEC3 and proposals to put application data in the DNS. which principles? and if these didn't exist at the time DNAME was approved (as evidenced by its approval!) then how is it that DNAME can violate them? > In short, denying current proposals via criteria that the DNAME > "breaks" is rather hypocritical. Worse, I take this to mean that > perhaps the DNAME is a suspect extension. well, that's you. i take this to mean that "dns is hard." > It is said that DNAME works. But it only works within certain bounds, > i.e., not with wild cards. If that's the case, then other extensions > ought to be allowed if they are used within their bounds. (rhetorical question about whether ed took his pills today omitted.) DNAME and wildcards work just fine. try it: dig \ 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.b.b.0.0.3.0.0.0.8.f.4.0.1.0.0.2.ip6.int \ aaaa see also . > Specifically, I am troubled by the changes to the search algorithm in the > DNAME RFC (RFC 2672). Not only is part 'c' of step 3 incompletely updated > (it says nothing of what happens when the QTYPE is any or DNAME), but it > also modifies the search in the cache. Specifically, the cache now takes on > a role that is otherwise reserved for the authoritative data - a "search" > having knowledge of the tree structure. this, at least, sounds problematic and in need of clarification/revision. > If there is interoperability and widespread use, then the RFC ought to be > amended for completeness. If not, I'd like to put forward the idea of > obsoleting the record. i think you can amend it in a way that makes NSEC3 easier, without killing it, simply because we all know that there's only one implementation (BIND9) and very modest utilization so far. far from removing DNAME, i think we need to work on nonterminal wildcards and per-rrtype wildcards. not all complexity is bad; sometimes if you add good kinds of complexity you prevent bad kinds of workarounds. the big problem with DNAME is that people who havn't read about it end up proposing things that aren't compatible with it and then they feel blindsided when the real problem is that they didn't do their research well enough. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 15 13:29:24 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24129 for ; Fri, 15 Apr 2005 13:29:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DMUZz-0004iA-4m for namedroppers-data@psg.com; Fri, 15 Apr 2005 17:26:07 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DMUZy-0004hv-BA for namedroppers@ops.ietf.org; Fri, 15 Apr 2005 17:26:06 +0000 Received: from [10.0.1.2] (c-24-6-153-109.hsd1.ca.comcast.net [24.6.153.109]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 4D79E568A4; Fri, 15 Apr 2005 10:26:05 -0700 (PDT) (envelope-from david.conrad@nominum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <00acfa48120bad6f711c5061faa7a401@nominum.com> Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org From: David Conrad Subject: Re: Who hates the DNAME? Date: Fri, 15 Apr 2005 10:26:03 -0700 To: Edward Lewis X-Mailer: Apple Mail (2.619.2) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Apr 15, 2005, at 8:52 AM, Edward Lewis wrote: > How many implementations have the DNAME processing in them - in the > recursive server, doing step 4? I suppose BIND does, but do any > others? Perhaps not surprisingly, Nominum CNS supports DNAME. > (Has interoperability been achieved?) I'm not aware of any formal interoperability tests, although I suspect a number of informal tests have been done. > If there is interoperability and widespread use, then the RFC ought to > be amended for completeness. If there is a need for amendment, yes. > If not, I'd like to put forward the idea of obsoleting the record. I would not want to do this, but that's just me. Rgds, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 15 14:15:22 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28069 for ; Fri, 15 Apr 2005 14:15:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DMVIg-000AkL-Mc for namedroppers-data@psg.com; Fri, 15 Apr 2005 18:12:18 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DMVIW-000Ain-Jw for namedroppers@ops.ietf.org; Fri, 15 Apr 2005 18:12:08 +0000 Received: from [10.31.32.242] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j3FIC055052667; Fri, 15 Apr 2005 14:12:01 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20050415163017.831B213971@sa.vix.com> References: <20050415163017.831B213971@sa.vix.com> Date: Fri, 15 Apr 2005 14:10:50 -0400 To: Paul Vixie From: Edward Lewis Subject: Re: Who hates the DNAME? Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 16:30 +0000 4/15/05, Paul Vixie wrote: >which principles? and if these didn't exist at the time DNAME was approved >(as evidenced by its approval!) then how is it that DNAME can violate them? Principles seem to change over time. Witness the gradual "un-definition" of "* NS". The principle I have in mind is seen in the message I referenced...changes to the lookup algorithm. Without DNAMEs, caches could still just use hash buckets to store data, with DNAMES the tree is needed. To me that seems a significant change. >see also . OTOH, someone from ISC was behind outlawing "* DNAME". I know that in some cases DNAME works. I am just questioning if it works in all cases. The doc is weak, and there is a call to make "* DNAME" illegal. That's why I'm questioning... >i think you can amend it in a way that makes NSEC3 easier, without killing >it, simply because we all know that there's only one implementation (BIND9) >and very modest utilization so far. There's no link of NSEC3 to DNAME per se. I raised NSEC3 because of the observation that it too mentioned changing the search algorithm - and that was cited as a problem. >the big problem with DNAME is that people who havn't read about it end up >proposing things that aren't compatible with it and then they feel blindsided >when the real problem is that they didn't do their research well enough. I think the big problem with DNAME is that when reading the doc, it's unclear what happens. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 15 14:15:23 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28087 for ; Fri, 15 Apr 2005 14:15:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DMVIe-000Ak5-Jr for namedroppers-data@psg.com; Fri, 15 Apr 2005 18:12:16 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DMVId-000Ajb-Iv for namedroppers@ops.ietf.org; Fri, 15 Apr 2005 18:12:15 +0000 Received: from [10.31.32.242] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j3FIC057052667; Fri, 15 Apr 2005 14:12:04 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <00acfa48120bad6f711c5061faa7a401@nominum.com> References: <00acfa48120bad6f711c5061faa7a401@nominum.com> Date: Fri, 15 Apr 2005 14:12:04 -0400 To: David Conrad From: Edward Lewis Subject: Re: Who hates the DNAME? Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 10:26 -0700 4/15/05, David Conrad wrote: >Perhaps not surprisingly, Nominum CNS supports DNAME. Until now, I hadn't heard of anyone else implementing it... >> If not, I'd like to put forward the idea of obsoleting the record. > >I would not want to do this, but that's just me. I'm still curious about how much use it is getting. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 15 14:27:03 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29013 for ; Fri, 15 Apr 2005 14:27:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DMVVL-000Cr9-0T for namedroppers-data@psg.com; Fri, 15 Apr 2005 18:25:23 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DMVVJ-000CqQ-Fx for namedroppers@ops.ietf.org; Fri, 15 Apr 2005 18:25:22 +0000 Received: from [10.31.32.242] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j3FIPCnn052749; Fri, 15 Apr 2005 14:25:13 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <16992.726.820996.693667@guava.araneus.fi> References: <16992.726.820996.693667@guava.araneus.fi> Date: Fri, 15 Apr 2005 14:25:16 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: Wild Card DNAMEs Cc: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,UPPERCASE_25_50 autolearn=no version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 21:07 +0300 4/15/05, Andreas Gustafsson wrote: >> The other way is if the QTYPE is "DNAME" or "ANY" and the QNAME leads >> to a source of synthesis. > >Could you please define the term "leads to", or give an example of a >query and some zone data illustrating this case? "Leads to" means - there is no exact match, and results in looking to the domain *. for a possible answer. For zone: example. 900 IN SOA ns1.example. edlewis.example. 1 1200 300 3600 900 example. 900 IN NS ns1.example. *.example. 900 IN DNAME sub.example. bus.example. 900 IN NS ns1.example. sub.example. 900 IN NS ns1.example. Three digs at a BIND 9.3.1 server (authoritative for the zones). ; <<>> DiG 9.3.1 <<>> @127.0.0.1 +norec www.letter.example. a ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31041 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.letter.example. IN A ;; AUTHORITY SECTION: example. 900 IN SOA ns1.example. ... ; <<>> DiG 9.3.1 <<>> @127.0.0.1 +norec www.letter.example. any ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41054 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.letter.example. IN ANY ;; ANSWER SECTION: www.letter.example. 900 IN DNAME sub.example. ;; AUTHORITY SECTION: example. 900 IN NS ns1.example. ; <<>> DiG 9.3.1 <<>> @127.0.0.1 +norec www.letter.example. dname ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4520 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.letter.example. IN DNAME ;; ANSWER SECTION: www.letter.example. 900 IN DNAME sub.example. ;; AUTHORITY SECTION: example. 900 IN NS ns1.example. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 15 14:33:33 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29432 for ; Fri, 15 Apr 2005 14:33:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DMVam-000DvP-Sz for namedroppers-data@psg.com; Fri, 15 Apr 2005 18:31:00 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DMVaj-000Dux-Oz for namedroppers@ops.ietf.org; Fri, 15 Apr 2005 18:30:57 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id CCCF3C2DA4; Fri, 15 Apr 2005 19:30:56 +0100 (BST) Date: Fri, 15 Apr 2005 19:30:47 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Edward Lewis , Paul Vixie Cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: Who hates the DNAME? Message-ID: <7B29C0B50720548A5DD2366A@[192.168.100.25]> In-Reply-To: References: <20050415163017.831B213971@sa.vix.com> X-Mailer: Mulberry/4.0.0a5 (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 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,BIZ_TLD autolearn=no version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 15 April 2005 14:10 -0400 Edward Lewis wrote: > I raised NSEC3 because of the observation that it too mentioned changing > the search algorithm - and that was cited as a problem. Strictly speaking, NSEC3 does NOT mention changing the search algorithm. It was me that pointed out an argument from before NSEC3 was proposed, that if the hash space and the "valid" native namespace overlapped, AND the search algorithm wasn't changed, THEN this would alter existing wildcard behaviour if a zone publisher changed from NSEC to NSEC3 in some corner cases (QNAME=a hashed name, QTYPE!=NSEC3, wildcard present). It has yet to be established this is a real world problem (not least because the publisher itself is aware of it so may just accept "heh, a consequence of signing with NSEC3 is I may generate a funny response for queries starting with two underscores" or whatever). What people did say was that solving this (potential non-) problem by changing the search algorithm was undesirable. I think your point is that there is a precedent with DNAME. But the above does not equate to NSEC3 requiring a change to the search algorithm! 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: From owner-namedroppers@ops.ietf.org Fri Apr 15 14:45:51 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00963 for ; Fri, 15 Apr 2005 14:45:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DMVnJ-000Fzz-5W for namedroppers-data@psg.com; Fri, 15 Apr 2005 18:43:57 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DMVnI-000Fzj-Bc for namedroppers@ops.ietf.org; Fri, 15 Apr 2005 18:43:56 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 180F513971 for ; Fri, 15 Apr 2005 18:43:56 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Who hates the DNAME? In-Reply-To: Message from Edward Lewis of "Fri, 15 Apr 2005 14:10:50 -0400." X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 15 Apr 2005 18:43:56 +0000 Message-Id: <20050415184356.180F513971@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > which principles? and if these didn't exist at the time DNAME was > > approved (as evidenced by its approval!) then how is it that DNAME > > can violate them? > > Principles seem to change over time. Witness the gradual > "un-definition" of "* NS". at the risk of kicking a dead war, that's a bad example since many of us felt that "* NS" was always implicitly-but-provably meaningless and that the only thing needed to "kill" it is an editorial clarification, not a protocol or principle change. > The principle I have in mind is seen in the message I > referenced... changes to the lookup algorithm. Without DNAMEs, caches > could still just use hash buckets to store data, with DNAMES the tree > is needed. To me that seems a significant change. it's a significant change to implementations of future enhancements, sure. but as approved, it required no change to any principle we then knowingly held. but i suspect that this definitional wordplay will not lead us to a better joint understanding so let's move on. > I know that in some cases DNAME works. I am just questioning if it works > in all cases. The doc is weak, and there is a call to make "* DNAME" > illegal. > > That's why I'm questioning... there have been calls to do all kinds of things. saying "i want a pony" will not, however, make one appear. (unless you're one of my daughters, it seems.) but to balance things out, i'm calling for "* DNAME" to remain legal, since i'm using it, and i find it useful, and since it's the first brick of the "nonterminal wildcard" proposal i've been considering a while. > There's no link of NSEC3 to DNAME per se. I raised NSEC3 because of > the observation that it too mentioned changing the search algorithm - > and that was cited as a problem. if dname changed the search algorythm in the same way and to the same extent and nothing bad has happened then we shouldn't stand in the way of changing it still further for NSEC3. however, i think the NSEC3 changes are different in their nature and extent than the DNAME changes. something to do with backward compatibility and split data horizons. let's revisit it and see if our new-found terminology and perspective sheds different light on it? > I think the big problem with DNAME is that when reading the doc, it's > unclear what happens. well, there's a call for editorial improvements to the doc, so that's out of the way. now let's focus on the issue at hand, which appears still to be zone walking? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 15 15:57:03 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14240 for ; Fri, 15 Apr 2005 15:57:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DMWtB-000OLq-7D for namedroppers-data@psg.com; Fri, 15 Apr 2005 19:54:05 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DMWtA-000OLU-5E for namedroppers@ops.ietf.org; Fri, 15 Apr 2005 19:54:04 +0000 Received: from [10.31.32.242] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j3FJrtVZ053886; Fri, 15 Apr 2005 15:53:55 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Fri, 15 Apr 2005 15:53:59 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: once more with the dname Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Before we get lost in the weeds... Arriving in Minneapolis I had this documented (in wcard -05): # 4.4 DNAME RRSet at a Wild Card Domain Name # # A DNAME RRset at a wild card domain name is effectively the same # as a CNAME at a wild card domain name. In Minneapolis I heard that, in no uncertain terms, that "* DNAME" was not like CNAME, further that it should be outlawed like "* NS". This was reported in the open meeting there (check the transcripts)... I can't justify outlawing "* DNAME" and in fact, every time I try to find a problem, I come back to "DNAME is like CNAME." To those who feel that "* DNAME" is a problem - can you please explain what I am missing? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: