From owner-namedroppers@ops.ietf.org Tue Feb 1 02:40:37 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22668 for ; Tue, 1 Feb 2005 02:40:36 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CvsZ3-000GOQ-Nd for namedroppers-data@psg.com; Tue, 01 Feb 2005 07:35:09 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CvsZ1-000GO5-92 for namedroppers@ops.ietf.org; Tue, 01 Feb 2005 07:35:07 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 6622525643; Tue, 1 Feb 2005 08:35:06 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 6E99025594 for ; Tue, 1 Feb 2005 08:35:02 +0100 (CET) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id j117Z2et011788 for ; Tue, 1 Feb 2005 08:35:02 +0100 Received: (from olaf@localhost) by x50.ripe.net (8.12.10/8.12.6) id j117Z1XH028823 for namedroppers@ops.ietf.org; Tue, 1 Feb 2005 08:35:01 +0100 Date: Tue, 1 Feb 2005 08:35:01 +0100 From: Olaf Kolkman Message-Id: <200502010735.j117Z1XH028823@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: 825c6ec87d09b8382043db5c65718cfd 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 - 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 Tue Feb 1 18:50: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 SAA17231 for ; Tue, 1 Feb 2005 18:50:56 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Cw7h1-000AQc-Bo for namedroppers-data@psg.com; Tue, 01 Feb 2005 23:44:23 +0000 Received: from [132.151.6.71] (helo=megatron.ietf.org) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Cw7gz-000AQL-LA for namedroppers@ops.ietf.org; Tue, 01 Feb 2005 23:44:21 +0000 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1Cw7fp-0001va-NZ; Tue, 01 Feb 2005 18:43:09 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Subject: Last Call: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard Reply-to: iesg@ietf.org CC: Message-Id: Date: Tue, 01 Feb 2005 18:43:09 -0500 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 The IESG has received a request from the DNS Extensions WG to consider the following document: - 'Domain Name System (DNS) Case Insensitivity Clarification ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-02-15. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dnsext-insensitive-05.txt -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 1 23:46: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 XAA25964 for ; Tue, 1 Feb 2005 23:46:51 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CwCJ4-000Nld-4A for namedroppers-data@psg.com; Wed, 02 Feb 2005 04:39:58 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CwCJ0-000NlI-6i for namedroppers@ops.ietf.org; Wed, 02 Feb 2005 04:39:54 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id j124djKN008170; Wed, 2 Feb 2005 04:39:45 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id j124dhw2008167; Wed, 2 Feb 2005 04:39:43 GMT Date: Wed, 2 Feb 2005 04:39:43 +0000 From: bmanning@vacation.karoshi.com To: iesg@ietf.org Cc: IETF-Announce , namedroppers@ops.ietf.org Subject: Re: Last Call: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard Message-ID: <20050202043943.GA8153@vacation.karoshi.com.> References: 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.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk fast track eh? its very helpful of the IESG to consider this proposed standard at this time when the WG has not seen the material. the ID was released -today-.... perhaps you would consider that some folks might like to read said document and consider it -before- placing it on the fast track. Or is this one in some special way unique so that it is being rushed through? Olaf/Olafur, whats up w/ this? On Tue, Feb 01, 2005 at 06:43:09PM -0500, The IESG wrote: > The IESG has received a request from the DNS Extensions WG to consider the > following document: > > - 'Domain Name System (DNS) Case Insensitivity Clarification ' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2005-02-15. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-insensitive-05.txt > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 2 03:13: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 DAA13941 for ; Wed, 2 Feb 2005 03:13:46 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CwFaC-000Nbz-Hy for namedroppers-data@psg.com; Wed, 02 Feb 2005 08:09:52 +0000 Received: from [202.12.73.115] (helo=delta.noi.kre.to) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CwFa8-000Nak-8q for namedroppers@ops.ietf.org; Wed, 02 Feb 2005 08:09:48 +0000 Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.11/8.11.6) with ESMTP id j127i3ix022711; Wed, 2 Feb 2005 14:44:03 +0700 (ICT) From: Robert Elz To: bmanning@vacation.karoshi.com cc: iesg@ietf.org, IETF-Announce , namedroppers@ops.ietf.org Subject: Re: Last Call: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard In-Reply-To: <20050202043943.GA8153@vacation.karoshi.com.> References: <20050202043943.GA8153@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 02 Feb 2005 14:44:03 +0700 Message-ID: <11972.1107330243@munnari.OZ.AU> 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 Date: Wed, 2 Feb 2005 04:39:43 +0000 From: bmanning@vacation.karoshi.com Message-ID: <20050202043943.GA8153@vacation.karoshi.com.> | fast track eh? its very helpful of the IESG to consider this proposed | standard at this time when the WG has not seen the material. the ID was | released -today-.... perhaps you would consider that some folks might like | to read said document and consider it -before- placing it on the fast track. | Or is this one in some special way unique so that it is being rushed through? Huh? Slow track more likely. The request for the last call on this was sent last November, so it has taken almost 3 months for the last call to get issued. Of course, events seem to have made clear why - the last call request was for the -04 version, it seems that someone decided they needed to wait for a new version to appear - as soon as that appeared, the last call was dispatched (as I recall, that is even semi-automated - the fact that the draft appears causes the last call to be transmitted, without much in the way of oversight of the process). None of this is unusual at all. In this case, what may be considered unusual, is that there has been no mention on the namedroppers list of the need for the -05 draft, nothing about what required it, and nothing about what has changed in it. Maybe the draft says that - but if it is the version that is to be published as an RFC, it shouldn't (RFCs should not contain info about what changed in the last few versions of the I-D, nor should they be having that kind of information editorially deleted after approval). kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 2 08:52: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 IAA03905 for ; Wed, 2 Feb 2005 08:52:55 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CwKrw-000IBm-0w for namedroppers-data@psg.com; Wed, 02 Feb 2005 13:48:32 +0000 Received: from [204.127.198.39] (helo=rwcrmhc13.comcast.net) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CwKrt-000IBW-Sh for namedroppers@ops.ietf.org; Wed, 02 Feb 2005 13:48:29 +0000 Received: from mini.pothole.com (pothole.com[24.62.71.160]) by comcast.net (rwcrmhc13) with ESMTP id <20050202134828015009klpue>; Wed, 2 Feb 2005 13:48:29 +0000 Received: by mini.pothole.com (Postfix, from userid 1026) id 1537F7693C; Wed, 2 Feb 2005 08:48:28 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mini.pothole.com (Postfix) with ESMTP id 133FF7693B; Wed, 2 Feb 2005 08:48:28 -0500 (EST) Date: Wed, 2 Feb 2005 08:48:27 -0500 (EST) From: Donald Eastlake III X-X-Sender: donaldeastlakeiii@mini.pothole.com To: namedroppers@ops.ietf.org Cc: iesg@ietf.org Subject: Re: Last Call: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard In-Reply-To: <11972.1107330243@munnari.OZ.AU> Message-ID: References: <20050202043943.GA8153@vacation.karoshi.com.> <11972.1107330243@munnari.OZ.AU> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 draft has fairly clear notes towards the end documenting all the changes since version -02. It has been percolating slowly through the system for a LONG time, like years, due to other higher priorities in DNSEXT. The changes from -04 to -05 are, in my opinion, extremely minor and were the changes suggested by our Area Direction. Cutting and pasting from the draft they are: -04 to -05 Changes The following changes were made between draft versions -04 and -05: 1. More clearly state that this draft updates RFCs 1034, 1035 [STD 13]. 2. Add informative references to ISO 8859-1 and ISO 8859-2. 3. Fix hyphenation and capitalization nits. Thanks, Donald ==================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 155 Beaver Street +1-508-634-2066(h) +1-508-786-7554(w) Milford, MA 01757 USA Donald.Eastlake@motorola.com On Wed, 2 Feb 2005, Robert Elz wrote: > Date: Wed, 02 Feb 2005 14:44:03 +0700 > From: Robert Elz > To: bmanning@vacation.karoshi.com > Cc: iesg@ietf.org, IETF-Announce , > namedroppers@ops.ietf.org > Subject: Re: Last Call: 'Domain Name System (DNS) Case Insensitivity > Clarification' to Proposed Standard > > Date: Wed, 2 Feb 2005 04:39:43 +0000 > From: bmanning@vacation.karoshi.com > Message-ID: <20050202043943.GA8153@vacation.karoshi.com.> > > | fast track eh? its very helpful of the IESG to consider this proposed > | standard at this time when the WG has not seen the material. the ID was > | released -today-.... perhaps you would consider that some folks might like > | to read said document and consider it -before- placing it on the fast track. > | Or is this one in some special way unique so that it is being rushed through? > > Huh? > > Slow track more likely. The request for the last call on this was > sent last November, so it has taken almost 3 months for the last call > to get issued. > > Of course, events seem to have made clear why - the last call request > was for the -04 version, it seems that someone decided they needed to > wait for a new version to appear - as soon as that appeared, the last > call was dispatched (as I recall, that is even semi-automated - the > fact that the draft appears causes the last call to be transmitted, > without much in the way of oversight of the process). > > None of this is unusual at all. > > In this case, what may be considered unusual, is that there has been > no mention on the namedroppers list of the need for the -05 draft, nothing > about what required it, and nothing about what has changed in it. Maybe > the draft says that - but if it is the version that is to be published as > an RFC, it shouldn't (RFCs should not contain info about what changed > in the last few versions of the I-D, nor should they be having that kind > of information editorially deleted after approval). > > 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: > > -- to unsubscribe send a message to namedroppers-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 Feb 2 09:40:05 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09460 for ; Wed, 2 Feb 2005 09:40:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CwLbs-000Pfo-HO for namedroppers-data@psg.com; Wed, 02 Feb 2005 14:36:00 +0000 Received: from [32.97.110.130] (helo=e32.co.us.ibm.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CwLbq-000PfW-4r for namedroppers@ops.ietf.org; Wed, 02 Feb 2005 14:35:58 +0000 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j12EZtul173036 for ; Wed, 2 Feb 2005 09:35:55 -0500 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j12EZs8D414908 for ; Wed, 2 Feb 2005 07:35:54 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j12EZsSD022608 for ; Wed, 2 Feb 2005 07:35:54 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-49-147-51.mts.ibm.com [9.49.147.51]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j12EZpIi022523; Wed, 2 Feb 2005 07:35:53 -0700 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id j12EZkFp011114; Wed, 2 Feb 2005 09:35:47 -0500 Message-Id: <200502021435.j12EZkFp011114@cichlid.raleigh.ibm.com> To: bmanning@vacation.karoshi.com cc: iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: Last Call: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard In-Reply-To: Message from bmanning@vacation.karoshi.com of "Wed, 02 Feb 2005 04:39:43 GMT." <20050202043943.GA8153@vacation.karoshi.com.> Date: Wed, 02 Feb 2005 09:35:45 -0500 From: Thomas Narten 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 > fast track eh? its very helpful of the IESG to consider this proposed > standard at this time when the WG has not seen the material. the ID was > released -today-.... perhaps you would consider that some folks might like > to read said document and consider it -before- placing it on the fast track. > Or is this one in some special way unique so that it is being rushed > through? Hi Bill. The document is hardling being rushed through. WG asked that it be advanced, like back in November or so. The request was sent to the secretariat (as is the proper procedure), but the document didn't get added to ID tracker like it should have, so I didn't realize it was on my plate. When I noticed (last week), I reviewed the doc, sent some questions to the author/chairs, and the result is a new revision. I was waiting for the new version before starting the last call. You can see the specific review comments in ID tracker if you want, but they are pretty unexciting, as are the changes in the new version. Thomas -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 2 09:55: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 JAA11244 for ; Wed, 2 Feb 2005 09:55:52 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CwLrw-0002Jv-Dt for namedroppers-data@psg.com; Wed, 02 Feb 2005 14:52:36 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CwLru-0002Jd-D7 for namedroppers@ops.ietf.org; Wed, 02 Feb 2005 14:52:34 +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 j12EqOvm005823; Wed, 2 Feb 2005 09:52:24 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.2.0.14.2.20050202094133.0495e6f8@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 02 Feb 2005 09:52:23 -0500 To: bmanning@vacation.karoshi.com, iesg@ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: Last Call: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard Cc: namedroppers@ops.ietf.org In-Reply-To: <20050202043943.GA8153@vacation.karoshi.com.> References: <20050202043943.GA8153@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.49 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:39 01/02/2005, bmanning@vacation.karoshi.com wrote: > fast track eh? its very helpful of the IESG to consider this proposed >standard at this time when the WG has not seen the material. the ID was >released -today-.... perhaps you would consider that some folks might like >to read said document and consider it -before- placing it on the fast track. >Or is this one in some special way unique so that it is being rushed through? > >Olaf/Olafur, whats up w/ this? This draft was processed in the working group, last call announcement: http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01486.html But due the fact that yours truly dropped the ball, the advancement notice did not go out for over a year: http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg02064.html Then there was another delay before AD approved the draft for LC. So we ended up with 18 months from start of WG last call to start of IETF LC. The fault for this slow process is mostly mine. Olafur PS: moral ping your WG chairs regularly if they have action items. -- to unsubscribe send a message to namedroppers-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 Feb 2 12:41: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 MAA03979 for ; Wed, 2 Feb 2005 12:41:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CwORy-000PpC-4K for namedroppers-data@psg.com; Wed, 02 Feb 2005 17:37:58 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CwORw-000PoG-2v for namedroppers@ops.ietf.org; Wed, 02 Feb 2005 17:37:56 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id j12HbdKN010773; Wed, 2 Feb 2005 17:37:39 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id j12Hbd6K010769; Wed, 2 Feb 2005 17:37:39 GMT Date: Wed, 2 Feb 2005 17:37:39 +0000 From: bmanning@vacation.karoshi.com To: Robert Elz Cc: bmanning@vacation.karoshi.com, iesg@ietf.org, IETF-Announce , namedroppers@ops.ietf.org Subject: Re: Last Call: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard Message-ID: <20050202173739.GA10707@vacation.karoshi.com.> References: <20050202043943.GA8153@vacation.karoshi.com.> <11972.1107330243@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11972.1107330243@munnari.OZ.AU> User-Agent: Mutt/1.4.1i 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,NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, Feb 02, 2005 at 02:44:03PM +0700, Robert Elz wrote: > Date: Wed, 2 Feb 2005 04:39:43 +0000 > From: bmanning@vacation.karoshi.com > Message-ID: <20050202043943.GA8153@vacation.karoshi.com.> > > | fast track eh? its very helpful of the IESG to consider this proposed > | standard at this time when the WG has not seen the material. the ID was > | released -today-.... perhaps you would consider that some folks might like > | to read said document and consider it -before- placing it on the fast track. > | Or is this one in some special way unique so that it is being rushed through? > > Huh? > > Slow track more likely. The request for the last call on this was > sent last November, so it has taken almost 3 months for the last call > to get issued. Ah... that option I had not considered. Sorry for the hasty outburst. > Of course, events seem to have made clear why - the last call request > was for the -04 version, it seems that someone decided they needed to > wait for a new version to appear - as soon as that appeared, the last > call was dispatched (as I recall, that is even semi-automated - the > fact that the draft appears causes the last call to be transmitted, > without much in the way of oversight of the process). > > None of this is unusual at all. seems wrong to me, but what do i know. > In this case, what may be considered unusual, is that there has been > no mention on the namedroppers list of the need for the -05 draft, nothing > about what required it, and nothing about what has changed in it. Maybe > the draft says that - but if it is the version that is to be published as > an RFC, it shouldn't (RFCs should not contain info about what changed > in the last few versions of the I-D, nor should they be having that kind > of information editorially deleted after approval). yes. thank you for being clear. > > kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 2 17:44: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 RAA21257 for ; Wed, 2 Feb 2005 17:44:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CwTAI-000ETm-Nf for namedroppers-data@psg.com; Wed, 02 Feb 2005 22:40:02 +0000 Received: from [158.38.152.233] (helo=eikenes.alvestrand.no) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CwTAH-000ET5-SA for namedroppers@ops.ietf.org; Wed, 02 Feb 2005 22:40:02 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E39FE61BF5; Wed, 2 Feb 2005 23:40:00 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07021-08; Wed, 2 Feb 2005 23:39:59 +0100 (CET) Received: from halvestr-w2k02.emea.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3535D61C4C; Wed, 2 Feb 2005 23:39:56 +0100 (CET) Date: Wed, 02 Feb 2005 23:34:31 +0100 From: Harald Tveit Alvestrand To: Robert Elz , bmanning@vacation.karoshi.com Cc: iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: Last Call: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard Message-ID: <88EAAA4611113A9E57A00593@B50854F0A9192E8EC6CDA126> In-Reply-To: <11972.1107330243@munnari.OZ.AU> References: <20050202043943.GA8153@vacation.karoshi.com.> <11972.1107330243@munnari.OZ.AU> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no 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 2. februar 2005 14:44 +0700 Robert Elz wrote: > In this case, what may be considered unusual, is that there has been > no mention on the namedroppers list of the need for the -05 draft, nothing > about what required it, and nothing about what has changed in it. Maybe > the draft says that - but if it is the version that is to be published as > an RFC, it shouldn't (RFCs should not contain info about what changed > in the last few versions of the I-D, nor should they be having that kind > of information editorially deleted after approval). Yes, they should. -- to unsubscribe send a message to namedroppers-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 Feb 2 18: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 SAA25935 for ; Wed, 2 Feb 2005 18:23:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CwTnq-000KGX-KM for namedroppers-data@psg.com; Wed, 02 Feb 2005 23:20:54 +0000 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CwTnn-000KGE-UR for namedroppers@ops.ietf.org; Wed, 02 Feb 2005 23:20:52 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.2/8.13.2/Debian-1) with ESMTP id j12NKjD7027771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Feb 2005 00:20:46 +0100 From: Simon Josefsson To: Samuel Weiler Cc: namedroppers@ops.ietf.org Subject: Re: rfc2538bis IANA considerations References: <6.1.2.0.2.20041011160917.070d8ec0@localhost> <20041012080533.GA17012@nic.fr> <6.1.2.0.2.20041012100511.0766efd0@localhost> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:050202:weiler@tislabs.com::+C7lVDp+wNEa6tt8:0upi X-Hashcash: 1:21:050202:namedroppers@ops.ietf.org::FfuBxtWrk/Jo1E2n:3/Jb Date: Thu, 03 Feb 2005 00:20:27 +0100 In-Reply-To: (Samuel Weiler's message of "Thu, 27 Jan 2005 17:02:38 -0500 (EST)") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.80/695/Tue Feb 1 12:34:47 2005 clamav-milter version 0.80j on yxa.extundo.com X-Virus-Status: Clean 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 Hi Sam, thanks for your comments, both in private and on the list. Samuel Weiler writes: > -- Ask IANA to add a citation to 2538bis for algorithm 0 -- it's > already marked reserved, but 2538 explains why it needs to > remain reserved. You might even rename it to 'CERT RR private' > or somesuch. > > -- Ask IANA to add the CERT RR to the list of type codes that use this > registry. That may encourage the next fool who comes along and > wants to change or reuse the registry to remember CERT, as we > forgot to do in 2004. Do you think anything should go into 2538bis to achieve this? > -- Can CERTs use private algorithms (type 253/254)? If so, do you > still want to use the same encoding as for KEY/DNSKEY, with the > algorithm in the RDATA? Some explicit mention of the private > algorithms might be a good idea, in any case. Also note David > Blacka's DNSSEC experiment draft, which encourages use of > the private algorithms. I have no idea how to address this, nor can I answer the question. I hope that others will give input on this. > -- Given that 3755 added applicablility columns to the algorithm > registry (see the registry itself and 3755 for details), do you > want another column for CERT, along with a requirement that new > algorithm definitions say whether they can be used for CERTs or > not? It seem to require some work for new algorithm definers. My experience is that the key tag and algorithm fields of CERT RRs are rarely useful, nor consistently populated. So the additional work will lead to little practical advantage, in my opinion. That would suggest we shouldn't worry about this. However, this seem to be more of a process issue, than a technical concern, so I'd be interested to hear what others feel. > If you want to reuse all algorithms registers, the doc should > say that (and the registry probably should, too). Suggested > registry text for the 'reuse all' option might be: > > OLD: The KEY, SIG, DNSKEY, RRSIG, and DS RRs use an 8-bit number used > to identify the security algorithm being used. > > Some algorithms are usable only for zone signing (DNSSEC), some > only for transaction security mechanisms (SIG(0) and TSIG), and > some for both. Those usable for zone signing may appear in > DNSKEY, RRSIG, and DS RRs. Those usable for SIG(0) and TSIG may > appear in SIG and KEY RRs. > > NEW: The KEY, SIG, DNSKEY, RRSIG, DS, and CERT RRs use an 8-bit > number used to identify the security algorithm being used. > > All algorithm numbers in this registry may be used in CERT RRs. > Some algorithms are not usable for zone signing (DNSSEC) and > some are not usable for transaction security mechanisms (SIG(0) > and TSIG). Only those usable for zone signing may appear in > DNSKEY, RRSIG, and DS RRs. Only those usable for SIG(0) and > TSIG may appear in SIG and KEY RRs. Could we suggest something in the IANA section, to perhaps get IANA's attention to make this change? Suggestions appreciated. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 2 19:20:02 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00792 for ; Wed, 2 Feb 2005 19:20:01 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CwUcA-0000vy-MI for namedroppers-data@psg.com; Thu, 03 Feb 2005 00:12:54 +0000 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CwUc7-0000v7-S5 for namedroppers@ops.ietf.org; Thu, 03 Feb 2005 00:12:52 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.2/8.13.2/Debian-1) with ESMTP id j130Cjas029937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 3 Feb 2005 01:12:46 +0100 From: Simon Josefsson To: namedroppers@ops.ietf.org Subject: Re: RFC 2538bis References: <200410151949.PAA03947@ietf.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:050202:namedroppers@ops.ietf.org::5qSsgt8iSxbb6ruW:43Ci Date: Thu, 03 Feb 2005 01:12:27 +0100 In-Reply-To: (Simon Josefsson's message of "Mon, 03 Jan 2005 01:57:53 +0100") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.80/695/Tue Feb 1 12:34:47 2005 clamav-milter version 0.80j on yxa.extundo.com X-Virus-Status: Clean 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 Dear All: I received several suggestions both on the list and privately, so I have updated the document and submitted -01 to the IETF. Meanwhile it is available at: http://josefsson.org/rfc2538bis/draft-ietf-dnsext-rfc2538bis.txt I believe the document is ready for last call. More stuff, like a diff against RFC 2538, is also available: http://josefsson.org/rfc2538bis/ However, there are at least two matters that could use discussion: * This version add the "indirect" types IPKIX, ISPKI and IPGP as suggested recently to the list by Ben. I encourage the WG to consider this idea, so I can gauge consensus on it. As far as I know, it has not been implemented yet. I suspect this means we are on the PROPOSED-recycle rather than DRAFT track for 2538bis. It does solve a major practical concern with RFC 2538, so I believe the idea has merit, but remain open to any criticism. * The SPKI types. The document reads: The SPKI type is reserved to indicate a certificate formated as to be specified by the IETF SPKI working group. The SPKI WG seem to have shut down. RFC 2693 is EXPERIMENTAL, which means it could only be an information reference, if 2538bis is aiming for PROPOSED. I suggest changing the above into 'The SPKI type is reserved for use with SPKI certificates', and drop the ISPKI type. Then someone with sufficient SPKI expertise can update the document later on to say what is needed to use SPKI certificates inside CERT RRs. I think this is better than me trying to guess what might work for SPKI people. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 2 21:20: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 VAA11012 for ; Wed, 2 Feb 2005 21:20:10 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CwWY8-000HD3-5j for namedroppers-data@psg.com; Thu, 03 Feb 2005 02:16:52 +0000 Received: from [207.8.226.12] (helo=emerald.pobox.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CwWY5-000HCk-5j for namedroppers@ops.ietf.org; Thu, 03 Feb 2005 02:16:49 +0000 Received: from dumbo.pobox.com (dumbo.pobox.com [209.2.32.34]) by emerald.pobox.com (Postfix) with ESMTP id CAF5B132D16 for ; Wed, 2 Feb 2005 21:16:18 -0500 (EST) Received: by dumbo.pobox.com (Postfix, from userid 505) id D5345BDC; Wed, 2 Feb 2005 21:16:45 -0500 (EST) Date: Wed, 2 Feb 2005 21:16:45 -0500 From: Meng Weng Wong To: IETF DNSEXT WG Subject: Re: confusion caused by http://spf.pobox.com/rfcs.html Message-ID: <20050203021645.GP9946@dumbo.pobox.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i 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 ok, let me know how you feel about what's on the website now. On Thu, Jan 20, 2005 at 09:31:20AM -0600, wayne wrote: | | Hi Meng | | The web page http://spf.pobox.com/rfcs.html still lists the Lentczner | draft of Oct 2004 as the "current SPF Protocol Specification" and | still says that a "libspf2" version will be available shortly. | | I know I've asked you to update the libspf2 part last Nov, and I guess | I had assumed that you would update the "current spec" part after the | council meetings. I realize that you are very busy right now with the | EL contract stuff, but could you please update that page? It is | causing confusion in the IETF. | | Also, if you could review the current draft and tell me what needs to | be changed, I would greatly appreciate it. Again, I realize that you | are very busy right now, but if the IETF decides to advance it, | changes will be harder. | | | -wayne | -- to unsubscribe send a message to namedroppers-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 Feb 2 21:41: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 VAA12622 for ; Wed, 2 Feb 2005 21:41:53 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CwWu1-000KBa-Ep for namedroppers-data@psg.com; Thu, 03 Feb 2005 02:39:29 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CwWtz-000KBD-Q9 for namedroppers@ops.ietf.org; Thu, 03 Feb 2005 02:39:28 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.11/8.12.11) with ESMTP id j132dJB1009571 for ; Wed, 2 Feb 2005 21:39:19 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.12.11/8.12.11/Submit) id j132dJRq009570 for namedroppers@ops.ietf.org; Wed, 2 Feb 2005 21:39:19 -0500 (EST) (envelope-from namedroppers) Received: from [193.201.200.170] (helo=chiark.greenend.org.uk) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CwMkZ-000ACP-34 for namedroppers@ops.ietf.org; Wed, 02 Feb 2005 15:49:03 +0000 Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path ijackson@chiark.greenend.org.uk) id 1CwMkY-00013S-00; Wed, 02 Feb 2005 15:49:02 +0000 From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16896.63086.21842.203333@chiark.greenend.org.uk> Date: Wed, 2 Feb 2005 15:49:02 +0000 To: iesg@ietf.org Cc: IETF-Announce , namedroppers@ops.ietf.org Subject: Re: Last Call: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard Newsgroups: chiark.mail.ietf.announce In-Reply-To: References: X-Mailer: VM 7.03 under Emacs 19.34.1 X-Scanned-By: MIMEDefang 2.49 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.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: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] The IESG writes ("Last Call: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard "): > The IESG has received a request from the DNS Extensions WG to consider the > following document: > > - 'Domain Name System (DNS) Case Insensitivity Clarification ' > as a Proposed Standard I am astounded that this much-needed clarification document still fails to unambiguously specify exactly which DNS labels are to be considered equivalent ! In particular, it fails to state clearly that the results of the comparison depends only on the individual separate comparisons of corresponding octets, and it fails to give a clearly stated (and clearly stated to be exhaustive) specification of the set of equivalence classes for octets. For example, it is not 100% clear, according to draft-ietf-dnsext-insensitive-05, whether an implementation may consider 0xCC as equivalent to 0xEC. An implementor trying to defend a bizarre and ancient implementation might argue that `0xCC is upper case L with top bit set, which compares equal to 0xEC because 0xEC is lower case L with top bit set'. This appears, on the face of it, to be difficult to square with the example of 0xDD != 0xFD, but 0xDD and 0xFD are not `ASCII letters with the top bit set'. This shows the danger of attempting to specify almost entirely by example ! I suggest the addition of text along the following lines, after section 3.3: 3.4. Equivalence of label strings Two labels of type 0x0 MUST be considered equivalent if they are of the same length and every octet in one label is considered equivalent to the corresponding octet in the other label. Otherwise the labels MUST be considered and treated as different labels. A pair of octets MUST be considered equivalent according to the following rules: A. One octets is in the range 0x41-0x5A (upper case ASCII letters) and the other is in the range 0x61-0x7A (lower case ASCII letters): They MUST be considered equivalent if the octet values differ by exactly 0x20, and MUST be considered NOT equivalent if the octet values differ by some different amount. B. Any other pair of octets (ie, at least one of the two octets outside either of the two ranges in B above, or both of the octets in the same one of the two ranges in B above): They MUST be considered equivalent if their octet values are the same, and MUST be considered NOT equivalent if they differ. Ian. -- to unsubscribe send a message to namedroppers-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 Feb 2 21:42: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 VAA12662 for ; Wed, 2 Feb 2005 21:42:10 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CwWv5-000KKG-8i for namedroppers-data@psg.com; Thu, 03 Feb 2005 02:40:35 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CwWv2-000KK1-Sr for namedroppers@ops.ietf.org; Thu, 03 Feb 2005 02:40:33 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.11/8.12.11) with ESMTP id j132eOO8009585 for ; Wed, 2 Feb 2005 21:40:24 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.12.11/8.12.11/Submit) id j132eOwL009584 for namedroppers@ops.ietf.org; Wed, 2 Feb 2005 21:40:24 -0500 (EST) (envelope-from namedroppers) Received: from [207.172.4.62] (helo=smtp03.mrf.mail.rcn.net) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CwQ2Q-000Fik-UZ for namedroppers@ops.ietf.org; Wed, 02 Feb 2005 19:19:43 +0000 X-Info: This message was accepted for relay by smtp03.mrf.mail.rcn.net as the sender used SMTP authentication X-Trace: NH6hZ0M49xUvypla0f8uZiwE48+znuubZRKHvwtZpyU= Received: from 65.105.220.34.ptr.us.xo.net ([65.105.220.34] helo=mail.blilly.com) by smtp03.mrf.mail.rcn.net with asmtp (Exim 3.35 #7) id 1CwQ2P-0003kh-00; Wed, 02 Feb 2005 14:19:41 -0500 Received: from marty.blilly.com (localhost [127.0.0.1]) by mail.blilly.com with ESMTP id j12JJZ5w010947(8.13.1/8.13.1/mail.blilly.com sendmail.mc.mail 1.18 2004/05/15 07:23:45) ; Wed, 2 Feb 2005 14:19:35 -0500 Received: from localhost (localhost [127.0.0.1]) by marty.blilly.com with ESMTP id j12JJX7q010946(8.13.1/8.13.1/blilly.com submit.mc 1.1 2003/08/26 22:21:33) ; Wed, 2 Feb 2005 14:19:35 -0500 From: Bruce Lilly Reply-To: ietf@ietf.org Organization: Bruce Lilly To: ietf@ietf.org Subject: Re: Last Call: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard Date: Wed, 2 Feb 2005 14:19:29 -0500 User-Agent: KMail/1.7.2 Cc: namedroppers@ops.ietf.org References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200502021419.31356.blilly@erols.com> X-Scanned-By: MIMEDefang 2.49 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.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] > Date: 2005-02-01 18:43 > From: The IESG > To: IETF-Announce > CC: namedroppers@ops.ietf.org =20 > The IESG has received a request from the DNS Extensions WG to consider th= e=20 > following document: >=20 > - 'Domain Name System (DNS) Case Insensitivity Clarification ' > =C2=A0 =C2=A0 as a Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. =C2=A0Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2005-02-15. Bravo! I have one question and one related note: Q: Why is the reference to "ASCII" given as the 1968 version rather than ANSI INCITS 4-1986 (R2002)? [N.B. no typos, the dates really are 1968 and 1986] On a related note, RFC 2822 introduced a syntactic mechanism to prohibit line folding within the domain part of message identifiers. One individual regards that as a declaration that the domain names in such identifiers have magically become case-sensitive (refs: http://www.imc.org/ietf-822/mail-archive/msg04712.html http://www.imc.org/ietf-822/mail-archive/msg04876.html http://www.imc.org/ietf-822/mail-archive/msg04909.html http://www.imc.org/ietf-822/mail-archive/msg04969.html ). It has been an item on my list of things to do to write a draft clarifying the syntactic issue, and its null effect on the right-hand side of identifier semantics as domain indication, reaffirming case- insensitivity. It would be nice if the draft under discussion were to address that specific issue, obviating the need for a separate document clarifying 2822. On the other hand, if it does not, at least it can serve as a reference for such a separate document. -- to unsubscribe send a message to namedroppers-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 Feb 2 21:42: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 VAA12745 for ; Wed, 2 Feb 2005 21:42:33 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CwWvR-000KNI-BL for namedroppers-data@psg.com; Thu, 03 Feb 2005 02:40:57 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CwWvP-000KMu-6Y for namedroppers@ops.ietf.org; Thu, 03 Feb 2005 02:40:55 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.11/8.12.11) with ESMTP id j132ekEU009597 for ; Wed, 2 Feb 2005 21:40:47 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.12.11/8.12.11/Submit) id j132ekBK009596 for namedroppers@ops.ietf.org; Wed, 2 Feb 2005 21:40:46 -0500 (EST) (envelope-from namedroppers) Received: from [209.187.148.211] (helo=bs.jck.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CwQun-000NnM-3s for namedroppers@ops.ietf.org; Wed, 02 Feb 2005 20:15:53 +0000 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1CwQum-0001qS-Ay; Wed, 02 Feb 2005 15:15:52 -0500 Date: Wed, 02 Feb 2005 15:15:52 -0500 From: John C Klensin To: ietf@ietf.org cc: namedroppers@ops.ietf.org Subject: Re: Last Call: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard Message-ID: In-Reply-To: <200502021419.31356.blilly@erols.com> References: <200502021419.31356.blilly@erols.com> X-Mailer: Mulberry/3.1.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.49 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.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: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] --On Wednesday, 02 February, 2005 14:19 -0500 Bruce Lilly wrote: >... > Q: Why is the reference to "ASCII" given as the 1968 version > rather than ANSI INCITS 4-1986 (R2002)? [N.B. no typos, > the dates really are 1968 and 1986] >... Because some incompatible changes were made in the ASCII definition in the early 70s that would have fouled up the "network virtual terminal" character set. You will find that X3.4-1968 is referenced in most Internet applications protocols that require an ASCII reference, include those for telnet, ftp, and the email base protocols as well as the DNS ones. john -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 2 21:42: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 VAA12769 for ; Wed, 2 Feb 2005 21:42:48 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CwWvh-000KQW-Kt for namedroppers-data@psg.com; Thu, 03 Feb 2005 02:41:13 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CwWve-000KOh-ID for namedroppers@ops.ietf.org; Thu, 03 Feb 2005 02:41:10 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.11/8.12.11) with ESMTP id j132f2hL009603 for ; Wed, 2 Feb 2005 21:41:02 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.12.11/8.12.11/Submit) id j132f2oh009602 for namedroppers@ops.ietf.org; Wed, 2 Feb 2005 21:41:02 -0500 (EST) (envelope-from namedroppers) Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CwTOz-000GJA-WE for namedroppers@ops.ietf.org; Wed, 02 Feb 2005 22:55:14 +0000 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j12MqfQ26538; Wed, 2 Feb 2005 14:52:41 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id OAA01587; Wed, 2 Feb 2005 14:52:41 -0800 (PST) Date: Wed, 2 Feb 2005 14:52:41 -0800 (PST) Message-Id: <200502022252.OAA01587@gra.isi.edu> To: ietf@ietf.org, john-ietf@jck.com Subject: Re: Last Call: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard Cc: namedroppers@ops.ietf.org X-Sun-Charset: US-ASCII X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: braden@isi.edu X-Scanned-By: MIMEDefang 2.49 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.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] *> *> *> --On Wednesday, 02 February, 2005 14:19 -0500 Bruce Lilly *> wrote: *> *> >... *> > Q: Why is the reference to "ASCII" given as the 1968 version *> > rather than ANSI INCITS 4-1986 (R2002)? [N.B. no typos, *> > the dates really are 1968 and 1986] *> >... *> *> Because some incompatible changes were made in the ASCII *> definition in the early 70s that would have fouled up the *> "network virtual terminal" character set. You will find that *> X3.4-1968 is referenced in most Internet applications protocols *> that require an ASCII reference, include those for telnet, ftp, *> and the email base protocols as well as the DNS ones. *> *> john *> Presumably, this is the character set defined in RFC 20 ...? Bob -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 2 21:43: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 VAA12876 for ; Wed, 2 Feb 2005 21:43:31 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CwWwM-000KWJ-8X for namedroppers-data@psg.com; Thu, 03 Feb 2005 02:41:54 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CwWwJ-000KVh-Uy for namedroppers@ops.ietf.org; Thu, 03 Feb 2005 02:41:52 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.11/8.12.11) with ESMTP id j132fh2v009614 for ; Wed, 2 Feb 2005 21:41:44 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.12.11/8.12.11/Submit) id j132fhBI009613 for namedroppers@ops.ietf.org; Wed, 2 Feb 2005 21:41:43 -0500 (EST) (envelope-from namedroppers) Received: from [207.172.4.61] (helo=smtp02.mrf.mail.rcn.net) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CwUqM-0002om-BR for namedroppers@ops.ietf.org; Thu, 03 Feb 2005 00:27:34 +0000 X-Info: This message was accepted for relay by smtp02.mrf.mail.rcn.net as the sender used SMTP authentication X-Trace: ge5eD7OohLKskcHieG43m62JdiFi91a0aQ4mrxQvoPc= Received: from 65.105.220.34.ptr.us.xo.net ([65.105.220.34] helo=mail.blilly.com) by smtp02.mrf.mail.rcn.net with asmtp (Exim 3.35 #7) id 1CwUqK-0006QM-00; Wed, 02 Feb 2005 19:27:33 -0500 Received: from marty.blilly.com (localhost [127.0.0.1]) by mail.blilly.com with ESMTP id j130RWlH014572(8.13.1/8.13.1/mail.blilly.com sendmail.mc.mail 1.18 2004/05/15 07:23:45) ; Wed, 2 Feb 2005 19:27:32 -0500 Received: from localhost (localhost [127.0.0.1]) by marty.blilly.com with ESMTP id j130RVn1014571(8.13.1/8.13.1/blilly.com submit.mc 1.1 2003/08/26 22:21:33) ; Wed, 2 Feb 2005 19:27:31 -0500 From: Bruce Lilly Reply-To: ietf@ietf.org Organization: Bruce Lilly To: ietf@ietf.org Subject: Re: Last Call: 'Domain Name System (DNS) Case =?utf-8?q?Insensitivity=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Clarification=27_to?= =?utf-8?q?_Proposed?= Standard Date: Wed, 2 Feb 2005 19:27:29 -0500 User-Agent: KMail/1.7.2 Cc: namedroppers@ops.ietf.org References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502021927.29955.blilly@erols.com> X-Scanned-By: MIMEDefang 2.49 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.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 [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] > Date: 2005-02-02 15:15 > From: John C Klensin > Because some incompatible changes were made in the ASCII > definition in the early 70s that would have fouled up the > "network virtual terminal" character set. OK, but I doubt that that would affect the case-insensitivity issue that is the subject of the draft. In any event, on reviewing the one citation in the text to that reference, I see that it's a chronological reference rather than substantive. The first DNS RFCs were RFCs 881-883, ca. 1983, so it's a bit misleading to point to a document which was at that time a decade and a half old, and by which time changes made in the early 70's were a decade old. Not a big issue in any event. -- to unsubscribe send a message to namedroppers-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 Feb 2 21:43: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 VAA12941 for ; Wed, 2 Feb 2005 21:43:50 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CwWwc-000KZr-N8 for namedroppers-data@psg.com; Thu, 03 Feb 2005 02:42:10 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CwWwZ-000KZ1-37 for namedroppers@ops.ietf.org; Thu, 03 Feb 2005 02:42:07 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.11/8.12.11) with ESMTP id j132fxxs009620 for ; Wed, 2 Feb 2005 21:41:59 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.12.11/8.12.11/Submit) id j132fw9Z009619 for namedroppers@ops.ietf.org; Wed, 2 Feb 2005 21:41:58 -0500 (EST) (envelope-from namedroppers) Received: from [128.2.185.161] (helo=minbar.fac.cs.cmu.edu) by psg.com with smtp (Exim 4.43 (FreeBSD)) id 1CwVvb-000BUC-QK for namedroppers@ops.ietf.org; Thu, 03 Feb 2005 01:37:03 +0000 Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa05643; 2 Feb 2005 20:36 EST Date: Wed, 02 Feb 2005 20:36:50 -0500 From: Jeffrey Hutzelman To: namedroppers@ops.ietf.org cc: ietf@ietf.org Subject: Re: Last Call: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard Message-ID: In-Reply-To: References: Originator-Info: login-token=Mulberry:01C9ptUHVC4sRXJeXRPlidv6JMpHuSDuZ4T5u1QVo=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.49 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.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: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] On Tuesday, February 01, 2005 06:43:09 PM -0500 The IESG wrote: > The IESG has received a request from the DNS Extensions WG to consider > the following document: > > - 'Domain Name System (DNS) Case Insensitivity Clarification ' > as a Proposed Standard The document in question states: One typographic convention for octets that do not correspond to an ASCII printing graphic is to use a back-slash followed by the value of the octet as an unsigned integer represented by exactly three decimal digits. While this is literally true, the _common_ convention is to use a backslash followed by the value of the octet as an unsigned integer represented by exactly three _octal_ digits. This is the syntax used by programming languages like C and perl. For example, ASCII ESC (0x1b) is represented as \033, not \027. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA -- to unsubscribe send a message to namedroppers-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 Feb 2 22:12: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 WAA15567 for ; Wed, 2 Feb 2005 22:12:07 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CwXLw-000OtI-Jd for namedroppers-data@psg.com; Thu, 03 Feb 2005 03:08:20 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CwXLm-000OpN-Pm for namedroppers@ops.ietf.org; Thu, 03 Feb 2005 03:08:10 +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 3E954677F2 for ; Thu, 3 Feb 2005 03:08:09 +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 j1337i2t073576; Thu, 3 Feb 2005 14:07:44 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200502030307.j1337i2t073576@drugs.dv.isc.org> To: Jeffrey Hutzelman Cc: namedroppers@ops.ietf.org, ietf@ietf.org From: Mark Andrews Subject: Re: Last Call: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard In-reply-to: Your message of "Wed, 02 Feb 2005 20:36:50 CDT." Date: Thu, 03 Feb 2005 14:07:44 +1100 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 > > [ Moderators note: Post was moderated, either because it was posted by > a non-subscriber, or because it was over 20K. > With the massive amount of spam, it is easy to miss and therefore > delete relevant posts by non-subscribers. Please fix your > subscription addresses. ] > > > > On Tuesday, February 01, 2005 06:43:09 PM -0500 The IESG > wrote: > > > The IESG has received a request from the DNS Extensions WG to consider > > the following document: > > > > - 'Domain Name System (DNS) Case Insensitivity Clarification ' > > as a Proposed Standard > > > The document in question states: > > One typographic convention for octets that do not correspond to an > ASCII printing graphic is to use a back-slash followed by the value > of the octet as an unsigned integer represented by exactly three > decimal digits. > > > While this is literally true, the _common_ convention is to use a backslash > followed by the value of the octet as an unsigned integer represented by > exactly three _octal_ digits. This is the syntax used by programming > languages like C and perl. For example, ASCII ESC (0x1b) is represented as > \033, not \027. The C convention also has \t, \r, \f, \n none of which are the special in domain labels. We are not trying to change conventions here. It is irrelevent that C has a different convention. -- 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 Feb 2 22:38: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 WAA18060 for ; Wed, 2 Feb 2005 22:38:57 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CwXme-0002Cm-Rw for namedroppers-data@psg.com; Thu, 03 Feb 2005 03:35:56 +0000 Received: from [168.61.5.27] (helo=harry.mail-abuse.org) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CwXmb-0002CC-MJ for namedroppers@ops.ietf.org; Thu, 03 Feb 2005 03:35:53 +0000 Received: from SJC-Office-DHCP-156.Mail-Abuse.ORG (SJC-Office-DHCP-156.Mail-Abuse.ORG [168.61.10.156]) by harry.mail-abuse.org (Postfix) with ESMTP id 5DBCC414EB; Wed, 2 Feb 2005 19:35:53 -0800 (PST) Subject: Re: confusion caused by http://spf.pobox.com/rfcs.html From: Douglas Otis To: Meng Weng Wong Cc: IETF DNSEXT WG In-Reply-To: <20050203021645.GP9946@dumbo.pobox.com> References: <20050203021645.GP9946@dumbo.pobox.com> Content-Type: text/plain Date: Wed, 02 Feb 2005 19:35:39 -0800 Message-Id: <1107401739.6898.319.camel@SJC-Office-DHCP-156.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.1 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 On Wed, 2005-02-02 at 21:16 -0500, Meng Weng Wong wrote: > ok, let me know how you feel about what's on the website > now. The current draft is listed, with the SPF classic draft, and also Sender-ID as a basis for the same record? -Doug -- to unsubscribe send a message to namedroppers-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 Feb 2 22: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 WAA18421 for ; Wed, 2 Feb 2005 22:44:03 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CwXsL-00030l-D0 for namedroppers-data@psg.com; Thu, 03 Feb 2005 03:41:49 +0000 Received: from [204.127.202.55] (helo=sccrmhc11.comcast.net) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CwXsH-00030A-9R for namedroppers@ops.ietf.org; Thu, 03 Feb 2005 03:41:45 +0000 Received: from mini.pothole.com (pothole.com[24.62.71.160]) by comcast.net (sccrmhc11) with ESMTP id <2005020303414401100ciobje>; Thu, 3 Feb 2005 03:41:44 +0000 Received: by mini.pothole.com (Postfix, from userid 1026) id C6EE6781A1; Wed, 2 Feb 2005 22:41:43 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mini.pothole.com (Postfix) with ESMTP id A7C86781A0; Wed, 2 Feb 2005 22:41:43 -0500 (EST) Date: Wed, 2 Feb 2005 22:41:43 -0500 (EST) From: Donald Eastlake III X-X-Sender: donaldeastlakeiii@mini.pothole.com To: namedroppers@ops.ietf.org Cc: iesg@ietf.org Subject: Re: Last Call: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 The context is clearly Master Files where the syntax is as given. For the purposes of this document, which is clarification of the existing DNS conventions, what does it matter what is done elsewhere? However, unless there is objection, I'd be happy to change the relevant sentence by inserting "in Master Files" so it reads: One typographic convention in Master Files for octets that do not correspond to an ASCII printing graphic is to use a back-slash followed by the value of the octet as an unsigned integer represented by exactly three decimal digits. Thanks, Donald ==================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 155 Beaver Street +1-508-634-2066(h) +1-508-786-7554(w) Milford, MA 01757 USA Donald.Eastlake@motorola.com On Wed, 2 Feb 2005, Jeffrey Hutzelman wrote: > Date: Wed, 02 Feb 2005 20:36:50 -0500 > From: Jeffrey Hutzelman > To: namedroppers@ops.ietf.org > Cc: ietf@ietf.org > Subject: Re: Last Call: 'Domain Name System (DNS) Case Insensitivity > Clarification' to Proposed Standard > > On Tuesday, February 01, 2005 06:43:09 PM -0500 The IESG > wrote: > >> The IESG has received a request from the DNS Extensions WG to consider >> the following document: >> >> - 'Domain Name System (DNS) Case Insensitivity Clarification ' >> as a Proposed Standard > > The document in question states: > > One typographic convention for octets that do not correspond to an > ASCII printing graphic is to use a back-slash followed by the value > of the octet as an unsigned integer represented by exactly three > decimal digits. > > While this is literally true, the _common_ convention is to use a backslash > followed by the value of the octet as an unsigned integer represented by > exactly three _octal_ digits. This is the syntax used by programming > languages like C and perl. For example, ASCII ESC (0x1b) is represented as > \033, not \027. > > -- Jeffrey T. Hutzelman (N3NHS) > Sr. Research Systems Programmer > School of Computer Science - Research Computing Facility > Carnegie Mellon University - Pittsburgh, PA -- to unsubscribe send a message to namedroppers-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 Feb 2 22:53: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 WAA19121 for ; Wed, 2 Feb 2005 22:53:15 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CwY1W-0004Mo-BQ for namedroppers-data@psg.com; Thu, 03 Feb 2005 03:51:18 +0000 Received: from [204.127.202.55] (helo=sccrmhc11.comcast.net) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CwY1T-0004Lu-Dw for namedroppers@ops.ietf.org; Thu, 03 Feb 2005 03:51:15 +0000 Received: from mini.pothole.com (pothole.com[24.62.71.160]) by comcast.net (sccrmhc11) with ESMTP id <2005020303511401100cdgi7e>; Thu, 3 Feb 2005 03:51:14 +0000 Received: by mini.pothole.com (Postfix, from userid 1026) id 63E3578233; Wed, 2 Feb 2005 22:51:14 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mini.pothole.com (Postfix) with ESMTP id 6220778232; Wed, 2 Feb 2005 22:51:14 -0500 (EST) Date: Wed, 2 Feb 2005 22:51:14 -0500 (EST) From: Donald Eastlake III X-X-Sender: donaldeastlakeiii@mini.pothole.com To: namedroppers@ops.ietf.org Cc: iesg@ietf.org, dee3@pothole.com Subject: Re: Last Call: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 See responses below: On Wed, 2 Feb 2005 Dan.Anderson@dtn.com wrote: > Date: Wed, 2 Feb 2005 12:51:40 -0600 > From: Dan.Anderson@dtn.com > To: Donald Eastlake III > Subject: Re: Last Call: 'Domain Name System (DNS) Case Insensitivity > Clarification' to Proposed Standard > > Not that any of it probably really matters in the whole scheme of things > but... > >> 4.2 DNS Input Case Preservation >> When a node in the DNS name tree is created by any of >> such inputs > > This might be a regional thing, but I'd leave the "of" out. I'm not inclined to make this change. >> However, >> when a name label is input for a node that already exist in DNS data >> being held, the situation is more complex. > > 'exists' instead of 'exist'? Yes. >> Implementations may retain >> the case first input for such a label or allow new input to override >> the old case or even maintain separate copies preserving the input >> case. > > 'MAY' versus 'may' Yes, seems right to me to be MAY. >> as the first resourced record under owner name "xyz.BAR.example" > > 'resourced' or 'resource'? Yes, "resource". >> However, the individual octets of which DNS names consist are not >> limited to valid ASCII character codes. They are 8-bit bytes and all >> values are allowed. > > Which RFC states this? Should it be referenced? Well, I could check whether 1034 or 1035 is the best reference but the purpose of this document is, afterall to clarify 1034 and 1035 so in some sense the influcen is going in the other direction... > Thanks > > Dan Anderson, CISSP, SCSA > UNIX Team Leader > DTN > 9110 West Dodge Road > Omaha, NE 68114 > > dan.anderson@dtn.com > Phone: 1-402-255-8371 > Fax: 1-402-255-8460 > www.dtn.com Thanks, Donald ==================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 155 Beaver Street +1-508-634-2066(h) +1-508-786-7554(w) Milford, MA 01757 USA Donald.Eastlake@motorola.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 3 01:35: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 BAA04479 for ; Thu, 3 Feb 2005 01:35:53 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CwaXJ-0000di-2k for namedroppers-data@psg.com; Thu, 03 Feb 2005 06:32:17 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CwaXH-0000dU-2T for namedroppers@ops.ietf.org; Thu, 03 Feb 2005 06:32:15 +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 4A738677EF for ; Thu, 3 Feb 2005 06:32: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 j136VoRk033920; Thu, 3 Feb 2005 17:31:50 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200502030631.j136VoRk033920@drugs.dv.isc.org> To: Donald Eastlake III Cc: namedroppers@ops.ietf.org, iesg@ietf.org From: Mark Andrews Subject: Re: Last Call: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard In-reply-to: Your message of "Wed, 02 Feb 2005 22:41:43 CDT." Date: Thu, 03 Feb 2005 17:31:50 +1100 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 > The context is clearly Master Files where the syntax is as given. > For the purposes of this document, which is clarification of the > existing DNS conventions, what does it matter what is done elsewhere? > > However, unless there is objection, I'd be happy to change the relevant > sentence by inserting "in Master Files" so it reads: > > One typographic convention in Master Files for octets that do not > correspond to an ASCII printing graphic is to use a back-slash > followed by the value of the octet as an unsigned integer > represented by exactly three decimal digits. > > Thanks, > Donald > ==================================================================== > Donald E. Eastlake 3rd dee3@torque.pothole.com > 155 Beaver Street +1-508-634-2066(h) +1-508-786-7554(w) > Milford, MA 01757 USA Donald.Eastlake@motorola.com The convention applies whereever domain names are entered. > On Wed, 2 Feb 2005, Jeffrey Hutzelman wrote: > > > Date: Wed, 02 Feb 2005 20:36:50 -0500 > > From: Jeffrey Hutzelman > > To: namedroppers@ops.ietf.org > > Cc: ietf@ietf.org > > Subject: Re: Last Call: 'Domain Name System (DNS) Case Insensitivity > > Clarification' to Proposed Standard > > > > On Tuesday, February 01, 2005 06:43:09 PM -0500 The IESG > > wrote: > > > >> The IESG has received a request from the DNS Extensions WG to consider > >> the following document: > >> > >> - 'Domain Name System (DNS) Case Insensitivity Clarification ' > >> as a Proposed Standard > > > > The document in question states: > > > > One typographic convention for octets that do not correspond to an > > ASCII printing graphic is to use a back-slash followed by the value > > of the octet as an unsigned integer represented by exactly three > > decimal digits. > > > > While this is literally true, the _common_ convention is to use a backslash > > > followed by the value of the octet as an unsigned integer represented by > > exactly three _octal_ digits. This is the syntax used by programming > > languages like C and perl. For example, ASCII ESC (0x1b) is represented as > > > \033, not \027. > > > > -- Jeffrey T. Hutzelman (N3NHS) > > Sr. Research Systems Programmer > > School of Computer Science - Research Computing Facility > > Carnegie Mellon University - Pittsburgh, PA > > -- > to 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 Feb 3 08:51:38 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22516 for ; Thu, 3 Feb 2005 08:51:37 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CwhIt-0004ya-OE for namedroppers-data@psg.com; Thu, 03 Feb 2005 13:45:51 +0000 Received: from [204.127.202.64] (helo=sccrmhc13.comcast.net) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CwhIr-0004yI-EC for namedroppers@ops.ietf.org; Thu, 03 Feb 2005 13:45:49 +0000 Received: from mini.pothole.com (pothole.com[24.62.71.160]) by comcast.net (sccrmhc13) with ESMTP id <20050203134548016004eokje>; Thu, 3 Feb 2005 13:45:48 +0000 Received: by mini.pothole.com (Postfix, from userid 1026) id 54EE079073; Thu, 3 Feb 2005 08:45:48 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mini.pothole.com (Postfix) with ESMTP id 5314579072; Thu, 3 Feb 2005 08:45:48 -0500 (EST) Date: Thu, 3 Feb 2005 08:45:48 -0500 (EST) From: Donald Eastlake III X-X-Sender: donaldeastlakeiii@mini.pothole.com To: namedroppers@ops.ietf.org Cc: iesg@ietf.org Subject: Re: Last Call: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard In-Reply-To: <86k6pqkx2i.fsf@abel.internet2.edu> Message-ID: References: <86k6pqkx2i.fsf@abel.internet2.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 Just to be clear, I didn't make any decisions here. This typographic convention for DNS names was adopted long ago. See RFCs 1034, 1035. Thanks, Donald PS: I don't believe it is worth the time of everyone on the IETF list to see this stuff so I have been consistently changing ietf@ietf.org to iesg@ietf.org as an addressee. ==================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 155 Beaver Street +1-508-634-2066(h) +1-508-786-7554(w) Milford, MA 01757 USA Donald.Eastlake@motorola.com On Thu, 3 Feb 2005, stanislav shalunov wrote: > Date: 03 Feb 2005 00:54:29 -0500 > From: stanislav shalunov > To: Jeffrey Hutzelman > Cc: namedroppers@ops.ietf.org, ietf@ietf.org > Subject: Re: Last Call: 'Domain Name System (DNS) Case Insensitivity > Clarification' to Proposed Standard > > Jeffrey Hutzelman writes: > >> [..T]he _common_ convention is to use a backslash followed by the >> value of the octet as an unsigned integer represented by exactly >> three _octal_ digits. This is the syntax used by programming >> languages like C and perl. For example, ASCII ESC (0x1b) is >> represented as \033, not \027. > > Actually, the convention used in C and Perl is to use \0, followed by > zero, one, or two octal digits (leaving some values of octets without > representation). > > I personally think it's a poor convention as it uses varying number of > digits, so it becomes difficult to represent, say, the NUL character > followed by the digit "1". (I still use the convention in cases when > it is familiar to most from documentation, e.g., "\015\012" in Perl.) > > A reasonable convention is hexadecimal: backslash, followed by the > letter x, followed by exactly two hexadecimal digits; e.g., "\x1b" for > ESC. This notation, while looking familiar, has differences from both > Perl and C hex notations: in Perl, you can have just a single hex > digit following ``backslash x'', while in C you can have arbitrarily > many. > > With the common conventions so unnecessarily complex and difficult to > use, it doesn't surprise me that the document authors chose to use a > nonstandard one. I'd have chosen a different one (hex with exactly > two digits, which won't deceive C and Perl programmers in the same way > "\027" meant for ESC would), but that's just a minor typographic > convention. > > -- > Stanislav Shalunov http://www.internet2.edu/~shalunov/ > > This message is designed to be viewed with 0.06479891g of NaCl. > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > > -- to unsubscribe send a message to namedroppers-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 Feb 3 08:51: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 IAA22534 for ; Thu, 3 Feb 2005 08:51:39 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CwhLh-0005Nk-7S for namedroppers-data@psg.com; Thu, 03 Feb 2005 13:48:45 +0000 Received: from [204.127.198.39] (helo=rwcrmhc13.comcast.net) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CwhLW-0005Lp-6Y for namedroppers@ops.ietf.org; Thu, 03 Feb 2005 13:48:34 +0000 Received: from mini.pothole.com (pothole.com[24.62.71.160]) by comcast.net (rwcrmhc13) with ESMTP id <20050203134833015009kd67e>; Thu, 3 Feb 2005 13:48:33 +0000 Received: by mini.pothole.com (Postfix, from userid 1026) id 81B6979085; Thu, 3 Feb 2005 08:48:32 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mini.pothole.com (Postfix) with ESMTP id 7FCD479084; Thu, 3 Feb 2005 08:48:32 -0500 (EST) Date: Thu, 3 Feb 2005 08:48:32 -0500 (EST) From: Donald Eastlake III X-X-Sender: donaldeastlakeiii@mini.pothole.com To: Ian Jackson Cc: iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: Last Call: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard In-Reply-To: <16896.63086.21842.203333@chiark.greenend.org.uk> Message-ID: References: <16896.63086.21842.203333@chiark.greenend.org.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 I think it is just a matter of style. As a clarification updating RFCs 1034 and 1035, the import is exactly the same as your suggested text. It is just that it is in the style of commentary. If there is consensus to do so, I suppose I could rewrite the whole document in Official Standards Very Harsh Imperative Style, as you suggest. Thanks, Donald ==================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 155 Beaver Street +1-508-634-2066(h) +1-508-786-7554(w) Milford, MA 01757 USA Donald.Eastlake@motorola.com On Wed, 2 Feb 2005, Ian Jackson wrote: > Date: Wed, 2 Feb 2005 15:49:02 +0000 > From: Ian Jackson > To: iesg@ietf.org > Cc: IETF-Announce , namedroppers@ops.ietf.org > Newsgroups: chiark.mail.ietf.announce > Subject: Re: Last Call: 'Domain Name System (DNS) Case Insensitivity > Clarification' to Proposed Standard > > > [ Moderators note: Post was moderated, either because it was posted by > a non-subscriber, or because it was over 20K. > With the massive amount of spam, it is easy to miss and therefore > delete relevant posts by non-subscribers. Please fix your > subscription addresses. ] > > The IESG writes ("Last Call: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard "): >> The IESG has received a request from the DNS Extensions WG to consider the >> following document: >> >> - 'Domain Name System (DNS) Case Insensitivity Clarification ' >> as a Proposed Standard > > I am astounded that this much-needed clarification document still > fails to unambiguously specify exactly which DNS labels are to be > considered equivalent ! In particular, it fails to state clearly that > the results of the comparison depends only on the individual separate > comparisons of corresponding octets, and it fails to give a clearly > stated (and clearly stated to be exhaustive) specification of the set > of equivalence classes for octets. > > For example, it is not 100% clear, according to > draft-ietf-dnsext-insensitive-05, whether an implementation may > consider 0xCC as equivalent to 0xEC. An implementor trying to defend > a bizarre and ancient implementation might argue that `0xCC is upper > case L with top bit set, which compares equal to 0xEC because 0xEC is > lower case L with top bit set'. This appears, on the face of it, to > be difficult to square with the example of 0xDD != 0xFD, but 0xDD and > 0xFD are not `ASCII letters with the top bit set'. This shows the > danger of attempting to specify almost entirely by example ! > > I suggest the addition of text along the following lines, after > section 3.3: > > 3.4. Equivalence of label strings > > Two labels of type 0x0 MUST be considered equivalent if they are of > the same length and every octet in one label is considered equivalent > to the corresponding octet in the other label. Otherwise the labels > MUST be considered and treated as different labels. > > A pair of octets MUST be considered equivalent according to the > following rules: > > A. One octets is in the range 0x41-0x5A (upper case ASCII > letters) and the other is in the range 0x61-0x7A (lower case > ASCII letters): > > They MUST be considered equivalent if the octet values differ by > exactly 0x20, and MUST be considered NOT equivalent if the octet > values differ by some different amount. > > B. Any other pair of octets (ie, at least one of the two octets > outside either of the two ranges in B above, or both of the > octets in the same one of the two ranges in B above): > > They MUST be considered equivalent if their octet values are the > same, and MUST be considered NOT equivalent if they differ. > > Ian. -- to unsubscribe send a message to namedroppers-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 Feb 3 08:55: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 IAA22822 for ; Thu, 3 Feb 2005 08:55:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CwhPS-0005wN-V5 for namedroppers-data@psg.com; Thu, 03 Feb 2005 13:52:38 +0000 Received: from [204.127.202.64] (helo=sccrmhc13.comcast.net) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CwhPR-0005w5-WD for namedroppers@ops.ietf.org; Thu, 03 Feb 2005 13:52:38 +0000 Received: from mini.pothole.com (pothole.com[24.62.71.160]) by comcast.net (sccrmhc13) with ESMTP id <20050203135237016004ipc5e>; Thu, 3 Feb 2005 13:52:37 +0000 Received: by mini.pothole.com (Postfix, from userid 1026) id 3E0FC790A9; Thu, 3 Feb 2005 08:52:37 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mini.pothole.com (Postfix) with ESMTP id 22AC0790A8 for ; Thu, 3 Feb 2005 08:52:36 -0500 (EST) Date: Thu, 3 Feb 2005 08:52:31 -0500 (EST) From: Donald Eastlake III X-X-Sender: donaldeastlakeiii@mini.pothole.com To: namedroppers@ops.ietf.org Subject: draft-ietf-dnsext-ecc-key-06.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 By the way, the is an updated version of the ECC draft out. I actually think it needs more work than my case insensitivity draft :-) One thing I noticed after posting it is that the reference to the specific "SIG" RR in the heading of section needs to go and that section header should be generalized to something like "Elliptic Cureve Signature Resource Records". Thanks, Donald ==================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 155 Beaver Street +1-508-634-2066(h) +1-508-786-7554(w) Milford, MA 01757 USA Donald.Eastlake@motorola.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 3 10:25: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 KAA02880 for ; Thu, 3 Feb 2005 10:25:02 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Cwijd-000HUC-FE for namedroppers-data@psg.com; Thu, 03 Feb 2005 15:17:33 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Cwija-000HTw-6X for namedroppers@ops.ietf.org; Thu, 03 Feb 2005 15:17:30 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.11/8.12.11) with ESMTP id j13FHPsT012097 for ; Thu, 3 Feb 2005 10:17:25 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.12.11/8.12.11/Submit) id j13FHPeH012096 for namedroppers@ops.ietf.org; Thu, 3 Feb 2005 10:17:25 -0500 (EST) (envelope-from namedroppers) Received: from [207.75.164.22] (helo=basie.internet2.edu) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CwZwj-000L7F-2N for namedroppers@ops.ietf.org; Thu, 03 Feb 2005 05:54:29 +0000 Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id AE9C41CD641; Thu, 3 Feb 2005 00:54:28 -0500 (EST) Received: from basie.internet2.edu ([127.0.0.1]) by localhost (basie.internet2.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17829-03; Thu, 3 Feb 2005 00:54:28 -0500 (EST) Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 5FF8D1CD49C; Thu, 3 Feb 2005 00:54:28 -0500 (EST) To: Jeffrey Hutzelman Cc: namedroppers@ops.ietf.org, ietf@ietf.org Subject: Re: Last Call: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard References: From: stanislav shalunov Date: 03 Feb 2005 00:54:29 -0500 In-Reply-To: Message-ID: <86k6pqkx2i.fsf@abel.internet2.edu> Lines: 35 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by mail.internet2.edu virus scanner X-Scanned-By: MIMEDefang 2.49 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.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] Jeffrey Hutzelman writes: > [..T]he _common_ convention is to use a backslash followed by the > value of the octet as an unsigned integer represented by exactly > three _octal_ digits. This is the syntax used by programming > languages like C and perl. For example, ASCII ESC (0x1b) is > represented as \033, not \027. Actually, the convention used in C and Perl is to use \0, followed by zero, one, or two octal digits (leaving some values of octets without representation). I personally think it's a poor convention as it uses varying number of digits, so it becomes difficult to represent, say, the NUL character followed by the digit "1". (I still use the convention in cases when it is familiar to most from documentation, e.g., "\015\012" in Perl.) A reasonable convention is hexadecimal: backslash, followed by the letter x, followed by exactly two hexadecimal digits; e.g., "\x1b" for ESC. This notation, while looking familiar, has differences from both Perl and C hex notations: in Perl, you can have just a single hex digit following ``backslash x'', while in C you can have arbitrarily many. With the common conventions so unnecessarily complex and difficult to use, it doesn't surprise me that the document authors chose to use a nonstandard one. I'd have chosen a different one (hex with exactly two digits, which won't deceive C and Perl programmers in the same way "\027" meant for ESC would), but that's just a minor typographic convention. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ This message is designed to be viewed with 0.06479891g of NaCl. -- to unsubscribe send a message to namedroppers-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 Feb 3 13:03:56 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21052 for ; Thu, 3 Feb 2005 13:03:56 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CwlFV-000DKd-5M for namedroppers-data@psg.com; Thu, 03 Feb 2005 17:58:37 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CwlFU-000DKG-10 for namedroppers@ops.ietf.org; Thu, 03 Feb 2005 17:58:36 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.11/8.12.11) with ESMTP id j13HwUl1012827 for ; Thu, 3 Feb 2005 12:58:30 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.12.11/8.12.11/Submit) id j13HwUQn012826 for namedroppers@ops.ietf.org; Thu, 3 Feb 2005 12:58:30 -0500 (EST) (envelope-from namedroppers) Received: from [193.201.200.170] (helo=chiark.greenend.org.uk) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CwjQD-000OND-Iz for namedroppers@ops.ietf.org; Thu, 03 Feb 2005 16:01:33 +0000 Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path ijackson@chiark.greenend.org.uk) id 1CwjQ7-0002pk-00; Thu, 03 Feb 2005 16:01:27 +0000 From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16898.19159.464261.827052@chiark.greenend.org.uk> Date: Thu, 3 Feb 2005 16:01:27 +0000 To: Donald Eastlake III Cc: Ian Jackson , iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: Last Call: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard In-Reply-To: References: <16896.63086.21842.203333@chiark.greenend.org.uk> X-Mailer: VM 7.03 under Emacs 19.34.1 X-Scanned-By: MIMEDefang 2.49 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.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 [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] Donald Eastlake III writes ("Re: Last Call: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard "): > I think it is just a matter of style. As a clarification updating RFCs > 1034 and 1035, the import is exactly the same as your suggested text. It > is just that it is in the style of commentary. If there is consensus to > do so, I suppose I could rewrite the whole document in Official > Standards Very Harsh Imperative Style, as you suggest. .. No, the import in the draft's text is not the same. Consider my example misunderstanding: > > For example, it is not 100% clear, according to > > draft-ietf-dnsext-insensitive-05, whether an implementation may > > consider 0xCC as equivalent to 0xEC. An implementor trying to defend > > a bizarre and ancient implementation might argue that `0xCC is upper > > case L with top bit set, which compares equal to 0xEC because 0xEC is > > lower case L with top bit set'. This appears, on the face of it, to > > be difficult to square with the example of 0xDD != 0xFD, but 0xDD and > > 0xFD are not `ASCII letters with the top bit set'. This shows the > > danger of attempting to specify almost entirely by example ! If you don't like my overly formal language then I'm sure there are other ways of putting it. But just a couple of examples does not constitute a clarification ! Ian. -- to unsubscribe send a message to namedroppers-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 Feb 3 13:03:58 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21082 for ; Thu, 3 Feb 2005 13:03:58 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CwlFx-000DQD-AS for namedroppers-data@psg.com; Thu, 03 Feb 2005 17:59:05 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CwlFt-000DPV-NX for namedroppers@ops.ietf.org; Thu, 03 Feb 2005 17:59:02 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.11/8.12.11) with ESMTP id j13HwuR3012833 for ; Thu, 3 Feb 2005 12:58:56 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.12.11/8.12.11/Submit) id j13HwuBR012832 for namedroppers@ops.ietf.org; Thu, 3 Feb 2005 12:58:56 -0500 (EST) (envelope-from namedroppers) Received: from [128.2.185.161] (helo=minbar.fac.cs.cmu.edu) by psg.com with smtp (Exim 4.43 (FreeBSD)) id 1Cwk10-0003Rd-6a for namedroppers@ops.ietf.org; Thu, 03 Feb 2005 16:39:34 +0000 Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa06941; 3 Feb 2005 11:38 EST Date: Thu, 03 Feb 2005 11:38:56 -0500 From: Jeffrey Hutzelman To: stanislav shalunov cc: namedroppers@ops.ietf.org, ietf@ietf.org Subject: Re: Last Call: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard Message-ID: In-Reply-To: <86k6pqkx2i.fsf@abel.internet2.edu> References: <86k6pqkx2i.fsf@abel.internet2.edu> Originator-Info: login-token=Mulberry:01U2KdHL3KEpCfrRWdhuDNi+rU1EfalhbA18uBieI=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.49 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.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 [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] On Thursday, February 03, 2005 12:54:29 AM -0500 stanislav shalunov wrote: > Jeffrey Hutzelman writes: > >> [..T]he _common_ convention is to use a backslash followed by the >> value of the octet as an unsigned integer represented by exactly >> three _octal_ digits. This is the syntax used by programming >> languages like C and perl. For example, ASCII ESC (0x1b) is >> represented as \033, not \027. > > Actually, the convention used in C and Perl is to use \0, followed by > zero, one, or two octal digits (leaving some values of octets without > representation). > > I personally think it's a poor convention as it uses varying number of > digits, so it becomes difficult to represent, say, the NUL character > followed by the digit "1". (I still use the convention in cases when > it is familiar to most from documentation, e.g., "\015\012" in Perl.) ISO/IEC 9899:1990 section 6.1.3.4 has this to say: octal-escape-sequence: \ octal-digit \ octal-digit octal-digit \ octal-digit octal-digit octal-digit hexadecimal-escape-sequence: \x hexadecimal-digit hexadecimal-escape-sequence hexadecimal-digit And... Each octal or hexadecimal escape sequence is the longest sequence of characters that can constitute the escape sequence. So, octal escape sequences consist of one, two, or three digits, but never more than three, and the first digit is not required to be zero. Every 8-bit character can be represented, and every string of 8-bit characters can be represented. The sequence of the NUL character followed by the digit "1" can be written as "\0001", or as any of these: \0\061 \00\061 \000\061 \0\61 \00\61 \000\61 Interestingly, as you noted, hexadecimal sequences are _not_ length-limted. Now, let's turn to Perl. The authoritative reference is from the section "Quotes and Quote-like Operators" in 'perldoc perlop': The following escape sequences are available in constructs that interpolate and in transliterations. \033 octal char (ESC) \x1b hex char (ESC) \x{263a} wide hex char (SMILEY) Unfortunately, this is a little vague, but an examination of the code shows that up to three digits are permitted in the octal case, and two in the hex case (wide hex chars have no preset length limit), which is pretty much what one would expect. In any case, my original point was not to get into a discussion of the finer details of character escapes in particular programming languages, nor to suggest that every escape permitted by C or Perl be used in this context. Rather, it was to point out that the existing, commonly-used convention for character escapes of this form uses octal digits, not decimal, and that differing in this particular way would be likely to lead to confusion. Mark Andrews wrote: > The C convention also has \t, \r, \f, \n none of which are > the special in domain labels. This is a strawman. I did not make the argument that C string literal syntax should be used; I mentioned the syntax of C and Perl as examples of the widespread recognition of octal character escapes. > We are not trying to change conventions here. It is irrelevent > that C has a different convention. The C programming language has precisely defined syntax, not a convention. Again, I did not make the argument that C syntax should be used. What I did do was point out that there is a commonly-recognized convention for the meaning of a backslash followed by three digits, and that it differs from that described in this document, which to my knowledge does not enjoy any form of widespread acceptance. This fact is not "irrelevant"; it is likely to lead to significant confusion. Note that I'm not demanding that the DNS use the same conventions as everyone else. I think they should, but I'm not going to insist on it. However, if you're going to be different, you need to call out this fact, and preferably explain why. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA -- to unsubscribe send a message to namedroppers-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 Feb 3 15:20: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 PAA04542 for ; Thu, 3 Feb 2005 15:20:28 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CwnOF-0005p1-8F for namedroppers-data@psg.com; Thu, 03 Feb 2005 20:15:47 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.43 (FreeBSD)) id 1CwnOC-0005oZ-Nm for namedroppers@ops.ietf.org; Thu, 03 Feb 2005 20:15:44 +0000 Received: (qmail 49834 invoked by uid 1016); 3 Feb 2005 20:16:07 -0000 Date: 3 Feb 2005 20:16:07 -0000 Message-ID: <20050203201607.49821.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: Last Call: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard References: <200502030631.j136VoRk033920@drugs.dv.isc.org> 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=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mark Andrews writes: > The convention applies whereever domain names are entered. Oh, really? I entered http://www.is\067.org into a browser using your libresolv. Your web server responded with a ``Bad Request'' message, rather than the www.isc.org web page. I have no objection to this document _if_ it is limited to zone files. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 3 15:55: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 PAA07798 for ; Thu, 3 Feb 2005 15:55:41 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CwnyW-000Atw-DN for namedroppers-data@psg.com; Thu, 03 Feb 2005 20:53:16 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CwnyV-000Atd-5J for namedroppers@ops.ietf.org; Thu, 03 Feb 2005 20:53:15 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07616; Thu, 3 Feb 2005 15:53:12 -0500 (EST) Message-Id: <200502032053.PAA07616@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-rfc2538bis-01.txt Date: Thu, 03 Feb 2005 15:53:12 -0500 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 : Storing Certificates in the Domain Name System (DNS) Author(s) : S. Josefsson Filename : draft-ietf-dnsext-rfc2538bis-01.txt Pages : 14 Date : 2005-2-3 Cryptographic public key are frequently published and their authenticity demonstrated by certificates. A CERT resource record (RR) is defined so that such certificates and related certificate revocation lists can be stored in the Domain Name System (DNS). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2538bis-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-rfc2538bis-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-rfc2538bis-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-3154551.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-rfc2538bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-rfc2538bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-3154551.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 3 15:55: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 PAA07825 for ; Thu, 3 Feb 2005 15:55:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CwnyN-000Asx-PR for namedroppers-data@psg.com; Thu, 03 Feb 2005 20:53:07 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CwnyL-000Asc-Df for namedroppers@ops.ietf.org; Thu, 03 Feb 2005 20:53:05 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07596; Thu, 3 Feb 2005 15:53:02 -0500 (EST) Message-Id: <200502032053.PAA07596@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-opt-in-06.txt Date: Thu, 03 Feb 2005 15:53:02 -0500 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 : DNSSEC Opt-in Author(s) : R. Arends, et al. Filename : draft-ietf-dnsext-dnssec-opt-in-06.txt Pages : 21 Date : 2005-2-3 In RFC 2535, delegations to unsigned subzones are cryptographically secured. Maintaining this cryptography is not practical or necessary. This document describes an 'Opt-In' model that allows administrators to omit this cryptography and manage the cost of adopting DNSSEC with large zones. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-opt-in-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-opt-in-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-opt-in-06.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-2-3154542.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-opt-in-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-opt-in-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-3154542.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 Feb 4 00:02:42 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04344 for ; Fri, 4 Feb 2005 00:02:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CwvV3-0007se-IM for namedroppers-data@psg.com; Fri, 04 Feb 2005 04:55:21 +0000 Received: from [202.12.73.64] (helo=fivedots.coe.psu.ac.th) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CwvUw-0007rd-SU for namedroppers@ops.ietf.org; Fri, 04 Feb 2005 04:55:16 +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 1CwvUb-0002zD-00; Fri, 04 Feb 2005 11:54:53 +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 j144sMU4008648; Fri, 4 Feb 2005 11:54:23 +0700 (ICT) From: Robert Elz To: stanislav shalunov cc: Jeffrey Hutzelman , namedroppers@ops.ietf.org, ietf@ietf.org Subject: Re: Last Call: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard In-Reply-To: <86k6pqkx2i.fsf@abel.internet2.edu> References: <86k6pqkx2i.fsf@abel.internet2.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 04 Feb 2005 11:54:22 +0700 Message-ID: <9186.1107492862@munnari.OZ.AU> 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 Date: 03 Feb 2005 00:54:29 -0500 From: stanislav shalunov Message-ID: <86k6pqkx2i.fsf@abel.internet2.edu> This is totally irrelevant to the doc in question, but ... | Actually, the convention used in C and Perl is to use \0, followed by | zero, one, or two octal digits (leaving some values of octets without | representation). that is utter garbage. \377 is a perfectly valid C (and I assume perl, though I gave up on perl years ago) representation of the value 255. | I personally think it's a poor convention as it uses varying number of | digits, so it becomes difficult to represent, say, the NUL character | followed by the digit "1". Not difficult, just ugly ... \0001 works just fine. | nonstandard one. I'd have chosen a different one You're 20 years too late. 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 Feb 4 00:04:38 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04539 for ; Fri, 4 Feb 2005 00:04:38 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Cwvav-00091M-Cz for namedroppers-data@psg.com; Fri, 04 Feb 2005 05:01:25 +0000 Received: from [202.12.73.64] (helo=fivedots.coe.psu.ac.th) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Cwvas-00090q-3z for namedroppers@ops.ietf.org; Fri, 04 Feb 2005 05:01:23 +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 1Cwvap-0008Ev-00; Fri, 04 Feb 2005 12:01:19 +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 j1450mIY010935; Fri, 4 Feb 2005 12:00:49 +0700 (ICT) From: Robert Elz To: Harald Tveit Alvestrand cc: bmanning@vacation.karoshi.com, iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: Last Call: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard In-Reply-To: <88EAAA4611113A9E57A00593@B50854F0A9192E8EC6CDA126> References: <88EAAA4611113A9E57A00593@B50854F0A9192E8EC6CDA126> <20050202043943.GA8153@vacation.karoshi.com.> <11972.1107330243@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 04 Feb 2005 12:00:48 +0700 Message-ID: <11515.1107493248@munnari.OZ.AU> 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 Date: Wed, 02 Feb 2005 23:34:31 +0100 From: Harald Tveit Alvestrand Message-ID: <88EAAA4611113A9E57A00593@B50854F0A9192E8EC6CDA126> | > In this case, what may be considered unusual, is that there has been | > no mention on the namedroppers list of the need for the -05 draft, nothing | > about what required it, and nothing about what has changed in it. Maybe | > the draft says that - but if it is the version that is to be published as | > an RFC, it shouldn't (RFCs should not contain info about what changed | > in the last few versions of the I-D, nor should they be having that kind | > of information editorially deleted after approval). | | Yes, they should. I'm not sure what you're saying there exactly. If you mean that if there are updates notes in a draft that is approved, then the rfc editor should delete them, then yes, I agree. On the other hand, if you're saying that that is the proper way to do things, then I disagree. The doc proposed (for IETF last call, at the very least) should be as close as possible (as close as the boilerplate nonsense permits) to the exact RFC that will be published. It is entirely possible that some readers may see some technical merit in the update notes - that the doc is clear, but only because those notes indicate what is going on, and why. Without the notes, a valid objection might be made. If (non boilerplate) data is deleted after approval, then a doc that shouldn't have been approved, can avoid objections. The right way to do this, is to have the final draft of the doc (perhaps the final version for WG last call, and certainly the version sent for IETF last call) be the same as what will be the RFC - taht is, a new version of the I-D should be publiched, where the only change is to delete any extraneous material like this (and the I-D shouldn't be saying this). Donald - if, as seems possible from other messages, you're going to publish a new I-D, please send a version without noise, so that one can be properly evaluated for IETF last call. 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 Feb 4 00:14:17 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05388 for ; Fri, 4 Feb 2005 00:14:16 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Cwvkh-000AOz-ES for namedroppers-data@psg.com; Fri, 04 Feb 2005 05:11:31 +0000 Received: from [202.12.73.64] (helo=fivedots.coe.psu.ac.th) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Cwvkf-000ANq-53 for namedroppers@ops.ietf.org; Fri, 04 Feb 2005 05:11:29 +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 1CwvkU-000393-00; Fri, 04 Feb 2005 12:11:18 +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 j145AluY013880; Fri, 4 Feb 2005 12:10:50 +0700 (ICT) From: Robert Elz To: Donald Eastlake III cc: namedroppers@ops.ietf.org, iesg@ietf.org Subject: Re: Last Call: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 04 Feb 2005 12:10:47 +0700 Message-ID: <11745.1107493847@munnari.OZ.AU> 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 Date: Wed, 2 Feb 2005 22:51:14 -0500 (EST) From: Donald Eastlake III Message-ID: | > 'MAY' versus 'may' | | Yes, seems right to me to be MAY. I wouldn't bother. MAY means nothing in 2119, that is, all it means is that is optional. That's what it would also mean written as "may", so you gain nothing. Of course you also loose nothing by the change, and it perhaps looks more consistent with 2119 to do it as MAY. The problem comes that people who see MAY for may, start to write MAY NOT for "may not". That one doesn't work at all. First, MAY NOT doesn't exist in 2119, so that term has no meaning as a term, leaving just the 2119 MAY, together with a "not" in a strange typographical convention. Since "MAY" means that whatever it applies to is optional, the NOT really is just noise (you may "do this", or you can chose not to, which is the same as you may "not do this" or you can chose not to "not do this", that is, you can choose to do it). But in English, and in the way people usually use the phrase, "may not" means something more like "must not", which it turns out is nothing like what "MAY NOT" means from 2119. To avoid this, the best thing is to simply discourage use of the 2119 MAY completely. kre ps: as it was uses in 1123 etc, MAY was fine, there it had a specific role. It is possible in some other doc using 2119 to desire a similar result, so I am not suggesting that MAY be deleted from 2119 - just that its use be confined to where there's a particular need, which is not just where there's something that happens to be optional, we don't need magic words for that. -- to unsubscribe send a message to namedroppers-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 Feb 4 08:04: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 IAA22696 for ; Fri, 4 Feb 2005 08:04:09 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Cx341-000JDu-QN for namedroppers-data@psg.com; Fri, 04 Feb 2005 12:59:57 +0000 Received: from [158.38.152.233] (helo=eikenes.alvestrand.no) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Cx33z-000JDT-8Y for namedroppers@ops.ietf.org; Fri, 04 Feb 2005 12:59:55 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6EF5A61B8E; Fri, 4 Feb 2005 13:59:54 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04221-06; Fri, 4 Feb 2005 13:59:53 +0100 (CET) Received: from halvestr-w2k02.emea.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5D81261C25; Fri, 4 Feb 2005 13:59:51 +0100 (CET) Date: Fri, 04 Feb 2005 08:22:14 +0100 From: Harald Tveit Alvestrand To: Robert Elz Cc: bmanning@vacation.karoshi.com, iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: Last Call: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard Message-ID: <95C734BD3EFDB009DFAC6009@B50854F0A9192E8EC6CDA126> In-Reply-To: <11515.1107493248@munnari.OZ.AU> References: <88EAAA4611113A9E57A00593@B50854F0A9192E8EC6CDA126> <20050202043943.GA8153@vacation.karoshi.com.> <11972.1107330243@munnari.OZ.AU> <11515.1107493248@munnari.OZ.AU> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no 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 Expanding slightly on the one-liner: What I am saying is that the version that is put before the IESG for the IESG's approval should include notes that track the revision history of the document, if these are available. In very many cases, members of the IESG have followed the document's development, seen Last Call comments, have formed opinions on particular issues, and may even have given specific feedback on the document in previous versions. A list of "what has changed since the last version of the document" helps both to make sure known issues have been addressed and to point out which sections of the document have NOT changed since the previous instance reviewed. Of course, such sections SHOULD be clearly marked with "RFC Editor, please delete this on publication". This is my opinion, formed over 8 years of trying to get documents through the IESG. You have stated your opinion, but you are not saying anything about your reasons for that opinion. Neither opinion is based on a published rule of the IETF, AFAIK; there's nothing indicating that the IETF has consensus on one of these. I'll stick to my opinion for now. Harald --On 4. februar 2005 12:00 +0700 Robert Elz wrote: > Date: Wed, 02 Feb 2005 23:34:31 +0100 > From: Harald Tveit Alvestrand > Message-ID: <88EAAA4611113A9E57A00593@B50854F0A9192E8EC6CDA126> > > | > In this case, what may be considered unusual, is that there has been > | > no mention on the namedroppers list of the need for the -05 draft, > nothing | > about what required it, and nothing about what has changed > in it. Maybe | > the draft says that - but if it is the version that > is to be published as | > an RFC, it shouldn't (RFCs should not contain > info about what changed | > in the last few versions of the I-D, nor > should they be having that kind | > of information editorially deleted > after approval). > | > | Yes, they should. > > I'm not sure what you're saying there exactly. If you mean that if > there are updates notes in a draft that is approved, then the rfc editor > should delete them, then yes, I agree. > > On the other hand, if you're saying that that is the proper way to do > things, then I disagree. > > The doc proposed (for IETF last call, at the very least) should be as > close as possible (as close as the boilerplate nonsense permits) to the > exact RFC that will be published. > > It is entirely possible that some readers may see some technical merit in > the update notes - that the doc is clear, but only because those notes > indicate what is going on, and why. Without the notes, a valid > objection might be made. If (non boilerplate) data is deleted after > approval, then a doc that shouldn't have been approved, can avoid > objections. > > The right way to do this, is to have the final draft of the doc (perhaps > the final version for WG last call, and certainly the version sent for > IETF last call) be the same as what will be the RFC - taht is, a new > version of the I-D should be publiched, where the only change is to > delete any extraneous material like this (and the I-D shouldn't be saying > this). > > Donald - if, as seems possible from other messages, you're going to > publish a new I-D, please send a version without noise, so that one can > be properly evaluated for IETF last call. > > 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 Feb 4 08:19: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 IAA24456 for ; Fri, 4 Feb 2005 08:19:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Cx3Ka-000M50-30 for namedroppers-data@psg.com; Fri, 04 Feb 2005 13:17:04 +0000 Received: from [65.205.251.74] (helo=colibri.verisign.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Cx3KX-000M4g-Tc for namedroppers@ops.ietf.org; Fri, 04 Feb 2005 13:17:02 +0000 Received: from mou1wnexc01.vcorp.ad.vrsn.com (mailer4.verisign.com [65.205.251.53]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id j14DGveC014132; Fri, 4 Feb 2005 05:16:57 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Fri, 4 Feb 2005 05:16:57 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD37038098@MOU1WNEXMB04.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" To: "'D. J. Bernstein'" , namedroppers@ops.ietf.org Subject: RE: Last Call: 'Domain Name System (DNS) Case Insensitivity Clari fication' to Proposed Standard Date: Fri, 4 Feb 2005 05:16:53 -0800 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=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of D. J. Bernstein > Mark Andrews writes: > > The convention applies whereever domain names are entered. > > Oh, really? I entered http://www.is\067.org into a browser > using your libresolv. Your web server responded with a ``Bad > Request'' message, rather than the www.isc.org web page. > > I have no objection to this document _if_ it is limited to zone files. This is exactly how it should be according to the HTTP URI specification. -- to unsubscribe send a message to namedroppers-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 Feb 4 10:02: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 KAA03287 for ; Fri, 4 Feb 2005 10:02:10 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Cx4ve-0007nt-Ev for namedroppers-data@psg.com; Fri, 04 Feb 2005 14:59:26 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Cx4vd-0007nX-7d for namedroppers@ops.ietf.org; Fri, 04 Feb 2005 14:59:25 +0000 Received: from [192.168.1.103] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j14ExEiq016994; Fri, 4 Feb 2005 09:59:15 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <198A730C2044DE4A96749D13E167AD37038098@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD37038098@MOU1WNEXMB04.vcorp.ad.vrsn.com> Date: Fri, 4 Feb 2005 09:59:14 -0500 To: iesg@ietf.org From: Edward Lewis Subject: RE: Last Call: ... Case Insensitivity Clarification ... Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.49 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.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Please advance this draft. It's concise, clear, defines the scope, and lays out the incompleteness of the original specification. This document makes no changes. My coding experience is in line with this draft. This is how I interpreted case insensitivity. I have no substantive disagreements with the draft. Others have mentioned that the DNS style of representing non-ASCII printable (whatever you might want to call them) is not in line with other systems. I do not believe that this is a germane issue. The draft is not proposing a means to express these octets, merely describing the method in place since the 1980's. The document is clear that it applies to the definition in RFC 1034 and 1035, which is sufficient to limit the scope. That URI's have what appear to be domain names in them is not an issue for DNS, it is an issue for that application area. As for process, I have read this document before, and now again. Using my judgement, there is nothing innocuous in the draft, nothing that would make me want to go back and "diff' it to see if the editor changed something "behind the WG's back." Given the simple nature of the document, it would take just a quick read of it to discover any "hidden" or "slipped in" problems. PS. I do somewhat agree that there is an editorial issue with "MAY" and may. I would suggest completely dropping the reference to RFC 2119 altogether. The original documents (1034 and 1035) don't use the terms, trying to retrofit formality is difficult. I have found this when editing the wildcard clarification document. However, this is not an issue that should (SHOULD?) hold up progress. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar "A noble spirit embiggens the smallest man." - Jebediah Springfield -- to unsubscribe send a message to namedroppers-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 Feb 4 10:18: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 KAA05444 for ; Fri, 4 Feb 2005 10:18:20 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Cx5Bw-000AV0-CN for namedroppers-data@psg.com; Fri, 04 Feb 2005 15:16:16 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Cx5Bv-000AUn-8h for namedroppers@ops.ietf.org; Fri, 04 Feb 2005 15:16:15 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 351822DF29; Fri, 4 Feb 2005 16:16:14 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 2EC092DF28; Fri, 4 Feb 2005 16:16:14 +0100 (CET) Date: Fri, 4 Feb 2005 16:16:13 +0100 (CET) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: Edward Lewis Cc: iesg@ietf.org, namedroppers@ops.ietf.org Subject: RE: Last Call: ... Case Insensitivity Clarification ... In-Reply-To: Message-ID: References: <198A730C2044DE4A96749D13E167AD37038098@MOU1WNEXMB04.vcorp.ad.vrsn.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=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 4 Feb 2005, Edward Lewis wrote: > Please advance this draft. I concur. 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 Fri Feb 4 10:25: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 KAA06327 for ; Fri, 4 Feb 2005 10:25:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1Cx5Jm-000BJZ-Qw for namedroppers-data@psg.com; Fri, 04 Feb 2005 15:24:22 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Cx5Jl-000BJ5-OE for namedroppers@ops.ietf.org; Fri, 04 Feb 2005 15:24:22 +0000 Received: from [192.168.1.103] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j14FOBUx017104; Fri, 4 Feb 2005 10:24:14 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <198A730C2044DE4A96749D13E167AD37038098@MOU1WNEXMB04.vcorp.ad.vrsn.com> Date: Fri, 4 Feb 2005 10:24:14 -0500 To: Edward Lewis From: Edward Lewis Subject: RE: Last Call: ... Case Insensitivity Clarification ... Cc: iesg@ietf.org, namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.49 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.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk As astute reader reported... At 9:59 -0500 2/4/05, Edward Lewis wrote: >judgement, there is nothing innocuous in the draft, nothing that would make s/there is nothing innocuous in the draft/the draft is innocuous/ or something to that extent. ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar "A noble spirit embiggens the smallest man." - Jebediah Springfield -- to unsubscribe send a message to namedroppers-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 Feb 4 18:26: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 SAA19451 for ; Fri, 4 Feb 2005 18:26:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CxClT-000I76-6M for namedroppers-data@psg.com; Fri, 04 Feb 2005 23:21:27 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.43 (FreeBSD)) id 1CxClR-000I6t-VY for namedroppers@ops.ietf.org; Fri, 04 Feb 2005 23:21:26 +0000 Received: (qmail 3913 invoked by uid 1016); 4 Feb 2005 23:21:51 -0000 Date: 4 Feb 2005 23:21:50 -0000 Message-ID: <20050204232150.3827.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: Last Call: 'Domain Name System (DNS) Case Insensitivity Clari fication' to Proposed Standard References: <198A730C2044DE4A96749D13E167AD37038098@MOU1WNEXMB04.vcorp.ad.vrsn.com> 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 Hallam-Baker, Phillip writes: > This is exactly how it should be according to the HTTP URI specification. But Mark just told us that \067 means c ``wherever domain names are entered.'' That's inconsistent in two ways with what actually happened: * The server did _not_ accept \067 as a substitute for c. * The client did _not_ convert \067 to c---which would have worked around the server's failure to accept \067. I think that the client and server are just fine, and that Mark's comment was a wild exaggeration. I now see that the draft under discussion makes the same wild exaggeration---it talks about all ``human readable and writable ASCII contexts'' rather than just zone files. Consequently I object to the draft as being blatantly inconsistent with (1) other IETF protocols, notably HTTP and SMTP, and (2) many existing user interfaces, such as the Firefox URL line and the qmail rcpthosts configuration-file format. I also object to the entire notion of the IETF trying to constrain user interfaces. If the IETF wants to define a zone-file format that can be transferred by FTP, fine---and I'll be happy to defend the goofy use of decimal in zone files for backwards compatibility---but the IETF has no business making declarations regarding _all_ formats. ---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 Feb 4 23:26: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 XAA10853 for ; Fri, 4 Feb 2005 23:26:28 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CxHS8-00040n-Hv for namedroppers-data@psg.com; Sat, 05 Feb 2005 04:21:48 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CxHS6-00040O-Sy for namedroppers@ops.ietf.org; Sat, 05 Feb 2005 04:21:47 +0000 Received: from [192.168.1.103] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j154LJUp019474; Fri, 4 Feb 2005 23:21:20 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20050204232150.3827.qmail@cr.yp.to> References: <198A730C2044DE4A96749D13E167AD37038098@MOU1WNEXMB04.vcorp.ad.vrsn.com> <20050204232150.3827.qmail@cr.yp.to> Date: Fri, 4 Feb 2005 23:21:23 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: Last Call: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard Cc: iesg@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.49 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.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 23:21 +0000 2/4/05, D. J. Bernstein wrote: >But Mark just told us that \067 means c ``wherever domain names are >entered.'' That's inconsistent in two ways with what actually happened: > > * The server did _not_ accept \067 as a substitute for c. > * The client did _not_ convert \067 to c---which would have worked > around the server's failure to accept \067. > >I think that the client and server are just fine, and that Mark's >comment was a wild exaggeration. Perhaps Mark's words are an overstatement. Looking at RFC 2396 (Uniform Resource Identifiers (URI): Generic Syntax), section 3.2.2 (Server-based Naming Authority), this text is found (chopped up): # URL schemes that involve the direct use of an IP-based protocol to a # specified server on the Internet use a common syntax for the server # component of the URI's scheme-specific data: # # @: ... # The host is a domain name of a network host, or its IPv4 address as a # set of four decimal digit groups separated by ".". Literal IPv6 # addresses are not supported. ... # host = hostname | IPv4address ... # Hostnames take the form described in Section 3 of [RFC1034] and # Section 2.1 of [RFC1123]: a sequence of domain labels separated by ... # To actually be "Uniform" as a resource locator, a URL hostname should # be a fully qualified domain name. In practice, however, the host # component may be a local domain literal. I find it interesting that section 3 of 1034 is called out here. The "\DDD" is not defined there, it is defined in RFC 1035 in section 5 (MASTER FILES), specifically in 5.1 (Format). From this I would take it that an implementation operating on URLs would not be required to parse the \DDD. An implementation could, under the mantra "liberal on receipt, conservative on send." Still, there is no requirement that an implementation make the entire syntax available to the GUI. An implementation is free to restrict what it allows to happen in a protocol, so long as it can speak (listen) the entire protocol. >I now see that the draft under discussion makes the same wild >exaggeration---it talks about all ``human readable and writable ASCII >contexts'' rather than just zone files. Consequently I object to the >draft as being blatantly inconsistent with (1) other IETF protocols, >notably HTTP and SMTP, and (2) many existing user interfaces, such as >the Firefox URL line and the qmail rcpthosts configuration-file format. "Wild exaggeration" is a bit melodramatic. It's not like the draft is claiming it would cure the common cold. But you have a point that it ought to stick to what is in zone files. Overall, I think this is a rather inconsequential point though, as this abstract and introduction do refer to RFC 1034 and 1035 (and not 2396, for example). >I also object to the entire notion of the IETF trying to constrain user >interfaces. If the IETF wants to define a zone-file format that can be >transferred by FTP, fine---and I'll be happy to defend the goofy use of >decimal in zone files for backwards compatibility---but the IETF has no >business making declarations regarding _all_ formats. I can't make this leap in the argument. I cannot see that the draft talks about user interfaces, just a (the original, standard) presentation format for DNS. You are right that there should never be an IETF effort to restrict what can be in an implementation. We should stick to what is needed for interoperability, while meeting requirements for functionality, operability, and simplicity. With that in mind, there's a protocol reason I can think of for having a master file format defined. The reason is this offers an alternative to zone transfers via port 53. At one time (and may still be true) the root zone was "file transferred" and not [A|I]XFR'd. The root servers are a mix of BIND and NSD, this wouldn't have been possible if NSD didn't have a Master File format to build to. (One can argue that such an arrangement is outmoded I guess, with VPNs, TSIG, etc. But changing an institutional practice is sometimes beyond the control of protocol wonks.) Beyond the on-the-wire protocol, there are two reasons for specifying a master file formats. It gives us a common language for discussing the protocol on a list like this. It also makes it easier to staff a DNS operations center - because there is a pool of people (or firms) that will be able to start "right away." Other than that, I don't think master files are important as they do not get passed around on port 53. It is important to remember that IETF specifications are for interoperability. An implementation is free to exceed the specifications, but exceeding it without extending the specification does not guarantee interoperability. As a customer for DNS software, I want to know that any implementation I decide to deploy would be compatible with my installed base so that I do not need to have a flag day should I choose to migrate. I wouldn't object to an implementation with non-standard features, but I would refrain from using them unless it was really compelling to do so. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar "A noble spirit embiggens the smallest man." - Jebediah Springfield -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From sgwzovg@wx88.net Sat Feb 5 18:05:23 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 SAA08171; Sat, 5 Feb 2005 18:05:20 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxZIW-0001lR-57; Sat, 05 Feb 2005 18:25:05 -0500 Received: from [221.211.176.33] (helo=USER-0919D6E94A) by mx2.foretec.com with smtp (Exim 4.24) id 1CxYzM-0000uz-QH; Sat, 05 Feb 2005 18:05:18 -0500 Received: from gaussian.fotofutura.com ([62.30.31.86]) by coalescent.fotofutura.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0O3O1614PZI8UN62@coalescent.fotofutura.com> for sabvxidr@ietf.org; Sun, 06 Feb 2005 01:01:08 +0200 (IST) Received: from culminate.calview.com ([216.168.224.63]) by gaussian.fotofutura.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0N1B089RGMF9EY78@gaussian.fotofutura.com> for sabvxidr@ietf.org (ORCPT sabvxidr@ietf.org); Sun, 06 Feb 2005 01:01:08 +0200 (IST) Received: from Antwan (IGLD-82-179-333-796.calview.com [64.5.1.150]) by balder.calview.com (Mirapoint Messaging Server MOS 3.3.7-GR) with ESMTP id DWZ20282 (AUTH Hatfield); Sun, 06 Feb 2005 00:56:08 +0200 (IST) Date: Sun, 06 Feb 2005 01:01:08 +0200 From: Gabrielle Campos Subject: system Update Alert - January 5th To: Sabvxidr Message-ID: <884394619972.YJA80125@cais.com> MIME-version: 1.0 Content-Type: multipart/alternative; boundary="----_001_4235_27I81NG8.81FN3702" X-Mailer: mPOP Web-Mail 2.19 X-Spam-Score: 5.3 (+++++) X-Spam-Flag: YES X-Scan-Signature: 31247fb3be228bb596db9127becad0bc This is a multi-part message in MIME format. ------_001_4235_27I81NG8.81FN3702 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7Bit HO||day Spec!al Bundle 1: W!NDoWS X,P Pro + oFFiCE X'P Pr0 = 80 Dollars W|nd0ws Software half prIce Bund|e 2: MacrOmedia Dreamwaver MX 20O4 + FLash MX 2oo4 - 100 D0|lars Laptop Magaz|ne : D|g!ta| PC 0pt!Ons BundLe 3: AdObe PhOtosh0p 7, Prem!ere 7, i|lustrat0r 10 - 12o D0Llars Y0U SHoULD HURRY!: oem The 0ffer is va|Id Unti|| February 12th StOck is l|mIted my appologizes Antwan Hatfield Hornere AnyCare Consulting, Beijing 100089, China Phone: 132-178-4768 Mobile: 218-844-8251 Email: sgwzovg@wx88.net your reply to this confirmation message is not needed This freeware is a 51 decade definite version NOTES: The contents of this e-mail is for information and should not be shirley compute lucia cavendish chimpanzee Time: Sun, 06 Feb 2005 01:01:08 +0200 ------_001_4235_27I81NG8.81FN3702 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7Bit We have Everyth|ng

Bund|e 1:
W1NDOWS X,P Pr0 and OFFiCE X'P Pro On|y 80 80 Dol|ars

Lead1ng SOftware such as:

BundLe 2:
Macr0media Dreamwaver MX 2o04 + Flash MX 2oO4 - 1oo D0Llars

Lapt0p MagazIne : D1g!tal ResuLts

Bund|e 3:
AdObe Ph0toshOp 7, Prem!ere 7, iL|ustrator 1o - 12o DoLLars

The 0ffer is va|Id Unt!L| February 12th
Cl!ck Now
StOck is lImited





your wachovia account

Antwan Hatfield
Fowler
BioNet, Jerusalem 93228, Israel
Phone: 845-714-4411
Mobile: 932-953-5676
Email: sgwzovg@wx88.net

please do not reply to this message

This package is a 71 decade complementary download

NOTES:

The contents of this reply is for manipulation and should not be petrel guarantor

puccini doll daniel

Time: Sun, 06 Feb 2005 01:01:08 +0200 ------_001_4235_27I81NG8.81FN3702-- From owner-namedroppers@ops.ietf.org Sun Feb 6 18:20:58 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07967 for ; Sun, 6 Feb 2005 18:20:58 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1Cxvcp-000FeA-AS for namedroppers-data@psg.com; Sun, 06 Feb 2005 23:15:31 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1Cxvcn-000Fdv-2p for namedroppers@ops.ietf.org; Sun, 06 Feb 2005 23:15:29 +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 D4BB0677F2 for ; Sun, 6 Feb 2005 23:15:27 +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 j16NEwf1019860; Mon, 7 Feb 2005 10:14:59 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200502062314.j16NEwf1019860@drugs.dv.isc.org> To: Edward Lewis Cc: namedroppers@ops.ietf.org, iesg@ietf.org From: Mark Andrews Subject: Re: Last Call: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard In-reply-to: Your message of "Fri, 04 Feb 2005 23:21:23 CDT." Date: Mon, 07 Feb 2005 10:14:58 +1100 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 > At 23:21 +0000 2/4/05, D. J. Bernstein wrote: > > >But Mark just told us that \067 means c ``wherever domain names are > >entered.'' That's inconsistent in two ways with what actually happened: > > > > * The server did _not_ accept \067 as a substitute for c. > > * The client did _not_ convert \067 to c---which would have worked > > around the server's failure to accept \067. > > > >I think that the client and server are just fine, and that Mark's > >comment was a wild exaggeration. > > Perhaps Mark's words are an overstatement. Looking at RFC 2396 > (Uniform Resource Identifiers (URI): Generic Syntax), section 3.2.2 > (Server-based Naming Authority), this text is found (chopped up): I stand by my words. URLs take hostnames. RFC 2396 just described the subset of hostnames that are representable in the DNS. The encoding applies to applications which take domain names. Most applications, including web browsers, take hostnames. The fact that you can represent most (but not all) hostnames in the DNS just adds to the confusion. Hostnames of length 254 and 255 cannot be represented in the DNS. I don't expect a application that takes a hostname to accept \DDD. I do expect a application that takes a domain name to accept \DDD. Mail clients take hostnames and/or mail domains (which are syntactically identical to hostnames). Telnet, ssh, ftp etc. take hostnames. > # URL schemes that involve the direct use of an IP-based protocol to a > # specified server on the Internet use a common syntax for the server > # component of the URI's scheme-specific data: > # > # @: > ... > # The host is a domain name of a network host, or its IPv4 address as a > # set of four decimal digit groups separated by ".". Literal IPv6 > # addresses are not supported. > ... > # host = hostname | IPv4address > ... > # Hostnames take the form described in Section 3 of [RFC1034] and > # Section 2.1 of [RFC1123]: a sequence of domain labels separated by > ... > # To actually be "Uniform" as a resource locator, a URL hostname should > # be a fully qualified domain name. In practice, however, the host > # component may be a local domain literal. > > I find it interesting that section 3 of 1034 is called out here. The > "\DDD" is not defined there, it is defined in RFC 1035 in section 5 > (MASTER FILES), specifically in 5.1 (Format). > > From this I would take it that an implementation operating on URLs > would not be required to parse the \DDD. An implementation could, > under the mantra "liberal on receipt, conservative on send." > > Still, there is no requirement that an implementation make the entire > syntax available to the GUI. An implementation is free to restrict > what it allows to happen in a protocol, so long as it can speak > (listen) the entire protocol. > > >I now see that the draft under discussion makes the same wild > >exaggeration---it talks about all ``human readable and writable ASCII > >contexts'' rather than just zone files. Consequently I object to the > >draft as being blatantly inconsistent with (1) other IETF protocols, > >notably HTTP and SMTP, and (2) many existing user interfaces, such as > >the Firefox URL line and the qmail rcpthosts configuration-file format. > > "Wild exaggeration" is a bit melodramatic. It's not like the draft > is claiming it would cure the common cold. But you have a point that > it ought to stick to what is in zone files. Overall, I think this is > a rather inconsequential point though, as this abstract and > introduction do refer to RFC 1034 and 1035 (and not 2396, for > example). > > >I also object to the entire notion of the IETF trying to constrain user > >interfaces. If the IETF wants to define a zone-file format that can be > >transferred by FTP, fine---and I'll be happy to defend the goofy use of > >decimal in zone files for backwards compatibility---but the IETF has no > >business making declarations regarding _all_ formats. > > I can't make this leap in the argument. I cannot see that the draft > talks about user interfaces, just a (the original, standard) > presentation format for DNS. > > You are right that there should never be an IETF effort to restrict > what can be in an implementation. We should stick to what is needed > for interoperability, while meeting requirements for functionality, > operability, and simplicity. > > With that in mind, there's a protocol reason I can think of for > having a master file format defined. The reason is this offers an > alternative to zone transfers via port 53. At one time (and may > still be true) the root zone was "file transferred" and not > [A|I]XFR'd. The root servers are a mix of BIND and NSD, this > wouldn't have been possible if NSD didn't have a Master File format > to build to. (One can argue that such an arrangement is outmoded I > guess, with VPNs, TSIG, etc. But changing an institutional practice > is sometimes beyond the control of protocol wonks.) > > Beyond the on-the-wire protocol, there are two reasons for specifying > a master file formats. It gives us a common language for discussing > the protocol on a list like this. It also makes it easier to staff a > DNS operations center - because there is a pool of people (or firms) > that will be able to start "right away." > > Other than that, I don't think master files are important as they do > not get passed around on port 53. > > It is important to remember that IETF specifications are for > interoperability. An implementation is free to exceed the > specifications, but exceeding it without extending the specification > does not guarantee interoperability. > > As a customer for DNS software, I want to know that any > implementation I decide to deploy would be compatible with my > installed base so that I do not need to have a flag day should I > choose to migrate. I wouldn't object to an implementation with > non-standard features, but I would refrain from using them unless it > was really compelling to do so. > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-571-434-5468 > NeuStar > > "A noble spirit embiggens the smallest man." - Jebediah Springfield > > -- > to 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 Sun Feb 6 19:04: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 TAA11659 for ; Sun, 6 Feb 2005 19:04:26 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CxwLR-000Kk4-Pv for namedroppers-data@psg.com; Mon, 07 Feb 2005 00:01:37 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CxwLP-000Kjm-Um for namedroppers@ops.ietf.org; Mon, 07 Feb 2005 00:01:35 +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 5074567503 for ; Mon, 7 Feb 2005 00:01:35 +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 j1701INB020004 for ; Mon, 7 Feb 2005 11:01:18 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200502070001.j1701INB020004@drugs.dv.isc.org> To: namedroppers@ops.ietf.org From: Mark Andrews Subject: I have a feeling that the rules for setting TC need tweaking Date: Mon, 07 Feb 2005 11:01:18 +1100 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 Currently the RFCs say don't set TC on truncation in the additional section. There are a number of cases where it is necessary to set TC for additional section truncation. * when using TSIG and after reserving enough space to fit the TSIG response there is not enough space left for the answer / authority sections. This is logically equivalent to additional section truncation. * when using EDNS and after reserving enough space to fit the EDNS response there is not enough space left for the answer / authority sections. This is logically equivalent to additional section truncation. * RFC 2181 precludes sending glue as a answer. This leads to cases where, with big enough RRsets, you can't return the requested glue even as the first additional RRset. I propose that nameservers be allowed to set TC in these case. For the glue case above it would only be if it will not fit as the first glue RRset in the additional section with or without space being reserved for TSIG and/or EDNS. 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 Mon Feb 7 00:02: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 AAA02568 for ; Mon, 7 Feb 2005 00:02:20 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1Cy0y1-0008mi-DQ for namedroppers-data@psg.com; Mon, 07 Feb 2005 04:57:45 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1Cy0y0-0008mS-Cs for namedroppers@ops.ietf.org; Mon, 07 Feb 2005 04:57:44 +0000 Received: from [192.168.1.103] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j174vZtr000371; Sun, 6 Feb 2005 23:57:37 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200502070001.j1701INB020004@drugs.dv.isc.org> References: <200502070001.j1701INB020004@drugs.dv.isc.org> Date: Sun, 6 Feb 2005 23:57:37 -0500 To: Mark Andrews From: Edward Lewis Subject: Re: I have a feeling that the rules for setting TC need tweaking Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.49 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.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:01 +1100 2/7/05, Mark Andrews wrote: > I propose that nameservers be allowed to set TC in these > case. For the glue case above it would only be if it will > not fit as the first glue RRset in the additional section > with or without space being reserved for TSIG and/or EDNS. This sounds like a matter that will need some study...you know the rules - send in a personal draft. ;) Sounds like there will be some sharp corner cases to consider. Perhaps you mean to say that if a response will have TSIG/EDNS0 in it, then TC is set for some definition of incompleteness in the additional section. For non-TSIG/EDNS0 servers you'd get FORMERR anyway, what happens to the current deployed base of TSIG/EDNS0-capable servers? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar "A noble spirit embiggens the smallest man." - Jebediah Springfield -- to unsubscribe send a message to namedroppers-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 Feb 7 02:15: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 CAA24860 for ; Mon, 7 Feb 2005 02:15:34 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1Cy33R-000ORR-TG for namedroppers-data@psg.com; Mon, 07 Feb 2005 07:11:29 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1Cy33Q-000OR4-MY for namedroppers@ops.ietf.org; Mon, 07 Feb 2005 07:11:28 +0000 Received: (qmail 92082 invoked by uid 1016); 7 Feb 2005 07:11:53 -0000 Date: 7 Feb 2005 07:11:53 -0000 Message-ID: <20050207071153.92081.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Cc: iesg@ietf.org Subject: Re: Last Call: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard References: <200502062314.j16NEwf1019860@drugs.dv.isc.org> 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 This document specifies \065 as a synonym for capital A---not just in zone files, but in all ``human readable and writable ASCII contexts.'' That specification is plainly erroneous. Nobody is willing to defend the notion that this screwy decimal system should be allowed in URLs, SMTP RCPT, etc. The obvious fix is to limit the document to zone files. ---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 Feb 7 11:16:27 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13323 for ; Mon, 7 Feb 2005 11:16:27 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CyBRY-000P9f-RD for namedroppers-data@psg.com; Mon, 07 Feb 2005 16:08:56 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CyBRX-000P9N-QZ for namedroppers@ops.ietf.org; Mon, 07 Feb 2005 16:08:56 +0000 Received: from [10.31.32.120] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j17G8mU4002575; Mon, 7 Feb 2005 11:08:49 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Mon, 7 Feb 2005 11:08:55 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: empty non-terminal Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.49 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.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Does anyone know of a published definition of "empty non-terminal"? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar "A noble spirit embiggens the smallest man." - Jebediah Springfield -- to unsubscribe send a message to namedroppers-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 Feb 7 11:36:01 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14648 for ; Mon, 7 Feb 2005 11:36:00 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CyBnt-0001Vl-Hy for namedroppers-data@psg.com; Mon, 07 Feb 2005 16:32:01 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CyBnr-0001VL-Vp for namedroppers@ops.ietf.org; Mon, 07 Feb 2005 16:32:00 +0000 Received: from [10.31.32.120] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j17GVrS4002683; Mon, 7 Feb 2005 11:31:53 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Mon, 7 Feb 2005 11:31:57 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: a new wild card can of worms Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.49 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.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Considering discussions on wildcards that have arisen in the context of "spam-reducing efforts involving the DNS" I think that perhaps something needs to be clarified in RFC 2782. In RFC 2782 the SRV RR is defined. # The format of the SRV RR # # Here is the format of the SRV RR, whose DNS type code is 33: # # _Service._Proto.Name TTL Class SRV Priority Weight Port Target Note that the owner name is "_Service._Proto.Name" Later this appears: # Name # The domain this RR refers to. The SRV RR is unique in that the # name one searches for is not this name; the example near the end # shows this clearly. Admittedly, the example referred to: # In this example, a client of the "foobar" service in the # "example.com." domain needs an SRV lookup of # "_foobar._tcp.example.com." and possibly A lookups of "new-fast- # box.example.com." and/or the other hosts named. The size of the SRV # reply is approximately 365 bytes: is correct and should clear things up, but still some folks have come to believe that "_foobar._tcp.*.example." would cover the foobar service over TCP on all unlisted "hosts." IMHO, the start of the confusion it the mixing of what the SRV document calls a "Name" and the use of domain names in wildcards. I'm thinking this as I re-edit text on (empty) non-terminal wildcards. Should I try to add a "Wildcards and SRV" record section? (As in the Wildcards and NS, CNAME, etc., that are already in the draft.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar "A noble spirit embiggens the smallest man." - Jebediah Springfield -- to unsubscribe send a message to namedroppers-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 Feb 7 11:59: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 LAA16656 for ; Mon, 7 Feb 2005 11:59:54 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CyCCH-0004M6-7Z for namedroppers-data@psg.com; Mon, 07 Feb 2005 16:57:13 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CyCCG-0004Lu-H7 for namedroppers@ops.ietf.org; Mon, 07 Feb 2005 16:57:12 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 5182C13E05 for ; Mon, 7 Feb 2005 16:57:12 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: empty non-terminal In-Reply-To: Message from Edward Lewis of "Mon, 07 Feb 2005 11:08:55 EST." X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 07 Feb 2005 16:57:12 +0000 Message-Id: <20050207165712.5182C13E05@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 > Does anyone know of a published definition of "empty non-terminal"? i believe that this particular hairball was first coughed up in [RFC2136 7.16]. -- to unsubscribe send a message to namedroppers-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 Feb 7 12:09: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 MAA17673 for ; Mon, 7 Feb 2005 12:09:40 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CyCLk-0005wq-U1 for namedroppers-data@psg.com; Mon, 07 Feb 2005 17:07:00 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CyCLh-0005w9-Nf for namedroppers@ops.ietf.org; Mon, 07 Feb 2005 17:06:57 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id F13D5C2DAB; Mon, 7 Feb 2005 17:06:56 +0000 (GMT) Date: Mon, 07 Feb 2005 17:06:57 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Edward Lewis , namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: a new wild card can of worms Message-ID: <654C1466398D937628768133@[192.168.100.25]> In-Reply-To: References: X-Mailer: Mulberry/4.0.0a4 (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 07 February 2005 11:31 -0500 Edward Lewis wrote: > Later this appears: > ># Name ># The domain this RR refers to. The SRV RR is unique in that the ># name one searches for is not this name; the example near the end ># shows this clearly. Is the ambiguity you are referring to the confusion between "Name" (capital 'n') and the two uses of "name" in the 2nd line? Or the fact that that what is searched for is a QNAME not a "name" (whatever that means here) and that cannot contain wildcards? Or the that it is unclear whether wildcard-clarify's prescriptions apply to the "name one searches for", it's corresponding RR in the zonefile, or "this name"? The definition itself seems to be self-referential to me: "The domain this RR refers to" does not seem right - the RR *refers* to the entire concatenation of labels doesn't it (i.e. the RR *is* _Service._Proto.Name)? Surely this is in fact "the label(s) to which the _Service and _Proto are prepended by the resolver to generate a QNAME to perform a search" or similar. 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 Mon Feb 7 12:24: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 MAA19498 for ; Mon, 7 Feb 2005 12:24:56 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CyCa4-0008Cg-9V for namedroppers-data@psg.com; Mon, 07 Feb 2005 17:21:48 +0000 Received: from [208.31.42.42] (helo=xuxa.iecc.com) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1CyCa1-0008C9-NC for namedroppers@ops.ietf.org; Mon, 07 Feb 2005 17:21:46 +0000 Received: (qmail 24275 invoked by uid 100); 7 Feb 2005 17:21:43 -0000 Date: 7 Feb 2005 17:21:43 -0000 Message-ID: <20050207172143.24274.qmail@xuxa.iecc.com> From: John Levine To: namedroppers@ops.ietf.org Subject: Re: a new wild card can of worms In-Reply-To: Organization: I.E.C.C., Trumansburg NY USA Cc: Ed.Lewis@neustar.biz Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 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 >is correct and should clear things up, but still some folks have come >to believe that "_foobar._tcp.*.example." would cover the foobar >service over TCP on all unlisted "hosts." I don't know anyone in the non-loony anti-spam community who thinks that x.*.y matches anything other than x.*.y, but I don't see any reason that a sentence or two reminding people that SRV prefixes don't change the wildcard rules would hurt. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY http://www.taugh.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 7 12:31:27 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20283 for ; Mon, 7 Feb 2005 12:31:27 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CyCgt-0008yW-Gp for namedroppers-data@psg.com; Mon, 07 Feb 2005 17:28:51 +0000 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CyCgs-0008yF-8P for namedroppers@ops.ietf.org; Mon, 07 Feb 2005 17:28:50 +0000 Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.12.11/8.12.11/TechFak/2004/05/05/sjaenick) with ESMTP id j17HSnmw016976 for ; Mon, 7 Feb 2005 18:28:49 +0100 (MET) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id j17HSmG29666 for ; Mon, 7 Feb 2005 18:28:48 +0100 (MET) Message-Id: <200502071728.j17HSmG29666@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: a new wild card can of worms In-reply-to: Your message of "Mon, 07 Feb 2005 11:31:57 EST." 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: <29661.1107797327.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Mon, 07 Feb 2005 18:28:48 +0100 From: Peter Koch 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 Edward Lewis wrote: > is correct and should clear things up, but still some folks have come > to believe that "_foobar._tcp.*.example." would cover the foobar > service over TCP on all unlisted "hosts." yes, but not necessarily due to an ambiguity in 2782. > IMHO, the start of the confusion it the mixing of what the SRV > document calls a "Name" and the use of domain names in wildcards. RFC 2782 combines the syntax definition of the SRV RR type with the definition of a very particular use case. That's why the owner name is given structured with "Name" being only one component. > Should I try to add a "Wildcards and SRV" record section? (As in the > Wildcards and NS, CNAME, etc., that are already in the draft.) Extending the query space by prefixes was probably introduced by SRV RRs but is not restricted to those. So, the pecularities of 'wildcards and SRV' do not arise from the RR type but from the particular use of the namespace it kind of induces. Now, hopefully you manage to explain this to the target audience better than I did. -Peter PS: And please don't forget the hint that *.example.com doesn't really match "everything" below "example.com" :-) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 7 13:33: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 NAA27476 for ; Mon, 7 Feb 2005 13:33:33 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CyDdf-000G5m-Tj for namedroppers-data@psg.com; Mon, 07 Feb 2005 18:29:35 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CyDdc-000G5V-IB for namedroppers@ops.ietf.org; Mon, 07 Feb 2005 18:29:33 +0000 Received: from [10.31.32.120] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j17ITN3i003303; Mon, 7 Feb 2005 13:29:24 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <654C1466398D937628768133@[192.168.100.25]> References: <654C1466398D937628768133@[192.168.100.25]> Date: Mon, 7 Feb 2005 13:29:16 -0500 To: Alex Bligh From: Edward Lewis Subject: Re: a new wild card can of worms Cc: Edward Lewis , namedroppers@ops.ietf.org, Alex Bligh Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.49 on 66.92.146.160 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 At 17:06 +0000 2/7/05, Alex Bligh wrote: >--On 07 February 2005 11:31 -0500 Edward Lewis wrote: > >> Later this appears: >> >># Name >># The domain this RR refers to. The SRV RR is unique in that the >># name one searches for is not this name; the example near the end >># shows this clearly. > >Is the ambiguity you are referring to the confusion between "Name" (capital >'n') and the two uses of "name" in the 2nd line? Or the fact that that >what is searched for is a QNAME not a "name" (whatever that means here) >and that cannot contain wildcards? Or the that it is unclear whether >wildcard-clarify's prescriptions apply to the "name one searches for", >it's corresponding RR in the zonefile, or "this name"? Definitely yes to the first option. Basically, "Name" in caps != the QNAME, whether or not any asterisk label or wildcard is in play. What I would add in a section on SRV's and wildcards would be something along the lines that the "matched portion of the name is the service-protocol-*N*ame, not just *N*ame." E.g. *.example. TXT "blah" _foobar._tcp.*.example. TXT "blah blah" QNAME = "_foobar._tcp.host1.example.", QTYPE=TXT (ignore QCLASS) The rdata returned is "blah". (Not the other.) >The definition itself seems to be self-referential to me: "The domain this >RR refers to" does not seem right - the RR *refers* to the entire >concatenation of labels doesn't it (i.e. the RR *is* _Service._Proto.Name)? >Surely this is in fact "the label(s) to which the _Service and _Proto are >prepended by the resolver to generate a QNAME to perform a search" or >similar. I guess the misunderstanding is what you mean by "prepended by the resolver." IMHO, a DNS protocol element ought not change the name being looked up. However, the shim layer between the GUI and the DNS protocol element is allowed to make the transformation. By "resolver" above, do you mean the code that is specific to an application or specific to the DNS? Maybe perhaps specific to a middleware-like shim. Hmmm. > >Alex -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar "A noble spirit embiggens the smallest man." - Jebediah Springfield -- to unsubscribe send a message to namedroppers-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 Feb 7 13:42: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 NAA28441 for ; Mon, 7 Feb 2005 13:42:38 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CyDo5-000HeO-C0 for namedroppers-data@psg.com; Mon, 07 Feb 2005 18:40:21 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CyDo4-000Hdo-As for namedroppers@ops.ietf.org; Mon, 07 Feb 2005 18:40:20 +0000 Received: from [10.31.32.120] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j17IeDut003373; Mon, 7 Feb 2005 13:40:14 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200502071728.j17HSmG29666@grimsvotn.TechFak.Uni-Bielefeld.DE> References: <200502071728.j17HSmG29666@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Mon, 7 Feb 2005 13:40:19 -0500 To: Peter Koch From: Edward Lewis Subject: Re: a new wild card can of worms Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.49 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:28 +0100 2/7/05, Peter Koch wrote: >RFC 2782 combines the syntax definition of the SRV RR type with the definition >of a very particular use case. That's why the owner name is given structured I think you've pointed out something important...mixing use case with definition. (Like the WhoIs "spec" rewrite.) >PS: And please don't forget the hint that *.example.com doesn't really > match "everything" below "example.com" :-) Had to think about that one. Again. ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar "A noble spirit embiggens the smallest man." - Jebediah Springfield -- to unsubscribe send a message to namedroppers-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 Feb 7 13:42:42 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28459 for ; Mon, 7 Feb 2005 13:42:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CyDnx-000HdU-Mr for namedroppers-data@psg.com; Mon, 07 Feb 2005 18:40:13 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CyDnw-000HdH-Gw for namedroppers@ops.ietf.org; Mon, 07 Feb 2005 18:40:13 +0000 Received: from [10.31.32.120] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j17Ie5IM003369; Mon, 7 Feb 2005 13:40:06 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20050207165712.5182C13E05@sa.vix.com> References: <20050207165712.5182C13E05@sa.vix.com> Date: Mon, 7 Feb 2005 13:37:31 -0500 To: Paul Vixie From: Edward Lewis Subject: Re: empty non-terminal Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.49 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:57 +0000 2/7/05, Paul Vixie wrote: >> Does anyone know of a published definition of "empty non-terminal"? > >i believe that this particular hairball was first coughed up in >[RFC2136 7.16]. Thanks... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar "A noble spirit embiggens the smallest man." - Jebediah Springfield -- to unsubscribe send a message to namedroppers-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 Feb 7 13:46: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 NAA28935 for ; Mon, 7 Feb 2005 13:46:48 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CyDsp-000IKw-Kx for namedroppers-data@psg.com; Mon, 07 Feb 2005 18:45:15 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CyDsn-000IKX-Ny for namedroppers@ops.ietf.org; Mon, 07 Feb 2005 18:45:13 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id D22F7C2DFE; Mon, 7 Feb 2005 18:45:12 +0000 (GMT) Date: Mon, 07 Feb 2005 18:45:13 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Edward Lewis Cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: a new wild card can of worms Message-ID: <0F45FF36D07C6308BDE1FBDC@[192.168.100.25]> In-Reply-To: References: <654C1466398D937628768133@[192.168.100.25]> X-Mailer: Mulberry/4.0.0a4 (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 07 February 2005 13:29 -0500 Edward Lewis wrote: >> The definition itself seems to be self-referential to me: "The domain >> this RR refers to" does not seem right - the RR *refers* to the entire >> concatenation of labels doesn't it (i.e. the RR *is* >> _Service._Proto.Name)? Surely this is in fact "the label(s) to which the >> _Service and _Proto are prepended by the resolver to generate a QNAME to >> perform a search" or similar. > > I guess the misunderstanding is what you mean by "prepended by the > resolver." IMHO, a DNS protocol element ought not change the name being > looked up. However, the shim layer between the GUI and the DNS protocol > element is allowed to make the transformation. > > By "resolver" above, do you mean the code that is specific to an > application or specific to the DNS? Maybe perhaps specific to a > middleware-like shim. I meant they are prepended by the (waves hands) "thing doing the resolving" i.e. before it gets to wire protocol. That could either be the application, a shim layer, or the low level resolver library (I don't think there is any reason why a resolver library might not do the concatenation itself and have a function like int getsrvrecord(char * name, char * service, char * proto, struct srvrecord * data ); and in fact for all I know libresolv might have just that - too lazy to look). 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 Mon Feb 7 13:54: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 NAA29792 for ; Mon, 7 Feb 2005 13:54:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CyDwT-000IwV-O1 for namedroppers-data@psg.com; Mon, 07 Feb 2005 18:49:01 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CyDwK-000IvW-HZ for namedroppers@ops.ietf.org; Mon, 07 Feb 2005 18:48:52 +0000 Received: from [10.31.32.120] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j17ImhD5003432; Mon, 7 Feb 2005 13:48:44 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <0F45FF36D07C6308BDE1FBDC@[192.168.100.25]> References: <654C1466398D937628768133@[192.168.100.25]> <0F45FF36D07C6308BDE1FBDC@[192.168.100.25]> Date: Mon, 7 Feb 2005 13:48:50 -0500 To: Alex Bligh From: Edward Lewis Subject: Re: a new wild card can of worms Cc: Edward Lewis , namedroppers@ops.ietf.org, Alex Bligh Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.49 on 66.92.146.160 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 At 18:45 +0000 2/7/05, Alex Bligh wrote: >--On 07 February 2005 13:29 -0500 Edward Lewis wrote: > >>> The definition itself seems to be self-referential to me: "The domain >>> this RR refers to" does not seem right - the RR *refers* to the entire >>> concatenation of labels doesn't it (i.e. the RR *is* >>> _Service._Proto.Name)? Surely this is in fact "the label(s) to which the >>> _Service and _Proto are prepended by the resolver to generate a QNAME to >>> perform a search" or similar. >> >> I guess the misunderstanding is what you mean by "prepended by the >> resolver." IMHO, a DNS protocol element ought not change the name being >> looked up. However, the shim layer between the GUI and the DNS protocol >> element is allowed to make the transformation. >> >> By "resolver" above, do you mean the code that is specific to an >> application or specific to the DNS? Maybe perhaps specific to a >> middleware-like shim. > >I meant they are prepended by the (waves hands) "thing doing the >resolving" i.e. before it gets to wire protocol. That could either >be the application, a shim layer, or the low level resolver library >(I don't think there is any reason why a resolver library might not >do the concatenation itself and have a function like > int getsrvrecord(char * name, char * service, char * proto, > struct srvrecord * data ); >and in fact for all I know libresolv might have just that - too lazy >to look). Ahh, good point there. I suppose it's not so important whether the thing that takes a *N*ame and makes a QNAME is a "DNS element" so much as it's important that what appears on the wire is the QNAME and, even more so, that the server answering the query does not do the *N*ame to QNAME conversion. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar "A noble spirit embiggens the smallest man." - Jebediah Springfield -- to unsubscribe send a message to namedroppers-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 Feb 7 14:35: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 OAA03645 for ; Mon, 7 Feb 2005 14:35:46 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CyEc0-000OfD-3R for namedroppers-data@psg.com; Mon, 07 Feb 2005 19:31:56 +0000 Received: from [207.65.203.98] (helo=goose.ehsco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CyEbw-000Oex-R3 for namedroppers@ops.ietf.org; Mon, 07 Feb 2005 19:31:52 +0000 Received: from [192.168.0.102] (cable0-stm-219.gmpexpress.net [63.147.50.219]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by goose.ehsco.com (Postfix ) with ESMTP id B2AF33116B; Mon, 7 Feb 2005 13:31:51 -0600 (CST) Message-ID: <4207C240.7030702@ehsco.com> Date: Mon, 07 Feb 2005 14:32:16 -0500 From: "Eric A. Hall" User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Andrews Cc: namedroppers@ops.ietf.org Subject: Re: I have a feeling that the rules for setting TC need tweaking References: <200502070001.j1701INB020004@drugs.dv.isc.org> In-Reply-To: <200502070001.j1701INB020004@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1 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 On 2/6/2005 7:01 PM, Mark Andrews wrote: > * RFC 2181 precludes sending glue as a answer. This leads > to cases where, with big enough RRsets, you can't return > the requested glue even as the first additional RRset. This isn't really needed if all the necessary prerequisites are met and the resolver does what it's supposed to. It wouldn't save anything, other than providing explicit pointer instead of having to rely on implicit logics. I mean, if the NS RRs are present and the parent servers are reachable, the resolver can go and fetch the glue data separately without being told that the data would not fit in the answer (it would still have to do that even if the TC flag were set so the only real shortcut here would be in the resolver logic). There are also a lot of really weird corner cases here... my QTYPE ADDR draft had some gymnastics that could be difficult to work with in such a case, for exammple, but there's also a huge installed base of RFCs and implementations alike that have been hammered on when TC is appropriate. There's probably another way to skin this cat that doesn't cause problems for core/critical handling that's already out there. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 7 15:40: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 PAA11554 for ; Mon, 7 Feb 2005 15:40:45 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CyFbc-0006hd-OW for namedroppers-data@psg.com; Mon, 07 Feb 2005 20:35:36 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CyFbb-0006hE-7e for namedroppers@ops.ietf.org; Mon, 07 Feb 2005 20:35:35 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10660; Mon, 7 Feb 2005 15:35:30 -0500 (EST) Message-Id: <200502072035.PAA10660@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-experiments-00.txt Date: Mon, 07 Feb 2005 15:35:30 -0500 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 : DNSSEC Experiments Author(s) : D. Blacka Filename : draft-ietf-dnsext-dnssec-experiments-00.txt Pages : 15 Date : 2005-2-4 In the long history of the development of the DNS security [1] extensions (DNSSEC), a number of alternate methodologies and modifications have been proposed and rejected for practical, rather than strictly technical, reasons. There is a desire to be able to experiment with these alternate methods in the public DNS. This document describes a methodology for deploying alternate, non-backwards-compatible, DNSSEC methodologies in an experimental fashion without disrupting the deployment of standard DNSSEC. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-experiments-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-experiments-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-experiments-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-7160440.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-experiments-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-experiments-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-7160440.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 7 15:42:01 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11808 for ; Mon, 7 Feb 2005 15:42:01 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CyFfv-0007Cy-7r for namedroppers-data@psg.com; Mon, 07 Feb 2005 20:40:03 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CyFft-0007C0-Th for namedroppers@ops.ietf.org; Mon, 07 Feb 2005 20:40:02 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j17KdAC15064; Mon, 7 Feb 2005 22:39:10 +0200 Date: Mon, 7 Feb 2005 22:39:10 +0200 (EET) From: Pekka Savola To: "Eric A. Hall" cc: Mark Andrews , namedroppers@ops.ietf.org Subject: Re: I have a feeling that the rules for setting TC need tweaking In-Reply-To: <4207C240.7030702@ehsco.com> Message-ID: References: <200502070001.j1701INB020004@drugs.dv.isc.org> <4207C240.7030702@ehsco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 On Mon, 7 Feb 2005, Eric A. Hall wrote: > On 2/6/2005 7:01 PM, Mark Andrews wrote: > >> * RFC 2181 precludes sending glue as a answer. This leads >> to cases where, with big enough RRsets, you can't return >> the requested glue even as the first additional RRset. > > This isn't really needed if all the necessary prerequisites are met and > the resolver does what it's supposed to. It wouldn't save anything, other > than providing explicit pointer instead of having to rely on implicit > logics. I mean, if the NS RRs are present and the parent servers are > reachable, the resolver can go and fetch the glue data separately without > being told that the data would not fit in the answer (it would still have > to do that even if the TC flag were set so the only real shortcut here > would be in the resolver logic). FWIW, draft-ietf-dnsop-ipv6-issues-10.txt section 4.4 (with subsections) discuss some of these problems in a specific context. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 7 17:21: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 RAA05696 for ; Mon, 7 Feb 2005 17:21:07 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CyHCY-000JeI-V6 for namedroppers-data@psg.com; Mon, 07 Feb 2005 22:17:50 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CyHCX-000Jdr-Ku for namedroppers@ops.ietf.org; Mon, 07 Feb 2005 22:17:50 +0000 Received: from [10.31.32.120] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j17MHdNw004492; Mon, 7 Feb 2005 17:17:40 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Mon, 7 Feb 2005 17:17:46 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: NS, *, and DNSSEC Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.49 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 In writing up a seciton on the interaction of NS's, *'s and DNSSEC, I found a problem. This comes from the Nove IETF meeting: For example, a zone has the following records (not complete): *.example. IN 3600 NS bogon.example. *.example. IN 3600 NSEC twn.example. NS NSEC RRSIG twn.example. IN 3600 NSEC twp.example. ... twn.example. IN 3600 RRSIG NSEC ... signed by example. ... twp.example. IN 3600 NSEC example. ... The query is for: two.example. IN NS The response is : Authoritative Answer, response code of no error Answer: two.example. IN 3600 NS bogon.example. Authority: twn.example. IN 3600 NSEC twp.example. ... twn.example. IN 3600 RRSIG NSEC ... signed by example. ... What I've noticed is that there is no signature over the NS in the answer section. It's not there because the signer would not have signed the *.example NS record - valid because if I were looking for www.*.example, this behaves as any other delegation. But without the RRSIG (NS), there's a tear in the fabric of DNSSEC. Let's say that there is no wildcard NS set. The response for the query would then be: Authoritative answer, authoritative name error: Answer: Authority: twn.example. IN 3600 NSEC twp.example. ... twn.example. IN 3600 RRSIG NSEC ... signed by example. ... example. IN 3600 NSEC a.example. ... example. IN 3600 RRSIG NSEC ... signed by example. ... This shows there is no "two.example." and no "*.example." This message is vulnerable to a substitution of this: Authoritative Answer, response code of no error Answer: two.example. IN 3600 NS bogon.example. Authority: twn.example. IN 3600 NSEC twp.example. ... twn.example. IN 3600 RRSIG NSEC ... signed by example. ... There is no way to tell that the latter response was substituted for the first. If the client asks the authority for "*.example" with type ANY, then the client can deduce a problem as an afterthought. OTOH, the client will probably detect that the zone is signed, hence seeing an unsigned answer is suspicious and will probably reject the answer. However, the latter answer would be legit given the example zone data. This is a really small and annoying corner case, no doubt. I don't like it because it means there is a point of ambiguity in the protocol, a non-determinism. We had the same problem with opt-in. It's probably not right to sign *-owned NS records not at the apex, but that is what would be needed for this particular record. I doubt that we would want the servers have to hold signatures for all wildcards and only dole them out when the wildcards are in answer sections (i.e. expanded). Suggestions? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar "A noble spirit embiggens the smallest man." - Jebediah Springfield -- to unsubscribe send a message to namedroppers-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 Feb 7 17:32: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 RAA07047 for ; Mon, 7 Feb 2005 17:32:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CyHOK-000KvN-QU for namedroppers-data@psg.com; Mon, 07 Feb 2005 22:30:00 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CyHOJ-000Kur-0s for namedroppers@ops.ietf.org; Mon, 07 Feb 2005 22:29:59 +0000 Received: from [10.31.32.120] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j17MTo79004544; Mon, 7 Feb 2005 17:29:50 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 7 Feb 2005 17:29:58 -0500 To: Edward Lewis From: Edward Lewis Subject: Re: NS, *, and DNSSEC Cc: namedroppers@ops.ietf.org, ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.49 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 A problem with the problem... the *.example. NSEC shouldn't exist. At 17:17 -0500 2/7/05, Edward Lewis wrote: >In writing up a seciton on the interaction of NS's, *'s and DNSSEC, >I found a problem. > >This comes from the Nove IETF meeting: > > For example, a zone has the following records (not complete): > > *.example. IN 3600 NS bogon.example. > *.example. IN 3600 NSEC twn.example. NS NSEC RRSIG > > twn.example. IN 3600 NSEC twp.example. ... > twn.example. IN 3600 RRSIG NSEC ... signed by example. ... > > twp.example. IN 3600 NSEC example. ... > > The query is for: two.example. IN NS > > The response is : > Authoritative Answer, response code of no error > Answer: > two.example. IN 3600 NS bogon.example. > Authority: > twn.example. IN 3600 NSEC twp.example. ... > twn.example. IN 3600 RRSIG NSEC ... signed by example. ... > >What I've noticed is that there is no signature over the NS in the >answer section. It's not there because the signer would not have >signed the *.example NS record - valid because if I were looking for >www.*.example, this behaves as any other delegation. > >But without the RRSIG (NS), there's a tear in the fabric of DNSSEC. > >Let's say that there is no wildcard NS set. The response for the >query would then be: > > Authoritative answer, authoritative name error: > Answer: > Authority: > twn.example. IN 3600 NSEC twp.example. ... > twn.example. IN 3600 RRSIG NSEC ... signed by example. ... > example. IN 3600 NSEC a.example. ... > example. IN 3600 RRSIG NSEC ... signed by example. ... > >This shows there is no "two.example." and no "*.example." > >This message is vulnerable to a substitution of this: > Authoritative Answer, response code of no error > Answer: > two.example. IN 3600 NS bogon.example. > Authority: > twn.example. IN 3600 NSEC twp.example. ... > twn.example. IN 3600 RRSIG NSEC ... signed by example. ... > >There is no way to tell that the latter response was substituted for >the first. If the client asks the authority for "*.example" with >type ANY, then the client can deduce a problem as an afterthought. > >OTOH, the client will probably detect that the zone is signed, hence >seeing an unsigned answer is suspicious and will probably reject the >answer. However, the latter answer would be legit given the example >zone data. > >This is a really small and annoying corner case, no doubt. I don't >like it because it means there is a point of ambiguity in the >protocol, a non-determinism. We had the same problem with opt-in. > >It's probably not right to sign *-owned NS records not at the apex, >but that is what would be needed for this particular record. I >doubt that we would want the servers have to hold signatures for all >wildcards and only dole them out when the wildcards are in answer >sections (i.e. expanded). > >Suggestions? >-- >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >Edward Lewis +1-571-434-5468 >NeuStar > >"A noble spirit embiggens the smallest man." - Jebediah Springfield > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar "A noble spirit embiggens the smallest man." - Jebediah Springfield -- to unsubscribe send a message to namedroppers-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 Feb 7 17:34: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 RAA07202 for ; Mon, 7 Feb 2005 17:34:51 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CyHPq-000L8m-JF for namedroppers-data@psg.com; Mon, 07 Feb 2005 22:31:34 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CyHPp-000L8V-1v for namedroppers@ops.ietf.org; Mon, 07 Feb 2005 22:31:33 +0000 Received: from [10.31.32.120] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j17MVN0c004559; Mon, 7 Feb 2005 17:31:24 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 7 Feb 2005 17:31:31 -0500 To: Edward Lewis From: Edward Lewis Subject: Re: NS, *, and DNSSEC Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.49 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 Forget the problem with the problem, the problem was correct before it. (My mind's fuse blew when writing this.) At 17:29 -0500 2/7/05, Edward Lewis wrote: >A problem with the problem... the *.example. NSEC shouldn't exist. > >At 17:17 -0500 2/7/05, Edward Lewis wrote: >>In writing up a seciton on the interaction of NS's, *'s and DNSSEC, >>I found a problem. >> >>This comes from the Nove IETF meeting: >> >> For example, a zone has the following records (not complete): >> >> *.example. IN 3600 NS bogon.example. >> *.example. IN 3600 NSEC twn.example. NS NSEC RRSIG >> >> twn.example. IN 3600 NSEC twp.example. ... >> twn.example. IN 3600 RRSIG NSEC ... signed by example. ... >> >> twp.example. IN 3600 NSEC example. ... >> >> The query is for: two.example. IN NS >> >> The response is : >> Authoritative Answer, response code of no error >> Answer: >> two.example. IN 3600 NS bogon.example. >> Authority: >> twn.example. IN 3600 NSEC twp.example. ... >> twn.example. IN 3600 RRSIG NSEC ... signed by example. ... >> >>What I've noticed is that there is no signature over the NS in the >>answer section. It's not there because the signer would not have >>signed the *.example NS record - valid because if I were looking >>for www.*.example, this behaves as any other delegation. >> >>But without the RRSIG (NS), there's a tear in the fabric of DNSSEC. >> >>Let's say that there is no wildcard NS set. The response for the >>query would then be: >> >> Authoritative answer, authoritative name error: >> Answer: >> Authority: >> twn.example. IN 3600 NSEC twp.example. ... >> twn.example. IN 3600 RRSIG NSEC ... signed by example. ... >> example. IN 3600 NSEC a.example. ... >> example. IN 3600 RRSIG NSEC ... signed by example. ... >> >>This shows there is no "two.example." and no "*.example." >> >>This message is vulnerable to a substitution of this: >> Authoritative Answer, response code of no error >> Answer: >> two.example. IN 3600 NS bogon.example. >> Authority: >> twn.example. IN 3600 NSEC twp.example. ... >> twn.example. IN 3600 RRSIG NSEC ... signed by example. ... >> >>There is no way to tell that the latter response was substituted >>for the first. If the client asks the authority for "*.example" >>with type ANY, then the client can deduce a problem as an >>afterthought. >> >>OTOH, the client will probably detect that the zone is signed, >>hence seeing an unsigned answer is suspicious and will probably >>reject the answer. However, the latter answer would be legit given >>the example zone data. >> >>This is a really small and annoying corner case, no doubt. I don't >>like it because it means there is a point of ambiguity in the >>protocol, a non-determinism. We had the same problem with opt-in. >> >>It's probably not right to sign *-owned NS records not at the apex, >>but that is what would be needed for this particular record. I >>doubt that we would want the servers have to hold signatures for >>all wildcards and only dole them out when the wildcards are in >>answer sections (i.e. expanded). >> >>Suggestions? >>-- >>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >>Edward Lewis +1-571-434-5468 >>NeuStar >> >>"A noble spirit embiggens the smallest man." - Jebediah Springfield >> >>-- >>to unsubscribe send a message to namedroppers-request@ops.ietf.org with >>the word 'unsubscribe' in a single line as the message text body. >>archive: > >-- >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >Edward Lewis +1-571-434-5468 >NeuStar > >"A noble spirit embiggens the smallest man." - Jebediah Springfield -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar "A noble spirit embiggens the smallest man." - Jebediah Springfield -- to unsubscribe send a message to namedroppers-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 Feb 7 18:15:02 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13935 for ; Mon, 7 Feb 2005 18:15:00 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CyI3n-000085-GR for namedroppers-data@psg.com; Mon, 07 Feb 2005 23:12:51 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CyI3l-00007s-Ju for namedroppers@ops.ietf.org; Mon, 07 Feb 2005 23:12:49 +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 C3604677EF for ; Mon, 7 Feb 2005 23:12:48 +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 j17NCRGb062820; Tue, 8 Feb 2005 10:12:27 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200502072312.j17NCRGb062820@drugs.dv.isc.org> To: "Eric A. Hall" Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: I have a feeling that the rules for setting TC need tweaking In-reply-to: Your message of "Mon, 07 Feb 2005 14:32:16 CDT." <4207C240.7030702@ehsco.com> Date: Tue, 08 Feb 2005 10:12:27 +1100 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 > > On 2/6/2005 7:01 PM, Mark Andrews wrote: > > > * RFC 2181 precludes sending glue as a answer. This leads > > to cases where, with big enough RRsets, you can't return > > the requested glue even as the first additional RRset. > > This isn't really needed if all the necessary prerequisites are met and > the resolver does what it's supposed to. It wouldn't save anything, other > than providing explicit pointer instead of having to rely on implicit > logics. I mean, if the NS RRs are present and the parent servers are > reachable, the resolver can go and fetch the glue data separately without > being told that the data would not fit in the answer (it would still have > to do that even if the TC flag were set so the only real shortcut here > would be in the resolver logic). You are missing the point. The query that needs the TC set *is* the glue query to the parent. If you are querying the parent (NET) for NS.EXAMPLE.NET/A and the size of the RRsets for EXAMPLE.NET/NS and NS.EXAMPLE.NET/A exceed what can fit in the UDP response you have a case were you can't fetch the glue. Note we can't assume we can reach any other servers for EXAMPLE.NET as we may have tried all of them and are just missing the glue for NS.EXAMPLE.NET. Older servers returned the NS.EXAMPLE.NET/A record in the answer section so if it didn't fit you would get TC set and fall back to TCP. RFC 2181 changes the section where the glue is returned. > There are also a lot of really weird corner cases here... my QTYPE ADDR > draft had some gymnastics that could be difficult to work with in such a > case, for exammple, but there's also a huge installed base of RFCs and > implementations alike that have been hammered on when TC is appropriate. > > There's probably another way to skin this cat that doesn't cause problems > for core/critical handling that's already out there. > > -- > Eric A. Hall http://www.ehsco.com/ > Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- 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 Mon Feb 7 21:01: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 VAA27586 for ; Mon, 7 Feb 2005 21:01:31 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CyKby-000JMo-2k for namedroppers-data@psg.com; Tue, 08 Feb 2005 01:56:18 +0000 Received: from [207.65.203.98] (helo=goose.ehsco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CyKbv-000JMW-RC for namedroppers@ops.ietf.org; Tue, 08 Feb 2005 01:56:15 +0000 Received: from [192.168.0.102] (cable0-stm-219.gmpexpress.net [63.147.50.219]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by goose.ehsco.com (Postfix ) with ESMTP id 446B33144D; Mon, 7 Feb 2005 19:56:14 -0600 (CST) Message-ID: <42081C3B.1090509@ehsco.com> Date: Mon, 07 Feb 2005 20:56:11 -0500 From: "Eric A. Hall" User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Andrews Cc: namedroppers@ops.ietf.org Subject: Re: I have a feeling that the rules for setting TC need tweaking References: <200502072312.j17NCRGb062820@drugs.dv.isc.org> In-Reply-To: <200502072312.j17NCRGb062820@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1 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 On 2/7/2005 6:12 PM, Mark Andrews wrote: >>On 2/6/2005 7:01 PM, Mark Andrews wrote: >> >>> * RFC 2181 precludes sending glue as a answer. This leads >>> to cases where, with big enough RRsets, you can't return >>> the requested glue even as the first additional RRset. >> >>This isn't really needed if all the necessary prerequisites are met and >>the resolver does what it's supposed to. It wouldn't save anything, other >>than providing explicit pointer instead of having to rely on implicit >>logics. I mean, if the NS RRs are present and the parent servers are >>reachable, the resolver can go and fetch the glue data separately without >>being told that the data would not fit in the answer (it would still have >>to do that even if the TC flag were set so the only real shortcut here >>would be in the resolver logic). > > You are missing the point. The query that needs the TC set *is* > the glue query to the parent. > > If you are querying the parent (NET) for NS.EXAMPLE.NET/A and the > size of the RRsets for EXAMPLE.NET/NS and NS.EXAMPLE.NET/A exceed > what can fit in the UDP response you have a case were you can't > fetch the glue. Sure you can: ask the servers for the NS.EXAMPLE.NET/A discretely. That's what they have to do anyway, so it's best to just bonk them and say as much. My main point is that changing the meaning of TC is probably bad. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 7 21:29:27 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29947 for ; Mon, 7 Feb 2005 21:29:27 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CyL5m-000Myk-Uc for namedroppers-data@psg.com; Tue, 08 Feb 2005 02:27:06 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1CyL5l-000MyP-Fz for namedroppers@ops.ietf.org; Tue, 08 Feb 2005 02:27:05 +0000 Received: (qmail 77926 invoked from network); 8 Feb 2005 03:01:15 -0000 Received: from yahoobb219001188041.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.41) by necom830.hpcl.titech.ac.jp with SMTP; 8 Feb 2005 03:01:15 -0000 Message-ID: <420823A5.4020301@necom830.hpcl.titech.ac.jp> Date: Tue, 08 Feb 2005 11:27:49 +0900 From: Masataka Ohta Organization: Tokyo Institute of Technology 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: "Eric A. Hall" CC: Mark Andrews , namedroppers@ops.ietf.org Subject: Re: I have a feeling that the rules for setting TC need tweaking References: <200502072312.j17NCRGb062820@drugs.dv.isc.org> <42081C3B.1090509@ehsco.com> In-Reply-To: <42081C3B.1090509@ehsco.com> Content-Type: text/plain; charset=us-ascii; 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=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Eric A. Hall wrote: > Sure you can: ask the servers for the NS.EXAMPLE.NET/A discretely. That's > what they have to do anyway, so it's best to just bonk them and say as > much. My main point is that changing the meaning of TC is probably bad. RFC1034 To fix this problem, a zone contains "glue" RRs which are not part of the authoritative data, and are address RRs for the servers. These RRs are only necessary if the name server's name is "below" the cut, and are only used as part of a referral response. 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 Feb 7 22:11: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 WAA03290 for ; Mon, 7 Feb 2005 22:11:54 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CyLjk-0001jh-JY for namedroppers-data@psg.com; Tue, 08 Feb 2005 03:08:24 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CyLji-0001jP-GR for namedroppers@ops.ietf.org; Tue, 08 Feb 2005 03:08:22 +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 B42EB677F4 for ; Tue, 8 Feb 2005 03:08:21 +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 j18381ZH011668; Tue, 8 Feb 2005 14:08:01 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200502080308.j18381ZH011668@drugs.dv.isc.org> To: "Eric A. Hall" Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: I have a feeling that the rules for setting TC need tweaking In-reply-to: Your message of "Mon, 07 Feb 2005 20:56:11 CDT." <42081C3B.1090509@ehsco.com> Date: Tue, 08 Feb 2005 14:08:01 +1100 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 > > On 2/7/2005 6:12 PM, Mark Andrews wrote: > >>On 2/6/2005 7:01 PM, Mark Andrews wrote: > >> > >>> * RFC 2181 precludes sending glue as a answer. This leads > >>> to cases where, with big enough RRsets, you can't return > >>> the requested glue even as the first additional RRset. > >> > >>This isn't really needed if all the necessary prerequisites are met and > >>the resolver does what it's supposed to. It wouldn't save anything, other > >>than providing explicit pointer instead of having to rely on implicit > >>logics. I mean, if the NS RRs are present and the parent servers are > >>reachable, the resolver can go and fetch the glue data separately without > >>being told that the data would not fit in the answer (it would still have > >>to do that even if the TC flag were set so the only real shortcut here > >>would be in the resolver logic). > > > > You are missing the point. The query that needs the TC set *is* > > the glue query to the parent. > > > > If you are querying the parent (NET) for NS.EXAMPLE.NET/A and the > > size of the RRsets for EXAMPLE.NET/NS and NS.EXAMPLE.NET/A exceed > > what can fit in the UDP response you have a case were you can't > > fetch the glue. > > Sure you can: ask the servers for the NS.EXAMPLE.NET/A discretely. That's > what they have to do anyway, so it's best to just bonk them and say as > much. My main point is that changing the meaning of TC is probably bad. F implement RFC 2181 rules. Note it has the glue for A.GTLD-SERVERS.NET and it is NOT returned in the ANSWER section. Now let the NS RRset for NET get bigger and / or the A RRset for A.GTLD-SERVERS.NET get bigger so that their combined sizes exceed 476 octets. Prior to RFC 2181 you would just set TC as you couldn't fit the response into the ANSWER and AUTHORITY sections. With RFC 2181 we still need to get the same information returned with the same space constaints however the A RRset now appears in the ADDITIONAL section and the current rules say that you don't set TC so all you return is the NS RRset and any other additonal RRsets that still fit. You don't get the glue you are requesting. You don't get any indication that if you were to retry the query with TCP that you would be able to get the glue. I know people will say that this is contrived. Add DNSSEC, with associate DS, RRSIG(DS) an OPT records, and a broken firewall forcing the client to use a 512 byte UDP size to the picture and it becomes a lot less contrived. ; <<>> DiG 8.3 <<>> a.gtld-servers.net @f.root-servers.net +norec ; (2 servers found) ;; res options: init defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13343 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 15 ;; QUERY SECTION: ;; a.gtld-servers.net, type = A, class = IN ;; AUTHORITY SECTION: net. 2D IN NS B.gtld-servers.net. net. 2D IN NS C.gtld-servers.net. net. 2D IN NS D.gtld-servers.net. net. 2D IN NS E.gtld-servers.net. net. 2D IN NS F.gtld-servers.net. net. 2D IN NS G.gtld-servers.net. net. 2D IN NS H.gtld-servers.net. net. 2D IN NS I.gtld-servers.net. net. 2D IN NS J.gtld-servers.net. net. 2D IN NS K.gtld-servers.net. net. 2D IN NS L.gtld-servers.net. net. 2D IN NS M.gtld-servers.net. net. 2D IN NS a.gtld-servers.net. ;; ADDITIONAL SECTION: a.gtld-servers.net. 2D IN A 192.5.6.30 a.gtld-servers.net. 2D IN AAAA 2001:503:a83e::2:30 B.gtld-servers.net. 2D IN A 192.33.14.30 B.gtld-servers.net. 2D IN AAAA 2001:503:231d::2:30 C.gtld-servers.net. 2D IN A 192.26.92.30 D.gtld-servers.net. 2D IN A 192.31.80.30 E.gtld-servers.net. 2D IN A 192.12.94.30 F.gtld-servers.net. 2D IN A 192.35.51.30 G.gtld-servers.net. 2D IN A 192.42.93.30 H.gtld-servers.net. 2D IN A 192.54.112.30 I.gtld-servers.net. 2D IN A 192.43.172.30 J.gtld-servers.net. 2D IN A 192.48.79.30 K.gtld-servers.net. 2D IN A 192.52.178.30 L.gtld-servers.net. 2D IN A 192.41.162.30 M.gtld-servers.net. 2D IN A 192.55.83.30 ;; Total query time: 179 msec ;; FROM: drugs.dv.isc.org to SERVER: 2001:500::1035 ;; WHEN: Tue Feb 8 13:41:02 2005 ;; MSG SIZE sent: 36 rcvd: 506 -- 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 Tue Feb 8 01:07: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 BAA14174 for ; Tue, 8 Feb 2005 01:07:07 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CyOSV-000NVF-Sk for namedroppers-data@psg.com; Tue, 08 Feb 2005 06:02:47 +0000 Received: from [202.12.73.64] (helo=fivedots.coe.psu.ac.th) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CyOSU-000NUu-CC for namedroppers@ops.ietf.org; Tue, 08 Feb 2005 06:02:46 +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 1CyOSS-0004y9-00; Tue, 08 Feb 2005 13:02:44 +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 j1862ACx011760; Tue, 8 Feb 2005 13:02:10 +0700 (ICT) From: Robert Elz To: Mark Andrews cc: "Eric A. Hall" , namedroppers@ops.ietf.org Subject: Re: I have a feeling that the rules for setting TC need tweaking In-Reply-To: <200502080308.j18381ZH011668@drugs.dv.isc.org> References: <200502080308.j18381ZH011668@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 08 Feb 2005 13:02:10 +0700 Message-ID: <11874.1107842530@munnari.OZ.AU> 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 I'm not sure what all the fuss is about here. The "rules" for not setting TC when an additional section is truncated are just to make it clear that additional data is not supposed to be mandatory, and forcing a TCP request to fetch it is just plain stupid. It makes no sense though to try and prevent the server setting TC any time it feels it needs to (it is the one that will suffer from having to deal with TCP after all). All that is needed is for the server to include nothing additional, and set TC. That's identical to a reply with a truncated answer/auth section, and causes a TCP retry (the client cannot possibly tell that there wasn't more needed for that section that simply didn't fit). If you prefer, send a baby reply, with nothing but header with TC set in it (no RR's, except the question, at all). kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 8 03:37: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 DAA15498 for ; Tue, 8 Feb 2005 03:37:15 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CyQny-000JNx-Q7 for namedroppers-data@psg.com; Tue, 08 Feb 2005 08:33:06 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CyQnv-000JNg-4F for namedroppers@ops.ietf.org; Tue, 08 Feb 2005 08:33:03 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 602F32DE2F; Tue, 8 Feb 2005 09:33:01 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 5EBCA2DE24; Tue, 8 Feb 2005 09:33:01 +0100 (CET) Date: Tue, 8 Feb 2005 09:33:01 +0100 (CET) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: NS, *, and DNSSEC In-Reply-To: Message-ID: References: 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 On Mon, 7 Feb 2005, Edward Lewis wrote: > In writing up a seciton on the interaction of NS's, *'s and DNSSEC, I > found a problem. > > This comes from the Nove IETF meeting: > > For example, a zone has the following records (not complete): > > *.example. IN 3600 NS bogon.example. > *.example. IN 3600 NSEC twn.example. NS NSEC RRSIG > > twn.example. IN 3600 NSEC twp.example. ... > twn.example. IN 3600 RRSIG NSEC ... signed by example. ... > > twp.example. IN 3600 NSEC example. ... > > The query is for: two.example. IN NS > > The response is : > Authoritative Answer, response code of no error > Answer: > two.example. IN 3600 NS bogon.example. > Authority: > twn.example. IN 3600 NSEC twp.example. ... > twn.example. IN 3600 RRSIG NSEC ... signed by example. ... > > What I've noticed is that there is no signature over the NS in the > answer section. It's not there because the signer would not have > signed the *.example NS record - valid because if I were looking for > www.*.example, this behaves as any other delegation. > > But without the RRSIG (NS), there's a tear in the fabric of DNSSEC. > > Let's say that there is no wildcard NS set. The response for the > query would then be: > > Authoritative answer, authoritative name error: > Answer: > Authority: > twn.example. IN 3600 NSEC twp.example. ... > twn.example. IN 3600 RRSIG NSEC ... signed by example. ... > example. IN 3600 NSEC a.example. ... > example. IN 3600 RRSIG NSEC ... signed by example. ... > > This shows there is no "two.example." and no "*.example." > > This message is vulnerable to a substitution of this: > Authoritative Answer, response code of no error > Answer: > two.example. IN 3600 NS bogon.example. > Authority: > twn.example. IN 3600 NSEC twp.example. ... > twn.example. IN 3600 RRSIG NSEC ... signed by example. ... > > There is no way to tell that the latter response was substituted for > the first. If the client asks the authority for "*.example" with > type ANY, then the client can deduce a problem as an afterthought. > > OTOH, the client will probably detect that the zone is signed, hence > seeing an unsigned answer is suspicious and will probably reject the > answer. However, the latter answer would be legit given the example > zone data. > > This is a really small and annoying corner case, no doubt. I don't > like it because it means there is a point of ambiguity in the > protocol, a non-determinism. We had the same problem with opt-in. > > It's probably not right to sign *-owned NS records not at the apex, > but that is what would be needed for this particular record. I doubt > that we would want the servers have to hold signatures for all > wildcards and only dole them out when the wildcards are in answer > sections (i.e. expanded). > > Suggestions? You must include the appropriate NSEC (and concomitant RRSIG) to prove that the delegation is not secured. So, in your latter example: Authoritative Answer, response code of no error Answer: two.example. IN 3600 NS bogon.example. Authority: twn.example. IN 3600 NSEC twp.example. ... twn.example. IN 3600 RRSIG NSEC ... signed by example. ... You MUST include a NSEC for two.example. In this case: *.example. IN 3600 NSEC twn.example. NS NSEC RRSIG (but then with expanded wildcard). In other words, a resolver would drop the response. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 8 08:38: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 IAA08901 for ; Tue, 8 Feb 2005 08:38:53 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CyVVA-000AJn-RO for namedroppers-data@psg.com; Tue, 08 Feb 2005 13:34:00 +0000 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CyVV8-000AJL-JS for namedroppers@ops.ietf.org; Tue, 08 Feb 2005 13:33:58 +0000 Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.12.11/8.12.11/TechFak/2004/05/05/sjaenick) with ESMTP id j18DXur4022820 for ; Tue, 8 Feb 2005 14:33:57 +0100 (MET) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id j18DXuN01894 for ; Tue, 8 Feb 2005 14:33:56 +0100 (MET) Message-Id: <200502081333.j18DXuN01894@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: Last Call: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard In-reply-to: Your message of "Mon, 07 Feb 2005 10:14:58 +1100." <200502062314.j16NEwf1019860@drugs.dv.isc.org> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1889.1107869635.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Tue, 08 Feb 2005 14:33:56 +0100 From: Peter Koch X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mark Andrews wrote: {IESG removed from Cc} > I stand by my words. URLs take hostnames. RFC 2396 just > described the subset of hostnames that are representable in > the DNS. RFC 2396 has recently been obsoleted by RFC 3986. That now uses a Thingy Formerly Known As Hostname. > names. Most applications, including web browsers, take > hostnames. The fact that you can represent most (but not all) > hostnames in the DNS just adds to the confusion. > > Hostnames of length 254 and 255 cannot be represented in the DNS. Yes, but "domain names" of length 254 or 255 cannot either - due to the fact that the wire format needs two more octets than the FQDN text representation. > I don't expect a application that takes a hostname to accept > \DDD. I do expect a application that takes a domain name to > accept \DDD. Now it may be time to dig out your long since expired Internet Draft again ... > Telnet, ssh, ftp etc. take hostnames. Weird enough they should use IDNs - at a different layer, though. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 8 09:33: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 JAA12843 for ; Tue, 8 Feb 2005 09:33:55 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CyWOl-000IuB-6l for namedroppers-data@psg.com; Tue, 08 Feb 2005 14:31:27 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CyWOj-000Itv-Hy for namedroppers@ops.ietf.org; Tue, 08 Feb 2005 14:31:26 +0000 Received: from [10.31.32.120] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j18EV3v9011671; Tue, 8 Feb 2005 09:31:05 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 8 Feb 2005 08:26:37 -0500 To: Roy Arends From: Edward Lewis Subject: Re: NS, *, and DNSSEC Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.49 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 9:33 +0100 2/8/05, Roy Arends wrote: >You must include the appropriate NSEC (and concomitant RRSIG) to prove >that the delegation is not secured. Why "must include?" This isn't a delegation, it's an authoritative answer. By virtue of following what is in 1034/4.3.2/3.c instead of b, we aren't dealing with a delegation point. >In other words, a resolver would drop the response. The problem is that when we decide to let the server treat the expanded wildcard NS as "just other data" we are messing with the signer and validator's mind. If we were to revert to treating the * NS expansion as a cut point, the signer and validator are happy, but the server is different. Options are (I am including discarded ones for completeness): 1) Alter the name servers to never accept a * NS record, whether via zone load, AXFR, IXFR, or dynamic update. 2) Alter the algorithm in 4.3.2 to exclude expanding NS records in step 3, part c. 3) Alter the rules in the signer to apply the signature to a * NS and then instruct the server to not include the RRSIG when adding this to the authority section. Option 3 is complicated because there is one execution path that goes through part b (the referral message result) that needs to be maintained as legal. I'm not as worried that we need to instruct the validator to understand this, that's the easy part. The problem is that we have a situation in the protocol where there are two distinctly different yet plausible answers to a query. The validator cannot distinguish which is right - meaning we are failing the source authenticity and data integrity goals. Before getting too excited about this, this is a really rare corner case we are talking about. The QTYPE has to be NS for this to come up, and rarely does anyone ask for the NS set outside of debugging operations. (Wildcards are not expanded in the authority section.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar "A noble spirit embiggens the smallest man." - Jebediah Springfield -- to unsubscribe send a message to namedroppers-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 Feb 8 10:51: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 KAA19490 for ; Tue, 8 Feb 2005 10:51:38 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CyXaU-00049C-7E for namedroppers-data@psg.com; Tue, 08 Feb 2005 15:47:38 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CyXaT-00048w-8Q for namedroppers@ops.ietf.org; Tue, 08 Feb 2005 15:47:37 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id D78442DF21; Tue, 8 Feb 2005 16:47:35 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id D38052DE2F; Tue, 8 Feb 2005 16:47:35 +0100 (CET) Date: Tue, 8 Feb 2005 16:47:35 +0100 (CET) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: NS, *, and DNSSEC In-Reply-To: Message-ID: References: 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 I envision endless discussion over beer... (the beer makes it A Good Thing). On Tue, 8 Feb 2005, Edward Lewis wrote: > At 9:33 +0100 2/8/05, Roy Arends wrote: > >You must include the appropriate NSEC (and concomitant RRSIG) to prove > >that the delegation is not secured. > > Why "must include?" This isn't a delegation, it's an authoritative > answer. By virtue of following what is in 1034/4.3.2/3.c instead of > b, we aren't dealing with a delegation point. Ah, not a delegation, eh ? Okay, why wouldn't this NS set be signed ? dnssec-records: The NS RRset that appears at the zone apex name MUST be signed, but the NS RRsets that appear at delegation points (that is, the NS RRsets in the parent zone that delegate the name to the child zone's name servers) MUST NOT be signed. Glue address RRsets associated with delegations MUST NOT be signed. Note that wildcard NS records are not 'zone cuts' or delegation points by your reading of the algorithm in 1034/4.3.2/3 Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 8 11:12: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 LAA21019 for ; Tue, 8 Feb 2005 11:12:04 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CyXvm-0007TG-Av for namedroppers-data@psg.com; Tue, 08 Feb 2005 16:09:38 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CyXvl-0007St-7Y for namedroppers@ops.ietf.org; Tue, 08 Feb 2005 16:09:37 +0000 Received: from [10.31.32.120] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j18G9IRR012104; Tue, 8 Feb 2005 11:09:18 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 8 Feb 2005 11:09:32 -0500 To: Roy Arends From: Edward Lewis Subject: Re: NS, *, and DNSSEC Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.49 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:47 +0100 2/8/05, Roy Arends wrote: >Ah, not a delegation, eh ? Not in this context, no. >Okay, why wouldn't this NS set be signed ? Because in another context it is a delegation. ;) (Ever take a Quantum Physics course?) >dnssec-records: > > The NS RRset that appears at the zone apex name MUST be signed, but > the NS RRsets that appear at delegation points (that is, the NS > RRsets in the parent zone that delegate the name to the child zone's > name servers) MUST NOT be signed. Glue address RRsets associated > with delegations MUST NOT be signed. > >Note that wildcard NS records are not 'zone cuts' or delegation points by >your reading of the algorithm in 1034/4.3.2/3 'Zactly. There are two frames of reference. In one, the observer is standing still, looking at the tree. To this observer, the * NS is a zone cut. In the other frame of reference, the observer is moving along the execution path of a response and falls into step c (authority record synthesis) and not step b (referral across a zone cut), concluding that the answer is not a zone cut. Both observers are witnessing the same structure. Ergo, the speed of light is a constant for the given medium. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar "A noble spirit embiggens the smallest man." - Jebediah Springfield -- to unsubscribe send a message to namedroppers-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 Feb 8 11:35: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 LAA22932 for ; Tue, 8 Feb 2005 11:35:40 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CyYJE-000BBq-69 for namedroppers-data@psg.com; Tue, 08 Feb 2005 16:33:52 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CyYJC-000BBX-OS for namedroppers@ops.ietf.org; Tue, 08 Feb 2005 16:33:51 +0000 Received: from [10.31.32.120] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j18GXaR6012211; Tue, 8 Feb 2005 11:33:37 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200502081333.j18DXuN01894@grimsvotn.TechFak.Uni-Bielefeld.DE> References: <200502081333.j18DXuN01894@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Tue, 8 Feb 2005 11:33:51 -0500 To: Peter Koch From: Edward Lewis Subject: Re: Last Call: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.49 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 14:33 +0100 2/8/05, Peter Koch wrote: >RFC 2396 has recently been obsoleted by RFC 3986. That now uses a Thingy >Formerly Known As Hostname. Thanks. (I wish they'd note "obsoleted-by" on the older RFCs. Googling often misses the new ones.) The updated text isn't materially different than the old, although it's a lot more specific, "section 3.5" instead of just 3. Getting into document lawyering (i.e., career preservation), I'm more convinced that \DDD isn't intended to be legal URI syntax. Looking at this, which is the comment that is prolonging the thread... At 7:11 +0000 2/7/05, D. J. Bernstein wrote: >This document specifies \065 as a synonym for capital A---not just in >zone files, but in all ``human readable and writable ASCII contexts.'' > >That specification is plainly erroneous. Nobody is willing to defend the >notion that this screwy decimal system should be allowed in URLs, SMTP >RCPT, etc. > >The obvious fix is to limit the document to zone files. Here is the text in the document: # 2.1 Escaping Unusual DNS Label Octets # # In Master Files [STD 13] and other human readable and writable ASCII # contexts, an escape is needed for the byte value for period (0x2E, Note that the draft does not say "all" but rather "and other." I don't see a need to edit this. It's not an exclusive statement. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar "A noble spirit embiggens the smallest man." - Jebediah Springfield -- to unsubscribe send a message to namedroppers-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 Feb 8 15:57:27 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17836 for ; Tue, 8 Feb 2005 15:57:27 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CycM1-000Ktc-4Q for namedroppers-data@psg.com; Tue, 08 Feb 2005 20:53:01 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CycLz-000KtL-Av for namedroppers@ops.ietf.org; Tue, 08 Feb 2005 20:52:59 +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 892FD677F9 for ; Tue, 8 Feb 2005 20:52:57 +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 j18KqYd9014121; Wed, 9 Feb 2005 07:52:35 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200502082052.j18KqYd9014121@drugs.dv.isc.org> To: Peter Koch Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Last Call: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard In-reply-to: Your message of "Tue, 08 Feb 2005 14:33:56 BST." <200502081333.j18DXuN01894@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Wed, 09 Feb 2005 07:52:34 +1100 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 > Mark Andrews wrote: > > {IESG removed from Cc} > > > I stand by my words. URLs take hostnames. RFC 2396 just > > described the subset of hostnames that are representable in > > the DNS. > > RFC 2396 has recently been obsoleted by RFC 3986. That now uses a Thingy > Formerly Known As Hostname. > > > names. Most applications, including web browsers, take > > hostnames. The fact that you can represent most (but not all) > > hostnames in the DNS just adds to the confusion. > > > > Hostnames of length 254 and 255 cannot be represented in the DNS. > > Yes, but "domain names" of length 254 or 255 cannot either - due to the fact > that the wire format needs two more octets than the FQDN text representation. The length of domain names has always been defined in terms of the uncompressed wire length. The presentation format can go to 1004 characters. > > I don't expect a application that takes a hostname to accept > > \DDD. I do expect a application that takes a domain name to > > accept \DDD. > > Now it may be time to dig out your long since expired Internet Draft again .. > . > > > Telnet, ssh, ftp etc. take hostnames. > > Weird enough they should use IDNs - at a different layer, though. What this document is talking about is the DNS (that big replicated distributed database) and how you represent domain names in it. In the tools that manipulate it. It has NOTHING to do with how hostnames are represented. The fact that you can store and retrieve hostnames from it is irrelevent as it is at a totally different layer. IDN exist at a layer about the DNS. They are transformed to and from DNS labels. -- 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 Tue Feb 8 21:56: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 VAA02631 for ; Tue, 8 Feb 2005 21:56:36 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CyhwG-000HeE-QU for namedroppers-data@psg.com; Wed, 09 Feb 2005 02:50:48 +0000 Received: from [208.218.130.13] (helo=gis.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CyhwF-000He0-NQ for namedroppers@ops.ietf.org; Wed, 09 Feb 2005 02:50:47 +0000 Received: from tecotoo.localhost ([207.7.193.195]) by mx05.gis.net; Tue, 08 Feb 2005 21:50:43 -0500 Received: from tecotoo (tecotoo [127.0.0.1]) by tecotoo.localhost (NTMail 3.03.0017/1.aaaa) with ESMTP id aa001118 for ; Tue, 8 Feb 2005 21:51:05 +0000 Message-Id: <4.3.1.2.20050208213702.049869a8@pop.gis.net> X-Sender: mayer@pop.gis.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 08 Feb 2005 21:50:56 -0500 To: Edward Lewis , Peter Koch From: Danny Mayer Subject: Re: Last Call: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard Cc: namedroppers@ops.ietf.org In-Reply-To: References: <200502081333.j18DXuN01894@grimsvotn.TechFak.Uni-Bielefeld.DE> <200502081333.j18DXuN01894@grimsvotn.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Rcpt-To: 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 At 11:33 AM 2/8/2005, Edward Lewis wrote: >At 14:33 +0100 2/8/05, Peter Koch wrote: > >>RFC 2396 has recently been obsoleted by RFC 3986. That now uses a Thingy >>Formerly Known As Hostname. > >Thanks. (I wish they'd note "obsoleted-by" on the older RFCs. Googling >often misses the new ones.) > >The updated text isn't materially different than the old, although it's a >lot more specific, "section 3.5" instead of just 3. Getting into document >lawyering (i.e., career preservation), I'm more convinced that \DDD isn't >intended to be legal URI syntax. URI's are described in RFC 1808 Section 2.1 and 1738 Section 3.1 which describes the host part of the URI this way: host The fully qualified domain name of a network host, or its IP address as a set of four decimal digit groups separated by ".". Fully qualified domain names take the form as described in Section 3.5 of RFC 1034 [13] and Section 2.1 of RFC 1123 [5]: a sequence of domain labels separated by ".", each domain label starting and ending with an alphanumerical character and possibly also containing "-" characters. The rightmost domain label will never start with a digit, though, which syntactically distinguishes all domain names from the IP addresses. I happened to have grabbed it today to deal with another unrelated matter. Looks like escaped digits are not allowed in host names and domain names. There's nothing in either Section 3.5 of RFC 1034 or Section 2.1 that mentions it. Does that clarify things? Danny -- to unsubscribe send a message to namedroppers-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 Feb 9 05:41: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 FAA18607 for ; Wed, 9 Feb 2005 05:41:12 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CypD9-0006RN-Io for namedroppers-data@psg.com; Wed, 09 Feb 2005 10:36:43 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CypD6-0006R1-As for namedroppers@ops.ietf.org; Wed, 09 Feb 2005 10:36:40 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 290F1C2DA4; Wed, 9 Feb 2005 10:36:39 +0000 (GMT) Date: Wed, 09 Feb 2005 10:36:39 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Danny Mayer , Edward Lewis , Peter Koch Cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: Last Call: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard Message-ID: In-Reply-To: <4.3.1.2.20050208213702.049869a8@pop.gis.net> References: <200502081333.j18DXuN01894@grimsvotn.TechFak.Uni-Bielefeld.DE> <200502081333.j18DXuN01894@grimsvotn.TechFak.Uni-Bielefeld.DE> <4.3.1.2.20050208213702.049869a8@pop.gis.net> X-Mailer: Mulberry/4.0.0a4 (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 08 February 2005 21:50 -0500 Danny Mayer wrote: > Does that clarify things? Not really as going back to the previous question, that leaves domain names having case "in them", but being compared case insensitively for DNS applications, but (unless it's elsewhere) no such prescription on the host part of URI's. I think all you've shown is that DJB's "typing things into browser bar"'s example is insufficient to prove his point, as the escape sequence itself may have been (correctly) passed in the wire-format URI rather than the capital letter he (I think) intended. 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 Wed Feb 9 05:48: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 FAA18939 for ; Wed, 9 Feb 2005 05:48:23 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CypMh-000Ckt-Nz for namedroppers-data@psg.com; Wed, 09 Feb 2005 10:46:35 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CypMY-000Che-E4 for namedroppers@ops.ietf.org; Wed, 09 Feb 2005 10:46:26 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 6481C2DF7D; Wed, 9 Feb 2005 11:46:25 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 630B12DF6F; Wed, 9 Feb 2005 11:46:25 +0100 (CET) Date: Wed, 9 Feb 2005 11:46:25 +0100 (CET) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: NS, *, and DNSSEC In-Reply-To: Message-ID: References: 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, 8 Feb 2005, Edward Lewis wrote: > At 16:47 +0100 2/8/05, Roy Arends wrote: > > (Ever take a Quantum Physics course?) The moment I tried to observe the course, it ceased to exist. > >dnssec-records: > > > > The NS RRset that appears at the zone apex name MUST be signed, but > > the NS RRsets that appear at delegation points (that is, the NS > > RRsets in the parent zone that delegate the name to the child zone's > > name servers) MUST NOT be signed. Glue address RRsets associated > > with delegations MUST NOT be signed. > > > >Note that wildcard NS records are not 'zone cuts' or delegation points by > >your reading of the algorithm in 1034/4.3.2/3 > > 'Zactly. > > There are two frames of reference. In one, the observer is standing > still, looking at the tree. To this observer, the * NS is a zone > cut. In the other frame of reference, the observer is moving along > the execution path of a response and falls into step c (authority > record synthesis) and not step b (referral across a zone cut), > concluding that the answer is not a zone cut. > > Both observers are witnessing the same structure. > > Ergo, the speed of light is a constant for the given medium. Actually, what I tried to argue here is that in any way, shape or form, a wildcard NS RRset is NOT (as in NEVER) a zone cut. I know this is a long shot, but 1034/4.3.2/3 backs the argument. The first observer would therefor never observe a zone cut. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 9 08:01: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 IAA27166 for ; Wed, 9 Feb 2005 08:01:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CyrQA-000Iy7-RP for namedroppers-data@psg.com; Wed, 09 Feb 2005 12:58:18 +0000 Received: from [202.12.73.64] (helo=fivedots.coe.psu.ac.th) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CyrQ7-000IxZ-29 for namedroppers@ops.ietf.org; Wed, 09 Feb 2005 12:58:15 +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 1CyrPw-00019x-00; Wed, 09 Feb 2005 19:58:04 +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 j19CvRhk027259; Wed, 9 Feb 2005 19:57:28 +0700 (ICT) From: Robert Elz To: Roy Arends cc: Edward Lewis , namedroppers@ops.ietf.org Subject: Re: NS, *, and DNSSEC In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 09 Feb 2005 19:57:27 +0700 Message-ID: <29904.1107953847@munnari.OZ.AU> 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 Date: Wed, 9 Feb 2005 11:46:25 +0100 (CET) From: Roy Arends Message-ID: | Actually, what I tried to argue here is that in any way, shape or form, a | wildcard NS RRset is NOT (as in NEVER) a zone cut. I know this is a long | shot, but 1034/4.3.2/3 backs the argument. You're right, and wrong ... a wildcard is never a zone cut, but a '*' as a label can be. The problem is that nothing ever prohibited '*' from being either a character in, or the whole text of, a label in a domain name. All that was done was to make it be the representation of a wildcard when a wildcard is needed. | The first observer would therefor never observe a zone cut. Someone will, if they query for x.*.example. in the example given in the earlier message. They'll get a referral to bogon.example. when the server for example. is queried. There's no way to run the algorithm without this happening, as the wildcard stuff only ever happens when there isn't an exact match (a case independent exact match of course...) between the label in the QNAME and a label in the zone being searched - and here that exact match exists (strcmp("*","*") == 0). 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 Dodgetqxlk@check1check.com Wed Feb 9 08:03:14 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 IAA28246; Wed, 9 Feb 2005 08:03:14 -0500 (EST) Received: from host217-37-73-91.in-addr.btopenworld.com ([217.37.73.91]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cyroi-0006IU-TF; Wed, 09 Feb 2005 08:23:43 -0500 Received: from effluent.redseven.de ([195.154.251.4]) by mulberry.glormhaigheo.com (InterMail vK.4.04.00.03 740-676-336 license 3rt412vx9781i4ch5q7qbd0458k2yum6) with ESMTP id <68329591816375.RVEH397.abbey@effluent.redseven.de> for ; Wed, 09 Feb 2005 13:57:32 +0100 Received: from lise (firecracker.ONE_DNS_NAME [81.19.232.95]) by ONE_DNS_NAME (MOS 3.4.5-GR) with SMTP id BNX33651; Wed, 09 Feb 2005 16:05:32 +0300 (IST) Message-ID: From: "Velma Castaneda" To: "Dnsext-archive" Subject: Re : Would you like to talk to me Date: Wed, 09 Feb 2005 12:04:32 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_901_7349_73Z6GMGM.G53C0918" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: The Bat! (v1.52f) Business X-Spam-Score: 15.0 (+++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb This is a multi-part message in MIME format. ------=_NextPart_901_7349_73Z6GMGM.G53C0918 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit




Goodbye<= /CENTER>



buttermilk blackoutbully copra parentscrub afraid arabida larval californiapsychoses ceremonious tabloiddiana considerate contralateralchop craft enigmahaydn macaque invitedatsun aqueous rancidartemisia ------=_NextPart_901_7349_73Z6GMGM.G53C0918 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable




Goodbye




admitted blumenthalcause isaiah albertcanaveral algorithm hoaglandfrigidaire desirous macgregorseep gerber airmailfluent gettysburg elizabethanmuse opponent classcardinal godwit rawhidesymbolic heartfelt nutritivebisect ------=_NextPart_901_7349_73Z6GMGM.G53C0918-- From owner-namedroppers@ops.ietf.org Wed Feb 9 08:50: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 IAA02200 for ; Wed, 9 Feb 2005 08:50:50 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CysBO-000AkY-Sa for namedroppers-data@psg.com; Wed, 09 Feb 2005 13:47:06 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CysBL-000Ajr-EH for namedroppers@ops.ietf.org; Wed, 09 Feb 2005 13:47:03 +0000 Received: from [192.168.1.103] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j19DknxO016705; Wed, 9 Feb 2005 08:46:49 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 9 Feb 2005 08:46:49 -0500 To: Roy Arends From: Edward Lewis Subject: Re: NS, *, and DNSSEC Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.49 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:46 +0100 2/9/05, Roy Arends wrote: >Actually, what I tried to argue here is that in any way, shape or form, a >wildcard NS RRset is NOT (as in NEVER) a zone cut. I know this is a long >shot, but 1034/4.3.2/3 backs the argument. One problem here is in the terminology. "A wildcard NS RRset" has a fuzzy meaning. In the draft I use the idiom "source of synthesis." This is the domain name that is consulted to synthesize records in 3c. Such a domain name has to "begin with" an asterisk label, the rest of the domain name is the closest encloser. Only in this role does being a wildcard have any special meaning. ("Begin with" doesn't precluse there being subdomains of the name, they just don't matter.) The reason a source of synthesis (well it's not "never a zone cut" but it) "never acts like a zone cut" is because in 3c, where the chimera called a source of synthesis briefly appears, there is no provision for a referral message reply. Outside of step 3c, wild card domain names really have no significance. (A source of synthesis is . - and there is no closest encloser until you define one, in 3c.) From that rule, a domain name starting with an asterisk label can be a cut point. I've been mulling this over and it isn't a problem in base DNS, it's a problem in the definition of DNSSEC. I have come to believe that we ought *not* to restrict * NS and still think so. I toyed with suggesting that we say in 3c that * NS is never expanded, but this would mean a change to all the legacy name servers. If DNSSEC were to fail, we'd have made a permanent change for a temporary problem. Perhaps what is needed are some rules added to DNSSEC processing. I.e., a signer does sign a * NS set. A server does not include the RRSIG(NS) in the authority section in step 3b. A validator is given the proper authorization information regarding the signer name in the RRSIG(NS). >The first observer would therefor never observe a zone cut. Usually because first observers wind up with an arrow in the back. ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar "A noble spirit embiggens the smallest man." - Jebediah Springfield -- to unsubscribe send a message to namedroppers-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 Feb 9 08:59:18 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03284 for ; Wed, 9 Feb 2005 08:59:18 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CysL2-000Ktg-HM for namedroppers-data@psg.com; Wed, 09 Feb 2005 13:57:04 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CysL1-000KtN-Dl for namedroppers@ops.ietf.org; Wed, 09 Feb 2005 13:57:03 +0000 Received: from [192.168.1.103] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j19Dumtg016747; Wed, 9 Feb 2005 08:56:49 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <29904.1107953847@munnari.OZ.AU> References: <29904.1107953847@munnari.OZ.AU> Date: Wed, 9 Feb 2005 08:53:09 -0500 To: Robert Elz From: Edward Lewis Subject: Re: NS, *, and DNSSEC Cc: Roy Arends , Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.49 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 19:57 +0700 2/9/05, Robert Elz wrote: >Someone will, if they query for x.*.example. in the example given in the >earlier message. They'll get a referral to bogon.example. when the >server for example. is queried. I don't think that is right - they'd get a referral to *.example. We don't "expand" the wildcard in 3b. NSD 2.2.0 does it that way...the other implementation I tried wouldn't let me load a "* NS." >There's no way to run the algorithm without this happening, as the wildcard >stuff only ever happens when there isn't an exact match (a case independent >exact match of course...) between the label in the QNAME and a label in the >zone being searched - and here that exact match exists (strcmp("*","*") == 0). Right - that's step 3c. PS -> (strcmp(label,"*") == 0) || (strcmp(label,"\*") == 0) || (strcmp(label,"\042") == 0) You can't escape the asterisk...;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar "A noble spirit embiggens the smallest man." - Jebediah Springfield -- to unsubscribe send a message to namedroppers-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 Feb 9 13:58: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 NAA26952 for ; Wed, 9 Feb 2005 13:58:48 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CywuP-000PHq-CX for namedroppers-data@psg.com; Wed, 09 Feb 2005 18:49:53 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CywuN-000PHR-1G for namedroppers@ops.ietf.org; Wed, 09 Feb 2005 18:49:51 +0000 Received: from [10.31.32.120] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j19IngCX018022; Wed, 9 Feb 2005 13:49:42 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Wed, 9 Feb 2005 13:49:49 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: proposed sol'n to the '* NS' problem Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.49 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 The problem with signed zones having a "* NS" is that when the record set acts as a source of synthesis, it lacks the requisite RRSIG to cover it (as would any other record set synthesized in 1034/4.3.2/3c). Without this RRSIG, this, albeit non-sense, situation is a place where message substitution can go undetected. Although this vulnerability is superficially a stupid little corner case, I am somewhat concerned that, if left untreated, would allow cache poisoning by allowing NS RRsets to be presented to a caching element. I am not sure this is possible - I haven't been able to construct the situation with existing code. In the spirit of, "well, there is an ugly fix to this I can imagine," I'll present it here. This isn't necessarily the best fix, nor does this mean that this or any fix is needed. It is presented here for discussion. In dnssecbis-protocol draft (sitting in the RFC Editor Queue since mid-Oct.): In Section 2.2, change the original text: # The NS RRset that appears at the zone apex name MUST be signed, but # the NS RRsets that appear at delegation points (that is, the NS # RRsets in the parent zone that delegate the name to the child zone's # name servers) MUST NOT be signed. Glue address RRsets associated # with delegations MUST NOT be signed. to something like: The NS RRset that appears at the zone apex name MUST be signed, as well as any NS RRset that is owned by a wild card domain name MUST be signed, but the NS RRsets that appear at delegation points (that is, the NS RRsets in the parent zone that delegate the name to the child zone's name servers) MUST NOT be signed. Glue address RRsets associated with delegations MUST NOT be signed. That takes care of the missing RRSIG, but now means that there is a spurious RRSIG in places, as well as a potentially confusing situation for the validator. In section 3.1.1, the original text: # o When placing a signed RRset in the Authority section, the name # server MUST also place its RRSIG RRs in the Authority section. # The RRSIG RRs have a higher priority for inclusion than any other # RRsets that may need to be included. If space does not permit # inclusion of these RRSIG RRs, the name server MUST set the TC bit. changes to this: o When placing a signed RRset in the Authority section, the name server MUST also place its RRSIG RRs in the Authority section, with the exception of RRSIGs for a referral NS RRSet. When a non-authoritative server adds an NS RRset to the Authority section, its RRSIG MUST NOT be inserted. (Ordinarily, there isn't such an RRSIG, only in the case of a wildcard NS RRset will it appear.) The RRSIG RRs have a higher priority for inclusion than any other RRsets that may need to be included. If space does not permit inclusion of these RRSIG RRs, the name server MUST set the TC bit. That takes care of the spurious RRSIG, noting that there is already a rule saying that all records in the Answer Section are signed. (My edit is perhaps too wordy.) In section 5.3.1, this takes care of the authorization-to-sign problem. The original is: # o The RRSIG RR's Signer's Name field MUST be the name of the zone # that contains the RRset; The new rule is: o The RRSIG RR's Signer's Name field MUST be the name of the zone that contains the RRset, with one exception. If the Type Covered field of the RRSIG is NS and the RRSIG Labels field indicates that this is a synthesized RRset, then the Signer's Name field MUST be the name of the zone above the cut point; That should take care of the problem, well, that is one way to take care of the problem. Yes, it is a wart. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar "A noble spirit embiggens the smallest man." - Jebediah Springfield -- to unsubscribe send a message to namedroppers-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 Feb 9 15:27: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 PAA10027 for ; Wed, 9 Feb 2005 15:27:31 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CyyOL-0001qk-Hp for namedroppers-data@psg.com; Wed, 09 Feb 2005 20:24:53 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CyyOK-0001qV-Dc for namedroppers@ops.ietf.org; Wed, 09 Feb 2005 20:24:52 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09661; Wed, 9 Feb 2005 15:24:50 -0500 (EST) Message-Id: <200502092024.PAA09661@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-dhcid-rr-09.txt Date: Wed, 09 Feb 2005 15:24:49 -0500 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 : A DNS RR for encoding DHCP information (DHCID RR) Author(s) : M. Stapp, et al. Filename : draft-ietf-dnsext-dhcid-rr-09.txt Pages : 10 Date : 2005-2-9 It is possible for multiple DHCP clients to attempt to update the same DNS FQDN as they obtain DHCP leases. Whether the DHCP server or the clients themselves perform the DNS updates, conflicts can arise. To resolve such conflicts, 'Resolution of DNS Name Conflicts'[1] proposes storing client identifiers in the DNS to unambiguously associate domain names with the DHCP clients to which they refer. This memo defines a distinct RR type for this purpose for use by DHCP clients and servers, the 'DHCID' RR. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dhcid-rr-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dhcid-rr-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dhcid-rr-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-9150222.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dhcid-rr-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dhcid-rr-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-9150222.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 9 15:41: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 PAA12142 for ; Wed, 9 Feb 2005 15:41:22 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CyycT-0003ve-1J for namedroppers-data@psg.com; Wed, 09 Feb 2005 20:39:29 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CyycP-0003uc-8m for namedroppers@ops.ietf.org; Wed, 09 Feb 2005 20:39:25 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11790; Wed, 9 Feb 2005 15:39:22 -0500 (EST) Message-Id: <200502092039.PAA11790@ietf.org> From: The IESG To: IETF-Announce@ietf.org Cc: namedroppers@ops.ietf.org, Olafur Gudmundsson , Olaf Kolkman Subject: WG Action: RECHARTER: DNS Extensions (dnsext) Date: Wed, 09 Feb 2005 15:39:22 -0500 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_20 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The charter of the DNS Extensions (dnsext) working group in the Internet Area of the IETF has been updated. For additional information, please contact the Area Directors or the working group Chairs. +++ DNS Extensions (dnsext) ========================= Current Status: Active Working Group Chair(s): Olafur Gudmundsson Olaf Kolkman Internet Area Director(s): Thomas Narten Margret Wasserman Internet Area Advisor: Thomas Narten Mailing Lists: General Discussion: namedroppers@ops.ietf.org To Subscribe: namedroppers-request@ops.ietf.org Archive: Description of Working Group: DNS was originally specified in RFC's 1034 and 1035, with subsequent updates. Within the scope of this WG are DNS protocol issues, including the specification of message formats, message handling, and data formats used for DNS client-server and server-server communication. This WG is focused on advancing the zone transfer, update, notify and DNSSECbis documents to Draft standard. The WG works on solutions for DNSSEC deployment issues that may require protocol modifications. Two of these issues are identified and are worked on under the umbrella of this WG. 1] (a) method(s) to prevent the possibility of trivial zone enumeration and 2] a method for automated rollover of trust-anchors configured in validating resolvers. Issues surrounding the operation of DNS, recommendations concerning the configuration of DNS servers, and other issues with the use of the protocol are out of scope for this Working Group. These issues are considered in other venues, such as the DNS Operations Working Group. The DNSEXT Working Group sometimes uses an additional mailing list for discussion of DNS Security related issues. This list is open to all Discussion: dnssec@cafax.se To Subscribe: dnssec-request@cafax.se Archive: http://www.cafax.se/dnssec/ and ftp://ftp.cafax.se/pub/archives/dnssec.list The 2535bis document set was edited by a team. This team was chartered with making editorial changes only, with all substantiative changes discussed on the WG list. The archive of this editors-only mailing list is available at: http://www.east.isi.edu/projects/DNSSEC Specific work items are: o Advance the DNSSECbis document set through the standards process. o Clarification of RFC1034/1035 relating to DNSEXT ongoing work. + Clarification of wildcard processing rules. o After the work items above have been completed the working group will continue on reviewing the following existing proposed standard and examine if there is a possibility to progress them on the standards track. + RFC1995 (IXFR) to Draft standard. + RFC1996 (Notify) to Draft standard. + RFC2136bis (Dynamic Update) to Draft Standard. + RFC2181 (Clarify) to IESG for advancement to Draft Standard. + RFC2308 (Neg Caching) to Draft Standard. + RFC2671 (EDNS0) to Draft Standard. + RFC2672 (DNAME) to Draft Standard, or revision. + RFC2845 (TSIG)to Draft standard. + RFC2930 (TKEY) to Draft standard. + RFC3007 (Secure Update) to Draft standard. + RFC3645 GSS/TSIG to Draft Standard + RFC3??? AXFR clarify to Draft Standard. o Identify (a) method(s) to prevent the possibility of trivial zone enumeration. o Define a method for automated rollover of trust-anchors configured in validating resolvers. o Foster the development of Link Local Multicast Name Resolution (LLMNR) standard. The WG has taken up this work since LLMNR it is very similar to the DNS protocol. LLMNR is targeted as proposed standard. The lifetime of the group is set by the work items above but while these are ongoing the working group has additional tasks: o Reviewing and providing recommendations about the specification, by other working groups, of RR types that do not require any special processing and that do not require any special naming conventions. Goals and Milestones: Done Forward RFC2535-bis to IESG for proposed standard Done Forward Case Insensitive to IESG for Proposed Standard Done Forward LLMNR to IESG for Proposed Standard Feb 05 Submit KEY algorithm documents RFC253[69]bis and RFC3110 to IESG for proposed standard Feb 05 Update boilerplate text on OPT-IN Mar 05 Forward Wildcard clarification to IESG for proposed standard Mar 05 Finalize Zone Enumeration Requirements Apr 05 Start of process of reviewing the following RFCs and to move them to Draft Standard status May 05 Submit to IESG RFC2845 (TSIG)to Draft standard Jun 05 RFC2672 (DNAME) to Draft Standard or revision Jun 05 RFC2671 (EDNS0) to Draft Standard Jul 05 RFC1995 (IXFR) to Draft standard Jul 05 RFC1996 (Notify) to Draft Standard Jul 05 RFC2136 (Dynamic Update) to Draft Standard Jul 05 RFC3007 (Secure Update) to Draft Standard Sep 05 RFC2308 (Neg Caching) to Draft Standard Sep 05 RFC2930 (TKEY) to Draft standard Sep 05 RFC2181 (Clarify) to Draft Standard Nov 05 RFC2782 (SRV RR) to Draft Standard Nov 05 RFC1982 (Serial Number Arithmetic) Nov 05 RFC2538 (CERT RR) to Draft Standard Nov 05 FRC2539 (DH Key RR) to Draft Standard Nov 05 RFC3226 (Message Size) to Draft Standard -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 9 16:19: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 QAA21766 for ; Wed, 9 Feb 2005 16:19:14 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CyzCn-000A3R-Tj for namedroppers-data@psg.com; Wed, 09 Feb 2005 21:17:01 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CyzCk-000A1y-Rd for namedroppers@ops.ietf.org; Wed, 09 Feb 2005 21:16:58 +0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-4.cisco.com with ESMTP; 09 Feb 2005 13:17:30 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j19LGpq8009395 for ; Wed, 9 Feb 2005 13:16:52 -0800 (PST) Received: from [10.32.254.179] (stealth-10-32-254-179.cisco.com [10.32.254.179]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id BBL52429; Wed, 9 Feb 2005 13:16:55 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: namedroppers@ops.ietf.org From: Richard Johnson Subject: Simple question re. DNS label compression Date: Wed, 9 Feb 2005 13:16:55 -0800 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 Simple question: Can a DNS domain name, which is using label compression, have multiple levels of indirect pointers? For example: +---------------------------+ | 1 | "a" | 4 | "t" | +---------------------------+ | "e" | "s" | "t" | 3 | +---------------------------+ | "c" | "o" | "m" | 0 | +---------------------------+ | 1 | "b" | 0xc0 | 0x7 | +---------------------------+ | "c" | 0xc0 | 0xc | 0 | +---------------------------+ So, assuming I have coded this correctly: 1) the first label here is "a.test.com" in the the simple fashion. 2) the second label after it would be "b.com" following the "0xc007" indirect pointer 3) the third label after it would be "c.b.com" following first the "0xc00c" indirect pointer and then the "0xc007" indirect pointer. Thanks for your time! /raj -- to unsubscribe send a message to namedroppers-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 Feb 9 17:15: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 RAA04858 for ; Wed, 9 Feb 2005 17:15:33 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1Cz04A-000IK8-Ub for namedroppers-data@psg.com; Wed, 09 Feb 2005 22:12:10 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1Cz04A-000IJw-2O for namedroppers@ops.ietf.org; Wed, 09 Feb 2005 22:12:10 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 09 Feb 2005 15:23:57 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.88,191,1102291200"; d="scan'208"; a="224924668:sNHT20425808" Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j19MC7Tj023032 for ; Wed, 9 Feb 2005 14:12:08 -0800 (PST) Received: from [10.32.254.179] (stealth-10-32-254-179.cisco.com [10.32.254.179]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id BBL58840; Wed, 9 Feb 2005 14:12:06 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7b371c1c2324d7ce45a7d0cbc5fc1812@cisco.com> Content-Transfer-Encoding: 7bit From: Richard Johnson Subject: Re: Simple question re. DNS label compression Date: Wed, 9 Feb 2005 14:12:07 -0800 To: namedroppers@ops.ietf.org 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 I have a response already. Apparently the answer is "yes". Thanks everyone. /raj On Feb 9, 2005, at 1:16 PM, Richard Johnson wrote: > Simple question: Can a DNS domain name, which is using label > compression, have multiple levels of indirect pointers? For example: > > +---------------------------+ > | 1 | "a" | 4 | "t" | > +---------------------------+ > | "e" | "s" | "t" | 3 | > +---------------------------+ > | "c" | "o" | "m" | 0 | > +---------------------------+ > | 1 | "b" | 0xc0 | 0x7 | > +---------------------------+ > | "c" | 0xc0 | 0xc | 0 | > +---------------------------+ > > So, assuming I have coded this correctly: > > 1) the first label here is "a.test.com" in the the simple fashion. > 2) the second label after it would be "b.com" following the "0xc007" > indirect pointer > 3) the third label after it would be "c.b.com" following first the > "0xc00c" indirect pointer and then the "0xc007" indirect pointer. > > Thanks for your time! > > /raj > -- to unsubscribe send a message to namedroppers-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 Feb 9 17:15: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 RAA04904 for ; Wed, 9 Feb 2005 17:15:54 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1Cz05y-000IXE-Ty for namedroppers-data@psg.com; Wed, 09 Feb 2005 22:14:02 +0000 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1Cz05v-000IWq-8j for namedroppers@ops.ietf.org; Wed, 09 Feb 2005 22:13:59 +0000 Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.12.11/8.12.11/TechFak/2004/05/05/sjaenick) with ESMTP id j19MDsOu005431; Wed, 9 Feb 2005 23:13:55 +0100 (MET) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id j19MDsm05193; Wed, 9 Feb 2005 23:13:54 +0100 (MET) Message-Id: <200502092213.j19MDsm05193@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: Richard Johnson Cc: namedroppers@ops.ietf.org Subject: Re: Simple question re. DNS label compression In-reply-to: Your message of "Wed, 09 Feb 2005 13:16:55 PST." 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: <5189.1107987233.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Wed, 09 Feb 2005 23:13:54 +0100 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 > Simple question: Can a DNS domain name, which is using label > compression, have multiple levels of indirect pointers? For example: this is correct per RFC 1035, 4.1.4. "Message compression": The compression scheme allows a domain name in a message to be represented as either: - a sequence of labels ending in a zero octet - a pointer - a sequence of labels ending with a pointer It can also be seen "in the wild": > host -Y -t ns de. de NS f.nic.de ;; 01 66 03 6E 69 63 C0 0C ; .f.nic.. de NS l.de.net ;; 01 6C 02 64 65 03 6E 65 74 00 ; .l.de.net. de NS s.de.net ;; 01 73 C0 36 ; .s.6 de NS z.nic.de ;; 01 7A C0 22 ; .z." de NS a.nic.de ;; 01 61 C0 22 ; .a." de NS c.de.net ;; 01 63 C0 36 ; .c.6 The first NS RR points back into the query section (C0 0C), the fourth points back into the first (the "nic.de" part of "f.nic.de"), which then again leads into the query section. Please bear in mind that per RFC 3597 label compression cannot be applied to domain names in the RDATA section of new RR types. -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 Wed Feb 9 20:18: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 UAA20781 for ; Wed, 9 Feb 2005 20:18:08 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1Cz2u5-000J73-Dt for namedroppers-data@psg.com; Thu, 10 Feb 2005 01:13:57 +0000 Received: from [202.12.73.64] (helo=fivedots.coe.psu.ac.th) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1Cz2u1-000J6j-Bk for namedroppers@ops.ietf.org; Thu, 10 Feb 2005 01:13:53 +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 1Cz2tv-0007mb-00; Thu, 10 Feb 2005 08:13:47 +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 j19LiV3O019336; Thu, 10 Feb 2005 04:44:32 +0700 (ICT) From: Robert Elz To: Edward Lewis cc: Roy Arends , namedroppers@ops.ietf.org Subject: Re: NS, *, and DNSSEC In-Reply-To: References: <29904.1107953847@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 10 Feb 2005 04:44:31 +0700 Message-ID: <20280.1107985471@munnari.OZ.AU> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,BIZ_TLD autolearn=no version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Wed, 9 Feb 2005 08:53:09 -0500 From: Edward Lewis Message-ID: | I don't think that is right - they'd get a referral to *.example. We | don't "expand" the wildcard in 3b. Difference in terminology, I meant they'd get an NS record with bogon.example in the RDATA (difference between "referral to" and "referral for") I don't think we have a different opinion on what actually happens. | PS -> (strcmp(label,"*") == 0) || (strcmp(label,"\*") == 0) | || (strcmp(label,"\042") == 0) | | You can't escape the asterisk...;) I expect this is humour, but it flew right past me ... For C, "\*" is identical to "*", so you most probably meant "\\*" in that second strcmp, but all those would be incorrect. When loading the zone file, any escape processing would (should) have been done when it was loaded, leaving just the desired name in the zone. So * \* and \042 all result in a "*" label in the zone data. You don't want to be repeating all of that for every query (quite apart from the possibility to make a mess of it - "\*" added to a zone via dunamic update is a 2 character label, \* in a master file is one...) If the "label" in your strcmp was from the QNAME, then a query for "\*" (not a C string, just 2 characters) would certainly only reference '*' RRs when that '*' is in its wildcard role. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 9 22:47: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 WAA28988 for ; Wed, 9 Feb 2005 22:47:28 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1Cz5Ea-000FzM-W3 for namedroppers-data@psg.com; Thu, 10 Feb 2005 03:43:16 +0000 Received: from [208.218.130.11] (helo=gis.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1Cz5EX-000Fz0-TN for namedroppers@ops.ietf.org; Thu, 10 Feb 2005 03:43:14 +0000 Received: from tecotoo.localhost ([207.7.206.216]) by mx03.gis.net; Wed, 09 Feb 2005 22:43:04 -0500 Received: from tecotoo (tecotoo [127.0.0.1]) by tecotoo.localhost (NTMail 3.03.0017/1.aaaa) with ESMTP id fa001123 for ; Wed, 9 Feb 2005 22:01:26 +0000 Message-Id: <4.3.1.2.20050209215944.04975f00@pop.gis.net> X-Sender: mayer@pop.gis.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 09 Feb 2005 22:01:18 -0500 To: Alex Bligh , Edward Lewis , Peter Koch From: Danny Mayer Subject: Re: Last Call: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard Cc: namedroppers@ops.ietf.org In-Reply-To: References: <4.3.1.2.20050208213702.049869a8@pop.gis.net> <200502081333.j18DXuN01894@grimsvotn.TechFak.Uni-Bielefeld.DE> <200502081333.j18DXuN01894@grimsvotn.TechFak.Uni-Bielefeld.DE> <4.3.1.2.20050208213702.049869a8@pop.gis.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Rcpt-To: 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 At 05:36 AM 2/9/2005, Alex Bligh wrote: >--On 08 February 2005 21:50 -0500 Danny Mayer wrote: > >>Does that clarify things? > >Not really as going back to the previous question, that leaves domain >names having case "in them", but being compared case insensitively for >DNS applications, but (unless it's elsewhere) no such prescription on >the host part of URI's. I think all you've shown is that DJB's >"typing things into browser bar"'s example is insufficient to prove >his point, as the escape sequence itself may have been (correctly) >passed in the wire-format URI rather than the capital letter he (I think) >intended. I agree, but then you didn't need my reference for this observation as it has nothing to do with DNS, just with browsers and perhaps http servers. Danny >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 Thu Feb 10 04:48: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 EAA12753 for ; Thu, 10 Feb 2005 04:48:45 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CzAsJ-0004uK-1m for namedroppers-data@psg.com; Thu, 10 Feb 2005 09:44:39 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CzAsH-0004u2-Nk for namedroppers@ops.ietf.org; Thu, 10 Feb 2005 09:44:38 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id D18F325D2C; Thu, 10 Feb 2005 10:44:36 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 7725E23F2A for ; Thu, 10 Feb 2005 10:44:33 +0100 (CET) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id j1A9iXet023077 for ; Thu, 10 Feb 2005 10:44:33 +0100 Date: Thu, 10 Feb 2005 10:44:33 +0100 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: Fw: Internet-Drafts Database Interface Message-Id: <20050210104433.72c170b2.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.003075 / -5.9 X-RIPE-Signature: f59a6ab027046f48641f91736ecc89a8 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: 7bit Dear Colleagues, FYI: The ID Database interface is a new tool. The relevant URL for this group is: https://datatracker.ietf.org/public/idindex.cgi?command=show_wg_id&id=1479 --Olaf ---------------------- Begin forwarded message ---------------------- Date: Wed, 09 Feb 2005 17:47:05 -0500 From: IETF Secretariat To: IETF Announcement list Cc: wgchairs@ietf.org Subject: Internet-Drafts Database Interface The IESG Secretariat is pleased to announce the deployment of the "Internet-Drafts Database Interface" (https://datatracker.ietf.org/public/idindex.cgi). This new Web tool, which may be accessed from the "Internet-Drafts" page (http://www.ietf.org/ID.html) of the IETF Web site, allows users to display Internet-Drafts by category, or to search for Internet-Drafts based on one or more search parameters. Specifically, users may: - List Internet-Drafts by I-D status (i.e., "All," "Active," "Published," or "Expired/Withdrawn/Replaced," sorted either by submission date or filename. - View Internet-Drafts that are products of an IETF working group, an independent submitter, or another IETF or IETF-related entity. - Identify Internet-Drafts that satisfy selected criteria. For each Internet-Draft of interest, the tool provides the following information, as applicable: - Title - I-D Status - Intended Status at Publication - RFC Number - I-D Tracker State - Abstract The tool also provides links to the following materials: - The document (i.e., the Internet-Draft or tombstone) - Related documents (e.g., documents that replaced or were replaced by the subject Internet-Draft, and the derivatives and precursors of these documents) - The RFC (if the Internet-Draft has been published) - The I-D Tracker "Detail Info" page (if the Internet-Draft has been added to the I-D Tracker) - A pre-addressed e-mail note for contacting an author If you require assistance in using this new Web tool, or wish to report a bug, then please send a message to ietf-action@ietf.org. The IETF Secretariat ---------------------- End forwarded message ------------------------ -- ---------------------------------| 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 Thu Feb 10 11:26: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 LAA13789 for ; Thu, 10 Feb 2005 11:26:18 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CzH3I-0004Iu-DF for namedroppers-data@psg.com; Thu, 10 Feb 2005 16:20:24 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CzH3H-0004IG-5S for namedroppers@ops.ietf.org; Thu, 10 Feb 2005 16:20:23 +0000 Received: from [10.31.32.120] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j1AGKHPI022717; Thu, 10 Feb 2005 11:20:17 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20050210104433.72c170b2.olaf@ripe.net> References: <20050210104433.72c170b2.olaf@ripe.net> Date: Thu, 10 Feb 2005 11:20:25 -0500 To: "Olaf M. Kolkman" From: Edward Lewis Subject: Re: Fw: Internet-Drafts Database Interface Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.49 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 I would like to see this one published as informational/historic if anyone still has it. https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=6905 It is a significant datapoint on the path from 2065 to 2535 to dnssec-bis. At 10:44 +0100 2/10/05, Olaf M. Kolkman wrote: >Dear Colleagues, > >FYI: The ID Database interface is a new tool. > >The relevant URL for this group is: > https://datatracker.ietf.org/public/idindex.cgi?command=show_wg_id&id=1479 > > > >--Olaf > > >---------------------- Begin forwarded message ---------------------- > > >Date: Wed, 09 Feb 2005 17:47:05 -0500 >From: IETF Secretariat >To: IETF Announcement list >Cc: wgchairs@ietf.org >Subject: Internet-Drafts Database Interface > > >The IESG Secretariat is pleased to announce the deployment of the >"Internet-Drafts Database Interface" >(https://datatracker.ietf.org/public/idindex.cgi). This new Web >tool, which may >be accessed from the "Internet-Drafts" page >(http://www.ietf.org/ID.html) of the >IETF Web site, allows users to display Internet-Drafts by category, >or to search >for Internet-Drafts based on one or more search parameters. >Specifically, users >may: > >- List Internet-Drafts by I-D status (i.e., "All," "Active," "Published," or >"Expired/Withdrawn/Replaced," sorted either by submission date or filename. >- View Internet-Drafts that are products of an IETF working group, an >independent submitter, or another IETF or IETF-related entity. >- Identify Internet-Drafts that satisfy selected criteria. > >For each Internet-Draft of interest, the tool provides the following >information, as applicable: > >- Title >- I-D Status >- Intended Status at Publication >- RFC Number >- I-D Tracker State >- Abstract > >The tool also provides links to the following materials: > >- The document (i.e., the Internet-Draft or tombstone) >- Related documents (e.g., documents that replaced or were replaced by the >subject Internet-Draft, and the derivatives and precursors of these documents) >- The RFC (if the Internet-Draft has been published) >- The I-D Tracker "Detail Info" page (if the Internet-Draft has been added to >the I-D Tracker) >- A pre-addressed e-mail note for contacting an author > >If you require assistance in using this new Web tool, or wish to report a bug, >then please send a message to ietf-action@ietf.org. > >The IETF Secretariat > > >---------------------- End forwarded message ------------------------ > >-- > >---------------------------------| 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: -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar "A noble spirit embiggens the smallest man." - Jebediah Springfield -- to unsubscribe send a message to namedroppers-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 Feb 10 14:42: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 OAA28607 for ; Thu, 10 Feb 2005 14:42:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CzK89-000I0E-98 for namedroppers-data@psg.com; Thu, 10 Feb 2005 19:37:37 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CzK7y-000HyR-7i for namedroppers@ops.ietf.org; Thu, 10 Feb 2005 19:37:26 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.11/8.12.11) with ESMTP id j1AJbKV4023458 for ; Thu, 10 Feb 2005 14:37:20 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.12.11/8.12.11/Submit) id j1AJbKqj023457 for namedroppers@ops.ietf.org; Thu, 10 Feb 2005 14:37:20 -0500 (EST) (envelope-from namedroppers) Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CzGqz-000296-6Y for namedroppers@ops.ietf.org; Thu, 10 Feb 2005 16:07:42 +0000 Received: from [10.31.32.120] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j1AG7YeC022653; Thu, 10 Feb 2005 11:07:35 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Thu, 10 Feb 2005 11:07:42 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: A different proposed sol'n to * NS Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.49 on 66.92.146.160 X-Scanned-By: MIMEDefang 2.49 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 [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] Putting up an alternative solution to the one I proposed a day or so ago, this time taking the tack that we cancel synthesis if the source of synthesis owns an NS RRSet. The upside of this approach is that it needs to change one section of text. The downside is that it is changing more text in RFC 1034. Here's the RFC 1034 text (omitting a page break) with the CNAME "chasing text" in there. # c. If at some label, a match is impossible (i.e., the # corresponding label does not exist), look to see if a # the "*" label exists. # # If the "*" label does not exist, check whether the name # we are looking for is the original QNAME in the query # or a name we have followed due to a CNAME. If the name # is original, set an authoritative name error in the # response and exit. Otherwise just exit. # # If the "*" label does exist, match RRs at that node # against QTYPE. If any match, copy them into the answer # section, but set the owner of the RR to be QNAME, and # not the node with the "*" label. Go to step 6. | | If the data at the source of synthesis is a CNAME, and | QTYPE doesn't match CNAME, copy the CNAME RR into the | answer section of the response changing the owner name | to the QNAME, change QNAME to the canonical name in the | CNAME RR, and go back to step 1. So, the new fix would be add this: If the source of synthesis is a also a delegation point, i.e., it owns an NS RRset, do not match any RRsets. (Note that the order of instructions is not the way one should write code.) What this does is cancel concerns about wildcard NS and wildcard DS. (Yipee.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar "A noble spirit embiggens the smallest man." - Jebediah Springfield -- to unsubscribe send a message to namedroppers-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 Feb 11 00:10:01 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03789 for ; Fri, 11 Feb 2005 00:10:01 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CzSyU-000Q08-MJ for namedroppers-data@psg.com; Fri, 11 Feb 2005 05:04:14 +0000 Received: from [202.12.73.64] (helo=fivedots.coe.psu.ac.th) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CzSyO-000Py5-Af for namedroppers@ops.ietf.org; Fri, 11 Feb 2005 05:04:08 +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 1CzSyK-0001F0-00; Fri, 11 Feb 2005 12:04:04 +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 j1B53Sb1006205; Fri, 11 Feb 2005 12:03:28 +0700 (ICT) From: Robert Elz To: Edward Lewis cc: "Olaf M. Kolkman" , namedroppers@ops.ietf.org Subject: Re: Fw: Internet-Drafts Database Interface In-Reply-To: References: <20050210104433.72c170b2.olaf@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 11 Feb 2005 12:03:28 +0700 Message-ID: <7351.1108098208@munnari.OZ.AU> 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 Date: Thu, 10 Feb 2005 11:20:25 -0500 From: Edward Lewis Message-ID: | I would like to see this one published as informational/historic if | anyone still has it. | | https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=6905 | | It is a significant datapoint on the path from 2065 to 2535 to dnssec-bis. ftp://munnari.oz.au/internet-drafts/draft-ietf-dnsext-parent-sig-00.txt.Z That's the -00 version of course, the -01 file on munnari is just the "this draft has been deleted" notice. I don't recall if the change to putting that notice in a higher version that the last ever submitted had happened by Apr 2002 or not, so I don't know if there once was a -01 version that got trampled by the "expired" notice. 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 Feb 11 05: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 FAA14225 for ; Fri, 11 Feb 2005 05:08:09 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CzXad-000BnN-8K for namedroppers-data@psg.com; Fri, 11 Feb 2005 09:59:55 +0000 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CzXaa-000BmI-4Y for namedroppers@ops.ietf.org; Fri, 11 Feb 2005 09:59:52 +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 j1B9xjiP003915 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 11 Feb 2005 04:59:48 -0500 Date: Fri, 11 Feb 2005 04:59:44 -0500 (EST) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: namedroppers@ops.ietf.org cc: Olafur Gudmundsson , Olaf Kolkman Subject: Re: WG Action: RECHARTER: DNS Extensions (dnsext) In-Reply-To: <200502092039.PAA11790@ietf.org> Message-ID: 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 > + RFC3??? AXFR clarify to Draft Standard. I thought AXFR clarify died a horrible and tragic death after a short and ill-fated attempt to impose unnecessary changes made by Bind on the rest of the DNS implmentations. Why is this still on the list? Possibly AXFR does need to be clarified. I think it was agreed that the current spec was vague, but Bind groups' proposed solution was universally rejected (by everyone except those associated with Bind, of course) I may be willing to write a clarification for AXFR that corrects the ambiguity in the fashion accepted by all of the non-Bind server implementations. --Dean -- 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 Fri Feb 11 05:44: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 FAA16466 for ; Fri, 11 Feb 2005 05:44:52 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CzYF7-000Kx8-Ki for namedroppers-data@psg.com; Fri, 11 Feb 2005 10:41:45 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CzYF2-000KwD-Sw for namedroppers@ops.ietf.org; Fri, 11 Feb 2005 10:41:41 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id EFAA925651; Fri, 11 Feb 2005 11:41:39 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id BE904246B3; Fri, 11 Feb 2005 11:41:37 +0100 (CET) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id j1BAfbet027459; Fri, 11 Feb 2005 11:41:37 +0100 Date: Fri, 11 Feb 2005 11:41:37 +0100 From: "Olaf M. Kolkman" To: Dean Anderson Cc: namedroppers@ops.ietf.org, ogud@ogud.com, Thomas Narten Subject: Re: WG Action: RECHARTER: DNS Extensions (dnsext) Message-Id: <20050211114137.2dd16bbf.olaf@ripe.net> In-Reply-To: References: <200502092039.PAA11790@ietf.org> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.000434 / -5.9 X-RIPE-Signature: 92f14491bf0de2ea65e8c00b4a274635 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 > I thought AXFR clarify died a horrible and tragic death after a short and > ill-fated attempt to impose unnecessary changes made by Bind on the rest > of the DNS implmentations. > > Why is this still on the list? > See the status of this ID in the ID-tracker: https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=5123&rfc_flag=0 To paraphrase: The AD has a number of comments and the working group will need to pick this ID up again. To be continued. -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Feb 11 15:27: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 PAA05562 for ; Fri, 11 Feb 2005 15:27:16 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CzhIH-000JGQ-4Y for namedroppers-data@psg.com; Fri, 11 Feb 2005 20:21:37 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CzhIF-000JGC-Lo for namedroppers@ops.ietf.org; Fri, 11 Feb 2005 20:21:36 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04683; Fri, 11 Feb 2005 15:21:33 -0500 (EST) Message-Id: <200502112021.PAA04683@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-wcard-clarify-05.txt Date: Fri, 11 Feb 2005 15:21:33 -0500 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 : Clarifying the Role of Wild Card Domains in the Domain Name System Author(s) : E. Lewis Filename : draft-ietf-dnsext-wcard-clarify-05.txt Pages : 18 Date : 2005-2-11 This is an update to the wildcard definition of RFC 1034. The interaction with wildcards and CNAME is changed, an error condition removed, and the words defining some concepts central to wildcards are changed. The overall goal is not to change wildcards, but to refine the definition of RFC 1034. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-wcard-clarify-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-wcard-clarify-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-wcard-clarify-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-11153829.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-wcard-clarify-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-wcard-clarify-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-11153829.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 Feb 11 15:38: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 PAA07352 for ; Fri, 11 Feb 2005 15:38:43 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1CzhVJ-000LU6-C5 for namedroppers-data@psg.com; Fri, 11 Feb 2005 20:35:05 +0000 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1CzhV7-000LSi-CV for namedroppers@ops.ietf.org; Fri, 11 Feb 2005 20:34:53 +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 j1BKY623015451 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 11 Feb 2005 15:34:20 -0500 Date: Fri, 11 Feb 2005 15:34:00 -0500 (EST) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: "Olaf M. Kolkman" cc: namedroppers@ops.ietf.org, , Thomas Narten Subject: Re: WG Action: RECHARTER: DNS Extensions (dnsext) In-Reply-To: <20050211114137.2dd16bbf.olaf@ripe.net> Message-ID: 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 Fri, 11 Feb 2005, Olaf M. Kolkman wrote: > See the status of this ID in the ID-tracker: > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=5123&rfc_flag=0 BTW, this is database thing is great. Kudos to the people who made the database app happen. I'm surprised at the amount of information in it already. The 'clarify work is tracked back to 2002. --Dean -- 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 Fri Feb 11 15:47: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 PAA08854 for ; Fri, 11 Feb 2005 15:47:54 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1Czher-000NVK-IO for namedroppers-data@psg.com; Fri, 11 Feb 2005 20:44:57 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1Czhep-000NV4-Vy for namedroppers@ops.ietf.org; Fri, 11 Feb 2005 20:44:56 +0000 Received: from [192.168.1.103] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j1BKijU3043694; Fri, 11 Feb 2005 15:44:48 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200502112021.PAA04683@ietf.org> References: <200502112021.PAA04683@ietf.org> Date: Fri, 11 Feb 2005 15:44:57 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: I-D ACTION:draft-ietf-dnsext-wcard-clarify-05.txt Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.49 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 Note that the title has been changed in the document to: The Role of Wildcard Domains in the Domain Name System Hmmm, I should have dropped the (first) " Domain" in there too. That's the first edit for version -06. The reason for the change is that the document is not just a clarification, but has minor edits. Changing the title was suggested by the chairs. (The draft file name won't change though, that would get confusing.) The abstract in the announcement is right - that was changed when the title removed clarification from it. At 15:21 -0500 2/11/05, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the DNS Extensions Working Group of the IETF. > > Title : Clarifying the Role of Wild Card Domains in >the Domain Name System > Author(s) : E. Lewis > Filename : draft-ietf-dnsext-wcard-clarify-05.txt > Pages : 18 > Date : 2005-2-11 > >This is an update to the wildcard definition of RFC 1034. The > interaction with wildcards and CNAME is changed, an error > condition removed, and the words defining some concepts central to > wildcards are changed. The overall goal is not to change wildcards, > but to refine the definition of RFC 1034. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-dnsext-wcard-clarify-05.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body >of the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-dnsext-wcard-clarify-05.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-dnsext-wcard-clarify-05.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > >[The following attachment must be fetched by mail. Command-click the >URL below and send the resulting message to get the attachment.] > >[The following attachment must be fetched by ftp. Command-click the >URL below to ask your ftp client to fetch it.] > -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar "A noble spirit embiggens the smallest man." - Jebediah Springfield -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From Morrowlmbr@ioc.net Fri Feb 11 18:09:59 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 SAA09644; Fri, 11 Feb 2005 18:09:58 -0500 (EST) From: Morrowlmbr@ioc.net Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzkFV-0002Tm-Gx; Fri, 11 Feb 2005 18:31:00 -0500 Received: from [202.149.203.2] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1Czjv6-0007Ko-MV; Fri, 11 Feb 2005 18:09:54 -0500 Received: from onec26.fsnet.co.uk ([213.184.179.202]) by participle.xeren.com (InterMail vK.4.04.00.00 4[3 Message-Id: Date: Fri, 11 Feb 2005 18:09:54 -0500 X-Spam-Score: 7.0 (+++++++) X-Spam-Flag: YES X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 From disman-archive@ietf.org Mon Feb 14 21:05:49 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 VAA14770; Mon, 14 Feb 2005 21:05:49 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0sQz-0006iQ-Uz; Mon, 14 Feb 2005 21:27:30 -0500 Received: from [211.243.68.48] (helo=ietf.org) by mx2.foretec.com with smtp (Exim 4.24) id 1D0s5x-0000Cz-Un; Mon, 14 Feb 2005 21:05:47 -0500 From: "Informe Exclusivo" To: ForumSocial2005@ns.cnri.reston.va.us Subject: Forum Social, "revolucao intersticial" e anarquia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 Content-Type: text/html Message-Id: Date: Mon, 14 Feb 2005 21:05:47 -0500 X-Spam-Score: 11.6 (+++++++++++) X-Spam-Flag: YES X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Destaque Internacional - Informes de Conjuntura - Ano VII - Nos

FSM:InformeCompletoGratuitoEnCastellano -- SendFreeAutomaticTranslator

Destaque Internacional - Informes de Conjuntura - Ano VII - Nos. 161-162 - Buenos Aires / Madri - Fevereiro, 2005 - Responsável: Javier González.-

5 o. Fórum Social Mundial: "diversidade", "revolução intersticial" e sonho anárquico

* Uma radiografia atualizada do chamado "movimento de movimentos" alter-globalista, suas metas, sua função dinamizadora, suas discussões estratégicas e de bastidores, seu poder real e seus calcanhares de Aquiles

*Um informe exclusivo, com entrevistas a José Saramago, Frei Betto, Leonardo Boff, Ignacio Ramonet, presidente Chávez, Alina Guevara, John Holloway, Michael Hardt, Tariq Ali, Atilio Borón, João Pedro Stédile, Ricardo Alarcón e outros participantes do FSM

FSM:InformeCompletoGratuitoEmPortugues

Introdução

* "O maior lobby da Terra" * O 5o. FSM em cifras

1. Frei Betto, Gramsci e Lenine: "pressão popular" para "conquistar" o poder

* Os recados de Frei Betto * Gramsci: Parcelas gradativas do poder * Lenine: "Doença infantil do comunismo" * "Política, mística e religião": a "companheira Aparecida" * "A dialética é que tem razão" * Filha do "Che" Guevara: "métodos velhos" e "erros" a serem evitados

2. ¿Transformar o mundo sem tomar o poder, ou tomar o poder para transformar o mundo?

* Holloway e a "revolução intersticial" * Tariq Ali: tomar o poder para transformar o mundo * Atilio Borón: atualidade de Lenine * "Certeza fundamental da superioridade do comunismo" * Stédile: "nossa querida Rosa Luxemburgo" * Rosa Luxemburgo e dilemas atuais

3. Chávez: ¿"novo libertador", sucessor de Fidel Castro?

* Presidente venezuelano incendeia o FSM * Acordo com Cuba comunista e eixo latino-americano das esquerdas * Chávez explica a estratégia gradualista e defende Lula

4. Foro de São Paulo, Cuba e Lula

* Genoíno, Regalado etc. * Guarda-chuvas político * Perfil discreto, para não prejudicar Lula * "Centralismo, modelo ultrapassado" * Direitos humanos, Cuba e "Che" Guevara

5. "Teologia da libertação", indigenismo e "sociedade futura"

* Pe. Torres: indígenas, "reserva espiritual" * Indígenas: "Nós somos o outro mundo" * Amazônia continental: alvo estratégico * Marilene: "distinção entre Estado e Nação" * Campos: "plurinacionalidade e multietnicidade"

6. Desconstrução de teorias, utopias e teologias...

* Utopistas versus anti-utopistas * Saramago: não-utopia * Ramonet: anti-utopia * Gadotti: "a época das certezas passou" * Siddhartha Shivamurthy * Teologia da libertação e desconstrução * Revolução sexual * D. Casaldáliga: "mudar a religião" * Pe. Barros: "Superar a convicção de que o cristianismo é a única religião verdadeira" * Inflexão no alter-mundialismo: rumo à anarquia política e religiosa? * O caminho rumo a um estado de coisas "tribal" * Estruturalismo e vida tribal

7. "Território Social Mundial" e Acampamento da Juventude, laboratórios de um "outro mundo" autogestionário e anárquico

* Acampamento Intercontinental * "Reinvenção da vida em sociedade" * "Horizontalidade" e "autogestão" * "Centros de Ação" * "Axônios"

8. FSM, "matança dos inocentes" e "diversidade" intolerante

* Aborto: flagrante contradição * "Ajudar as católicas a serem a favor do aborto" * Ministras de Lula * "Diversidade" intolerante

9. Esquerdas reconhecem calcanhares de Aquiles

* FSM: Força e fraqueza * Altmann: "Mas terá valido a pena?" * "Frustração" e "adiamento": incapacidade de convencer * Pe. Torres: "Vamos tardar 30 anos em ter nova alternativa" * Frei Betto, Aleida Guevara, Borón * Leonardo Boff: estrela do PT rejeitada "com desdém" * Weissheimer: "auto-engano" de dirigentes do PT

Conclusão: ver, julgar, atuar

* Um "outro mundo" que já está nascendo * "Diversidade": rumo a novas formas de totalitarismo? * Mapa de vulnerabilidades

LINKS GRATUITOS

FSM:InformeCompletoGratuitoEmPortugues

FSM:InformeCompletoGratuitoEnCastellano

InformesCompletosGratuitosForunsAnterioresEmPortugues

InformesCompletosGratuitosForumsAnterioresEnCastellano

FSM:MinhaOpiniao

FSM:MiOpinion

Remover

From Ferrellhlx@trebnet.com Tue Feb 15 03:01:21 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 DAA03801; Tue, 15 Feb 2005 03:01:21 -0500 (EST) Date: Tue, 15 Feb 2005 03:01:21 -0500 (EST) From: Ferrellhlx@trebnet.com Message-Id: <200502150801.DAA03801@ietf.org> Received: from [212.109.34.84] (helo=SIROPCHIK) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D0xz5-0005he-4J; Tue, 15 Feb 2005 03:23:05 -0500 Received: from cabana.net ([204.118.6.2]) by bewail.kiwi.net (InterMail vK.4.04.00.00 8[3 X-Spam-Score: 9.7 (+++++++++) X-Spam-Flag: YES X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 From owner-namedroppers@ops.ietf.org Tue Feb 15 13:49: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 NAA16224 for ; Tue, 15 Feb 2005 13:49:47 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D17f9-000BsP-C7 for namedroppers-data@psg.com; Tue, 15 Feb 2005 18:43:07 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D17f5-000BrX-A9 for namedroppers@ops.ietf.org; Tue, 15 Feb 2005 18:43:03 +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 j1FIgvqS003351 for ; Tue, 15 Feb 2005 13:42:58 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.2.0.14.2.20050215104624.03d3d278@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 15 Feb 2005 13:21:03 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: Key-rollover IPR disclosure 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.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,PORN_URL_SEX autolearn=no version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Dear Colleagues, An IPR[*] disclosure has been made. It relates to two drafts in our working group: draft-ietf-dnsext-trustupdate-timers draft-ietf-dnsext-trustupdate-threshold The disclosure has been made by "Diversinet.com" and can be found in the IETF IPR disclosure database: https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=530 and https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=531 Copies of the patent application can be found on http://stora.ogud.com/DNSSEC/key-rollover/key-rollover-patent-Application.pdf a copy of the patent certificate can be found in http://stora.ogud.com/DNSSEC/key-rollover/key-rollover-patent-certificate.pdf The licensing terms of this patent are not known yet. The chairs will inquire about licensing terms in neutral terms and report to the group. We want to issue is a "rat hole" alert: Working groups tend to discuss the validity of patent claims, the licensing terms and such at great lengths. In the end patent issues are not technical but legal issues. It is up to the implementors of technology under IPR to deal with these issues, not the working group. If the IPR prohibits implementation than the WG would like to know, from implementors. As rough consensus without running code does not make sense. Or to paraphrase the above: we all have an opinion on IPR, this is not the list to rehash those. --Olaf and Olafur DNSEXT WG Chairs We'll try to maintain documentation on our (experimental) DNSEXT twiki: http://dnsext.secret-wg.org [*] IPR == Intellectual PRoperty i.e. patent -- to unsubscribe send a message to namedroppers-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 Feb 15 20:55:02 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12831 for ; Tue, 15 Feb 2005 20:55:02 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1EJY-000IIa-0a for namedroppers-data@psg.com; Wed, 16 Feb 2005 01:49:16 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1D1EJU-000IIK-QG for namedroppers@ops.ietf.org; Wed, 16 Feb 2005 01:49:13 +0000 Received: (qmail 17302 invoked by uid 1016); 16 Feb 2005 01:49:38 -0000 Date: 16 Feb 2005 01:49:38 -0000 Message-ID: <20050216014938.17301.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: I have a feeling that the rules for setting TC need tweaking References: <4207C240.7030702@ehsco.com> <200502072312.j17NCRGb062820@drugs.dv.isc.org> 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=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The situation seems quite straightforward to me. Fundamental rules: (1) If the server's response doesn't fit into UDP, it has to be sent through TCP. (The server sets the TC bit; the client makes a TCP connection.) (2) If the server's response is a normal answer (or a CNAME), it must include the answer records (or the CNAME record). (3) If the server's response is a referral (in bailiwick), it must include the relevant IP addresses. See RFC 1034 section 4.2.1. Of course, by rule #1, this referral---with the IP addresses--- must be sent through TCP if it doesn't fit into UDP. The server might add other records (and often can improve performance by doing so), but those other records are optional. These fundamental rules are separate from the rules for assigning records to sections. In particular, it's not true that records in the answer section are the only required records; RFC 1123 section 6.1.3.2 third sentence is both inadequate and misleading. Here's what my software does: * Client: If a packet shows up with the TC bit, I throw it away and retry through TCP. * Server: If I have a packet over 512 bytes to be sent through UDP, I try throwing away the additional section _if the packet is not a referral_; if it's still over 512 bytes, I try throwing away the authority section _if the packet is not a referral_; it it's still over 512 bytes, I throw away _all_ records and set the TC bit. Each of these strategies has a perfect interoperability record. ---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 Feb 15 20:55: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 UAA12883 for ; Tue, 15 Feb 2005 20:55:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1EN1-000J9D-Bn for namedroppers-data@psg.com; Wed, 16 Feb 2005 01:52:51 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1D1EMy-000J6l-Fq for namedroppers@ops.ietf.org; Wed, 16 Feb 2005 01:52:48 +0000 Received: (qmail 20633 invoked by uid 1016); 16 Feb 2005 01:53:15 -0000 Date: 16 Feb 2005 01:53:15 -0000 Message-ID: <20050216015315.20632.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: WG Action: RECHARTER: DNS Extensions (dnsext) References: <200502092039.PAA11790@ietf.org> 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=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk A note to AXFR implementors worried about interoperability: Check out http://cr.yp.to/djbdns/axfr-notes.html for a description of exactly how the AXFR protocol works. ---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 hgrkgpqwi@eyah.com.au Wed Feb 16 02:54:43 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 CAA08866; Wed, 16 Feb 2005 02:54:42 -0500 (EST) Received: from [221.155.164.144] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D1KMO-0003AK-KZ; Wed, 16 Feb 2005 03:16:39 -0500 Received: from ebb.turbomail.net ([208.254.3.160]) by colloquium.turbomail.net (Sun Java System Messaging Server 6.1 HotFix 0.09 (built Aug 21 2004)) with ESMTP id <0D5Q00OS719SM45@colloquium.turbomail.net> for pwe3-admin@ietf.org; Wed, 16 Feb 2005 11:51:41 +0400 (IST) Received: from childhood.mailpride.com ([203.212.4.14]) by ebb.turbomail.net (Sun Java System Messaging Server 6.1 HotFix 0.07 (built Aug 27 2004)) with ESMTP id <0M7Q00ZX324GK83@ebb.turbomail.net> for pwe3-admin@ietf.org (ORCPT pwe3-admin@ietf.org); Wed, 16 Feb 2005 10:54:41 +0300 (IST) Date: Wed, 16 Feb 2005 11:53:41 +0400 From: "Roman Norris" To: Subject: this is a great artic|e : fOOtage can cOst y0u y0ur job Sender: "Roman Norris" Message-ID: <869077608241.ALA79452@childhood.mailpride.com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="Java.ORXXY.31459799320813909381" X-Priority: 3 X-MSMail-Priority: Normal Message-Id: <6433935771282453@GDUSQ> X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1437 X-Spam-Score: 4.0 (++++) X-Scan-Signature: 4d9ae72af46718088458d214998cc683 This is a multi-part message in MIME format. --Java.ORXXY.31459799320813909381 Content-Type: multipart/alternative; boundary="Java.LRTJO.35848467570725034980" --Java.LRTJO.35848467570725034980 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Minnesota, which can clinch a wild-card playoff spot with a loss by either Carolina or St. Louis this weekend, appeared on its way to retaking the lead. But a holding penalty on Birk -- the Vikings were flagged nine times for 78 yards -- wiped out a 16-yard run by Michael Bennett that would have given them the ball at the Green Bay 40 just before the 2-minute warning. --Java.LRTJO.35848467570725034980 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
3D""
 
 
 
En0ugh
Minnesota, which can clin= ch a wild-card playoff spot with a loss by either Carolina or St. Louis this weekend, app= eared on its way to retaking the lead. But a holding penalty on Birk -- the Vikings= were flagged nine times for 78 yards -- wiped out a 16-yard run by Michael Benn= ett that would have given them the ball at the Green Bay 40 just before the 2-minut= e warning.
 
The Vikings (8-7), though= , couldn't get what they needed from a pass defense that has struggled all season.
 
Government spokesman Raan= an Gissin said four soldiers were killed.
 
Six people were taken to = hospital -- four badly hurt, one with moderate injuries and one lightly injured, milit= ary sources said.
 
The sources said another = soldier remained beneath the rubble.
 
Gissin said rescue operat= ions were continuing Sunday night.
 
The attack "indicates tha= t unless there is decisive and sustained effort taken to dismantle the terrorist organization, it will be impossible to move towards normalizations and tow= ards political negotiations," Gissin told a news crew. "And I think the responsibility on that lies with the Palestinian Authority."
 
Shortly after the first b= last, a second explosion was heard in southern Gaza, but its precise location was = not immediately known.
 
Hamas, in a phone call to= CNN, said it had set off the first explosion near Rafah in cooperation with a group = called the Fatah Hawks.
 
There was no immediate in= formation available on that group, although it was believed to be linked to the Fata= h movement formerly led by the late Palestinian leader Yasser Arafat.=
 
Israeli military sources = said it was a coordinated attack, with Palestinians firing mortar shells and guns at t= he post when the explosives were detonated.
 
It was not clear whether = there were Palestinian casualties.
 
News video of the afterma= th showed soldiers using stretchers to transport troops who appeared to be severely = wounded.
 
In a pamphlet distributed= after the attack, Hamas said it had used 1.5 tons of explosives and had recorded vid= eo of the incident.
 
Palestinians have used tu= nnels in the area to smuggle weapons from Egypt. Israel has carried out operations to c= rack down on the smuggling.
Shell explosion in schoolyard
 
An Israeli tank shell exp= loded in a Gaza schoolyard Sunday morning, wounding eight Palestinian schoolchildren,= Palestinian medical and security sources said.
 
The children between the = ages of 6 and 12 -- sustained moderate to light injuries, the sources said.
 
The violence happened in = Khan Yunis in central Gaza
 
Israeli military sources = said that forces in the area identified what they thought was a number of mortar she= lls being fired towards Israeli settlements nearby.
 
In response, the forces f= ired towards the positions with light weapons, but did not fire a tank shell, the milit= ary sources said.
--Java.LRTJO.35848467570725034980-- --Java.ORXXY.31459799320813909381 Content-Type: image/gif; name="spaniel35.gif" Content-Transfer-Encoding: base64 Content-ID: <017156c4d3c0$2180fea0$176aa5c0@GDUSQ> Content-Transfer-Encoding: base64 R0lGODlhlgCbAMQAAFxfYK2srMcZGTG6FS0tLOvr69XV1XKMjLLQ45u1rtPq8oqIiKnCsM3k2tma mn0qKpGtpR1UED15LAn2qb/c9XFzczs7POdjY42bmRISEv8AADP/AMzMzP///0lHR////yH/C05F VFNDQVBFMi4wAwEAAAAh+QQFlgAfACwAAAAAlgCbAAAF/2BGjGRpnmiqrmzrvlYsz3Rt33il70fv /xiIcEgsGo/IZGLJbAafyqgUQa1ar9gsZcvtYgg8oFhKdprP6HR53dS63924FxwWj9l4tR6aV8L/ gHIUX3V2fH17iYqIfoGOgnGEhneMi5aVZY+akFuSk5SYl6KhQ5umcp6fh6SjrZWnsJ10qqusrrds sZy7soWgtrjBmbq8kKm0wMLJacTFkbM/hcvKtcnNzlzHANt109TVodfYCr3c5t3e397i2BAZ5+dA 6erW7M7u8Nzy8/TA9sX48u3j1y/cP4DvBA4kWBDRQYQKFzJsKOrhroDxfk2kaMkiuY8fMfrysZFj RY8gQ/8mjGbIpMuTKFO6Y9nypU1FMVMqmElT482fbXLKhNaTJNCjQYWqLCoR6dGcQn4QZVrSqRmP BwDMECGCaVOrNh8ewNHVq9GqYBkczJpvBq2zaK3+G7Kgrl0dHkaYhRsX6cEAd3dw0/sWXN+XfwPj zRuDb1S+Pg+rS6x4G2PDkKlKnmwPcGXLhDHzKex4c9DTScV5/ny58BnSpU2jZtL5SV3GHkBPLeoE Nm/Zs5eww6BPq4qRkX1rTntVnPEeZFci70FEuXXg7Co0Brwio6/qtjVa/xrWuV4H2msY914Tg/jM 46lXHZ7bs/e87N9fdx9fPjW1AAbYGQfodXObdIJJw0T/fxIp95+AENqToGIWJBQRfPoxyN+GhikT 4TjG6JbbXXlZOOJI4GnIoYMeBjfcDiS0ZeJ0Ke63IoY3dujhNfaBdptxFVo4ITpL4GjkaBnqKIxq /AmWG5BBTtdgjlT6V+WVHLYY4YcggkRcEFCmIGVsvSWJJZJkainOWOeQVRyNl9h4pppcNjNWAHj+ eMOYVuJiZnhZ0llnl15WkECYuJUwJkNTUinooISS0wOiKCwqXBZazuneo5BGuhOelJrAZ5qZ1hjo Ky7WFqqioyIDnB5bxkrfVmLupeSrsMraqafklMhCZHGSiquu2UVHwDSN3prrssQ2u2aYXIlAhpy2 ksfs/7XOziWiCU22emZ6FyaYn7WpZrsrrwgsJqoFHLSL6WPfimFOY62KG+4TgASY2rmeqkvCEuw2 IPDABLtbRZmAkkQFcU/uVa9lGdH2Br+x5BbSk7gtHHDBHBfMwDAfPefww0SW8rG5zlVgAEj45XXA wRt37LG7IFPQQboN2xuuztIsXG5M+EFg881jjSA0zAbLnLTPylaxHlv5RC01uDoc/TNKX4wAwNDk HHrsM0srbYVDXgMwKWgQT92WPkxfvVZZCnRwcwE7baMTBDGLfUWRypapbtqABy74MChvgrcHVNAt d9xZGa043QHkHXbYfJ/aSAJQY6z55pxv3ue+Si0uev/jYDxeQAKST5505Zb7AcGqiXYuu6GXoqvT 7bjHLbrpdHOCt+rAs943E7DLbvw5R/ee+/K6N8+889BHf/sXwAfv6LTFH6991Yk/7/334MtMffVL f3y9FIJrrz7g1Nke/vsdjz/x3uafL7G7ma+f/v76HJA8/AAMoMDkNz99Wa6Ai+Gf2niGopU5sHyh UxoBLcKwBCpwgdNhH+giKLYJ6k2AFbwgA32hwCBQTIAoHGDqUji92WFQhP0zoYA+SEMWMs+DNryb /mKnnhiajIM5HBgOg3ixC3ouDPeroRKXSMSCDdF9B1PDb2rHxCpasYlCXKGngnUI8l3xi2AM4BMd gS3/pYTxjCDUYr4aYUY0uhGFY3zXBqH4xjpiUXxqbKMd93jH+OWRjnwMpCDBF8c+DvKQhsxiIhHJ yEYqcpGOjKQhCynJSlqyg3+8pCY32QBKcvKTkfQkKEd5SFGS8pR1VMtYIInKVhowk62MZfj0dTLz wVKWuJwZLWtZy1WyMpepNNgueUlMBvjyl8A84zCLyUxbIjOZVlxmM6fpzGdCU2/SpKY2q3nNTW7z m9Q8ZjcbmU1wmlOVtxxnNMt5znaiU53BdKc8vylOeK5znvikZzrtyc58+vOV9sRmP/9J0F7uM5cF TehAT1ZPdSr0oQtl6EG9CdGKRlSiCL2oRTdqUFdy//Sj+GzoJUFK0nyK9JclTak/T9pHlbr0nyxl oUZfStNmxnSWwqypTmE6UV3u9KcEvalAywjUohZTqDklqlKNOlN5akeOTI1qQrullaYuVao0bVLs sMVVrO70bDMwW+OG5VWr8s1fI5Khdsha1pnmr2EyBNBa2dpWc4IrrUqYK13rqk2GWYB2rtPrXvkq kaAFR63HGmxZtWpYAFUwro+pGl0Sq1imgjUCEpDAADIL2cbWD4kfE2xls8pYzA5gABNIbWpN9jq9 IMwIou2qbPkaWeNE4LSoVa1uWfucZcV2trQFZ2kjcFvdGne1+uptX38L3OBmk3TEJa5mj0vd5Lp2 m9x3Gm1J/Spd3FK3urVULqyyq12QFs20p/3ud3ujNSWRt7wcZdht05va3KoXuRIV67QoC9+Nype+ 9b2vatuQh/f2t6L/tS+A70vgcxq4uc7NpnGmW98Fgzek/IVwhKc54dzi1r4XxvCB49vhD4N4t7Zg roY3HN4RzPfDxkVWhkf80PSg98P+S4eKV8xizFUIs5oV1kpnTOOpakW/G9kxj1ksZCMTeck93i5s nwzlKPu3RlUtspVNpeQqbzmojuqyl788z4Qd4sFaXqz9jImgeo3szXCOs5znPELkACAEACH5BAUK AB8ALAAAAACWAJsAAAX/4OeNZGmeaKqubOu+cPx2dG3feK7vfO//wKDQF/AMj8ikcsnUFZvQqHR6 fFKv2CzUqu16v04jeEzWcsvo9PKsbruJ4rd8fmPT7207fk/W8/9dfoCDVIKEh02GiItIioyPQI6Q kzuSlJc2lpiYmpuUnZ6QoKGMo6SIpqeEqaqArK18r7B4srN0tbZyuLluu7xqvr9owcJ9ccWix8il ysuozc6r0NGu09Sx1te02dq33N263+C94uPA5ebD6OnG7Njue8Twa+vzgfX2WfL5Vfj8hf7+Sdkn MFLAgokOIqS3MA3BhpUUQuw3sV1FMA8vZpKo8QMcjV8yguwgYuQ9k2Y42aIMsxKLSJAvNca8OLNi zYk3IeZsuHNhT4Q/CwYVOPRfUX5H8yW1t3ReU3hP3UVlNzVdVXNXx2UFt7VbV21fr4WlNjZaWWdn l6VFtrZYW2Fvf8XlNTdXXVt3Z+WFtbdVX1V/TwUmNThUYU+HNyXmpLJlncaOayy+NPkT5MgdKk/S nAzzwMuROT8SzcxzFNKLUD8zvQW0Y9WHYEtjnZA2E9mDcFezzZB3Et1/gL/z3ch1S+HxjK9Evo14 cecUoQthfoe6twDYs2vfzr279+/gw4sfT768efEVQgAAIfkEBZYAHwAsAAAAAJYAmwAABf/gl41k aZ5oqq5s675w/Hp0bd94ru987//AoPCXGRqPyKRyuSsyn9Co1OicWq/YZzXL7Xp12694fA2Tz+ik Oc1u99buuJwAn9vR9bv+m9/7sX1/glGBg4ZKhYeKQ4mLjj6Nj5I5kZOWNJWXk5maj5ydi5+gh6Kj g6Wmf6ipe6usd66vc7GycbS1bbe4abq7Z72+Y8DBfMSXw8ZcyMmAzJLLzlPQ0YTUodaK09hL2ttq 3qfggt3ijOV+5OdA6eqQ7bDvduzxYPT25/P3Nvn6mP1s/PoF1DfwXkF7B+kljLfwi4CHAh50gfhQ YpCGXjRo1CCgy0aNFtdF+9iRy0cNIYn/RKOY8srJlm/kwJQ5M8hLIZUefAypc2NJGiRrCDipMaIN kkOLAvXpIanSo0ybfpS680bPjQ+cahA6FaeRqjS0bq0BlujNpUXL+jT78yrHsCTN2hCbdiNXu16H OP1J1KJbuGajegg8djBhvGjfUj0c8jDivea+4nX7FLJhrIkL9zWamaNYv0EXFxVbkjLgx4JFSgYp Gm9XG1nJvj4LFTXmxKVDmxbd+PXVn6r1Mo3LOrVQuppf11bMW3ZlsJcVa+2N+Hfk1RF9/nbKE/ls 47jvsg7fnPx08YUv12yCZC9m4un7Zv3+9Ebo8m5z345e8nxm2Ovx8AllGp0mmH+iOcfc/3JtQaeb g1HtJlYNWUF03WoR9oUeaPQtqGCD+z0Y4oGOJYdYcEZ8pmCB6HlG1Ic53IegiOPxR2GJ6F2IYXoI dlYXizbiICOEz41YX3ha5ZhXexTB1iQOe/UHkUUsxfikBxVWdJyWWFZ5GnAUKpngkv8sxlmQ3JR5 I1JagYkERofgqIWaawYWIJl0ZjmlFHDiQycZfZYTqDiDglOoN4dukyg2i1rTKDWPRhOpM5MyU2ky lxqTKTGbBtOpL5/uEiouo9ZSqiynvpIqK6um0qopr44SKyizdlKrJrce86cwu4qRqyW/btJrMcN2 EewzxRqbrDLLZnGsJ802E60VzzpS7Us100qTrbbbVtMtFNdm8y24485ZbprnIpKuuuu+2a6771IR r7zz4llvTPeimK+A+6rUL77/skfHwAQXbPDBCCes8MIMN+zwwxA3HAIAIfkEBQoAHwAsAAAAAJYA mwAABf/g541kaZ5oqq5s675w/HZ0bd94ru987//AoNAX8AyPyKRyydQVm9CodHp8Uq/YLNSq7Xq/ TiN4TNZyy+j08qxuu4nit3x+Y9PvbTt+T9bz/11+gINUgoSHTYaIi0iKjI9AjpCTO5KUlzaWmJia m5SdnpCgoYyjpIimp4SpqoCsrXyvsHiys3S1tnK4uW67vGq+v2jBwn1xxaLHyKXKy6jNzqvQ0a7T 1LHW17TZ2rfc3brf4L3i48Dl5sPo6cbs2O57xPBr6/OB9fZZ8vlV+PyF/v5J2ScwUsCCiQ4ipLcw DcGGlRRC7DexXUUwDy9mkqjxR8aOHT52FKmR5EWTFVHZTlQJkWVDlwthIpRZkKZAm/9w8tOZj6c9 n/OAwhPqjig7o+mQmlM6jik4p92gapN6jSo1q9GwOtO6jCsyr8XAChP7iywvs7nQ2lI7iy0st63g qpJ7ii4pu6HwetK7iS8njiB5+L00+BPgwGEQ6zusuA7jxjUKT5KcDDJAy1MoP9LMDPPAx5Y5LxL9 zHMU0odQSzO9BTRk1YNgV2OdkDYT2X9wv7OtRHc81419b+PdG7hi4XeQeyOeRPkc5+GYNzKOmAGB ANiza9/Ovbv37+DDix9Pvrx58RVCAAAh+QQFMgAfACwAAAAAlgCbAAAF/+CXjWRpnmiqrmzrvnD8 enRt33iu73zv/8Cg8JcZGo/IpHK5KzKf0KjU6Jxar9hnNcvtenXbr3h8DZPP6KQ5J5EM3m12e07H 0eP2+92259dvejt6fXmDhDhrNgMbjI2MAxJ8jpOPkTSLjpY1mI2cGwObk6CXjqM2lKaSlJSaHp6r jU08r6w1ErCTmqKqnR6Tob+kja2uq8Qet7ilwMqMsjq0tLbNscK9NJTYmdq53M43sKk0ydQbzM3P Od0E5IyW7Rtzr5rzxdsWnpHwjxa+jv0A91Xj5U7euldvEioEiGhHLhKdII2bFAHishqi4A0g0U5C Blqf2JUiYe3TvWn/Sv/kK7mBRY5E/kpJqGiiHzyaH09aEOioRISRuAjkIxmT0c9rKBvhzDmMgL1G LhtCwwWpBDKKI25uAWnUKsVSmTzRtAn0H8F4EdK+IlAEocKEY6VOpTqWJ6URDAnA8kg03z+wPfE+ jcfU3VmqeLliXQNzojK2IqnFTdqp5uBJhUURxZzhKD/KuPiOUKzzRmMPIyJwHWVXqVVFiwVfXbWR 50a87W5noAgaFeTEot7CSQfGxD7HndxItHz2NUZjI/YK9gSpzS7kXdeS1J4ib41ECR/5DKZVBQ7u Tk+tggwLsjd02DfQ1Aw8cPeXc6FyxLwzNorznJkBEgkD4laOUfHRpBX/Syt4RwNMGaVFX3n/ARiY g/voluF0B4Y0m2vRBXNZaA66lwNp+mVAoYn5MSLbYXGxIlguadW41oddkXURik3h51AzOC0IhHY6 3MVhSm0FWEI3QuITDI+G+QiGG7QZh1WJJ3LWom7xbTfSCdT1lxJDu0AZDxg9kFCjJSd851wQzL0U pwUVPhiDm0TZ+eYMchXXgg1zEvEmInPWSWehzCHqHJ+m+fAnoIM6Giikg7ZJ6Yt4yqZonowCCsR9 pkWapmUClCrApZj+9qKlob4WqKWdfseEABo8gIUGuGqQRhqn9UArrrZekauuu57RKw/DBmvFsMUa 28MDpipbQ7LS0gBt/6nV2hBttsym58G12D6bbbbfRvsEtOSiqcOvw2pw6rftAlsDtPG+a228uNr7 wLB4sTusvTiwq2+uwe5b77zdepAsvPmya+vCUt5gcL7/Mtxuwfjme2/G7m6M6wgTu1uxDgk7bPHB J09L8MndQtyntrluXGq5/woQbMX+2pozvTGfPAK7Mqer8MpDd1x0xzmnTAPE9d5M9Ms1CPzA1N4u natgAj+Y9bdTY9xzyD9TKzTCGk+sc8lEJ8x0rgBb4HKjJOMrgGD8kuCv3PNeG296dYf8b6oqf8xu 2MCSELLPRfRd92/9iAoTz+3O7dTiGdyN8t3+grw45H9XDbPg+RJeq//hbE9+deKng22Z4zyQvvbH dpcuWAkCa5764qjZ/nQObJ9euewE1K768JSjXirgiZiqAQmvj94P8aaOAHHmqMOuPPO7B7y37qMT z7bf3OeJO9zaE5y51dNzLHnNd4f/u/n88uD3AyRZDjzHsKvO0Nuexo1v/ZGLmtxcV7PbGfB/gAsc 7LA2wNgVMH/jO1q6GgMubL2mgtLCYLZMZTMLdI1+RbAZ1ZxQQZuJimzu4lQGMMi4ch3Pg13rVwy3 gC0QYqkJKtRUnvRUBVflUIez++ENk7XDRf2wTpFiHQ7Nw0Mg3qcmrPIhEz/Xrj01qIlR3CEPb7hE VuUuUaBSFRKPeML/eIGQMYYSo6oAkkQtPkhQbtxiq5C3KhbZUY07kNoJWygnz/nxj3d8Y7N4FcdB BtKQZUgjIg+5yCl4sZGMhCQUJrXIY0nyko7EpCbFYMlNehIJnazBBz5ggBtUYJQVMEIFSumBAIyy BgtgwCetEEoajJKVsETlEDDwSg/EkpUcIOUsMzmEW9Lgl7z8QCoBgAEDGCAAADgmNAPwTACscpTQ rEAAslkAUgYgltBs5TeHeYRaesCYpxylOlNpAHUK85ykVOc23anNV7ZznbrUJTmHABNwLuAGxmSA MF2pzAXospvQvOU1SylQZTLzlQtl5we++c59CgEm98SlLYXZzlKm/7Oe7hQmNj3Q0Vb2kqA0KKlJ nzlRi/JzB/4EKEeFadCColKbC0jlSEuKUpN+IKUVvaVDXQonI6Dzlt10aDcLkFSdtpSnCu1pMN/Z 0AIQ9aJGcGY4XVmAXy4zo/8kqQH+Sc1w3hMDvzxmU3050qt+apgVAGk03UqEYSazpXStq13HmVe9 CiGugJ0rDgLLhcAuU5KEfWsxQxpOmTY2CAzQKA8Iqk6rSlKlihUCUteJg20eFgiY7QFBndnWRobW UUYd6E2daVBqjnWVY21lNReQ0WkuFZhLfaxalUrTqb7zmqQMKzUDOltnpjS2zfRmNMtq3IWWFLhd JQ4QFHrPuAq1pv/QRCg8s0vKs97Tnt0t7W7RGlChPtWbNEUlUzGAUoLmFJWjLe9SSRremXKAq4Il X2e1KlN3etSY213pR635TezS978TXegNKMtZnCo4txhY7i35ql6ECtSq2q0pAKrLVt6WEsL51e8N MipTplazw8tsKzbxOtykchfBIV0wUjkQVtqG16NJDe6G/XvgiZq4pSP9qEoH/NwcRzdipkzsRiU7 4ACv1KHJtO55ERxhtH7Wp59NZ4Tn62BsBnaqHVYmZaMJ1Z8Oeac05SZeoeYDAOdyqG1NJytrGl7b wjekYX1zlv1rX/cStMVAtSyA6YxmXH53vrnVJ5tFy1cbeFaah2X/b6RZG0vhGteXWr2yLx9tA9q+ dps0cC0Dlunp2EL61NJkLapDPVtLn1hdfY11/2RNa3PSepO23nSjVRlXX/baBw4O8V81reTBbjPC WDAndCu6S/DO+dU2OPSRh9BkUTIbB0m1bBmyis2pcuAIKK30RnXr0/u6+a+KXjJMvZyFWhqYpONk rmUjq9xAg7ms9K23tefM1xZHF7atXWlDr4zOZ9qYuzpObgFkOclmDzXa8fxwfe383QPD89xaHuxm bRrP99aX4Ko1MqHnGc9rq2EHonZ0ugOd4gQHE8PnNfM7xdthchNYrnIONIpLjGUNE7mlGtbCDkis 5+P+88wh/elI/1GqUpoDoK2RRTa9m9rkIj9c3eG+aT6BvnJQwrTYS42lfK1d5Zxa/J4WdzLEu1pT q778oRz/ashBzlCIat3DcBd2OVUZ0uhilsFQrqyz7W1KIzu0qtVtcjpLTnefonjAhF7zEmytzUyv GtMGh2WrN11jDlx6wZZntSwfzWnMB9vR48RpqLPJ6crTOAq5vvUlYy97SNK+9pU0wrGPrYPS/xUI ON09gVlvc0+aM+mSHTe1mQoEwIv5lT3d5/G9uVZYWvPXXz9saIsdamzy/vqOt35+uV+s6ded465s KEXxzmCJqxPTlQ2xewPb3l7auK2H1jSvUrtwqse/0E/nYX52W/8HNlwM92bxV38/FYDm9nxmNmqf RHTWxmMZF2AG1VUVlVN/ZnFyBmgq112zBX0iOFEGSGfQ1iwYdW7wtHB81WT413H2BoBy5kyf131X p4DlRoPclG1upYIuyGKcNYBTJlGjdl95ZoOfhYNaRlvEF35E5YP6FGeDVlntZGccp1AydoMjaINH VWduxX3Yl1himHq/Bk7RdHpJRmykFmm+x17Ft3+4l1e3F4d0WIdeMId2CId5aFF4uIdk0Id+yEmB KH2DSE6AWIhccIiImGyL+EmK2IjEBImYZAYyUImWeImYmImXCDWa2Ime+ImgeEUhRokZYGKmeIqo mIqquIqs2Ir/rviKsBiLsphNIpY7NHiLuJiLuriLvNiLvviLwBiMwiiMBXZlpDiMnpeMyriMzNiM zviM0BiN0jiN1CiNOYV9ggQpyFiN3NiN3viN4AiN12iMhLKN4XiO6JiO6TiOtcgW5qiO8BiP8tiM 7DhrbvKO85iP+niO9SgroYKP+xiQAmmN4GePdsKL1yhqaCVqRriQC5mMDwmRCsle9EhgywhYE0mR NIZWnueQzdSRGllgG+mRZUWSDRmRFYmNh6SLC1ATnjcCG5aMAHACH3koGQCRI1CTGfCROGkVHWkC sOUeNEYCL2kC1AQZRUkAHPAfS+mSasSQEFmQ/qiNuUgUOdmU/zHpeTO5BWVVAp6GAUT5bTu5jFa5 k2AJk5DRTL8hliOQlEKJlGzJloJBWzskl0LJjP2YjfeIiy05lhtZlFnJltf3lWgpVmdZBGLJk0Pp l5Vni/cFk3IZACUAmE2plHAJl3GZjC9ylDl5lhaQkuT4j7i4lc0ImTLpkmJpAX35k2nJFopJmmSJ mEkpljNZAUXQlpW5lSR1mbKZmW55lWpUasqYlys5mrh5X5rZm4J5fY9ZBGfJhM7plcoIm8iZmslp mTtJAqtZmdppnd7pm7lpkWIknMMplXp5kHx5lc+JldN5nKxpAosZmcOpnjm5lV2JmK5JlLgpG651 KLOple5pmv/XCZ7lqZLHWJV4EZY0uZVeaZO/8U2ymZaxeZv7maAVGmFtWaGBuZjSCaA3eZ0k4Z0C WqChSZXMqCqetqA0KaAweZbJqZjN2Z0xepWJ2ZK7+aEj6qEjSp3ciRfeaZ94aZ7F6YwcOZDPWKTD qZHrqKT7SJwHaqRQGqXf6KTlCJBSeqX5SKWiiaVc2qUk2o5KaaVeOqZTKqRPSqZoaqRaaqJp2qZN aqZVuntyOqd0Wqd2eqd4mqd6uqd82qdrKisQqHeCOqiEWqiGeqiImqiKGmJmZ5Cw5KB4FKmSOqmU WqmWeqmYmqnpgVbtqE19+qmgGqqiOqqkumt35KmlmqqquqoprGqnRxhJkoiCsTqJszp7tSpJj3ir SpCrgNSrvvqrwBqswjqsxEoAIQAAIfkEBTIAHwAsDwCAAHgACgAABf/gJzrX5Yifc6Kj6rIvqsor O5a1WJp0Hbuz1uoF/BVPR5hmubyImqwLk7mSLmXLlUCTS001Tu80vNUIPlbN8yvanj/uzxc6P5en 2mb5BEVZBYACK3gjTG1cNkwXew5LAotZcIZpa2ZQcZJ2d4B8joBOZYBQjYhog2BRTTiFYKhiqFs5 pFUnViiXlnJla6BmmYdvaFe3ZjvAKlC2NnKuOl9vUibDjXuxqWo2mL9b0a3Yjla9b9rKlVSSX7XD ic3CYKvM0ojUpJF+6yjacbGWpOaRmMjhA7fqjr1ZYjqFcYYNyzMvZ9LIijTLChJc9ZitebRQWR93 LD4CAwnszj8uaahL/BHFhdqhUvkcGWJmaVgsW8NEvjrHMORDTB8NnsKTMsvHJi7XdEF3MN0hZE5y tmMoshxNJnZ8uZO1dJnXr2DBBoExNqxZIWfTsggBACH5BAUyAB8ALA8AgAB4AAoAAAX/4CcuABCI H6aio+qyL7q2LFyebHXLczq7vcBvBYwViUVYZrn0iJo5JhMjsjBlS+qHkNFipc6UNFOpQivX7dhM YKvHgLdUPn02uV11HAW4c3FSCyNpfzVMfVkYh3hUeBlydmBvbo5NgmAEcZVnWTR6UWQlgmIZHqWD UIVfWhWNSyipV3OfeJO2H4gsTSV7jIqnuTWffGNtahYLr6RZqiLBuqeUpWTTj8eITrXHxNaRdZt5 z9B7zrsAo5adv7+d3MLa21zJ8srFJ9rw4ua9Y6PrpJfIgKoxb80vXHVWAUR0IkAsdmoi7bAFpVy3 YbBOWekGzlsWRIE2VhISjZEhP9aKP6XsYupRPYGgArnLKAlfNDro+oGcUlHPQTteaLZzKFONilMv yXHrifCiym1Ng/YQRrWq1aueYEzFinUr168hAAAh+QQFMgAfACwPAIAAeAAKAAAF/+AnOtfliJ9z oqPqsi+qyis7lrVYmnQdu7PW6gX8FU9HmGa5vIiarAuTuZIuZcuVQJNLTTVO7zS81Qg+Vs3zK9qe P+7PFzo/l6faZvkERVkFgAIreCNMbVw2TBd7DksCi1lwhmlrZlBxknZ3gHyOgE5lgFCNiGiDYFFN OIVgqGKoWzmkVSdWKJeWcmVroGaZh29oV7dmO8AqULY2cq46X29SJsONe7GpajaYv1vRrdiOVr1v 2sqVVJJftcOJzcJgq8zSiNSkkX7rKNpxsZak5pGYyOEDt+qOvVliOoVxhg3LMy9n0siKNMsKElz1 mK15tFBZH3csPgIDCezOPy5pqEv8EcWF2qFS+RwZYmZpWCxbw0S+Oscw5ENMHw2ewpMyy8cmLtd0 QXcw3SFkTnK2YyiyHE0mdny5k7V0mdevYMEGgTE2rFkhZ9OyCAEAIfkEBTIAHwAsDwCAAHgACgAA Bf/gJy4AEIgfpqKj6rIvurYsXJ5sdctzOru9wG8FjBWJRVhmufSImjkmEyOyMGVL6oeQ0WKlzpQ0 U6lCK9ft2Exgq8eAt1Q+fTa5XXUcBbhzcVILI2l/NUx9WRiHeFR4GXJ2YG9ujk2CYARxlWdZNHpR ZCWCYhkepYNQhV9aFY1LKKlXc594k7YfiCxNJXuMiqe5NZ98Y21qFguvpFmqIsG6p5SlZNOPx4hO tcfE1pF1m3nP0HvOuwCjlp2/v53cwtrbXMnyysUn2vDi5r1jo+ukl8iAqjFvzS9cdVYBRHQiQCx2 aiLtsAWlXLdhsE5Z6QbOWxZEgTZWEhKNkSE/1oo/pexi6lE9gaACucsoCV80Ouj6gZxSUc9BO15o tnMoU42KUy/JceuJ8KLKbU2D9hBGtarVq55gTMWKdSvXryEAACH5BAUyAB8ALA8AgAB4AAoAAAX/ 4Cc61+WIn3Oio+qyL6rKKzuWtViadB27s9bqBfwVT0eYZrm8iJqsC5O5ki5ly5VAk0tNNU7vNLzV CD5WzfMr2p4/7s8XOj+Xp9pm+QRFWQWAAit4I0xtXDZMF3sOSwKLWXCGaWtmUHGSdneAfI6ATmWA UI2IaINgUU04hWCoYqhbOaRVJ1Yol5ZyZWugZpmHb2hXt2Y7wCpQtjZyrjpfb1Imw417salqNpi/ W9Gt2I5WvW/aypVUkl+1w4nNwmCrzNKI1KSRfuso2nGxlqTmkZjI4QO36o69WWI6hXGGDcszL2fS yIo0ywoSXPWYrXm0UFkfdyw+AgMJ7M4/LmmoS/wRxYXaoVL5HBliZmlYLFvDRL46xzDkQ0wfDZ7C kzLLxyYu13RBdzDdIWROcrZjKLIcTSZ2fLmTtXSZ169gwQaBMTasWSFn07IIAQAh+QQFMgAfACwP AIAAeAAKAAAF/+AnLgAQiB+moqPqsi+6tixcnmx1y3M6u73AbwWMFYlFWGa59IiaOSYTI7IwZUvq h5DRYqXOlDRTqUIr1+3YTGCrx4C3VD59NrlddRwFuHNxUgsjaX81TH1ZGId4VHgZcnZgb26OTYJg BHGVZ1k0elFkJYJiGR6lg1CFX1oVjUsoqVdzn3iTth+ILE0le4yKp7k1n3xjbWoWC6+kWaoiwbqn lKVk04/HiE61x8TWkXWbec/Qe867AKOWnb+/ndzC2ttcyfLKxSfa8OLmvWOj66SXyICqMW/NL1x1 VgFEdCJALHZqIu2wBaVct2GwTlnpBs5bFkSBNlYSEo2RIT/Wij+l7GLqUT2BoAK5yygJXzQ66PqB nFJRz0E7Xmi2cyhTjYpTL8lx64nwosptTYP2EEa1qtWrnmBMxYp1K9evIQAAIfkEBTIAHwAsDwCA AHgACgAABf/gJzrX5Yifc6Kj6rIvqsorO5a1WJp0Hbuz1uoF/BVPR5hmubyImqwLk7mSLmXLlUCT S001Tu80vNUIPlbN8yvanj/uzxc6P5en2mb5BEVZBYACK3gjTG1cNkwXew5LAotZcIZpa2ZQcZJ2 d4B8joBOZYBQjYhog2BRTTiFYKhiqFs5pFUnViiXlnJla6BmmYdvaFe3ZjvAKlC2NnKuOl9vUibD jXuxqWo2mL9b0a3Yjla9b9rKlVSSX7XDic3CYKvM0ojUpJF+6yjacbGWpOaRmMjhA7fqjr1ZYjqF cYYNyzMvZ9LIijTLChJc9ZitebRQWR93LD4CAwnszj8uaahL/BHFhdqhUvkcGWJmaVgsW8NEvjrH MORDTB8NnsKTMsvHJi7XdEF3MN0hZE5ytmMoshxNJnZ8uZO1dJnXr2DBBoExNqxZIWfTsggBACH5 BAUKAB8ALAAAAACWAJsAAAX/4OeNZGmeaKqubOu+cPx2dG3feK7vfO//wKDQF/AMj8ikcsnUFZvQ qHR6fFKv2CzUqu16v04jeEzWcsvo9PKsbruJ4rd8fmPT7207fk/W8/9dfoCDVIKEh02GiItIioyP QI6QkzuSlJc2lpiYmpuUnZ6QoKGMo6SIpqeEqaqArK18r7B4srN0tbZyuLluu7xqvr9owcJ9ccWi x8ilysuozc6r0NGu09Sx1te02dq33N263+C94uPA5ebD6OnG7Njue8Twa+vzgfX2WfL5Vfj8hf7+ SdknMFLAgokOIqS3MA3BDxA/NKyjcGI/i+0wgnmoMVPFjj8IgqwhcmSHkiNR6oLkmPKjRJM5VHZk ufIjzDA3IQLM+fJlwpxXZGoUipGoRaMTkTZUupApQqcFoUbMB1VgVZ32rvaEp5WqzZs4qv4Ty4+s V7BBv6Il6XItW7cD28KlOVMt1pt0h9r1eVcv3Chms6p1G3heYa6D1x52t5hd43SPzUUeNxlc5W6X tWW+tpla52ifnYVeNhpZ6WKnhaX+tZpX61yvbcWeNRtW7Va3VeU+tZtU71C/PQXfNJxTYrTFLyX/ dBzs8knPk/3d0hxvdZjRH2VnNv1nd4bflWxfxIBAgPPo06tfz769+/fw48ufT79+/AohAAA7 --Java.ORXXY.31459799320813909381-- From kera6nfu@kati.com Thu Feb 17 05:30:46 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 FAA03756; Thu, 17 Feb 2005 05:30:46 -0500 (EST) Received: from usen-221x255x150x211.ap-us01.usen.ad.jp ([221.255.150.211]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D1jHD-0006ch-QA; Thu, 17 Feb 2005 05:52:57 -0500 Received: from angela.kera6nfu@kati.com ([132.151.6.1]) by splotch.kera6nfu@kati.com with MailEnable ESMTP; Thu, 17 Feb 2005 04:30:30 -0600 Date: Thu, 17 Feb 2005 04:30:30 -0600 Message-Id: <766000812440.98129@dagian> From: augnete cooke To: Discuss Subject: CiaIis - Stable Erections MIME-Version: 1.0 Content-Type: text/plain; charset="iso-6055-4" Content-Transfer-Encoding: 7Bit Content-Description: alphabet divergent docile X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7Bit Special offer! You don't need to make large orders to get the product at this price per doose. All the prices mentioned are retail prices! One Time DISC0UNT 0RDER for CiaIis And Wiaggra! ToDAY CiaIis only 3.00 per doose.Wiaggra is 0.87 per doose. The Cheapest Pharm On The Net That offers CiaIis ,Wiaggra Xonax ,M3ridia ,Pr0zac ,S0ma ,Pr0opecia And Many Meds... http://www.ultrameds4sale.com From hicymjlrrk@wp.pl Thu Feb 17 08:40:14 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 IAA22845; Thu, 17 Feb 2005 08:40:14 -0500 (EST) Received: from [220.72.97.55] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D1mEZ-0003Dm-Vs; Thu, 17 Feb 2005 09:02:26 -0500 Received: from osha.france.com ([32.32.118.219]) by albany.france.com (Sun Java System Messaging Server 6.1 HotFix 0.08 (built Aug 24 2004)) with ESMTP id <0D7I00AL529QV36@albany.france.com> for l3vpn-admin@ietf.org; Thu, 17 Feb 2005 09:39:02 -0400 (IST) Received: from conductor.wx88.net ([240.124.100.56]) by osha.france.com (Sun Java System Messaging Server 6.1 HotFix 0.06 (built Aug 20 2004)) with ESMTP id <0P0C00MU640HY66@osha.france.com> for l3vpn-admin@ietf.org (ORCPT l3vpn-admin@ietf.org); Thu, 17 Feb 2005 14:33:02 +0100 (IST) Date: Thu, 17 Feb 2005 17:31:02 +0400 From: "Eliza Howard" To: Subject: Have a medical breakthrough Sender: "Eliza Howard" Message-ID: <017315174255.OZD00819@conductor.wx88.net> MIME-Version: 1.0 Content-type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7Bit X-Spam-Score: 6.4 (++++++) X-Spam-Flag: YES X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7Bit You can feel the vitality V*I.O'X.X 25 m.g 3o P||LS 72.50 V,1*A'G.R.A 1Oo m,g 32 P1l|S 149.0o C'1*A*L,1.S 2o m.g 1o Pi||S 79.O0 more Drugs here : http://meredith.tehexpertz.com/a/209015/sharpe ! Same Day Sh1pp1ng ! We Als0 have in StOck: X,A*N.A.X 1 m.g 3o P|LLS 79.OO P*R'0.Z.A.C 20 m.g 3O PiL|S 110.Oo P,A.X*1.L 20 m'g 2o PI|lS 155.oo M,E.R.I*D'I.A 1o m.g 3O PI||S 147.Oo thank you Shawn Gaston Fletcher LION Bioscience AG, D-69123 Heidelberg, Germany Phone: 711-514-1154 Mobile: 296-751-2196 Email: hicymjlrrk@wp.pl your reply to this confirmation message is not needed This product is a 7[2 From owner-namedroppers@ops.ietf.org Sat Feb 19 02:15: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 CAA24318 for ; Sat, 19 Feb 2005 02:15:03 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2Oky-000Jw4-7U for namedroppers-data@psg.com; Sat, 19 Feb 2005 07:10:24 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2Okx-000Jvt-6P for namedroppers@ops.ietf.org; Sat, 19 Feb 2005 07:10:23 +0000 Received: from [202.13.76.233] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j1J7A9fI022127; Sat, 19 Feb 2005 02:10:12 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Sat, 19 Feb 2005 16:09:59 +0900 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: editorial question 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 In preparing the wcard draft, it was suggested that I present a "fixed" (as in grammatically fixed) version of 3c. Good idea, 'cept I'm not sure how to do it. (At my college if you could spell it's full name you passed the English requirement for graduation. ;) ) 3c is: # c. If at some label, a match is impossible (i.e., the # corresponding label does not exist), look to see if a # the "*" label exists. I want to indicate that the last "a" ("x"or the last "the") is to be stricken. (If I had to add a word, I'd put it in []'s.) Does anyone know the convention for "striking" a word to fix the grammar? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Achieving total enlightenment has taught me that ignorance in 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 aelfwyn77oi@lozu.com Sat Feb 19 12:20:56 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 MAA22409; Sat, 19 Feb 2005 12:20:56 -0500 (EST) Received: from 82-32-30-151.cable.ubr04.azte.blueyonder.co.uk ([82.32.30.151]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D2Yda-0004mA-79; Sat, 19 Feb 2005 12:43:37 -0500 Received: from sclerotic.aelfwyn77oi@lozu.com ([132.151.6.1]) by trial.aelfwyn77oi@lozu.com with MailEnable ESMTP; Sat, 19 Feb 2005 11:23:16 -0600 Date: Sat, 19 Feb 2005 11:23:16 -0600 Message-Id: <100711905.82828@arla> From: kailin kennedy To: Dinaras Subject: c0rel and ad0be software for a cheap price MIME-Version: 1.0 Content-Type: text/html; charset="iso-0855-3" Content-Transfer-Encoding: 7Bit Content-Description: claustrophobia shrapnel interrogate X-Spam-Score: 3.4 (+++) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7Bit
You looking for inexpensive software for your PC ?
Latest graphics and publishing software from Corel,Macromedia,Adobe etc
are available in our site.You can get them for a very cheap price.
Check our 0em software site.Here is a brief list of what we have :

Microsoft Windows XP Pro + Microsoft Office XP Pro -89.95 $
Windows XP Professional With SP2 Full Version -79.95 $
Windows 2000 Professional -59.95 $
Macromedia Dreamwaver MX 2004 + Flash MX 2004 -109.95 $
Adobe Photoshop CS with ImageReady CS -99.95 $
Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 -129.95 $
Adobe Photoshop CS + Adobe Illustrator CS + Adobe InDesign CS -149.95 $
Corel Draw Graphics Suite 11 -59.95 $
Corel Photo Painter 8 -59.95 $
Corel WordPerfect Office 10 -69.95 $


These are some of the software we have.Please check our site
to find more products.You save up to % 80 on all products.

Check our site

Thanks
From owner-namedroppers@ops.ietf.org Sat Feb 19 20:54:38 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28808 for ; Sat, 19 Feb 2005 20:54:38 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2gA3-000KbW-UZ for namedroppers-data@psg.com; Sun, 20 Feb 2005 01:45:27 +0000 Received: from [63.208.196.171] (helo=outbound.mailhop.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2gA1-000KbC-Di for namedroppers@ops.ietf.org; Sun, 20 Feb 2005 01:45:25 +0000 Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.44) id 1D2gA0-0000Td-Bt for namedroppers@ops.ietf.org; Sat, 19 Feb 2005 20:45:24 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j1K1jMG28214 for ; Sat, 19 Feb 2005 17:45:23 -0800 Date: Sat, 19 Feb 2005 17:45:22 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed Resolution to Issue 78: UNIQUEness Probing Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba 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 The text of Issue 78, raised by Thomas Narten during the AD review, is available here: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html#Issue%2078 A version of the document incorporating the proposed resolution is available here: http://www.drizzle.com/~aboba/DNSEXT/draft-ietf-dnsext-mdns-38c.txt The proposed resolution is as follows: Change the first part of Section 2.1.1 to: "2.1.1. LLMNR header format LLMNR queries and responses utilize the DNS header format defined in [RFC1035] with exceptions noted below: 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ID | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |QR| Opcode | Z|TC| U| C| Z| Z| Z| RCODE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QDCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ANCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | NSCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ARCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: ID A 16 bit identifier assigned by the program that generates any kind of query. This identifier is copied from the query to the response and can be used by the sender to match responses to outstanding queries. The ID field in a query SHOULD be set to a pseudo-random value. For advice on generation of pseudo-random values, please consult [RFC1750]. QR A one bit field that specifies whether this message is an LLMNR query (0), or an LLMNR response (1). OPCODE A four bit field that specifies the kind of query in this message. This value is set by the originator of a query and copied into the response. This specification defines the behavior of standard queries and responses (opcode value of zero). Future specifications may define the use of other opcodes with LLMNR. LLMNR senders and responders MUST support standard queries (opcode value of zero). LLMNR queries with unsupported OPCODE values MUST be silently discarded by responders. TC TrunCation - specifies that this message was truncated due to length greater than that permitted on the transmission channel. The TC bit MUST NOT be set in an LLMNR query and if set is ignored by an LLMNR responder. If the TC bit is set in an LLMNR response, then the sender SHOULD discard the response and resend the LLMNR query over TCP using the unicast address of the responder as the destination address. See [RFC2181] and Section 2.4 of this specification for further discussion of the TC bit. U UNIQUE - specifies that this message is a UNIQUEness query. The U bit MUST NOT be set in an LLMNR response, and if set is ignored by an LLMNR sender. If the U bit is set in an LLMNR query, this indicates that the sender believes that it is authoritative for the name. See Section 4.1 and 4.2 for discussion of name conflict detection. C Conflict - specifies that a sender has previously received multiple LLMNR responses to this query. The C bit MUST NOT be set in an LLMNR response, and if set is ignored by an LLMNR sender. Responders do not respond to LLMNR queries with the 'C' bit set; since no response is expected, LLMNR senders do not retransmit. Z Reserved for future use. Implementations of this specification MUST set these bits to zero in both queries and responses. If these bits are set in a LLMNR query or response, implementations of this specification MUST ignore them. Since reserved bits could conceivably be used for different purposes than in DNS, implementors are advised not to enable processing of these bits in an LLMNR implementation starting from a DNS code base." In Section 2.3, change: "[c] Responders MUST respond to LLMNR queries for names and addresses they are authoritative for. This applies to both forward and reverse lookups." To: "[c] Responders MUST respond to LLMNR queries for names and addresses they are authoritative for. This applies to both forward and reverse lookups, with the exception of queries with the 'C' bit set, which do not elicit a response." In Section 2.7, change: "If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT, then a sender SHOULD repeat the transmission of the query in order to assure that it was received by a host capable of responding to it. Retransmission of UDP queries SHOULD NOT be attempted more than 3 times. Where LLMNR queries are sent using TCP, retransmission is handled by the transport layer." To: "If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT, then a sender SHOULD repeat the transmission of the query in order to assure that it was received by a host capable of responding to it. Retransmission of UDP queries SHOULD NOT be attempted more than 3 times. Where LLMNR queries are sent using TCP, retransmission is handled by the transport layer. Queries with the 'C' bit set MUST be sent over UDP and MUST NOT be retransmitted." In Section 2.9, change: " In LLMNR, the additional section is only intended for use by EDNS0, TSIG and SIG(0). As a result, senders MAY only include pseudo RR- types in the additional section of a query; responders MUST ignore the additional section of queries containing other RR types." To: "In LLMNR, the additional section is primarily intended for use by EDNS0, TSIG and SIG(0). As a result, unless the 'C' bit is set, senders MAY only include pseudo RR-types in the additional section of a query; unless the 'C' bit is set, responders MUST ignore the additional section of queries containing other RR types. In queries where the 'C' bit is set, the sender SHOULD include the conflicting RRs in the additional section. Since conflict notifications are advisory, responders SHOULD log information from the additional section, but otherwise MUST ignore the additional section." Change Section 4 and 4.1 to the following: "4. Conflict resolution The uniqueness of a resource record depends on the nature of the name in the query and type of the query. For example it is expected that: - multiple hosts may respond to a query for an SRV type record - multiple hosts may respond to a query for an A or AAAA type record for a cluster name (assigned to multiple hosts in the cluster) - only a single host may respond to a query for an A or AAAA type record for a name. By default, a responder SHOULD be configured to behave as though all RRs are UNIQUE on each interface on which LLMNR is enabled. When name conflicts are detected, they SHOULD be logged. To detect duplicate use of a name, an administrator can use a name resolution utility which employs LLMNR and lists both responses and responders. This would allow an administrator to diagnose behavior and potentially to intervene and reconfigure LLMNR responders who should not be configured to respond to the same name. 4.1. Uniqueness Verification Prior to including a UNIQUE resource record in a response, for each UNIQUE resource record in a given interface's configuration, the host MUST verify that there is no other host within the scope of LLMNR query propagation that can return a resource record for the same name, type and class on that interface. Once a responder has verified the uniqueness of a UNIQUE resource record, if it receives an LLMNR query for that resource record, with the 'C' bit clear, it MUST respond. Uniqueness verification is carried out when the host: - starts up or is rebooted - wakes from sleep (if the network interface was inactive during sleep) - is configured to respond to LLMNR queries on an interface enabled for transmission and reception of IP traffic - is configured to respond to LLMNR queries using additional UNIQUE resource records - verifies the acquisition of a new IP address and configuration on an interface To verify uniqueness, a responder MUST send an LLMNR query with the 'U' bit set for each UNIQUE resource record. If no response is received, the sender retransmits the query, as specified in Section 2.7. If a response is received, the responder MUST NOT use the UNIQUE resource record in response to LLMNR queries. Periodically carrying out uniqueness verification in an attempt to detect name conflicts is not necessary, wastes network bandwidth, and may actually be detrimental. For example, if network links are joined only briefly, and are separated again before any new communication is initiated, temporary conflicts are benign and no forced reconfiguration is required. Triggering a reconfiguration in this case would not serve any useful purpose. LLMNR responders SHOULD NOT periodically attempt uniqueness verification. 4.2. Conflict Detection and Defense Hosts on disjoint network links may configure the same name for use with LLMNR. If these separate network links are later joined or bridged together, then there may be multiple hosts which are now on the same link, trying to use the same name. There are several mechanisms by which ongoing name conflicts may be detected. [a] Receipt of a query with the 'U' bit set. Whenever an LLMNR responder receives an LLMNR query for a UNIQUE resource record with the 'U' bit set, if the source IP address does not match an IP address configured on that interface, this indicates a conflict. [b] Conflict notification queries. When an LLMNR sender receives multiple LLMNR responses to a query, it MUST send another query for the same resource record, this time with the 'C' bit set, with the answers received included in the Additional section. Queries with the 'C' bit set are considered advisory and responders MUST verify the existence of a conflict by other means before acting on it. A responder receiving a query with the 'C' bit set MUST NOT respond. If the resource record is not UNIQUE, then the responder MUST ignore the query. If the resource record is UNIQUE, then the responder MUST send its own query for the same resource record, with the 'U' bit set. If a response is received, or if a query with the 'U' bit set is received, then a conflict has been detected. An LLMNR responder MUST NOT ignore conflicts once detected. An LLMNR responder MUST respond to a conflict as described in either [1] or [2] below: [1] Upon detecting a conflict, an LLMNR responder MAY elect to immediately stop using the conflicting UNIQUE resource record in response to LLMNR queries. The responder MAY also elect to configure a new name. However, since name reconfiguration may be disruptive, this is not required, and a responder may have been configured to respond to multiple names so that alternative names may already be available. [2] If a responder currently has reasons to prefer using the name, and it has not seen any other conflicting LLMNR queries within the last DEFEND_INTERVAL seconds, then it MAY elect to defend its name, by recording the time that the conflicting LLMNR query was received, and then sending a query for the UNIQUE resource record, with the 'U' bit set if it had not already done so (e.g. if had not already sent such a UNIQUEness query as part of the UNIQUEness verification process). Having done this, an LLMNR responder can then continue to use the name normally without any further special action. However, if this is not the first conflicting LLMNR query the responder has seen, and the time recorded for the previous conflicting LLMNR query is recent, within DEFEND_INTERVAL, then the LLMNR responder MUST immediately cease using the conflicting resource records. This is necessary to ensure that two hosts do not get stuck in an endless loop with both hosts trying to defend the same name." -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 21 05:27: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 FAA07925 for ; Mon, 21 Feb 2005 05:27:08 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3AfI-000M7u-HR for namedroppers-data@psg.com; Mon, 21 Feb 2005 10:19:44 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3AfD-000M5q-B3 for namedroppers@ops.ietf.org; Mon, 21 Feb 2005 10:19:39 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 849202DFB8; Mon, 21 Feb 2005 11:19:36 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 7DF482DFB7 for ; Mon, 21 Feb 2005 11:19:36 +0100 (CET) Date: Mon, 21 Feb 2005 11:19:36 +0100 (CET) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: namedroppers@ops.ietf.org Subject: draft-ietf-dnsext-nsec3-01 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: 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 I've just submitted draft-ietf-dnsext-nsec3-01 and am hereby solliciting comments. Abstract The DNS Security (DNSSEC) NSEC resource record (RR) is intended to be used to provide authenticated denial of existence of DNS ownernames and types; however, it permits any user to traverse a zone and obtain a listing of all ownernames. A complete zone file can be used either directly as a source of probable e-mail addresses for spam, or indirectly as a key for multiple WHOIS queries to reveal registrant data which many registries (particularly in Europe) may be under strict legal obligations to protect. Many registries therefore prohibit copying of their zone file; however the use of NSEC RRs makes renders policies unenforceable. This document proposes a scheme which obscures original ownernames while permitting authenticated denial of existence of non-existent names. Non-authoritative delegation point NS RR types may be excluded. Full version can be found at: http://www.logmess.com/~roy/ 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 Mon Feb 21 15:34: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 PAA12450 for ; Mon, 21 Feb 2005 15:34:16 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3KBl-000DJq-NQ for namedroppers-data@psg.com; Mon, 21 Feb 2005 20:29:53 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3KBk-000DJZ-BB for namedroppers@ops.ietf.org; Mon, 21 Feb 2005 20:29:52 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11520; Mon, 21 Feb 2005 15:29:50 -0500 (EST) Message-Id: <200502212029.PAA11520@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-mdns-38.txt Date: Mon, 21 Feb 2005 15:29:50 -0500 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 : Linklocal Multicast Name Resolution (LLMNR) Author(s) : L. Esibov, et al. Filename : draft-ietf-dnsext-mdns-38.txt Pages : 26 Date : 2005-2-21 Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a Domain Name System (DNS) server. The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache. Since LLMNR only operates on the local link, it cannot be considered a substitute for DNS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-38.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-mdns-38.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-mdns-38.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-2-21151339.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-38.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-38.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-21151339.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 21 16:22: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 PAA12451 for ; Mon, 21 Feb 2005 15:34:16 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3KBO-000DGd-PD for namedroppers-data@psg.com; Mon, 21 Feb 2005 20:29:30 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3KBN-000DGE-Mi for namedroppers@ops.ietf.org; Mon, 21 Feb 2005 20:29:29 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11439; Mon, 21 Feb 2005 15:29:27 -0500 (EST) Message-Id: <200502212029.PAA11439@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-01.txt Date: Mon, 21 Feb 2005 15:29:27 -0500 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-01.txt Pages : 8 Date : 2005-2-21 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 for additional HMAC SHA TSIG algorithms and standardizes how to specify the truncation of HMAC values. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tsig-sha-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-tsig-sha-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-tsig-sha-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-21151333.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-tsig-sha-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-tsig-sha-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-21151333.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 21 20:13:42 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08217 for ; Mon, 21 Feb 2005 20:13:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3OWW-0001pE-RF for namedroppers-data@psg.com; Tue, 22 Feb 2005 01:07:36 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3OWV-0001oy-G4 for namedroppers@ops.ietf.org; Tue, 22 Feb 2005 01:07:35 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j1M141EW016501 for ; Mon, 21 Feb 2005 20:04:01 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA9tayoG; Mon, 21 Feb 05 20:03:59 -0500 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j1M15kRa026923 for ; Mon, 21 Feb 2005 20:05:46 -0500 (EST) Date: Mon, 21 Feb 2005 20:05:43 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org Subject: new epsilon draft Message-ID: 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 A new version of the on-line signing (epsilon) draft has been submitted. Major changes include examples covering the wildcard name and explicit verbiage relaxing constraints on the 'next name' field in NSEC RRs. Also available from: http://dnssec-tools.sourceforge.net/docs/draft-weiler-dnsext-dnssec-online-signing-01.txt -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Feb 22 15:42: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 PAA17475 for ; Tue, 22 Feb 2005 15:42:34 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3gmt-000OcI-H3 for namedroppers-data@psg.com; Tue, 22 Feb 2005 20:37:43 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3gms-000Oby-AD for namedroppers@ops.ietf.org; Tue, 22 Feb 2005 20:37:42 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16936; Tue, 22 Feb 2005 15:37:37 -0500 (EST) Message-Id: <200502222037.PAA16936@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-nsec3-01.txt Date: Tue, 22 Feb 2005 15:37:37 -0500 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 : DNSSEC Hash Authenticated Denial of Existence Author(s) : B. Laurie, et al. Filename : draft-ietf-dnsext-nsec3-01.txt Pages : 18 Date : 2005-2-22 The DNS Security (DNSSEC) NSEC resource record (RR) is intended to be used to provide authenticated denial of existence of DNS ownernames and types; however, it permits any user to traverse a zone and obtain a listing of all ownernames. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-nsec3-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-nsec3-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-nsec3-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-22155638.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-nsec3-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-nsec3-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-22155638.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 23 10:46: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 KAA00515 for ; Wed, 23 Feb 2005 10:46:07 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3yYe-0008Kt-0P for namedroppers-data@psg.com; Wed, 23 Feb 2005 15:36:12 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3yYd-0008Kg-1O for namedroppers@ops.ietf.org; Wed, 23 Feb 2005 15:36:11 +0000 Received: from Puki.ogud.com (mail.md.ogud.com [10.20.30.6]) by ogud.com (8.12.11/8.12.11) with ESMTP id j1NFa6Th042449 for ; Wed, 23 Feb 2005 10:36:06 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.2.0.14.2.20050223103137.04c94b20@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 23 Feb 2005 10:36:06 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: DNSEXT WG Last Call: TSIG/SHA document Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.51 on 10.20.30.6 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 This WG last call ends March 12'th 2005. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tsig-sha-01.txt The TSIG protocol provides transaction level authentication for DNS. TSIG is extensible through the definition of new algorithms. This document specifies an algorithm(s) from the SHA algorithm family. This document specifies 4 new TSIG/HMAC algorithms, if there are any issues with defining any of the algorithms, please state so and why. This draft is on standards track, if you disagree with that please state why in your response. The there are no reports of implementations, if you are aware of any please let us know. In order to advance this document, the chairs must receive some messages of support for this document. Silence will result in dropping the document. Olafur and Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 23 10: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 KAA01355 for ; Wed, 23 Feb 2005 10:52:09 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3ylm-000A5N-US for namedroppers-data@psg.com; Wed, 23 Feb 2005 15:49:46 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3yll-000A51-UL for namedroppers@ops.ietf.org; Wed, 23 Feb 2005 15:49:46 +0000 Received: from Puki.ogud.com (ns.md.ogud.com [10.20.30.6]) by ogud.com (8.12.11/8.12.11) with ESMTP id j1NFnfXp042502 for ; Wed, 23 Feb 2005 10:49:41 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.2.0.14.2.20050223104714.04e1bde0@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 23 Feb 2005 10:49:42 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: Re: IETF-62 Agenda items In-Reply-To: <6.2.0.14.2.20050110102805.04781d08@localhost> References: <6.2.0.14.2.20050110102805.04781d08@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.51 on 10.20.30.6 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: quoted-printable The meeting is on Wed. at 9:00 (this will not change) If you have not sent in agenda items please send them to both chairs ASAP so we can post agenda. thanks =D3lafur (and Olaf) At 12:15 12/01/2005, =D3lafur Gudmundsson/DNSEXT co-chair wrote: >IETF-62 March 6-11 2005. > >The meeting is in less than 2 months, the chairs have requested one >long slot for this meeting. > >Feels free to send in agenda items soon in order to help us chairs to >gauge if we need to add second slot. > >Also this is a friendly reminder to document editors to take a look at >their documents and update them OR declare the documents are ready for >last call. > >If there are many agenda requests there is still time to ask >for second slot so get those requests in. > >Important deadlines: >February 7, Monday - Working Group Chair approval for initial document=20 >(Version -00) submissions due by 09:00 ET (14:00 GMT) > >February 14, Monday - Internet Draft Cut-off for initial document (-00)=20 >submission by 09:00 ET (14:00 GMT) > >February 21, Monday - Internet Draft final submission cut-off by 09:00 ET= =20 >(14:00 GMT) > >So anyone intents to ask for a document to become a WG document the >co-chairs MUST see a draft of that document before Feb 7'th. > > =D3lafur (and Olaf) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 23 11:03: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 LAA02594 for ; Wed, 23 Feb 2005 11:03:45 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3yw0-000BtY-K0 for namedroppers-data@psg.com; Wed, 23 Feb 2005 16:00:20 +0000 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3yvz-000BtA-HY for namedroppers@ops.ietf.org; Wed, 23 Feb 2005 16:00:19 +0000 Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j1NFxUaT014286 for ; Wed, 23 Feb 2005 10:59:32 -0500 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id j1NFwmEX029458 for ; Wed, 23 Feb 2005 10:58:48 -0500 (EST) From: "Scott Rose" To: Subject: RE: DNSEXT WG Last Call: TSIG/SHA document Date: Wed, 23 Feb 2005 10:58:48 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <6.2.0.14.2.20050223103137.04c94b20@localhost> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Importance: Normal X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov 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 I support this document. I do not know of any implementations yet. Hopefully I can get the ball rolling on at least one effort. Scott > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Olafur Gu?mundsson > /DNSEXT co-chair > Sent: Wednesday, February 23, 2005 10:36 AM > To: namedroppers@ops.ietf.org > Subject: DNSEXT WG Last Call: TSIG/SHA document > > > This WG last call ends March 12'th 2005. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tsig-sha-01.txt > > The TSIG protocol provides transaction level authentication for DNS. > TSIG is extensible through the definition of new algorithms. This > document specifies an algorithm(s) from the SHA algorithm family. > This document specifies 4 new TSIG/HMAC algorithms, if there are any > issues with defining any of the algorithms, please state so and why. > > This draft is on standards track, if you disagree with that > please state why > in your response. > > The there are no reports of implementations, if you are aware of > any please > let us know. > > In order to advance this document, the chairs must receive some > messages of support for this document. > Silence will result in dropping the document. > > Olafur and Olaf > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-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 Feb 23 11:29: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 LAA05656 for ; Wed, 23 Feb 2005 11:29:14 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3zIX-000FeL-0G for namedroppers-data@psg.com; Wed, 23 Feb 2005 16:23:37 +0000 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3zIT-000Fe7-IT for namedroppers@ops.ietf.org; Wed, 23 Feb 2005 16:23:33 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 53AA526C076; Wed, 23 Feb 2005 17:23:32 +0100 (CET) Received: from maya20.nic.fr (maya20.nic.fr [192.134.4.152]) by mx2.nic.fr (Postfix) with ESMTP id 122F726C09F; Wed, 23 Feb 2005 17:23:31 +0100 (CET) Received: from batilda.nic.fr (postfix@batilda.nic.fr [192.134.4.69]) by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id j1NGNP4u1504705; Wed, 23 Feb 2005 17:23:25 +0100 (CET) Received: by batilda.nic.fr (Postfix, from userid 1000) id 5CAFD16A9E4; Wed, 23 Feb 2005 17:23:25 +0100 (CET) Date: Wed, 23 Feb 2005 17:23:25 +0100 From: Stephane Bortzmeyer To: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= /DNSEXT co-chair Cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WG Last Call: TSIG/SHA document Message-ID: <20050223162325.GA4687@nic.fr> References: <6.2.0.14.2.20050223103137.04c94b20@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6.2.0.14.2.20050223103137.04c94b20@localhost> X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-1-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new at mx2.nic.fr 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: 8bit On Wed, Feb 23, 2005 at 10:36:06AM -0500, Ólafur Guðmundsson /DNSEXT co-chair wrote a message of 28 lines which said: > The TSIG protocol provides transaction level authentication for DNS. > TSIG is extensible through the definition of new algorithms. This > document specifies an algorithm(s) from the SHA algorithm family. The Security Considerations do not mention the very recent attacks on SHA-1, which, IMHO (I am not a cryptographer) should stop this document from going on the Standards Track (pending further studies). http://www.schneier.com/blog/archives/2005/02/sha1_broken.html -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 23 11:44: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 LAA08622 for ; Wed, 23 Feb 2005 11:44:03 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3zZk-000HyO-PF for namedroppers-data@psg.com; Wed, 23 Feb 2005 16:41:24 +0000 Received: from [200.160.2.4] (helo=clone.registro.br) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3zZj-000Hy9-R8 for namedroppers@ops.ietf.org; Wed, 23 Feb 2005 16:41:24 +0000 Received: by clone.registro.br (Postfix, from userid 1000) id CA95F2A441; Wed, 23 Feb 2005 13:41:22 -0300 (BRT) Date: Wed, 23 Feb 2005 13:41:22 -0300 From: Frederico A C Neves To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WG Last Call: TSIG/SHA document Message-ID: <20050223164122.GQ12539@registro.br> References: <6.2.0.14.2.20050223103137.04c94b20@localhost> <20050223162325.GA4687@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050223162325.GA4687@nic.fr> 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 Wed, Feb 23, 2005 at 05:23:25PM +0100, Stephane Bortzmeyer wrote: ... > > The Security Considerations do not mention the very recent attacks on > SHA-1, which, IMHO (I am not a cryptographer) should stop this > document from going on the Standards Track (pending further studies). > HMAC based on SHA doesn't suffer this attack. There is plenty of cryptographers in this list to confirm this. Let the document go ! -- to unsubscribe send a message to namedroppers-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 Feb 23 12:04: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 MAA12018 for ; Wed, 23 Feb 2005 12:04:16 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3ztk-000Ksw-DW for namedroppers-data@psg.com; Wed, 23 Feb 2005 17:02:04 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3ztg-000Krw-7I for namedroppers@ops.ietf.org; Wed, 23 Feb 2005 17:02:00 +0000 Received: from Puki.ogud.com (mail.md.ogud.com [10.20.30.6]) by ogud.com (8.12.11/8.12.11) with ESMTP id j1NH1sOQ042923; Wed, 23 Feb 2005 12:01:54 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.2.0.14.2.20050223113008.02ee7150@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 23 Feb 2005 12:01:54 -0500 To: Stephane Bortzmeyer From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: DNSEXT WG Last Call: TSIG/SHA document Cc: namedroppers@ops.ietf.org In-Reply-To: <20050223162325.GA4687@nic.fr> References: <6.2.0.14.2.20050223103137.04c94b20@localhost> <20050223162325.GA4687@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.51 on 10.20.30.6 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: quoted-printable At 11:23 23/02/2005, Stephane Bortzmeyer wrote: >On Wed, Feb 23, 2005 at 10:36:06AM -0500, > =D3lafur Gu=F0mundsson /DNSEXT co-chair wrote > a message of 28 lines which said: > > > The TSIG protocol provides transaction level authentication for DNS. > > TSIG is extensible through the definition of new algorithms. This > > document specifies an algorithm(s) from the SHA algorithm family. > >The Security Considerations do not mention the very recent attacks on >SHA-1, which, IMHO (I am not a cryptographer) should stop this >document from going on the Standards Track (pending further studies). > >http://www.schneier.com/blog/archives/2005/02/sha1_broken.html Excellent point, the document should address this issue before being advanced. I checked with some people that know cryptography before issuing this last call, they do not see an issue with THIS USE of SHA-1. According to cryptographers: The HMAC addition protects the underlying algorithm from the vulnerabilities found in SHA-1. http://jis.mit.edu/pipermail/saag/2005q1/001184.html IMHO more given the short time TSIG signatures are valid, and the great control each TSIG generator has over the input this is not a great risk. Having said that the WG can decide to list SHA-1 as Optional, not mandatory as in the current draft. Note also HMAC/SHA-256 is listed as mandatory to implement and that is the algorithm people should be using if they want to significantly improve security over HMAC/MD5 =D3lafur=20 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 23 13:03: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 NAA20857 for ; Wed, 23 Feb 2005 13:03:40 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D40oW-0003RK-Ci for namedroppers-data@psg.com; Wed, 23 Feb 2005 18:00:44 +0000 Received: from [204.152.189.154] (helo=gusto.araneus.fi) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D40oT-0003Qa-Hq for namedroppers@ops.ietf.org; Wed, 23 Feb 2005 18:00:41 +0000 Received: from guava.araneus.fi ([195.238.197.162]) by gusto.araneus.fi (8.12.10/8.12.10) with ESMTP id j1NI0X4X015092; Wed, 23 Feb 2005 10:00:33 -0800 (PST) Received: from guava.araneus.fi (localhost [127.0.0.1]) by guava.araneus.fi (8.12.10/8.11.6) with ESMTP id j1NI0UP9008180; Wed, 23 Feb 2005 20:00:30 +0200 (EET) Received: (from gson@localhost) by guava.araneus.fi (8.12.10/8.12.6/Submit) id j1NI0PaX026242; Wed, 23 Feb 2005 20:00:25 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <16924.50357.206629.553474@guava.araneus.fi> Date: Wed, 23 Feb 2005 20:00:21 +0200 To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WG Last Call: TSIG/SHA document In-Reply-To: <6.2.0.14.2.20050223103137.04c94b20@localhost> References: <6.2.0.14.2.20050223103137.04c94b20@localhost> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@araneus.fi (Andreas Gustafsson) 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: quoted-printable =D3lafur Gu=F0mundsson /DNSEXT co-chair writes: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tsig-sha-01.txt= I think the draft needs to emphasize the distinction between implementing an algorithm and having a policy of accepting messages signed by that algorithm, especially when most existing implementations do not yet need to make that distinction because they only deal with a single algorithm. It would be unfortunate if an implementor interpreted "must implement SHA-1" as "must accept messages signed with SHA-1" (or even as "should accept them by default"), since accepting messages signed with a new algorithm without rejecting messages signed with the old one can only hurt security. What would be particularly bad is if someone made their implementation accept messages with the MAC truncated to a single octet just because the draft says "MAY implement any or all other truncations". Such an implementation would of course be completely insecure, breakable in 128 tries on average. Although the Security Considerations section does note that "excessive truncation clearly weakens authentication", I don't think it makes it sufficiently clear that the risk doesn't lie in excessive truncation by the sender but in the acceptance of excessively truncated hashes by the receiver. --=20 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 Wed Feb 23 15:39:05 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12638 for ; Wed, 23 Feb 2005 15:39:04 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D43Cf-000OPQ-Ml for namedroppers-data@psg.com; Wed, 23 Feb 2005 20:33:49 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D43Ce-000OPE-PQ for namedroppers@ops.ietf.org; Wed, 23 Feb 2005 20:33: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 PAA11827; Wed, 23 Feb 2005 15:33:45 -0500 (EST) Message-Id: <200502232033.PAA11827@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-trans-02.txt Date: Wed, 23 Feb 2005 15:33:45 -0500 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 : Evaluating DNSSEC Transition Mechanisms Author(s) : R. Arends, et al. Filename : draft-ietf-dnsext-dnssec-trans-02.txt Pages : 15 Date : 2005-2-23 This document collects and summarizes different proposals for alternative and additional strategies for authenticated denial in DNS responses, evaluates these proposals and gives a recommendation for a way forward. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-trans-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-trans-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-trans-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-23155328.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-trans-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-trans-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-23155328.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Feb 23 20:46: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 UAA20081 for ; Wed, 23 Feb 2005 20:46:22 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4803-000BNH-Sl for namedroppers-data@psg.com; Thu, 24 Feb 2005 01:41:07 +0000 Received: from [202.13.76.111] (helo=delta.noi.kre.to) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4801-000BMv-NR for namedroppers@ops.ietf.org; Thu, 24 Feb 2005 01:41:06 +0000 Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.11/8.11.6) with ESMTP id j1O1VNGx002838; Thu, 24 Feb 2005 08:31:23 +0700 (ICT) From: Robert Elz To: gson@araneus.fi (Andreas Gustafsson) cc: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair , namedroppers@ops.ietf.org Subject: Re: DNSEXT WG Last Call: TSIG/SHA document In-Reply-To: <16924.50357.206629.553474@guava.araneus.fi> References: <16924.50357.206629.553474@guava.araneus.fi> <6.2.0.14.2.20050223103137.04c94b20@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Feb 2005 08:31:23 +0700 Message-ID: <5098.1109208683@munnari.OZ.AU> 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: quoted-printable Date: Wed, 23 Feb 2005 20:00:21 +0200 From: gson@araneus.fi (Andreas Gustafsson) Message-ID: <16924.50357.206629.553474@guava.araneus.fi> | I think the draft needs to emphasize the distinction between | implementing an algorithm and having a policy of accepting messages | signed by that algorithm, And *I* think there are way too many attempts in the IETF to mandate quality of implementation issues. All we're supposed to be concerned with is interoperability. In bilateral protocols like TSIG that doesn't require very much. If there's a sub-standard TSIG implementation around, that doesn't meet your requirements, then just find a better one. If there's something in the spec that harms either interoperability, or of correct operation of the protocol, by all means, object to it. But if the only complaint is that it is possible for people to use it in ways= that don't meet your needs, then just leave it alone. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 24 00:44:42 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17345 for ; Thu, 24 Feb 2005 00:44:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4Bj1-000KBu-M7 for namedroppers-data@psg.com; Thu, 24 Feb 2005 05:39:47 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4Biy-000KBc-7h for namedroppers@ops.ietf.org; Thu, 24 Feb 2005 05:39:44 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j1O5aAr3022485 for ; Thu, 24 Feb 2005 00:36:10 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA_saG6R; Thu, 24 Feb 05 00:36:07 -0500 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j1O5bdco002137; Thu, 24 Feb 2005 00:37:39 -0500 (EST) Date: Thu, 24 Feb 2005 00:37:39 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org cc: Roy Arends , ben@algroup.co.uk Subject: comments on nsec3-01 In-Reply-To: Message-ID: References: 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 > I've just submitted draft-ietf-dnsext-nsec3-01 and am hereby > solliciting comments. Executive summary: While I don't like the inclusion of opt-in, I like most of the technical substance in this doc. That said, the text has some rough edges, and I'm still worried about how to change salts and hash functions. Technical summary (someone tell me if I get any of this wrong, please): At the San Diego IETF last August, I did a presentation comparing NSEC2 (from Ben Laurie) to DNSNR (from Roy Arends). I described four differences between the protocols: hash iterations, the authoritative-only bit (a.k.a. opt-in), a null hash function (plaintext names), and the choice of what gets hashed. The first three I described as options -- they were compatible with both protocols. This proposal uses hash iterations and the authoritative-only bit (opt-in) but does not define a null hash function. This proposal hashes the entire owner name (as NSEC2 had originally proposed) and adds NSEC3 RRs at all empty non-terminals (a new innovation that should help with wildcard proofs). That presentation also identified several problems common to both documents. This new proposal seems to address the wildcard handling issues and it makes progress on handling hash collisions. I still worry about changing hashes/salts. Details (with asterisks on especially interesting items): Sections 2 and 2.1.1 were very hard to read, 2.1.1 especially. Please rework them. Section 2: rather than cite (just?) 2308, (also?) cite -records. ** 2.1.2 Discarding NSEC3 RRs w/ unknown hashes sounds very, very bad. ** If you simply discard them, then presumably you can't do validation ** of negative answers in that zone (can anyone say "attack vector"?). ** One (perhaps bad) option is to tie the NSEC3 hash algorithm to the ** zone's DS message digest algorithm, since we already know how to ** handle unsupported algorithms in the DS. But since a zone could ** have multiple DS's (with different hash algorithms), but not ** multiple NSEC3 chains (presumably), this doesn't sound so good. ** Can we just declare "this is the NSEC3 hash function" and not ** parameterize it? 2.2 Citation for RFC3597 ([5]) doesn't exist. Section 3. Adding NSEC RRs at names with no other RRs is a protocol change and should probably be more vigorously flagged as such (as in: "changes section xxx of -records by..."). ** Section 5 is remarkably clear. I wish there were similar sections ** telling resolvers how to deal with NSEC3's and telling servers when ** to include them -- both with very explicit instructions. Section 6.1.1: I'm uneasy with this paragraph: The only possible mitigation is to either not use this method, hence proving existence or absence of unsigned delegations, or signing the delegated zone, changing the unsigned delegation into a signed delegation. It's not the signing of the child that mitigates the attack, it's the signing of the delegation, whether or not there's a DS. Section 6.2: This doesn't sounds quite right: "... an RR must be shown for the closest encloser, and non-existence must be shown for all enclosers that could be closer." Ed? Section 6.4: the 2^80 number depends on SHA1. Say that. Section 6.4.1: for the second paragraph (really dealing with collisions), suggest a specific server behavior when it needs to prove the non-existence of something and can't. Should it make up an RR set? Give a REFUSED? Section 6.4.3: hash truncation. Are you describing a technique you expect to be used? Are you expecting truncation to be recognized automatically? Or do you need a new hash identifier for each truncation? If recognized automatically, more text is needed. IANA: What's the criteria for assignment? "Reserved" won't cut it -- see 2434bis. Standards Action might be appropriate. What's experimental (also in section 2.1.2)? (Is it "private use"?) Describe it or drop it. The presentation format in section 2.2 allows for the "name of the hash" to appear. If that's to be retained, the names/mnemonics need to be in the registry. All that said, if we can't find a wat to change hash functions, maybe we should just drop the parameterization entirely, as discussed above re: section 2.1.2. Security considerations: "...in any case, [a dictonary] attack could also be used directly against the name server..." is misleading. NSEC3 enables an off-line dictonary attack, which is faster, less dectable, and less susceptible to counter-measures than an on-line attack. ** Security considerations: suggests changing salt, but how? Section ** 2.1.5 requires identical salt values throughout the zone. Can you ** change salts without going insecure? How? Security considerations: "If [hash collisions occur], it will be impossible to prove the non-existence of the colliding domain" doesn't sound quite right. Security considerations: needs to discuss the risks of opt-in. 6.1.1 does much of it, but there should at least be a pointer here, if not a repeat of the discussion. May want to look at the text from David's opt-in draft. Remove sections 10 (duplicates 1.2) & 11 -- to unsubscribe send a message to namedroppers-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 Feb 24 01:44: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 BAA08718 for ; Thu, 24 Feb 2005 01:44:52 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4Cer-00051n-W8 for namedroppers-data@psg.com; Thu, 24 Feb 2005 06:39:33 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4Cen-000509-Os for namedroppers@ops.ietf.org; Thu, 24 Feb 2005 06:39:30 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id DD43B33CA1; Thu, 24 Feb 2005 06:39:27 +0000 (GMT) Message-ID: <421D7625.8090201@algroup.co.uk> Date: Thu, 24 Feb 2005 06:37:25 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Samuel Weiler Cc: namedroppers@ops.ietf.org, Roy Arends Subject: Re: comments on nsec3-01 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=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Responding to non-editorial points for now. I'll edit the document tomorrow. Samuel Weiler wrote: >>I've just submitted draft-ietf-dnsext-nsec3-01 and am hereby >>solliciting comments. > > > Executive summary: While I don't like the inclusion of opt-in, I like > most of the technical substance in this doc. That said, the text has > some rough edges, and I'm still worried about how to change salts and > hash functions. As discussed, opt-in is optional, and can be removed at the WG's discretion. I don't like it much either, but since it impacts the spec it seemed wise to include it, at this point. > Technical summary (someone tell me if I get any of this wrong, > please): At the San Diego IETF last August, I did a presentation > comparing NSEC2 (from Ben Laurie) to DNSNR (from Roy Arends). I > described four differences between the protocols: hash iterations, the > authoritative-only bit (a.k.a. opt-in), a null hash function > (plaintext names), and the choice of what gets hashed. The first > three I described as options -- they were compatible with both > protocols. This proposal uses hash iterations and the > authoritative-only bit (opt-in) but does not define a null hash > function. This proposal hashes the entire owner name (as NSEC2 had > originally proposed) and adds NSEC3 RRs at all empty non-terminals (a > new innovation that should help with wildcard proofs). > > That presentation also identified several problems common to both > documents. This new proposal seems to address the wildcard handling > issues and it makes progress on handling hash collisions. I still > worry about changing hashes/salts. I still don't understand what your concern is. Any individual NSEC3 record works standalone with its own hash/salt/iterations. The owner of a zone must be sure to have a complete set for any particular combination of hash/salt/iterations, or there could be queries it could not respond to, but it doesn't actually matter if a client receives part of the response from one set and part from another, since each individual NSEC3 record denies a particular RR, and that RR is denied whichever set it comes from (not that I can see how this can happen anyway, but guessing at your concern). > ** 2.1.2 Discarding NSEC3 RRs w/ unknown hashes sounds very, very bad. > ** If you simply discard them, then presumably you can't do validation > ** of negative answers in that zone (can anyone say "attack vector"?). How can this be used as an attack? NSEC3s must be signed, so an attacker is not at liberty to choose the hash. > ** One (perhaps bad) option is to tie the NSEC3 hash algorithm to the > ** zone's DS message digest algorithm, since we already know how to > ** handle unsupported algorithms in the DS. But since a zone could > ** have multiple DS's (with different hash algorithms), but not > ** multiple NSEC3 chains (presumably), this doesn't sound so good. > ** Can we just declare "this is the NSEC3 hash function" and not > ** parameterize it? Then we'd have to roll the whole protocol to change the hash function, which sounds even less good. > Security considerations: "...in any case, [a dictonary] attack could > also be used directly against the name server..." is misleading. > NSEC3 enables an off-line dictonary attack, which is faster, I would dispute that it is necessarily faster - that was the point of having iterations. I would agree with "might be faster". > less dectable, and less susceptible to counter-measures than an on-line > attack. One of our entry-points to the whole NSEC++ discussion was that there are no plausible counter-measures. > ** Security considerations: suggests changing salt, but how? Section > ** 2.1.5 requires identical salt values throughout the zone. Can you > ** change salts without going insecure? How? You would have to change the salt for the whole zone, and see above. But hash collisions are a distraction. In practice they will not occur. > Security considerations: "If [hash collisions occur], it will be > impossible to prove the non-existence of the colliding domain" doesn't > sound quite right. It sounds right to me. What do you think is wrong? 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 Thu Feb 24 08:20:05 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15877 for ; Thu, 24 Feb 2005 08:20:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4IqB-00086x-Ra for namedroppers-data@psg.com; Thu, 24 Feb 2005 13:15:39 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4Iq7-00086C-Qf for namedroppers@ops.ietf.org; Thu, 24 Feb 2005 13:15:36 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 9CA2133CAC; Thu, 24 Feb 2005 13:15:34 +0000 (GMT) Message-ID: <421DD2FC.7030405@algroup.co.uk> Date: Thu, 24 Feb 2005 13:13:32 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Samuel Weiler Cc: namedroppers@ops.ietf.org, Roy Arends Subject: Re: comments on nsec3-01 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=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Samuel Weiler wrote: > Sections 2 and 2.1.1 were very hard to read, 2.1.1 especially. Please > rework them. I think this'll have to wait for discussion about exactly what is unclear. > Section 2: rather than cite (just?) 2308, (also?) cite -records. Where, exactly? Would 1.1 be more appropriate? > 2.2 Citation for RFC3597 ([5]) doesn't exist. Fixed. > Section 3. Adding NSEC RRs at names with no other RRs is a protocol > change and should probably be more vigorously flagged as such (as in: > "changes section xxx of -records by..."). > > ** Section 5 is remarkably clear. I wish there were similar sections > ** telling resolvers how to deal with NSEC3's and telling servers when > ** to include them -- both with very explicit instructions. > > Section 6.1.1: I'm uneasy with this paragraph: > The only possible mitigation is to either not use this method, > hence proving existence or absence of unsigned delegations, or > signing the delegated zone, changing the unsigned delegation into a > signed delegation. > It's not the signing of the child that mitigates the attack, it's the > signing of the delegation, whether or not there's a DS. Agreed, fixed. Of course, this relates to opt-in, hence the confusion. I note that the other case is also wrong. Proving absence of unsigned delegations does not prevent the fabrication of such delegations. I am also fixing that. This strikes me as an argument against opt-in. > Section 6.2: This doesn't sounds quite right: "... an RR must be shown > for the closest encloser, and non-existence must be shown for all > enclosers that could be closer." Ed? What doesn't sound right about this? It seems correct to me. > Section 6.4: the 2^80 number depends on SHA1. Say that. Fixed (and made more general). > Section 6.4.1: for the second paragraph (really dealing with > collisions), suggest a specific server behavior when it needs to prove > the non-existence of something and can't. Should it make up an RR > set? Give a REFUSED? You know, this obsession with collisions is really getting quite silly. If you want to follow it to its logical conclusion, then we are going to have to rework all the signature stuff in DNSSEC, too, since they are equally vulnerable to hash collisions (and with substantially worse consequences, too). Do you really want to go down that path? Incidentally, 6.4.2 deals with the case you described, not 6.4.1. But I'm personally in favour of deleting all mention of collisions beyond specifying that hash functions should resist them. > Section 6.4.3: hash truncation. Are you describing a technique you > expect to be used? Are you expecting truncation to be recognized > automatically? Or do you need a new hash identifier for each > truncation? If recognized automatically, more text is needed. No, I've updated the text to reflect this. > IANA: What's the criteria for assignment? "Reserved" won't cut it -- > see 2434bis. Standards Action might be appropriate. What's > experimental (also in section 2.1.2)? (Is it "private use"?) > Describe it or drop it. The presentation format in section 2.2 allows > for the "name of the hash" to appear. If that's to be retained, the > names/mnemonics need to be in the registry. All that said, if we > can't find a wat to change hash functions, maybe we should just drop > the parameterization entirely, as discussed above re: section 2.1.2. Since I've added the null function back, this is not an option. I leave it to the WG to decide what action is needed to allocate a new hash function. > Security considerations: "...in any case, [a dictonary] attack could > also be used directly against the name server..." is misleading. > NSEC3 enables an off-line dictonary attack, which is faster, less > dectable, and less susceptible to counter-measures than an on-line > attack. Text modified somewhat. > Security considerations: "If [hash collisions occur], it will be > impossible to prove the non-existence of the colliding domain" doesn't > sound quite right. This seems correct to me - what problem do you see? BTW, Alex Bligh did point out a way to completely resolve this - in the event of a collision, one presents NSEC3 records with the identity hash function instead. I would suggest we do NOT specify this, because it's a good deal of work for implementers to handle a case that will almost certainly never occur and is computationally infeasible to ever test(!). Plus it substantially increases the size and signing cost of the zone. > Security considerations: needs to discuss the risks of opt-in. 6.1.1 > does much of it, but there should at least be a pointer here, if not a > repeat of the discussion. May want to look at the text from David's > opt-in draft. Perhaps we should simply refer to the opt-in draft, since all we're doing is adding support for it. > Remove sections 10 (duplicates 1.2) & 11 Done. 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 Thu Feb 24 09:07: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 JAA21252 for ; Thu, 24 Feb 2005 09:07:31 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4Jba-000Ebg-N4 for namedroppers-data@psg.com; Thu, 24 Feb 2005 14:04:38 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4JbY-000Eb5-AR for namedroppers@ops.ietf.org; Thu, 24 Feb 2005 14:04:36 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 80080C2DA4; Thu, 24 Feb 2005 14:04:32 +0000 (GMT) Date: Thu, 24 Feb 2005 14:04:32 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Ben Laurie , Samuel Weiler Cc: namedroppers@ops.ietf.org, Roy Arends , Alex Bligh Subject: Re: comments on nsec3-01 Message-ID: <39818D7BAE778D256222CD67@[192.168.100.25]> In-Reply-To: <421DD2FC.7030405@algroup.co.uk> References: <421DD2FC.7030405@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 24 February 2005 13:13 +0000 Ben Laurie wrote: > BTW, Alex Bligh did point out a way to completely resolve this - in the > event of a collision, one presents NSEC3 records with the identity hash > function instead. I would suggest we do NOT specify this, because it's a > good deal of work for implementers to handle a case that will almost > certainly never occur and is computationally infeasible to ever test(!). > Plus it substantially increases the size and signing cost of the zone. Firstly, I agree with your comment about hash collisions taking up an inordinate amount of unnecessary conversations. That being said, in partial defense of my own suggestion above, I'd make the following points: 1. It certainly should not be a MUST or a SHOULD requirement, but I would have thought a MAY specification is reasonable (indicating it is a possible option), as there may be some implementers who are worried about hash collisions more than we are. It would be reasonable to say MUST either (a) use alternate non-colliding hash such as the identity hash which is guaranteed never to collide, OR (b) [specify default behaviour - REFUSED, SERVERR whatever]. 2. It is not computationally infeasible to test because one can generate (for this purpose) a deliberately weak hash function (for instance take the octets as groups of 32 bit words and XOR them together). If we are that concerned about it, given we probably want to do interoperability testing for multiple hash functions, it might be that specifying this (as an optional hash) is a good idea anyway. 3. If it is optional, the argument about it being a lot of work falls. Ditto the argument about increasing size and signing cost of zone. Only the ultra-cautious/paranoid (you pick which!) bear the cost. 4. Such a scheme would permit the use of very truncated hashes as alternate hash functions, where one is prepared to accept the possibility of the occasional collision (and thus the occasional adjacent name being discovered) AND additional signing complexity in order to minimize on-wire data (if bandwidth rather than CPU is the problem). I figure you can truncate the zone hash to something like 2logN bits (where N is number of items in zone) and keep the expected value of the number of collisions smaller than 2 (but you would HAVE to handle the case where collisions do exist if you are doing this by doing an identity sign as well). That's a noticeable on-wire saving. But no, I'm not that fussed about it. 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 Thu Feb 24 16:42: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 QAA24966 for ; Thu, 24 Feb 2005 16:42:46 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4QgG-000KC9-6C for namedroppers-data@psg.com; Thu, 24 Feb 2005 21:37:56 +0000 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4QgE-000KBu-I6 for namedroppers@ops.ietf.org; Thu, 24 Feb 2005 21:37: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/2004/05/05/sjaenick) with ESMTP id j1OLbqZI023159 for ; Thu, 24 Feb 2005 22:37:53 +0100 (MET) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id j1OLbqU02800 for ; Thu, 24 Feb 2005 22:37:52 +0100 (MET) Message-Id: <200502242137.j1OLbqU02800@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: IETF DNSEXT WG Subject: Re: I-D ACTION:draft-ietf-dnsext-dnssec-trans-02.txt In-reply-to: Your message of "Wed, 23 Feb 2005 15:33:45 EST." <200502232033.PAA11827@ietf.org> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2794.1109281069.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Thu, 24 Feb 2005 22:37:52 +0100 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 > Title : Evaluating DNSSEC Transition Mechanisms > Author(s) : R. Arends, et al. > Filename : draft-ietf-dnsext-dnssec-trans-02.txt Changes include some editorial comments, some references and a new "method". Some comments have been read but not yet incorporated, including those from Sam: you said in November that you hadn't done an in depth review. Nevertheless you suggested another "dead end" to be added (DS hash based; I'd be happy to learn the details, but pls see below) Mark: details for the SIG(0) approach and its drawbacks need to be added Miek: The "new" method is basically what went into the "BERT" draft. This document needs one other round before it hopefully can go to WG LC. My plan is to do this editing round in and shortly after MPLS. Since it is mostly intended to document the collection of ideas on the table when the WG decided to proceed with -bis as is, it's not necessary to find more alternatives, but instead to go back in time a bit and improve the description and assessment of those already in the draft. -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 Thu Feb 24 18:04:17 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03684 for ; Thu, 24 Feb 2005 18:04:16 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4RzK-0005O1-NP for namedroppers-data@psg.com; Thu, 24 Feb 2005 23:01:42 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4RzH-0005NX-Lz for namedroppers@ops.ietf.org; Thu, 24 Feb 2005 23:01:39 +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; Thu, 24 Feb 2005 18:01:38 -0500 id 005742BC.421E5CD2.00000E59 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: unknown (IP address lookup failed.?) SPF=MAILFROM; sender=davidb@verisignlabs.com; remoteip=::ffff:172.25.170.10; remotehost=; helo=[10.131.244.227]; receiver=mail.verisignlabs.com; Message-ID: <421E5CD2.9040004@verisignlabs.com> Date: Thu, 24 Feb 2005 18:01:38 -0500 From: David Blacka Organization: VeriSign, Inc. User-Agent: Mozilla Thunderbird 0.9 (X11/20041127) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Laurie CC: namedroppers@ops.ietf.org, Roy Arends Subject: Re: comments on nsec3-01 References: <421DD2FC.7030405@algroup.co.uk> In-Reply-To: <421DD2FC.7030405@algroup.co.uk> X-Enigmail-Version: 0.89.5.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 Ben Laurie wrote: > I note that the other case is also wrong. Proving absence of unsigned > delegations does not prevent the fabrication of such delegations. I am > also fixing that. This strikes me as an argument against opt-in. Opt-In explicitly doesn't prove the absence of unsigned delegations. That was the point. That you can fabricate unsigned delegations in an opt-in signed zone is very well understood. Because this strikes some as an argument against opt-in is why opt-in is always *optional*. >> Security considerations: needs to discuss the risks of opt-in. 6.1.1 >> does much of it, but there should at least be a pointer here, if not a >> repeat of the discussion. May want to look at the text from David's >> opt-in draft. > > > Perhaps we should simply refer to the opt-in draft, since all we're > doing is adding support for it. You could refer to it, but keep in mind that the opt-in document is heading for the Experimental track, not PS. -- David Blacka Sr. Engineer VeriSign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Feb 24 22:08: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 WAA25671 for ; Thu, 24 Feb 2005 22:08:31 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4VmJ-000DXt-Hk for namedroppers-data@psg.com; Fri, 25 Feb 2005 03:04:31 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4VmI-000DXd-7r for namedroppers@ops.ietf.org; Fri, 25 Feb 2005 03:04:30 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j1P30uN1016652 for ; Thu, 24 Feb 2005 22:00:56 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAHhayHG; Thu, 24 Feb 05 22:00:53 -0500 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j1P32guc008200 for ; Thu, 24 Feb 2005 22:02:42 -0500 (EST) Date: Thu, 24 Feb 2005 22:02:42 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org Subject: I-D ACTION:draft-weiler-dnsext-dnssec-online-signing-01.txt (fwd) Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY=NextPart Content-ID: 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 autolearn=no version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --NextPart Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: I posted about this on Monday but didn't include the announcement from the i-d respository... ---------- Forwarded message ---------- Date: Mon, 21 Feb 2005 15:37:34 -0500 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-weiler-dnsext-dnssec-online-signing-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Minimally Covering NSEC Records and DNSSEC On-line Signing Author(s) : S. Weiler, J. Ihren Filename : draft-weiler-dnsext-dnssec-online-signing-01.txt Pages : 8 Date : 2005-2-21 This document describes how to construct DNSSEC NSEC resource records that cover a smaller range of names than called for by [-records]. By generating and signing these records on demand, authoritative name servers can effectively stop the disclosure of zone contents otherwise made possible by walking the chain of NSEC records in a signed zone. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-weiler-dnsext-dnssec-online-signing-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-weiler-dnsext-dnssec-online-signing-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-weiler-dnsext-dnssec-online-signing-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: MULTIPART/ALTERNATIVE; BOUNDARY=OtherAccess Content-ID: Content-Description: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; ACCESS-TYPE=mail-server; SERVER="mailserv@ietf.org" Content-ID: --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; NAME="draft-weiler-dnsext-dnssec-online-signing-01.txt"; SITE="ftp.ietf.org"; ACCESS-TYPE=anon-ftp; DIRECTORY=internet-drafts Content-ID: --OtherAccess-- --NextPart Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-ID: Content-Description: Content-Disposition: INLINE _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --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 Sat Feb 26 14:31: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 OAA24245 for ; Sat, 26 Feb 2005 14:31:30 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D57Zh-0007iO-DW for namedroppers-data@psg.com; Sat, 26 Feb 2005 19:26:01 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D57Ze-0007i9-UD for namedroppers@ops.ietf.org; Sat, 26 Feb 2005 19:25:59 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j1QJMOXu019810 for ; Sat, 26 Feb 2005 14:22:24 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAjJayRM; Sat, 26 Feb 05 14:22:20 -0500 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j1QJNr5w009842; Sat, 26 Feb 2005 14:23:53 -0500 (EST) Date: Sat, 26 Feb 2005 14:23:53 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: Ben Laurie cc: namedroppers@ops.ietf.org, Roy Arends Subject: Re: comments on nsec3-01 In-Reply-To: <421D7625.8090201@algroup.co.uk> Message-ID: References: <421D7625.8090201@algroup.co.uk> 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 On Thu, 24 Feb 2005, Ben Laurie wrote: > I still don't understand what your concern is. Any individual NSEC3 > record works standalone with its own hash/salt/iterations. The owner of > a zone must be sure to have a complete set for any particular > combination of hash/salt/iterations, or there could be queries it could > not respond to, but it doesn't actually matter if a client receives part > of the response from one set and part from another, since each > individual NSEC3 record denies a particular RR, and that RR is denied > whichever set it comes from (not that I can see how this can happen > anyway, but guessing at your concern). Then the doc needs to say that, including specific instructions to validators to treat each NSEC3 individually (for instance, you might have one NSEC3 proving no exact match using hash1 and one proving no wildcard with hash2). The doc currently requires that the salt be the same throughout the zone, which suggests (perhaps incorrectly) that the above doesn't work. > > ** 2.1.2 Discarding NSEC3 RRs w/ unknown hashes sounds very, very bad. > > ** If you simply discard them, then presumably you can't do validation > > ** of negative answers in that zone (can anyone say "attack vector"?). > > How can this be used as an attack? NSEC3s must be signed, so an attacker > is not at liberty to choose the hash. If a new (relatively unknown) hash is in use, the attacker can replay it with interesting results. Imagine a zone using NSEC3 with a previously-unknown hash algorithm (type 42). A validator that doesn't understand hash type 42 can still process positive answers from that zone and set the ad bit for them. What happens when that same validator (that doesn't understand hash 42) gets a nonexistence proof from the zone? Following the above rules, it discards the NSEC3. What does it do now? Treat validation as having failed? That would make it very dangerous to use new hash algorithms. Treat the zone as insecure (at least for non-existence answers)? That looks like the only safe option, given the 'discard' directive. Now imagine a man-in-the-middle. In response to a query for an existing RR in the zone, the attacker synthesizes a nonexistence proof using ANY of the NSEC3 RR's from the zone. The validator can't tell the difference between this and the second situation above -- the attacker has just spoofed away real names. Wouldn't it be better to know the zone was insecure when you first enter it rather than have this "somewhat secure" state? This reminds me of a discussion from 1.5 years ago: http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01539.html http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01773.html > > ** One (perhaps bad) option is to tie the NSEC3 hash algorithm to the > > ** zone's DS message digest algorithm, since we already know how to > > ** handle unsupported algorithms in the DS. But since a zone could > > ** have multiple DS's (with different hash algorithms), but not > > ** multiple NSEC3 chains (presumably), this doesn't sound so good. > > ** Can we just declare "this is the NSEC3 hash function" and not > > ** parameterize it? > > Then we'd have to roll the whole protocol to change the hash function, > which sounds even less good. If you can't change the algorithm with some grace, I think parameterizing it is misleading and adds unnecessary complexity. > > Security considerations: "...in any case, [a dictonary] attack could > > also be used directly against the name server..." is misleading. > > NSEC3 enables an off-line dictonary attack, which is faster, > > I would dispute that it is necessarily faster - that was the point of > having iterations. I would agree with "might be faster". Fair enough. > > Security considerations: "If [hash collisions occur], it will be > > impossible to prove the non-existence of the colliding domain" doesn't > > sound quite right. > > It sounds right to me. What do you think is wrong? There are at least two ways to read this. Having looked again, I suspect you meant: if the hash of an existing name and that of a non-existing name collide, it will be impossible to prove the non-existence of the non-existing name. Another way to read it is: if the hashes of two EXISTING names collide, if will be impossible to prove the non-existence of either. (Which is the whole point, right?). In that case (of two exisitng owner names colliding), given the rules about including the superset of types in the bitmap, it might or might not be impossible to prove the non-existence of some RR types at those names. If the set of types at both names is the same, there shouldn't be issues. Hence my (somewhat frivolous) suggestion that one response would be to synthesize bogus records to match the bitmap. Or, in the case of a non-existing name colliding, synthesizing bogus RR's at the (previously non-existing) QNAME to match the NSEC3. -- 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 Sat Feb 26 17:20: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 RAA05060 for ; Sat, 26 Feb 2005 17:20:46 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D5AFQ-0004aD-Bf for namedroppers-data@psg.com; Sat, 26 Feb 2005 22:17:16 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D5AFN-0004ZZ-Em for namedroppers@ops.ietf.org; Sat, 26 Feb 2005 22:17:14 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 820BC33C33; Sat, 26 Feb 2005 22:17:12 +0000 (GMT) Message-ID: <4220F4F0.50602@algroup.co.uk> Date: Sat, 26 Feb 2005 22:15:12 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Samuel Weiler Cc: namedroppers@ops.ietf.org, Roy Arends Subject: Re: comments on nsec3-01 References: <421D7625.8090201@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 Samuel Weiler wrote: > On Thu, 24 Feb 2005, Ben Laurie wrote: > > >>I still don't understand what your concern is. Any individual NSEC3 >>record works standalone with its own hash/salt/iterations. The owner of >>a zone must be sure to have a complete set for any particular >>combination of hash/salt/iterations, or there could be queries it could >>not respond to, but it doesn't actually matter if a client receives part >>of the response from one set and part from another, since each >>individual NSEC3 record denies a particular RR, and that RR is denied >>whichever set it comes from (not that I can see how this can happen >>anyway, but guessing at your concern). > > > Then the doc needs to say that, including specific instructions to > validators to treat each NSEC3 individually (for instance, you might > have one NSEC3 proving no exact match using hash1 and one proving no > wildcard with hash2). > > The doc currently requires that the salt be the same throughout the > zone, which suggests (perhaps incorrectly) that the above doesn't > work. That is a requirement on the zone, to enable it to answer all queries. >>>** 2.1.2 Discarding NSEC3 RRs w/ unknown hashes sounds very, very bad. >>>** If you simply discard them, then presumably you can't do validation >>>** of negative answers in that zone (can anyone say "attack vector"?). >> >>How can this be used as an attack? NSEC3s must be signed, so an attacker >>is not at liberty to choose the hash. > > If a new (relatively unknown) hash is in use, the attacker can replay > it with interesting results. > > Imagine a zone using NSEC3 with a previously-unknown hash algorithm > (type 42). A validator that doesn't understand hash type 42 can still > process positive answers from that zone and set the ad bit for them. > What happens when that same validator (that doesn't understand hash > 42) gets a nonexistence proof from the zone? Following the above > rules, it discards the NSEC3. What does it do now? Treat validation > as having failed? That would make it very dangerous to use new hash > algorithms. Treat the zone as insecure (at least for non-existence > answers)? That looks like the only safe option, given the 'discard' > directive. > > Now imagine a man-in-the-middle. In response to a query for an > existing RR in the zone, the attacker synthesizes a nonexistence proof > using ANY of the NSEC3 RR's from the zone. The validator can't tell > the difference between this and the second situation above -- the > attacker has just spoofed away real names. Wouldn't it be better to > know the zone was insecure when you first enter it rather than have > this "somewhat secure" state? Would it? So long as I'm getting answers I can rely on, why do I care that I might get answers I can't? If I get an answer I can't understand, then I know that I can't understand it, so what's the big deal? An attacker can always deny me any answer at all, so the easy answer is to treat all incomprehensible answers as no answer. > This reminds me of a discussion from 1.5 years ago: > http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01539.html > http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01773.html > > >>>** One (perhaps bad) option is to tie the NSEC3 hash algorithm to the >>>** zone's DS message digest algorithm, since we already know how to >>>** handle unsupported algorithms in the DS. But since a zone could >>>** have multiple DS's (with different hash algorithms), but not >>>** multiple NSEC3 chains (presumably), this doesn't sound so good. >>>** Can we just declare "this is the NSEC3 hash function" and not >>>** parameterize it? >> >>Then we'd have to roll the whole protocol to change the hash function, >>which sounds even less good. > > If you can't change the algorithm with some grace, I think > parameterizing it is misleading and adds unnecessary complexity. I don't believe you've demonstrated that inability. >>>Security considerations: "If [hash collisions occur], it will be >>>impossible to prove the non-existence of the colliding domain" doesn't >>>sound quite right. >> >>It sounds right to me. What do you think is wrong? > > There are at least two ways to read this. Having looked again, I > suspect you meant: if the hash of an existing name and that of a > non-existing name collide, it will be impossible to prove the > non-existence of the non-existing name. Yes. > Another way to read it is: if the hashes of two EXISTING names > collide, if will be impossible to prove the non-existence of either. > (Which is the whole point, right?). In that case (of two exisitng > owner names colliding), given the rules about including the superset > of types in the bitmap, it might or might not be impossible to prove > the non-existence of some RR types at those names. If the set of > types at both names is the same, there shouldn't be issues. Hence my > (somewhat frivolous) suggestion that one response would be to > synthesize bogus records to match the bitmap. Or, in the case of a > non-existing name colliding, synthesizing bogus RR's at the > (previously non-existing) QNAME to match the NSEC3. I'll agree these are frivolous. -- 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 Feb 27 06:36: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 GAA16058 for ; Sun, 27 Feb 2005 06:36:18 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D5Meu-0006KM-He for namedroppers-data@psg.com; Sun, 27 Feb 2005 11:32:24 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D5Mer-0006Jt-G4 for namedroppers@ops.ietf.org; Sun, 27 Feb 2005 11:32:21 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id C5298C2DA6; Sun, 27 Feb 2005 11:32:16 +0000 (GMT) Date: Sun, 27 Feb 2005 11:32:15 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Samuel Weiler , Ben Laurie Cc: namedroppers@ops.ietf.org, Roy Arends , Alex Bligh Subject: Re: comments on nsec3-01 Message-ID: <5BEAED1795F883ABF5F12B85@[192.168.100.25]> In-Reply-To: References: <421D7625.8090201@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 26 February 2005 14:23 -0500 Samuel Weiler wrote: > Another way to read it is: if the hashes of two EXISTING names > collide, if will be impossible to prove the non-existence of either. > (Which is the whole point, right?). Such a circumstance can be trivially avoided at signing time by choice of salt. 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 Mon Feb 28 03:29: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 DAA18385 for ; Mon, 28 Feb 2005 03:29:53 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D5gCy-0005T1-T6 for namedroppers-data@psg.com; Mon, 28 Feb 2005 08:24:52 +0000 Received: from [193.0.2.43] (helo=ernie.secret-wg.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D5gCv-0005Sm-UH for namedroppers@ops.ietf.org; Mon, 28 Feb 2005 08:24:50 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by ernie.secret-wg.org (Postfix) with ESMTP id 4614514871F; Mon, 28 Feb 2005 09:24:28 +0100 (CET) Message-ID: <4222D53B.7030402@ripe.net> Date: Mon, 28 Feb 2005 09:24:27 +0100 From: "Olaf M. Kolkman" User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: agenda@ietf.org, namedroppers Subject: IETF62 DNSEXT Agenda 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.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, Below follows the draft agenda. Apologies for the somewhat last minute posting. --Olaf IETF-62 DNSEXT draft agenda WEDNESDAY, March 9, 2005 0900-1130 Morning Sessions The meeting is parallel to APP imapext Internet Message Access Protocol Extension WG INT autoconf Ad hoc Network Configuration BOF OPS v6ops IPv6 Operations WG RTG mpls MultiProtocol Label Switching WG SEC msec Multicast Security WG TSV ecrit Emergency Context Resolution with Internet Technologies WG ---------------------------------------------------------------------- Agenda (as of 2005/02/28) * Wilcard document Ed Lewis 20 min. 9:20 http://www.ietf.org/internet-drafts/draft-ietf-dnsext-wcard-clarify-06 DNS SHA-1 attack imact Olafur Gudmundsson 10 min 9:30 DNSSEC Keying * IPR issues Chairs 5 min. 9:35 DNSSEC Denial of existence * Requirements for new RR synthesis methods. Chairs 10 min. 9:45 http://www.ietf.org/internet-drafts/draft-ietf-dnsext-signed-nonexistence-requirements-01 * Closest enclosers for DNS Names (in Last Call ending March 20'th). Sisson or Lauri 10 min. 10:00 http://www.ietf.org/internet-drafts/draft-sisson-dnsext-dns-name-p-s-01 * DNSSEC Online Epsilon signing Weiler 10 min. 10:10 http://www.ietf.org/internet-drafts/draft-weiler-dnsext-dnssec-online-signing-01 * NSECv3 Hashed based denial of existence Arends 15 min. 10:25 http://www.ietf.org/internet-drafts/draft-ietf-dnsext-nsec3-03 * Bert Denial (Basic Error Response Type) Gieben 5 min. 10:40 http://www.ietf.org/internet-drafts/draft-gieben-bert-response-00 other DNSSEC * DNSSEC experiments Blacka 10 min. 10:50 http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-experiments-00 * Opt-In status update Chairs 5 min. 10:55 http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-opt-in-07 Documents in final stages. 10 min. 11:05 * LLMNR changes Aboba http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-38 * TSIG SHA-1 (Last Call March 8) http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tsig-sha-01 * RFC2538bis CERT RR (Last Call ending March 20) http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2538bis-01.txt Cross fertilization * DNS issues in other groups. 20 min. 11:25 Any other business Document Administrivia -- to unsubscribe send a message to namedroppers-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 Feb 28 03:33: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 DAA18650 for ; Mon, 28 Feb 2005 03:33:19 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D5gIa-0006F3-9C for namedroppers-data@psg.com; Mon, 28 Feb 2005 08:30:40 +0000 Received: from [193.0.2.43] (helo=ernie.secret-wg.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D5gIR-0006CA-AW for namedroppers@ops.ietf.org; Mon, 28 Feb 2005 08:30:31 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by ernie.secret-wg.org (Postfix) with ESMTP id 78507148725 for ; Mon, 28 Feb 2005 09:30:10 +0100 (CET) Message-ID: <4222D691.1090804@ripe.net> Date: Mon, 28 Feb 2005 09:30:09 +0100 From: "Olaf M. Kolkman" User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers Subject: DNSEXT WG Last Call: RFC2538bis CERT RR 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.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 This WG last call ends March 20'th 2005 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2538bis-01.txt This is an update to RFC2538 which defines an DNS RR named CERT. The changes from RFC2538 are technically minor, but significant new text about use and applicability has been added. This document is on standards track, the plan is to submit it as advancing the specification for CERT RR from Proposed to Draft Standard. Before that happens an interoperabilty report needs to be generated. If you disagree with this standards action please state so and why it is necessary to recycle at Proposed Standard. If there are no comments on this document it will be advanced to the IESG after interoperabilty report is submitted. If you are willing to take on the task to generate the interoperability report please notify the grateful chairs. If we do not find volunteers we will forward the document to the IESG for a recycle as Proposed standard. Olaf and Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 28 08:18: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 IAA18091 for ; Mon, 28 Feb 2005 08:18:03 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D5kiH-000JoR-Rd for namedroppers-data@psg.com; Mon, 28 Feb 2005 13:13:29 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D5kiF-000JoB-Kb for namedroppers@ops.ietf.org; Mon, 28 Feb 2005 13:13:27 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id BE26F26655; Mon, 28 Feb 2005 14:13:26 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id D1CD926653 for ; Mon, 28 Feb 2005 14:13:25 +0100 (CET) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id j1SDDPet023033 for ; Mon, 28 Feb 2005 14:13:25 +0100 Date: Mon, 28 Feb 2005 14:13:25 +0100 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: Re: IETF62 DNSEXT Agenda Message-Id: <20050228141325.51a5d5e8.olaf@ripe.net> In-Reply-To: <4222D53B.7030402@ripe.net> References: <4222D53B.7030402@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.000001 / -5.9 X-RIPE-Signature: 2b2eb9af7221b0ff652afd1aab7152b4 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 Mon, 28 Feb 2005 09:24:27 +0100 "Olaf M. Kolkman" wrote: In the agenda announcment I wrote: * Closest enclosers for DNS Names (in Last Call ending March 20'th). http://www.ietf.org/internet-drafts/draft-sisson-dnsext-dns-name-p-s-01 I made a mistake: The document is not in last call and will be updated once more before a last call is issued. -- 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 Mon Feb 28 15:18: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 PAA02479 for ; Mon, 28 Feb 2005 15:18:15 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D5rGn-0003o7-3r for namedroppers-data@psg.com; Mon, 28 Feb 2005 20:13:33 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D5rGk-0003nc-IM for namedroppers@ops.ietf.org; Mon, 28 Feb 2005 20:13:30 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j1SK9t1t013885 for ; Mon, 28 Feb 2005 15:09:55 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAesaihB; Mon, 28 Feb 05 15:09:52 -0500 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j1SKBOvr019073; Mon, 28 Feb 2005 15:11:27 -0500 (EST) Date: Mon, 28 Feb 2005 15:11:24 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: Ben Laurie cc: namedroppers@ops.ietf.org, Roy Arends Subject: Re: comments on nsec3-01 In-Reply-To: <4220F4F0.50602@algroup.co.uk> Message-ID: References: <421D7625.8090201@algroup.co.uk> <4220F4F0.50602@algroup.co.uk> 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 Sat, 26 Feb 2005, Ben Laurie wrote: > >>>** 2.1.2 Discarding NSEC3 RRs w/ unknown hashes sounds very, very bad. > >>>** If you simply discard them, then presumably you can't do validation > >>>** of negative answers in that zone (can anyone say "attack vector"?). I made a leap to "there could be an attack" by assuming a behavior (treat the zone as unsecure) that differs from what the doc seems to describe now. Going back to the doc as it is now: > > Imagine a zone using NSEC3 with a previously-unknown hash algorithm > > (type 42). A validator that doesn't understand hash type 42 can still > > process positive answers from that zone and set the ad bit for them. > > What happens when that same validator (that doesn't understand hash > > 42) gets a nonexistence proof from the zone? Following the above > > rules, it discards the NSEC3. What does it do now? Treat validation > > as having failed? That would make it very dangerous to use new hash > > algorithms. [Discussion of an alternative behavior removed.] ... > Would it? So long as I'm getting answers I can rely on, why do I care > that I might get answers I can't? If I get an answer I can't understand, > then I know that I can't understand it, so what's the big deal? An > attacker can always deny me any answer at all, so the easy answer is to > treat all incomprehensible answers as no answer. Think about this from the perspective of a zone owner: "if I sign my zone using new NSEC3 hash algorithm 42, many/most resolvers will discard the NSEC3's, resulting in validation failures in my zone -- among other things, unsecure delegations FROM my zone will vanish, since resolvers discard the NSEC3's needed to prove that they're unsecure". And none of this requires an attacker -- this is what happens with well-behaved validators using the algorithm your doc describes. That's a pretty strong disincentive to use any new algorithm. > > This reminds me of a discussion from 1.5 years ago: > > http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01539.html > > http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01773.html > > > >>>** One (perhaps bad) option is to tie the NSEC3 hash algorithm to the > >>>** zone's DS message digest algorithm, since we already know how to > >>>** handle unsupported algorithms in the DS. But since a zone could > >>>** have multiple DS's (with different hash algorithms), but not > >>>** multiple NSEC3 chains (presumably), this doesn't sound so good. > >>>** Can we just declare "this is the NSEC3 hash function" and not > >>>** parameterize it? > >> > >>Then we'd have to roll the whole protocol to change the hash function, > >>which sounds even less good. > > > > If you can't change the algorithm with some grace, I think > > parameterizing it is misleading and adds unnecessary complexity. > > I don't believe you've demonstrated that inability. And I believe this document hasn't even postulated, much less demonstrated, an ability to gracefully roll them. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Feb 28 15:24: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 PAA03209 for ; Mon, 28 Feb 2005 15:24:54 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D5rQ5-0004zX-6v for namedroppers-data@psg.com; Mon, 28 Feb 2005 20:23:09 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D5rQ4-0004z7-3N for namedroppers@ops.ietf.org; Mon, 28 Feb 2005 20:23:08 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j1SKJW46014812 for ; Mon, 28 Feb 2005 15:19:32 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAceay6C; Mon, 28 Feb 05 15:19:29 -0500 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j1SKLF9g019579; Mon, 28 Feb 2005 15:21:17 -0500 (EST) Date: Mon, 28 Feb 2005 15:21:15 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: Peter Koch cc: IETF DNSEXT WG Subject: Re: I-D ACTION:draft-ietf-dnsext-dnssec-trans-02.txt In-Reply-To: <200502242137.j1OLbqU02800@grimsvotn.TechFak.Uni-Bielefeld.DE> Message-ID: References: <200502242137.j1OLbqU02800@grimsvotn.TechFak.Uni-Bielefeld.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=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The sections I commented on in -01 seem largely unchanged in -02, so the same comments apply. See: http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg02097.html I also noticed that 2.2.3.2 suggests splitting the algorithm space with each version of DNSSEC. As David Blacka's experiments draft suggests, there might be more efficient ways to do this, and blindly allocating half of the algorithm numbers at each versioning sounds very limiting. > Sam: you said in November that you hadn't done an in depth review. > Nevertheless > you suggested another "dead end" to be added (DS hash based; I'd be happy > to learn the details, but pls see below) Essentially: rather than change DNSKEY algorithms, change DS message digest algorithms (or: use message digest algorithms as a signaling mechanism). Any resolver that doesn't understand the new message digest number wouldn't be able to use that DS anyway. http://darkwing.uoregon.edu/~llynch/dnsop/msg03203.html -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: