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: From owner-namedroppers@ops.ietf.org Wed Apr 20 10:22:39 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13442 for ; Wed, 20 Apr 2005 10:22:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DOG0l-000B03-Jm for namedroppers-data@psg.com; Wed, 20 Apr 2005 14:17:03 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DOG0Z-000Ayw-UO for namedroppers@ops.ietf.org; Wed, 20 Apr 2005 14:16:52 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id C7A0C25E0F; Wed, 20 Apr 2005 16:16:00 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id DB3F025E09 for ; Wed, 20 Apr 2005 16:15:59 +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 j3KEFxet013317 for ; Wed, 20 Apr 2005 16:15:59 +0200 Date: Wed, 20 Apr 2005 16:15:59 +0200 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: RFC2538bis WGLC summary Message-Id: <20050420161559.7a8a7253.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.000091 / -5.9 X-RIPE-Signature: 81360c6e8e86ef3913b4ad7daa3d79ff 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, The working group last call on summary [1] has long been concluded. We have had (public) feedback on the last call from two (!) participants. Given that there was significant feedback on the document while it was still a personal submission we do not thing that this indicates that the document has not been reviewed sufficiently. Based on that we will forward the (updated) document, but not with warm fuzzies. There are a few minor issues [2] that came up during last call that will need to be addressed but that do not warrant a new WGLC. We will allow this working group another 2 weeks to catch possible errors before forwarding the revised document to the IESG. One open process issue is interoperability testing. We think that if we accompany the edits with an interoperability test we can lift it to draft standard. Simon is working on a test-plan, we are looking for volunteers to review that test plan and for volunteers to do the testing. We do not think this is on the critical path. If no volunteers can be found in time we will push this document to the IESG and recycle it at "proposed." Thanks to Simon for the editing of the document, he has done a good job on tracking questions, requests and changes. My apologies for not wrapping up this last call earlier. --Olaf DNSEXT Co-Chair [1] http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00411.html [2] http://josefsson.org/rfc2538bis/ -- to unsubscribe send a message to namedroppers-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 26 23:52:10 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21396 for ; Tue, 26 Apr 2005 23:52:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DQdVB-0002jt-Tq for namedroppers-data@psg.com; Wed, 27 Apr 2005 03:46:17 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DQdVA-0002j7-3d for namedroppers@ops.ietf.org; Wed, 27 Apr 2005 03:46:16 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 30D0C677F6 for ; Wed, 27 Apr 2005 03:46:14 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id j3R3jSbX013225; Wed, 27 Apr 2005 13:45:29 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200504270345.j3R3jSbX013225@drugs.dv.isc.org> To: Edward Lewis Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Who hates the DNAME? In-reply-to: Your message of "Fri, 15 Apr 2005 11:52:48 -0400." Date: Wed, 27 Apr 2005 13:45:28 +1000 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 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. The reason for blocking "* DNAME" is that it results in different results from authoritative servers compared with the results that come from the cache. Plain (non-wildcard) DNAME. "example.com DNAME foo.net" is like "*.example.com CNAME .foo.net". Note there is a implict wildcard generated by the DNAME that *also* operates in caches. To get consistant results from both authoritative servers and caches no subdomains of the DNAME owner are permitted. With wildcard DNAME you have *only* the explict wilcard being expaned by the authoritatives servers and *only* the implicit wildcard being expanded by the caches. This results in different answers depending apon which server you query. As for which servers support DNAME. Every server that supports DNSSECbis is required to support DNAME. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Apr 27 03:44:48 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10715 for ; Wed, 27 Apr 2005 03:44:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DQhA7-0001yT-Eu for namedroppers-data@psg.com; Wed, 27 Apr 2005 07:40:47 +0000 Received: from [193.1.169.34] (helo=dakota.ucd.ie) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DQhA3-0001xp-6e for namedroppers@ops.ietf.org; Wed, 27 Apr 2005 07:40:43 +0000 Received: from conversion-daemon.dakota.ucd.ie by dakota.ucd.ie (Sun Java System Messaging Server 6.1 HotFix 0.04 (built Sep 29 2004)) id <0IFL00B01H9K4R00@dakota.ucd.ie> (original mail from Niall.oReilly@ucd.ie) for namedroppers@ops.ietf.org; Wed, 27 Apr 2005 08:40:41 +0100 (IST) Received: from [10.0.1.189] ([83.141.81.52]) by dakota.ucd.ie (Sun Java System Messaging Server 6.1 HotFix 0.04 (built Sep 29 2004)) with ESMTPSA id <0IFL00226HBSVK20@dakota.ucd.ie>; Wed, 27 Apr 2005 08:40:41 +0100 (IST) Date: Wed, 27 Apr 2005 08:40:46 +0100 From: "Niall O'Reilly" Subject: Re: Who hates the DNAME? In-reply-to: <200504270345.j3R3jSbX013225@drugs.dv.isc.org> To: Mark Andrews Cc: "Niall O'Reilly" , Edward Lewis , namedroppers@ops.ietf.org Message-id: <26a4754c6cdbfbc778f45293c5eb819f@ucd.ie> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT References: <200504270345.j3R3jSbX013225@drugs.dv.isc.org> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On 27 Apr 2005, at 04:45, Mark Andrews wrote: > Note there > is a implict wildcard generated by the DNAME that *also* operates > in caches. To get consistant results from both authoritative > servers and caches no subdomains of the DNAME owner are permitted. > > With wildcard DNAME you have *only* the explict wilcard being expaned > by the authoritatives servers and *only* the implicit wildcard being > expanded by the caches. This results in different answers depending > apon which server you query. Succinct, clear, helpful, bravo! Best regards, Niall O'Reilly University College Dublin Computing Services PGP key ID: AE995ED9 (see www.pgp.net) Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Apr 27 03:54: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 DAA11298 for ; Wed, 27 Apr 2005 03:54:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DQhKN-0003Cv-A2 for namedroppers-data@psg.com; Wed, 27 Apr 2005 07:51:23 +0000 Received: from [64.233.162.203] (helo=zproxy.gmail.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DQhKJ-0003CQ-Kr for namedroppers@ops.ietf.org; Wed, 27 Apr 2005 07:51:19 +0000 Received: by zproxy.gmail.com with SMTP id 18so222953nzp for ; Wed, 27 Apr 2005 00:51:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=HkHVgpWaOppAvI7YgyuBYGBLwJTvHh4sLnv++5K1d3pcjLVM+7AwycJZHbqu4qjd/0/JcX0O488DZV41768iFfNiqjHmiR8zjG2AHvUhI0Z49I6BkmqKWygrac8yPYQ3mQthzygTsQmTNZRPuxb+G/T2Q5jlpt8IEj0hQFTJfMw= Received: by 10.36.88.3 with SMTP id l3mr29802nzb; Wed, 27 Apr 2005 00:51:16 -0700 (PDT) Received: by 10.36.43.14 with HTTP; Wed, 27 Apr 2005 00:51:16 -0700 (PDT) Message-ID: <487354f105042700517764e5c2@mail.gmail.com> Date: Wed, 27 Apr 2005 09:51:16 +0200 From: Robert Martin-Legene Reply-To: Robert Martin-Legene To: namedroppers@ops.ietf.org Subject: Re: DNS Blackhole attack In-Reply-To: <72438e6589c87609acf30798043c0394@autonomica.se> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050306192606.9FAFB190D4@sa.vix.com> <065A74B680020B2B862AD9C9@192.168.100.25> <72438e6589c87609acf30798043c0394@autonomica.se> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,RCVD_BY_IP, RCVD_IN_BL_SPAMCOP_NET autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable On 7/Mar/05, Johan Ihr=E9n wrote: > As most of you know for a signed delegation the referral will contain > NS RRset for the child + DS for the child + RRSIG(DS) + possibly some > glue. The RRSIG(DS) enables the validator to verify whether the data > from the child is authentic or not regardlesss of whether it arrived > from the right servers or not. I.e. it will work just fine even if the > glue is spoofed as long as the bad guy serves data that validate. I've been reading this paragraph a number of times, and it also looked very clear in the RFC. I'm just still wondering if it is or isn't possible to do a DoS in terms of putting lame glues out there. If I MiM replies from .tld-servers regarding fish.tld and remove the glues, inserting my own with a high TTL. Wouldn't fish.tld then be unreachable? -- Robert Martin-Legene, .DK -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Apr 27 05:37: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 FAA18617 for ; Wed, 27 Apr 2005 05:37:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DQivx-000GKk-SH for namedroppers-data@psg.com; Wed, 27 Apr 2005 09:34:17 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DQivs-000GK5-RL for namedroppers@ops.ietf.org; Wed, 27 Apr 2005 09:34:13 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 1E37F2461E; Wed, 27 Apr 2005 11:34:12 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 4C8CF24626; Wed, 27 Apr 2005 11:34:11 +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 j3R9YBet005841; Wed, 27 Apr 2005 11:34:11 +0200 Date: Wed, 27 Apr 2005 11:34:11 +0200 From: "Olaf M. Kolkman" To: Robert Martin-Legene Cc: namedroppers@ops.ietf.org Subject: Re: DNS Blackhole attack Message-Id: <20050427113411.18220766.olaf@ripe.net> In-Reply-To: <487354f105042700517764e5c2@mail.gmail.com> References: <20050306192606.9FAFB190D4@sa.vix.com> <065A74B680020B2B862AD9C9@192.168.100.25> <72438e6589c87609acf30798043c0394@autonomica.se> <487354f105042700517764e5c2@mail.gmail.com> 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.000105 / -5.9 X-RIPE-Signature: 7e766a0e3e6ac30ed80b1d51fcf09966 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 27 Apr 2005 09:51:16 +0200 Robert Martin-Legene wrote: > I've been reading this paragraph a number of times, and it also looked > very clear in the RFC. I'm just still wondering if it is or isn't > possible to do a DoS in terms of putting lame glues out there. It is still possible to do a DoS attack. DNSSEC will not protect against DOS attacks. The ultimate DOS attack would be if the "Man in the Middle" would just strip al the glue. The client would (assuming that the glue is critical i.e. all nameservers are in bailiwick) not be able to contact any of the authoritative nameservers. -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC ---------------------------------| JID: olaf at jabber.secret-wg.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Apr 27 07:58:10 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28842 for ; Wed, 27 Apr 2005 07:58:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DQl5t-0007GW-4x for namedroppers-data@psg.com; Wed, 27 Apr 2005 11:52:41 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DQl5s-0007GB-Bv for namedroppers@ops.ietf.org; Wed, 27 Apr 2005 11:52:40 +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 j3RBqXB7010225; Wed, 27 Apr 2005 07:52:34 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <26a4754c6cdbfbc778f45293c5eb819f@ucd.ie> References: <200504270345.j3R3jSbX013225@drugs.dv.isc.org> <26a4754c6cdbfbc778f45293c5eb819f@ucd.ie> Date: Wed, 27 Apr 2005 07:52:29 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: 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.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 8:40 +0100 4/27/05, Niall O'Reilly wrote: >On 27 Apr 2005, at 04:45, Mark Andrews wrote: > >> Note there >> is a implict wildcard generated by the DNAME that *also* operates >> in caches. To get consistant results from both authoritative >> servers and caches no subdomains of the DNAME owner are permitted. >> >> With wildcard DNAME you have *only* the explict wilcard being expaned >> by the authoritatives servers and *only* the implicit wildcard being >> expanded by the caches. This results in different answers depending >> apon which server you query. > >Succinct, clear, helpful, bravo! > >Best regards, > >Niall O'Reilly >University College Dublin Computing Services Maybe it's my American English or my desire for longer email messages, but, Mark, could you cook up an example? Maybe a zone with just a DNAME and one other name below the apex and then a sequence of queries showing what you mean? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Wed Apr 27 10:04: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 KAA13884 for ; Wed, 27 Apr 2005 10:04:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DQn4U-000Ncy-GM for namedroppers-data@psg.com; Wed, 27 Apr 2005 13:59:22 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DQn4Q-000Nbv-Bl for namedroppers@ops.ietf.org; Wed, 27 Apr 2005 13:59: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 j3RDx4Pk010734; Wed, 27 Apr 2005 09:59:05 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200504270345.j3R3jSbX013225@drugs.dv.isc.org> References: <200504270345.j3R3jSbX013225@drugs.dv.isc.org> Date: Wed, 27 Apr 2005 09:59:12 -0400 To: Mark Andrews 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.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 13:45 +1000 4/27/05, Mark Andrews wrote: > > The reason for blocking "* DNAME" is that it results in different > results from authoritative servers compared with the results that > come from the cache. So, unlike '* NS' this case ought to be outright "banned?" By that I mean, '* NS' was once plausible, but DNSSEC has made exposed the rift in the fabric of DNS and created a protocol pinch point. It seems that '* DNAME' has never been a wise idea and should have been explicitly prohibited when this went to proposed standard. > Plain (non-wildcard) DNAME. > > "example.com DNAME foo.net" is like > "*.example.com CNAME .foo.net". Note there > is a implict wildcard generated by the DNAME that *also* operates > in caches. To get consistant results from both authoritative > servers and caches no subdomains of the DNAME owner are permitted. > > With wildcard DNAME you have *only* the explict wilcard being expaned > by the authoritatives servers and *only* the implicit wildcard being > expanded by the caches. This results in different answers depending > apon which server you query. So, to try an example (I know I asked for one earlier): If there is a "*.example DNAME cctld." here are two scenarios... SCENARIO 1 Query Cache Authoritative www.zone1.example. ------------------------> responds with www.zone1.example DNAME www.zone1.example DNAME <---- www.sub.zone1.example. (cache miss) -----------> responds with www.sub.zone1.example. DNAME SCENARIO 2 Query Cache Authoritative zone1.example. ------------------------> responds with zone1.example DNAME zone1.example. DNAME <-------- www.zone1.example. falls under DNAME above "synthesizes" the CNAME www.zone1.example. CNAME www.tld zone1.example. DNAME tld. <---------- www.zone1.example. CNAME www.tld. www.sub.zone1.example. (Not a cache miss this time) It seems to me that DNAME processing in the cache is the culprit. > As for which servers support DNAME. Every server that supports > DNSSECbis is required to support DNAME. That's not a good gauge. There is no enforcement of IETF standards...;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Wed Apr 27 16:00: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 QAA21038 for ; Wed, 27 Apr 2005 16:00:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DQsd9-000Ifo-Fw for namedroppers-data@psg.com; Wed, 27 Apr 2005 19:55:31 +0000 Received: from [193.1.169.34] (helo=dakota.ucd.ie) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DQsd8-000IfX-My for namedroppers@ops.ietf.org; Wed, 27 Apr 2005 19:55:30 +0000 Received: from conversion-daemon.dakota.ucd.ie by dakota.ucd.ie (Sun Java System Messaging Server 6.1 HotFix 0.04 (built Sep 29 2004)) id <0IFM00F01F9FMD00@dakota.ucd.ie> (original mail from Niall.oReilly@ucd.ie) for namedroppers@ops.ietf.org; Wed, 27 Apr 2005 20:55:29 +0100 (IST) Received: from [10.0.1.189] ([83.141.81.52]) by dakota.ucd.ie (Sun Java System Messaging Server 6.1 HotFix 0.04 (built Sep 29 2004)) with ESMTPSA id <0IFM00G19FCGYPE0@dakota.ucd.ie>; Wed, 27 Apr 2005 20:55:28 +0100 (IST) Date: Wed, 27 Apr 2005 20:55:21 +0100 From: "Niall O'Reilly" Subject: Re: Who hates the DNAME? In-reply-to: To: Edward Lewis Cc: "Niall O'Reilly" , namedroppers@ops.ietf.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT References: <200504270345.j3R3jSbX013225@drugs.dv.isc.org> <26a4754c6cdbfbc778f45293c5eb819f@ucd.ie> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On 27 Apr 2005, at 12:52, Edward Lewis wrote: > Maybe it's my American English or my desire for longer email messages, > but, Mark, could you cook up an example? Maybe a zone with just a > DNAME and one other name below the apex and then a sequence of queries > showing what you mean? I hope this isn't too short, and that I'm not "teaching my grandmother to suck eggs", as we say in this part of the anglophone world. 8-) A well-crafted example would be nice, and I'll take off my hat to whoever shows one. See also the penultimate sentence below. What I found truly wonderful about Mark's message was that he told me something which, on reflection, I believe I must already have known, but had never recognized in such simple terms. What it comes down to is, not mixing the kinds of synthesis you use. Simple terminal (non-NS, non-DNAME) wildcard specifies a synthesis which might be called "default terminal substitution". This is synthesis because the given QNAME does not match the NAME of any existing RR; an RRset is brought into existence on demand. Simple CNAME specifies "specific terminal substitution". In this case, what happens is not synthesis; the given QNAME matches an existing RR, and the specified substitution is performed. No tricks. Simple DNAME specifies "non-terminal substitution". This is synthesis because, just like the simple wildcard case, the given QNAME does not match the NAME of any existing RR. What Mark helped me realize is that these two kinds of synthesis are sufficiently different that there is probably no circumstance in which mixing them would be appropriate. A well-crafted example contradicting this view would be a significant contribution to the discussion. Non-terminal wildcard and wildcard NS are topics on which I don't feel prepared to comment. /Niall -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Apr 27 16:21:39 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29071 for ; Wed, 27 Apr 2005 16:21:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DQszX-000MV5-Nh for namedroppers-data@psg.com; Wed, 27 Apr 2005 20:18:39 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DQszV-000MUe-0t for namedroppers@ops.ietf.org; Wed, 27 Apr 2005 20:18:37 +0000 Received: from [10.131.244.227] ([::ffff:172.25.170.10]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.verisignlabs.com with esmtp; Wed, 27 Apr 2005 16:18:36 -0400 id 002F00EC.426FF39C.00000E80 Received-SPF: unknown (Address does not pass the Sender Policy Framework) SPF=HELO; sender=[10.131.244.227]; remoteip=::ffff:172.25.170.10; remotehost=; helo=[10.131.244.227]; receiver=mail.verisignlabs.com; Received-SPF: fail (Address does not pass the Sender Policy Framework) SPF=MAILFROM; sender=davidb@verisignlabs.com; remoteip=::ffff:172.25.170.10; remotehost=; helo=[10.131.244.227]; receiver=mail.verisignlabs.com; Message-ID: <426FF39B.6000905@verisignlabs.com> Date: Wed, 27 Apr 2005 16:18:35 -0400 From: David Blacka Organization: VeriSign, Inc. User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Andrews CC: Edward Lewis , namedroppers@ops.ietf.org Subject: Re: Who hates the DNAME? References: <200504270345.j3R3jSbX013225@drugs.dv.isc.org> In-Reply-To: <200504270345.j3R3jSbX013225@drugs.dv.isc.org> X-Enigmail-Version: 0.90.0.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.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mark Andrews wrote: > As for which servers support DNAME. Every server that supports > DNSSECbis is required to support DNAME. What do you mean by server? What do you mean by "support DNAME"? -- David Blacka Sr. Engineer VeriSign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Apr 27 16:35:04 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03492 for ; Wed, 27 Apr 2005 16:35:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DQtDf-000PBe-H2 for namedroppers-data@psg.com; Wed, 27 Apr 2005 20:33:15 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DQtDe-000PBQ-VM for namedroppers@ops.ietf.org; Wed, 27 Apr 2005 20:33:15 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id j3RKX5KN011357; Wed, 27 Apr 2005 20:33:05 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id j3RKX5Q1011354; Wed, 27 Apr 2005 20:33:05 GMT Date: Wed, 27 Apr 2005 20:33:05 +0000 From: bmanning@vacation.karoshi.com To: David Blacka Cc: Mark Andrews , Edward Lewis , namedroppers@ops.ietf.org Subject: Re: Who hates the DNAME? Message-ID: <20050427203305.GL10712@vacation.karoshi.com.> References: <200504270345.j3R3jSbX013225@drugs.dv.isc.org> <426FF39B.6000905@verisignlabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <426FF39B.6000905@verisignlabs.com> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > Mark Andrews wrote: > > > As for which servers support DNAME. Every server that supports > > DNSSECbis is required to support DNAME. > > David Blacka wrote: > What do you mean by server? What do you mean by "support DNAME"? and for that matter, Mark, you talk aobut a cache that performs tricks :) i'd be really interested in the distinction betwn a cache (which i think of a data structures in storage) and a server (authoritative is the only kind i know) what some folks call a caching server is really an iterative mode resolver that has access to a cache... right? --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Apr 27 16:56:46 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06017 for ; Wed, 27 Apr 2005 16:56:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DQtYf-0001pE-My for namedroppers-data@psg.com; Wed, 27 Apr 2005 20:54:57 +0000 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DQtYd-0001nz-T8 for namedroppers@ops.ietf.org; Wed, 27 Apr 2005 20:54:56 +0000 Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:250:daff:fe82:1c39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id A7D3D78 for ; Wed, 27 Apr 2005 16:54:54 -0400 (EDT) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id F024741EA for ; Wed, 27 Apr 2005 16:54:53 -0400 (EDT) Date: Wed, 27 Apr 2005 16:54:53 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Who hates the DNAME? In-Reply-To: References: <20050415163017.831B213971@sa.vix.com> MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20050427205453.F024741EA@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Fri, 15 Apr 2005 14:10:50 -0400, Edward Lewis wrote: > At 16:30 +0000 4/15/05, Paul Vixie wrote: > > >see also . > > OTOH, someone from ISC was behind outlawing "* DNAME". Note that the technique outlined in the above reference does not in fact use wildcard DNAME. It uses plain old DNAME. I think that Niall's observation is correct. Part of the reason that wildcard DNAME make's people's heads hurt is that it's a mixture of two different kinds of synthesis, which work in sufficiently different ways that the result is (at best) undefined. I do not believe that wildcard DNAME ever worked, any more than wildcard NS ever worked. Stating that the result of using them is undefined is simply acknowledging the behavior of horses that left the barn long ago. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Apr 27 17:14: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 RAA07474 for ; Wed, 27 Apr 2005 17:14:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DQtpi-0004JO-JD for namedroppers-data@psg.com; Wed, 27 Apr 2005 21:12:34 +0000 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DQtpY-0004Ig-OE for namedroppers@ops.ietf.org; Wed, 27 Apr 2005 21:12:25 +0000 Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:250:daff:fe82:1c39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id 661EC8B for ; Wed, 27 Apr 2005 17:12:23 -0400 (EDT) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id B2A5F41EA for ; Wed, 27 Apr 2005 17:12:22 -0400 (EDT) Date: Wed, 27 Apr 2005 17:12:22 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Who hates the DNAME? In-Reply-To: <20050427203305.GL10712@vacation.karoshi.com.> References: <200504270345.j3R3jSbX013225@drugs.dv.isc.org> <426FF39B.6000905@verisignlabs.com> MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20050427211222.B2A5F41EA@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Wed, 27 Apr 2005 20:33:05 +0000, Bill Manning wrote: > > > > Mark Andrews wrote: > > > > > As for which servers support DNAME. Every server that supports > > > DNSSECbis is required to support DNAME. > > > > David Blacka wrote: > > What do you mean by server? What do you mean by "support DNAME"? > > and for that matter, Mark, you talk aobut a cache that > performs tricks :) i'd be really interested in the distinction > betwn a cache (which i think of a data structures in storage) > and a server (authoritative is the only kind i know) > > what some folks call a caching server is really an iterative mode > resolver that has access to a cache... right? It's a recursive name server, which includes an iterative reolver, which includes a cache. As far as DNSSECbis requiring support for DNAME, search for "DNAME" in RFC4035, but the one that's relevant here has to do with validation of synthesized CNAMEs: 4.8. Synthesized CNAMEs A validating security-aware resolver MUST treat the signature of a valid signed DNAME RR as also covering unsigned CNAME RRs that could have been synthesized from the DNAME RR, as described in [RFC2672], at least to the extent of not rejecting a response message solely because it contains such CNAME RRs. The resolver MAY retain such CNAME RRs in its cache or in the answers it hands back, but is not required to do so. That is: the DNSSECbis validation algorithm requires the validator to understand DNAME, because DNAME is another kind of synthesis rule. Just as with wildcards, the only real options we had here were: a) signing synthesized RRsets on the fly, or b) signing the synthesis rule, which requires the validator to understand the synthesis rule. RFC2672 said to do both (a) and (b) at once. For DNSSECbis, the WG decided to punt (a) and just do (b). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Apr 27 19:55:07 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21835 for ; Wed, 27 Apr 2005 19:55:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DQwJt-000Nqt-HV for namedroppers-data@psg.com; Wed, 27 Apr 2005 23:51:53 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DQwJq-000NoJ-LE for namedroppers@ops.ietf.org; Wed, 27 Apr 2005 23:51:50 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 23822677FA for ; Wed, 27 Apr 2005 23:51:49 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id j3RNp54I060718; Thu, 28 Apr 2005 09:51:05 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200504272351.j3RNp54I060718@drugs.dv.isc.org> To: Edward Lewis Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Who hates the DNAME? In-reply-to: Your message of "Wed, 27 Apr 2005 07:52:29 -0400." Date: Thu, 28 Apr 2005 09:51:05 +1000 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > At 8:40 +0100 4/27/05, Niall O'Reilly wrote: > >On 27 Apr 2005, at 04:45, Mark Andrews wrote: > > > >> Note there > >> is a implict wildcard generated by the DNAME that *also* operates > >> in caches. To get consistant results from both authoritative > >> servers and caches no subdomains of the DNAME owner are permitted. > >> > >> With wildcard DNAME you have *only* the explict wilcard being expaned > >> by the authoritatives servers and *only* the implicit wildcard being > >> expanded by the caches. This results in different answers depending > >> apon which server you query. > > > >Succinct, clear, helpful, bravo! > > > >Best regards, > > > >Niall O'Reilly > >University College Dublin Computing Services > > Maybe it's my American English or my desire for longer email > messages, but, Mark, could you cook up an example? Maybe a zone with > just a DNAME and one other name below the apex and then a sequence of > queries showing what you mean? > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > 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: *.example.net DNAME foo.bar Perform the following query sequence. a) sub.example.net/ANY b) www.sub.example.net/A Auth server: a) sub.example.net DNAME foo.bar b) NODATA Cache: a) sub.example.net DNAME foo.bar b) sub.example.net DNAME foo.bar + www.sub.example.net CNAME www.foo.bar -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Apr 27 20:21:30 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23938 for ; Wed, 27 Apr 2005 20:21:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DQwiw-0002e3-2U for namedroppers-data@psg.com; Thu, 28 Apr 2005 00:17:46 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DQwit-0002cx-1H for namedroppers@ops.ietf.org; Thu, 28 Apr 2005 00:17:43 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id j3S0EwKN012179; Thu, 28 Apr 2005 00:14:58 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id j3S0Ewmc012176; Thu, 28 Apr 2005 00:14:58 GMT Date: Thu, 28 Apr 2005 00:14:58 +0000 From: bmanning@vacation.karoshi.com To: Rob Austein Cc: namedroppers@ops.ietf.org Subject: Re: Who hates the DNAME? Message-ID: <20050428001458.GC12063@vacation.karoshi.com.> References: <200504270345.j3R3jSbX013225@drugs.dv.isc.org> <426FF39B.6000905@verisignlabs.com> <20050427211222.B2A5F41EA@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050427211222.B2A5F41EA@thrintun.hactrn.net> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, Apr 27, 2005 at 05:12:22PM -0400, Rob Austein wrote: > At Wed, 27 Apr 2005 20:33:05 +0000, Bill Manning wrote: > > > > > > Mark Andrews wrote: > > > > > > > As for which servers support DNAME. Every server that supports > > > > DNSSECbis is required to support DNAME. > > > > > > David Blacka wrote: > > > What do you mean by server? What do you mean by "support DNAME"? > > > > and for that matter, Mark, you talk aobut a cache that > > performs tricks :) i'd be really interested in the distinction > > betwn a cache (which i think of a data structures in storage) > > and a server (authoritative is the only kind i know) > > > > what some folks call a caching server is really an iterative mode > > resolver that has access to a cache... right? > > It's a recursive name server, which includes an iterative reolver, > which includes a cache. > > As far as DNSSECbis requiring support for DNAME, search for "DNAME" in > RFC4035, but the one that's relevant here has to do with validation of > synthesized CNAMEs: > > 4.8. Synthesized CNAMEs > > A validating security-aware resolver MUST treat the signature of a > valid signed DNAME RR as also covering unsigned CNAME RRs that could > have been synthesized from the DNAME RR, as described in [RFC2672], > at least to the extent of not rejecting a response message solely > because it contains such CNAME RRs. The resolver MAY retain such > CNAME RRs in its cache or in the answers it hands back, but is not > required to do so. > > That is: the DNSSECbis validation algorithm requires the validator to > understand DNAME, because DNAME is another kind of synthesis rule. > Just as with wildcards, the only real options we had here were: > > a) signing synthesized RRsets on the fly, or > > b) signing the synthesis rule, which requires the validator to > understand the synthesis rule. > > RFC2672 said to do both (a) and (b) at once. For DNSSECbis, the WG > decided to punt (a) and just do (b). > that still leaves me withthe question of -where- synthesis is supposed to occur. ... the resolver? the validator? some shared datastructures where intermediate data si stored ffor future use by either the resolver or the validator? it could be that synthesis can occur in several distinct areas but the expectation is that the results of the synthesis operation is expected to be stored in a cache... and one of the problems Ed and Mark were trying to tease out is that what is eventually stored in a cache may not be consistant with what an auth server might have synthesized - or for that matter what might be found in some other cache. regardless of who ir what did the synthesis to put it there. (oh for better connectivity... :) --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Apr 27 20: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 UAA25508 for ; Wed, 27 Apr 2005 20:43:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DQx5S-0006CA-Et for namedroppers-data@psg.com; Thu, 28 Apr 2005 00:41:02 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DQx5Q-0006Bx-Ll for namedroppers@ops.ietf.org; Thu, 28 Apr 2005 00:41:00 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id A0DC8677FB for ; Thu, 28 Apr 2005 00:40:59 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id j3S0eHjg061569; Thu, 28 Apr 2005 10:40:17 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200504280040.j3S0eHjg061569@drugs.dv.isc.org> To: bmanning@vacation.karoshi.com Cc: Rob Austein , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Who hates the DNAME? In-reply-to: Your message of "Thu, 28 Apr 2005 00:14:58 GMT." <20050428001458.GC12063@vacation.karoshi.com.> Date: Thu, 28 Apr 2005 10:40:17 +1000 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > On Wed, Apr 27, 2005 at 05:12:22PM -0400, Rob Austein wrote: > > At Wed, 27 Apr 2005 20:33:05 +0000, Bill Manning wrote: > > > > > > > > Mark Andrews wrote: > > > > > > > > > As for which servers support DNAME. Every server that supports > > > > > DNSSECbis is required to support DNAME. > > > > > > > > David Blacka wrote: > > > > What do you mean by server? What do you mean by "support DNAME"? > > > > > > and for that matter, Mark, you talk aobut a cache that > > > performs tricks :) i'd be really interested in the distinction > > > betwn a cache (which i think of a data structures in storage) > > > and a server (authoritative is the only kind i know) > > > > > > what some folks call a caching server is really an iterative mode > > > resolver that has access to a cache... right? > > > > It's a recursive name server, which includes an iterative reolver, > > which includes a cache. > > > > As far as DNSSECbis requiring support for DNAME, search for "DNAME" in > > RFC4035, but the one that's relevant here has to do with validation of > > synthesized CNAMEs: > > > > 4.8. Synthesized CNAMEs > > > > A validating security-aware resolver MUST treat the signature of a > > valid signed DNAME RR as also covering unsigned CNAME RRs that could > > have been synthesized from the DNAME RR, as described in [RFC2672], > > at least to the extent of not rejecting a response message solely > > because it contains such CNAME RRs. The resolver MAY retain such > > CNAME RRs in its cache or in the answers it hands back, but is not > > required to do so. > > > > That is: the DNSSECbis validation algorithm requires the validator to > > understand DNAME, because DNAME is another kind of synthesis rule. > > Just as with wildcards, the only real options we had here were: > > > > a) signing synthesized RRsets on the fly, or > > > > b) signing the synthesis rule, which requires the validator to > > understand the synthesis rule. > > > > RFC2672 said to do both (a) and (b) at once. For DNSSECbis, the WG > > decided to punt (a) and just do (b). > > > > that still leaves me withthe question of -where- synthesis > is supposed to occur. ... the resolver? the validator? > some shared datastructures where intermediate data si stored > ffor future use by either the resolver or the validator? > it could be that synthesis can occur in several distinct areas > but the expectation is that the results of the synthesis operation > is expected to be stored in a cache... and one of the problems Ed and M > ark > were trying to tease out is that what is eventually stored in > a cache may not be consistant with what an auth server might > have synthesized - or for that matter what might be found in some other > cache. > regardless of who ir what did the synthesis to put it there. > > (oh for better connectivity... :) > > --bill Well for BIND 9 we don't cache the CNAME. We cache the DNAME and generate the CNAME when replying. Note that CNAME generation is for non-DNAME aware clients. DNAME aware clients are supposed to self generate the CNAME / re-write the QNAME when processing the answer. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Apr 28 03:23:29 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16013 for ; Thu, 28 Apr 2005 03:23:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DR3IC-0007sF-LP for namedroppers-data@psg.com; Thu, 28 Apr 2005 07:18:36 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DR3IA-0007rr-Qi for namedroppers@ops.ietf.org; Thu, 28 Apr 2005 07:18:35 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 8FFC12DE36; Thu, 28 Apr 2005 09:18:29 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 8EB332DE35; Thu, 28 Apr 2005 09:18:29 +0200 (CEST) Date: Thu, 28 Apr 2005 09:18:29 +0200 (CEST) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: Mark Andrews cc: bmanning@vacation.karoshi.com, Rob Austein , namedroppers@ops.ietf.org Subject: Re: Who hates the DNAME? In-Reply-To: <200504280040.j3S0eHjg061569@drugs.dv.isc.org> Message-ID: References: <200504280040.j3S0eHjg061569@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 28 Apr 2005, Mark Andrews wrote: > Well for BIND 9 we don't cache the CNAME. We cache the DNAME and > generate the CNAME when replying. Note that CNAME generation > is for non-DNAME aware clients. DNAME aware clients are supposed > to self generate the CNAME / re-write the QNAME when processing > the answer. non-dname aware clients are currently ALL clients by definition. RFC2672 states DNAME aware clients may indicate DNAME support by signalling EDNS version>0. There is no version>0 defined. rfc4035 does not change that fact. Sure, the validator needs to understand how to validate DNAME in order to trust the syntesized CNAMEs, but that is basically it. This self generating/synthesizing crap on a resolver is imho an undesired precedent. I dislike DNAME as well. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Apr 28 09:53: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 JAA15958 for ; Thu, 28 Apr 2005 09:53:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DR9MB-000Ori-Ms for namedroppers-data@psg.com; Thu, 28 Apr 2005 13:47:07 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DR9MA-000OrT-1A for namedroppers@ops.ietf.org; Thu, 28 Apr 2005 13:47:06 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 727F667801 for ; Thu, 28 Apr 2005 13:47:04 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id j3SDi1iZ005155; Thu, 28 Apr 2005 23:44:03 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200504281344.j3SDi1iZ005155@drugs.dv.isc.org> To: Roy Arends Cc: bmanning@vacation.karoshi.com, Rob Austein , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Who hates the DNAME? In-reply-to: Your message of "Thu, 28 Apr 2005 09:18:29 +0200." Date: Thu, 28 Apr 2005 23:44:01 +1000 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > On Thu, 28 Apr 2005, Mark Andrews wrote: > > > Well for BIND 9 we don't cache the CNAME. We cache the DNAME and > > generate the CNAME when replying. Note that CNAME generation > > is for non-DNAME aware clients. DNAME aware clients are supposed > > to self generate the CNAME / re-write the QNAME when processing > > the answer. > > non-dname aware clients are currently ALL clients by definition. No. There is no signaling of whether the client is DNAME aware to the server. That is very different to saying that there are no DNAME aware clients. > RFC2672 > states DNAME aware clients may indicate DNAME support by signalling EDNS > version>0. There is no version>0 defined. > > rfc4035 does not change that fact. Sure, the validator needs to understand > how to validate DNAME in order to trust the syntesized CNAMEs, but that is > basically it. > > This self generating/synthesizing crap on a resolver is imho an undesired > precedent. That arguement should have been made six years ago. > I dislike DNAME as well. I like DNAME. I don't think that wildcard DNAMEs are sensible or meaningful. > Roy > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Apr 28 10:21:28 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19965 for ; Thu, 28 Apr 2005 10:21:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DR9rD-0004Ee-1g for namedroppers-data@psg.com; Thu, 28 Apr 2005 14:19:11 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DR9rA-0004EK-Ta for namedroppers@ops.ietf.org; Thu, 28 Apr 2005 14:19:09 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 1FBD02DE66; Thu, 28 Apr 2005 16:19:07 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 1E3C82DE24; Thu, 28 Apr 2005 16:19:07 +0200 (CEST) Date: Thu, 28 Apr 2005 16:19:06 +0200 (CEST) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: Mark Andrews cc: bmanning@vacation.karoshi.com, Rob Austein , namedroppers@ops.ietf.org Subject: Re: Who hates the DNAME? In-Reply-To: <200504281344.j3SDi1iZ005155@drugs.dv.isc.org> Message-ID: References: <200504281344.j3SDi1iZ005155@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 28 Apr 2005, Mark Andrews wrote: > > > On Thu, 28 Apr 2005, Mark Andrews wrote: > > > > > Well for BIND 9 we don't cache the CNAME. We cache the DNAME and > > > generate the CNAME when replying. Note that CNAME generation > > > is for non-DNAME aware clients. DNAME aware clients are supposed > > > to self generate the CNAME / re-write the QNAME when processing > > > the answer. > > > > non-dname aware clients are currently ALL clients by definition. > > No. There is no signaling of whether the client is DNAME > aware to the server. exactly. > That is very different to saying that > there are no DNAME aware clients. So, well, until I see a signal that martians exist, I assume no martians exist, especially when I can only depend on that signal to tell me martians exists. > > RFC2672 > > states DNAME aware clients may indicate DNAME support by signalling EDNS > > version>0. There is no version>0 defined. > > > > rfc4035 does not change that fact. Sure, the validator needs to understand > > how to validate DNAME in order to trust the syntesized CNAMEs, but that is > > basically it. > > > > This self generating/synthesizing crap on a resolver is imho an undesired > > precedent. > > That arguement should have been made six years ago. Well, I'm making it now. btw, how was interoperability tested with DNAME ? What was the other (as in, other than BIND) implementation? Why not move this to experimental, as we did with A6 ? Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Apr 28 10:44:57 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22308 for ; Thu, 28 Apr 2005 10:44:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DRAEE-0008Di-VP for namedroppers-data@psg.com; Thu, 28 Apr 2005 14:42:58 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DRAEC-0008Bt-VA for namedroppers@ops.ietf.org; Thu, 28 Apr 2005 14:42:57 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j3SEgoPM016321 for ; Thu, 28 Apr 2005 10:42:50 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.2.1.2.2.20050428103217.040e2670@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 28 Apr 2005 10:42:48 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: Re: Who hates the DNAME? In-Reply-To: References: <200504281344.j3SDi1iZ005155@drugs.dv.isc.org> Mime-Version: 1.0 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.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 10:19 28/04/2005, Roy Arends wrote: >On Thu, 28 Apr 2005, Mark Andrews wrote: > >btw, how was interoperability tested with DNAME ? What was the other (as >in, other than BIND) implementation? Good question, has anyone else implemented DNAME processing ? >Why not move this to experimental, as we did with A6 ? As this is a DNSEXT specific question the joint process (DNSEXT +NGTRANS) that lead to move of A6 to experimental did not have authority to make that change. The choices we have in front of us regarding DNAME are: Fix the specification Move it to experimental (i.e. make it optional to support) Obsolete DNAME The first question to ask: is something like DNAME a useful feature in DNS? If the answer to this question is NO then obsoleting DNAME is the right thing to do, if the answer is YES then the other options remain on the table. Olafur PS: in regards to feature signalling at some point it might be worth while to create a profile of required RFC's to implement for implementations to be compliant with "modern" DNS. -- to unsubscribe send a message to namedroppers-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 28 11:02:53 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24074 for ; Thu, 28 Apr 2005 11:02:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DRAUp-000AoN-Qi for namedroppers-data@psg.com; Thu, 28 Apr 2005 15:00:07 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DRAUm-000AnT-ID for namedroppers@ops.ietf.org; Thu, 28 Apr 2005 15:00:04 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id AF893677FC for ; Thu, 28 Apr 2005 15:00:03 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id j3SEx2DZ005549; Fri, 29 Apr 2005 00:59:14 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200504281459.j3SEx2DZ005549@drugs.dv.isc.org> To: Roy Arends Cc: bmanning@vacation.karoshi.com, Rob Austein , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Who hates the DNAME? In-reply-to: Your message of "Thu, 28 Apr 2005 16:19:06 +0200." Date: Fri, 29 Apr 2005 00:59:02 +1000 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > On Thu, 28 Apr 2005, Mark Andrews wrote: > > > > > > On Thu, 28 Apr 2005, Mark Andrews wrote: > > > > > > > Well for BIND 9 we don't cache the CNAME. We cache the DNAME a > nd > > > > generate the CNAME when replying. Note that CNAME generation > > > > is for non-DNAME aware clients. DNAME aware clients are suppos > ed > > > > to self generate the CNAME / re-write the QNAME when processing > > > > the answer. > > > > > > non-dname aware clients are currently ALL clients by definition. > > > > No. There is no signaling of whether the client is DNAME > > aware to the server. > > exactly. > > > That is very different to saying that > > there are no DNAME aware clients. > > So, well, until I see a signal that martians exist, I assume no martians > exist, especially when I can only depend on that signal to tell me > martians exists. If the client groks a DNAME record then it is DNAME aware. Servers don't care if the client is DNAME aware or not. They just send the DNAME (for the DNAME aware clients) and the CNAME (for the non-DNAME aware clients). Being able to say I understand DNAME is a optimisation not a requirement. > > > RFC2672 > > > states DNAME aware clients may indicate DNAME support by signalling EDNS > > > version>0. There is no version>0 defined. > > > > > > rfc4035 does not change that fact. Sure, the validator needs to understan > d > > > how to validate DNAME in order to trust the syntesized CNAMEs, but that i > s > > > basically it. > > > > > > This self generating/synthesizing crap on a resolver is imho an undesired > > > precedent. > > > > That arguement should have been made six years ago. > > Well, I'm making it now. > > btw, how was interoperability tested with DNAME ? What was the other (as > in, other than BIND) implementation? You don't need interoperability to get a PS, you need it for a DS. > Why not move this to experimental, as we did with A6 ? Because it is useful. Because there is no need to move it to experimental. I and I suspect others took great care to ensure DNAME was not marked as experimental when A6 and bitstring labels were moved to experimental. That would have been throwing the baby out with the bath water. Section 4 of RFC 3363 is completely without basis. The initial premise is false. One can easily do a similar demonstation with nibble based reverse lookups as was done with bitstring based lookups in RFC 2874 and therby prove the initial premise false. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Apr 28 11:09:50 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24720 for ; Thu, 28 Apr 2005 11:09:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DRAcb-000CLp-Jt for namedroppers-data@psg.com; Thu, 28 Apr 2005 15:08:09 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DRAcZ-000CKO-R4 for namedroppers@ops.ietf.org; Thu, 28 Apr 2005 15:08:07 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 3DDA8677F9 for ; Thu, 28 Apr 2005 15:08:07 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id j3SF7Nr5005603; Fri, 29 Apr 2005 01:07:24 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200504281507.j3SF7Nr5005603@drugs.dv.isc.org> To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Who hates the DNAME? In-reply-to: Your message of "Thu, 28 Apr 2005 10:42:48 -0400." <6.2.1.2.2.20050428103217.040e2670@localhost> Date: Fri, 29 Apr 2005 01:07:23 +1000 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > At 10:19 28/04/2005, Roy Arends wrote: > >On Thu, 28 Apr 2005, Mark Andrews wrote: > > > >btw, how was interoperability tested with DNAME ? What was the other (as > >in, other than BIND) implementation? > > Good question, has anyone else implemented DNAME processing ? DRC has already said CNS implements DNAME. > >Why not move this to experimental, as we did with A6 ? > > > As this is a DNSEXT specific question the joint process (DNSEXT +NGTRANS) > that lead to move of A6 to experimental did not have authority to > make that change. > The choices we have in front of us regarding DNAME are: > Fix the specification > Move it to experimental (i.e. make it optional to support) > Obsolete DNAME > > The first question to ask: is something like DNAME a useful feature in DNS? Yes. We asked this question 6 years ago and the answer was yes then and it is still yes today. I suspect a lot have not implemented DNAME because they have mis-read RFC 3363 to imply that DNAME is experimental. I've heard "But isn't DNAME experimental?" so many times. > If the answer to this question is NO then obsoleting DNAME is the right > thing to do, if the answer is YES then the other options remain on the > table. > > Olafur > PS: in regards to feature signalling at some point it might be worth while > to create a profile of required RFC's to implement for implementations > to be compliant with "modern" DNS. > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Apr 28 11:26:45 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26347 for ; Thu, 28 Apr 2005 11:26:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DRAsP-000Eux-Ga for namedroppers-data@psg.com; Thu, 28 Apr 2005 15:24:29 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DRAsO-000Euk-0I for namedroppers@ops.ietf.org; Thu, 28 Apr 2005 15:24:28 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id B456713971 for ; Thu, 28 Apr 2005 15:24:27 +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 =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair of "Thu, 28 Apr 2005 10:42:48 -0400." <6.2.1.2.2.20050428103217.040e2670@localhost> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 28 Apr 2005 15:24:27 +0000 Message-Id: <20050428152427.B456713971@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > The first question to ask: is something like DNAME a useful feature in DNS? yes, absolutely. > If the answer to this question is NO then obsoleting DNAME is the right > thing to do, if the answer is YES then the other options remain on the > table. clarify the specification, is my advice. -- to unsubscribe send a message to namedroppers-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 28 11:32:10 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26790 for ; Thu, 28 Apr 2005 11:32:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DRAxd-000FsZ-5e for namedroppers-data@psg.com; Thu, 28 Apr 2005 15:29:53 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DRAxc-000FsI-0v for namedroppers@ops.ietf.org; Thu, 28 Apr 2005 15:29:52 +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 j3SFTiwd016644; Thu, 28 Apr 2005 11:29:45 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <6.2.1.2.2.20050428103217.040e2670@localhost> References: <200504281344.j3SDi1iZ005155@drugs.dv.isc.org> <6.2.1.2.2.20050428103217.040e2670@localhost> Date: Thu, 28 Apr 2005 11:29:53 -0400 To: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson_=2FDNSEXT__co=2Dchair?= From: Edward Lewis Subject: Re: Who hates the DNAME? Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, MIME_QP_LONG_LINE autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable =46irst let me apologize for stirring up such a=20 nest of trouble. ;) I only wanted to get wcard=20 done. I swear. At 10:42 -0400 4/28/05, =D3lafur Gu=F0mundsson /DNSEXT co-chair wrote: >Good question, has anyone else [other than BIND] implemented DNAME processi= ng? I believe Nominum has done it. (someone else) >Why not move this to experimental, as we did with A6? >As this is a DNSEXT specific question the joint process (DNSEXT +NGTRANS) >that lead to move of A6 to experimental did not have authority to >make that change. >The choices we have in front of us regarding DNAME are: > Fix the specification > Move it to experimental (i.e. make it optional to support) > Obsolete DNAME And the ever popular option of "leave it as is." >The first question to ask: is something like DNAME a useful feature in DNS? I'd like to hear cases for the DNAME, and cases=20 where it has proven to be a big help.=20 Personally, as an architectural purist, I think=20 it's an abomination - but if it's something of=20 benefit, it's worthwhile. (Don't let the bus=20 driver determine the route.) To date, I have=20 heard a few strong voices say "it's important"=20 but there hasn't been much anecdotal data to=20 support the claims. Note - no offense to "strong voices" but it takes=20 more than a comment from a reputable person to=20 support something. People come and go,=20 reputations are fleeting, that is why it pays to=20 document use cases, etc. >If the answer to this question is NO then obsoleting DNAME is the right >thing to do, if the answer is YES then the other options remain on the >table. And if the answer is unclear, then...;) >PS: in regards to feature signalling at some point it might be worth while >to create a profile of required RFC's to implement for implementations >to be compliant with "modern" DNS. While this is admirable, I don't see a nest of=20 engineers ever defining a useful profile.=20 Operators would be invaluable for this...you'd be=20 surprised at the differing perspectives of a=20 protocol architect and of a service provider. -- -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- 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 Thu Apr 28 11:50: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 LAA28253 for ; Thu, 28 Apr 2005 11:50:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DRBFS-000IwX-D5 for namedroppers-data@psg.com; Thu, 28 Apr 2005 15:48:18 +0000 Received: from [195.54.233.67] (helo=shaun.rfc1035.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DRBFQ-000IwG-CQ for namedroppers@ops.ietf.org; Thu, 28 Apr 2005 15:48:16 +0000 Received: from [195.54.233.69] (gromit.rfc1035.com [195.54.233.69]) by shaun.rfc1035.com (8.12.10/8.12.10) with ESMTP id j3SFm9jQ000286; Thu, 28 Apr 2005 16:48:09 +0100 (BST) In-Reply-To: <6.2.1.2.2.20050428103217.040e2670@localhost> References: <200504281344.j3SDi1iZ005155@drugs.dv.isc.org> <6.2.1.2.2.20050428103217.040e2670@localhost> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <8df14648191342337eef7cbf35049bd2@rfc1035.com> Content-Transfer-Encoding: quoted-printable Cc: namedroppers@ops.ietf.org From: Jim Reid Subject: Re: Who hates the DNAME? Date: Thu, 28 Apr 2005 16:48:04 +0100 To: =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson_/DNSEXT__co-chair?= X-Mailer: Apple Mail (2.622) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable On Apr 28, 2005, at 15:42, =D3lafur Gu=F0mundsson /DNSEXT co-chair = wrote: > Good question, has anyone else implemented DNAME processing ? I'm fairly sure it's in the Nominum servers. -- to unsubscribe send a message to namedroppers-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 28 13:18: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 NAA05899 for ; Thu, 28 Apr 2005 13:18:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DRCas-0007YC-UT for namedroppers-data@psg.com; Thu, 28 Apr 2005 17:14:30 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DRCaj-0007Xd-5Q for namedroppers@ops.ietf.org; Thu, 28 Apr 2005 17:14:21 +0000 Received: from [81.200.65.49] (dhcp-49.wl.nominum.com [81.200.65.49]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 42E3556884; Thu, 28 Apr 2005 10:14:20 -0700 (PDT) (envelope-from david.conrad@nominum.com) In-Reply-To: <6.2.1.2.2.20050428103217.040e2670@localhost> References: <200504281344.j3SDi1iZ005155@drugs.dv.isc.org> <6.2.1.2.2.20050428103217.040e2670@localhost> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable Cc: namedroppers@ops.ietf.org From: David Conrad Subject: Re: Who hates the DNAME? Date: Thu, 28 Apr 2005 10:14:19 -0700 To: =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson_/DNSEXT_co-chair?= X-Mailer: Apple Mail (2.622) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, On Apr 28, 2005, at 7:42 AM, =D3lafur Gu=F0mundsson /DNSEXT co-chair = wrote: >> btw, how was interoperability tested with DNAME ? What was the other=20= >> (as >> in, other than BIND) implementation? > Good question, has anyone else implemented DNAME processing ? Nominum has. It works. > The choices we have in front of us regarding DNAME are: > Fix the specification > Move it to experimental (i.e. make it optional to support) > Obsolete DNAME Unless DNAME is going to be obsoleted, I believe the specification=20 should be fixed. > The first question to ask: is something like DNAME a useful feature in=20= > DNS? I believe so. > PS: in regards to feature signalling at some point it might be worth=20= > while > to create a profile of required RFC's to implement for implementations > to be compliant with "modern" DNS. I would imagine that such a profile would be a teensy bit controversial=20= and may with a bit of luck be completed before heat death of the=20 universe. Just maybe. Rgds, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Apr 28 15:49:28 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19307 for ; Thu, 28 Apr 2005 15:49:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DREwr-0002ge-6v for namedroppers-data@psg.com; Thu, 28 Apr 2005 19:45:21 +0000 Received: from [193.1.169.37] (helo=cali.ucd.ie) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DREwp-0002e5-U0 for namedroppers@ops.ietf.org; Thu, 28 Apr 2005 19:45:20 +0000 Received: from conversion-daemon.cali.ucd.ie by cali.ucd.ie (Sun Java System Messaging Server 6.1 HotFix 0.04 (built Sep 29 2004)) id <0IFO006018ZKIJ00@cali.ucd.ie> (original mail from Niall.oReilly@ucd.ie) for namedroppers@ops.ietf.org; Thu, 28 Apr 2005 20:45:18 +0100 (IST) Received: from [10.0.1.189] ([83.141.81.52]) by cali.ucd.ie (Sun Java System Messaging Server 6.1 HotFix 0.04 (built Sep 29 2004)) with ESMTPSA id <0IFO00FUG9JHS390@cali.ucd.ie>; Thu, 28 Apr 2005 20:45:18 +0100 (IST) Date: Thu, 28 Apr 2005 20:45:13 +0100 From: "Niall O'Reilly" Subject: Re: Who hates the DNAME? In-reply-to: <6.2.1.2.2.20050428103217.040e2670@localhost> To: namedroppers@ops.ietf.org Cc: "Niall O'Reilly" , =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson_/DNSEXT_co-chair?= , Edward Lewis Message-id: <7e1a44d0cbd7d268480475c74faeda02@ucd.ie> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE References: <200504281344.j3SDi1iZ005155@drugs.dv.isc.org> <6.2.1.2.2.20050428103217.040e2670@localhost> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: QUOTED-PRINTABLE On 28 Apr 2005, at 15:42, =D3lafur Gu=F0mundsson /DNSEXT co-chair wro= te: > The first question to ask: is something like DNAME a useful feature= in=20 > DNS? Yes, definitely. On 28 Apr 2005, at 16:29, Edward Lewis wrote: > I'd like to hear cases for the DNAME, and cases where it has proven= to=20 > be a big help. I've found it operationally useful for consolidating the administrati= on of scattered parts of both the in-addr.arpa and e164.arpa hierarchies into a single zone file (=E0 la RFC2317, but for shorter prefixes tha= n=20 /24). For an example, dig 1.7.0.2.6.1.7.1.3.5.3.e164.arpa. naptr To my mind, using $GENERATE or creating numbers of zone files contain= ing 256 or 65536 CNAME records is considerably uglier, and creating lots = of delegation points with paired configuration entries and microzone fil= es, worse again. /Niall -- to unsubscribe send a message to namedroppers-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 28 15:49:30 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19328 for ; Thu, 28 Apr 2005 15:49:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DREwQ-0002Vk-Ko for namedroppers-data@psg.com; Thu, 28 Apr 2005 19:44:54 +0000 Received: from [66.163.169.227] (helo=smtp107.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DREwO-0002VU-Qi for namedroppers@ops.ietf.org; Thu, 28 Apr 2005 19:44:52 +0000 Received: from unknown (HELO phred.yahoo.com) (david?macquigg@216.183.69.14 with login) by smtp107.mail.sc5.yahoo.com with SMTP; 28 Apr 2005 19:44:52 -0000 Message-Id: <5.2.1.1.0.20050428111134.04408c70@mail.gainbroadband.com> X-Sender: david_macquigg@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 28 Apr 2005 12:45:40 -0700 To: namedroppers@ops.ietf.org From: David MacQuigg Subject: Email Authentication - Minimizing the Risk to DNS Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_40 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I'm preparing a draft for IETF. Before submitting it, I would like to get some feedback from people familiar with DNS. I've had some discussion on lists with email-authentication experts, but it is hard to get good answers on questions like - What are the problems with putting authentication records in their own subdomain, like _AUTH.example.com? How do we set up these records so they are no more of a problem than any other services supported by DNS. Abstract Consolidating email authentication information into one DNS record at a standard location can avoid the threat of abuse facing IP-based authentication methods. A simple, general record syntax can provide for the use of any authentication method or domain-rating service and facilitate changing methods, should that become necessary. The current draft is at http://purl.net/net/macquigg/email/draft-macquigg-authent-dns.htm Comments and suggestions will be appreciated. -- Dave ************************************************************ * * David MacQuigg, PhD email: david_macquigg at yahoo.com * * * IC Design Engineer phone: USA 520-721-4583 * * * * Analog Design Methodologies * * * * 9320 East Mikelyn Lane * * * * VRS Consulting, P.C. Tucson, Arizona 85710 * ************************************************************ * -- to unsubscribe send a message to namedroppers-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 28 23:59:10 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25656 for ; Thu, 28 Apr 2005 23:59:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DRMaM-0002f3-CL for namedroppers-data@psg.com; Fri, 29 Apr 2005 03:54:38 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DRMaK-0002eL-E3 for namedroppers@ops.ietf.org; Fri, 29 Apr 2005 03:54:36 +0000 Received: (qmail 908 invoked by uid 1016); 29 Apr 2005 03:54:59 -0000 Date: 29 Apr 2005 03:54:59 -0000 Message-ID: <20050429035459.907.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: Who hates the DNAME? References: <200504281344.j3SDi1iZ005155@drugs.dv.isc.org> <6.2.1.2.2.20050428103217.040e2670@localhost> <7e1a44d0cbd7d268480475c74faeda02@ucd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Niall O'Reilly writes: > To my mind, using $GENERATE or creating numbers of zone files containing > 256 or 65536 CNAME records is considerably uglier You're having trouble configuring your computer. This is not an Internet protocol problem. Your computer is not having trouble communicating with DNS clients. You should not be asking for changes in the DNS protocol; you should be complaining to whoever wrote your server software. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 29 05:43: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 FAA08157 for ; Fri, 29 Apr 2005 05:43:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DRRwe-000HoH-2g for namedroppers-data@psg.com; Fri, 29 Apr 2005 09:38:00 +0000 Received: from [193.1.169.37] (helo=cali.ucd.ie) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DRRwS-000HkT-Ar for namedroppers@ops.ietf.org; Fri, 29 Apr 2005 09:37:48 +0000 Received: from conversion-daemon.cali.ucd.ie by cali.ucd.ie (Sun Java System Messaging Server 6.1 HotFix 0.04 (built Sep 29 2004)) id <0IFP00E01BPC7W00@cali.ucd.ie> (original mail from niall.oreilly@ucd.ie) for namedroppers@ops.ietf.org; Fri, 29 Apr 2005 10:37:47 +0100 (IST) Received: from [10.0.1.189] ([83.141.81.52]) by cali.ucd.ie (Sun Java System Messaging Server 6.1 HotFix 0.04 (built Sep 29 2004)) with ESMTPSA id <0IFP007UJC2WNZ60@cali.ucd.ie>; Fri, 29 Apr 2005 10:37:46 +0100 (IST) Date: Fri, 29 Apr 2005 08:30:15 +0100 From: "Niall O'Reilly" Subject: Re: Who hates the DNAME? In-reply-to: <20050429035459.907.qmail@cr.yp.to> To: "D. J. Bernstein" Cc: "Niall O'Reilly" , namedroppers@ops.ietf.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT References: <200504281344.j3SDi1iZ005155@drugs.dv.isc.org> <6.2.1.2.2.20050428103217.040e2670@localhost> <7e1a44d0cbd7d268480475c74faeda02@ucd.ie> <20050429035459.907.qmail@cr.yp.to> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On 29 Apr 2005, at 04:54, D. J. Bernstein wrote: > You should not be asking for changes in the DNS protocol; Agreed. I'm not. I'm arguing against downgrading an existing and useful protocol element to "experimental". Best regards, Niall O'Reilly University College Dublin Computing Services PGP key ID: AE995ED9 (see www.pgp.net) Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9 -- to unsubscribe send a message to namedroppers-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 29 06:28: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 GAA10535 for ; Fri, 29 Apr 2005 06:28:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DRSh6-000PJR-0Y for namedroppers-data@psg.com; Fri, 29 Apr 2005 10:26:00 +0000 Received: from [204.152.189.154] (helo=gusto.araneus.fi) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DRSh3-000PJA-43 for namedroppers@ops.ietf.org; Fri, 29 Apr 2005 10:25:57 +0000 Received: from guava.araneus.fi ([195.238.197.162]) by gusto.araneus.fi (8.12.10/8.12.10) with ESMTP id j3TAPeqX001727; Fri, 29 Apr 2005 03:25:40 -0700 (PDT) Received: from guava.araneus.fi (localhost [127.0.0.1]) by guava.araneus.fi (8.12.10/8.11.6) with ESMTP id j3TAPiLG019476; Fri, 29 Apr 2005 13:25:44 +0300 (EEST) Received: (from gson@localhost) by guava.araneus.fi (8.12.10/8.12.6/Submit) id j3TAPimD026268; Fri, 29 Apr 2005 13:25:44 +0300 (EEST) Date: Fri, 29 Apr 2005 13:25:44 +0300 (EEST) Message-Id: <200504291025.j3TAPimD026268@guava.araneus.fi> To: namedroppers@ops.ietf.org CC: Mark Andrews Subject: Re: Who hates the DNAME? In-Reply-To: <200504272351.j3RNp54I060718@drugs.dv.isc.org> References: <200504272351.j3RNp54I060718@drugs.dv.isc.org> X-Mailer: VM 7.17 under Emacs 21.4.1 From: gson@araneus.fi (Andreas Gustafsson) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mark Andrews gave the following helpful example of DNAME resolution: > *.example.net DNAME foo.bar > > Perform the following query sequence. > a) sub.example.net/ANY > b) www.sub.example.net/A > > Auth server: > a) sub.example.net DNAME foo.bar > b) NODATA > > Cache: > a) sub.example.net DNAME foo.bar > b) sub.example.net DNAME foo.bar + > www.sub.example.net CNAME www.foo.bar Not all caching servers will actually give the response shown on the last two lines of the example above, and it's far from clear that this response is the correct one based on the DNAME specification. Let's look at what the caching server will do in terms of the algorithm in RFC2672 section 4.2 when resolving the two queries above: > a) sub.example.net/ANY Here, the caching server will cache the record "sub.example.net DNAME foo.bar". The caching occurs in step 4a of the algorithm (not step 4d - this DNAME is simply the answer to the question, not a DNAME being redirected through to find the answer). > b) www.sub.example.net/A This is where we get into murky waters. When the caching server resolves this query, at what step of the resolver algorithm does the DNAME we just cached come into play, if any? As far as I can see, the text of RFC2672 section 4.2 doesn't say. Clearly in step 1 the answer is not in local information, so we proceed to step 2, "find the best servers to ask", but what happens in that step is unclear. I see the following possible interpretations: 1) "Finding the best servers to ask" means looking for the closest parent node with cached NS records, just as it did when DNAME was not yet invented. In this case, the cache ends up sending the "www.sub.example.net/A" query to the authoritative server which responds with a NODATA response because there is no A record at "*.example.net.". The client will get a NODATA response, not the DNAME + CNAME response Mark showed. 2) "Finding the best servers to ask" means looking for the closest parent node with cached NS records or a parent node with a cached DNAME record. If a cached DNAME is found, the SNAME is rewritten, a DNAME and optional synthetic CNAME are added to the response, and the search for the best servers is restarted at the SNAME, in a way similar to what authoritative servers do in section 4.1 step 3c. In this case, the response will be the DNAME + CNAME response Mark showed. 3) "Finding the best servers to ask" means looking for the closest parent node with cached NS records or a parent node with a DNAME record that was cached in step 4d of the algorithm (due to being involved in a rewrite), disregarding any DNAME record that was cached in step 4a (due to being the answer to a query). If the former kind of DNAME is found, we rewrite as in 2) above. In this case, the client will get a NODATA response, as in 1). The advantage of this interpretation over 1) is that it will avoid making queries to the authoritative servers in some situations where a server doing 1) would make them. Of these interpretations, 1) seems closest to the letter of RFC2672, but I don't know any implementation using it. BIND 9 does 2), and Nominum CNS does 3). I would argue that the inconsistency between the responses from the authoritative and caching server in Mark's example indicates a problem with the BIND 9 implementation, not a problem with the DNAME specification. A server implementing the specification literally (as in case 1 above) will not exhibit the inconsistency. Also, this issue doesn't actually have anything to do with wildcards. If you replace the "*" in Mark's example with "sub", you will get exactly the same results. This of course means that outlawing wildcard DNAMEs would not eliminate the inconsistency. If this message seems familiar, it's because I sent an almost identical one in 2003 when the wildcard DNAME discussion last came up. I have just changed the domain names to refer to Mark's current example rather than the one that was used in the 2003 discussion and made some minor edits. -- Andreas Gustafsson, gson@araneus.fi -- to unsubscribe send a message to namedroppers-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 29 06:33:04 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08158 for ; Fri, 29 Apr 2005 05:43:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DRRwU-000Hl4-Jb for namedroppers-data@psg.com; Fri, 29 Apr 2005 09:37:50 +0000 Received: from [193.1.169.37] (helo=cali.ucd.ie) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DRRwS-000HkT-01 for namedroppers@ops.ietf.org; Fri, 29 Apr 2005 09:37:48 +0000 Received: from conversion-daemon.cali.ucd.ie by cali.ucd.ie (Sun Java System Messaging Server 6.1 HotFix 0.04 (built Sep 29 2004)) id <0IFP00E01BPC7W00@cali.ucd.ie> (original mail from niall.oreilly@ucd.ie) for namedroppers@ops.ietf.org; Fri, 29 Apr 2005 10:37:46 +0100 (IST) Received: from [10.0.1.189] ([83.141.81.52]) by cali.ucd.ie (Sun Java System Messaging Server 6.1 HotFix 0.04 (built Sep 29 2004)) with ESMTPSA id <0IFP007UJC2WNZ60@cali.ucd.ie>; Fri, 29 Apr 2005 10:37:45 +0100 (IST) Date: Fri, 29 Apr 2005 08:44:07 +0100 From: "Niall O'Reilly" Subject: Re: Who hates the DNAME? In-reply-to: <20050429035459.907.qmail@cr.yp.to> To: "D. J. Bernstein" Cc: "Niall O'Reilly" , namedroppers@ops.ietf.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT References: <200504281344.j3SDi1iZ005155@drugs.dv.isc.org> <6.2.1.2.2.20050428103217.040e2670@localhost> <7e1a44d0cbd7d268480475c74faeda02@ucd.ie> <20050429035459.907.qmail@cr.yp.to> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On 29 Apr 2005, at 04:54, D. J. Bernstein wrote: > you should be complaining to whoever wrote your server software. Dan, To quote a comedy TV series from my part of the world: "That would be an ecumenical issue". Let's keep such discussions off-list. /Niall -- to unsubscribe send a message to namedroppers-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 29 06:54:48 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12068 for ; Fri, 29 Apr 2005 06:54:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DRT5f-00030E-Kr for namedroppers-data@psg.com; Fri, 29 Apr 2005 10:51:23 +0000 Received: from [204.152.189.154] (helo=gusto.araneus.fi) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DRT5e-0002zx-3p for namedroppers@ops.ietf.org; Fri, 29 Apr 2005 10:51:22 +0000 Received: from guava.araneus.fi ([195.238.197.162]) by gusto.araneus.fi (8.12.10/8.12.10) with ESMTP id j3TAp8qX019609; Fri, 29 Apr 2005 03:51:09 -0700 (PDT) Received: from guava.araneus.fi (localhost [127.0.0.1]) by guava.araneus.fi (8.12.10/8.11.6) with ESMTP id j3TApDLG019499; Fri, 29 Apr 2005 13:51:13 +0300 (EEST) Received: (from gson@localhost) by guava.araneus.fi (8.12.10/8.12.6/Submit) id j3TApDQk017289; Fri, 29 Apr 2005 13:51:13 +0300 (EEST) Date: Fri, 29 Apr 2005 13:51:13 +0300 (EEST) Message-Id: <200504291051.j3TApDQk017289@guava.araneus.fi> To: gson@araneus.fi (Andreas Gustafsson) To: namedroppers@ops.ietf.org CC: Mark Andrews Subject: Re: Who hates the DNAME? In-Reply-To: <200504291025.j3TAPimD026268@guava.araneus.fi> References: <200504272351.j3RNp54I060718@drugs.dv.isc.org> <200504291025.j3TAPimD026268@guava.araneus.fi> X-Mailer: VM 7.17 under Emacs 21.4.1 From: gson@araneus.fi (Andreas Gustafsson) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk A small correction to my previous message... I said: > If you replace the "*" in Mark's example with "sub", you will get > exactly the same results. Actually, you won't. Mea culpa. Although the question of how cached DNAMEs affect the resolution algorithm applies equally to DNAMEs that resulted from wildcard expansion and ones that don't, the specific inconsistency Mark showed only happens in the wildcard case. -- Andreas Gustafsson, gson@araneus.fi -- to unsubscribe send a message to namedroppers-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 29 15:19:30 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00929 for ; Fri, 29 Apr 2005 15:19:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DRauz-000Mkn-PX for namedroppers-data@psg.com; Fri, 29 Apr 2005 19:12:53 +0000 Received: from [66.163.169.225] (helo=smtp105.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DRaux-000MkU-Rp for namedroppers@ops.ietf.org; Fri, 29 Apr 2005 19:12:51 +0000 Received: from unknown (HELO phred.yahoo.com) (david?macquigg@216.183.69.33 with login) by smtp105.mail.sc5.yahoo.com with SMTP; 29 Apr 2005 19:12:50 -0000 Message-Id: <5.2.1.1.0.20050428185130.03daf168@pop.mail.yahoo.com> X-Sender: david_macquigg@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 29 Apr 2005 11:44:40 -0700 To: namedroppers@ops.ietf.org From: David MacQuigg Subject: Re: Email Authentication - Minimizing the Risk to DNS In-Reply-To: <5.2.1.1.0.20050428111134.04408c70@mail.gainbroadband.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk That abstract was a bit terse. I should have included the Introduction. See below. Is anyone interested in this topic? It seems to me that DNS has a key role to play in solving an important problem. Existing methods have not done a good job of minimizing the risk to DNS. The folks working on email authentication don't know DNS very well (nor do I). They could use some help from experts who are not part of one or another warring camp, but just want to see the interface to DNS done right. -- Dave 1. Introduction A fundamental requirement of any email authentication method is that it not create any new opportunities for Denial-of-Service ( DoS ) attacks or abuse of the Internet infrastructure. IP-based authentication methods are particularly vulnerable, because they require at least one query to the Domain Name System ( DNS ) by a Mail Transfer Agent ( MTA ) within each domain handling an email. Some of the current methods require multiple queries per MTA. Many DNS servers are old, slow, but reliable machines, intended to answer only occasional queries from other domains, and very dependent on name servers in those other domains to cache the answers and handle the vast majority of queries locally. A typical query by an Internet Service Provider ( ISP ) for the address of a web page might be cached for days, and during that time, provide local answers to 1000 similar queries. In requesting the support of DNS for email authentication, we must anticipate not just the increase in DNS load under normal circumstances, but what may happen in worst-case scenarios, when configurations are deliberately set up for abuse. We have to be especially careful about possible involvement of "third parties", i.e. those not involved in sending or receiving an email. Planning for this abuse is difficult, because we have to think about complex and unlikely scenarios. If there is a one-in-ten chance of a successful attack, we have to take it seriously, and design for this worst case. We also have to avoid demanding so much of the new authentication methods, that no solution is possible. We must compare the potential costs, including the upgrade of DNS servers and a small possibility of DoS attack, to the real and present costs of continued email abuse. No method will avoid all possibility of abuse. Even the current uses of DNS for non-email services can be abused. A reasonable goal for new services is that the DNS load be comparable in magnitude and risk to the load from current services. If it is not possible to meet this goal, then perhaps authentication queries should be handled by servers separate from those providing other critical DNS services. A well-planned authentication system should allow for rapid migration to such separate servers. At 12:45 PM 4/28/2005 -0700, David MacQuigg wrote: >I'm preparing a draft for IETF. Before submitting it, I would like to get >some feedback from people familiar with DNS. I've had some discussion on >lists with email-authentication experts, but it is hard to get good >answers on questions like - What are the problems with putting >authentication records in their own subdomain, like >_AUTH.example.com? How do we set up these records so they are no more of >a problem than any other services supported by DNS. > >Abstract >Consolidating email authentication information into one DNS record at a >standard location can avoid the threat of abuse facing IP-based >authentication methods. A simple, general record syntax can provide for >the use of any authentication method or domain-rating service and >facilitate changing methods, should that become necessary. > >The current draft is at >http://purl.net/net/macquigg/email/draft-macquigg-authent-dns.htm > >Comments and suggestions will be appreciated. > >-- >Dave > >************************************************************ * >* David MacQuigg, PhD email: david_macquigg at yahoo.com * * >* IC Design Engineer phone: USA 520-721-4583 * * * >* Analog Design Methodologies * * * >* 9320 East Mikelyn Lane * * * >* VRS Consulting, P.C. Tucson, Arizona 85710 * >************************************************************ * -- to unsubscribe send a message to namedroppers-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 29 16:08:10 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00928 for ; Fri, 29 Apr 2005 15:19:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DRaw7-000MzM-Qt for namedroppers-data@psg.com; Fri, 29 Apr 2005 19:14:03 +0000 Received: from [66.163.169.223] (helo=smtp104.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DRaw6-000MyA-15 for namedroppers@ops.ietf.org; Fri, 29 Apr 2005 19:14:02 +0000 Received: from unknown (HELO phred.yahoo.com) (david?macquigg@216.183.69.33 with login) by smtp104.mail.sc5.yahoo.com with SMTP; 29 Apr 2005 19:14:01 -0000 Message-Id: <5.2.1.1.0.20050429120623.03dbbd50@pop.mail.yahoo.com> X-Sender: david_macquigg@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 29 Apr 2005 12:15:12 -0700 To: namedroppers@ops.ietf.org From: David MacQuigg Subject: Re: Email Authentication - Minimizing the Risk to DNS In-Reply-To: <5.2.1.1.0.20050428111134.04408c70@mail.gainbroadband.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward, Thanks for the heads up. Yes, I'm aware of the MARID problems, and the need to not repeat mistakes of the past. The essential difference in this new effort is that we won't try to standardize everything, just a few very simple items. I am seeing resistance from the advocates on every side, and at some point we may need a referee. I'm hoping that referee will be the IETF, but it could also be the FTC. They have a mandate from Congress, they can hire neutral experts, and they know how to deal with advocacy. I'm hoping to get some good advice and less hard-core advocacy from this group, at least on the DNS issues. Of the items needing standardization, this is the toughest. -- Dave At 10:37 PM 4/28/2005 -0400, Edward Lewis wrote (quoted with permission): >Not to squash any ideas (I've not read you draft), but in case you aren't >already aware of this group and it's history you might want to look into this: > >http://ietf.org/html.charters/OLD/marid-charter.html > >The group failed to meet its objectives ...not a comment on the work, but >on the mess it devolved into. Yet, it does cover some of the same ground >your message hints at. > >Emphasizing that I am only sending this as a reference to prior work, not >as a commentary of any of you effort. > >At 12:45 -0700 4/28/05, David MacQuigg wrote: >>I'm preparing a draft for IETF. Before submitting it, I would like to >>get some feedback from people familiar with DNS. I've had some >>discussion on lists with email-authentication experts, but it is hard to >>get good answers on questions like - What are the problems with putting >>authentication records in their own subdomain, like >>_AUTH.example.com? How do we set up these records so they are no more of >>a problem than any other services supported by DNS. >> >>Abstract >>Consolidating email authentication information into one DNS record at a >>standard location can avoid the threat of abuse facing IP-based >>authentication methods. A simple, general record syntax can provide for >>the use of any authentication method or domain-rating service and >>facilitate changing methods, should that become necessary. >> >>The current draft is at >>http://purl.net/net/macquigg/email/draft-macquigg-authent-dns.htm >> >>Comments and suggestions will be appreciated. >> >>-- >>Dave >> >>************************************************************ * >>* David MacQuigg, PhD email: david_macquigg at yahoo.com * * >>* IC Design Engineer phone: USA 520-721-4583 * * * >>* Analog Design Methodologies * * * >>* 9320 East Mikelyn Lane * * * >>* VRS Consulting, P.C. Tucson, Arizona 85710 * >>************************************************************ * -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Apr 30 02:05: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 CAA27354 for ; Sat, 30 Apr 2005 02:05:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DRl0d-0006hB-1R for namedroppers-data@psg.com; Sat, 30 Apr 2005 05:59:23 +0000 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1DRl0a-0006gW-0U for namedroppers@ops.ietf.org; Sat, 30 Apr 2005 05:59:20 +0000 Received: from dakota.av8.net (dakota.av8.net [130.105.19.131]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id j3U5xFXL009941 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 30 Apr 2005 01:59:16 -0400 Date: Sat, 30 Apr 2005 01:59:14 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: David MacQuigg cc: namedroppers@ops.ietf.org Subject: Re: Email Authentication - Minimizing the Risk to DNS In-Reply-To: <5.2.1.1.0.20050428111134.04408c70@mail.gainbroadband.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The problem is that DNS isn't suitable for authentication. It isn't secure itself. But you should refer to the MARID archives, where these issues were discussed very thoroughly before writing a new draft. Email authentication, even if possible by some other method, doesn't solve the problem, since it is the equivalent of dialup problem: Every user is authorized to send email until they aren't. Only their service provider can remove that authorization Lack of identification is not actually a problem. On every spam, there is attached a time and IP address of the abuser. After appropriate investigation, their service provider may terminate their account. That takes time. They may receive warnings. They may have virus infections using their identity. Further, email is not sent by only real people. It is sent frequently by computers, pagers, routers, refrigerators, you name it. It is a mistake to assume that an email is sent by a person, and that you (a remote user, recipient of their email) can find out who they are. You can't do that any more than you can find out the name and address or phone number of someone who called you with Caller-ID blocked. That doesn't mean they can't be found, it just means that ordinary users can't do it. That feature will not change, any more than you are likely to be granted access to the E911 or subscriber database of another carrier. So, given that you've found out Paris Hilton's email address, you are not going to be given her home phone number. So email authentication is not a solution to a problem. The people "frustrated" by email identity issues are usually recipients of spam. Email authentication isn't going to lessen that. Even if it were do-able (and done), end-users and other carriers wouldn't have access to the subscriber identity information. And if they are your subscriber, you usually don't have any lack of identity information given a spam and its headers. --Dean On Thu, 28 Apr 2005, David MacQuigg wrote: > I'm preparing a draft for IETF. Before submitting it, I would like to get > some feedback from people familiar with DNS. I've had some discussion on > lists with email-authentication experts, but it is hard to get good answers > on questions like - What are the problems with putting authentication > records in their own subdomain, like _AUTH.example.com? How do we set up > these records so they are no more of a problem than any other services > supported by DNS. > > Abstract > Consolidating email authentication information into one DNS record at a > standard location can avoid the threat of abuse facing IP-based > authentication methods. A simple, general record syntax can provide for > the use of any authentication method or domain-rating service and > facilitate changing methods, should that become necessary. > > The current draft is at > http://purl.net/net/macquigg/email/draft-macquigg-authent-dns.htm > > Comments and suggestions will be appreciated. > > -- > Dave > > ************************************************************ * > * David MacQuigg, PhD email: david_macquigg at yahoo.com * * > * IC Design Engineer phone: USA 520-721-4583 * * * > * Analog Design Methodologies * * * > * 9320 East Mikelyn Lane * * * > * VRS Consulting, P.C. Tucson, Arizona 85710 * > ************************************************************ * > > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Apr 30 07:59: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 HAA29860 for ; Sat, 30 Apr 2005 07:59:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DRqZQ-0004C1-I9 for namedroppers-data@psg.com; Sat, 30 Apr 2005 11:55:40 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DRqZO-0004BL-TZ for namedroppers@ops.ietf.org; Sat, 30 Apr 2005 11:55:39 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id j3UBtbKN024800; Sat, 30 Apr 2005 11:55:37 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id j3UBtXB7024797; Sat, 30 Apr 2005 11:55:33 GMT Date: Sat, 30 Apr 2005 11:55:33 +0000 From: bmanning@vacation.karoshi.com To: "Niall O'Reilly" Cc: "D. J. Bernstein" , namedroppers@ops.ietf.org Subject: Re: Who hates the DNAME? Message-ID: <20050430115533.GC24529@vacation.karoshi.com.> References: <200504281344.j3SDi1iZ005155@drugs.dv.isc.org> <6.2.1.2.2.20050428103217.040e2670@localhost> <7e1a44d0cbd7d268480475c74faeda02@ucd.ie> <20050429035459.907.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, Apr 29, 2005 at 08:30:15AM +0100, Niall O'Reilly wrote: > > On 29 Apr 2005, at 04:54, D. J. Bernstein wrote: > > >You should not be asking for changes in the DNS protocol; > > Agreed. I'm not. I'm arguing against downgrading an > existing and useful protocol element to "experimental". > > Best regards, > > Niall O'Reilly > University College Dublin Computing Services er... at what point did "experimental" == "downgrade" --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Apr 30 08:01: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 IAA29992 for ; Sat, 30 Apr 2005 08:01:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DRqdC-0004jC-PH for namedroppers-data@psg.com; Sat, 30 Apr 2005 11:59:34 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DRqd9-0004iq-K1 for namedroppers@ops.ietf.org; Sat, 30 Apr 2005 11:59:32 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id j3UBxTKN024817; Sat, 30 Apr 2005 11:59:29 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id j3UBxOFC024814; Sat, 30 Apr 2005 11:59:24 GMT Date: Sat, 30 Apr 2005 11:59:24 +0000 From: bmanning@vacation.karoshi.com To: Andreas Gustafsson Cc: namedroppers@ops.ietf.org, Mark Andrews Subject: Re: Who hates the DNAME? Message-ID: <20050430115924.GD24529@vacation.karoshi.com.> References: <200504272351.j3RNp54I060718@drugs.dv.isc.org> <200504291025.j3TAPimD026268@guava.araneus.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504291025.j3TAPimD026268@guava.araneus.fi> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk thank you andreas. it is clear that the beahviour of the caching engine is underspecified here and needs work. I think that option one is the correct behaviour - but since caches are woefully underspecifed, we get into nasty interoperability problems. --bill On Fri, Apr 29, 2005 at 01:25:44PM +0300, Andreas Gustafsson wrote: > Mark Andrews gave the following helpful example of DNAME resolution: > > > *.example.net DNAME foo.bar > > > > Perform the following query sequence. > > a) sub.example.net/ANY > > b) www.sub.example.net/A > > > > Auth server: > > a) sub.example.net DNAME foo.bar > > b) NODATA > > > > Cache: > > a) sub.example.net DNAME foo.bar > > b) sub.example.net DNAME foo.bar + > > www.sub.example.net CNAME www.foo.bar > > Not all caching servers will actually give the response shown on the > last two lines of the example above, and it's far from clear that this > response is the correct one based on the DNAME specification. > > Let's look at what the caching server will do in terms of the > algorithm in RFC2672 section 4.2 when resolving the two queries above: > > > a) sub.example.net/ANY > > Here, the caching server will cache the record "sub.example.net > DNAME foo.bar". The caching occurs in step 4a of the algorithm > (not step 4d - this DNAME is simply the answer to the question, > not a DNAME being redirected through to find the answer). > > > b) www.sub.example.net/A > > This is where we get into murky waters. When the caching server > resolves this query, at what step of the resolver algorithm does the > DNAME we just cached come into play, if any? > > As far as I can see, the text of RFC2672 section 4.2 doesn't say. > Clearly in step 1 the answer is not in local information, so we > proceed to step 2, "find the best servers to ask", but what happens in > that step is unclear. I see the following possible interpretations: > > 1) "Finding the best servers to ask" means looking for the closest > parent node with cached NS records, just as it did when DNAME was > not yet invented. > > In this case, the cache ends up sending the "www.sub.example.net/A" > query to the authoritative server which responds with a > NODATA response because there is no A record at "*.example.net.". > The client will get a NODATA response, not the DNAME + CNAME response > Mark showed. > > 2) "Finding the best servers to ask" means looking for the closest > parent node with cached NS records or a parent node with a cached > DNAME record. If a cached DNAME is found, the SNAME is > rewritten, a DNAME and optional synthetic CNAME are added to the > response, and the search for the best servers is restarted at the > SNAME, in a way similar to what authoritative servers do in > section 4.1 step 3c. > > In this case, the response will be the DNAME + CNAME response > Mark showed. > > 3) "Finding the best servers to ask" means looking for the closest > parent node with cached NS records or a parent node with a DNAME > record that was cached in step 4d of the algorithm (due to being > involved in a rewrite), disregarding any DNAME record that was > cached in step 4a (due to being the answer to a query). > If the former kind of DNAME is found, we rewrite as in 2) above. > > In this case, the client will get a NODATA response, as in 1). > The advantage of this interpretation over 1) is that it will avoid > making queries to the authoritative servers in some situations where > a server doing 1) would make them. > > Of these interpretations, 1) seems closest to the letter of RFC2672, > but I don't know any implementation using it. BIND 9 does 2), and > Nominum CNS does 3). > > I would argue that the inconsistency between the responses from the > authoritative and caching server in Mark's example indicates a > problem with the BIND 9 implementation, not a problem with the DNAME > specification. A server implementing the specification literally (as > in case 1 above) will not exhibit the inconsistency. > > Also, this issue doesn't actually have anything to do with wildcards. > If you replace the "*" in Mark's example with "sub", you will get > exactly the same results. This of course means that outlawing > wildcard DNAMEs would not eliminate the inconsistency. > > If this message seems familiar, it's because I sent an almost > identical one in 2003 when the wildcard DNAME discussion last came up. > I have just changed the domain names to refer to Mark's current > example rather than the one that was used in the 2003 discussion and > made some minor edits. > -- > Andreas Gustafsson, gson@araneus.fi > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Apr 30 08:46: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 IAA02706 for ; Sat, 30 Apr 2005 08:46:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DRrKO-000CFu-7V for namedroppers-data@psg.com; Sat, 30 Apr 2005 12:44:12 +0000 Received: from [193.1.169.34] (helo=dakota.ucd.ie) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DRrKL-000CFb-5K for namedroppers@ops.ietf.org; Sat, 30 Apr 2005 12:44:09 +0000 Received: from conversion-daemon.dakota.ucd.ie by dakota.ucd.ie (Sun Java System Messaging Server 6.1 HotFix 0.04 (built Sep 29 2004)) id <0IFR00B01ED2TW00@dakota.ucd.ie> (original mail from Niall.oReilly@ucd.ie) for namedroppers@ops.ietf.org; Sat, 30 Apr 2005 13:44:08 +0100 (IST) Received: from [10.0.1.189] ([83.141.81.52]) by dakota.ucd.ie (Sun Java System Messaging Server 6.1 HotFix 0.04 (built Sep 29 2004)) with ESMTPSA id <0IFR00395FDJUBC0@dakota.ucd.ie>; Sat, 30 Apr 2005 13:44:07 +0100 (IST) Date: Sat, 30 Apr 2005 13:44:07 +0100 From: "Niall O'Reilly" Subject: Re: Who hates the DNAME? In-reply-to: <20050430115533.GC24529@vacation.karoshi.com> To: bmanning@vacation.karoshi.com Cc: "Niall O'Reilly" , "D. J. Bernstein" , namedroppers@ops.ietf.org Message-id: <99ea293623712630670a49e4ea68a541@ucd.ie> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT References: <200504281344.j3SDi1iZ005155@drugs.dv.isc.org> <6.2.1.2.2.20050428103217.040e2670@localhost> <7e1a44d0cbd7d268480475c74faeda02@ucd.ie> <20050429035459.907.qmail@cr.yp.to> <20050430115533.GC24529@vacation.karoshi.com> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On 30 Apr 2005, at 12:55, bmanning@vacation.karoshi.com wrote: > er... at what point did "experimental" == "downgrade" Fair point. Ed's slogan applies: If you knew what I was thinking, you'd understand what I was saying. /Niall -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: