From owner-namedroppers@ops.ietf.org Thu Jun 01 02:39:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlgqB-0006dz-L1 for dnsext-archive@lists.ietf.org; Thu, 01 Jun 2006 02:39:31 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flgq8-0000hI-5h for dnsext-archive@lists.ietf.org; Thu, 01 Jun 2006 02:39:31 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Flgls-000KZR-AV for namedroppers-data@psg.com; Thu, 01 Jun 2006 06:35:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Flglq-000KYs-Tq for namedroppers@ops.ietf.org; Thu, 01 Jun 2006 06:35:03 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k516Z0W1054240 for ; Thu, 1 Jun 2006 08:35:00 +0200 (CEST) (envelope-from olaf@open.nlnetlabs.nl) Received: (from olaf@localhost) by open.nlnetlabs.nl (8.13.4/8.13.4/Submit) id k516Z0RE054239 for namedroppers@ops.ietf.org; Thu, 1 Jun 2006 08:35:00 +0200 (CEST) (envelope-from olaf) Date: Thu, 1 Jun 2006 08:35:00 +0200 (CEST) From: Olaf Kolkman Message-Id: <200606010635.k516Z0RE054239@open.nlnetlabs.nl> To: namedroppers@ops.ietf.org Subject: DNSEXT list policy Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 - List Purpose namedroppers@ops.ietf.org is the mailing list for the IETF DNSEXT working group. See for the wg charter. Messages should be on topics appropriate to the dnsext wg, which are various discussion of the DNS protocols or administrivia of the WG itself. - Specific items that are not not appropriate for posting Calls for papers, announcements of events not directly relevant to the DNS protocols, etc. are not appropriate. Discussion of problems with particular implementations, announcements of releases, sites' misconfigurations, pleas for help with specific implementations, etc. should be done on mailing lists for the particular implementations. There is a working group for dns operational practice, DNSOP, whose charter can be found at . Items relevant to the DNSOP charter are to be discussed on the DNSOP mailinglist. Discussion about the quality of implementations is outside the scope of this list. - Moderation Moderation is based on "subscriber-only with spam filter". To counter a certain class of spam mails messages over 20000 characters, originating from list subscribers, will be held for moderations. Questions or concerns related to the acceptance or rejection of specific messages to the namedroppers mailing list should first be discussed with the wg chairs, with followup appeals using the normal appeals process of rfc 2026 (i.e. follup with area directors, then iesg, etc.). There is a mailing list for the discussion of ietf processes, which includes any general discussion of the moderation of ietf mailing lists. it is poised@lists.tislabs.com --- NOTE WELL: All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. ---------------------------------------------------------------------- $Id: dnsext-list-policy.txt,v 1.8 2005/01/12 15:54:51 olaf Exp $ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 02 00:55:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm1gk-0007vo-6W for dnsext-archive@lists.ietf.org; Fri, 02 Jun 2006 00:55:10 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm1gi-00043b-TO for dnsext-archive@lists.ietf.org; Fri, 02 Jun 2006 00:55:10 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fm1bn-000HRW-2J for namedroppers-data@psg.com; Fri, 02 Jun 2006 04:50:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: * X-Spam-Status: No, score=1.0 required=5.0 tests=BAYES_00,DATE_IN_PAST_03_06, FORGED_RCVD_HELO,RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_SORBS_WEB autolearn=no version=3.1.1 Received: from [147.28.0.18] (helo=dragaera.hactrn.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fm1bm-000HR4-5E for namedroppers@ops.ietf.org; Fri, 02 Jun 2006 04:50:02 +0000 Received: from thangorodrim.hactrn.net (m010f36d0.tmodns.net [208.54.15.1]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thangorodrim.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by dragaera.hactrn.net (Postfix) with ESMTP id 724F114C46; Fri, 2 Jun 2006 04:50:00 +0000 (GMT) Received: from thangorodrim.hactrn.net (localhost [IPv6:::1]) by thangorodrim.hactrn.net (Postfix) with ESMTP id 6CFDB116B7; Fri, 2 Jun 2006 00:14:27 +0000 (UTC) Date: Thu, 01 Jun 2006 20:14:27 -0400 From: Rob Austein To: Namedroppers , Mark Townsley Subject: Re: draft-ietf-dnsext-nsid issues to be reviewed In-Reply-To: <1A9A27DF-B365-4F02-80EE-D499DC3449AA@nlnetlabs.nl> References: <1A9A27DF-B365-4F02-80EE-D499DC3449AA@nlnetlabs.nl> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20060602001427.6CFDB116B7@thangorodrim.hactrn.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.9 (+) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 At Tue, 23 May 2006 10:50:48 +0200, Olaf M Kolkman wrote: > > NEW: > > 3.1. The NSID Payload > > The syntax and semantics of the content of the NSID option is > deliberately left outside the scope of this specification. It is > the prerogative of the server administrator to choose the NSID > content as long as the content is unique and the server administrator > is able to match the NSID to server instances. This > section describe some of the kinds of data that server administrators > might choose to provide as the content of the NSID option, and > explains the reasoning behind choosing a simple opaque byte string. I do not see the need for content to be unique. All that matters is that the name server which provides the NSID payload be able to understand it; the rest is nobody else's business. > Is there consensus to add such a "MUST implement a specific automated > method"? I do not see the need for a "MUST implement" method. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From fdpd2001@teenscare.com Fri Jun 02 14:25:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmELH-0004hg-No for dnsext-archive@ietf.org; Fri, 02 Jun 2006 14:25:51 -0400 Received: from [218.95.118.144] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FmE9B-0003Rb-24 for dnsext-archive@ietf.org; Fri, 02 Jun 2006 14:13:25 -0400 Message-ID: <000001c6866f$ba327a80$0100007f@localhost> From: "Edward Stewart" To: Subject: Corel Draw Date: Sat, 03 Jun 2006 02:13:25 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6866F.BA327A80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.5 (++++) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6866F.BA327A80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Special Offer Adobe Video Collection Adobe Premiere 1.5 Professional Adobe After Effects 6.5 Professional Adobe Audition 1.5 Adobe Encore DVD 1.5 $149.95 More Info >> Microsoft 2 in 1 MS Windows XP Pro MS Office 2003 Pro $99.95 More Info >> Microsoft + Adobe 3 in 1 MS Windows XP Pro MS Office 2003 Pro Adobe Acrobat 7.0 Professional $149.95 More Info >> Bestsellers Microsoft Office Professional Edition 2003 Rating: 6 reviews Retail price: $550.00 You save: $480.05 (87%) Our price: $69.95 [Add to cart] Microsoft Windows XP Professional Rating: 8 reviews Retail price: $200.00 You save: $150.05 (75%) Our price: $49.95 [Add to cart] Adobe Photoshop CS2 V 9.0 Rating: 3 reviews Retail price: $599.00 You save: $529.05 (88%) Our price: $69.95 [Add to cart] ------=_NextPart_000_0001_01C6866F.BA327A80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable DS
Special Offer
Adobe Video Collection
  • Adobe Premiere 1.5 Professional
  • Adobe After Effects 6.5 Professional
  • Adobe Audition 1.5
  • Adobe Encore DVD 1.5
$149.95    
More Info >>
Microsoft 2 in 1
  • MS Windows XP Pro
  • MS Office 2003 Pro




$99.95    
More Info >>
Microsoft + Adobe 3 in 1
  • MS Windows XP Pro
  • MS Office 2003 Pro
  • Adobe Acrobat 7.0 Professional


$149.95    
More Info >>
Bestsellers
3D"" Microsoft Office Professional Edition 2003
Rating: 6 reviews
Retail price: $550.00
You save: $480.05 (87%)
Our price: $69.95		  

Add to cart

3D"" Microsoft Windows XP Professional
Rating: 8 reviews
Retail price: $200.00
You save: $150.05 (75%)
Our price: $49.95		  

Add to cart

3D"" Adobe Photoshop CS2 V 9.0
Rating: 3 reviews
Retail price: $599.00
You save: $529.05 (88%)
Our price: $69.95		  

Add to cart

------=_NextPart_000_0001_01C6866F.BA327A80-- From owner-namedroppers@ops.ietf.org Fri Jun 02 18:55:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmIYg-0004Rp-Du for dnsext-archive@lists.ietf.org; Fri, 02 Jun 2006 18:55:58 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmIYe-0001NE-Vb for dnsext-archive@lists.ietf.org; Fri, 02 Jun 2006 18:55:58 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FmITx-0005qR-Fk for namedroppers-data@psg.com; Fri, 02 Jun 2006 22:51:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_ZOMBIE autolearn=no version=3.1.1 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FmITw-0005qG-Dw for namedroppers@ops.ietf.org; Fri, 02 Jun 2006 22:51:04 +0000 Received: from [130.105.12.10] ([130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id k52MotVM020267 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 2 Jun 2006 18:50:55 -0400 Date: Fri, 2 Jun 2006 18:50:53 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Rob Austein cc: Namedroppers , Mark Townsley Subject: Re: draft-ietf-dnsext-nsid issues to be reviewed In-Reply-To: <20060602001427.6CFDB116B7@thangorodrim.hactrn.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.8 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c On Thu, 1 Jun 2006, Rob Austein wrote: > At Tue, 23 May 2006 10:50:48 +0200, Olaf M Kolkman wrote: > > I do not see the need for content to be unique. All that matters is > that the name server which provides the NSID payload be able to > understand it; the rest is nobody else's business. It should be unique so that remote users can determine if there a problem with an anycast instance, that is, two anycast instances returning different data, or verify that different anycast instances return the same data. etc. I think it has to be unique anyway, even if opaque. If it is exactly the same across all instances, then it is entirely useless. So, the question that needs to be addressed (and I think this is what Olaf was driving to) is whether the (opaque) response remains the same for the same anycast instance across multiple requests which reach the same instance, or is changed for each packet in some way that only the server operator can decode. I think it should be the former. By contrast, it seems to me that Mr. Austein has in mind a means of keeping secret the number of anycast instances. I see no good reason for that, and many good reasons for being able to identify specific instances over a series of requests. One would need to be able to do this in order to perform any sort of testing on Anycasted responses. Given the current state of discredited research on stateful DNS anycast, and the difficulty of getting data from DNS operators, it is an important facility to be able to uniquely identify that different Anycast servers respond, and with what responses. I think its perfectly fine to hide sensitive information about OS and DNS vendor/version, even about static unicast address, but I think it is not OK to withhold data which indicates that Anycast is in use, and which can indicate how many anycast instances there are, or at least that different anycast instances responded over a series of queries. I suggest the following wording: 3.1. The NSID Payload The syntax and semantics of the content of the NSID option is deliberately left outside the scope of this specification. It is the prerogative of the server administrator to choose the NSID content as long as the content is unique to each anycast instance so that a remote user is able to match the NSID to the server instance over a series of queries. The NSID can be opaque and encoded such that it can be decoded by the server adminstrator to provide more information. This section describe some of the kinds of data that server administrators might choose to provide as the content of the NSID option, and explains the reasoning behind choosing a simple opaque byte string. --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 Mon Jun 05 10:58:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnGWt-0006Ry-Ns for dnsext-archive@lists.ietf.org; Mon, 05 Jun 2006 10:58:07 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnGWr-0007bp-5T for dnsext-archive@lists.ietf.org; Mon, 05 Jun 2006 10:58:07 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FnGRZ-0005pL-IJ for namedroppers-data@psg.com; Mon, 05 Jun 2006 14:52:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FnGRY-0005p9-Ln for namedroppers@ops.ietf.org; Mon, 05 Jun 2006 14:52:37 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k55EqVBU009925 for ; Mon, 5 Jun 2006 10:52:31 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.2.5.6.2.20060531110957.03269760@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 05 Jun 2006 10:52:19 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: NSEC3 Issue 19: NSEC3 processing order Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Issue: Should the document specify a recommendation about if a validating resolver should process first the range of NSEC3 names covers query name or the signature on the NSEC3 records is valid Discussion: RFC4035 specifies/recommends that validating resolver first check that the name range applies before validating the signature, as that is the less expensive operation. For a NSEC3 with high iteration count it is possible that validating the signature is less expensive than checking the name range. Resolution: None at this point -- to unsubscribe send a message to namedroppers-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 Jun 05 17:21:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnMVT-0003F7-Fp for dnsext-archive@lists.ietf.org; Mon, 05 Jun 2006 17:21:03 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnMVS-0002rZ-2O for dnsext-archive@lists.ietf.org; Mon, 05 Jun 2006 17:21:03 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FnMR9-0009cQ-7Y for namedroppers-data@psg.com; Mon, 05 Jun 2006 21:16:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FnMR7-0009c7-Qy; Mon, 05 Jun 2006 21:16:33 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 05 Jun 2006 22:16:28 +0100 X-IronPort-AV: i="4.05,211,1146438000"; d="scan'208"; a="3581906:sNHT32095512" In-Reply-To: <6.2.5.6.2.20060531110957.03269760@ogud.com> To: =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson?= Cc: namedroppers@ops.ietf.org, owner-namedroppers@ops.ietf.org Subject: Re: NSEC3 Issue 19: NSEC3 processing order MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Roy Arends Date: Mon, 5 Jun 2006 23:16:11 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 06/05/2006 10:16:12 PM, Serialize complete at 06/05/2006 10:16:12 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 owner-namedroppers@ops.ietf.org wrote on 06/05/2006 04:52:19 PM: > > > Issue: Should the document specify a recommendation about if a validating > resolver should process first > the range of NSEC3 names covers query name > or the signature on the NSEC3 records is valid > > Discussion: RFC4035 specifies/recommends that validating resolver first > check that the name range applies before validating the signature, as that > is the less expensive operation. For a NSEC3 with high iteration count it > is possible that validating the signature is less expensive than checking > the name range. > > > Resolution: > None at this point I think it is fine to have the draft include a note on this specific implementation recommendation, absent of any MUST or SHOULD. Regards, Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From adle.truck@teenscare.com Tue Jun 06 01:52:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnUO5-0005oA-S8 for dnsext-archive@ietf.org; Tue, 06 Jun 2006 01:45:57 -0400 Received: from 200-147-4-87.tlm.dialuol.com.br ([200.147.4.87] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FnU7c-00053Q-C2 for dnsext-archive@ietf.org; Tue, 06 Jun 2006 01:33:40 -0400 Message-ID: <000001c68929$b3cf2780$0100007f@localhost> From: "Israel Wood" To: Subject: Don't get left behind! Date: Tue, 06 Jun 2006 02:28:40 -0300 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0001_01C68929.B3CF2780" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.0 (++) X-Scan-Signature: 6fd498969019220b4f904725504c12a0 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C68929.B3CF2780 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C68929.B3CF2780" ------=_NextPart_001_000E_01C68929.B3CF2780 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In a trice without warning the face of nature grew sullen Black angry mouths, the clouds swallowed up the sun The air was dense with suppressed excitement The wind howled through the long corridors and sobbed and whisperedin the secret recesses ------=_NextPart_001_000E_01C68929.B3CF2780 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi dear baby
------=_NextPart_001_000E_01C68929.B3CF2780-- ------=_NextPart_000_0001_01C68929.B3CF2780 Content-Type: image/jpeg; name="top.jpg" Content-Transfer-Encoding: base64 Content-ID: <00088751267563$0762dd00$0403a8c0@zuzu> /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAAAAA/+4ADkFkb2JlAGTAAAAA Af/bAIQAGxoaKR0pQSYmQUIvLy9CRz8+Pj9HR0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dH R0dHR0dHR0dHR0dHR0dHRwEdKSk0JjQ/KCg/Rz81P0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dH R0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dH/8AAEQgAqQJCAwEiAAIRAQMRAf/EAI4AAAID AQEAAAAAAAAAAAAAAAADAQIEBQYBAQEBAQEAAAAAAAAAAAAAAAABAgMEEAABAwIEAwQIBQEG BgMBAAABAAIDERIhMVEEQWETcZGhBYGx0SIyQlIU8MFi0iOz4fGSsjNTcoKio9MV4kMkRBEB AAMAAgMBAQEBAAAAAAAAAAERIQIS8DFBYVGBof/aAAwDAQACEQMRAD8A7gcVNx1S0LrTnZlx 1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1Rcd UtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCU WZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcd UXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHV LQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFmXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlF mXHVFx1S0JRZlx1RcdUtCUWZcdUXHVLQlFtFf8qFX9qFlpnqiqoXCuai8arq5GVRVKvCOoED aoqk9QI6rUDqoqkdYI6wQPqiqz9YI64QaKoqkMlvNrRirm4ZjxUUyqKpBkposD/NY2GmJ7P7 0HWqiqwx7sSAOAwP41TOsVUaqoqsvWKOqUGqqKrL1SjqFFaqoqsvUcpvcg01RVZr3KbnaoNF UVWe52qmrtVA+qKpFXaqfe1QOqiqTR2qmjtfBLKNqiqVR2vgptdr4JZRlUVS7Xa+Cmx2vglw UvVMjZf2LOQR83gt8bbWgFZmf41EJsboqmJpQXVValY1vEGHQqhicE68qb1blKhlIIzUVWy4 KCxruCvZnqyVRVPdtwciQlnbO4O8FrtCdZUqiqDA8cfBUscOPglwVK9UVVLHa+CLHa+CtwlS vVFUu12vgi12vglwUZVFUu12vgoo7XwSyjaoqlUdr4Io7VLKNqiqT72qPe1QOqiqT72qj3tU D6oqkVdqirtUD6oqkVdqirtUD6oqsM+4MLa5rEfNHD5fH+xSZiFqXbqiq4P/ALZ30+P/AMVp 22+fO6lKAca/2KdoXrMurVFUoB2qtY7XwU78V6cl6oqq9N31eCnpO+rwV78U6ymqKo6Tvq8E dF31eCdoOsn/ALEIsOvyU/tQsXDVSybpgDQ4LDVdWZt0ZHJcldePpzlKFClbQIQhQCECpNBi U77WXQD0pZRKgAvNrRUp7do4/EQAt0bWQije/iszy/jUQrFCIG/qOZWeV1VE8zvlosI3JrR4 pzCRH2SZLmfQELiObRdTdn3wRkVm3LKEAKykG7PcClhzGS6oNVxBFTFb4XEiikT/AFa/japV GteeCCS34hRW4SjFKqDVWQSpUKUEqVCsoBShSoqVKFKKFKFKgFKFKihVcaK6o/NBDG3OAW9x oFm27cSdE55WZaVQoQiBCFCAQhQgm4hWEhS1CB4lHFWvaVlUJRbVY0qphHArNUhWErglSWs6 ItxzS1sY8PFVjdg4hWJJhCFKhaZQoVlCCqFKhUQoUoREKFKEEIQocaBUcnfPq4N0xXMctG4f c9x50WVy4TsuvqELtbOkMYwq53BcZguIC9JtmBguOZ8Ascm+KpdPwClu5czBye6YBLJbJzWX SmiPdNfhxWoOXM6AzC0xEjApbNNalLBUlyts0f7EKtf8qFq0pUZLkSNtcRousMlh3bKEO1Xf j7cZZFKhSurAUHQZqU/asufcfl9akjdBCIW/qOZRJKEPcsj1iIvZbmaKlnIOCWHkjFSWqCFq mbLc4pTkxyUVUc+QkGhyTiL/AHlSZmNVePFiDIXkYJ0W4tSpG4pdFmYtYl6GLctc0FL3M4ou TE+3BWmNQlLa+13Ra+x3wnJdkGq8qV6LaydRgcpBLUrKFKqJUqFZFSpUKyglShSFFCsiimii hSpopooISnZp9EmlSitMIo3tUONSmn3QkLKpUIQqgQoQgFCFCqBQhQgFVChVAqoUKjTts3ej 80itXuPMrRtsGk81mixxWPrXw1QrKFpFVCsoVRVClQghQpUKohClQgFn3D7GE8loXO376Mpq pPpY9uM4pauVVcXVp2cd7xyXVmlsHNL8vhoy76lpkgL8OC5z7dYyHOEjnPAzOWK6J20jRUt9 LVDdmAa8M6Lo9U6U9K1cJN/GGJ/A96eClvYTiM07pkCqxLR7cUOURokKvxn6bX/IhVr/AE0K spCXMy9pHFXClehxchCbMyx3IpS6uaCtu0waTzWErftR/HXtUlYXeUpyjcvLBhmTQelZZXwx OtlldcMwApcQtWcQluCQNxtXENa+Zzjwb7KKTNtbrTJKxw+sflRTvB1lD0op8rCwB1Q9jsnt 9RWd+C3E2zMUzzFM2nvMI0KzylaNgcXBBnnZQrOV0tw1c9wQUVg6uCqV1dpHFBCdzKLgDQN1 NKrMzTURbjujdoV1vLT7lOahvnDXODXRMsJpgMaLX0hBK9jcgfWFmJuWpjGoKVQOGqutMJVg qpeL3EElrWNuNuLj2KSsNCkLm/dbYZyyK7J4X4sfM7saT6gs3DVOkFYLmOmiYKufO0alpH5J 0UmLHMc57JbqXZ+77UspvUqlVJcBmaKC6lZdxMWsqw4uIbXSqw7meDbutmMr3aGoaezLBFdR 00YwLm17QrxCrlxNpvItzL0mxNay1xcTi6gHArreXVMIJ/GKitchwokq0hqVRIRKFCFUCFCh BKhCqqJVUKEQKqCoVAqoVSVUbme7DXkSlRDBW3LhFtzdgABWi47dzBZfduLMrvl76UXJ0dpQ udDM2X/Qlvd9D8z6VsilEgrkRgRoVpF1VSSBmorVVEKEOcGipwCzhzpPeDhGwkNaSK3E4YKo eoS4nl1Q74mG0pioFCKhZbm9MzSl4bUijBlTVLopoc4NzNFxt/IHuABTH+Z7aP8A0o7zq/FT 5i0BzaANJY0upgKkY0CxM3DURTluVGipAVnZrV5a2/cNrk03d2K5tu1A+NoDQ5veFstqsomk LLy4kn5TSh/TlxyTA8sc5o+Bh8K0NP8AhOfJY6/xu/6cWKOlzUCUucABgfUPm7K4c+C0UUos kMorFXKoSooaqvV2pbs0Dqf00Kf/ABoW2VUKELu4lzsvbzC566iwzx2moyK3xn4zLORcaDiu sGhjQBwXOgFZAug4pKQy7ht7Twpj3Ll+ayF23ivxcamvLgujuXWxns9eC5HnRo9kX0MA9Kzz b4l+TN/nL/8AbY53hT81bzsfzNr8Vjbu1X8m6jL3sj6oNGnECnHjmrzeX7ndSmWa2Fp4uIy7 AVybW8ojfNBKwZEstrlX5vCi0PftonCP3txITSgwFUbuRuy2jYtv/wDZXHidT6fVgub5Q14n 6jWXloJxIbnhWp7VblG+fcwQP6U8JYdWuqrjaRR/ziQMid8Lqa8O38YJXmGz3G7eHNYGhrba F7St+yjft4OlJSrQ9xbgcOCsTJTE/c7OPFznTHuCh262bGiW0lzh8AJoPT+S4RgeTgOK9Tvm /wD5pIsKMEbW8iMSlyYww7rb7x3RLOm53wuGuhWh0e3ihO33DxQ0dQZg04Hj3Lk+W7Z33MfJ 1e7FdLzKsu3bU4ue4troDRNGXZR7UbhjWXSknC6gApjWnGnat+4MW3rLuffe81DBpwquf5VA Y5XSGn8bHO/JW83gdJPeT7jgC08qKaNccoljMw29YhXEOxwzIHJXa9hayWK4MkJFruXELL5f ujtR05PfjPe2udPYtj2NY6ONn+mxpLMa1uWou0n0eEot/lYWkguND2cU1VjP84JyY1zvyW5Z h5vzJ4fuXkfUurtXOg2jLTYZHudXkPdXMkga5xcSakrvxF21Y2MzBnug29O6leYXOm7X23Ue P5X+7Jcxodx9CXIyGBsbXS2WNwwxNePJXAk+4D3u6jWRukaQKDEUy1WZ5MmzcJfeFwa2vDin 6Fv3u0aQPemJObjQIm3u0hNGtMp1dXLks2w2zHbhmGRr3Cq2eZ0mZG5+LjcfQTgmijJYt3G5 0Q6boxVzeBGvoSPN3nowsOJtu70zYRBrZXAfIG/4ireaNa6a0itjQ1PwZfKRayaXRlv+I/2L smcbWJomd0xTBjfi7Seegos2xjthForfKMB9LcUzc7fbdR0m4fea4NGnAfiiCJd0I4hOYnWO yJkNTXI0rgCp2u7ZuiRDVjwK2OJc0jj+AjzF5MLWFljD8IJxoBxHDvPNY/LmNY58gFLI3d5T R0ZN3FGSHzAEZhrcfGqVBu4Nw8xsvoGlxkLjhTlkkeY++2K+jn21Jpqk7OCOj5Xj3GAVaMLq 5A8k0MPmm3vsDHFuQc0m71p+43u32+Di6V2laU7aYVUQwbd7i6NhZIxrjZwry41XKa1jnAuA oSKpo6cu6dDG2V8DRG/LHHlXSqq3zPaltf5Gn6QTTvzWzftPSkvyc8WjkAsHlsIa4zUAY1pH aTk3mg27eRm5jMzP4WtdSpJOFMc/D88lSPcxzP6cDXzOGbi60exJ8yc1p6DAGtGJDRQVKv5Y 0xMcWR3BzhjcG/Cmhce/gkf03B0L60rdUA8wVuBIJY74m5+30rmT+Wyyvc+1vvEn4m8fSui4 1lONaNaD2qwkrqKVIGpooV4RWRo5+rFbYV88fbtiPqISI22bLpnLo3HteahX87F7WR6lRuGT zRdFsRbUAE3N4c65Lk6vJxlwcLPiqKdvBex3LGxPfLK/psdTBubqD+9c/b7FmzeHv9+X5Ixj jqexa99tYZZOpuHkAUowcO3PinpCepF0jOyEujHzOdicaVA7VTbbmDcusiBhlPw41aeRWjcu ptLI2dOJ2Dan3ta0xw7TVcvyzbAblrq4Nq7uBV0dKaSPbsEswdKT/gB0XNZv5d3uWOtLgw1D G8lq8wbft421pcXOPpOCR5ZD0jJJWtsZA7XZJNjqtgM1zhG+F2dznZknTTVZ3y7drhGS7cSE 0oDQVVN698ULYWH3ni557eCy+WRGASTnNjaN7XcU0atzPFtXBs0FLhX3Xk+OqdG+L7eSeEmw tLS13B2HtSH2vYI9ywvtxa4HHHMVV9y5o2RZE2xpdaB4kk9qTY81EA57Q7AEivZVej3fmW1a 8kMMjjxNQO5c3yrbn7lheMG1cfQD+dFr84ulZE4iryCT2HJRU1g30TnRt6b48SOBHLsSPLhZ 1X/Qwj0nBHljCyKZ7sBa1veUiJ7gHNHwvOPOmIQq3dhIayrQA5pFXU9612h5HDsTbmsINPdb UHiXVGI/N3o4rFCatzpUUPYcxitkQA41wp2D8ek8Vz7Os8Z/xphoC4ca+Hy05W0onErPG0Nx qTgB2AcP702qkyzSHFLKs4qtQFlo1owSnpwdgkONUkg+v9NCKf00LbKiFCF6HBKq9oeKFShB j27SJCDwC1uQAK14qshote5RlLDOSSQ2NjqEu40zAXL3r2TTOfg4arSdwYaghj2uddRwrQ/j 8Zqw3UlMGxj/AJQszEzLUVQ2rBJt+nGWtffUitDlQUQzbteCTW4YU5q0e5keatjjq052ioPe nRMLB72JJqfSrEJMs24aZNux7cenVruWhSdnKxjy15o2RpbXSvFayHwuvi45jgVR0jDi6Bte VQszErZkUMMbsD15PlY31u5duCfubNvG4m1sj2hpa3Xjh2LC7eOaLY2tiB+kY96k75xNSyO7 ibcSlStwxQFvUZcaC5te9dTzGRrWWBwJe8vNNOHgsx35+ZsZ7WKp8y4hsYP/AAJUpcJ8uI6p qQ02Otrqp30jBZE0h3TbQkaqn/sg7BzI3V1YnHdvAqGRt7GhKkxbyp0dXh5FSBQHjnX8lrgl ZvI7HhmBNwypjg5v5/gLEzeE+904yNbaFKO9ipQxR0HL81KlbZ3xUkMTPfxoKcV03ANeyIGp iZR3alx7h1P4GMjr8wz70yKMMGpOZWohJld7wxpceCHAwMe+UgPe20NGY7VErL2lo4qhklca viie7i4tFT24pNpDkChIByXcng6sjntdEWuAAuOWCTc//Zh/wj2oq/8A2Yf8I9qmtYcJDAwQ sfdI9wApiGivBL80mZQMaRWtxohr5GmrYYgeTR+5AdNwjjb2NHtUqS2Xy0gyOxAJY4NrqaI8 wla54aw1axob3LXdNmY4yf8AhHtQHTjJkbexoSpFPL7DEauDf5AXVPytxHiufuZRJI5wyJXT rN/tRE62j2qaz/RHTSgShMUoj2VWH3mjHUXOxXK27miVrpMg4ErrtG6Aq2KMA50DfeGh97LF KtINegyv44VQJ8znbI5tpuFK19JyUbExlkjHODHPoBXl7clpc6Z4pLGx44Ze7yGKgOlAtbDG G6UHtShi38rZJfdNWtFAnbQNkhdGHNDrwSHGlW09q0Az8Gxt/wCUKrnys94xxGmNbR35pobe IydxIKGM2ADiaVxK5s07JnVsDBXEtz58qrVv5gxgipUvo8uOp09Sjb+Xs3DA5slHcRStD3hA xsmzdS4vNODiSPWrTUmAdC5rmx49NotpTjTikT+VuhYX3tNPQqbFhZdO73WBpA/UTwCgr5gw iXqDFkmLSrbZ0csRhe6wh1zScjhSibEZI2AACRjsS1yj3M+g2vafUtVIfBHG02xBsp+d7vga OPpVYraus+G407FV3UmFrqRxj5G4fj8YJoAaKDJWIZmUp+1FZOwFZ1r2Qxcez80n0ke2LzF7 fuYw40a2hPelyw1kq91WyONCw1zyBTtyZDK61rXD9QBVWslkc25rY2NN1GgYnvKzDciGMQSP LcSyMkLj3XuufxOK7k0bw4SxH3xhTULOak1MDKqifMtwyRjRGagk9mFFm8vcwPdcbS5trcK4 uWsyzEUfGxzODaZdmihr5W4RRti/VTHvKlBHmfuPYw5NYAo2UkIjeyQ0uLcsyBwHpTyZWiyR jZmjInh6c1LXyN/0omRn6qY+KVIR5g15LZS2xpFKaaA6Girsy17HwuIaX0LScqhaR14qmokD via7EJZsOJ24r6fUrUjR0wTR5Ez+EbPhHNx4enxWfzF8bGtijIoKk0Nc01s07f8ATY2No+UA Y9v4CgPmGUcbexoUqTGby60veLg1xYWtrzVfMJWvko01awBo9Cu/fFhIcyOo/Ql/+ztyawdj EDYW37VzWEX3XOFcbQNPH+1ciKQRmjuC6DvM6ggBjbhQlraGmi5MmJrqsy1GO3CatBC1scsm 1xjaeS1Bq80vVHpra5Nqs7ME4FGJVkBOSxujfdcCRy4LoIoCqkTTJ1S0LM6SQn3RhzW8x1KD EAo1cGXH/s19KE20f9uiF0c7JQoKF6XnShQhBKh1CMRXv/IoQqMz4InkAsB9Lv3Jwgj+kd7v apDRWqnqM+odzvYpoiOGNpNGgV5u9qf02/T6/akdWMH4h3O9i1B7QM/WpNrhJjZ9Pr9qo6OP 6R3u9qa+ZlMXDx9iUZI+Lh3O9ib+mM5giPyDvd+5R0IvoHe79yl08QzeO537UNniOTx3O/ar v6mFu28JzYO9/wC5LO2g/wBsd7/3Jz54Rm8dz/2pP3MH+4O5/wC1N/TEs2sFw/jHe/8ActnR j+kd7v3LJHuYS4APFex/7Vs6sf1Dud7FN/VKZBEBQMFO137lUbOEilgx5v8A3K7JoiSA4dzv 2ppkjA+IdzvYmhW3jjAtDQKc3fm5aumz6fX7Vg+4hZJQvFTwo/8AatolYfmHj7E0xbps09ft U2M09ftUdRn1ev2I6jNfX7E0TY3T1+1TY3T1+1R1Ga+v2I6jNfX7E0Vc6NptIxw+rjgMcs1Q TQnL1P5fuHepc2J7riccOH0munHiqCGKlK1GHhb+n9A8VNDBJHhgccMn609GOqOrFSuWedw+ HPu/GSqI42kEOpTIUwxJP04Z0wphRHSjIILrq3Z/qIJ+XUVCKa1zHEgDLk6mGGeSoZoqkHhX g7hWv+U9yGMY114djj4m76a56lS3bskJxONfG/l+s+CB53DAOI7WuGVKnLAYjE4JJljBIoag 0ydnn6cMcEO2zGClSBjwaKg0qPdbyzz5qpjbUm81uu4YYW/TopBKTLEMD6naXd9MaZpjgxoL iMBjxSHQxOqScTx4/Db9Pp7UwhpaWudW7Dv7GhUVMsQFSMMeDvlwNdKc1DnROBBGGRwfrbTn jhgl/bxUpXnkP08LafLpxOqnoxVJJ+I1OH6rvprTtOSCCY3Nsc0OYMq3VFSW8cRiKJIi2oxD HDPi8ZZ8eC0COJpqDjw5e8XUGGRrQ8sFDo4nChNfi/6jU8M9Eosmm3aahlSPqvdxphWvHDBO cY56GQA0pQe8KVNowrTMUyUdKKpIdQnl+q76dfDsQI4x85586OLvp1PCiUWY10TqUGeXxDhX jyCCYw0OpgaU+LjkktiiGbrssxoCB8uOfqTCIy0MDqBtPDL5U1MWHScaACuOvDPjzVC+EcPB +tMNcdFLem03B2OOvzG7TuVDHEQfez7fquyIpnyV0xesWVMcMDcDiaZdqdDLG0YA4k5Nefhp XgcqrMGRD5sqcNCTwbzT/tmPixcSPeNaN+bPNlR6KHwpJWEudG12IxdU4Bx9VdVPUiy50451 DfWR68kp7I5aEuy5Vzp9TTorGGM41occe11+nA5KC7nxtNpGOH1cTQY5CpVBNEcq8OD+NfYU GKMm5xucKYkY4Gv0+g8ksbeJooHUy4D6bfp4g414qhvUjxwOGJwfhhX1elQJojwOmT+fD/lP cljbxD5uFuQ+m3O2uXNS6CN2buNcq8XHi0j5j4IGXxZcdPerldlnl7M1ZtjwHAYHtVGxxtIN cQa5fpt008VdhYxoaDgBTj7EFrG6ev2qLG6ev2qb26+v2Kt7dfX7ERBa3T1pb7QMvWrlw19a xbyUNYcc8FRy5LHEmmfb7VleG6ev2q7ng8Vnc5cmxQaKslKqQqE1KDteXmsQGi6IC4vlsmJZ 6V2wuM+3ePSQqySWCpyV1DmhwocllWZu8DsjVMEpPApDtmwnDAp0cT2YD3lpTPuMKVUCYapY Lq1LUmRrycGof47F/wDTqhZaP0//AJ/+pC6Oa5Qg5qF6XlShQhBKFCEEpb4w7tV0KjC5pa4A 6re44YqpAOak4p7GKR2NFV2KJM1VaZYZkQGoKbK2qXtR7xuOGiBUxWUCpotk4osjTQoJrY8H RdgYhcaTVdTbOuYCgrGbZiNcVscMFjmFrmv9B9K2VqFFcXdk1DuIXZhdc0HULlbttA70Fbtk axN7FPq/G5ChSqiVKqpQWUqqlRVkKqlBZa9txWNSyYxOrw4rM+lhvmaXNwzCw1W1m5jfk4V5 4KzomPxIB5rETTUxbn1UVWw7VpyJHj60p21eMiD4e1auGalnqoqruikbm0+jFJJpgcO1aRaq iqhQqiaqKqFCCaoUKERKFCFQFdV/uQU/SAuWBcQNTRdTeGkdNSFz5N8WOPJXVG5KyolQhQqi UKEIBCFCAQhCoFxvMJKkNXXcaBed3L7nkrHL01xKqlqSVAXJtbIVSgruPBUVD9u4tkBC9JE8 OC4G0jqbuAXVidZ2LlyduEY6KlUa6qYFhS3BDZiOSfbVLdCCmrcfU9amhSZJKlW+3UiEBW5M O/8AChNt/poW3O2Y5qEHNQvW8yUKEIJQoQglChCCUKEIIc0OzSXQfSnoRHMlYW5hZwaFdtJf t435juwVspw5nVWVduTy4O+FxHbj7Fjd5ZKMiCiMci6Gy+BZpdpMMLSVo2TXtqx7SOIqCn1W mVl7SFWF9W45jArQQkW2uPNVGPfClDw4rTsf9Jv44qu4Ze0hW2I/ib6fWp9X42qVCEFkKEIL IUIQWRVQhQWqluzV1VwRSy2qAHN+EkdilSpS2u3dTN417U9vmDh8Te5ZUUWahbdFu+jOdW9o 9lU8SRyYAhy41oVSxTqtuw7bRu+WnZh6kl2yHyuI7cfYue1z2fC4j0pzd5K3Oju0exKmDDHb OQZUd4fjvSHRPbm0+v1VWpvmA+Zvd+Ant3kTuNO1O0pUOVVC7X8co+V3cUp2zjOQp2H8BXsn VykLe7Y/S7vHsolfZyfp7z7FrtCVJe3bdI0aGvcte9ODRzToNuIRq45lY92+6QNHyhYu5bqo VGSlVClbYShQoVEoUIQShQhAIQhAjcPtaSvOONSuxv30bTVcYrly9unH0jkpCA0qwjc44DFY bqSyE6GB0poO9b4PLycZO5dWOFrBRoosTy/jUcf6yxQCNtArlq1lqUWrk6wQ2S3ArS2RZpGp FS3JF9uw14KvcuQ2chPbugrbM8XRuVS5YvuKpbp1bTq61f6aFnv/AKFULbFL9KuNVHS5qyF6 NcMV6XNHS5qyE0xXpc0dLmrITTFelzR0uashNMV6XNHS5qyE0xXpc0dLmrITTFelzR0uashN MV6XNHS5qyE0xXpc0dLmrITTFelzR0uashNMV6PNHR5qyE1MV6PNHR5qyE0xXo80dHmrITTF ejzR0eashNMV6PNHR5qyE1cV6PNHR5qyE0xXoj8BR0B+AroTfKMU+3Cj7capiE0wv7caqPt+ fgmoTTCvt+aj7fmnITTCPtlQ7ZakJpjH9tRXb1WZOPr9a0oWVLG5lbmA7w/Hcmjej5mkdmPs UIUVD97UUjBrqUhkBOLjiVoQrH4k/qvR5o6PNWQtamK9Hmjo81ZCb5RivR5o6PNWQm+UYr0e aOjzVkJpivR5o6PNWQmmFO2rHfEAe0BV+yi+lv8AhCehTfKPPpX2rBwHcj7Vug7k1CefG9/f +qCADL1K3S5qUJ58Z8+o6XNR0eashPPh59V6KjoD8BXQm+UefVOgPwEdAfgK6Fd8pPPqvR5o 6PNWQm+UYbZ/kohKQsq//9k= ------=_NextPart_000_0001_01C68929.B3CF2780 Content-Type: image/gif; name="down.gif" Content-Transfer-Encoding: base64 Content-ID: <004601c66a1a$04432100$0403a8c0@tutu> R0lGODlhMgJtAaIAABoZGdTQyAAnWP8AAP//////+77X8AAAACH5BAAAAAAALAAAAAAyAm0B AAP/aLrc/jDKSau9OOvNufhgKI5kaZ5oqq5s675wLM90bZNdru987//AhiggIBqLyJtyyWw6 n9Co9BSsWq/YbDYUIHi/3wBxSi6bz+h0Wstuu99vkbdArxeIBbV+z+/713CBgoOEFlxzBB91 AAEAjn+QkZKTlCGFl5iZcSUMd2JJJF5PonKJLKSVJ1+po6asNJqxsrM7IgYCtwKJdGJiACao McEgw7quKsUpxaLJS6jJYKrHStBg0yjNry203N3eEJYKH7dzAQZEvyXZK9Uj6+7XysGrZM/x xtj3NO0w79op3wIKnAXiE75bdQLQKWWKmT169oxBTOSwoauJEj+Q8qdx/6LDjh8t0ssIcuMq a/A6kkQp0aIufCOjtZw2zCRMmzNVinSpz8/An0AHFRwHgtw5T+le3uR5kWJTlcScMtWo0+ZH djlDHosWcSM+qBFDiQT7dKnUqmTFlqo6tetJphz1BJ1Ld8unXF4MzEmYJ6XbqF+/8ru51m21 miDRzitLGHBaqCkD4xTs1HHjySGs7YSsFXDYq6zqih7dQwCjoueI9bqTFOVftI/Xwnb9dCRW qoq3MjbpMnazycBpW66IMbJsyZVfz6z8irTz5xlA5cKly45Cx6CzM6esNjdssy3idR7OuDF3 yLI/l0fu+drgqMHNaz+eCrr9++BCPCJHQKEY1v9pKXdVcd+NNx9oyqiFYFgwFdhbYOmVxeB2 AqJnWYC1UaghMRBWgt+HHzKklwF3lHgdfMQ99BBycBUn3Gw9ZabgZovFpGJ5trXEXmI67khZ jQy9xZaLMtX4YH0gJvncIQRYZ6Iv/0QpZRlxTamCkliOJkIBJHpiYolWhikmNTGOCVCWaAbF RS9stjmGmXDGKWcUadY5EBemjZDOaXP26eefMAgyjhC4PDCoA+FoMQIDi3ZwaHS2aALopJRW OgMQjSJaKKObEirBo1eAuoCojnZ6AamZuKnqqqy26uqrsMYq66y01mrrrbjmquuuvOZaBaqf mjqqsJyygSqwGiAbgbL/hBzhLBLPRgvttNJWS+211maL7bbadsvtt96GC+644pZL7rnmpovu ub8SO12nOIiTabGEolZBpPLiG2++h1qC2r4TAKxvUfYGodnBCCes8MIMN+zwwxBHLPHEFFds 8cUYZ2xxu8Fqml/H9OZy76agHitsv/AOivIGoq48bKHMctBfrzTXbPPNOOes884888rxsie7 i+yjJbs7rKdHG2pq0Ul7nOzSUDeNxcw9V2311VhnrfXWsP4sDtIhg600pwArLbDQUYdsMstp Nx3zDjN7wfXcdNdt9912e32L2PJ+DHTYhhjd99iAu+w0pHwbPrUY/RWB9+OQRy755K3q3bbb /2ofPvjmf0u9NthEoz3qqUF7LrgPcVOu+uqst241ppy8m+i7moae6bzBJrrv2faWTfvI+Mr+ 8uwGM26ErYzwnLzrzNe8/M7PN8+qndR7kzqsjmTfyPa6Zq99m4wkH32s0YcPvfe7io+z999j n2v5q44vvZvV1z9L6o63Kr/8tPLfy/P+0x/4ehZAXBWwe7U6oADZxD8FNs9+EMzE9V4FP/G1 T1b7Q1/4Lki+//nCF99bngj756YQerARJjQf+lDoiP+1EHnga98KLejAE55whtvj4PwiyENC 4I+CAzSfDTs4QA+qD4YfzCEDucfEGiZRVUJUohGPOEIjInCIUVSiE/+XuEQA5rCK8xNDD8cI hwm6in1a5CIG0ejFIybwhkzkngrjSL4VwtGNUpQjFun4xj22kY91ZGMX47hFyJHxkGz44RmD yEIdLrKIH8QjCUfIPvXNkYQxfKEQ/5hEEaIRhQZUYx6l+MJZVVCQXgyjGBHJSiuYcYFWLKQo n0jKUFISimnEpA0tScsoutF/siTkIK04RPcN85iAZF4rlwkERcIyksI0ZQldqMdb+TKaTUTi LrdJzGpiM5lA9CMyt1jBQaZSlcxMJw9eyapyNjKBn9SeL4OZSjtms48MlGE+NblLGtIwlPv0 JD8d+cgbptCeYQxIwQinpoWKDD/OVKVEJ8r/tWBKTiDKehstWnY6urAzfp/kVSUt2s6RZq2S kBspSdeIUop2TaEd1VLpIGq8/Ln0pjjNqc4wSp2icbSnp/OX7Xz6L5VxlGzEw903PqrTpjr1 qbLiKcxmmjSH5meqmzOcVqkqNbfFVBMzgxZUx0rWsvaCp4VLGeA6l1Z+He6ofHPrXKhm1rra talo7Wro1uo3pA6sYIrjnGCH91Ww3vWwiKVoXgW7166y1bFm86rmBlsvoDROXZhdV2Y3q9nO cvazng0taEcr2tKaA6ZYTdxUv0qqxm41X5N96N6yejlZaOy2uM2tbnfL29769re3Re10/No7 onS0bLcL3nCLOq/Z/ylVo2VUnWmnS9rqUve61s0uXe9WJ+iqUwfbTalKx0ve8pr3vOhNr3rX y972uve96e1C5Lpb2O+Cl3HhpZtpgMvf/vr3vwqjVRHySzcsKde+V4io3ZYD4AY7+MEY64LD tkfguSH4whdgKt0AAOEOe/jDE65wm0wj31mReKcYTrEEFBzOWb6vwxwGsYxnLDcRj7jEsyrA Siun4h47QMPAnCav9gvhGFvMyDROMsVwDEQb35iWNfOxlBfA4iy6eMe9YLB/kUwxLiv5yyHG IJNbJYCEQBmhtJrylJmaxXhqUI4y1GQp/8cwI9uZAHf2AofzjGdrxDh7eu4znh2hZ0APmv/Q fja09wpNaEODucFjZhWJnfwfT2QZjOB8lZqlXOV7QnOKvfwm+Or8hTvzec+lTjUYuLznP6/6 1YL2s6xTfeqIeeLRFou0pHXNpjJnWY0NJKiq4EA853i3VLULWH2baTwhe3OU1+xmMom8MFSj OtDWpnWfvczqWCP524HWTLe1He5YM8wTA5AwrieGY5MukdLvPDGUQ/1SH/hOttA5tgeIldFl /0DBVeTkpxspZ2q6Scuyzja2t63ta8N60d/+M/vKDWtVL7zcXraGpQOQ7gGsu2JMDqkHKS1C eT9Rni5eVRACi+8l+XvfDOXGR+M5Tk87m48ZFzfDTc3whTuc3D3/f3XGhz7ri3v7YBsfQMfV /XF2b1eHkyazjvN5c2jHauUk4yq/oLbQ5hYbaMUFKmGJmnXjHtfrw0Vq7azag4i6E5SetPk5 ce4wPmO86OAO+s+NLui8j9vodqea0gfvpqY7veq/dvLci9nmq8POsUyjrGxfK3nQlZ1zrc06 2SrP16JOluWoa/Ys/0l6QoZQzuOjdrUtfveK+53RDnf0okvtatjb/ugU78/gCb/7dPfC8A/j NS5FXAQFCjzTbMI65NXa+bLXtt9IUxxcJYu4t2r968yWr00XDPwP38H3CtH90vHb/YMJf5qK DyTqa4j1rw/1r4DVXezA3ijpB213/s78//LX/vIMi/6MLbU+5QdiHFeAX/B9BdgmA9gf8BZ1 +mNyPKN8IFN5oOd51cdQjcVXkKVsGKh1m+dKNZVSC0iABqgZHXeC5Nd053djijdnOyOBj4Vv RgVbtGU6FOBamoc5mJeDGNAv1NdWnHdfK6g1qjeCEFaCDJOAKQhmQzhy8/UDuDN/Xid2ssN1 bMd/qwVUKUN2WXiFZuN8vxM7SvVvIfg4CGeE/1UAHjdhBZhu61YujABvV7NpPkY122c3OYeG KsgmYPYL6tWEWEOHPSaHWXOHiVU3u5dThFg1gqhii3g1ehiJYcCHaPiEjXhhl4Vdmphdm9iJ nJguADB4p/GJnv9Yipt1iRgmiar4cWq4hKsIYKiIiYc4izSjdLRoM7GIYI94i7zYJrbYi7qS i/a1i8BYjL9YjLUijN+ViaTYjKb4jM7YjBwHjdQYjdSijOp0aPC1jdzYjd74jeAYjiMliuJY juboXpdgVV7YQ8WGfYPwivAIfAlYAPHYW5jwOeqEjxJUj/z4aK24hv2IW/coOt+lj5gQkAip ZBx3BwmZMVigXASzhQ8lVFvIhcR1g7yDMlSYdvGnjgQpV/KXYA05kh8mBr5HkhTTBi5TXDRI gzNYgzDZch9jXB2YWpP3kRsYeTsokijZkw5mkvTokw+jkjY5kcw3WJHXjuvoKTRpfT//aJAy iZRFqQVCWZX/xXHg54pWmRehEik4GDY/lVxd545M2VNj95Q8WIWxJZVB2ExbyY8bx3S3FZe+ 2IbjVzWG15VVxXwZKJMx45ExRZMveZNo+YM5yW9ROTVv2XR06SoomJW1iJWS+YtqCAYmOZmP mZmYuZm22Jm14mB6mXZGmYPxF3ODSXkc2JRGxYMr2ZoeSFlKyZOL6X2topmdiYLqZpecaZu8 KZc0hoC3uZtKWHj22JUbGZGXh5xJBX/vF5iCuZrLpZwvI5rIuXXMBZH81n8VMJsO1pi8h4Lc yVuXGZyQ6ZsVg40wFQjh6VveuZnrSZuPSYnniZ7doG9w8564/2Vp32me+KmQusmfDEOfG0WW rtSfFpN0SGigI6iEESOgraSgEIOgtgihqzh+Q+mgiEShC6OfCaih9fh9kJkwGJqhHqoZ6OaG JZqQvUB4CDOih5SiB3iZDZMZi7l7/KV0DwairuiiZASj6MZxEHOGCCOkKWJ4OApcR5qjLAoG PDpGJfqjE3MetlETQyojuMEhPaJlNtp7OMqlHmejCpOkXgCmBDB4ZQqQvfcFZJqmC8OmZ9ql XtowrWgNTdpDHiqjFJMRQvIWUqEwWTEgyVGkY/qlZ1qoX3qoZVqobQqQ1pCkZrqGRxqpkIqm jJowjjqomAqnirqhlZolvScLSlc/d/+KohGzFHqqIkTap50hJDRqgoSqqYjapZtqqZXqpmL6 pozKpWpaqQhzqYoKq4iahJ2KJZ8aC6FaPR5amVFaEafKFYKqGcvxEnxqFrS6qZqaqbx6MGIq qbuqrWY6q93KMLf6q7EarAuzhHVyrJqgrnaiobe2rGdhFczKp9A6rc1Krb1qrtdqqLXKq9s6 qeEartw6pgILBv+qppjKrworrHSqBbu3AF46ABDrpRPLrhNgsRXLrg87eA7ApQxQrAoQsRjw qRKbsSVrAB7LsW6goUBaMSXREFeaEy8LrSWRpTZbrY6qr+aasLgKprpqq2SKq416q0T7rYMK p+WarRpHqgT/wAYPG7IUC7UeK7UnSwEYi7JTi7VRq7Ugu7UiawFfy7UqG7Eqm0gU2rLApyMw Kp5o27ROW7JwG7chC7V0i7J1C7ZVCwEWO7Ynq7Fy+7FVe7UX67dSW7F1e6yCWwUsC6BKRqMo sra39Xtc6bBwe7iVi7WHe7cVILhZq7mAi7FkC7gasLd/O7GW67mKCaFtC7nhuZCTmwWhyrGI K7GyK7e1O7J5S7Vli7om27dhi7kZkLike7rAa7YQOqesu54m+bqwG7t+S7vPq7XBm7tlO7yD O7uDO7q5a7qiC7zY2waLq7TJa5Ut6wa1G7jOi77QS72cy76G270di76Fy713S7p5/7u7diu9 8/u9iWswizu+yguk5uu78Eu4qIu/YRu6Yru7Cby1C3y/oOu1U7ux6Qu+LKu0qfowLzuzusXB ufW4/eXBkOZxA0y/xWvAxfu+vfu866u7DAyyvRu/V4u/LtwAXXu++kuV7iq+H1yvwJXBLuth QPxbjFOnPDSqNLsSIoyq0uoVXkESN2skrlGzPLITSZwjVaoUO4ITVswVVcwjknEhNgKzLSHA RgxBd7q6xDEktBGoMEIjWhGoqlokcrwSfjqtDHOqemyvC8MWNbuncWyqHlEOJHzG9lOiatyn zXowjgvI8SoT8IEiIOysZxHJeYzHl1zH8/qslLzIjyytUP+MxUVqgIZ8yGnsm2rLyXscyPQ6 x5Tcyp28ya7cxp48pI+syZyMyaq6x03srAw2E9/HvKWcJog8rqk8y5/syJ4crcqcMKt8y86s y318r4CKzLr8p8nRxM/8yronYcOMrIhMfnKApQhHHx1CE4vRqq2axFRMzkscyevMyCzRI2Q8 yeh8z5Jcye18zpLrtt9cJzDqugDcxx/atv/crmt7kgPNzvAYzEx60MS8tq3IuAutilD60BCd Jck7nP1c0ZGoo5qR0Wgyvv+4dOUpnx6dZHQ5oQcj0hqd0ivKmaqS0gDmneCpMC6NJTR9rjJN nDtNMY2pmyx9oTkNIj8dMSapmcj/SDfkqdAbU9RGfdQXc6LC2dRV3ZtWndVYvdVX3dVa7dWa 6VtQHdVSXdaSONYfYtZqrYdoDVFr/dYD2Nb3Add0DXxybR91ndfrdtd83dd+/deAHdiCPdiE XdiGfdiIndiKvdg+0L+M/diQPb1P69gXQNlY0L45YNmXvb0boNkr9ytCEAvaCdoswyhqYicR 3AOeXQWrjbuX0NoRANulQdqjIymy0H/wctr5xnapTbXcq66THdztC9zVW7qfi73OS7xcK8Oz O8NP69vE29vLrdzPTdyrvZG/szf11zsiQ5GG8jWzFd7Y537UOZpZKFfoHQ5g+DUdSTKIUtuz pYXUIZqm/w3e2Z3b2r009K07VTjf7T069gk7X9fb/Gvc1G3gKey9f0vgcXu7Cq7c9Pu93Vvg 0e2+D37hFJ7ggVPb+O2D9h3f7m3fJwPeMAPf4Q0Ob5VV9R3iJP7eoX3iNomYJy7iHP7hHl7f 8b3iK56dJs7hLD55Nt6WbjCGE7zgRm6y9Yvg1mvd25vhFQ7hSX7AR47hSj7lGe7ka+fiLV7j 8N3hOP7jWz7fJh5UWp7jY07jXI7jaW7mH77mAK7da47fof3jJe7mZ+7icg7jQT7j6XhgGt7c xU3cB/7cnxvDJjzhxs3khl7AVW65wZ2/0Bu/NQzdC5zknL0sO67eX67jXd7jZv9ukfxX5nW+ 586nkR/I5qhe6m3O3nC+5Xs+53fu5d/d5Zp+5yTulbft5wz+ANU95RrO6wg+3Tbs6ydc3BIg 6H9O7O9Lwxc+7MgOv7yL6Xau56S+6ate52K+6i9+7Zxe7dqu5mHe7amu7f4t3q/O561O7bIu 6t5+7qMO7gOJKrs+t5Tu5MAd26Wr7FTO6M9u4c3+2/luws5dvxkb4Z573eL+7nT+6mD+6WjO 7Z6+7upu6xHv6uM+8bOO8eeu5uuuMige5+6e8A//DUVe8NAutsvO7ITe67xbrCic4IRe6MKO 6CavuQNP6Qdv7DMPPENF8fzd6RA/6usd6vVy4+mtdun/zd1HT+v/8vHUvlzw3ubORRTfHjy4 vnly/vPoHtmHNNp14fX2A/bbzvUQLfa6nWJmH/Vkv/Zs3/Zu//bDXFjYXub1E+DSvgUZD/eD rfU3aPHfniZpP/ahMtt6X/biHjB+v/WAbwWBf/c60PiFv2mI+d8vPuJLL97qyPQLn99z3vMP b4WXn+PtnZ0ayeKk7/FUb+7orfiR36Q8bvH6zecKj+Z5TvsiH5Ue3vEV3+4gDvKCr/GWf+tp Pvt/3/qur/SwX/l4vumbD+u8/+4cz/BwLuMaf/G1L/vMn/fEn+5Zb/wiTfxRGPTZb53fvfkS H/1qyerZbu3JX/2kf5ae/vxv/07+xe/9dQr+nyL+nd7w740AYqtr3Zh0NL5JpdoZW1hh1yh2 YHdZzidGXLmi8kzX9o3n+s73/g8MCofEmJFFSo5Uy5CxJUNOXCeTU0pieq6rapOhPXJhVOgz GS6q1+y2+w2Py3OCusv5sFuVWT0eXDejYvcR6PVHFYgXVqgI+OVhaOIHeAeT94I1SMk35/kJ Gio6SlpalGaaqrrK2ur6Chtriipba3uLm6u7y9vr+wscLDxMXGx8jJysvMzc7PwMHW08MBBE rXq9Rl3Nk83rXQMuDe1Ix0wbKi6esU7R7s6dHv/+Q29jL4vvoD+KnuEvC6C5HgJ7WTK1bR+/ GQtFNf/s8ZBdvGURPRXspOuiDY2Xih18Q0hGwgUjDWybx+1kypMkS2ZTKdJltZclTSaE6Y1l y5o6FY7seU0dypw9bcokalMiT5lJiYKDuXPiRkwVKG0oFxKTJEVZCUHg9CTRRxDlUmC1qlXP 1UZ3znJFW3ZtVUdIrlZCkdUsI7hu6cbxqmXmzKQSWxom3I7m4XWKjQZdedgkYcSQKUfugJRy TcucG3teufnzYpaiO0vF4RcNGDGsV+M1Q6Y1pCVaUv9zjcZS3dpnvuLVPWbKxz3Cz5hJLYWj DsAoBEt2Wrpx1MrSFY6Gdx179uinrW/vbvq7+MmFw5Pnnv13WdXs6wbHOBv/S4yxx6P8ka2p /mv9xOPzh9/efQHiZxwbzGE2HnqTKcgYVE85KFVmChrVHErplccgdRDGNJpODyY41A67dXWF V7BV4sWBt9E3YH9ipYgIioeE9V6MLc5GlYsnyvjfcAaaiKB5GXo3oXfaXYakhBomeZqSSBK5 pJBNglfakVIyuVyN//Vmo3yvsejeflO8l18njHCJUZhjyiagmnzwRmBHauTFDmZRTjhkeZKd N09kzoGIpZ5VYnhnofs8Od6eH15p5VRxugkjmmXq2BpX9j1q45qa3ralpMFZKqanBUIaiStT +oQnTT9FqZSF8Dzo1IJMadYdrK7aiSqUqA51a6sT/wH1K6+vqgqeIHTmlRwnav2D7FvrGXes JGlG68cmL0RiG6d3dZSsW/GB1UW2taEVlrQAjoNuHBUhCotyqrh7abryzksvDUXtsK4o8Jay b6j1/gtwwAIPTHDBBh+McMIKx5KvvcXq0FDD+D7cjxD9snbxLhnTC2fAKlEsMYdC2JOZHCH/ oOIQqBQ0yI/gqrzwGh37sLGpvfZCMsVunEwzSDSwrO0pAloc85z+8lDzJ3QeCZ2RwL7zdK5S V+khacJOV6Gfs4pW3b2OMhtuI/x1RfazJxy0dNihijUfB8qqVXZbLesVBV9sta1Vjtuyl/ck 1S5iN4p6mUutj7ik7PSpnP/pSqiRjD/H6uN5apenqhQO+nXQld4YZ2xfsCgIpbt1wSZ8vu2R 7XHAHYE2pqV3OfTp/t0447mxID5dsKsG2qDWu/JemWPBT8545YaSt3fYqW/K+aZens33uUyQ Gv2MadQ+O+yub+F8p9pfEin1bhZ4OJCFLSrdUZsJ7yrmxhcfudSMZuj1z/ECObem+M8F7tnW vmw+5YkKNuQSYJp2lJbwkYlGtAvX2ghIou3RplleKl/aFue+4GUNV+aBX6KIJ7/3dVBElxpf mKgXuiZUMFPkQ+GbToS9SMVugXxbXfc018Aciq8GhrNgGJy0uPQobk+MghygZHXEVnlwfsPL 0n7/1HQtULlwemsCHZpm2LkXVo9bCNxh52wIifVQ0TVl0CENn/cM9FUtKsOKyaKEF8I1Ym0n sgIiB+P4uw7W72fme5EDH1GFPjoLToFUm3rEWDdxlchbaeFi9AxZwwJmoVze+sqzqJKIPvyN kprUJNvIV7Qb8CyUoCSlKXF4yl+sL5UiShorOfbKWMpylrSspS1victc6nKXvOylL++hs29o EGfBBMUq5zDKVyFvma1IZj2KCQTsKU1oE2uUnopRHWLaDCHQxEHJHPcKZzLTYXLoFzrOSU2I BYucxxAnKdwJBHjmQJz4kOcQ6NnNcRotCOjkYTohec2mdSgxw1OfdYiF/yuE4pFWV7MTQZcC xIcKdI6PYaP8lAhHjDpmiROVaBxXdRNeNRQqFt1ohaCjO4+WFEIhpRU47TdI/mGMgtOLm+D6 ZqbAGVB5gVknEzmYzc+01I0VXWYGL3RHjh6Pcscj1p8wN0JwipCpd3zqUkWYviACdalO+ynW oGqsK45hjGgcIOr8mYcsJvCkGyriEt+qTzXmsWvtq5XXsKq4qbo1UY1K39ZE+iShJBGvwGNr U4d4xG+CNV6PrKK2yuo95p1VrbjjU+74KkSUDnOVtpqc+npnVA2tMSWhHWiRPnbZxo3zsz5N LGK9KiU5BpWkSkUq8jzr02zitAWC3KQmAgjDEv/sz2+guiFPN2hbqM42sHZNKmip1toNPneY dKTQVpl7IdCKTLdUdWhdMXvbw9ZWtYJliHhL213opheaFTwhtNDaIy15kQwvs+yCwLvc+zJT u/oFYU6uS94+XYagQuTrf/W7XnYemLCCgi2ePojg8er2v7hNMGq+9znPaTiHkp3vJdmpNSUd k6UpdVz9hNLZ7xjUsAA26YCp9LSUbhaiMP7mRYEVYpQiKsZv1fFKCzpRX2WWsyvGYFEXeoP/ 8Q96jUzeXJJXrQgya5PYsp0a7PlLLP9yywXTsi73yOUwi3nMZC6zmc+M5jRzGV6uzAh8kcbP aF6YICTsD8JmRowPoyz/GWy23zneXE599YzOpbwdv4YGjDZbmRd9TuEyaKFoxlpk0HAudLsO bWlGuyHSc0CW3nDqadXgD4CfDvUk92aXKcuNLeOyiqsNgZxSR3lZqP60GEj9tr6M8dRr2YrZ KAmmtIYg16sOiVwgmerH3trYtuYeqLkQF1nbxkc2rQ+xOQ0K2VlvrDSk7/bAKLsUxnpUZ2Sg tp94RmrjpqYS3PXqCkHuG45uEi1cd1UedT1z8zbes5s32OTNQGXjW63BUGDQmGxcLRrXbaeW LLoJ7mGMYXG+WoRsv2fI8ITzJtiva2z2zAjTFGRx42aNYbcZfqb4cvgXw62yfiAFXA6j/Lim /5Pyx1Xeuuy1/OLxtrglqWwmkYMb4yV3JLaKu8W1Sk/oI/9S0Q/IOk9nPG8cB3ima+FCq2dd dItgOvgYa/ANh/3d5W73ZMX+9XpPXYZBrzqOnj6pty997cG1gttN3vGZi4nibDdIt11Xxrir 3NnNwznpHjt2iZt95Qk3PG4ErnGwfwrvVq87FO/395SPjfIf72HDwzh2bP8lbp+sNSD/eMEA Lm04piauDGk9ZU8GHOGezGTpy/q8wj1Z893yuBKoJfcm39RakZw25jm5QiU7kPOlJ/zBc61z c+lS9Gqu2D6t3+nq/1n7x3Al9Y/mM+6Lf/zkL7/5z4/+XCrn+4gO9P8p2J/++KMZ/u2vdEDk j/9Z0v/qc75//v8PM8TWNmgDQL5FU4m0akt2SMj2RZKkAX0xgLMmN1QHgQ8oNlAGgBkYTUMn bBnmaD1Xf7QBcVzXeB3GgcbHOrP3RDZ0LZ+ngS/YfzznWB8oXGL1cCW4a5NkRaXDd0/ngpVH QDAohDH4c0gXSJckSazWakaIQHqTMpOyc6pjc3c3e1MoXH00hFnoZw43PgBSSCHYg+JmH1So cHKXHCe3ePmDSlqohWGYg5OVg3G4eX52eX3QKWEoc2k4HyHIhlmoekkoHGZDLr21F0Bne8Ql U84Ge1EofM/WG4CoiFb4CBjYh5W4aNNniZn/qAz7JzCcqImfCIqhKIqjSIqlaIqniIqpqIqr yIqt6IqvCIuxKIuzSIvGUAC3iIu5qIu7yIu96Iu/CIzBKIzDSIzFaIzHiIzJqIzLyIzN6IzP CI3RKI3TSI3VmIw2YI3ZqI3byI3d6I3fCI7hKI7jSI7kOAPliI7pqI7ryI7t6I7vCI/rmAG8 uGW6CDD2eAz42Av6iH67OI+5GGb8OC8COQwEmQsGaX766I9chpDj0JC/8JC1EJHit5ATeUsW 6QwYqQsa6QocqWb2uJAMCZD/4pG3UJKrcJJnFoxilpJtoGdu0JIy0y8xWQo0OWYrGZAjSTMx 9291IwoeWVk7KQQl/xltoGCTLAmMSqOGzxCTdLEyT/mTOokaZWQxMymVU7lCb3CUOfmLSpmV ytCUVEl62/KHFfgDQCmW10ZG2uZqHdgBRNmBt3c6L0kDWymSXTlp09aWb5GIthCWh3dvcTmB wsaXbgkEaHl4hamYc8lujfiPuAhnyMGYa3mWV5l+OJl9y+MsmDSZfmmZy5GWUQaYlEmY4XaY n8lHzUKai7luZIONqEmH/rOapqkDdlmPSTlphGlArFmaJgmbSSZIpGmYi0lBQ/mbv+GWB8Kb y0mbb3mce5cJk0kW7mKbv4SZ7pdWncmcF9SRz8lHyNmbjxeeH0aXNYCYgklv46mdzfmYt/9o f9JSmDlSXzhQnb50nX9BOus5m7vwl+kZn37Bm7+3L+cZniKonvtpmCgAl6jHloHpA/XZS/cJ BxfInMLpiTnQn67HoAF6gEFAoKWpa7vpRwnqnJBZZ4AZLQ7aAxDKSxIafijqmgXKnd1povXC oukJBzeao97JfS7aojzaDDq6W1oJpDTqnvnno7skpLiwpEZZpK3QpLaUpLoUpRL5pL5Zo7xQ pbQkjFx5pDZ6pZ6ZpfwZpmY2jF5aAPdYprKwpUXQprFUjLc5pvLypjs6pwe5pkgZj3vKp33q p38KqIEqqINKqIVqqIeKqImqqIvKqI3qqI8KqZEqqZNKqZVqqZf/iqmZqqmbyqmd6qmfCqqh KqqjSqqlaqqniqqpqqqryqqMKgCHOgCtKqvS6BW3WAfHSAjUaAePequ4uKvM2Ku++KvumKsF UKu2Gqy9OKzHKo0qoYvUkIsnEYzSiovOyqeAoY3JmouviozcSqjByq3aSozi+ozkaqjFaqyv aq7j6q3C2q7r2Kvhiqzzuq63Gq/vGo3QeouxWq36WgD66q+8CLD8+q8E66feiq/TmLCdqq3M iq7omq7uqq4Iu6zFaq/hWrHpOrHrSo7gOrG8uKsee68V+6sPS7IcC43meq8Rq6wfq7ELy4wB G63+OrC/WLP7ug1/qq6+6rIau60oa7Es/+uz9IqxQpuxyXqx7TisQsuySWu0MOuzDduzGCuu SRuyRau0FMu0P9uz88q04Eq0TeuyKFuuS+u1TguyY+u1+Uqt+1qw/YqzNsuvNBu3fbq0SOur tpq3yrq38bqtP6u3Tfu3PBu4WJu1WsuzuYqta5u2Z6u4+Hq3j0u0EKuOHru1hCu2JduuVfux 2Eq52xi5XAu1lEu2yUitc2uw1uqLqgu3dmusg5u4I8uxy7q3gWu78mq7r1u7uKu777iymAu8 gOuuYRuxnPu7Tou2vqu1Klu0x7u5kNu5Cfu52Yi00BuMUjuNBDuwbdu602qwdXutu/iukGuM vLu5sGu+sNu76f/Ljojrt2ALtowrvlbbvAgbtit7sVNLrMu7sFcrtmdrtPdrv7+brYyLvcG7 toYLjdr7vTL7tjMrsNrbvXtKvuqbu8Lat7Xbu+t7u+prvxzcvhB7srGLrNNbvBT7uCM7uf4r u4eruTCLtos7wlGbv1Rbus5Iuiisi9U7vjdsjKxrrdwLvgUrs0IMj5E7wy8rsVRLwy+Mwk+8 sUNrwpjqw8tYxYB6xecKq7NaueLbjFBbqcxKq2a7qGIcqWDMp9/LxeGIxMlIxmsMx3Esx3NM x3Vsx3eMx3msx3vMx33sx38MyIEsyINMyIVsyIeMyGMMGGacyI3syI98wZAsyZMsyGj/TMmX jMlybMmZzMmdrKqb7MmhLMqgCsqjbMqnbKmljMqrfKmq3I5qjKiu3MkO+8SHe6gnK8vCK7FH HLqJy7XAiMvNqLrca8S7SMzFXK6s3LIaPL/7e65jm8vNDMzRbI1+q8TEm7w7DM3PSLcPfLMO DMEPLM7VrMyNK7ra7MtXq8Lk6r8lDMXYfLQ13LHQzLxT68TvfM35zMi6Kr38S7yN28Ixq8bf jLpyC77InMzlPL89jM6Ei7xM3L/ZHMPu3Mz5+7/laM31vLUEHMAn/L8cXc1my7n/XNG4m8XP 2rYEPcTGXNBuO860qtBp+7wNLcAWC8bO286/HLvbvLjjONLm/yy7CjzSNSzP39jLwTvF+Sy/ ppuzONvURAzOM/vUEwzTMW3OGz2+uvvTw+vRXX3OH12/ldvPy9zVHD3UXUvC3li9uszWZI3A x8jALC3XwujAUY3DVr27iIvAmtu3N02//xzW+BvF8cvGWX25JVzWWKu/Hg2/CkzOX6vXbL3V jg3XVF3XDQzL3fzS0UjNlHysnkvLtfyyMGzPKczEJyy5AS2OoT28IvvCaa3O17zP/OzaRI3Y ki21nQ3VDBywRtzbUw3V1IvXIcyNJ521rbzFjarbw43DSW3Fbyyos63cye2qzG3d132wwtjT 1aiyblzY2A3enrrJHyzcirrc4Y3egf863utb2jq9xHorsg4d1rft1fWtzfNNr+mt36k8jEcN wuTtxYXLuxuc0QM+01q91LsLwFp93vvt4L7b3wR+30H9i7Sbu+dbuBqM4QgeyV/9wQD+4CFu 3hG+wyVu4uPawRqewReOvikOsivO4Rss4jOuxdod4Mws43yb4Syu4CDM4zEOwzDOvjRO5N+q 3Tzs2mkt0xBt2/oczLGt1Atdq/dc5FWu3rd848rY4FbO5Tr7zM+by9Dd5WPOq2Ru5kS+5Weu 5jgeqLCM5cw9258r5m5s3NEN5l/s12letmvty32+y+6s20Cc2akL3BH824XerXAO4jTd1s0d xpZb5wnO6PD/atLxTNLoDNLK2M2+TbMt3Ys3u9lWTME6q+fsKuW4fdg5bbJ8rdoW7dzpaM+p HsNUDugUbeujXdxjDc+HDc+RvtJUTcSta9fezNtujqt4XOr9zdBPK98RjdYTHeWM/dDhC+nO jtUG/OHRu+ugK9J3fumAW+ACDdxFLM6gHsEH/euJTueKrcOA/dpfPbQyTeCC7bh+3uHdSNSG a7m8jtPZHO+4Ltiv3rEJjNaYS+GQXdKjvbHJ/ucE/7Sz2+3OeMzROsSsa+iXfdfqzuHkHdkA vuFD7sU7+98mLeQWbNTzve8XLc3TbrzsDtakbtP8jvJCbb3+Hu3Ue+D2TbYHrOkT/3zohT7s 4Sz0ot6tJiu6IN6/973TGCzysl3yt57jaj3zwGvR8s7y2Z7YqN3R1+rPVr/Nghu/fw3flK2r 2C7fqE7TZF+McQ3sm13Eg16tbX/sGi/ZL27y9z7gTA/kKf7hKj7PSa7wkwvQULzwt53vie3r uR7fy1zbpy3brk7r3N749B3x9v7vTP3UH9OvTc3pUo3ZQY/idL/jUW/YEt7jlryz7Nv3gvvj vMrwjX7Gr9++1F3GWt7OgM/ata7UJrzIgA7lD63Oib+/c/7cwn+wAh/LtD/ia8786S37zQ/9 h/z80U/9lVz91x/T04/925/H2s/930/H3g/+47/G4p/lpv9+5Ndr/uTP/nY/qKCM+u0v/z7t 09UO7+zt8O2e3/PP/whQutz+cIlIq2VT5i2xV1whhCIIZleqrmzrvnAsz3Rt33iu7xXKUz4U qRHslEyi0Qh5/Dmf0Kh0Sk35qrIBlnelFpFdZpM0ZIa3LOUyuY60NeiHMg5cq8+qt1xP17Tn J4BsPX9qMwOIiAyKi4mNjBSJWguSkzJ4UF9HQh9gZGJmfTBLhYSiFnyib6kurBiYW3YnSbOv tBCkG7AqkJOSjQqMwpYPw5TEM7s7d4OAgsyzdoZsQtOnK7lwfrrOz9Nzd9avE4Xl0rfWueSC N3ri47fUgebc1fSZV9ny0Xj67y7/kBoENFaAIASDv2gou8bwmr54tiDW4keRlMRAEh/Wc5AN nK4c6SYSeVhrFSda/taJ5MKuZEmVuGB+jFFJIDGCBov5srRTYcOfQEeaHHdupK1zHS+iqwcT 3jaZ6/4la7pSm7RuEY9G9ehq2VCj8+q4W1ghYTBkNc86imT2mM+gcBvyKbWUYxCoKMkpRfpx Lta8FFlmPMP3ZVY4JLdNoQtWW53GL3jeRObWZoqAZ9/G3dzHr9WZ1bRW1JvKY90/o0c3JZtH ZlWMKV2iBoy6qBPQ+UR+zToThmRgDjAXREt5OKXKlzgrR5MOWjiM1NQNim6xJeB56rjxM5Sy awx21hHb3es2HnZ27FGae7MHuWV4FmmHJ2zbNvMxzPVHLd/PfzHrUf/5198LAV5T3IBGIKjg gt9JpdB7qjjIIBELHqhggRNmqOGGHHboYTIfhijiiCSW+CGGJqao4oostvidizDGKOOMLIZj I4o05qjjjjz26OOPQAYp5JBEFmnkkUjyZ0CSTDbp5JAGLPnklFRW2WKUUlqp5ZZcMohlll2G KeaYDX0ZJZlopqnmE2Z+ueabcMbZQpttymnnnXbSqeeefPbp55+ABirooIQWauihiCaq6KKM Nuroo5BGKumkjyYAADs= ------=_NextPart_000_0001_01C68929.B3CF2780-- From owner-namedroppers@ops.ietf.org Tue Jun 06 10:59:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnd26-00037z-7z for dnsext-archive@lists.ietf.org; Tue, 06 Jun 2006 10:59:50 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnbde-0008Ro-2O for dnsext-archive@lists.ietf.org; Tue, 06 Jun 2006 09:30:30 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FnbUY-0003Og-IT for dnsext-archive@lists.ietf.org; Tue, 06 Jun 2006 09:21:08 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FnbPs-000D2S-4n for namedroppers-data@psg.com; Tue, 06 Jun 2006 13:16:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FnbPr-000D27-6i for namedroppers@ops.ietf.org; Tue, 06 Jun 2006 13:16:15 +0000 Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k56DG84f031778 for ; Tue, 6 Jun 2006 09:16:09 -0400 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.13.6/8.13.6) with SMTP id k56DFIHl012613 for ; Tue, 6 Jun 2006 09:15:21 -0400 (EDT) From: "Scott Rose" To: Subject: RE: NSEC3 Issue 19: NSEC3 processing order Date: Tue, 6 Jun 2006 09:15:21 -0400 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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Importance: Normal X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.0 (--) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Roy Arends > > > > Issue: Should the document specify a recommendation about if a > validating > > resolver should process first > > the range of NSEC3 names covers query name > > or the signature on the NSEC3 records is valid > > > > Discussion: RFC4035 specifies/recommends that validating resolver first > > check that the name range applies before validating the signature, as > that > > is the less expensive operation. For a NSEC3 with high iteration count > it > > is possible that validating the signature is less expensive than > checking > > the name range. > > > > > > Resolution: > > None at this point > > I think it is fine to have the draft include a note on this specific > implementation recommendation, absent of any MUST or SHOULD. > I agree - just mention the trade-off but give no implementation constraint. Scott > Regards, > > Roy > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 06 11:30:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FndW4-0000tO-Hl for dnsext-archive@lists.ietf.org; Tue, 06 Jun 2006 11:30:48 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FndW3-0007E2-7f for dnsext-archive@lists.ietf.org; Tue, 06 Jun 2006 11:30:48 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FndRm-000Oqn-NE for namedroppers-data@psg.com; Tue, 06 Jun 2006 15:26:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,DNS_FROM_RFC_WHOIS,SPF_HELO_PASS, SPF_PASS autolearn=no version=3.1.1 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FndRl-000OqV-OK for namedroppers@ops.ietf.org; Tue, 06 Jun 2006 15:26:21 +0000 Received: from [10.131.244.197] ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Tue, 06 Jun 2006 11:26:20 -0400 id 002CC01C.44859E9C.0000529D In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v750) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <75056A3F-549A-4173-ABAA-D4FC6D723C31@verisignlabs.com> Content-Transfer-Encoding: 7bit From: David Blacka Subject: Re: NSEC3 Issue 20: Server behavior wrt unknown hash algorithms Date: Tue, 6 Jun 2006 11:26:15 -0400 To: Namedroppers WG X-Mailer: Apple Mail (2.750) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 On Jun 6, 2006, at 10:00 AM, Scott Rose wrote: > Personally, I think Approach 1 may be best. It would be consistent in > dealing with everything - name errors, no error/no data, wildcards and > unsigned delegations. I think approach 1 is best, too, although I disagree with how it is stated. If a nameserver refuses to load a zone, why would it return RCODE=2 in responses that would fall under that zone? As far as responses go, it should behave the same for all zones that it isn't authoritative for. -- David Blacka Sr. Engineer VeriSign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 06 11:37:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fndc5-0001yI-Fx for dnsext-archive@lists.ietf.org; Tue, 06 Jun 2006 11:37:01 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FncYJ-0004Vd-7n for dnsext-archive@lists.ietf.org; Tue, 06 Jun 2006 10:29:03 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fnc9N-0004G6-BY for dnsext-archive@lists.ietf.org; Tue, 06 Jun 2006 10:03:19 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fnc6Y-000H3m-Ce for namedroppers-data@psg.com; Tue, 06 Jun 2006 14:00:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fnc6X-000H3M-Gi for namedroppers@ops.ietf.org; Tue, 06 Jun 2006 14:00:21 +0000 Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k56E09nY025958 for ; Tue, 6 Jun 2006 10:00:09 -0400 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.13.6/8.13.6) with SMTP id k56E03H4004750 for ; Tue, 6 Jun 2006 10:00:04 -0400 (EDT) From: "Scott Rose" To: Subject: RE: NSEC3 Issue 20: Server behavior wrt unknown hash algorithms Date: Tue, 6 Jun 2006 10:00:06 -0400 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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Importance: Normal X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.3 (--) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Personally, I think Approach 1 may be best. It would be consistent in dealing with everything - name errors, no error/no data, wildcards and unsigned delegations. I'm not tied to this solution though, so if the consensus is 2, 3, or some other choice, I won't object. Scott > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Roy Arends > Sent: Wednesday, May 31, 2006 11:33 AM > To: namedroppers@ops.ietf.org > Subject: NSEC3 Issue 20: Server behavior wrt unknown hash algorithms > > > Issue: > > Server behavior with regards to unknown hash algorithms > > Discussion: > > An NSEC3 capable server might, on load or during a zone transfer, > encounter an NSEC3 with an unknown hash algorithm. As it is unable to > determine which NSEC3 to send back in a response, the server can't fully > provide the service intended. > > Approach 1) > Refuse to load/accept the zone. Return rcode 2 on requests > related to this > zone. > > Approach 2) > load/accept the zone with a warning. Return rcode 2 where the responses > normally would contain NSEC3 records. This allows the server to provide > service for DO=0 requests, and for DO=1 where the responses do > not contain > NSEC3's > > Approach 3) > Load/accept the zone with a warning. Return rcode 2 except for > qtype=axfr/ixfr. This allows the server to provide service for > secondaries. > > This is not an exhaustive list. > > Resolution: > Default approach has yet to be set. > > Regards, > > Roy > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 06 11:39:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnde8-0003Hp-8q for dnsext-archive@lists.ietf.org; Tue, 06 Jun 2006 11:39:08 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnde6-0008Jo-Sg for dnsext-archive@lists.ietf.org; Tue, 06 Jun 2006 11:39:08 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fndbk-000PqU-Sp for namedroppers-data@psg.com; Tue, 06 Jun 2006 15:36:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,DNS_FROM_RFC_WHOIS,SPF_HELO_PASS, SPF_PASS autolearn=no version=3.1.1 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fndbk-000PqH-BN for namedroppers@ops.ietf.org; Tue, 06 Jun 2006 15:36:40 +0000 Received: from [10.131.244.197] ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Tue, 06 Jun 2006 11:36:39 -0400 id 002CC01C.4485A107.000055EA In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <85E4123D-65B1-470D-AD6F-D737396AEF32@verisignlabs.com> Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit From: David Blacka Subject: Re: NSEC3 Issue 17: opt-out for delegation only is not enforcable. Date: Tue, 6 Jun 2006 11:36:34 -0400 To: Roy Arends X-Mailer: Apple Mail (2.750) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 On May 31, 2006, at 7:11 AM, Roy Arends wrote: > Issue: > > The use of Optout is restricted to unsigned delegations. This > restriction > is inherited from the experimental Opt-In draft. Even-though the > restriction is in place, it can't be enforced on the server side, i.e. > there is a way to allow unsigned records other than delegations to > exist > in an optout span, without it ever to appear as such on the wire, > by means > of delegating them to unsigned subzones with the same name. > > Discussion: > > Assume the administrator of the secured zone 'example.com' wants > the world > to see 'www.example.com' as unsigned. He could delegate > www.example.com > away as an optout unsigned delegation to another server. > > This process can be automated without breaking any signatures. > Delegation > point NS records are unsigned, and there is no evidence the NS record > exist if the NSEC3 duo that proves the closest provable encloser is > marked > as optout. This would violate the NSEC3 draft where a signer MUST NOT > allow any other record than delegation point NS records to exist in an > optout span. I would say that the issue is more accurately described as an inability to enforce delegation-only on the validator side. That is, it is impractical for a validator to be in the business of making absolutely certain that only delegations exist within opt-out spans. However, I do not believe that this is really an issue either for NSEC3 or for the experimental opt-in draft. Delegation-only is a MUST on the server (and thus signer) side because it forms an underlying assumption in how an opt-in/out aware validator validates. That is, the validator is only required to pay attention to the flag in cases where a delegation could have been opted out. That it may be possible to violate the "delegation-only" restriction on the server side without being detected by the validator is of no consequence because the same effect can always be achieved legally (by using a delegation). -- David Blacka Sr. Engineer VeriSign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 06 11:52:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FndrA-000385-6J for dnsext-archive@lists.ietf.org; Tue, 06 Jun 2006 11:52:36 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fndr8-0001YQ-Rv for dnsext-archive@lists.ietf.org; Tue, 06 Jun 2006 11:52:36 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fndot-0001B0-1Y for namedroppers-data@psg.com; Tue, 06 Jun 2006 15:50:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fndos-0001An-4d for namedroppers@ops.ietf.org; Tue, 06 Jun 2006 15:50:14 +0000 Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k56FoAig017424 for ; Tue, 6 Jun 2006 11:50:10 -0400 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.13.6/8.13.6) with SMTP id k56FnCHq001994 for ; Tue, 6 Jun 2006 11:49:13 -0400 (EDT) From: "Scott Rose" To: "Namedroppers WG" Subject: RE: NSEC3 Issue 20: Server behavior wrt unknown hash algorithms Date: Tue, 6 Jun 2006 11:49:15 -0400 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: <75056A3F-549A-4173-ABAA-D4FC6D723C31@verisignlabs.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Importance: Normal X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of David Blacka > > On Jun 6, 2006, at 10:00 AM, Scott Rose wrote: > > > Personally, I think Approach 1 may be best. It would be consistent in > > dealing with everything - name errors, no error/no data, wildcards and > > unsigned delegations. > > I think approach 1 is best, too, although I disagree with how it is > stated. > > If a nameserver refuses to load a zone, why would it return RCODE=2 > in responses that would fall under that zone? As far as responses > go, it should behave the same for all zones that it isn't > authoritative for. > My guess that part was for ixfr/axfr. How secondaries should act when getting a zone with unknown hash algos in the NSEC3 RRs (after a hash algo rollover I assume). At least that was my understanding. Scott > -- > David Blacka > Sr. Engineer VeriSign Applied Research > > > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 06 12:20:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FneI6-0007Wk-79 for dnsext-archive@lists.ietf.org; Tue, 06 Jun 2006 12:20:26 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FneI3-0003uy-MG for dnsext-archive@lists.ietf.org; Tue, 06 Jun 2006 12:20:26 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FneCj-0003Rl-SC for namedroppers-data@psg.com; Tue, 06 Jun 2006 16:14:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FneCi-0003RT-Dw for namedroppers@ops.ietf.org; Tue, 06 Jun 2006 16:14:52 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k56GEiSh019045 for ; Tue, 6 Jun 2006 12:14:44 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.2.5.6.2.20060606103736.03c810c0@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 06 Jun 2006 12:14:26 -0400 To: From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: RE: NSEC3 Issue 20: Server behavior wrt unknown hash algorithms In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Solution #1 is the only sane solution, as it forces a zone owner to make sure all server serving the zone support the new algorithm before it is used. Here is what is scaring me about NSEC3: (more than just issue 20 but mainly issue 20) In order for authorative server to find the correct NSEC3 record to return in negative answers, the server NEEDS to interpret the RDADA contents of a "magic" random NSEC3 to parameterize its search algorithm. Magic = the NSEC3 covering the apex. Only in one other place does the RDATA of an RR dictate the behavior of a server in processing a zone, this is the timer values in the SOA record. A consequence of this The first question: Do we want the contents of a new resource record dictate the processing rules for a zone? The second question: Do we want this Control plane information stored in a random place in zone or at a fixed place? If the answer is the second. This can be accomplished either by special casing the NSEC3 covering the APEX to be stored at the APEX or create a new RR only allowed at the APEX that stores the control parameters for the NSEC3 processing in that zone. If the current specification proposal stands: any zone transfer agent now needs to parse the RDATA contents of all NSEC3 records to check that the zone control plane parameters are still the same. Olafur (no hats just a regular WG trouble maker) At 10:00 06/06/2006, Scott Rose wrote: >Personally, I think Approach 1 may be best. It would be consistent in >dealing with everything - name errors, no error/no data, wildcards and >unsigned delegations. > >I'm not tied to this solution though, so if the consensus is 2, 3, or some >other choice, I won't object. > >Scott > > -----Original Message----- > > From: owner-namedroppers@ops.ietf.org > > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Roy Arends > > Sent: Wednesday, May 31, 2006 11:33 AM > > To: namedroppers@ops.ietf.org > > Subject: NSEC3 Issue 20: Server behavior wrt unknown hash algorithms > > > > > > Issue: > > > > Server behavior with regards to unknown hash algorithms > > > > Discussion: > > > > An NSEC3 capable server might, on load or during a zone transfer, > > encounter an NSEC3 with an unknown hash algorithm. As it is unable to > > determine which NSEC3 to send back in a response, the server can't fully > > provide the service intended. > > > > Approach 1) > > Refuse to load/accept the zone. Return rcode 2 on requests > > related to this > > zone. > > > > Approach 2) > > load/accept the zone with a warning. Return rcode 2 where the responses > > normally would contain NSEC3 records. This allows the server to provide > > service for DO=0 requests, and for DO=1 where the responses do > > not contain > > NSEC3's > > > > Approach 3) > > Load/accept the zone with a warning. Return rcode 2 except for > > qtype=axfr/ixfr. This allows the server to provide service for > > secondaries. > > > > This is not an exhaustive list. > > > > Resolution: > > Default approach has yet to be set. > > > > Regards, > > > > Roy > > > > -- > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > > > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to namedroppers-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 Jun 07 05:54:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnukZ-00023k-Pm for dnsext-archive@lists.ietf.org; Wed, 07 Jun 2006 05:54:55 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnukY-0001Ox-Ak for dnsext-archive@lists.ietf.org; Wed, 07 Jun 2006 05:54:55 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fnuej-000Dar-2s for namedroppers-data@psg.com; Wed, 07 Jun 2006 09:48:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_NEUTRAL autolearn=no version=3.1.1 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fnueg-000DaN-OY for namedroppers@ops.ietf.org; Wed, 07 Jun 2006 09:48:51 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 43ECB33C1C; Wed, 7 Jun 2006 10:48:41 +0100 (BST) Message-ID: <4486A0B8.8020602@algroup.co.uk> Date: Wed, 07 Jun 2006 10:47:36 +0100 From: Ben Laurie User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson?= CC: namedroppers@ops.ietf.org Subject: Re: NSEC3 Issue 20: Server behavior wrt unknown hash algorithms References: <6.2.5.6.2.20060606103736.03c810c0@ogud.com> In-Reply-To: <6.2.5.6.2.20060606103736.03c810c0@ogud.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Ólafur Guðmundsson wrote: > > Solution #1 is the only sane solution, as it forces a zone owner to make > sure all server serving the zone support the new algorithm before it is > used. > > Here is what is scaring me about NSEC3: (more than just issue 20 but mainly > issue 20) > > In order for authorative server to find the correct NSEC3 record to return > in negative answers, the server NEEDS to interpret the RDADA contents of > a "magic" random NSEC3 to parameterize its search algorithm. > Magic = the NSEC3 covering the apex. > > Only in one other place does the RDATA of an RR dictate the behavior of > a server in processing a zone, this is the timer values in the SOA record. > > A consequence of this > The first question: Do we want the contents of a new resource > record dictate the processing rules for a zone? > > The second question: Do we want this Control plane information > stored in a random place in zone or at a fixed place? > > If the answer is the second. > This can be accomplished either by > special casing the NSEC3 covering the APEX to be stored at > the APEX > or create a new RR only allowed at the APEX that stores the > control parameters for the NSEC3 processing in that zone. > > If the current specification proposal stands: > any zone transfer agent now needs to parse the RDATA contents of all > NSEC3 records to check that the zone control plane parameters are still the > same. The only reason I didn't suggest creating a new RR for the data in the first place is I suspected I'd get shot for proposing it. If the WG thinks that's the way to go I'm certainly not opposed. I'm not in favour of special-casing the apex record, seems to me that adds complication all over the place in order to accomplish something unrelated to that complication. > > Olafur (no hats just a regular WG trouble maker) > > At 10:00 06/06/2006, Scott Rose wrote: >> Personally, I think Approach 1 may be best. It would be consistent in >> dealing with everything - name errors, no error/no data, wildcards and >> unsigned delegations. >> >> I'm not tied to this solution though, so if the consensus is 2, 3, or >> some >> other choice, I won't object. >> >> Scott >> > -----Original Message----- >> > From: owner-namedroppers@ops.ietf.org >> > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Roy Arends >> > Sent: Wednesday, May 31, 2006 11:33 AM >> > To: namedroppers@ops.ietf.org >> > Subject: NSEC3 Issue 20: Server behavior wrt unknown hash algorithms >> > >> > >> > Issue: >> > >> > Server behavior with regards to unknown hash algorithms >> > >> > Discussion: >> > >> > An NSEC3 capable server might, on load or during a zone transfer, >> > encounter an NSEC3 with an unknown hash algorithm. As it is unable to >> > determine which NSEC3 to send back in a response, the server can't >> fully >> > provide the service intended. >> > >> > Approach 1) >> > Refuse to load/accept the zone. Return rcode 2 on requests >> > related to this >> > zone. >> > >> > Approach 2) >> > load/accept the zone with a warning. Return rcode 2 where the responses >> > normally would contain NSEC3 records. This allows the server to provide >> > service for DO=0 requests, and for DO=1 where the responses do >> > not contain >> > NSEC3's >> > >> > Approach 3) >> > Load/accept the zone with a warning. Return rcode 2 except for >> > qtype=axfr/ixfr. This allows the server to provide service for >> > secondaries. >> > >> > This is not an exhaustive list. >> > >> > Resolution: >> > Default approach has yet to be set. >> > >> > Regards, >> > >> > Roy >> > >> > -- >> > to unsubscribe send a message to namedroppers-request@ops.ietf.org with >> > the word 'unsubscribe' in a single line as the message text body. >> > archive: >> >> >> >> -- >> to unsubscribe send a message to namedroppers-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- http://www.apache-ssl.org/ben.html http://www.links.org/ "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 Wed Jun 07 12:59:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo1N6-00082D-2q for dnsext-archive@lists.ietf.org; Wed, 07 Jun 2006 12:59:08 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo1N3-000384-7D for dnsext-archive@lists.ietf.org; Wed, 07 Jun 2006 12:59:08 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fo1GH-0000rN-2i for namedroppers-data@psg.com; Wed, 07 Jun 2006 16:52:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_12_24 autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fo1GG-0000qt-5h for namedroppers@ops.ietf.org; Wed, 07 Jun 2006 16:52:04 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k57GpwXR029873 for ; Wed, 7 Jun 2006 12:51:58 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.2.5.6.2.20060606225159.032dea38@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 06 Jun 2006 23:02:48 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: DNSEXT @ IETF-66 agenda items Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Send items you would like to have discussed to me 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 tomaslivingston@lovingporn.com Fri Jun 09 10:13:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FohkJ-0007N0-Tk for dnsext-archive@lists.ietf.org; Fri, 09 Jun 2006 10:13:55 -0400 Received: from host-200-94-75-196.block.alestra.net.mx ([200.94.75.196] helo=BABY) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FohkG-00041y-As for dnsext-archive@lists.ietf.org; Fri, 09 Jun 2006 10:13:55 -0400 Message-Id: <001b01c68bc5$72f33f00$3e705101@wrgwxr> From: "roobbie emerson" To: "evered blackburn" Subject: Cash out, noble-tempered Date: Fri, 09 Jun 2006 09:07:28 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01C68BC5.72F33F00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.5 (++++) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C68BC5.72F33F00 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable How much are you paying for your Home? To much?=20 You have been pre-approved to fill out for a ref inance laon,=20 if you need some cash to spend ANY way you like, or simply wish=20 to LOWER your monthly payments by a third or more, etc. We skip the middle man to save hundreds with deals we have!=20 This offer is for you, we DONT CARE about your credit.=20 Apply online now for your instant quote. Stop over paying...=20 http://teenmu.org/d2/ life-sapping school model quick-freezing wide-eared self-humbling late-protracted hand paper wrong-screwed Brittany cloth bosom-breathing nipperty-tipperty castana nut = rocking chair Eupolidean meter twice-witnessed tire chipper sedge bird wisdom-loving block chain subject matter saddle currier Martinmas summer disk cultivator tank drama calamity howler barley-fed Non-stoic ear fungus draft chair air casing sausage tree ------=_NextPart_000_001B_01C68BC5.72F33F00 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
How much are you paying for your Home? To much?
You have been pre-approved to fill out for a ref inance laon,
if you need some cash to spend ANY way you like, or simply wish
to LOWER your monthly payments by a third or more, etc.

We skip the middle man to save hundreds with deals we have!
This offer is for you, we DONT CARE about your credit.

Apply online now for your instant quote. Stop over paying...

http://teenmu.org/d2/

life-sapping school model quick-freezing wide-eared self-humbling
late-protracted hand paper
wrong-screwed Brittany cloth bosom-breathing nipperty-tipperty castana nut = rocking chair
Eupolidean meter twice-witnessed tire chipper sedge bird wisdom-loving
block chain subject matter saddle currier
Martinmas summer disk cultivator tank drama
calamity howler barley-fed Non-stoic ear fungus draft chair
air casing sausage tree
= ------=_NextPart_000_001B_01C68BC5.72F33F00-- From owner-namedroppers@ops.ietf.org Fri Jun 09 10:19:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FohpN-00006I-RM for dnsext-archive@lists.ietf.org; Fri, 09 Jun 2006 10:19:09 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FohpM-00049t-Ex for dnsext-archive@lists.ietf.org; Fri, 09 Jun 2006 10:19:09 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FohjJ-0003UQ-90 for namedroppers-data@psg.com; Fri, 09 Jun 2006 14:12:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FohjI-0003U9-Cl for namedroppers@ops.ietf.org; Fri, 09 Jun 2006 14:12:52 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k59ECkvu053641 for ; Fri, 9 Jun 2006 10:12:46 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.2.5.6.2.20060609101012.03ef5ef0@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 09 Jun 2006 10:12:35 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: Re: Standardize RSA/SHA256 ? In-Reply-To: <6.2.5.6.2.20060508094001.03182b80@ogud.com> References: <6.2.5.6.2.20060508094001.03182b80@ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f At 11:41 08/05/2006, =D3lafur Gu=F0mundsson /DNSEXT wrote: >Dear colleagues > >The Working group has had a document for the last few months that >defines a new DNSKEY algorithm RSA/SHA256. Discussion on this >document has been non existent. > >The chairs would like to ask the working group following question: >Is there support in the working group to add a new RSA algorithm >to the list of supported algorithms? There does not seem to be a general consensus on standardizing RSA/SHA256 for signatures now. The main arguments are that from a security point of view there are no compelling arguments and that introducing RSA/SHA256 now would add implementation and operational complexity at the time where that sort of complexity may push back the deployment. It should be noted that one of the questions; how doe multiple algorithms play together with NSEC and NSEC3 is currently being addressed in the NSEC3 work and has been described in the "experiments" draft. We think that once NSEC3 is finished and we have seen some pick up in deployment we should revisit the SHA256 signature issue. Then we have more operational experience to address the operational issues too. The chairs thank the document editor for his work on this document. Olaf & Olafur =20 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 12 10:41:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpnbd-00045L-Q3 for dnsext-archive@lists.ietf.org; Mon, 12 Jun 2006 10:41:29 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fpnbc-0005c2-Gn for dnsext-archive@lists.ietf.org; Mon, 12 Jun 2006 10:41:29 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FpnWc-0005yS-01 for namedroppers-data@psg.com; Mon, 12 Jun 2006 14:36:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FpnWb-0005yE-2Z for namedroppers@ops.ietf.org; Mon, 12 Jun 2006 14:36:17 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k5CEaADS073106; Mon, 12 Jun 2006 10:36:10 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.2.5.6.2.20060612102822.03b52c00@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 12 Jun 2006 10:35:09 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: RFC2672bis DNAME update document Cc: ogud@ogud.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 The chairs have recruited volunteers to take on this effort They are: Matt Larson Wouter Wijngaards Right now they are working on assembling a list off issues, related to RFC2672 DNAME specification. If you have issues/experiences with DNAME that you would like to see in the initial list of issues, please send them a note, right now. We need 5 people that speak up in response to this note and between those people there is general consensus that this document is a work item, If we do not consensus, we will ask the editors to post this document as a personal submission first. (We'd be sad if that would need to be the case.) The editors will operate an public issue tracker for the document. The process is a standard clarify process: Wouter and Matt are editors reflecting the consensus of the working group. The initial time line for this effort is to try to have the working group finish this with this document by IETF 68 (March/2007). At this point it is not clear if the resulting document will be recycled at Proposed or be issued as a Draft standard. Olafur & Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 12 11:24:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpoH4-0000Cn-II for dnsext-archive@lists.ietf.org; Mon, 12 Jun 2006 11:24:18 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpoH4-0002mI-4T for dnsext-archive@lists.ietf.org; Mon, 12 Jun 2006 11:24:18 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FpoES-000AFQ-FL for namedroppers-data@psg.com; Mon, 12 Jun 2006 15:21:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [144.189.100.105] (helo=motgate5.mot.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FpoEP-000AF4-Pb for namedroppers@ops.ietf.org; Mon, 12 Jun 2006 15:21:33 +0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id k5CFLWIR015409 for ; Mon, 12 Jun 2006 08:21:32 -0700 (MST) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id k5CFLVXS008705 for ; Mon, 12 Jun 2006 10:21:32 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RFC2672bis DNAME update document Date: Mon, 12 Jun 2006 11:21:31 -0400 Message-ID: <3870C46029D1F945B1472F170D2D979001052664@de01exm64.ds.mot.com> In-Reply-To: <6.2.5.6.2.20060612102822.03b52c00@ogud.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC2672bis DNAME update document thread-index: AcaOL62Fx3tsCgVVTVuD7+SFp7rhHwABCZHQ From: "Eastlake III Donald-LDE008" To: X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Seems like a good idea to me. Donald -----Original Message----- From: owner-namedroppers@ops.ietf.org = [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of =D3lafur = Gu=F0mundsson /DNSEXT co-chair Sent: Monday, June 12, 2006 10:35 AM To: namedroppers@ops.ietf.org Cc: ogud@ogud.com Subject: RFC2672bis DNAME update document The chairs have recruited volunteers to take on this effort They are: Matt Larson Wouter Wijngaards Right now they are working on assembling a list off issues, related to = RFC2672 DNAME specification. If you have issues/experiences with DNAME = that you would like to see in the initial list of issues, please send = them a note, right now. We need 5 people that speak up in response to this note and between = those people there is general consensus that this document is a work = item, If we do not consensus, we will ask the editors to post this = document as a personal submission first. (We'd be sad if that would need to be the case.) The editors will operate an public issue tracker for the document. The process is a standard clarify process: Wouter and Matt are editors = reflecting the consensus of the working group. The initial time line for this effort is to try to have the working = group finish this with this document by IETF 68 (March/2007). At this point it is not clear if the resulting document will be recycled = at Proposed or be issued as a Draft standard. Olafur & Olaf=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 Mon Jun 12 13:24:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpq9C-000532-RZ for dnsext-archive@lists.ietf.org; Mon, 12 Jun 2006 13:24:18 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fpq9B-00069a-C6 for dnsext-archive@lists.ietf.org; Mon, 12 Jun 2006 13:24:18 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fpq6m-000M3M-N8 for namedroppers-data@psg.com; Mon, 12 Jun 2006 17:21:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.1 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fpq6l-000M38-Ly for namedroppers@ops.ietf.org; Mon, 12 Jun 2006 17:21:47 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k5CHKlEw023345 for ; Mon, 12 Jun 2006 13:20:47 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAjxaOpT; Mon, 12 Jun 06 13:19:26 -0400 Received: from localhost (suresh@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id k5CGvWg8020014 for ; Mon, 12 Jun 2006 12:57:32 -0400 (EDT) Date: Mon, 12 Jun 2006 12:57:32 -0400 (EDT) From: Suresh Krishnaswamy To: namedroppers@ops.ietf.org Subject: Pending issues for draft-ietf-dnsext-rollover-requirements-01 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Dear Namedroppers, In a short while I'll be sending out the current list of pending issues and proposed changes for draft-ietf-dnsext-rollover-requirements-01. I propose to include these changes (which the chairs feel capture the WGs intent) to the draft if there is no further feedback by the end of the week. The chairs intend to last-call the document once these changes are in place. Thanks! Suresh -- to unsubscribe send a message to namedroppers-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 Jun 12 13:26:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpqBX-00074S-5o for dnsext-archive@lists.ietf.org; Mon, 12 Jun 2006 13:26:43 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpqBV-0006Ho-Td for dnsext-archive@lists.ietf.org; Mon, 12 Jun 2006 13:26:43 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FpqAK-000MRt-CU for namedroppers-data@psg.com; Mon, 12 Jun 2006 17:25:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.1 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FpqAH-000MRJ-Va for namedroppers@ops.ietf.org; Mon, 12 Jun 2006 17:25:26 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k5CHOSmm023950 for ; Mon, 12 Jun 2006 13:24:28 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAxuaiEU; Mon, 12 Jun 06 13:23:23 -0400 Received: from localhost (suresh@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id k5CHM1rR021033 for ; Mon, 12 Jun 2006 13:22:01 -0400 (EDT) Date: Mon, 12 Jun 2006 13:22:01 -0400 (EDT) From: Suresh Krishnaswamy To: namedroppers@ops.ietf.org Subject: ISSUE 6: draft-moreau-dnsext-tak-req-00 has other useful requirements, was Re: Pending issues for draft-ietf-dnsext-rollover-requirements-01 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad ISSUE 6: draft-moreau-dnsext-tak-req-00 has other useful requirements, RE-OPENED Based on clarification from Olaf and Thierry I intend to use replacement text from for the definition of the "Non-degrading trust". -- to unsubscribe send a message to namedroppers-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 Jun 12 13:53:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpqbG-000765-DM for dnsext-archive@lists.ietf.org; Mon, 12 Jun 2006 13:53:18 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpqbF-0001IA-3w for dnsext-archive@lists.ietf.org; Mon, 12 Jun 2006 13:53:18 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FpqZb-000PNe-Eb for namedroppers-data@psg.com; Mon, 12 Jun 2006 17:51:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.1 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FpqZZ-000PNI-Jx for namedroppers@ops.ietf.org; Mon, 12 Jun 2006 17:51:34 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k5CHoCu3027919 for ; Mon, 12 Jun 2006 13:50:12 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcEAATQaiq2; Mon, 12 Jun 06 13:50:11 -0400 Received: from localhost (suresh@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id k5CHMEQC021043 for ; Mon, 12 Jun 2006 13:22:14 -0400 (EDT) Date: Mon, 12 Jun 2006 13:22:14 -0400 (EDT) From: Suresh Krishnaswamy To: namedroppers@ops.ietf.org Subject: ISSUE 8: Wording of existing requirements, was Re: Pending issues for draft-ietf-dnsext-rollover-requirements-01 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ISSUE 8: Wording of existing requirements, RE-OPENED In I included two new requirements based on my interpretation of various comments on the list. * 5.5 Detection of Stale Trust Anchors * 5.11 Support for Trust Anchor Maintenance Operations Of these, I read Ed's mail in as support for requirement 5.11 and lack of support for 5.5. The intent of 5.5 is really to say that the solution must allow the security-aware validating resolver to identify when it is "out-of-sync" so that initial trust may be re-established. Olaf has offered the following text as replacement: The Trust Anchor Rollover solution MUST allow a validating security- aware resolver to be able to detect if the DNSKEY or DS RR(s) can no longer be updated given the current set of actual trust-anchors so that initial trust may be re-established. I also propose dropping the sentence "The same solution SHALL be able to be used to maintain Trust Anchors for the root zone and other zones." from 5.3 (again from Ed's mail above). I wasn't exactly sure what the proposed actions for 5.1, 5.4 and 5.12 were so I've not made any changes. -- to unsubscribe send a message to namedroppers-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 Jun 12 13:53:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpqbG-00076H-Lj for dnsext-archive@lists.ietf.org; Mon, 12 Jun 2006 13:53:18 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpqbF-0001ID-CZ for dnsext-archive@lists.ietf.org; Mon, 12 Jun 2006 13:53:18 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FpqZB-000PMA-9n for namedroppers-data@psg.com; Mon, 12 Jun 2006 17:51:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.1 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FpqZ9-000PLu-MN for namedroppers@ops.ietf.org; Mon, 12 Jun 2006 17:51:08 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k5CHoA8n027912 for ; Mon, 12 Jun 2006 13:50:10 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAPQaiq2; Mon, 12 Jun 06 13:49:25 -0400 Received: from localhost (suresh@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id k5CHMnKK021069 for ; Mon, 12 Jun 2006 13:22:49 -0400 (EDT) Date: Mon, 12 Jun 2006 13:22:49 -0400 (EDT) From: Suresh Krishnaswamy To: namedroppers@ops.ietf.org Subject: ISSUE 10: Use of RFC 2119 terminology, was Re: Pending issues for draft-ietf-dnsext-rollover-requirements-01 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 ISSUE 10: Use of RFC 2119 terminology, NEW This document is to be used as guidance for selecting a rollover solution. It may well be that not all the requirements can be met in which case trade-offs will be made. The use of 2119 terminology may be confusing here and Olaf has proposed the following change: REMOVE: The use of the RFC-2119 words in this version of document is preliminary in nature and feedback is requested as to the correct word to use for each of the requirements. ADD: The use of RFC-2119 words in the requirements is intended to unambiguously describe a requirement. If a tradeoff is to be made between conflicting requirements when choosing for a solution the requirement with MUST language will have higher preference than requirements with SHOULD, MAY, or RECOMMEND language. It is understood that a tradeoff may need to be made between requirements that both contain MUST language. -- to unsubscribe send a message to namedroppers-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 Jun 12 13:53:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpqbI-00076W-MC for dnsext-archive@lists.ietf.org; Mon, 12 Jun 2006 13:53:20 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpqbH-0001IK-DV for dnsext-archive@lists.ietf.org; Mon, 12 Jun 2006 13:53:20 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FpqZK-000PMj-FJ for namedroppers-data@psg.com; Mon, 12 Jun 2006 17:51:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.1 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FpqZI-000PMP-G3 for namedroppers@ops.ietf.org; Mon, 12 Jun 2006 17:51:17 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k5CHoFr9027925 for ; Mon, 12 Jun 2006 13:50:15 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcIAAXQaiq2; Mon, 12 Jun 06 13:50:14 -0400 Received: from localhost (suresh@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id k5CHMPOQ021057 for ; Mon, 12 Jun 2006 13:22:25 -0400 (EDT) Date: Mon, 12 Jun 2006 13:22:25 -0400 (EDT) From: Suresh Krishnaswamy To: namedroppers@ops.ietf.org Subject: Issue 9: Relevance to working group charter, was Re: Pending issues for draft-ietf-dnsext-rollover-requirements-01 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: d6b246023072368de71562c0ab503126 Issue 9: Relevance to working group charter, NEW In Thierry raised a couple of objections to the wording in section 5.2. Wes provided replacement text in to address the first. Olaf noted in that the second objection was probably a non-issue. The replacement text from Wes will be merged into the document and with that the issue will be considered CLOSED. -- to unsubscribe send a message to namedroppers-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 Jun 12 17:26:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FptvG-0007uL-Ak for dnsext-archive@lists.ietf.org; Mon, 12 Jun 2006 17:26:10 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FptvF-0000Ze-0w for dnsext-archive@lists.ietf.org; Mon, 12 Jun 2006 17:26:10 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FptrE-000FLc-4X for namedroppers-data@psg.com; Mon, 12 Jun 2006 21:22:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,DNS_FROM_RFC_WHOIS,SPF_HELO_PASS, SPF_PASS autolearn=no version=3.1.1 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FptrD-000FLO-B7 for namedroppers@ops.ietf.org; Mon, 12 Jun 2006 21:21:59 +0000 Received: from [10.131.244.197] ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Mon, 12 Jun 2006 17:21:58 -0400 id 002CC032.448DDAF6.0000335C Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <6.2.5.6.2.20060612102822.03b52c00@ogud.com> References: <6.2.5.6.2.20060612102822.03b52c00@ogud.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <5DE8438C-59AC-4A4B-8BFF-A22710390521@verisignlabs.com> Content-Transfer-Encoding: quoted-printable From: David Blacka Subject: Re: RFC2672bis DNAME update document Date: Mon, 12 Jun 2006 17:21:57 -0400 To: Namedroppers WG X-Mailer: Apple Mail (2.750) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 On Jun 12, 2006, at 10:35 AM, =D3lafur Gu=F0mundsson /DNSEXT co-chair = wrote: > > We need 5 people that speak up in response to this > note and between those people there is general consensus that this > document is a work item, If we do not consensus, we will ask the > editors to post this document as a personal submission first. > (We'd be sad if that would need to be the case.) Just removing the references to EDNS1 would be a big improvement, IMHO. So, I certainly support this becoming a work item. -- 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 Mon Jun 12 17:43:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpuCN-0000nA-Pm for dnsext-archive@lists.ietf.org; Mon, 12 Jun 2006 17:43:51 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpuCN-000672-D4 for dnsext-archive@lists.ietf.org; Mon, 12 Jun 2006 17:43:51 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FpuAR-000Gdo-Gw for namedroppers-data@psg.com; Mon, 12 Jun 2006 21:41:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FpuAQ-000Gdc-Ow for namedroppers@ops.ietf.org; Mon, 12 Jun 2006 21:41:50 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id A8E8E5683C; Mon, 12 Jun 2006 14:41:49 -0700 (PDT) (envelope-from Mike.StJohns@nominum.com) Message-Id: <7.0.1.0.2.20060612174002.03d76008@nominum.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 12 Jun 2006 17:42:02 -0400 To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair , namedroppers@ops.ietf.org From: Mike StJohns Subject: Re: RFC2672bis DNAME update document Cc: ogud@ogud.com In-Reply-To: <6.2.5.6.2.20060612102822.03b52c00@ogud.com> References: <6.2.5.6.2.20060612102822.03b52c00@ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Olafur - While I don't have any problems with this as a=20 work item, I will note that we haven't made very=20 much progress on those already on our plate. I'd=20 like to suggest deferring this for one meeting=20 with the hope that the chairs will do some much=20 needed spring cleaning of the groups current tasks. Mike At 10:35 AM 6/12/2006, =D3lafur Gu=F0mundsson /DNSEXT wrote: >The chairs have recruited volunteers to take on this effort >They are: > Matt Larson > Wouter Wijngaards > >Right now they are working on assembling a list off issues, >related to RFC2672 DNAME specification. If you have >issues/experiences with DNAME that you would like to see in the >initial list of issues, please send them a note, right now. > >We need 5 people that speak up in response to this >note and between those people there is general consensus that this >document is a work item, If we do not consensus, we will ask the >editors to post this document as a personal submission first. >(We'd be sad if that would need to be the case.) > >The editors will operate an public issue tracker for the document. > >The process is a standard clarify process: Wouter and Matt are editors >reflecting the consensus of the working group. > >The initial time line for this effort is to try to have the working >group finish this with this document by IETF 68 (March/2007). >At this point it is not clear if the resulting >document will be recycled at Proposed or be issued as a Draft standard. > > Olafur & Olaf > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to namedroppers-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 Jun 12 19:08:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpvW9-00019d-S3 for dnsext-archive@lists.ietf.org; Mon, 12 Jun 2006 19:08:21 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpvW8-0004HA-F7 for dnsext-archive@lists.ietf.org; Mon, 12 Jun 2006 19:08:21 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FpvT7-000MGB-8D for namedroppers-data@psg.com; Mon, 12 Jun 2006 23:05:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FpvT6-000MFz-MC for namedroppers@ops.ietf.org; Mon, 12 Jun 2006 23:05:12 +0000 Received: from drugs.dv.isc.org (localhost.isc.org [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 ABC14E6009 for ; Mon, 12 Jun 2006 23:05:11 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.6/8.13.6) with ESMTP id k5CN56GG086594 for ; Tue, 13 Jun 2006 09:05:06 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200606122305.k5CN56GG086594@drugs.dv.isc.org> To: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: RFC2672bis DNAME update document In-reply-to: Your message of "Mon, 12 Jun 2006 10:35:09 -0400." <6.2.5.6.2.20060612102822.03b52c00@ogud.com> Date: Tue, 13 Jun 2006 09:05:06 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 The TTL of the synthesised CNAME is currently set at zero. There is no reason not to make the TTL of the CNAME match the TTL of the DNAME. Doing so will reduce the load on the authoritative servers from non DNAME aware clients by allowing them to cache the CNAME name. -- 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 Jun 12 19:18:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpvg4-0005C0-Df for dnsext-archive@lists.ietf.org; Mon, 12 Jun 2006 19:18:36 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fpvg3-0004gT-4i for dnsext-archive@lists.ietf.org; Mon, 12 Jun 2006 19:18:36 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FpveP-000N4s-Rp for namedroppers-data@psg.com; Mon, 12 Jun 2006 23:16:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FpveP-000N4e-9e for namedroppers@ops.ietf.org; Mon, 12 Jun 2006 23:16:53 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id AFF3111429 for ; Mon, 12 Jun 2006 23:16:52 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: RFC2672bis DNAME update document In-Reply-To: Your message of "Tue, 13 Jun 2006 09:05:06 +1000." <200606122305.k5CN56GG086594@drugs.dv.isc.org> References: <200606122305.k5CN56GG086594@drugs.dv.isc.org> X-Mailer: MH-E 7.93; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 12 Jun 2006 23:16:52 +0000 Message-ID: <67332.1150154212@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 > The TTL of the synthesised CNAME is currently set at zero. > There is no reason not to make the TTL of the CNAME match > the TTL of the DNAME. Doing so will reduce the load on > the authoritative servers from non DNAME aware clients > by allowing them to cache the CNAME name. i agree. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 12 19:22:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpvjy-0008Fx-Nr for dnsext-archive@lists.ietf.org; Mon, 12 Jun 2006 19:22:38 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fpvjx-0004mO-9F for dnsext-archive@lists.ietf.org; Mon, 12 Jun 2006 19:22:38 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FpviZ-000NOy-7Z for namedroppers-data@psg.com; Mon, 12 Jun 2006 23:21:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FpviY-000NOn-Ms for namedroppers@ops.ietf.org; Mon, 12 Jun 2006 23:21:10 +0000 Received: from drugs.dv.isc.org (localhost.isc.org [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 CD0D4E6020 for ; Mon, 12 Jun 2006 23:21: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.6/8.13.6) with ESMTP id k5CNL8WC020335 for ; Tue, 13 Jun 2006 09:21:08 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200606122321.k5CNL8WC020335@drugs.dv.isc.org> Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: RFC2672bis DNAME update document In-reply-to: Your message of "Tue, 13 Jun 2006 09:05:06 +1000." Date: Tue, 13 Jun 2006 09:21:08 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a We also need to refute this section of RFC 3363. 4. DNAME in IPv6 Reverse Tree The issues for DNAME in the reverse mapping tree appears to be closely tied to the need to use fragmented A6 in the main tree: if one is necessary, so is the other, and if one isn't necessary, the other isn't either. Therefore, in moving RFC 2874 to experimental, the intent of this document is that use of DNAME RRs in the reverse tree be deprecated. And this section of RFC 4294 which was supposed to have dropped all reference to DNAME. I thought I had clobbered it but missed that it had not been removed when the next draft came out (months later). See the thread starting: http://www1.ietf.org/mail-archive/web/ipv6/current/msg01689.html Those nodes are NOT RECOMMENDED to support the experimental A6 and DNAME Resource Records [RFC-3363]. -- 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 Jun 13 09:24:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq8sQ-0002uI-5f for dnsext-archive@lists.ietf.org; Tue, 13 Jun 2006 09:24:14 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq8sO-0000cW-P9 for dnsext-archive@lists.ietf.org; Tue, 13 Jun 2006 09:24:14 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fq8mY-000BUI-CR for namedroppers-data@psg.com; Tue, 13 Jun 2006 13:18:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.154.224.54] (helo=grover.secret-wg.org) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fq8mX-000BU2-15 for namedroppers@ops.ietf.org; Tue, 13 Jun 2006 13:18:09 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by grover.secret-wg.org (Postfix) with ESMTP id 1F5C65E61D2; Tue, 13 Jun 2006 15:18:11 +0200 (CEST) In-Reply-To: <04E573F9-1398-4AF0-AEF1-AF37A9A25465@NLnetLabs.nl> References: <448E7515.8080606@cisco.com> <04E573F9-1398-4AF0-AEF1-AF37A9A25465@NLnetLabs.nl> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-8-98798579" Message-Id: Cc: Mark Townsley Content-Transfer-Encoding: 7bit From: Olaf M.Kolkman Subject: Re: nsid last call Date: Tue, 13 Jun 2006 15:18:10 +0200 To: Namedroppers X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.750) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-8-98798579 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Colleagues, This is to close the remaining issues. On the second issue we did not see consensus to change the text and it will remain as is > In section 2.3: > > OLD: > The OPTION-DATA for the NSID option is an opaque byte string the > semantics of which are deliberately left outside the protocol. As for the discussion of the first issue. The group consents with the general idea that the NSID option remains "unique" but also asked for a definition of unique. I think Dean Anderson's proposed text is catching the spirit of the discussion. And if there are is no push- back before the end of the week I would like to ask the editors to update 3.1 with the following. 3.1. The NSID Payload The syntax and semantics of the content of the NSID option is deliberately left outside the scope of this specification. It is the prerogative of the server administrator to choose the NSID content as long as the content is unique to each anycast instance so that a remote user is able to match the NSID to the server instance over a series of queries. The NSID can be opaque and encoded such that it can be decoded by the server adminstrator to provide more information. This section describe some of the kinds of data that server administrators might choose to provide as the content of the NSID option, and explains the reasoning behind choosing a simple opaque byte string. ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-8-98798579 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFEjrsStN/ca3YJIocRAnjVAKCAumX2hk1i+8Psq0GnPwSdmPrUxACgy+8V TMSU5earOljQSbN+zCluYl8= =i+9l -----END PGP SIGNATURE----- --Apple-Mail-8-98798579-- -- to unsubscribe send a message to namedroppers-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 Jun 13 09:24:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq8sZ-0002uZ-Dw for dnsext-archive@lists.ietf.org; Tue, 13 Jun 2006 09:24:23 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq8sY-0000cf-1X for dnsext-archive@lists.ietf.org; Tue, 13 Jun 2006 09:24:23 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fq8qk-000BsV-VA for namedroppers-data@psg.com; Tue, 13 Jun 2006 13:22:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.154.224.54] (helo=grover.secret-wg.org) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fq8qj-000BsD-OQ for namedroppers@ops.ietf.org; Tue, 13 Jun 2006 13:22:30 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by grover.secret-wg.org (Postfix) with ESMTP id 895855E61EB; Tue, 13 Jun 2006 15:22:32 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <7.0.1.0.2.20060612174002.03d76008@nominum.com> References: <6.2.5.6.2.20060612102822.03b52c00@ogud.com> <7.0.1.0.2.20060612174002.03d76008@nominum.com> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-9-99059975" Message-Id: <2805B0B0-CFA9-49E7-8ABD-4279673564D8@NLnetLabs.nl> Content-Transfer-Encoding: 7bit From: Olaf M.Kolkman Subject: Key rollover work, was Re: RFC2672bis DNAME update document Date: Tue, 13 Jun 2006 15:22:31 +0200 To: Mike StJohns , Namedroppers X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.750) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-9-99059975 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Jun 12, 2006, at 11:42 PM, Mike StJohns wrote: > Olafur - > > While I don't have any problems with this as a work item, I will > note that we haven't made very much progress on those already on > our plate. I'd like to suggest deferring this for one meeting with > the hope that the chairs will do some much needed spring cleaning > of the groups current tasks. > Hello Mike, Let me try to focus on that other, very important piece of work that has taken far to long to produce output; trust-anchor management. I want to try and get requirements done before the next IETF. Suresh has identified a few final issues and is about to post (or has posted, I have not cleared my inbox yet) a rev of the document. That version I'd like to last call. The requirements (finally) provide us a means to select among proposals. But in order to make that selection we do need folk that are committed to do some work in this space. I propose the following. 1 - All editors off drafts make sure that their drafts are alive in the repository. (before start of summer, June 21) 2 - Maybe some editors want to revoke their draft in lessen the entropy in this space or just because they think another draft is superior 3 - We start a reading round of one month. Here we need working group participants doing real work (!). I would like to see (at least 5?) people to read _all_ the drafts. (before IETF meeting (?)) 4 - While reading drafts reviewers create issue lists 5 - All people that read _all_ drafts (hopefully more than 5) will provide their motivated preference, say a top 3. Motivation is to be based on requirements. (There are folk who did proposal comparison. It would be good if those were reviewed and reposted at that time). 6- We compile a shortlist of 1 or 2 documents and work to technically improve those to get a consensus outcome. I am hesitant to spend to much face-2-face time on rehashing previous discussion. But if we manage to have some review done, issues identified, and preferences stated, we may actually be able to make real progress. I'd say that committed reviewers need anything between 1 to 3 days to do this work. Any comments, alternative approaches, takers? --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-9-99059975 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFEjrwXtN/ca3YJIocRAshxAKD6FTlBqkuMFnHaD4DqxWnX4prQ1ACgjcRR rtdVav8uCGOcUW/iu90PW/g= =Oxsy -----END PGP SIGNATURE----- --Apple-Mail-9-99059975-- -- to unsubscribe send a message to namedroppers-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 Jun 13 10:23:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq9nn-0004cB-Hi for dnsext-archive@lists.ietf.org; Tue, 13 Jun 2006 10:23:31 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq9nm-0007az-5L for dnsext-archive@lists.ietf.org; Tue, 13 Jun 2006 10:23:31 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fq9l1-000HNZ-9s for namedroppers-data@psg.com; Tue, 13 Jun 2006 14:20:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [81.91.160.27] (helo=denic.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fq9kz-000HMt-Kn for namedroppers@ops.ietf.org; Tue, 13 Jun 2006 14:20:37 +0000 Received: by unknown.office.denic.de (Postfix, from userid 501) id 8F8042F51A5; Tue, 13 Jun 2006 16:20:35 +0200 (CEST) Date: Tue, 13 Jun 2006 16:20:34 +0200 From: Peter Koch To: IETF DNSEXT WG Cc: Mark Townsley Subject: Re: nsid last call Message-ID: <20060613142034.GJ1232@unknown.office.denic.de> References: <448E7515.8080606@cisco.com> <04E573F9-1398-4AF0-AEF1-AF37A9A25465@NLnetLabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 On Tue, Jun 13, 2006 at 03:18:10PM +0200, Olaf M.Kolkman wrote: > The syntax and semantics of the content of the NSID option is > deliberately left outside the scope of this specification. It is > the prerogative of the server administrator to choose the NSID > content as long as the content is unique to each anycast instance > so that a remote user is able to match the NSID to the server > instance > over a series of queries. The NSID can be opaque and encoded sorry to disagree, but in the Paris meeting and subsequently in I explicitly asked to have this as dynamic as possible and neither were there any objections nor can I see much discussion, lest support for this 180 degree change. Please remove "as long as the content ... over a series of queries". > such that it > can be decoded by the server adminstrator to provide more > information. > This section describe some of the kinds of data that server > administrators [...] The rest of the more verbose explanation is fine, 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 Wed Jun 14 10:20:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqWEH-0006gl-OM for dnsext-archive@lists.ietf.org; Wed, 14 Jun 2006 10:20:21 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqWEG-0002R5-Fr for dnsext-archive@lists.ietf.org; Wed, 14 Jun 2006 10:20:21 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqWAx-00013D-CY for namedroppers-data@psg.com; Wed, 14 Jun 2006 14:16:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqWAw-00012u-Oc for namedroppers@ops.ietf.org; Wed, 14 Jun 2006 14:16:55 +0000 Received: from [10.31.32.128] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k5EEGgrC094747; Wed, 14 Jun 2006 10:16:43 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <44DE321D-8835-4073-83B5-EB27C902DF4B@NLnetLabs.nl> References: <448E7515.8080606@cisco.com> <04E573F9-1398-4AF0-AEF1-AF37A9A25465@NLnetLabs.nl> <20060613142034.GJ1232@unknown.office.denic.de> <44DE321D-8835-4073-83B5-EB27C902DF4B@NLnetLabs.nl> Date: Wed, 14 Jun 2006 10:16:51 -0400 To: "Olaf M. Kolkman" From: Edward Lewis Subject: Re: nsid last call Cc: Peter Koch , IETF DNSEXT WG , Mark Townsley Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 At 14:37 +0200 6/14/06, Olaf M. Kolkman wrote: >Now for a fair way to get closure on this issue; Can you provide a link to the document? (The thread began as an "Re:" as far as I can tell.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-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 Jun 14 10:23:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqWHb-0008EF-UU for dnsext-archive@lists.ietf.org; Wed, 14 Jun 2006 10:23:47 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqUhz-0005uq-Lm for dnsext-archive@lists.ietf.org; Wed, 14 Jun 2006 08:42:57 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqUcS-000HWR-TJ for namedroppers-data@psg.com; Wed, 14 Jun 2006 12:37:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.154.224.54] (helo=grover.secret-wg.org) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqUcR-000HWD-EV for namedroppers@ops.ietf.org; Wed, 14 Jun 2006 12:37:11 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by grover.secret-wg.org (Postfix) with ESMTP id B415C5E68EE; Wed, 14 Jun 2006 14:37:15 +0200 (CEST) In-Reply-To: <20060613142034.GJ1232@unknown.office.denic.de> References: <448E7515.8080606@cisco.com> <04E573F9-1398-4AF0-AEF1-AF37A9A25465@NLnetLabs.nl> <20060613142034.GJ1232@unknown.office.denic.de> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-42-182742873" Message-Id: <44DE321D-8835-4073-83B5-EB27C902DF4B@NLnetLabs.nl> Cc: IETF DNSEXT WG , Mark Townsley Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: nsid last call Date: Wed, 14 Jun 2006 14:37:14 +0200 To: Peter Koch X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.750) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-42-182742873 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Jun 13, 2006, at 4:20 PM, Peter Koch wrote: > On Tue, Jun 13, 2006 at 03:18:10PM +0200, Olaf M.Kolkman wrote: > >> The syntax and semantics of the content of the NSID option is >> deliberately left outside the scope of this specification. It is >> the prerogative of the server administrator to choose the NSID >> content as long as the content is unique to each anycast >> instance >> so that a remote user is able to match the NSID to the server >> instance >> over a series of queries. The NSID can be opaque and encoded > > sorry to disagree, but in the Paris meeting and subsequently in > msg01347.html> > I explicitly asked to have this as dynamic as possible and neither > were > there any objections nor can I see much discussion, lest support > for this > 180 degree change. Please remove "as long as the content ... over a > series > of queries". Fair point Peter, I'm always happy to see you disagree and in this case you made me painfully and rightfully aware that this issue was in fact already explicitly brought up before last call and I had just forgot about it. Anyway, this causes a bit of dilemma since during this post last-call debate Dean made an argument in favor of being able to identify the any cast nodes as a client while you made the argument to hide instances behind an anycast based load sharing system. These are clearly conflicting. Now for a fair way to get closure on this issue; I think that a one person call in favor for identifying the any cast instances over a series of queries is not sufficient to overhaul an issue that was brought up pre-last call. On the other hand I'd like to give others the possibility support one of the two views. So, I will not close the issue yet. We leave it open for another few days and unless there is no clear consensus building for _not_ removing "as long as the content ... over a series of queries" I propose to converge to: 3.1. The NSID Payload The syntax and semantics of the content of the NSID option is deliberately left outside the scope of this specification. It is the prerogative of the server administrator to choose the NSID content. The NSID can be opaque and encoded such that it can be decoded by the server adminstrator to provide more information. This section describe some of the kinds of data that server administrators might choose to provide as the content of the NSID option, and explains the reasoning behind choosing a simple opaque byte string. (Silence or increased entropy do not constitute "clear consensus building for _not_ ... &c &c".) phewww, --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-42-182742873 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFEkAL6tN/ca3YJIocRAgjSAJ0UXVqfwb+BRqfnLqaKe6+rL2wI9QCfWLkE haEncccWinNBrYHgboQmvZk= =/LQH -----END PGP SIGNATURE----- --Apple-Mail-42-182742873-- -- to unsubscribe send a message to namedroppers-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 Jun 14 11:08:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqWyf-0000Cb-8F for dnsext-archive@lists.ietf.org; Wed, 14 Jun 2006 11:08:17 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqWyd-0002Hs-Nx for dnsext-archive@lists.ietf.org; Wed, 14 Jun 2006 11:08:17 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqWvG-0005Hc-Hw for namedroppers-data@psg.com; Wed, 14 Jun 2006 15:04:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqWvE-0005H7-7j for namedroppers@ops.ietf.org; Wed, 14 Jun 2006 15:04:44 +0000 Received: from [10.31.32.128] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k5EF4TES095038 for ; Wed, 14 Jun 2006 11:04:30 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Wed, 14 Jun 2006 11:04:37 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: A look at draft-...nsid-01.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 http://www.ietf.org/internet-drafts/draft-ietf-dnsext-nsid-01.txt Comments in line: Network Working Group R. Austein Internet-Draft ISC Expires: July 15, 2006 January 11, 2006 DNS Name Server Identifier Option (NSID) draft-ietf-dnsext-nsid-01 2.4. Presentation Format User interfaces MUST read and write the content of the NSID option as a sequence of hexadecimal digits, two digits per payload octet. ===== I don't see why this is a MUST. First litmus test - in what way does this impact interoperability? I do agree that a User Interface ought to be cautioned about displaying certain formats unchecked, i.e., displaying as HTML with embedded badness in it. ===== 3. Discussion o Using an arbitrary octet string gives name server operators yet another thing to configure, or mis-configure, or forget to configure. Having all the nodes in an anycast name server constellation identify themselves as "My Name Server" would not be particularly useful. ===== I can see usefulness in setting all of the servers to the same name - that is if I don't want anyone to differentiate amongst them, e.g., to prevent someone from knowing how many servers are there, behind a load balancer. (As if that matters anymore.) Keep in mind that many DNS constellations are already managed via a VPN, so in many cases, NOCs already would know of anomalies, or be able to identify which DNS server is misbehaving. ===== 3.3. User Interface Issues ... be useful. Thus, the presentation format must support arbitrary binary data. ===== That's more reasonable than "MUST present as". It's possible that an interface could try to interpret the bits and that's okay (so long as it doesn't launch an Javascript exploit, say.). ===== After looking at http://www.ops.ietf.org/lists/namedroppers/namedroppers.2005/msg01347.html: What I see missing is a limit on the length of the option. Is there any reason to leave it unbounded? An unbounded length opens the door to abuse. (I.e., I agree with the first point.) As far as the "open issue" - > On Tue, Jun 13, 2006 at 03:18:10PM +0200, Olaf M.Kolkman wrote: > >> The syntax and semantics of the content of the NSID option is >> deliberately left outside the scope of this specification. It is >> the prerogative of the server administrator to choose the NSID >> content as long as the content is unique to each anycast instance >> so that a remote user is able to match the NSID to the server >> instance over a series of queries. The NSID can be opaque and encoded I don't see that there is any reason to guarantee a remote user see a consistent reply from one process. Remote users aren't supposed to be able to prod the DNS constellation to reverse engineer it. Just like we see zone walking iN DNSSEC as undesirable or bad, providing a means to reverse a DNS constellation is undesirable. Although, frankly, if I didn't want to "expose" individual servers, I would just give them all the same NSID name, contrary to the part of section 3 I commented on. With the advent of dynamic update, I doubt we can ever require a server provide consistent answers over a series of queries. DNS isn't real-time, but it's hardly static. Bottom line, I don't see that there is a *responsibility* of a server operator to report to a remote user *anything* other than the data requested in the DNS. NSID is helpful to server operators, no doubt, but it is not for the benefit of the remote users. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From uhrdcrvv@tiger.livedoor.com Wed Jun 14 12:00:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXnQ-0001G5-Rp for dnsext-archive@lists.ietf.org; Wed, 14 Jun 2006 12:00:44 -0400 Received: from [221.209.128.174] (helo=lists.ietf.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FqXaN-0005eR-Qp for dnsext-archive@lists.ietf.org; Wed, 14 Jun 2006 11:47:17 -0400 To: From: =?iso-2022-jp?B?bWFyaW9u?= Subject: =?iso-2022-jp?B?GyRCIk0iTTBNTWobKEJObzEyNTYbJEIhISVhJUMlOyE8JTg8dT8uGyhC?= MIME-Version: 1.0 Reply-To: Content-Type:text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 3.6 (+++) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad $B%_%;%9%U%j!<$N5HB<$G$9!#(B $B$*@$OC$K$J$j$^$9!#(B $BB3$-$^$7$F!">R2p(BNo1256 $B0MMj;R$5$s$+$i%a%C%;!<%8$G$9!#(B ===$B$*L>A0(B=== $B@;L>;R$5$s!J(B35$B!K(B ===$B%3%a%s%H(B=== $B%M%C%H$G=P0)$$$rC5$9$N$ODq93$,$"$C$?$1$I!"M'?M$b$3$3$G$GM%$7$$H`$r(B $B8+$D$1$?$C$FJ9$$$?$N$GM&5$=P$7$F;22C$7$^$7$?!#IW$K$OFb=o$N%W%i%$%Y!<%H$,(B $BM_$7$$$G$9!#$b$A$m$s@dBPHkL)$G(B (>_<) From owner-namedroppers@ops.ietf.org Wed Jun 14 12:02:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXpX-0004Vc-R6 for dnsext-archive@lists.ietf.org; Wed, 14 Jun 2006 12:02:55 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqXpW-00006U-An for dnsext-archive@lists.ietf.org; Wed, 14 Jun 2006 12:02:55 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqXmW-0009xB-Vc for namedroppers-data@psg.com; Wed, 14 Jun 2006 15:59:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.154.224.54] (helo=grover.secret-wg.org) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqXmV-0009wo-C7 for namedroppers@ops.ietf.org; Wed, 14 Jun 2006 15:59:47 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by grover.secret-wg.org (Postfix) with ESMTP id 7E4A85E69C1; Wed, 14 Jun 2006 17:59:51 +0200 (CEST) In-Reply-To: References: <448E7515.8080606@cisco.com> <04E573F9-1398-4AF0-AEF1-AF37A9A25465@NLnetLabs.nl> <20060613142034.GJ1232@unknown.office.denic.de> <44DE321D-8835-4073-83B5-EB27C902DF4B@NLnetLabs.nl> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-51-194898831" Message-Id: <1F3A6B17-7705-4873-AC12-48CAE71E9C68@NLnetLabs.nl> Cc: Peter Koch , IETF DNSEXT WG , Mark Townsley Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: nsid last call Date: Wed, 14 Jun 2006 17:59:50 +0200 To: Edward Lewis X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.750) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-51-194898831 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Jun 14, 2006, at 4:16 PM, Edward Lewis wrote: > At 14:37 +0200 6/14/06, Olaf M. Kolkman wrote: > >> Now for a fair way to get closure on this issue; > > Can you provide a link to the document? (The thread began as an > "Re:" as far as I can tell.) Apologies, I messed up the subject header. The first mail in this thread (http://ops.ietf.org/lists/namedroppers/ namedroppers.2006/msg00735.html) should have been a continuation of the thread starting at: http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00684.html Hope this clarifies. --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-51-194898831 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFEkDJ2tN/ca3YJIocRAi3VAKCcjbivPAOtAKkjgArtlOa0M5Qh5gCgsNIm eD+hb4Wt/JCnnrJdU1CFYAU= =dyvs -----END PGP SIGNATURE----- --Apple-Mail-51-194898831-- -- to unsubscribe send a message to namedroppers-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 Jun 14 12:26:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqYCJ-0007uT-1j for dnsext-archive@lists.ietf.org; Wed, 14 Jun 2006 12:26:27 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqYCH-0002bi-IB for dnsext-archive@lists.ietf.org; Wed, 14 Jun 2006 12:26:27 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqY9I-000BwY-D9 for namedroppers-data@psg.com; Wed, 14 Jun 2006 16:23:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST,HTML_40_50,HTML_MESSAGE autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqY9H-000BwC-CE for namedroppers@ops.ietf.org; Wed, 14 Jun 2006 16:23:19 +0000 Received: from [10.31.32.128] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k5EGN2iu095432; Wed, 14 Jun 2006 12:23:03 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <1F3A6B17-7705-4873-AC12-48CAE71E9C68@NLnetLabs.nl> References: <448E7515.8080606@cisco.com> <04E573F9-1398-4AF0-AEF1-AF37A9A25465@NLnetLabs.nl> <20060613142034.GJ1232@unknown.office.denic.de> <44DE321D-8835-4073-83B5-EB27C902DF4B@NLnetLabs.nl> <1F3A6B17-7705-4873-AC12-48CAE71E9C68@NLnetLabs.nl> Date: Wed, 14 Jun 2006 12:23:09 -0400 To: "Olaf M. Kolkman" From: Edward Lewis Subject: Re: nsid last call Cc: Edward Lewis , Peter Koch , IETF DNSEXT WG , Mark Townsley Content-Type: multipart/alternative; boundary="============_-1061820301==_ma============" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 --============_-1061820301==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 17:59 +0200 6/14/06, Olaf M. Kolkman wrote: From: >http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00684.html I don't see the purpose of this change: # In section 2.3: # # OLD: # The OPTION-DATA for the NSID option is an opaque byte string the semantics of # which are deliberately left outside the protocol. # NEW: # The OPTION-DATA for the NSID option is an opaque byte string the semantics of # which are deliberately left outside the protocol. Implementations MUST # implement manual configuration of the NSID string. (Altering NSDID to NSID in the last line.) This does not impact interoperability (it's not in the protocol). Not all server implementations will need to do this, e.g., turnkey DNS code paths, code that is not distributed, etc. It some situations, hardcoding one value for this field may work quite well. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... --============_-1061820301==_ma============ Content-Type: text/html; charset="us-ascii" Re: nsid last call
At 17:59 +0200 6/14/06, Olaf M. Kolkman wrote:

From:

>http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00684.html

I don't see the purpose of this change:

# In section 2.3:
#
# OLD:
# The OPTION-DATA for the NSID option is an opaque byte string the semantics of
# which are deliberately left outside the protocol.
# NEW:
# The OPTION-DATA for the NSID option is an opaque byte string the semantics of
# which are deliberately left outside the protocol. Implementations MUST
# implement manual configuration of the NSID string.

(Altering NSDID to NSID in the last line.)

This does not impact interoperability (it's not in the protocol).

Not all server implementations will need to do this, e.g., turnkey DNS code paths, code that is not distributed, etc.  It some situations, hardcoding one value for this field may work quite well.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Nothin' more exciting than going to the printer to watch the toner drain...
--============_-1061820301==_ma============-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From few@mail.com Wed Jun 14 23:03:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqi9D-0005zU-TA for dnsext-archive@lists.ietf.org; Wed, 14 Jun 2006 23:03:55 -0400 Received: from [211.149.242.2] (helo=lists.ietf.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fqi99-0000FX-IL for dnsext-archive@lists.ietf.org; Wed, 14 Jun 2006 23:03:55 -0400 To: From: =?iso-2022-jp?B?ZmV3?= Subject: =?iso-2022-jp?B?GyRCJCIkayQiJGslOyVVJWxCYhsoQg==?= MIME-Version: 1.0 Reply-To: Content-Type:text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 4.2 (++++) X-Scan-Signature: 08e48e05374109708c00c6208b534009 $B%;%U%lH/7!$O$3$3$+$i!*(B $B40A4L5NA$G%$%C$A$c$$$^$9!*(B http://yahyahyah.info/aruaru ************************ bankcard@breakthru.com ************************ From owner-namedroppers@ops.ietf.org Wed Jun 14 23:33:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqibp-0006TI-3c for dnsext-archive@lists.ietf.org; Wed, 14 Jun 2006 23:33:29 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqibm-0001vL-L0 for dnsext-archive@lists.ietf.org; Wed, 14 Jun 2006 23:33:29 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqiXK-000Aew-FN for namedroppers-data@psg.com; Thu, 15 Jun 2006 03:28:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_ZOMBIE autolearn=no version=3.1.1 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqiXH-000Aec-AW for namedroppers@ops.ietf.org; Thu, 15 Jun 2006 03:28:47 +0000 Received: from [130.105.12.10] ([130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id k5F3STgf022408 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 14 Jun 2006 23:28:29 -0400 Date: Wed, 14 Jun 2006 23:28:28 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Peter Koch cc: IETF DNSEXT WG , Mark Townsley Subject: Re: nsid last call In-Reply-To: <20060613142034.GJ1232@unknown.office.denic.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.8 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 On Tue, 13 Jun 2006, Peter Koch wrote: > On Tue, Jun 13, 2006 at 03:18:10PM +0200, Olaf M.Kolkman wrote: > > > The syntax and semantics of the content of the NSID option is > > deliberately left outside the scope of this specification. It is > > the prerogative of the server administrator to choose the NSID > > content as long as the content is unique to each anycast instance > > so that a remote user is able to match the NSID to the server > > instance > > over a series of queries. The NSID can be opaque and encoded > > sorry to disagree, but in the Paris meeting and subsequently in > > I explicitly asked to have this as dynamic as possible and neither were > there any objections nor can I see much discussion, lest support for this > 180 degree change. Please remove "as long as the content ... over a series > of queries". This change is what has been discussed recently. I don't see that as a very great change, even though it may not be exactly what you wanted in Paris. I wasn't at Paris, so I don't know what was agreed there, but presumably review by a wider audience has its benefits.... Can you explain why this should be allowed to be changed on a per-packet basis? It is actaully very dynamic as I worded it. I can't see any good reason for there to be a secret as to how many anycast instances there are, nor can I see any good reason that remote users shouldn't be able to match the NSID to the server instance over a series of queries. I think I would object to the 'each query unique secret' version, with some good reasons for that. --Dean > > such that it > > can be decoded by the server adminstrator to provide more > > information. > > This section describe some of the kinds of data that server > > administrators > > [...] > > The rest of the more verbose explanation is fine, 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: > > -- 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 Thu Jun 15 07:21:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqpuM-00051n-6D for dnsext-archive@lists.ietf.org; Thu, 15 Jun 2006 07:21:06 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqpuK-0008FI-MG for dnsext-archive@lists.ietf.org; Thu, 15 Jun 2006 07:21:06 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fqpp4-0002kp-GP for namedroppers-data@psg.com; Thu, 15 Jun 2006 11:15:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.1.1 Received: from [195.177.253.212] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fqpp3-0002kU-Lr for namedroppers@ops.ietf.org; Thu, 15 Jun 2006 11:15:37 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 0F8ABC2E00; Thu, 15 Jun 2006 12:15:36 +0100 (BST) Date: Thu, 15 Jun 2006 12:15:25 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Dean Anderson , Peter Koch Cc: IETF DNSEXT WG , Mark Townsley , Alex Bligh Subject: Re: nsid last call Message-ID: <377A5284C7AA04A2F9313089@[192.168.100.25]> In-Reply-To: References: X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 --On 14 June 2006 23:28 -0400 Dean Anderson wrote: > I can't see any good reason for there to be a secret as to how many > anycast instances there are, nor can I see any good reason that remote > users shouldn't be able to match the NSID to the server instance over a > series of queries. I can see a reason. If you were trying to DDOS a set of anycast servers you might well like to know how many you had disabled. You could look at NSID for that. If someone wanted to hide the number of anycast servers, they could encrypt a server ID with a random number appended and use that as NSID. That way only persons in possession of a key could tell two servers apart. I'm not sure I'd want to do it myself, but I see no reason why NSID necessarily has to be the same between two packets. It simply means the server will not necessarily appear as a single server. 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 Jun 15 16:12:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqyCb-0007y1-I7 for dnsext-archive@lists.ietf.org; Thu, 15 Jun 2006 16:12:29 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqyCa-0005XW-78 for dnsext-archive@lists.ietf.org; Thu, 15 Jun 2006 16:12:29 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fqy8T-000GcH-33 for namedroppers-data@psg.com; Thu, 15 Jun 2006 20:08:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_ZOMBIE autolearn=no version=3.1.1 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fqy8R-000Gc2-RY for namedroppers@ops.ietf.org; Thu, 15 Jun 2006 20:08:12 +0000 Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id k5FK80Vf023371 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 15 Jun 2006 16:08:03 -0400 Date: Thu, 15 Jun 2006 16:08:00 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: Alex Bligh cc: Peter Koch , IETF DNSEXT WG , Mark Townsley Subject: Re: nsid last call In-Reply-To: <377A5284C7AA04A2F9313089@[192.168.100.25]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.8 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 On Thu, 15 Jun 2006, Alex Bligh wrote: > --On 14 June 2006 23:28 -0400 Dean Anderson wrote: > > > I can't see any good reason for there to be a secret as to how many > > anycast instances there are, nor can I see any good reason that remote > > users shouldn't be able to match the NSID to the server instance over a > > series of queries. > > I can see a reason. If you were trying to DDOS a set of anycast servers > you might well like to know how many you had disabled. You could look > at NSID for that. But it wouldn't tell you anything that a non-NSID response tells them: That there are still nameservers operating. So this isn't a good reason. > If someone wanted to hide the number of anycast servers, they could > encrypt a server ID with a random number appended and use that as NSID. > That way only persons in possession of a key could tell two servers > apart. Right: "hide the number of anycast servers". I see no good reason to do this. This draft exists so that anycast servers can be distinguished. Server administrators are not in need of NSID. They have etherreal, and server logs, and server debugging messages to tell them what is going on. NSID is so that non-server administrators can figure out what is going on. > I'm not sure I'd want to do it myself, but I see no reason why NSID > necessarily has to be the same between two packets. NSID is supposed to do that: distinguish between anycast instances. Disabling such distinction subverts the purpose of this draft. --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 Thu Jun 15 16:15:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqyFb-0000fl-BY for dnsext-archive@lists.ietf.org; Thu, 15 Jun 2006 16:15:35 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqyFa-0005im-1W for dnsext-archive@lists.ietf.org; Thu, 15 Jun 2006 16:15:35 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqyE3-000H2K-Gk for namedroppers-data@psg.com; Thu, 15 Jun 2006 20:13:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.1.1 Received: from [195.177.253.212] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqyE2-000H26-Je for namedroppers@ops.ietf.org; Thu, 15 Jun 2006 20:13:58 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 3A478C2DA9; Thu, 15 Jun 2006 21:13:53 +0100 (BST) Date: Thu, 15 Jun 2006 21:13:42 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Dean Anderson Cc: Peter Koch , IETF DNSEXT WG , Mark Townsley , Alex Bligh Subject: Re: nsid last call Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Dean, >> > I can't see any good reason for there to be a secret as to how many >> > anycast instances there are, nor can I see any good reason that remote >> > users shouldn't be able to match the NSID to the server instance over a >> > series of queries. >> >> I can see a reason. If you were trying to DDOS a set of anycast servers >> you might well like to know how many you had disabled. You could look >> at NSID for that. > > But it wouldn't tell you anything that a non-NSID response tells them: > That there are still nameservers operating. So this isn't a good reason. It tells you how many are no longer operating. In a unicast environment you have no way to know. > Server administrators are not in need of NSID. They have etherreal, and > server logs, and server debugging messages to tell them what is going on. > NSID is so that non-server administrators can figure out what is going on. > >> I'm not sure I'd want to do it myself, but I see no reason why NSID >> necessarily has to be the same between two packets. > > NSID is supposed to do that: distinguish between anycast instances. > Disabling such distinction subverts the purpose of this draft. The question is "allow whom to distinguish?". If you operate an array of unicast servers, and you have reports for (say) intermittent failures when a name is looked up from a client with IP address 1.2.3.4, you (as administrator) have no way of seeing which unicast server is being used without NSID. If in answer to the report, you say "OK, please send me the result of 'dig -t NSID blah'", this is enough as an administrator to help you, EVEN IF the result is insufficient to help the person reporting the data to you to understand what is going on. So, for instance, the client above could send back the result of the dig which contained an encrypted opaque value. He'd have no idea how many servers there were, etc, nor which one he'd be accessing. But when sent to the administrator, it could be deduced by decryption which the reporter was accessing. 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 Jun 15 16:37:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqyaq-0008Cu-9o for dnsext-archive@lists.ietf.org; Thu, 15 Jun 2006 16:37:32 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqyao-0006pj-TA for dnsext-archive@lists.ietf.org; Thu, 15 Jun 2006 16:37:32 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqyYJ-000IgH-FW for namedroppers-data@psg.com; Thu, 15 Jun 2006 20:34:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,INFO_TLD autolearn=no version=3.1.1 Received: from [207.219.45.62] (helo=mail.libertyrms.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqyYI-000Ig5-St for namedroppers@ops.ietf.org; Thu, 15 Jun 2006 20:34:54 +0000 Received: from wormhole2.int.libertyrms.com ([10.1.2.130] helo=trilby.local) by mail.libertyrms.com with esmtp (Exim 4.22) id 1FqyYI-0006sQ-7f for namedroppers@ops.ietf.org; Thu, 15 Jun 2006 16:34:54 -0400 Received: by trilby.local (Postfix, from userid 1019) id 22D181BA4DA; Thu, 15 Jun 2006 16:34:24 -0400 (EDT) Date: Thu, 15 Jun 2006 16:34:24 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: nsid last call Message-ID: <20060615203423.GB340@afilias.info> Reply-To: Andrew Sullivan References: <377A5284C7AA04A2F9313089@[192.168.100.25]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 X-SA-Exim-Mail-From: andrew@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 On Thu, Jun 15, 2006 at 04:08:00PM -0400, Dean Anderson wrote: > > I'm not sure I'd want to do it myself, but I see no reason why NSID > > necessarily has to be the same between two packets. > > NSID is supposed to do that: distinguish between anycast instances. Disabling > such distinction subverts the purpose of this draft. But as others have already argued, just because remote users can't make the distinction does not mean that nobody can distinguish them. It's supposed to make the instances distinguish_able_, not actually distinguished. A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 -- to unsubscribe send a message to namedroppers-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 Jun 15 16:44:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqyi0-0005Je-8v for dnsext-archive@lists.ietf.org; Thu, 15 Jun 2006 16:44:56 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqyhy-0008OJ-TG for dnsext-archive@lists.ietf.org; Thu, 15 Jun 2006 16:44:56 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fqygc-000JMJ-Hf for namedroppers-data@psg.com; Thu, 15 Jun 2006 20:43:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fqygb-000JM5-QH for namedroppers@ops.ietf.org; Thu, 15 Jun 2006 20:43:30 +0000 Received: from [192.168.1.100] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k5FKhGpd006705; Thu, 15 Jun 2006 16:43:17 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20060615203423.GB340@afilias.info> References: <377A5284C7AA04A2F9313089@[192.168.100.25]> <20060615203423.GB340@afilias.info> Date: Thu, 15 Jun 2006 16:43:28 -0400 To: Andrew Sullivan From: Edward Lewis Subject: Re: nsid last call Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 At 16:34 -0400 6/15/06, Andrew Sullivan wrote: >On Thu, Jun 15, 2006 at 04:08:00PM -0400, Dean Anderson wrote: >> > I'm not sure I'd want to do it myself, but I see no reason why NSID >> > necessarily has to be the same between two packets. >> >> NSID is supposed to do that: distinguish between anycast instances. >> Disabling such distinction subverts the purpose of this draft. > >But as others have already argued, just because remote users can't >make the distinction does not mean that nobody can distinguish them. >It's supposed to make the instances distinguish_able_, not actually >distinguished. I agree with Andrew. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-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 Jun 15 19:10:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr0yO-0002K0-FS for dnsext-archive@lists.ietf.org; Thu, 15 Jun 2006 19:10:00 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr0yN-0000XL-2H for dnsext-archive@lists.ietf.org; Thu, 15 Jun 2006 19:10:00 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fr0us-0004X7-Ho for namedroppers-data@psg.com; Thu, 15 Jun 2006 23:06:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_ZOMBIE autolearn=no version=3.1.1 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fr0ur-0004Wv-Dk for namedroppers@ops.ietf.org; Thu, 15 Jun 2006 23:06:21 +0000 Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id k5FN5tRH023485 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 15 Jun 2006 19:05:55 -0400 Date: Thu, 15 Jun 2006 19:05:55 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: Alex Bligh cc: Peter Koch , IETF DNSEXT WG , Mark Townsley Subject: Re: nsid last call In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.8 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 On Thu, 15 Jun 2006, Alex Bligh wrote: > Dean, > > >> > I can't see any good reason for there to be a secret as to how many > >> > anycast instances there are, nor can I see any good reason that remote > >> > users shouldn't be able to match the NSID to the server instance over a > >> > series of queries. > >> > >> I can see a reason. If you were trying to DDOS a set of anycast servers > >> you might well like to know how many you had disabled. You could look > >> at NSID for that. > > > > But it wouldn't tell you anything that a non-NSID response tells them: > > That there are still nameservers operating. So this isn't a good reason. > > It tells you how many are no longer operating. In a unicast environment > you have no way to know. It only tells you that some are still operating. The NSID doesn't tell you how many. But different NSIDs show that Anycast is in use. In a unicast environment, you absolutely have a way to know if a unicast server is operating: dig @. If you get a response back, the server is still operating. The "DOS" attack argument seems to be a red-herring, to me. There is no benefit to the DOS attacker from knowing that anycast is in use. Even if there was a benefit to DOS attackers, I don't think it would outweigh the benefit to legitimate users to know that anycast is in use. > > Server administrators are not in need of NSID. They have etherreal, and > > server logs, and server debugging messages to tell them what is going on. > > NSID is so that non-server administrators can figure out what is going on. > > > >> I'm not sure I'd want to do it myself, but I see no reason why NSID > >> necessarily has to be the same between two packets. > > > > NSID is supposed to do that: distinguish between anycast instances. > > Disabling such distinction subverts the purpose of this draft. > > The question is "allow whom to distinguish?". Obviously, allow non-server operators to distinguish. As I said, server operators can already distinguish. > If you operate an array of unicast servers, and you have reports for (say) > intermittent failures when a name is looked up from a client with IP address > 1.2.3.4, you (as administrator) have no way of seeing which unicast server is > being used without NSID. ???? This doesn't make sense to me. Unicast is not-anycast. NSID is meant to distinguish anycast servers. But plainly one can tell which unicast server is not responding..... NSID isn't invented to fix unicast problems. Its purpose is to fix anycast problems: the problem being that you can't tell which anycast instance responded to a particulary query. > If in answer to the report, you say "OK, please send me the result of 'dig -t > NSID blah'", this is enough as an administrator to help you, EVEN IF the > result is insufficient to help the person reporting the data to you to > understand what is going on. I don't think this is terribly helpful. With unicast servers, you don't need NSID, as you can say 'dig @ and get exactly what you need. > So, for instance, the client above could send back the result of the dig which > contained an encrypted opaque value. He'd have no idea how many servers there > were, etc, nor which one he'd be accessing. But when sent to the > administrator, it could be deduced by decryption which the reporter was > accessing. The user ___could___. But why? I wouldn't want to have to debug every client that has a problem. Your encrypted scheme requires the server administrators to figure out why a client has a network latency problem. Right now, with Unicast servers, they can figure that out for themselves. The goal of NSID is to have this same capability to distinguish anycast servers. As it is, we can't tell which one handled our query. --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 Thu Jun 15 19:12:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr10U-00034b-Ij for dnsext-archive@lists.ietf.org; Thu, 15 Jun 2006 19:12:10 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr10T-0000qZ-9E for dnsext-archive@lists.ietf.org; Thu, 15 Jun 2006 19:12:10 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fr0y3-0004hY-Ly for namedroppers-data@psg.com; Thu, 15 Jun 2006 23:09:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_ZOMBIE autolearn=no version=3.1.1 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fr0y3-0004hM-5h for namedroppers@ops.ietf.org; Thu, 15 Jun 2006 23:09:39 +0000 Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id k5FN9b34023488 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 15 Jun 2006 19:09:37 -0400 Date: Thu, 15 Jun 2006 19:09:37 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: Andrew Sullivan cc: namedroppers@ops.ietf.org Subject: Re: nsid last call In-Reply-To: <20060615203423.GB340@afilias.info> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.8 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 On Thu, 15 Jun 2006, Andrew Sullivan wrote: > On Thu, Jun 15, 2006 at 04:08:00PM -0400, Dean Anderson wrote: > > > I'm not sure I'd want to do it myself, but I see no reason why NSID > > > necessarily has to be the same between two packets. > > > > NSID is supposed to do that: distinguish between anycast instances. Disabling > > such distinction subverts the purpose of this draft. > > But as others have already argued, just because remote users can't > make the distinction does not mean that nobody can distinguish them. NSID is not useful if only server operators can make that distinction. As I said before, server operators already have sufficient tools for their own use. They aren't asking for NSID to debug their own servers. > It's supposed to make the instances distinguish_able_, not actually > distinguished. Its supposed to make them distinguished. --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 Jun 16 04:33:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr9ll-00065d-H4 for dnsext-archive@lists.ietf.org; Fri, 16 Jun 2006 04:33:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr9lk-00048j-4P for dnsext-archive@lists.ietf.org; Fri, 16 Jun 2006 04:33:33 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fr9gE-000JDV-4c for namedroppers-data@psg.com; Fri, 16 Jun 2006 08:27:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.1.1 Received: from [195.177.253.212] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fr9gD-000JDI-0g for namedroppers@ops.ietf.org; Fri, 16 Jun 2006 08:27:49 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id AC356C70BB; Fri, 16 Jun 2006 09:27:47 +0100 (BST) Date: Fri, 16 Jun 2006 09:27:36 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Dean Anderson Cc: Peter Koch , IETF DNSEXT WG , Mark Townsley , Alex Bligh Subject: Re: nsid last call Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 --On 15 June 2006 19:05 -0400 Dean Anderson wrote: > It only tells you that some are still operating. The NSID doesn't tell > you how many. But different NSIDs show that Anycast is in use. > Even if > there was a benefit to DOS attackers, I don't think it would outweigh the > benefit to legitimate users to know that anycast is in use. To be clear, that isn't true under my proposal (I don't know if that's why you are objecting to it). Different NSIDs could come from different servers on different IP addresses; each one could produce multiple NSIDs in order to make it appear that anycast was in use, when in fact it isn't (under my proposal). Yes, that means that a DNS infrastructure provider can analyse his own network without giving away to potential attackers whether or not there is Unicast in play, and if so how many unique servers there are. I appreciate that doesn't help what you characterize as "legitimate users" but currently they aren't helped at all. This allows the infrastructure provider to give away as much or as little information as they want to. Currently the choice for the operator is to give away all information or nothing. Given that in practice there are no RFC-police to go check up on what they are doing, and no client means of differentiating between opaque NSIDs and just very extensive anycast, producing opaque NSIDs is in any case going to be a practical proposition. So why outlaw it, when the effect may be to discourage operators from taking it up at all? It isn't as if it complicates the protocol. >> If you operate an array of unicast servers, and you have reports for >> (say) intermittent failures when a name is looked up from a client with >> IP address 1.2.3.4, you (as administrator) have no way of seeing which >> unicast server is being used without NSID. > > ???? This doesn't make sense to me. Unicast is not-anycast. NSID is > meant to distinguish anycast servers. Sorry - "if you operate an array of ANYCAST servers" - my typo (and "anycast" in the bottom line too. >> If in answer to the report, you say "OK, please send me the result of >> 'dig -t NSID blah'", this is enough as an administrator to help you, >> EVEN IF the result is insufficient to help the person reporting the data >> to you to understand what is going on. > > I don't think this is terribly helpful. With unicast servers, you don't > need NSID, as you can say 'dig @ and get exactly > what you need. My example probably makes more sense if you know I'm talking about anycast not unicast :-) Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 16 04:56:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrA7U-0000aQ-T1 for dnsext-archive@lists.ietf.org; Fri, 16 Jun 2006 04:56:00 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrA7T-0005NX-Dl for dnsext-archive@lists.ietf.org; Fri, 16 Jun 2006 04:56:00 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrA5S-000LGk-KA for namedroppers-data@psg.com; Fri, 16 Jun 2006 08:53:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [81.91.161.3] (helo=smtp.denic.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrA5J-000LGF-KH for namedroppers@ops.ietf.org; Fri, 16 Jun 2006 08:53:45 +0000 Received: from mail-int1.denic.de (mail-int1.denic.de [192.168.0.45]) by smtp.denic.de with esmtp id 1FrA5H-0005fy-Rs; Fri, 16 Jun 2006 10:53:43 +0200 Received: from localhost by mail-int1.denic.de with local id 1FrA5H-0001Ds-00; Fri, 16 Jun 2006 10:53:43 +0200 Date: Fri, 16 Jun 2006 10:53:43 +0200 From: Peter Koch To: IETF DNSEXT WG Subject: Re: nsid last call Message-ID: <20060616085343.GA29211@denics7.denic.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f On Thu, Jun 15, 2006 at 07:05:55PM -0400, Dean Anderson wrote: > The goal of NSID is to have this same capability to distinguish anycast servers. strictly speaking nsid is there to identify servers, not necessarily to distinguish them. More importantly, the draft makes it very clear that the only entity the payload has to have meaning for is the server operator. And, finally, we shouldn't mix policy with protocol here. Since an operator is free to enable nsid or not or to apply ACLs to the NSID feature, there's no gain in requiring that nsid blobs remain constant for a particular instance (however you define that). -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 16 07:20:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrCN9-0008JN-KN for dnsext-archive@lists.ietf.org; Fri, 16 Jun 2006 07:20:19 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrCN8-0004VP-B1 for dnsext-archive@lists.ietf.org; Fri, 16 Jun 2006 07:20:19 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrCJK-0005Ke-Q9 for namedroppers-data@psg.com; Fri, 16 Jun 2006 11:16:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,INFO_TLD autolearn=no version=3.1.1 Received: from [207.219.45.62] (helo=mail.libertyrms.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrCJK-0005KT-7G for namedroppers@ops.ietf.org; Fri, 16 Jun 2006 11:16:22 +0000 Received: from dba3.int.libertyrms.com ([10.1.3.12] helo=dba3.int.libertyrms.info ident=postfix) by mail.libertyrms.com with esmtp (Exim 4.22) id 1FrCJJ-0004X7-Hf for namedroppers@ops.ietf.org; Fri, 16 Jun 2006 07:16:21 -0400 Received: by dba3.int.libertyrms.info (ca.afilias.info, from userid 1019) id 113CC13744; Fri, 16 Jun 2006 07:16:21 -0400 (EDT) Date: Fri, 16 Jun 2006 07:16:21 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: nsid last call Message-ID: <20060616111620.GB17213@dba3> Reply-To: Andrew Sullivan References: <20060615203423.GB340@afilias.info> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-SA-Exim-Mail-From: andrew@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb On Thu, Jun 15, 2006 at 07:09:37PM -0400, Dean Anderson wrote: > > NSID is not useful if only server operators can make that distinction. That's not true, and in any case isn't the only possibility entailed by having the identifiers be opaque and changing. It is possible, for instance, that a server operator could allow some users, but not all, access to the mechanism for troubleshooting. This way, unknown users (who are possibly attackers) can't use the information in an attack, but known users can do their own troubleshooting. This might be a good model for a managed service provider, who can't give the user access to the network &c. > > It's supposed to make the instances distinguish_able_, not actually > > distinguished. > > Its supposed to make them distinguished. I don't see support for this stronger claim in the document. On the contrary, the discussion in section 3.1 points out that there are several different considerations that need to be taken into account, and one size does not fit all. If you think the document says otherwise, and can point to the text that supports that, I'm happy to be proven incorrect; but I think the idea that this document entails policy about what people divulge about their own servers is probably mistaken. A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 -- to unsubscribe send a message to namedroppers-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 Jun 16 10:04:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrEw3-0004g6-Ab for dnsext-archive@lists.ietf.org; Fri, 16 Jun 2006 10:04:31 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrEw3-000852-8Y for dnsext-archive@lists.ietf.org; Fri, 16 Jun 2006 10:04:31 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FrEvx-0003O6-Pg for dnsext-archive@lists.ietf.org; Fri, 16 Jun 2006 10:04:31 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrErn-000Hg8-OG for namedroppers-data@psg.com; Fri, 16 Jun 2006 14:00:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [216.151.192.200] (helo=sokol.elan.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrErk-000Hfk-Uc for namedroppers@ops.ietf.org; Fri, 16 Jun 2006 14:00:05 +0000 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id k5GE02eH023514; Fri, 16 Jun 2006 07:00:03 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id k5GE01mr023503; Fri, 16 Jun 2006 07:00:02 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Fri, 16 Jun 2006 07:00:00 -0700 (PDT) From: "william(at)elan.net" To: Andrew Sullivan cc: namedroppers@ops.ietf.org Subject: Re: nsid last call In-Reply-To: <20060616111620.GB17213@dba3> Message-ID: References: <20060615203423.GB340@afilias.info> <20060616111620.GB17213@dba3> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 On Fri, 16 Jun 2006, Andrew Sullivan wrote: > On Thu, Jun 15, 2006 at 07:09:37PM -0400, Dean Anderson wrote: >> >> NSID is not useful if only server operators can make that distinction. > > That's not true, and in any case isn't the only possibility entailed > by having the identifiers be opaque and changing. It is possible, > for instance, that a server operator could allow some users, but not > all, access to the mechanism for troubleshooting. This way, unknown > users (who are possibly attackers) can't use the information in an > attack, but known users can do their own troubleshooting. This might > be a good model for a managed service provider, who can't give the > user access to the network &c. Before making an assumption that NSID would be used in attack, could you perhaps explain how that is to be done and what benefit having it brings to the attacker that he oterwise could not do with existing other dns parameters? Now If the attack is indeed possible and helped by NSID that should be clearly stated in security consideratons with appropraite explanation. -- William Leibzon Elan Networks william@elan.net -- to unsubscribe send a message to namedroppers-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 Jun 16 10:32:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrFN6-00072p-D5 for dnsext-archive@lists.ietf.org; Fri, 16 Jun 2006 10:32:28 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrFN5-0001ci-1V for dnsext-archive@lists.ietf.org; Fri, 16 Jun 2006 10:32:28 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrFKW-000K3F-HP for namedroppers-data@psg.com; Fri, 16 Jun 2006 14:29:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrFKV-000K2r-JJ for namedroppers@ops.ietf.org; Fri, 16 Jun 2006 14:29:47 +0000 Received: from [10.31.32.128] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k5GETOPo015196; Fri, 16 Jun 2006 10:29:27 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 16 Jun 2006 10:28:02 -0400 To: Dean Anderson From: Edward Lewis Subject: Re: nsid last call Cc: Alex Bligh , Peter Koch , IETF DNSEXT WG , Mark Townsley Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a At 19:05 -0400 6/15/06, Dean Anderson wrote: >many. But different NSIDs show that Anycast is in use. Why does it matter if anycast is in use? Along the lines of why does it matter what implementation is in use? >Obviously, allow non-server operators to distinguish. As I said, server >operators can already distinguish. Why do the non-operators have to be able to tell? What business is it of theirs? If they have a problem with a response, and they present it to the operator, they don't need to know what instance gave it to them. I suppose there's a basic assumption that clients ought to be debugging problems in someone else's service. That may be the old way of doing things - when there was a common mode of operation on the Internet. It's foolhardy and rude to debug someone else's service problems. Fool hardy because you don't know the entire story - who else is experiencing problems? Maybe it's not the server but some odd-ball box at an ISP in the way. I've seen lots of weird problems in my day - including a half-working T-1 (back in the day) that worked just good enough to fool the router at the monitoring end but not good enough to carry data. Unless you sit at the service NOC, you're not going to be able to debug the most gnarly of problems. It's also rude, because it's a fine line between debugging someone else's service and probing for a weakness to exploit. A long time ago I used some proprietary code putting TCP/IP on a Vax. The code had bugs and so I filed a report with a diagnosis. My diagnosis was so detailed and "correct" (not a big deal, in those days the net was simple) they came back and accused me of stealing their source code. It took a mutual friend (like I said, small world then) to convince them that 1) I didn't have the code, 2) I did have deep knowledge of the problem and 3) they themselves had used the same variable names as appeared in Stevens' book. This wordy walk into the past is meant to say that I think the desire to allow a client to determine which or how many servers are out there is outmoded. It's as outmoded (for the same reasons) as leaving servers open for AXFR. This is the same as the NSEC3 debate, except this time it's the service, not the data, being exposed. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-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 Jun 16 10:35:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrFQA-0001AC-Vs for dnsext-archive@lists.ietf.org; Fri, 16 Jun 2006 10:35:38 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrFQ9-0002Ok-LO for dnsext-archive@lists.ietf.org; Fri, 16 Jun 2006 10:35:38 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrFOX-000KRQ-GX for namedroppers-data@psg.com; Fri, 16 Jun 2006 14:33:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,INFO_TLD autolearn=no version=3.1.1 Received: from [207.219.45.62] (helo=mail.libertyrms.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrFOW-000KR8-Hh for namedroppers@ops.ietf.org; Fri, 16 Jun 2006 14:33:56 +0000 Received: from dba3.int.libertyrms.com ([10.1.3.12] helo=dba3.int.libertyrms.info ident=postfix) by mail.libertyrms.com with esmtp (Exim 4.22) id 1FrFOW-0003gF-3n for namedroppers@ops.ietf.org; Fri, 16 Jun 2006 10:33:56 -0400 Received: by dba3.int.libertyrms.info (ca.afilias.info, from userid 1019) id 6C02E13744; Fri, 16 Jun 2006 10:33:55 -0400 (EDT) Date: Fri, 16 Jun 2006 10:33:55 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: nsid last call Message-ID: <20060616143355.GD22893@dba3> Reply-To: Andrew Sullivan References: <20060615203423.GB340@afilias.info> <20060616111620.GB17213@dba3> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-SA-Exim-Mail-From: andrew@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca On Fri, Jun 16, 2006 at 07:00:00AM -0700, william(at)elan.net wrote: > > Before making an assumption that NSID would be used in attack, could > you perhaps explain how that is to be done and what benefit having > it brings to the attacker that he oterwise could not do with existing > other dns parameters? Someone has already pointed out that an attacker might use the information both to profile the servers offering the service, and to determine how successful an in-progress DoS is. Moreover, every experience we have with Internet services tells us "don't advertise more information than is necessary for your purposes". I can't see why we should enshrine in this case a requirement that people advertise some minimum amount of information, when it might turn out to be useful to attackers in some circumstances. Note that the weaker version of the document, which says that the identifier is purely up to the server administrator, in no way precludes putting all the information you might want in the identifier. It is only the stronger formulation, which requires that the identifier be useful to remote (and potentially unknown) users that restricts the operator's choice. I'm not arguing that people who are using nsid should never expose information. I'm saying instead that, without thinking very long, I can come up with several scenarios where I can see good reasons not to have every stranger on the Net be able to figure out, consistently, exactly which server in a service they are talking to. My reading of the draft is that it currently allows operators to make the identifier sufficiently opaque that at least some people won't be able to use it for such consistent identification. I suspect the disagreement is that what I regard as a feature, others regard as a deficiency. I believe that those who want the stronger reading need to argue why the document should impose the more stringent requirement, and so far I haven't seen such an argument. A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 -- to unsubscribe send a message to namedroppers-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 Jun 16 12:22:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrH5L-0000nT-81 for dnsext-archive@lists.ietf.org; Fri, 16 Jun 2006 12:22:15 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrH5J-00043p-SA for dnsext-archive@lists.ietf.org; Fri, 16 Jun 2006 12:22:15 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrH2y-0004kM-J9 for namedroppers-data@psg.com; Fri, 16 Jun 2006 16:19:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrH2p-0004jo-Ka for namedroppers@ops.ietf.org; Fri, 16 Jun 2006 16:19:39 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 1C59F11425 for ; Fri, 16 Jun 2006 16:19:39 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Namedroppers WG Subject: Re: DNAME questions In-Reply-To: Your message of "Fri, 16 Jun 2006 11:27:50 -0400." References: X-Mailer: MH-E 7.93; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 16 Jun 2006 16:19:39 +0000 Message-ID: <25213.1150474779@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca "creeeeeeeeeeeeeeeaaaaaaaaaak." (opening the crypt.) > 1. Why does DNAME not match at the DNAME itself? > > I can certainly think of reasons why, but I was wondering what the > original reason was. since dname was cast in the shadow of cname, and a cname to itself is not useful, there was no expectation that a dname to itself would be useful. > 2. Does anyone know of any non-trivial production use of DNAME? > > I am curious about this for two reasons: a) if not, then the working group > might be free to modify how DNAME works (or deprecate it), b) if not, then > why not? Perhaps the working group should change DNAME to make it more > useful? well, there's which proved to my satisfaction that DNAME-as-deployed works pretty well. since it is deployed, i recommend that it be treated as "finished", and if the working group wants incompatible DNAME-like functionality, they start from scratch with a new type code (DNAME2 or whatever). if something new comes about and is more useful, then we can talk later on about deprecating DNAME. > 3. Would there be harm in allowing a DNAME and CNAME to both exist at the > same name? > > This is related to questions #1 and #4, actually. But since DNAMEs do not > match at the DNAME, does that mean that having a CNAME at the same name is > not harmful? yow. i would never have thought of that, but you're right, other than the implications for #4 (below). a node in the DNS graph is either an alias, or not. if it's an alias, then it can't contain any data of its own other than Secure DNS metadata (to validate the aliasness and alias target.) i think the corner cases for CNAME+DNAME at the same node would be ~numerous. > 4. Is it OK for caches to synthesize CNAMEs from cached DNAMEs? > > I believe that some implementations do this, but we did spend a lot of time > in DNSSEC trying to specify that caches should not synthesize negative > responses, nor use cached wildcard records to synthesize. Should DNAME be > any different? it was always intended that anyone possessing a cached DNAME could use it to act-as-if a CNAME existed. i think caches should be able to synthesize. -- to unsubscribe send a message to namedroppers-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 Jun 16 12:48:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrHUG-0001TF-9I for dnsext-archive@lists.ietf.org; Fri, 16 Jun 2006 12:48:00 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrGe7-00008L-Ps for dnsext-archive@lists.ietf.org; Fri, 16 Jun 2006 11:54:07 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FrGHI-0004bZ-48 for dnsext-archive@lists.ietf.org; Fri, 16 Jun 2006 11:30:34 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrGEl-0000Q4-B4 for namedroppers-data@psg.com; Fri, 16 Jun 2006 15:27:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,DNS_FROM_RFC_WHOIS,SPF_HELO_PASS, SPF_PASS autolearn=no version=3.1.1 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrGEi-0000Pi-PY for namedroppers@ops.ietf.org; Fri, 16 Jun 2006 15:27:52 +0000 Received: from [10.131.244.197] ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Fri, 16 Jun 2006 11:27:51 -0400 id 002CC097.4492CDF7.00003D42 Mime-Version: 1.0 (Apple Message framework v750) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Namedroppers WG From: David Blacka Subject: DNAME questions Date: Fri, 16 Jun 2006 11:27:50 -0400 X-Mailer: Apple Mail (2.750) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 I have a few questions about DNAME that I've been storing up. Since some folks are currently working on a 2672bis document, I thought that now might be a reasonable time to ask the list. 1. Why does DNAME not match at the DNAME itself? I can certainly think of reasons why, but I was wondering what the original reason was. 2. Does anyone know of any non-trivial production use of DNAME? I am curious about this for two reasons: a) if not, then the working group might be free to modify how DNAME works (or deprecate it), b) if not, then why not? Perhaps the working group should change DNAME to make it more useful? 3. Would there be harm in allowing a DNAME and CNAME to both exist at the same name? This is related to questions #1 and #4, actually. But since DNAMEs do not match at the DNAME, does that mean that having a CNAME at the same name is not harmful? 4. Is it OK for caches to synthesize CNAMEs from cached DNAMEs? I believe that some implementations do this, but we did spend a lot of time in DNSSEC trying to specify that caches should not synthesize negative responses, nor use cached wildcard records to synthesize. Should DNAME be any different? -- 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 Fri Jun 16 14:59:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrJXS-0003CR-3Z for dnsext-archive@lists.ietf.org; Fri, 16 Jun 2006 14:59:26 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrJXQ-0006e4-MH for dnsext-archive@lists.ietf.org; Fri, 16 Jun 2006 14:59:26 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrJTs-000H9q-Db for namedroppers-data@psg.com; Fri, 16 Jun 2006 18:55:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrJTr-000H9e-GW for namedroppers@ops.ietf.org; Fri, 16 Jun 2006 18:55:43 +0000 Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k5GIsVd1027551 for ; Fri, 16 Jun 2006 14:54:32 -0400 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.13.6/8.13.6) with SMTP id k5GIrdOj009546 for ; Fri, 16 Jun 2006 14:53:39 -0400 (EDT) From: "Scott Rose" To: Subject: RE: ISSUE 10: Use of RFC 2119 terminology, was Re: Pending issues for draft-ietf-dnsext-rollover-requirements-01 Date: Fri, 16 Jun 2006 14:54:07 -0400 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Importance: Normal In-Reply-To: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Suresh Krishnaswamy > > > ISSUE 10: Use of RFC 2119 terminology, NEW > > This document is to be used as guidance for selecting a rollover > solution. > It may well be that not all the requirements can be met in which case > trade-offs will be made. The use of 2119 terminology may be confusing > here and Olaf has proposed the following change: > > REMOVE: > The use of the RFC-2119 words in this version of document is > preliminary in nature and feedback is requested as to the correct > word to use for each of the requirements. > > ADD: > The use of RFC-2119 words in the requirements is intended to > unambiguously describe a requirement. If a tradeoff is to be made > between conflicting requirements when choosing for a solution the > requirement with MUST language will have higher preference than > requirements with SHOULD, MAY, or RECOMMEND language. It is understood > that a tradeoff may need to be made between requirements that both > contain MUST language. > Haven't seen much in the way of resolution on this topic, but I think it is unnecessary. Isn't a MUST always more important over a SHOULD? Any solution would require trade offs of some kind. Scott > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 16 15:32:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrK3n-0002Ya-PH for dnsext-archive@lists.ietf.org; Fri, 16 Jun 2006 15:32:51 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrK3m-0007t9-8J for dnsext-archive@lists.ietf.org; Fri, 16 Jun 2006 15:32:51 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrK1q-000Jcm-Ar for namedroppers-data@psg.com; Fri, 16 Jun 2006 19:30:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_ZOMBIE autolearn=no version=3.1.1 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrK1o-000JcO-Nt for namedroppers@ops.ietf.org; Fri, 16 Jun 2006 19:30:48 +0000 Received: from [130.105.12.10] ([130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id k5GJUZLI025344 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 16 Jun 2006 15:30:46 -0400 Date: Fri, 16 Jun 2006 15:30:34 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Peter Koch cc: IETF DNSEXT WG Subject: Re: nsid last call In-Reply-To: <20060616085343.GA29211@denics7.denic.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.8 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a On Fri, 16 Jun 2006, Peter Koch wrote: > On Thu, Jun 15, 2006 at 07:05:55PM -0400, Dean Anderson wrote: > > > The goal of NSID is to have this same capability to distinguish anycast servers. > > strictly speaking nsid is there to identify servers, not necessarily to > distinguish them. If you can't uniquely distinguish them, then they aren't identified. Identification implies uniqueness. If I show my drivers licence to 2 people, they should be able to agree it was me. Showing them each some incomparable encryption that only I can decode is not an identification. Moreover, this just seems to split hairs and ignore the history of this draft. Remember, that this proposal developed from the BIND CH query to return the server id. In 2002, dnsop-serverid-00 (http://ietfreport.isoc.org/all-ids/draft-ietf-dnsop-serverid-00.txt) was submitted. After 5 dnsop-serverid drafts, it is finally realized that this serverid scheme won't work for anycast, and a stateless EDNSO NSID is proposed in February, 2005. There is no talk of secrecy in any of these prior drafts. > More importantly, the draft makes it very clear that the only entity the > payload has to have meaning for is the server operator. I object to that notion as well. It has no basis in any prior history, and I certainly missed that change.... But my read was that they can encode information that only has meaning to them. This is in lieu of the implementation information. That did not mean that they can or should make it impossible for me to identify anycast instances. > And, finally, we shouldn't mix policy with protocol here. Since an operator is > free to enable nsid or not or to apply ACLs to the NSID feature, there's no > gain in requiring that nsid blobs remain constant for a particular instance > (however you define that). Absolutely there is a gain to have per-instance-constant blobs: One can tell if Anycast is in use, and if different anycast instances are returning different data. Or if it is Anycast is in use when stateful queries are being made. Anycast operators can't hide problems resulting from Anycast. Incidentally, adding non-constant NSIDs adds a new DDOS attack in that the calculation of a decryptable per-packet NSID is a cryptographic function that would take CPU resources to calculate. But since an operator is free to enable nsid or not, or apply ACLs, that seems to address any questions about its value to DDOS attackers. So there seems to be no valid reason that NSID should be variable and indistinguishable. That feature seems only to subvert the purpose of the draft. My view: If they enable NSID, it had better be a per-instance-constant identifier that everyone can see and agree is instance-unique. Subverting that notion is pretty significant. --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 Jun 16 15:36:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrK7H-0005cL-8U for dnsext-archive@lists.ietf.org; Fri, 16 Jun 2006 15:36:27 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrK7F-0008Bp-UC for dnsext-archive@lists.ietf.org; Fri, 16 Jun 2006 15:36:27 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrK4o-000Jua-0i for namedroppers-data@psg.com; Fri, 16 Jun 2006 19:33:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_ZOMBIE autolearn=no version=3.1.1 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrK4n-000JuH-D9 for namedroppers@ops.ietf.org; Fri, 16 Jun 2006 19:33:53 +0000 Received: from [130.105.12.10] ([130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id k5GJXkQk025347 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 16 Jun 2006 15:33:47 -0400 Date: Fri, 16 Jun 2006 15:33:46 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Edward Lewis cc: Alex Bligh , Peter Koch , IETF DNSEXT WG , Mark Townsley Subject: Re: nsid last call In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.8 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 On Fri, 16 Jun 2006, Edward Lewis wrote: > At 19:05 -0400 6/15/06, Dean Anderson wrote: > > >many. But different NSIDs show that Anycast is in use. > > Why does it matter if anycast is in use? Anycast causes a number of problems that are difficult to debug because one can't tell which response came from which server. That's why its important. That's why this draft exists. > Along the lines of why does it matter what implementation is in use? It doesn't. We agree that the implementation identification can be removed. > >Obviously, allow non-server operators to distinguish. As I said, server > >operators can already distinguish. > > Why do the non-operators have to be able to tell? What business is it of > theirs? This seems somewhat arrogant, to me. DNS is a collective operation. If my TCP or stateful queries are failing, and I should be able to figure out that Anycast is in use, and either arrange to not do stateful queries to those servers, or to complain to the operator that they are doing Anycast when stateful queries are needed. > If they have a problem with a response, and they present it to the operator, > they don't need to know what instance gave it to them. Yes, actually, they do need to know that. When I do testing of root anycast servers, I need to know if I'm hitting different instances. I can't do that now, which is why these drafts were proposed. --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 Jun 16 15:49:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrKKA-0007XI-0C for dnsext-archive@lists.ietf.org; Fri, 16 Jun 2006 15:49:46 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrKK8-0000dm-EB for dnsext-archive@lists.ietf.org; Fri, 16 Jun 2006 15:49:45 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrKIZ-000L8v-32 for namedroppers-data@psg.com; Fri, 16 Jun 2006 19:48:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM, NO_REAL_NAME autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrKIX-000L8j-OI for namedroppers@ops.ietf.org; Fri, 16 Jun 2006 19:48:06 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id k5GJlwbq016815 for ; Fri, 16 Jun 2006 15:47:58 -0400 (EDT) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id k5GJlwbx016814 for namedroppers@ops.ietf.org; Fri, 16 Jun 2006 15:47:58 -0400 (EDT) (envelope-from namedroppers) Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrHMJ-0006SH-Ej for namedroppers@ops.ietf.org; Fri, 16 Jun 2006 16:39:47 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 16 Jun 2006 17:39:46 +0100 X-IronPort-AV: i="4.06,143,1149462000"; d="scan'208"; a="4138118:sNHT31164720" In-Reply-To: <20060616085343.GA29211@denics7.denic.de> To: IETF DNSEXT WG Subject: Re: nsid last call MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: jad@nominet.org.uk Date: Fri, 16 Jun 2006 17:39:16 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 06/16/2006 05:39:13 PM, Serialize complete at 06/16/2006 05:39:13 PM Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f [ 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. ] Peter Koch wrote on 16/06/2006 09:53:43: > On Thu, Jun 15, 2006 at 07:05:55PM -0400, Dean Anderson wrote: > > > The goal of NSID is to have this same capability to distinguish > anycast servers. > > strictly speaking nsid is there to identify servers, not necessarily to > distinguish them. More importantly, the draft makes it very clear that > the only entity the payload has to have meaning for is the server operator. > And, finally, we shouldn't mix policy with protocol here. Since an operator I agree. Whatever reasons there are for or against having unique, constant or obscure content in the NSID it is a policy decision that should be made by the operator and has nothing to do with protocol. John ==== John Dickinson Nominet UK ==== -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 16 17:15:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrLfT-0003xZ-DX for dnsext-archive@lists.ietf.org; Fri, 16 Jun 2006 17:15:51 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrLfS-0003eC-3S for dnsext-archive@lists.ietf.org; Fri, 16 Jun 2006 17:15:51 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrLcP-0002ns-7W for namedroppers-data@psg.com; Fri, 16 Jun 2006 21:12:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS, SPF_SOFTFAIL autolearn=no version=3.1.1 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrLcO-0002nb-Bi for namedroppers@ops.ietf.org; Fri, 16 Jun 2006 21:12:40 +0000 Received: from monsoon.verisignlabs.com ([::ffff:172.25.170.10]) by mail.verisignlabs.com with esmtp; Fri, 16 Jun 2006 17:12:39 -0400 id 002CC141.44931EC7.0000247C Received: from mistral.verisignlabs.com (mistral.verisignlabs.com [10.131.244.205]) by monsoon.verisignlabs.com (Postfix) with ESMTP id ED03C137E64; Fri, 16 Jun 2006 17:12:38 -0400 (EDT) Date: Fri, 16 Jun 2006 17:12:38 -0400 From: Matt Larson To: "Olaf M. Kolkman" Cc: Peter Koch , IETF DNSEXT WG , Mark Townsley Subject: Re: nsid last call Message-ID: <20060616211238.GU5772@mistral.verisignlabs.com> References: <448E7515.8080606@cisco.com> <04E573F9-1398-4AF0-AEF1-AF37A9A25465@NLnetLabs.nl> <20060613142034.GJ1232@unknown.office.denic.de> <44DE321D-8835-4073-83B5-EB27C902DF4B@NLnetLabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <44DE321D-8835-4073-83B5-EB27C902DF4B@NLnetLabs.nl> User-Agent: Mutt/1.5.11 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 On Wed, 14 Jun 2006, Olaf M. Kolkman wrote: > 3.1. The NSID Payload > > The syntax and semantics of the content of the NSID option is > deliberately left outside the scope of this specification. It is > the prerogative of the server administrator to choose the NSID > content. The NSID can be opaque and encoded such that it > can be decoded by the server adminstrator to provide more > information. > This section describe some of the kinds of data that server > administrators > might choose to provide as the content of the NSID option, and > explains the reasoning behind choosing a simple opaque byte > string. > > > (Silence or increased entropy do not constitute "clear consensus > building for _not_ ... &c &c".) I can live with this text, although I prefer the original text. This whole thread is getting a bit silly, since the contents of the NSID payload is unenforceable, anyway. How about directing all this energy to reading the various trust anchor management proposals? Matt -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 16 17:34:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrLxs-0001I0-St for dnsext-archive@lists.ietf.org; Fri, 16 Jun 2006 17:34:52 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrLw2-0004Ma-OP for dnsext-archive@lists.ietf.org; Fri, 16 Jun 2006 17:33:00 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrLu4-00046D-0M for namedroppers-data@psg.com; Fri, 16 Jun 2006 21:30:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS, SPF_SOFTFAIL autolearn=no version=3.1.1 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrLu3-00045k-0k for namedroppers@ops.ietf.org; Fri, 16 Jun 2006 21:30:55 +0000 Received: from monsoon.verisignlabs.com ([::ffff:172.25.170.10]) by mail.verisignlabs.com with esmtp; Fri, 16 Jun 2006 17:30:53 -0400 id 002CC13B.4493230D.000029BF Received: from mistral.verisignlabs.com (mistral.verisignlabs.com [10.131.244.205]) by monsoon.verisignlabs.com (Postfix) with ESMTP id C2E51137E64; Fri, 16 Jun 2006 17:30:53 -0400 (EDT) Date: Fri, 16 Jun 2006 17:30:53 -0400 From: Matt Larson To: Paul Vixie Cc: Namedroppers WG Subject: Re: DNAME questions Message-ID: <20060616213053.GV5772@mistral.verisignlabs.com> References: <25213.1150474779@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <25213.1150474779@sa.vix.com> User-Agent: Mutt/1.5.11 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 On Fri, 16 Jun 2006, Paul Vixie wrote: > > 1. Why does DNAME not match at the DNAME itself? > > > > I can certainly think of reasons why, but I was wondering what the > > original reason was. > > since dname was cast in the shadow of cname, and a cname to itself is not > useful, there was no expectation that a dname to itself would be useful. I believe you have perhaps misunderstood Dave's question. He's not asking about a DNAME from one name pointing to the same name; rather, he's asking why DNAME synthesis/matching/whatever-we-call-it occurs below the DNAME owner name and not at it. For example, given: foo. DNAME bar. ...then obviously queries for ".foo" are rewritten to ".bar" for an arbitrary number of labels in . But queries for "foo" are not rewritten to "bar". Dave's question is: why was DNAME designed this way? One reason I've thought of is that this allows a DNAME at a zone apex. Is that a reason (or the reason) or is it something else? > > 2. Does anyone know of any non-trivial production use of DNAME? > > > > I am curious about this for two reasons: a) if not, then the working group > > might be free to modify how DNAME works (or deprecate it), b) if not, then > > why not? Perhaps the working group should change DNAME to make it more > > useful? > > well, there's > which proved to my satisfaction that DNAME-as-deployed works pretty well. > since it is deployed, i recommend that it be treated as "finished", and if > the working group wants incompatible DNAME-like functionality, they start > from scratch with a new type code (DNAME2 or whatever). if something new > comes about and is more useful, then we can talk later on about deprecating > DNAME. I would be interested to know if anyone is using the technique described in that document. Has anyone ever deployed or encountered a DNAME in a production environment? I haven't. I'm not trying to use this as an excuse to change or not change DNAME semantics. I'm mostly asking out of curiosity. > > 3. Would there be harm in allowing a DNAME and CNAME to both exist at the > > same name? > > > > This is related to questions #1 and #4, actually. But since DNAMEs do not > > match at the DNAME, does that mean that having a CNAME at the same name is > > not harmful? > > yow. i would never have thought of that, but you're right, other than the > implications for #4 (below). a node in the DNS graph is either an alias, > or not. if it's an alias, then it can't contain any data of its own other > than Secure DNS metadata (to validate the aliasness and alias target.) i > think the corner cases for CNAME+DNAME at the same node would be ~numerous. The reason for this question goes back to #1. If one truly wanted to alias everything from one node to another, including the node itslef, then one would theoretically need not only the DNAME but also a CNAME at the same node. The rule used to be "no other data at a CNAME". Now it's "no other data except security metadata at a CNAME". We could conceivably change it again. Since CNAME matches at the node only and DNAME matches below the node only, I don't immediately see a bunch of corner cases. > > 4. Is it OK for caches to synthesize CNAMEs from cached DNAMEs? > > > > I believe that some implementations do this, but we did spend a lot of time > > in DNSSEC trying to specify that caches should not synthesize negative > > responses, nor use cached wildcard records to synthesize. Should DNAME be > > any different? > > it was always intended that anyone possessing a cached DNAME could use it > to act-as-if a CNAME existed. i think caches should be able to synthesize. I agree, but I can't find any language in 2672 that explicitly allows synthesis from DNAME. That's at least one of the issues the rewrite needs to address. Matt -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 16 17:40:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrM3b-0005zo-7z for dnsext-archive@lists.ietf.org; Fri, 16 Jun 2006 17:40:47 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrM3Z-0005nB-RI for dnsext-archive@lists.ietf.org; Fri, 16 Jun 2006 17:40:47 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrM2A-0004kR-Dn for namedroppers-data@psg.com; Fri, 16 Jun 2006 21:39:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrM29-0004k4-EV for namedroppers@ops.ietf.org; Fri, 16 Jun 2006 21:39:17 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 0325311425 for ; Fri, 16 Jun 2006 21:39:17 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Namedroppers WG Subject: Re: DNAME questions In-Reply-To: Your message of "Fri, 16 Jun 2006 17:30:53 -0400." <20060616213053.GV5772@mistral.verisignlabs.com> References: <25213.1150474779@sa.vix.com> <20060616213053.GV5772@mistral.verisignlabs.com> X-Mailer: MH-E 7.93; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 16 Jun 2006 21:39:17 +0000 Message-ID: <73826.1150493957@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 > ... > foo. DNAME bar. > > ...then obviously queries for ".foo" are rewritten to > ".bar" for an arbitrary number of labels in . But > queries for "foo" are not rewritten to "bar". Dave's question is: why > was DNAME designed this way? > > One reason I've thought of is that this allows a DNAME at a zone apex. > Is that a reason (or the reason) or is it something else? ah. yes. it's to avoid a "DNAME and other data" problem that would otherwise occur. > > well, there's > ... > I would be interested to know if anyone is using the technique > described in that document. Has anyone ever deployed or encountered a > DNAME in a production environment? I haven't. 2001:4f8::/32 used it. > I'm not trying to use this as an excuse to change or not change DNAME > semantics. I'm mostly asking out of curiosity. > > > > 3. Would there be harm in allowing a DNAME and CNAME to both exist at the > > > same name? > ... > The rule used to be "no other data at a CNAME". Now it's "no other data > except security metadata at a CNAME". We could conceivably change it again. > Since CNAME matches at the node only and DNAME matches below the node only, > I don't immediately see a bunch of corner cases. at a minimum, since CNAME and NS can't coexist, you would not be able to use DNAME at a zone apex if you also wanted a CNAME. at a maximum, if we want to change it yet again, it'll cost an EDNS version number to prevent caching resolvers who would not understand "CNAME and other data" and who might be implemented internally in a way that the aliased node isn't fully instantiated and doesn't even have a place to hang the other data. (more or less the same way and for the same reason we try to keep such caches from seeing Secure DNS metadata.) in other words, lots of corner cases. but i agree that it's ~achievable. > > it was always intended that anyone possessing a cached DNAME could use it > > to act-as-if a CNAME existed. i think caches should be able to > > synthesize. > > I agree, but I can't find any language in 2672 that explicitly allows > synthesis from DNAME. That's at least one of the issues the rewrite > needs to address. suits me. note that i was worried about a cache doing this synthesis if the real zone had data below the DNAME and would know NOT to synthesize in that case, but marka talked me out of worrying about this, i just don't recall how. -- to unsubscribe send a message to namedroppers-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 Jun 16 17:59:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrMLe-000473-Ao for dnsext-archive@lists.ietf.org; Fri, 16 Jun 2006 17:59:26 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrMLc-0007h0-Sc for dnsext-archive@lists.ietf.org; Fri, 16 Jun 2006 17:59:26 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrMIs-00061h-RT for namedroppers-data@psg.com; Fri, 16 Jun 2006 21:56:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,DNS_FROM_RFC_WHOIS,SPF_HELO_PASS, SPF_PASS autolearn=no version=3.1.1 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrMIr-00061W-Vq for namedroppers@ops.ietf.org; Fri, 16 Jun 2006 21:56:34 +0000 Received: from [10.131.244.197] ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Fri, 16 Jun 2006 17:56:32 -0400 id 002CC140.44932910.0000312E In-Reply-To: <25213.1150474779@sa.vix.com> References: <25213.1150474779@sa.vix.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Namedroppers WG Content-Transfer-Encoding: 7bit From: David Blacka Subject: Re: DNAME questions Date: Fri, 16 Jun 2006 17:56:31 -0400 To: Paul Vixie X-Mailer: Apple Mail (2.750) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f On Jun 16, 2006, at 12:19 PM, Paul Vixie wrote: > "creeeeeeeeeeeeeeeaaaaaaaaaak." (opening the crypt.) > >> 1. Why does DNAME not match at the DNAME itself? >> >> I can certainly think of reasons why, but I was wondering what the >> original reason was. > > since dname was cast in the shadow of cname, and a cname to itself > is not > useful, there was no expectation that a dname to itself would be > useful. I was asking why a DNAME doesn't (essentially) act as a CNAME at the ownername. And, in particular, what was the thinking at the time, as opposed to the reasoning now. >> 2. Does anyone know of any non-trivial production use of DNAME? >> >> I am curious about this for two reasons: a) if not, then the >> working group >> might be free to modify how DNAME works (or deprecate it), b) if >> not, then >> why not? Perhaps the working group should change DNAME to make it >> more >> useful? > > well, there's tn-2002-1.txt> > which proved to my satisfaction that DNAME-as-deployed works pretty > well. > since it is deployed, i recommend that it be treated as "finished", > and if > the working group wants incompatible DNAME-like functionality, they > start > from scratch with a new type code (DNAME2 or whatever). if > something new > comes about and is more useful, then we can talk later on about > deprecating > DNAME. This doesn't answer my question at all. I'm not necessarily advocating changes to DNAME. I mostly want to know if DNAME has been found to be generally useful in actual practice, and if not, why not. >> 3. Would there be harm in allowing a DNAME and CNAME to both exist >> at the >> same name? >> >> This is related to questions #1 and #4, actually. But since >> DNAMEs do not >> match at the DNAME, does that mean that having a CNAME at the same >> name is >> not harmful? > > yow. i would never have thought of that, but you're right, other > than the > implications for #4 (below). a node in the DNS graph is either an > alias, > or not. if it's an alias, then it can't contain any data of its > own other > than Secure DNS metadata (to validate the aliasness and alias > target.) i > think the corner cases for CNAME+DNAME at the same node would be > ~numerous. I thought that the corner case for CNAME+anything really boiled down to a single corner case, so I'm not sure I share this view. AFAICT, for there to be an issue, your cache would have to be using a cached DNAME as a source of synthesis AND have seen a query for the DNAME itself first AND the target of the CNAME would have to have a DNAME. >> 4. Is it OK for caches to synthesize CNAMEs from cached DNAMEs? >> >> I believe that some implementations do this, but we did spend a >> lot of time >> in DNSSEC trying to specify that caches should not synthesize >> negative >> responses, nor use cached wildcard records to synthesize. Should >> DNAME be >> any different? > > it was always intended that anyone possessing a cached DNAME could > use it > to act-as-if a CNAME existed. i think caches should be able to > synthesize. But why this and not that? -- 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 Fri Jun 16 18:10:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrMWc-0005uO-3T for dnsext-archive@lists.ietf.org; Fri, 16 Jun 2006 18:10:46 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrL5g-00074n-RY for dnsext-archive@lists.ietf.org; Fri, 16 Jun 2006 16:38:52 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FrKc9-0000CY-Kq for dnsext-archive@lists.ietf.org; Fri, 16 Jun 2006 16:08:24 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrKZy-000Mjf-Ax for namedroppers-data@psg.com; Fri, 16 Jun 2006 20:06:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_ZOMBIE autolearn=no version=3.1.1 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrKZx-000MjQ-Ma for namedroppers@ops.ietf.org; Fri, 16 Jun 2006 20:06:05 +0000 Received: from [130.105.12.10] ([130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id k5GK62rB025377 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 16 Jun 2006 16:06:02 -0400 Date: Fri, 16 Jun 2006 16:06:01 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Alex Bligh cc: IETF DNSEXT WG Subject: Re: nsid last call In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.5 (--) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 On Fri, 16 Jun 2006, Alex Bligh wrote: > To be clear, that isn't true under my proposal (I don't know if that's why > you are objecting to it). Different NSIDs could come from different servers > on different IP addresses; each one could produce multiple NSIDs in order > to make it appear that anycast was in use, when in fact it isn't (under my > proposal). Yes, that means that a DNS infrastructure provider can analyse > his own network without giving away to potential attackers whether or not > there is Unicast in play, and if so how many unique servers there are. I > appreciate that doesn't help what you characterize as "legitimate users" > but currently they aren't helped at all. This allows the infrastructure > provider to give away as much or as little information as they want to. This sort of machination isn't what one would call "standard behavior". Its in the same category as spoofing OS tcp fingerprints (ala nmap) and that sort of thing. Clever, but not really something that needs to be defined in the standard. --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 Jun 16 19:15:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrNXi-0006OR-E3 for dnsext-archive@lists.ietf.org; Fri, 16 Jun 2006 19:15:58 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrNXg-0000eY-WD for dnsext-archive@lists.ietf.org; Fri, 16 Jun 2006 19:15:58 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrNTu-000BCx-4t for namedroppers-data@psg.com; Fri, 16 Jun 2006 23:12:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.1.1 Received: from [195.177.253.212] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrNTt-000BCi-D1 for namedroppers@ops.ietf.org; Fri, 16 Jun 2006 23:12:01 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 67AA6C2DAB; Sat, 17 Jun 2006 00:12:00 +0100 (BST) Date: Sat, 17 Jun 2006 00:11:55 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Dean Anderson Cc: IETF DNSEXT WG , Alex Bligh Subject: Re: nsid last call Message-ID: <44A20EBEB553FD57F04E0B8C@[192.168.100.25]> In-Reply-To: References: X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 --On 16 June 2006 16:06 -0400 Dean Anderson wrote: > This sort of machination isn't what one would call "standard behavior". > Its in the same category as spoofing OS tcp fingerprints (ala nmap) and > that sort of thing. Clever, but not really something that needs to be > defined in the standard. I agree. Does it need to be prohibited in the standard though? 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 Sat Jun 17 06:28:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrY2m-0001nC-CG for dnsext-archive@lists.ietf.org; Sat, 17 Jun 2006 06:28:44 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrY2k-0001Ti-Ny for dnsext-archive@lists.ietf.org; Sat, 17 Jun 2006 06:28:44 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrXyW-0003nZ-7q for namedroppers-data@psg.com; Sat, 17 Jun 2006 10:24:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrXyT-0003mh-UR for namedroppers@ops.ietf.org; Sat, 17 Jun 2006 10:24:18 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id k5HAOHYI004029; Sat, 17 Jun 2006 10:24:17 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id k5HAOEOx004028; Sat, 17 Jun 2006 10:24:14 GMT Date: Sat, 17 Jun 2006 10:24:14 +0000 From: bmanning@vacation.karoshi.com To: Paul Vixie Cc: Namedroppers WG Subject: Re: DNAME questions Message-ID: <20060617102414.GA3761@vacation.karoshi.com.> References: <25213.1150474779@sa.vix.com> <20060616213053.GV5772@mistral.verisignlabs.com> <73826.1150493957@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <73826.1150493957@sa.vix.com> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 > > > well, there's > > ... > > I would be interested to know if anyone is using the technique > > described in that document. Has anyone ever deployed or encountered a > > DNAME in a production environment? I haven't. > > 2001:4f8::/32 used it. 2002.ip6.int used it to map to 2002.ip6.arpa. (we could not get ICANN to do it for the ip6.int/ip6.arpa) 2001:478::/32 used it. --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 18 03:26:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Frrg1-0000db-Cl for dnsext-archive@lists.ietf.org; Sun, 18 Jun 2006 03:26:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Frrfz-0006rH-VJ for dnsext-archive@lists.ietf.org; Sun, 18 Jun 2006 03:26:33 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrraE-000LND-Ut for namedroppers-data@psg.com; Sun, 18 Jun 2006 07:20:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrraC-000LMy-QS for namedroppers@ops.ietf.org; Sun, 18 Jun 2006 07:20:32 +0000 Received: from drugs.dv.isc.org (localhost.isc.org [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 CF8C3E601F for ; Sun, 18 Jun 2006 07:20:31 +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.6/8.13.6) with ESMTP id k5I7KMI2003231; Sun, 18 Jun 2006 17:20:24 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200606180720.k5I7KMI2003231@drugs.dv.isc.org> To: David Blacka Cc: Namedroppers WG From: Mark Andrews Subject: Re: DNAME questions In-reply-to: Your message of "Fri, 16 Jun 2006 11:27:50 -0400." Date: Sun, 18 Jun 2006 17:20:22 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d > I have a few questions about DNAME that I've been storing up. Since > some folks are currently working on a 2672bis document, I thought > that now might be a reasonable time to ask the list. > > > 1. Why does DNAME not match at the DNAME itself? > > I can certainly think of reasons why, but I was wondering what the > original reason was. Yes. That allows you to deploy DNAME at the zone apex. The synthesised CNAME records don't break "no other data at a CNAME" rule. They play nice with 1034 caches. > 2. Does anyone know of any non-trivial production use of DNAME? > > I am curious about this for two reasons: a) if not, then the working > group might be free to modify how DNAME works (or deprecate it), b) > if not, then why not? Perhaps the working group should change DNAME > to make it more useful? DNAME has been used to renamed ip6.int to ip6.arpa. It has also been used to rename zones. The A6/DNAME examples to aid renumbering are equally applicable to AAAA/DNAME especially if you do delegations on the nibble boundary. > 3. Would there be harm in allowing a DNAME and CNAME to both exist at > the same name? > > This is related to questions #1 and #4, actually. But since DNAMEs > do not match at the DNAME, does that mean that having a CNAME at the > same name is not harmful? Yes. You couldn't query for a DNAME through a 1034 cache. > 4. Is it OK for caches to synthesize CNAMEs from cached DNAMEs? > > I believe that some implementations do this, but we did spend a lot > of time in DNSSEC trying to specify that caches should not synthesize > negative responses, nor use cached wildcard records to synthesize. > Should DNAME be any different? That was the design intent. That is why there cannot be any children of a DNAME. DNSSECbis aware servers MUST know about DNAME processing so that can validate synthesised answers. You can't, in general, synthesis from a cached wild names as you don't how what other names there are in the zone that would normally block synthesis. The same is not true for DNAME as we know there are no children of the name with the DNAME record. Mark > -- > 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: -- 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 Jun 18 10:58:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fryiu-0006U2-Vc for dnsext-archive@lists.ietf.org; Sun, 18 Jun 2006 10:58:00 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fryit-0001TR-Ip for dnsext-archive@lists.ietf.org; Sun, 18 Jun 2006 10:58:00 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FryeL-000LRs-C9 for namedroppers-data@psg.com; Sun, 18 Jun 2006 14:53:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.1 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FryeK-000LRc-7F for namedroppers@ops.ietf.org; Sun, 18 Jun 2006 14:53:16 +0000 Received: from [192.168.1.13] ([::ffff:70.110.18.119]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Sun, 18 Jun 2006 10:53:10 -0400 id 002CC0FB.449568D6.000058EA In-Reply-To: <200606180720.k5I7KMI2003231@drugs.dv.isc.org> References: <200606180720.k5I7KMI2003231@drugs.dv.isc.org> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <61597A95-168B-4FFB-9F53-BC460E53DC21@verisignlabs.com> Cc: Namedroppers WG Content-Transfer-Encoding: 7bit From: David Blacka Subject: Re: DNAME questions Date: Sun, 18 Jun 2006 10:53:06 -0400 To: Mark Andrews X-Mailer: Apple Mail (2.750) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc On Jun 18, 2006, at 3:20 AM, Mark Andrews wrote: > >> I have a few questions about DNAME that I've been storing up. Since >> some folks are currently working on a 2672bis document, I thought >> that now might be a reasonable time to ask the list. >> >> >> 1. Why does DNAME not match at the DNAME itself? >> >> I can certainly think of reasons why, but I was wondering what the >> original reason was. > > Yes. That allows you to deploy DNAME at the zone apex. The > synthesised CNAME records don't break "no other data at a > CNAME" rule. They play nice with 1034 caches. This is, of course, the reason that I thought of. But, why was there a desire to deploy the DNAME at the zone apex and not at the parent? >> 2. Does anyone know of any non-trivial production use of DNAME? >> >> I am curious about this for two reasons: a) if not, then the working >> group might be free to modify how DNAME works (or deprecate it), b) >> if not, then why not? Perhaps the working group should change DNAME >> to make it more useful? > > DNAME has been used to renamed ip6.int to ip6.arpa. It has > also been used to rename zones. The A6/DNAME examples to > aid renumbering are equally applicable to AAAA/DNAME especially > if you do delegations on the nibble boundary. > >> 3. Would there be harm in allowing a DNAME and CNAME to both exist at >> the same name? >> >> This is related to questions #1 and #4, actually. But since DNAMEs >> do not match at the DNAME, does that mean that having a CNAME at the >> same name is not harmful? > > Yes. You couldn't query for a DNAME through a 1034 cache. Why would you query for a DNAME? >> 4. Is it OK for caches to synthesize CNAMEs from cached DNAMEs? >> >> I believe that some implementations do this, but we did spend a lot >> of time in DNSSEC trying to specify that caches should not synthesize >> negative responses, nor use cached wildcard records to synthesize. >> Should DNAME be any different? > > That was the design intent. That is why there cannot be > any children of a DNAME. DNSSECbis aware servers MUST know > about DNAME processing so that can validate synthesised > answers. > > You can't, in general, synthesis from a cached wild names > as you don't how what other names there are in the zone > that would normally block synthesis. The same is not true > for DNAME as we know there are no children of the name with > the DNAME record. Some folks have expressed that idea that "caches don't do synthesis", which is possibly what they got out of the discussion around caches using NSEC records to synthesize negative responses. I'm just trying to reconcile this concept with reality. It is clear that having caches synthesize from a cached DNAME is *safe*, because it was defined to be safe. -- David Blacka Sr. Engineer VeriSign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 18 14:28:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fs20r-00012T-4s for dnsext-archive@lists.ietf.org; Sun, 18 Jun 2006 14:28:45 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fs20p-0002Dx-Pa for dnsext-archive@lists.ietf.org; Sun, 18 Jun 2006 14:28:45 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fs1x9-0007AC-2F for namedroppers-data@psg.com; Sun, 18 Jun 2006 18:24:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fs1x8-00079y-C1 for namedroppers@ops.ietf.org; Sun, 18 Jun 2006 18:24:54 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id A136811425 for ; Sun, 18 Jun 2006 18:24:53 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Namedroppers WG Subject: Re: DNAME questions In-Reply-To: Your message of "Sun, 18 Jun 2006 10:53:06 -0400." <61597A95-168B-4FFB-9F53-BC460E53DC21@verisignlabs.com> References: <200606180720.k5I7KMI2003231@drugs.dv.isc.org> <61597A95-168B-4FFB-9F53-BC460E53DC21@verisignlabs.com> X-Mailer: MH-E 7.93; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sun, 18 Jun 2006 18:24:53 +0000 Message-ID: <28669.1150655093@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 > > Yes. That allows you to deploy DNAME at the zone apex. The > > synthesised CNAME records don't break "no other data at a CNAME" rule. > > They play nice with 1034 caches. > > But, why was there a desire to deploy the DNAME at the zone apex and not at > the parent? probably it was developed by folks who were usually representing a child zone rather than a parent zone. being able to deploy at a zone apex gives greater autonomy to child zone administrators, while taking none away from parent zone administrators. > > Yes. You couldn't query for a DNAME through a 1034 cache. > > Why would you query for a DNAME? IIRC, the argument was not of the form "because we foresee a need to query for this type..." but rather "because we don't want to unnecessarily prohibit someone from querying for this type..." --- off topic response: > Some folks have expressed that idea that "caches don't do synthesis", which > is possibly what they got out of the discussion around caches using NSEC > records to synthesize negative responses. I'm just trying to reconcile this > concept with reality. > > It is clear that having caches synthesize from a cached DNAME is *safe*, > because it was defined to be safe. if we had it to do over again, everything synthesizable anywhere would be synthesizable everywhere, which ultimately means: wildcards wouldn't be synthetic at all, a covering-wildcard would be considered-responsive, and would be synthesized in the querying agent (or in gethostbyname etc). the fact that DNAME is designed to be safe in this way is wonderful... but it's 25 years too late to save wildcards, and 10 years too late to save NXDOMAIN. -- to unsubscribe send a message to namedroppers-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 Jun 18 19:11:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fs6Q2-0000fB-4P for dnsext-archive@lists.ietf.org; Sun, 18 Jun 2006 19:11:02 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fs6Q0-0008Iy-Jh for dnsext-archive@lists.ietf.org; Sun, 18 Jun 2006 19:11:02 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fs6M2-000NP5-Nv for namedroppers-data@psg.com; Sun, 18 Jun 2006 23:06:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fs6M1-000NOu-Tl for namedroppers@ops.ietf.org; Sun, 18 Jun 2006 23:06:54 +0000 Received: from drugs.dv.isc.org (localhost.isc.org [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 8B4AFE6020 for ; Sun, 18 Jun 2006 23:06:52 +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.6/8.13.6) with ESMTP id k5IN6lm3073428; Mon, 19 Jun 2006 09:06:48 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200606182306.k5IN6lm3073428@drugs.dv.isc.org> To: David Blacka Cc: Namedroppers WG From: Mark Andrews Subject: Re: DNAME questions In-reply-to: Your message of "Sun, 18 Jun 2006 10:53:06 -0400." <61597A95-168B-4FFB-9F53-BC460E53DC21@verisignlabs.com> Date: Mon, 19 Jun 2006 09:06:47 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 > > On Jun 18, 2006, at 3:20 AM, Mark Andrews wrote: > > > > >> I have a few questions about DNAME that I've been storing up. Since > >> some folks are currently working on a 2672bis document, I thought > >> that now might be a reasonable time to ask the list. > >> > >> > >> 1. Why does DNAME not match at the DNAME itself? > >> > >> I can certainly think of reasons why, but I was wondering what the > >> original reason was. > > > > Yes. That allows you to deploy DNAME at the zone apex. The > > synthesised CNAME records don't break "no other data at a > > CNAME" rule. They play nice with 1034 caches. > > This is, of course, the reason that I thought of. > > But, why was there a desire to deploy the DNAME at the zone apex and > not at the parent? Because all the nameservers for a zone with a DNAME have to support synthesizing the CNAMES. Say you wanted have "FOO.COM. DNAME BAR.COM." You would have to wait for all the COM servers to be upated and for the registry to accept DNAMES. Once the COM servers are updated and the registry process is updated to support adding DNAME (and everything else that normally appears there sans NS and SOA) then the delegation could be replaced. > >> 2. Does anyone know of any non-trivial production use of DNAME? > >> > >> I am curious about this for two reasons: a) if not, then the working > >> group might be free to modify how DNAME works (or deprecate it), b) > >> if not, then why not? Perhaps the working group should change DNAME > >> to make it more useful? > > > > DNAME has been used to renamed ip6.int to ip6.arpa. It has > > also been used to rename zones. The A6/DNAME examples to > > aid renumbering are equally applicable to AAAA/DNAME especially > > if you do delegations on the nibble boundary. > > > >> 3. Would there be harm in allowing a DNAME and CNAME to both exist at > >> the same name? > >> > >> This is related to questions #1 and #4, actually. But since DNAMEs > >> do not match at the DNAME, does that mean that having a CNAME at the > >> same name is not harmful? > > > > Yes. You couldn't query for a DNAME through a 1034 cache. > > Why would you query for a DNAME? Does it matter why? The problem is that you can't do it. > >> 4. Is it OK for caches to synthesize CNAMEs from cached DNAMEs? > >> > >> I believe that some implementations do this, but we did spend a lot > >> of time in DNSSEC trying to specify that caches should not synthesize > >> negative responses, nor use cached wildcard records to synthesize. > >> Should DNAME be any different? > > > > That was the design intent. That is why there cannot be > > any children of a DNAME. DNSSECbis aware servers MUST know > > about DNAME processing so that can validate synthesised > > answers. > > > > You can't, in general, synthesis from a cached wild names > > as you don't how what other names there are in the zone > > that would normally block synthesis. The same is not true > > for DNAME as we know there are no children of the name with > > the DNAME record. > > Some folks have expressed that idea that "caches don't do synthesis", > which is possibly what they got out of the discussion around caches > using NSEC records to synthesize negative responses. I'm just trying > to reconcile this concept with reality. Which was never a technical arguement. It was just people being cautious. DNAME synthesis is simple. A lot simpler than generating a negative response from a cached negative response for a different QNAME. > It is clear that having caches synthesize from a cached DNAME is > *safe*, because it was defined to be safe. And it was alway the intent that such synthesis occur. Synthesis in the cache. wildcard synthesis negative answer DNAME impossible possible possible - hard easy Mark > -- > David Blacka > Sr. Engineer VeriSign Applied Research -- 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 Jun 18 20:33:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fs7iG-0001mV-Ad for dnsext-archive@lists.ietf.org; Sun, 18 Jun 2006 20:33:56 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fs7iE-0007s7-Vv for dnsext-archive@lists.ietf.org; Sun, 18 Jun 2006 20:33:56 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fs7fS-00025q-KA for namedroppers-data@psg.com; Mon, 19 Jun 2006 00:31:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST,DNS_FROM_RFC_WHOIS,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.1 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fs7fR-00025f-Hn for namedroppers@ops.ietf.org; Mon, 19 Jun 2006 00:31:01 +0000 Received: from [192.168.1.104] ([::ffff:69.243.97.45]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Sun, 18 Jun 2006 20:31:00 -0400 id 002CC084.4495F044.00006635 In-Reply-To: <200606182306.k5IN6lm3073428@drugs.dv.isc.org> References: <200606182306.k5IN6lm3073428@drugs.dv.isc.org> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Namedroppers WG Content-Transfer-Encoding: 7bit From: David Blacka Subject: Re: DNAME questions Date: Sun, 18 Jun 2006 20:30:58 -0400 To: Mark Andrews X-Mailer: Apple Mail (2.750) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 On Jun 18, 2006, at 7:06 PM, Mark Andrews wrote: >> >> But, why was there a desire to deploy the DNAME at the zone apex and >> not at the parent? > > Because all the nameservers for a zone with a DNAME have > to support synthesizing the CNAMES. I.e., it is far easier to upgrade all of your nameservers than to get your parent to do so. Makes sense. >>>> 3. Would there be harm in allowing a DNAME and CNAME to both >>>> exist at >>>> the same name? >>>> >>>> This is related to questions #1 and #4, actually. But since DNAMEs >>>> do not match at the DNAME, does that mean that having a CNAME at >>>> the >>>> same name is not harmful? >>> >>> Yes. You couldn't query for a DNAME through a 1034 cache. >> >> Why would you query for a DNAME? > > Does it matter why? The problem is that you can't do it. Well, it only matters why if you are trying to figure out if having a CNAME at a DNAME is a practical or only theoretical problem. > >> It is clear that having caches synthesize from a cached DNAME is >> *safe*, because it was defined to be safe. > > And it was alway the intent that such synthesis occur. > > Synthesis in the cache. > > wildcard synthesis negative answer DNAME > impossible possible possible > - hard easy Excellent responses, all. I still don't know if there is any ongoing use of DNAME (all of the examples given no longer use it or no longer exist.) A few things about DNAME struck me as strange or sub-optimal. The main one is that you cannot use DNAME to completely move a zone, since you cannot move the zone apex. Hence my wondering if this could be solved by having a CNAME at the DNAME (and putting the DNAME at the parent), or if it would make sense to define a DNAME2 that matched at the DNAME. The other thing is that I've found that very few people seem to understand DNAME, and it also seems very sparsely used. So I wonder if this is because a) not enough software supports it, b) DNAME doesn't work quite the way people need it to to be useful, c) it suffers from a general lack of awareness (i.e., it would be used more if more widely known and understood), or d) it doesn't solve a problem that people actually have. -- David Blacka Sr. Engineer VeriSign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 18 21:29:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fs8Zm-0007Mi-Ov for dnsext-archive@lists.ietf.org; Sun, 18 Jun 2006 21:29:14 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fs8Zk-00027L-Dw for dnsext-archive@lists.ietf.org; Sun, 18 Jun 2006 21:29:14 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fs8V9-0002Ed-SN for namedroppers-data@psg.com; Mon, 19 Jun 2006 01:24:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fs8V9-0002EM-6d for namedroppers@ops.ietf.org; Mon, 19 Jun 2006 01:24:27 +0000 Received: from drugs.dv.isc.org (localhost.isc.org [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 10870E601F for ; Mon, 19 Jun 2006 01:24:25 +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.6/8.13.6) with ESMTP id k5J1OMZO097853; Mon, 19 Jun 2006 11:24:23 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200606190124.k5J1OMZO097853@drugs.dv.isc.org> To: David Blacka Cc: Namedroppers WG From: Mark Andrews Subject: Re: DNAME questions In-reply-to: Your message of "Sun, 18 Jun 2006 20:30:58 -0400." Date: Mon, 19 Jun 2006 11:24:22 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f > Excellent responses, all. I still don't know if there is any ongoing > use of DNAME (all of the examples given no longer use it or no longer > exist.) > > A few things about DNAME struck me as strange or sub-optimal. The > main one is that you cannot use DNAME to completely move a zone, > since you cannot move the zone apex. Hence my wondering if this > could be solved by having a CNAME at the DNAME (and putting the DNAME > at the parent), or if it would make sense to define a DNAME2 that > matched at the DNAME. > > The other thing is that I've found that very few people seem to > understand DNAME, and it also seems very sparsely used. So I wonder > if this is because a) not enough software supports it, b) DNAME > doesn't work quite the way people need it to to be useful, c) it > suffers from a general lack of awareness (i.e., it would be used more > if more widely known and understood), or d) it doesn't solve a > problem that people actually have. Just about every cases where you double load the same masterfile could be handled using DNAME. I think is it not used because of lack of awareness and because people mis-read RFC 3363. The later is very true within the IETF. 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 Sun Jun 18 22:13:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fs9GA-00035C-Ji for dnsext-archive@lists.ietf.org; Sun, 18 Jun 2006 22:13:02 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fs9G9-0005OS-6F for dnsext-archive@lists.ietf.org; Sun, 18 Jun 2006 22:13:02 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fs9Dn-0004nO-FD for namedroppers-data@psg.com; Mon, 19 Jun 2006 02:10:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fs9Dl-0004nA-P6 for namedroppers@ops.ietf.org; Mon, 19 Jun 2006 02:10:33 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id EF46911426 for ; Mon, 19 Jun 2006 02:10:32 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Namedroppers WG Subject: Re: DNAME questions In-Reply-To: Your message of "Sun, 18 Jun 2006 20:30:58 -0400." References: <200606182306.k5IN6lm3073428@drugs.dv.isc.org> X-Mailer: MH-E 7.93; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 19 Jun 2006 02:10:32 +0000 Message-ID: <89977.1150683032@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 > ... I still don't know if there is any ongoing use of DNAME > (all of the examples given no longer use it or no longer exist.) i don't know a way to find out. only an authority server could be sure that DNAMEs aren't in use, and most DNS characterization these days is done on query/response flows or inside of caches. and voluntary surveys of DNS data and usage are notoriously inaccurate. > A few things about DNAME struck me as strange or sub-optimal. The main one > is that you cannot use DNAME to completely move a zone, since you cannot > move the zone apex. Hence my wondering if this could be solved by having a > CNAME at the DNAME (and putting the DNAME at the parent), or if it would > make sense to define a DNAME2 that matched at the DNAME. if you want to complete move a zone, you can't instantiate it, there will not be an SOA. you'd have to completely move that zone's namespace, which is to say, you'd have to put a leaf-DNAME at the parent. i must be misunderstanding the complaint. > The other thing is that I've found that very few people seem to understand > DNAME, and it also seems very sparsely used. So I wonder if this is because > a) not enough software supports it, b) DNAME doesn't work quite the way > people need it to to be useful, c) it suffers from a general lack of > awareness (i.e., it would be used more if more widely known and understood), > or d) it doesn't solve a problem that people actually have. i'd say that (c) is most likely, and has led to (d) out of general ignorance. that is, if (c) is true now and stops being true, then (d) would also die out. -- to unsubscribe send a message to namedroppers-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 Jun 18 23:00:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fs9zy-0000RI-T6 for dnsext-archive@lists.ietf.org; Sun, 18 Jun 2006 23:00:22 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fs9zx-0008Kd-3H for dnsext-archive@lists.ietf.org; Sun, 18 Jun 2006 23:00:22 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fs9wZ-0007oQ-IR for namedroppers-data@psg.com; Mon, 19 Jun 2006 02:56:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,DNS_FROM_RFC_WHOIS,SPF_HELO_PASS, SPF_PASS autolearn=no version=3.1.1 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fs9wY-0007oA-Jj for namedroppers@ops.ietf.org; Mon, 19 Jun 2006 02:56:50 +0000 Received: from [192.168.1.13] ([::ffff:70.110.18.119]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Sun, 18 Jun 2006 22:56:49 -0400 id 002CC096.44961271.00000C2A In-Reply-To: <89977.1150683032@sa.vix.com> References: <200606182306.k5IN6lm3073428@drugs.dv.isc.org> <89977.1150683032@sa.vix.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5AED1106-BD97-48F0-8C4A-05ACABA32DF8@verisignlabs.com> Cc: Namedroppers WG Content-Transfer-Encoding: 7bit From: David Blacka Subject: Re: DNAME questions Date: Sun, 18 Jun 2006 22:56:47 -0400 To: Paul Vixie X-Mailer: Apple Mail (2.750) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac On Jun 18, 2006, at 10:10 PM, Paul Vixie wrote: >> ... I still don't know if there is any ongoing use of DNAME >> (all of the examples given no longer use it or no longer exist.) > > i don't know a way to find out. only an authority server could be > sure that > DNAMEs aren't in use, and most DNS characterization these days is > done on > query/response flows or inside of caches. and voluntary surveys of > DNS data > and usage are notoriously inaccurate. This is true. But, in this case, a few real-world, still active examples would go a long way. That is, it would make a huge difference (in my mind, at least) if a few folks just stood up and said "I use DNAME here because ..." I'm guessing that this mailing list isn't the place to find out, though. >> A few things about DNAME struck me as strange or sub-optimal. The >> main one >> is that you cannot use DNAME to completely move a zone, since you >> cannot >> move the zone apex. Hence my wondering if this could be solved by >> having a >> CNAME at the DNAME (and putting the DNAME at the parent), or if it >> would >> make sense to define a DNAME2 that matched at the DNAME. > > if you want to complete move a zone, you can't instantiate it, > there will not > be an SOA. you'd have to completely move that zone's namespace, > which is to > say, you'd have to put a leaf-DNAME at the parent. i must be > misunderstanding > the complaint. The issue is that you cannot move the *entire* namespace of the zone. These days there is frequently non-trivial content at the zone apex. I'm not convinced that this is actually a problem, but it does seem sub-optimal to me. >> The other thing is that I've found that very few people seem to >> understand >> DNAME, and it also seems very sparsely used. So I wonder if this >> is because >> a) not enough software supports it, b) DNAME doesn't work quite >> the way >> people need it to to be useful, c) it suffers from a general lack of >> awareness (i.e., it would be used more if more widely known and >> understood), >> or d) it doesn't solve a problem that people actually have. > > i'd say that (c) is most likely, and has led to (d) out of general > ignorance. > that is, if (c) is true now and stops being true, then (d) would > also die out. I think that (c) and (d) are mutually exclusive. Either there are problems that people actually have that are solved by DNAME or there are not. I'm not clear how increased awareness of DNAME leads to more problems. -- David Blacka Sr. Engineer VeriSign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 18 23:08:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsA7U-00040q-4f for dnsext-archive@lists.ietf.org; Sun, 18 Jun 2006 23:08:08 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsA7S-0000iA-Qh for dnsext-archive@lists.ietf.org; Sun, 18 Jun 2006 23:08:08 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsA5d-0008Xx-Dz for namedroppers-data@psg.com; Mon, 19 Jun 2006 03:06:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsA5c-0008Xd-Rs for namedroppers@ops.ietf.org; Mon, 19 Jun 2006 03:06:12 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 3488311426 for ; Mon, 19 Jun 2006 03:06:09 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Namedroppers WG Subject: Re: DNAME questions In-Reply-To: Your message of "Sun, 18 Jun 2006 22:56:47 -0400." <5AED1106-BD97-48F0-8C4A-05ACABA32DF8@verisignlabs.com> References: <200606182306.k5IN6lm3073428@drugs.dv.isc.org> <89977.1150683032@sa.vix.com> <5AED1106-BD97-48F0-8C4A-05ACABA32DF8@verisignlabs.com> X-Mailer: MH-E 7.93; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 19 Jun 2006 03:06:09 +0000 Message-ID: <98422.1150686369@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca > > if you want to complete[ly] move a zone, you can't instantiate it, there > > will not be an SOA. you'd have to completely move that zone's namespace, > > which is to say, you'd have to put a leaf-DNAME at the parent. i must be > > misunderstanding the complaint. > > The issue is that you cannot move the *entire* namespace of the zone. you can if you do it at the parent, but not if... > These days there is frequently non-trivial content at the zone apex. ...there's necessary non-trivial content inside the zone. what you're looking for sounds more like CNAME2 than DNAME2. that is, a fall-through for uninstantiated types. call it the "OTHER" RR. it would only match queries whose {QNAME,QCLASS} matched an existing node but whose {QNAME,QCLASS,QTYPE} did not match any existing RR's. sadly, there's no way to do this with authority-server synthesis, and no way to require caches or stubs or applications to be able to understand it any other way. if you were hoping to accomplish this with DNAME2, then i wonder what you thought the synthesized CNAMEs from the authority server would end up doing inside caches and applications. now, a DNAME2 that could synthesize an OTHER at the apex and a CNAME otherwise, would work, if OTHER could work, which it can't. > I'm not convinced that this is actually a problem, but it does seem > sub-optimal to me. > > >> The other thing is that I've found that very few people seem to > >> understand DNAME, and it also seems very sparsely used. So I wonder if > >> this is because a) not enough software supports it, b) DNAME doesn't work > >> quite the way people need it to to be useful, c) it suffers from a > >> general lack of awareness (i.e., it would be used more if more widely > >> known and understood), or d) it doesn't solve a problem that people > >> actually have. > > > > i'd say that (c) is most likely, and has led to (d) out of general > > ignorance. that is, if (c) is true now and stops being true, then (d) > > would also die out. > > I think that (c) and (d) are mutually exclusive. Either there are problems > that people actually have that are solved by DNAME or there are not. I'm > not clear how increased awareness of DNAME leads to more problems. a lot of people probably have a lot of problems that they don't recognize as being DNAME-soluble simply because they don't know about DNAME or have misunderstood the deprecation statements regarding A6 and bitstring labels. -- to unsubscribe send a message to namedroppers-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 Jun 18 23:29:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsARg-0005NF-Ux for dnsext-archive@lists.ietf.org; Sun, 18 Jun 2006 23:29:00 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsARf-0003oL-FA for dnsext-archive@lists.ietf.org; Sun, 18 Jun 2006 23:29:00 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsAP2-0009po-4g for namedroppers-data@psg.com; Mon, 19 Jun 2006 03:26:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_ZOMBIE autolearn=no version=3.1.1 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsAP0-0009pR-Uv for namedroppers@ops.ietf.org; Mon, 19 Jun 2006 03:26:15 +0000 Received: from [130.105.12.10] ([130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id k5J3PcL1003651 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 18 Jun 2006 23:25:39 -0400 Date: Sun, 18 Jun 2006 23:25:38 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Matt Larson , Alex Bligh cc: "Olaf M. Kolkman" , Peter Koch , IETF DNSEXT WG , Mark Townsley Subject: Re: nsid last call In-Reply-To: <44A20EBEB553FD57F04E0B8C@[192.168.100.25]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.8 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 On Fri, 16 Jun 2006, Matt Larson wrote: > On Wed, 14 Jun 2006, Olaf M. Kolkman wrote: > > 3.1. The NSID Payload > > > > The syntax and semantics of the content of the NSID option is > > deliberately left outside the scope of this specification. It is > > the prerogative of the server administrator to choose the NSID > > content. The NSID can be opaque and encoded such that it > > can be decoded by the server adminstrator to provide more > > information. > > This section describe some of the kinds of data that server > > administrators > > might choose to provide as the content of the NSID option, and > > explains the reasoning behind choosing a simple opaque byte > > string. > > > > > > (Silence or increased entropy do not constitute "clear consensus > > building for _not_ ... &c &c".) > > I can live with this text, although I prefer the original text. Do you mean the text I proposed? > This whole thread is getting a bit silly, since the contents of the > NSID payload is unenforceable, anyway. Well, of course that's true most of the time. But its not always true, e.g. root server operators who have legal agreements that compel them to comply with the standards. That's why I think this sort of business should be left out of the standard. Those people who want to do things with spoofing and hiding, obviously still can. But I don't want to see the root operators doing this sort thing. On Sat, 17 Jun 2006, Alex Bligh wrote: > --On 16 June 2006 16:06 -0400 Dean Anderson wrote: > > > This sort of machination isn't what one would call "standard behavior". > > Its in the same category as spoofing OS tcp fingerprints (ala nmap) and > > that sort of thing. Clever, but not really something that needs to be > > defined in the standard. > > I agree. Does it need to be prohibited in the standard though? As opposed to just omitted? Hmm. I think that it should at least be omitted, and strictly standard behavior should be that anycast instances are identified universally. But I could be happy with merely omitting it. However, in that case, we also need to remove the following text in section 3.1: o It could be some sort of dynamicly generated identifier so that only the name server operator could tell whether or not any two queries had been answered by the same server. --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 Mon Jun 19 00:24:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsBJX-0007Qw-QF for dnsext-archive@lists.ietf.org; Mon, 19 Jun 2006 00:24:39 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsBJW-0005F5-C2 for dnsext-archive@lists.ietf.org; Mon, 19 Jun 2006 00:24:39 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsBGS-000D4Q-C7 for namedroppers-data@psg.com; Mon, 19 Jun 2006 04:21:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,DNS_FROM_RFC_WHOIS,SPF_HELO_PASS, SPF_PASS autolearn=no version=3.1.1 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsBGR-000D4D-Kr for namedroppers@ops.ietf.org; Mon, 19 Jun 2006 04:21:27 +0000 Received: from [192.168.1.13] ([::ffff:70.110.18.119]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Mon, 19 Jun 2006 00:21:26 -0400 id 002CC114.44962646.00002026 In-Reply-To: <98422.1150686369@sa.vix.com> References: <200606182306.k5IN6lm3073428@drugs.dv.isc.org> <89977.1150683032@sa.vix.com> <5AED1106-BD97-48F0-8C4A-05ACABA32DF8@verisignlabs.com> <98422.1150686369@sa.vix.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Namedroppers WG Content-Transfer-Encoding: 7bit From: David Blacka Subject: Re: DNAME questions Date: Mon, 19 Jun 2006 00:21:24 -0400 To: Paul Vixie X-Mailer: Apple Mail (2.750) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b On Jun 18, 2006, at 11:06 PM, Paul Vixie wrote: >>> if you want to complete[ly] move a zone, you can't instantiate >>> it, there >>> will not be an SOA. you'd have to completely move that zone's >>> namespace, >>> which is to say, you'd have to put a leaf-DNAME at the parent. i >>> must be >>> misunderstanding the complaint. >> >> The issue is that you cannot move the *entire* namespace of the >> zone. > > you can if you do it at the parent, but not if... > >> These days there is frequently non-trivial content at the zone apex. > > ...there's necessary non-trivial content inside the zone. > > what you're looking for sounds more like CNAME2 than DNAME2. that is, > a fall-through for uninstantiated types. call it the "OTHER" RR. it > would only match queries whose {QNAME,QCLASS} matched an existing node > but whose {QNAME,QCLASS,QTYPE} did not match any existing RR's. > sadly, > there's no way to do this with authority-server synthesis, and no way > to require caches or stubs or applications to be able to understand it > any other way. if you were hoping to accomplish this with DNAME2, > then > i wonder what you thought the synthesized CNAMEs from the authority > server > would end up doing inside caches and applications. now, a DNAME2 that > could synthesize an OTHER at the apex and a CNAME otherwise, would > work, > if OTHER could work, which it can't. Not that I understood any of that, but it sounds way more complex that what I was thinking of. The behavior that I am thinking of would be accomplished if DNAME2 matched at (and below) its ownername. Or are you saying that that would not work? I will continue to state that I do not know if such behavior is necessary or desired, I'm just thinking about it. >>>> The other thing is that I've found that very few people seem to >>>> understand DNAME, and it also seems very sparsely used. So I >>>> wonder if >>>> this is because a) not enough software supports it, b) DNAME >>>> doesn't work >>>> quite the way people need it to to be useful, c) it suffers from a >>>> general lack of awareness (i.e., it would be used more if more >>>> widely >>>> known and understood), or d) it doesn't solve a problem that people >>>> actually have. >>> >>> i'd say that (c) is most likely, and has led to (d) out of general >>> ignorance. that is, if (c) is true now and stops being true, >>> then (d) >>> would also die out. >> >> I think that (c) and (d) are mutually exclusive. Either there are >> problems >> that people actually have that are solved by DNAME or there are >> not. I'm >> not clear how increased awareness of DNAME leads to more problems. > > a lot of people probably have a lot of problems that they don't > recognize > as being DNAME-soluble simply because they don't know about DNAME > or have > misunderstood the deprecation statements regarding A6 and bitstring > labels. yeah, that was (c). -- 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 Mon Jun 19 00:49:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsBhv-00021J-VU for dnsext-archive@lists.ietf.org; Mon, 19 Jun 2006 00:49:51 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsBhu-0006h2-Ig for dnsext-archive@lists.ietf.org; Mon, 19 Jun 2006 00:49:51 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsBfR-000ESy-UC for namedroppers-data@psg.com; Mon, 19 Jun 2006 04:47:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsBfR-000ESm-BC for namedroppers@ops.ietf.org; Mon, 19 Jun 2006 04:47:17 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id CAFDC11425 for ; Mon, 19 Jun 2006 04:47:16 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Namedroppers WG Subject: Re: DNAME questions In-Reply-To: Your message of "Mon, 19 Jun 2006 00:21:24 -0400." References: <200606182306.k5IN6lm3073428@drugs.dv.isc.org> <89977.1150683032@sa.vix.com> <5AED1106-BD97-48F0-8C4A-05ACABA32DF8@verisignlabs.com> <98422.1150686369@sa.vix.com> X-Mailer: MH-E 7.93; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 19 Jun 2006 04:47:16 +0000 Message-ID: <13204.1150692436@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 > Not that I understood any of that, but it sounds way more complex that what > I was thinking of. The behavior that I am thinking of would be accomplished > if DNAME2 matched at (and below) its ownername. Or are you saying that that > would not work? DNS is often more complex than it appears. Let me try again. DNAME works by synthesizing CNAMEs in the authority servers for the zone and optionally by synthesizing them in caches as well. (Note that when we start synthesizing CNAME from DNAME in caches, the TTL of the DNAME will function as a long-lived whiteout for any new names one wishes to introduce in the zone below the node of the DNAME, so such TTL's should be kept low, noting that TTL's do not decrement in authority servers and so the impact of this particular low TTL will be, um, low.) If DNAME2 were to arrive which was like DNAME in other ways but had the added feature of "matching at" rather than just "matching below" the node of the DNAME2, then authority servers (and who knows, perhaps caching servers too?) would be able to synthesize CNAME RRs for the node that the DNAME is at. Since anyone receiving this synthetic CNAME knows that a DNS node either is or is not an alias, and that this node is an alias, that it cannot contain other data, including most kinds of metadata, especially SOA. I find this assertion-by-implication of the nonexistence of a zone cut to be disturbing. I would also find it disturbing if I were to ask for MX and get a real answer (because there's an MX RRset there) and then I might ask for "A" and get back a DNAME2 and a synthesized CNAME (because there was no "A" there) and then I'd be left wondering, is that DNS node an alias, or is it not? > I will continue to state that I do not know if such behavior is necessary or > desired, I'm just thinking about it. I will continue to state only that this design choice wasn't stylistic, and to make a different choice you will need to be able to synthesize something besides CNAME in order to make the DNAME2 effective at its own DNS node but without the disturbing (to me) side effect of "turning that node into an alias". (And no, mandating a zero TTL on the synthetic CNAME won't fix it.) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 19 02:44:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsDUR-0004bl-Mx for dnsext-archive@lists.ietf.org; Mon, 19 Jun 2006 02:44:03 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsDUQ-0001pQ-7G for dnsext-archive@lists.ietf.org; Mon, 19 Jun 2006 02:44:03 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsDR5-000Lbc-8q for namedroppers-data@psg.com; Mon, 19 Jun 2006 06:40:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsDR4-000LbA-8f for namedroppers@ops.ietf.org; Mon, 19 Jun 2006 06:40:34 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 19 Jun 2006 07:40:32 +0100 X-IronPort-AV: i="4.06,149,1149462000"; d="scan'208"; a="4162245:sNHT31834668" In-Reply-To: To: Dean Anderson Cc: namedroppers@ops.ietf.org Subject: Re: nsid last call MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: Date: Mon, 19 Jun 2006 07:39:47 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 06/19/2006 07:39:56 AM, Serialize complete at 06/19/2006 07:39:56 AM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Dean Anderson wrote on 2006-06-19 04:25:38: > On Fri, 16 Jun 2006, Matt Larson wrote: > > > This whole thread is getting a bit silly, since the contents of the > > NSID payload is unenforceable, anyway. > > Well, of course that's true most of the time. But its not always > true, e.g. root > server operators who have legal agreements that compel them to comply with the > standards. That's why I think this sort of business should be left out of the > standard. Those people who want to do things with spoofing and hiding, > obviously still can. > > But I don't want to see the root operators doing this sort thing. That may be, but that's an issue which is completely outside the scope of the protocol. Specifying this in (or omitting it from) the protocol will not govern or control how it is used in the wild, by the root server operators or anyone else. > > I agree. Does it need to be prohibited in the standard though? > > As opposed to just omitted? Hmm. I think that it should at least be omitted, > and strictly standard behavior should be that anycast instances are identified > universally. But I could be happy with merely omitting it. However, in that > case, we also need to remove the following text in section 3.1: > > o It could be some sort of dynamicly generated identifier so that > only the name server operator could tell whether or not any two > queries had been answered by the same server. I think it's preferable to keep this in as an illustration of the degree to which the protocol is agnostic to payload content. [Nit: this should be "dynamically", not "dynamicly".] Geoff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 19 05:21:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsFxC-00053f-RS for dnsext-archive@lists.ietf.org; Mon, 19 Jun 2006 05:21:54 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsFxB-0002EB-CS for dnsext-archive@lists.ietf.org; Mon, 19 Jun 2006 05:21:54 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsFtB-0007Db-Ru for namedroppers-data@psg.com; Mon, 19 Jun 2006 09:17:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.1.1 Received: from [195.177.253.212] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsFtA-0007DL-MB for namedroppers@ops.ietf.org; Mon, 19 Jun 2006 09:17:44 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 0E132C2DA3; Mon, 19 Jun 2006 10:17:43 +0100 (BST) Date: Mon, 19 Jun 2006 10:17:34 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Dean Anderson , Matt Larson Cc: "Olaf M. Kolkman" , Peter Koch , IETF DNSEXT WG , Mark Townsley , Alex Bligh Subject: Re: nsid last call Message-ID: <0EDFAE67FFEB02D85CFB6326@[192.168.100.25]> In-Reply-To: References: X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 --On 18 June 2006 23:25 -0400 Dean Anderson wrote: >> I agree. Does it need to be prohibited in the standard though? > > As opposed to just omitted? Hmm. I think that it should at least be > omitted, and strictly standard behavior should be that anycast instances > are identified universally. But I could be happy with merely omitting > it. However, in that case, we also need to remove the following text in > section 3.1: > > o It could be some sort of dynamicly generated identifier so that > only the name server operator could tell whether or not any two > queries had been answered by the same server. The disadvantage of it being omitted completely is there is nothing to warn the potential NSID client user that they might be dynamically generated. This might confuse people - the latter is really just an illustration of what might happen in a payload reply such as "none of your business". I could also live with it being omitted though I would prefer some caveat for the receiver of packets. I agree we should not be seeking to imply that there is some sort of endorsement or recommendation for opaque NSID in the absence of current operational REQUIREMENT to mandate 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 Mon Jun 19 05:58:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsGWT-0006Vc-Pa for dnsext-archive@lists.ietf.org; Mon, 19 Jun 2006 05:58:21 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsGWS-0006zZ-7F for dnsext-archive@lists.ietf.org; Mon, 19 Jun 2006 05:58:21 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsGTg-000A5y-JO for namedroppers-data@psg.com; Mon, 19 Jun 2006 09:55:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.154.224.54] (helo=grover.secret-wg.org) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsGTf-000A5f-Cm for namedroppers@ops.ietf.org; Mon, 19 Jun 2006 09:55:27 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by grover.secret-wg.org (Postfix) with ESMTP id D74CF5E71F2; Mon, 19 Jun 2006 11:55:37 +0200 (CEST) In-Reply-To: <44DE321D-8835-4073-83B5-EB27C902DF4B@NLnetLabs.nl> References: <448E7515.8080606@cisco.com> <04E573F9-1398-4AF0-AEF1-AF37A9A25465@NLnetLabs.nl> <20060613142034.GJ1232@unknown.office.denic.de> <44DE321D-8835-4073-83B5-EB27C902DF4B@NLnetLabs.nl> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-89-605045198" Message-Id: <36D0F62B-7E0A-44E4-A0D7-2DFEEB45FC7A@NLnetLabs.nl> Cc: Mark Townsley Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: nsid last call Date: Mon, 19 Jun 2006 11:55:36 +0200 To: IETF DNSEXT WG X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.750) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-89-605045198 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Jun 14, 2006, at 2:37 PM, Olaf M. Kolkman wrote: > > I think that a one person call in favor for identifying the any > cast instances over a series of queries is not sufficient to > overhaul an issue that was brought up pre-last call. On the other > hand I'd like to give others the possibility support one of the two > views. So, I will not close the issue yet. We leave it open for > another few days and unless there is no clear consensus building > for _not_ removing "as long as the content ... over a series of > queries" I propose to converge to: > > > > 3.1. The NSID Payload > > The syntax and semantics of the content of the NSID option is > deliberately left outside the scope of this specification. It is > the prerogative of the server administrator to choose the NSID > content. The NSID can be opaque and encoded such that it > can be decoded by the server adminstrator to provide more > information. > This section describe some of the kinds of data that server > administrators > might choose to provide as the content of the NSID option, and > explains the reasoning behind choosing a simple opaque byte > string. > > > (Silence or increased entropy do not constitute "clear consensus > building for _not_ ... &c &c".) Kind Colleagues, I have seen the discussion develop over the last couple of days and I think it has converged to a point where arguments are being reiterated. I have not seen a clear consensus building for '_not_ removing "as long as the content ... over a series of queries"'. Hence I would like to request the editors to include the above version of 3.1 in the draft (modulo the possible "Strunk and White" and "Merriam-Webster" kind of corrections that are needed to turn the text into plain english). --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-89-605045198 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFElnSZtN/ca3YJIocRAnScAJ0f9VurBtolgnbzjyxdyXoqdxR8qACfXLq/ Dd5t8YjbfUzrYRXlKVJ/d2c= =HyBU -----END PGP SIGNATURE----- --Apple-Mail-89-605045198-- -- to unsubscribe send a message to namedroppers-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 Jun 19 12:37:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsMkH-00024x-Tm for dnsext-archive@lists.ietf.org; Mon, 19 Jun 2006 12:37:01 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsMkG-00011o-H3 for dnsext-archive@lists.ietf.org; Mon, 19 Jun 2006 12:37:01 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsMgJ-000E0E-Ap for namedroppers-data@psg.com; Mon, 19 Jun 2006 16:32:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,DNS_FROM_RFC_WHOIS,SPF_HELO_PASS, SPF_PASS autolearn=no version=3.1.1 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsMgI-000Dzz-8E for namedroppers@ops.ietf.org; Mon, 19 Jun 2006 16:32:54 +0000 Received: from [10.131.244.197] ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Mon, 19 Jun 2006 12:32:53 -0400 id 002C4105.4496D1B5.0000062B In-Reply-To: <13204.1150692436@sa.vix.com> References: <200606182306.k5IN6lm3073428@drugs.dv.isc.org> <89977.1150683032@sa.vix.com> <5AED1106-BD97-48F0-8C4A-05ACABA32DF8@verisignlabs.com> <98422.1150686369@sa.vix.com> <13204.1150692436@sa.vix.com> Mime-Version: 1.0 (Apple Message framework v750) X-Gpgmail-State: !signed Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Namedroppers WG Content-Transfer-Encoding: 7bit From: David Blacka Subject: Re: DNAME questions Date: Mon, 19 Jun 2006 12:32:51 -0400 To: Paul Vixie X-Mailer: Apple Mail (2.750) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 On Jun 19, 2006, at 12:47 AM, Paul Vixie wrote: >> Not that I understood any of that, but it sounds way more complex >> that what >> I was thinking of. The behavior that I am thinking of would be >> accomplished >> if DNAME2 matched at (and below) its ownername. Or are you saying >> that that >> would not work? > > DNS is often more complex than it appears. Let me try again. > > DNAME works by synthesizing CNAMEs in the authority servers for the > zone and > optionally by synthesizing them in caches as well. (Note that when > we start > synthesizing CNAME from DNAME in caches, the TTL of the DNAME will > function > as a long-lived whiteout for any new names one wishes to introduce > in the > zone below the node of the DNAME, so such TTL's should be kept low, > noting > that TTL's do not decrement in authority servers and so the impact > of this > particular low TTL will be, um, low.) I don't think that you are allowed to introduce *any* names below the DNAME, so I'm not sure what this "whiteout" you are speaking of is. > If DNAME2 were to arrive which was like DNAME in other ways but had > the added > feature of "matching at" rather than just "matching below" the node > of the > DNAME2, then authority servers (and who knows, perhaps caching > servers too?) > would be able to synthesize CNAME RRs for the node that the DNAME > is at. > Since anyone receiving this synthetic CNAME knows that a DNS node > either is > or is not an alias, and that this node is an alias, that it cannot > contain > other data, including most kinds of metadata, especially SOA. This hypothetical DNAME2 would, indeed, have to be the only RR at its ownername, just like CNAME (and thus must be in the parent, not at a zone apex). However, there could (and probably would be) a SOA at the *target* name. That is what I mean by moving the entire zone. I'm guessing one point of confusion here is that I'm not suggesting that if DNAME(2) matched at its ownername that it would *also* be present at the zone apex. > I find this assertion-by-implication of the nonexistence of a zone > cut to be > disturbing. I would also find it disturbing if I were to ask for > MX and get > a real answer (because there's an MX RRset there) and then I might > ask for "A" > and get back a DNAME2 and a synthesized CNAME (because there was no > "A" there) > and then I'd be left wondering, is that DNS node an alias, or is it > not? This behavior that you are describing certainly sounds interesting, but doesn't seem to have much to do with what I'm talking about. >> I will continue to state that I do not know if such behavior is >> necessary or >> desired, I'm just thinking about it. > > I will continue to state only that this design choice wasn't > stylistic, and > to make a different choice you will need to be able to synthesize > something > besides CNAME in order to make the DNAME2 effective at its own DNS > node but > without the disturbing (to me) side effect of "turning that node > into an > alias". (And no, mandating a zero TTL on the synthetic CNAME won't > fix it.) I did ask the question as to why DNAME didn't match at the DNAME itself, and the answers I got back from both you and Mark seemed stylistic to me. The reasons were good, but it didn't seem like the choice was forced by the protocol. If it were, then that would be very good to know. -- 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 Mon Jun 19 12:53:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsN0Z-0001rY-J7 for dnsext-archive@lists.ietf.org; Mon, 19 Jun 2006 12:53:51 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsN0X-0002pC-Tg for dnsext-archive@lists.ietf.org; Mon, 19 Jun 2006 12:53:51 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsMyK-000FQL-4I for namedroppers-data@psg.com; Mon, 19 Jun 2006 16:51:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsMyJ-000FPq-9F for namedroppers@ops.ietf.org; Mon, 19 Jun 2006 16:51:31 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id B782911426 for ; Mon, 19 Jun 2006 16:51:30 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Namedroppers WG Subject: Re: DNAME questions In-Reply-To: Your message of "Mon, 19 Jun 2006 12:32:51 -0400." References: <200606182306.k5IN6lm3073428@drugs.dv.isc.org> <89977.1150683032@sa.vix.com> <5AED1106-BD97-48F0-8C4A-05ACABA32DF8@verisignlabs.com> <98422.1150686369@sa.vix.com> <13204.1150692436@sa.vix.com> X-Mailer: MH-E 7.93; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 19 Jun 2006 16:51:30 +0000 Message-ID: <95960.1150735890@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 > > (Note that when we start synthesizing CNAME from DNAME in caches, the TTL > > of the DNAME will function as a long-lived whiteout for any new names one > > wishes to introduce in the zone below the node of the DNAME, so such TTL's > > should be kept low, noting that TTL's do not decrement in authority > > servers and so the impact of this particular low TTL will be, um, low.) > > I don't think that you are allowed to introduce *any* names below the > DNAME, so I'm not sure what this "whiteout" you are speaking of is. if you remove the DNAME from the authority zone you will still have to wait for the expiration of that DNAME's TTL in all caches before you can usefully add nodes in the authority zone before the DNS node where the DNAME had been. this seems obvious until you realize that as long as only authority servers were doing the DNAME->CNAME synthesis, it wasn't true. anything obvious that happens not to be true creates an opportunity and therefore a likelihood that some folks will depend on the contra-obvious behaviour. so, i'm just saying. > This hypothetical DNAME2 would, indeed, have to be the only RR at its > ownername, just like CNAME (and thus must be in the parent, not at a zone > apex). However, there could (and probably would be) a SOA at the *target* > name. That is what I mean by moving the entire zone. oh. ok. > I'm guessing one point of confusion here is that I'm not suggesting that if > DNAME(2) matched at its ownername that it would *also* be present at the > zone apex. indeed not. when you spoke of "renaming a zone" it made me think that the DNAME2 you wanted would have to be at the apex of some zone whose name you wanted to change. now i see that you want to "rename a zone-cut". oops. for this, most of us are currently using another set of NS RR's and just loading and serving the same relativised zone content at multiple namespaces. a DNAME2 that could only appear as a parent leaf and not a child apex is not as obvious to me as an authority-server per-zone option that just said "this relativised content should be made available under multiple zone namespaces, and does not need to be loaded into memory (or DB) more than once." but i admit i'm biased toward the perspective of child zone operations rather than delegation-only or mostly-delegation zone operations, and also biased by my perspective as a sometimes-implementor of name server software. there could be meat further up this bone that i'm not seeing. > I did ask the question as to why DNAME didn't match at the DNAME itself, > and the answers I got back from both you and Mark seemed stylistic to me. > The reasons were good, but it didn't seem like the choice was forced by > the protocol. If it were, then that would be very good to know. had DNAME matched the owner name of the DNAME, it would not be valid to use at a zone apex, where SOA and NS must also appear. so, still not stylistic. -- to unsubscribe send a message to namedroppers-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 Jun 19 16:46:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsQdl-0007OG-QX for dnsext-archive@lists.ietf.org; Mon, 19 Jun 2006 16:46:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsPpU-0001NH-GD for dnsext-archive@lists.ietf.org; Mon, 19 Jun 2006 15:54:38 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsPm6-000345-4z for namedroppers-data@psg.com; Mon, 19 Jun 2006 19:51:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [209.173.57.84] (helo=cypress.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsPm5-00033s-CW for namedroppers@ops.ietf.org; Mon, 19 Jun 2006 19:51:05 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k5JJo1mU030972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Jun 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FsPl3-0007YW-Jp; Mon, 19 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-signed-nonexistence-requirements-03.txt Message-Id: Date: Mon, 19 Jun 2006 15:50:01 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Requirements related to DNSSEC Signed Proof of Non-Existence Author(s) : R. Loomis, B. Laurie Filename : draft-ietf-dnsext-signed-nonexistence-requirements-03.txt Pages : 14 Date : 2006-6-19 DNSSEC-bis uses the NSEC record to provide authenticated denial of existence of RRsets. NSEC also has the side-effect of permitting zone enumeration, even if zone transfers have been forbidden. Because some see this as a problem, this document has been assembled to detail the possible requirements for denial of existence A/K/A signed proof of non-existence. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-signed-nonexistence-requirements-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-signed-nonexistence-requirements-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-signed-nonexistence-requirements-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-19114457.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-signed-nonexistence-requirements-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-signed-nonexistence-requirements-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-19114457.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 scventer@gmeas.com Mon Jun 19 19:24:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsT6j-0005Py-10 for dnsext-archive@ietf.org; Mon, 19 Jun 2006 19:24:37 -0400 Received: from 75.red-83-35-232.dynamicip.rima-tde.net ([83.35.232.75] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FsT6g-0000RB-J6 for dnsext-archive@ietf.org; Mon, 19 Jun 2006 19:24:37 -0400 Message-ID: <000001c693f7$61950880$0100007f@localhost> From: "William Wood" To: Subject: Three Steps to the Software You Need at the Prices You Want Date: Tue, 20 Jun 2006 01:24:43 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C693F7.61950880" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.0 (++++) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C693F7.61950880 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Special Offer Adobe Video Collection Adobe Premiere 1.5 Professional Adobe After Effects 6.5 Professional Adobe Audition 1.5 Adobe Encore DVD 1.5 $149.95 More Info >> Microsoft 2 in 1 MS Windows XP Pro MS Office 2003 Pro $99.95 More Info >> Microsoft + Adobe 3 in 1 MS Windows XP Pro MS Office 2003 Pro Adobe Acrobat 7.0 Professional $149.95 More Info >> Bestsellers Microsoft Office Professional Edition 2003 Rating: 6 reviews Retail price: $550.00 You save: $480.05 (87%) Our price: $69.95 [Add to cart] Microsoft Windows XP Professional Rating: 8 reviews Retail price: $200.00 You save: $150.05 (75%) Our price: $49.95 [Add to cart] Adobe Photoshop CS2 V 9.0 Rating: 3 reviews Retail price: $599.00 You save: $529.05 (88%) Our price: $69.95 [Add to cart] ------=_NextPart_000_0001_01C693F7.61950880 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable DS
Special Offer
Adobe Video Collection
  • Adobe Premiere 1.5 Professional
  • Adobe After Effects 6.5 Professional
  • Adobe Audition 1.5
  • Adobe Encore DVD 1.5
$149.95    
More Info >>
Microsoft 2 in 1
  • MS Windows XP Pro
  • MS Office 2003 Pro




$99.95    
More Info >>
Microsoft + Adobe 3 in 1
  • MS Windows XP Pro
  • MS Office 2003 Pro
  • Adobe Acrobat 7.0 Professional


$149.95    
More Info >>
Bestsellers
3D"" Microsoft Office Professional Edition 2003
Rating: 6 reviews
Retail price: $550.00
You save: $480.05 (87%)
Our price: $69.95		  

Add to cart

3D"" Microsoft Windows XP Professional
Rating: 8 reviews
Retail price: $200.00
You save: $150.05 (75%)
Our price: $49.95		  

Add to cart

3D"" Adobe Photoshop CS2 V 9.0
Rating: 3 reviews
Retail price: $599.00
You save: $529.05 (88%)
Our price: $69.95		  

Add to cart

------=_NextPart_000_0001_01C693F7.61950880-- From owner-namedroppers@ops.ietf.org Wed Jun 21 12:50:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft5uQ-00007a-IS for dnsext-archive@lists.ietf.org; Wed, 21 Jun 2006 12:50:30 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft5np-0000oT-HJ for dnsext-archive@lists.ietf.org; Wed, 21 Jun 2006 12:43:42 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ft5hk-000PPS-IV for namedroppers-data@psg.com; Wed, 21 Jun 2006 16:37:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ft5hj-000PP6-Ru for namedroppers@ops.ietf.org; Wed, 21 Jun 2006 16:37:24 +0000 Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:250:daff:fe82:1c39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id 30939BC for ; Wed, 21 Jun 2006 12:37:22 -0400 (EDT) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 7C8045C1D for ; Wed, 21 Jun 2006 12:37:21 -0400 (EDT) Date: Wed, 21 Jun 2006 12:37:21 -0400 From: Rob Austein To: IETF DNSEXT WG Subject: draft-austein-dnsext-relax-gratuitous-tsig-00.txt MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Message-Id: <20060621163721.7C8045C1D@thrintun.hactrn.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 draft-austein-dnsext-relax-gratuitous-tsig-00.txt, available from a fine Internet-Draft repository near you. In brief: GSS-TSIG is underspecified in a way that makes it difficult to interoperate without violating the spec. As the piece that's underspecified is also, as far as we can tell, both useless and annoying, the easiest fix would be to remove the underspecified piece, thus making a hideously complex mechanism a trifle simpler in the bargain. This is something the WG will have to address sooner or later as part of moving GSS-TSIG to Draft Standard; we're writing about it now because my co-author and I have some relevant recent experience. I've requested a few minutes on the agenda in Montr=E9al. -- to unsubscribe send a message to namedroppers-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 Jun 21 19:23:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtC2l-0004QG-JK for dnsext-archive@lists.ietf.org; Wed, 21 Jun 2006 19:23:31 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtC2j-00077w-Vn for dnsext-archive@lists.ietf.org; Wed, 21 Jun 2006 19:23:31 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtByZ-0002Qg-EL for namedroppers-data@psg.com; Wed, 21 Jun 2006 23:19:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [193.71.199.94] (helo=aibo.runbox.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtByY-0002QL-3f for namedroppers@ops.ietf.org; Wed, 21 Jun 2006 23:19:10 +0000 Received: from [10.9.9.131] (helo=garm.runbox.com) by greyhound.runbox.com with esmtp (Exim 4.34) id 1FtByO-0001Ay-CA; Thu, 22 Jun 2006 01:19:00 +0200 Received: from mail by garm.runbox.com with local (Exim 4.50) id 1FtByO-0004Eu-Aq; Thu, 22 Jun 2006 01:19:00 +0200 Content-Type: text/plain; charset="iso-8859-15" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [129.246.254.14] by secure.runbox.com with http (uid:258406) (RMM 4.0); Wed, 21 Jun 2006 23:19:00 GMT From: "David A. Wheeler" Reply-To: dwheeler@dwheeler.com To: namedroppers@ops.ietf.org CC: ben@algroup.co.uk, geoff@nominet.org.uk, roy@nominet.org.uk Subject: NSEC3 nit Date: Wed, 21 Jun 2006 19:19:00 -0400 (EDT) X-Sender: 258406 X-Mailer: RMM Message-Id: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de A quick nit on the NSEC3 May draft spec - in section 10, in the phrase "cannot by cryptographically proven", replace "by" with "be". I hope to send more meaty comments soon.. --- David A. Wheeler=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 Jun 21 19:34:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtCDH-0008El-SJ for dnsext-archive@lists.ietf.org; Wed, 21 Jun 2006 19:34:23 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtCDG-0007Ym-IW for dnsext-archive@lists.ietf.org; Wed, 21 Jun 2006 19:34:23 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtCBK-0003GE-2f for namedroppers-data@psg.com; Wed, 21 Jun 2006 23:32:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [193.71.199.94] (helo=aibo.runbox.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtCBJ-0003G1-Ab for namedroppers@ops.ietf.org; Wed, 21 Jun 2006 23:32:21 +0000 Received: from [10.9.9.130] (helo=fenris.runbox.com) by greyhound.runbox.com with esmtp (Exim 4.34) id 1FtCBH-0005dg-Gq; Thu, 22 Jun 2006 01:32:19 +0200 Received: from mail by fenris.runbox.com with local (Exim 4.50) id 1FtCBH-0005yj-Fm; Thu, 22 Jun 2006 01:32:19 +0200 Content-Type: text/plain; charset="iso-8859-15" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [129.246.254.14] by secure.runbox.com with http (uid:258406) (RMM 4.0); Wed, 21 Jun 2006 23:32:19 GMT From: "David A. Wheeler" Reply-To: dwheeler@dwheeler.com To: namedroppers@ops.ietf.org CC: ben@algroup.co.uk, geoff@nominet.org.uk, roy@nominet.org.uk Subject: Re: NSEC3 Issue 10: Potential DoS on Servers, Date: Wed, 21 Jun 2006 19:32:19 -0400 (EDT) X-Sender: 258406 X-Mailer: RMM Message-Id: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Earlier an "NSEC3 issue 10" was noted, saying: >Significantly more work is required for a name server to >respond to queries which require negative proofs using NSEC3 >than is required for a client to compose and send them. I don't understand this as an issue, and I'm concerned that I may be misunderstanding NSEC3. It seems to me that the whole point of the NSEC3 design is that all the hashes and signatures can be precomputed, offline. You don't want the signing key to BE on-line, and you cannot assert that hash ranges don't exist until you've computed ALL the valid hash values anyway. And the hash already includes the salt, iterations, etc. So I'd expect the entire chain of hash calculations and signing to be done off-line, where DoS is irrelevant. Thus, when a client sends a request, the server should be able to trivially determine the non-match, find the relevant NSEC3 key (a trivial binary search would be fine), and send the appropriate canned re= sponse. The computation in view is very trivial; I wouldn't expect any complex comp= utations to be done for an NSEC3 response by a sensible name server (at run time). Do I misunderstand things? If so, please enlighten me! --- David A. Wheeler=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 Jun 21 19:54:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtCX8-00049F-2I for dnsext-archive@lists.ietf.org; Wed, 21 Jun 2006 19:54:54 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtCX5-0000QO-I5 for dnsext-archive@lists.ietf.org; Wed, 21 Jun 2006 19:54:54 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtCV1-0004bV-7e for namedroppers-data@psg.com; Wed, 21 Jun 2006 23:52:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_NEUTRAL autolearn=no version=3.1.1 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtCUz-0004bF-V4 for namedroppers@ops.ietf.org; Wed, 21 Jun 2006 23:52:42 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id DA42333C1A; Thu, 22 Jun 2006 00:52:39 +0100 (BST) Message-ID: <4499DBD1.3040109@algroup.co.uk> Date: Thu, 22 Jun 2006 00:52:49 +0100 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: dwheeler@dwheeler.com CC: namedroppers@ops.ietf.org, geoff@nominet.org.uk, roy@nominet.org.uk Subject: Re: NSEC3 Issue 10: Potential DoS on Servers, References: In-Reply-To: X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 David A. Wheeler wrote: > Earlier an "NSEC3 issue 10" was noted, saying: >> Significantly more work is required for a name server to >> respond to queries which require negative proofs using NSEC3 >> than is required for a client to compose and send them. > > I don't understand this as an issue, and I'm concerned that I may be > misunderstanding NSEC3. It seems to me that the whole point > of the NSEC3 design is that all the hashes and signatures can > be precomputed, offline. You don't want the signing key to BE on-line, > and you cannot assert that hash ranges don't exist until you've > computed ALL the valid hash values anyway. And the hash already includes > the salt, iterations, etc. So I'd expect the entire chain of hash > calculations and signing to be done off-line, where DoS is irrelevant. > > Thus, when a client sends a request, the server should be able to > trivially determine the non-match, find the relevant NSEC3 key > (a trivial binary search would be fine), and send the appropriate canned response. > The computation in view is very trivial; I wouldn't expect any complex computations > to be done for an NSEC3 response by a sensible name server (at run time). > > Do I misunderstand things? If so, please enlighten me! The problem is that the server has to calculate iterated hashes to find the right NSEC3 records. > > > --- David A. Wheeler > > -- http://www.apache-ssl.org/ben.html http://www.links.org/ "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 Wed Jun 21 20:57:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtDVf-0000pX-Ei for dnsext-archive@lists.ietf.org; Wed, 21 Jun 2006 20:57:27 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtDVd-0004bW-Rb for dnsext-archive@lists.ietf.org; Wed, 21 Jun 2006 20:57:27 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtDSS-00099Z-9E for namedroppers-data@psg.com; Thu, 22 Jun 2006 00:54:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [193.71.199.94] (helo=aibo.runbox.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtDSO-00097j-E3 for namedroppers@ops.ietf.org; Thu, 22 Jun 2006 00:54:04 +0000 Received: from [10.9.9.161] (helo=patch.runbox.com ident=Debian-exim) by greyhound.runbox.com with esmtp (Exim 4.34) id 1FtDSK-0006nO-CM; Thu, 22 Jun 2006 02:54:00 +0200 Received: from [129.246.254.14] (helo=[129.246.80.140]) by patch.runbox.com with esmtpsa (uid:258406 ) (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1FtDSK-0004EU-0e; Thu, 22 Jun 2006 02:54:00 +0200 Message-ID: <4499EA64.8090304@dwheeler.com> Date: Wed, 21 Jun 2006 20:55:00 -0400 From: "David A. Wheeler" User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: namedroppers@ops.ietf.org CC: Ben Laurie , geoff@nominet.org.uk, roy@nominet.org.uk Subject: Re: NSEC3 Issue 10: Potential DoS on Servers, and partial resolution: separate queue for not-found References: <4499DBD1.3040109@algroup.co.uk> In-Reply-To: <4499DBD1.3040109@algroup.co.uk> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Ben Laurie wrote: > The problem is that the server has to calculate iterated hashes to find the right NSEC3 records. > Ah! Of course! Perhaps that note, as well as noting that a server could use NSEC if this was the primary concern, could be put in the next version. I don't see any reasonable way to resolve this 100%. Even if you had requestors sending the iterated hash with the request (a MAJOR protocol change), you'd still have to redo the recalculation at the server end (without the trusted check, NSEC3 dissolves into NSEC). An attacker can just send random names and ruin any cache. There is a PARTIAL solution, though, that I suspect would be worth including as a suggestion in the spec. Something like this: "It is RECOMMENDED that DNS servers designed to withstand determined denial-of-service attacks selectively drop processing NSEC3 responses if necessary to be able to reasonably respond to queries where there is a valid name." Don't make this a "SHALL". In servers that do this, resolvers who DO request a valid name can get responses, while those who request an invalid name will get a "not-found" response unless the server is overloaded... but then, only the invalid names are dropped. There are lots of ways to do this, including separate queues, dropping if you've seen more than X not-found packets in a period, whatever. You might also recommend caching at the master server level some not-found values. That won't help against intentional attack, but there's always a few screwed-up or old values; servers that cache a few of them will have better performance, and that might help encourage deployment. (This isn't necessary at a master if the master isn't visible, and only negative-caching slaves are visible and used for queries, but I don't think that is ALWAYS the case.) E.G., "It is RECOMMENDED that master servers cache a few recent queries that resulted in not-found results, so that they need not recalculate the hash." Finally, no matter what, any hashing approach can be attacked through a dictionary. The salt and iterations are very helpful, but I think the following should be added: "Any hashing system can be attacked using a dictionary attack. The salt and iteration values make such attacks much more difficult, but those who are especially concerned about revealing names can make such attacks even more difficult by using longer, more difficult-to-guess names that are not obviously related to each other." --- David A. Wheeler -- to unsubscribe send a message to namedroppers-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 Jun 22 10:44:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtQPl-0002dQ-5J for dnsext-archive@lists.ietf.org; Thu, 22 Jun 2006 10:44:13 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtQPi-0002wt-MN for dnsext-archive@lists.ietf.org; Thu, 22 Jun 2006 10:44:13 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtQJp-000E3k-Kt for namedroppers-data@psg.com; Thu, 22 Jun 2006 14:38:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [193.71.199.94] (helo=aibo.runbox.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtQJo-000E3V-0N for namedroppers@ops.ietf.org; Thu, 22 Jun 2006 14:38:04 +0000 Received: from [10.9.9.131] (helo=garm.runbox.com) by greyhound.runbox.com with esmtp (Exim 4.34) id 1FtQJd-0006DS-4J; Thu, 22 Jun 2006 16:37:53 +0200 Received: from mail by garm.runbox.com with local (Exim 4.50) id 1FtQJd-0002bm-39; Thu, 22 Jun 2006 16:37:53 +0200 Content-Type: text/plain; charset="iso-8859-15" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [129.246.254.14] by secure.runbox.com with http (uid:258406) (RMM 4.0); Thu, 22 Jun 2006 14:37:53 GMT From: "David A. Wheeler" Reply-To: dwheeler@dwheeler.com To: ben@algroup.co.uk CC: namedroppers@ops.ietf.org, roy@nominet.org.uk, geoff@nominet.org.uk Subject: NSEC3 and the future Date: Thu, 22 Jun 2006 10:37:53 -0400 (EDT) X-Sender: 258406 X-Mailer: RMM References: <4499DBD1.3040109@algroup.co.uk> In-Reply-To: <4499DBD1.3040109@algroup.co.uk> Message-Id: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Thanks for the clarification. I view DNSSEC as critically important to Int= ernet security, but I've been concerned about the zone enumeration issue. Thus, I view NSEC3 as critically important as well, and I'm glad it's getti= ng done. I'm just reviewing it in the hopes that I can help in some way. There are two possible alternatives to NSEC3 (and NSEC) that I don't see noted, for those where zone confidentiality is especially critical; are there non-obvious horrors to these alternatives?: 1. What about permitting a name server to simply drop requests for names it doesn't have when it has a zone's data, e.g, no reply at all? Clearly that is NOT how things currently work, and that screws up caching for those without the complete zone, but it WOULD be a possi= bility. 2. What about having a separate signing key used ONLY for signing denial of existence? The risk is that when then server is subverted, y= ou can forge denial-of-existence as a DoS attack, but if it's limited to t= hat use, the attacker can't forge anything else... so for some that might be acc= eptable. That way, you can sign "that name doesn't exist" without giving away any other information. NSEC3 seems to me to strike a good balance between confidentiality and availability. I.E., it provides some confidentiality of zone names (now yo= u have to mount a dictionary/guessing attack, since you have only the hashes), while not requiring online signing keys (risking signed DoS's if broken int= o) and not just dropping requests for non-names. Option #1 screws up caching, and option #2 risks DoS. But I can imagine that for a small subset, perhaps those problems might be okay. Would it be reasonable to permit ("MAY") option #1, perhaps even just "slip= ped in" as part of NSEC3, and then consider option #2 as a potential future work it= em? Forgive me if this has been discussed before. --- David A. Wheeler -- to unsubscribe send a message to namedroppers-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 Jun 22 13:02:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtSZB-0000yT-SU for dnsext-archive@lists.ietf.org; Thu, 22 Jun 2006 13:02:05 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtSZA-0000vJ-HD for dnsext-archive@lists.ietf.org; Thu, 22 Jun 2006 13:02:05 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtSTR-000P4G-FG for namedroppers-data@psg.com; Thu, 22 Jun 2006 16:56:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtSTQ-000P3o-Ne for namedroppers@ops.ietf.org; Thu, 22 Jun 2006 16:56:08 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 4A60E11427 for ; Thu, 22 Jun 2006 16:56:06 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: NSEC3 and the future In-Reply-To: Your message of "Thu, 22 Jun 2006 10:37:53 -0400." References: <4499DBD1.3040109@algroup.co.uk> X-Mailer: MH-E 7.93; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 22 Jun 2006 16:56:06 +0000 Message-ID: <4811.1150995366@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa > I'm just reviewing it in the hopes that I can help in some way. welcome. > There are two possible alternatives to NSEC3 (and NSEC) that I don't see > noted, for those where zone confidentiality is especially critical; are > there non-obvious horrors to these alternatives?: yes. > 1. What about permitting a name server to simply drop requests for names it > doesn't have when it has a zone's data, e.g, no reply at all? Clearly that > is NOT how things currently work, and that screws up caching for those > without the complete zone, but it WOULD be a possibility. this blurs the necessary and important distinction between packet loss due to network overcommit/outage, packet loss due to intentional targetted attack, and assertion-of-nonexistence. without a bright line separating those three conditions from a requestor's point of view, the inevitable results will be (a) excessive useless retransmissions and (b) effective lack of authenticated denial of existence. > 2. What about having a separate signing key used ONLY for signing denial of > existence? The risk is that when then server is subverted, you can forge > denial-of-existence as a DoS attack, but if it's limited to that use, the > attacker can't forge anything else... so for some that might be acceptable. > That way, you can sign "that name doesn't exist" without giving away any > other information. this creates a new vector for authority server CPU attacks, and leads back to the same blurred distinction as above. it's expected that signature generation will almost always be more expensive than signature verification (in fact, that's a desireable feature and guided the choice of crypto alg) and if it takes more authority server CPU to generate an authentic NXDOMAIN than an authentic NOERROR, an attacker can target an attack so as to prevent authentic NXDOMAIN from being available during their real attack elsewhere, which effectively removes authenticated NXDOMAIN as a DNSSEC-bis feature. > Forgive me if this has been discussed before. you are forgiven; the archives are in complete disarray on this topic. -- to unsubscribe send a message to namedroppers-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 Jun 22 19:21:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtYU9-0002iE-2o for dnsext-archive@lists.ietf.org; Thu, 22 Jun 2006 19:21:17 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtYU9-0008Vk-0t for dnsext-archive@lists.ietf.org; Thu, 22 Jun 2006 19:21:17 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FtYU7-0008OZ-EO for dnsext-archive@lists.ietf.org; Thu, 22 Jun 2006 19:21:16 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtY0x-000Pr6-M0 for namedroppers-data@psg.com; Thu, 22 Jun 2006 22:51:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [209.173.57.84] (helo=cypress.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtY0w-000Pqo-VV for namedroppers@ops.ietf.org; Thu, 22 Jun 2006 22:51:07 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k5MMo2mU022639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Jun 2006 22:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FtXzt-0007sx-US; Thu, 22 Jun 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-nsid-02.txt Message-Id: Date: Thu, 22 Jun 2006 18:50:01 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNS Name Server Identifier Option (NSID) Author(s) : R. Austein Filename : draft-ietf-dnsext-nsid-02.txt Pages : 16 Date : 2006-6-22 With the increased use of DNS anycast, load balancing, and other mechanisms allowing more than one DNS name server to share a single IP address, it is sometimes difficult to tell which of a pool of name servers has answered a particular query. While existing ad-hoc mechanism allow an operator to send follow-up queries when it is necessary to debug such a configuration, the only completely reliable way to obtain the identity of the name server which responded is to have the name server include this information in the response itself. This note defines a protocol extension to support this functionality. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-nsid-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-nsid-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-nsid-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: <2006-6-22153731.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-nsid-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-nsid-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-22153731.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 Jun 22 19:38:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtY4h-0005DE-4W for dnsext-archive@lists.ietf.org; Thu, 22 Jun 2006 18:54:59 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtY4e-00056i-Ul for dnsext-archive@lists.ietf.org; Thu, 22 Jun 2006 18:54:59 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtY0h-000PpB-Iq for namedroppers-data@psg.com; Thu, 22 Jun 2006 22:50:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [209.173.53.70] (helo=oak.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtY0g-000Pok-S1 for namedroppers@ops.ietf.org; Thu, 22 Jun 2006 22:50:51 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k5MMo2WR003662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Jun 2006 22:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FtXzu-0007u1-Cz; Thu, 22 Jun 2006 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 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-09.txt Message-Id: Date: Thu, 22 Jun 2006 18:50:02 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 --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) : D. Blacka, et al. Filename : draft-ietf-dnsext-dnssec-opt-in-09.txt Pages : 16 Date : 2006-6-22 In the DNS security extensions (DNSSEC), delegations to unsigned subzones are cryptographically secured. Maintaining this cryptography is not always practical or necessary. This document describes an experimental "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-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-opt-in-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-opt-in-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: <2006-6-22161733.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-opt-in-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-opt-in-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-22161733.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 Jun 22 20:47:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtZq3-00087A-0l for dnsext-archive@lists.ietf.org; Thu, 22 Jun 2006 20:47:59 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtYUo-00008D-No for dnsext-archive@lists.ietf.org; Thu, 22 Jun 2006 19:21:58 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FtY4f-00075X-8v for dnsext-archive@lists.ietf.org; Thu, 22 Jun 2006 18:55:02 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtY0z-000PrW-Mt for namedroppers-data@psg.com; Thu, 22 Jun 2006 22:51:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [209.173.57.84] (helo=cypress.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtY0z-000PrD-2Z for namedroppers@ops.ietf.org; Thu, 22 Jun 2006 22:51:09 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k5MMo2mU022643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Jun 2006 22:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FtXzt-0007t6-W8; Thu, 22 Jun 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-rollover-requirements-02.txt Message-Id: Date: Thu, 22 Jun 2006 18:50:01 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Requirements related to DNSSEC Trust Anchor Rollover Author(s) : S. Crocker, et al. Filename : draft-ietf-dnsext-rollover-requirements-02.txt Pages : 11 Date : 2006-6-22 Every DNS security-aware resolver must have at least one Trust Anchor to use as the basis for validating responses from DNS signed zones. For various reasons, most DNS security-aware resolvers are expected to have several Trust Anchors. For some operations, manual monitoring and updating of Trust Anchors may be feasible but many operations will require automated methods for updating Trust Anchors in their security-aware resolvers. This document identifies the requirements that must be met by an automated DNS Trust Anchor rollover solution for security-aware DNS resolvers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rollover-requirements-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-rollover-requirements-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-rollover-requirements-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: <2006-6-22154109.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-rollover-requirements-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-rollover-requirements-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-22154109.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 Jun 23 03:11:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftfp7-0006ck-S2 for dnsext-archive@lists.ietf.org; Fri, 23 Jun 2006 03:11:25 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ftfj4-0003lb-U7 for dnsext-archive@lists.ietf.org; Fri, 23 Jun 2006 03:05:11 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ftfiz-0003IL-U3 for dnsext-archive@lists.ietf.org; Fri, 23 Jun 2006 03:05:10 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ftfei-000BoA-TK for namedroppers-data@psg.com; Fri, 23 Jun 2006 07:00:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=0.9 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM, HTML_FONT_FACE_BAD,HTML_MESSAGE,HTML_OBFUSCATE_05_10 autolearn=no version=3.1.1 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ftfeg-000Bnd-JD for namedroppers@ops.ietf.org; Fri, 23 Jun 2006 07:00:39 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k5N70YIt041594 for ; Fri, 23 Jun 2006 09:00:34 +0200 (CEST) (envelope-from namemod@open.nlnetlabs.nl) Received: (from namemod@localhost) by open.nlnetlabs.nl (8.13.4/8.13.4/Submit) id k5N70XIO041593 for namedroppers@ops.ietf.org; Fri, 23 Jun 2006 09:00:33 +0200 (CEST) (envelope-from namemod) Received: from [220.90.238.66] (helo=syi.hana.ne.kr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtJJL-0007fL-S1 for namedroppers@ops.ietf.org; Thu, 22 Jun 2006 07:09:08 +0000 Received: from SHINHJ ([147.6.74.177]) (authenticated bits=0) by syi.hana.ne.kr (8.13.5/8.13.4) with ESMTP id k5M6Jg6F073363 for ; Thu, 22 Jun 2006 15:19:47 +0900 (KST) (envelope-from shinhj@hana.ne.kr) X-Authentication-Warning: syi.hana.ne.kr.: Host [147.6.74.177] claimed to be SHINHJ From: "Hyo-Jeong Shin" To: Subject: usage of Server Failure Response code Date: Thu, 22 Jun 2006 16:08:47 +0900 Message-ID: <000301c695ca$bac31f80$bdb4fea9@SHINHJ> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C69616.2BDDF050" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcaVyrRpmFym96psSJG+8/gOJ4lGNw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -0.2 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 [ 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. ] This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C69616.2BDDF050 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I'm analyzing DNS packets for my company's DNS servers. According to RFC 1035, the meaning of Server failure is "The name server was unable to process this query due to a problem with the name server". On real network, Server Failure RCODE is generated in case of "unsuccessful lookup" such as timeout due to a lack of response from overloaded cache DNS server. I noticed that Bind 9 returns "Server Failure" but Bind 8 doesn't return anything (timeout) for the same query. Why don't you add new RCODE for "unsuccessful lookup"? - Hyo-Jeong Shin@KT ------=_NextPart_000_0004_01C69616.2BDDF050 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m analyzing DNS packets for my = company’s = DNS servers.

According to RFC 1035, the = meaning of Server failure is “The name server was unable to = process this query due to a problem with the name server”.

On real network, Server = Failure RCODE is generated in case of “unsuccessful = lookup” = such as timeout due to a lack of response from overloaded cache DNS = server.

I noticed that Bind 9 = returns “Server Failure” = but Bind 8 doesn’t = return anything (timeout) for the same query.

Why don’t = you add new RCODE for “unsuccessful lookup”?

 

- Hyo-Jeong = Shin@KT

------=_NextPart_000_0004_01C69616.2BDDF050-- -- to unsubscribe send a message to namedroppers-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 Jun 23 06:06:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtiYk-0007I8-TI for dnsext-archive@lists.ietf.org; Fri, 23 Jun 2006 06:06:42 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtiYi-0008Pz-6X for dnsext-archive@lists.ietf.org; Fri, 23 Jun 2006 06:06:42 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtiVd-0000nK-SQ for namedroppers-data@psg.com; Fri, 23 Jun 2006 10:03:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.244.168.210] (helo=outpost.ds9a.nl) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtiVb-0000n6-Ty for namedroppers@ops.ietf.org; Fri, 23 Jun 2006 10:03:28 +0000 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 8728540CD; Fri, 23 Jun 2006 12:03:12 +0200 (CEST) Date: Fri, 23 Jun 2006 12:03:12 +0200 From: bert hubert To: Hyo-Jeong Shin Cc: namedroppers@ops.ietf.org Subject: Re: usage of Server Failure Response code Message-ID: <20060623100312.GC16050@outpost.ds9a.nl> References: <000301c695ca$bac31f80$bdb4fea9@SHINHJ> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000301c695ca$bac31f80$bdb4fea9@SHINHJ> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 On Thu, Jun 22, 2006 at 04:08:47PM +0900, Hyo-Jeong Shin wrote: > Why don't you add new RCODE for "unsuccessful lookup"? Bit late for that. It is already hard to say "there is no answer", because this often results in servers being hammered with the same query over and over and over again. In other words, you could define such a code, but it would no be respected. It would also be very close in meaning to 'ServFail'. Kind regards, bert hubert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-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 Jun 23 09:47:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftlzw-0002yc-JQ for dnsext-archive@lists.ietf.org; Fri, 23 Jun 2006 09:47:00 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ftlzv-0006i6-7q for dnsext-archive@lists.ietf.org; Fri, 23 Jun 2006 09:47:00 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtlvT-000InM-Eo for namedroppers-data@psg.com; Fri, 23 Jun 2006 13:42:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.1 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtlvS-000In8-Js for namedroppers@ops.ietf.org; Fri, 23 Jun 2006 13:42:22 +0000 Received: from [10.131.244.197] ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Fri, 23 Jun 2006 09:42:21 -0400 id 002CC0E6.449BEFBD.00001874 Mime-Version: 1.0 (Apple Message framework v750) Content-Transfer-Encoding: 7bit Message-Id: <32121001-32BE-4D22-970B-4DD6C0E26B5C@verisignlabs.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Namedroppers WG From: David Blacka Subject: NSEC3 Issue 22: Defining new hash algorithms. Date: Fri, 23 Jun 2006 09:42:20 -0400 X-Mailer: Apple Mail (2.750) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Issue: Currently, the NSEC3 draft indicates that it uses the same IANA registry as DS for its hash algorithms. This leads to a number of potential concerns: a) Operators might get the impression that if a new hash algorithm is added to the DS registry, then it is automatically defined for use in NSEC3. I'm not sure that this is correct. b) The desirable criteria for a DS digest algorithm and an NSEC3 hash algorithm are not exactly the same. For instance, NSEC3 is less sensitive to the second pre-image resistance property of a hash. In fact, algorithms that would simply not be acceptable for DS may be totally fine for NSEC3 (e.g., MD5.) c) There are things that must be defined about how a hash works with NSEC3 before it can be successfully used. For instance, if the hash length is longer that 63 characters in base 32, then the hash must be split across multiple labels. The consequences of this will no doubt require a significant amount of specification, possibly modifying the current NSEC3 specification. Discussion: 1) The draft can establish a new IANA registry for NSEC3 hash algorithms, or 2) the draft can continue to use the DS registry. This will prevent people from defining new hash algorithms that are fine for use with NSEC3 but not acceptable for use with DS (point b, above). Independent from this decision the draft could be modified to stress that hash algorithms MUST be specified before use. My recommendation: Both establish a new registry and require that new algorithms have a specification describing its use with NSEC3. -- 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 Fri Jun 23 10:54:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftn3g-0003f4-6O for dnsext-archive@lists.ietf.org; Fri, 23 Jun 2006 10:54:56 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ftn3e-0008Gh-Rw for dnsext-archive@lists.ietf.org; Fri, 23 Jun 2006 10:54:56 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ftmzw-000OVq-Lu for namedroppers-data@psg.com; Fri, 23 Jun 2006 14:51:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,DNS_FROM_RFC_WHOIS,SPF_HELO_PASS, SPF_PASS autolearn=no version=3.1.1 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ftmzv-000OVc-UY for namedroppers@ops.ietf.org; Fri, 23 Jun 2006 14:51:04 +0000 Received: from [10.131.244.197] ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Fri, 23 Jun 2006 10:51:02 -0400 id 002CC111.449BFFD6.00002BAF Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5A8121DB-8360-4F77-B76E-BA7A66896FE4@verisignlabs.com> Content-Transfer-Encoding: 7bit From: David Blacka Subject: Re: NSEC3 Issue 18: signalling complete NSEC3 chains Date: Fri, 23 Jun 2006 10:51:01 -0400 To: Namedroppers WG X-Mailer: Apple Mail (2.750) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 On May 31, 2006, at 9:11 AM, Roy Arends wrote: > ISSUE: > > A server must use NSEC3 records from a complete chain. How does it > know > what parameters (salt, iterations, algorithm) to use that belong to a > complete chain. I think that the real issue here isn't that there isn't a method for learning what parameters to use, but that the currently specified method isn't efficient. To recap the currently specified method: Implementations are expected to find a NSEC3 that corresponds to the zone apex (identified by the presence of the SOA bit in the type map), and use those parameters. If there is more than one such NSEC3 record, any of them may be chosen. The means that, if not atomically adding an entire new NSEC3 chain to a zone, the zone apex NSEC3 RRset must be added last. However, the practice of having the search for the zone apex NSEC3 RR is not efficient to do post zone loading, and to do it during zone loading is impractical, or at least distasteful. So, there are a number of proposed solutions to this issue: 1) Leave the situation as-is. 2) Define a new RR that may be queried at the zone apex that will hold the NSEC3 parameters. This record would be (tentatively) called NSEC3-PARAMS. It would only have value at the zone apex of an NSEC3 signed zone. 3) Use a special-cased NSEC3 RR named after the zone apex that isn't part of the chain, but reflects a completed chain's parameters. That is, an NSEC3 like "example. NSEC3 0 1 100 ". 4) special-case the zone apex NSEC3 RR, naming it after the zone apex. That is, the zone apex NSEC3 RR would be like "example. NSEC3 0 1 100 NS SOA DNSKEY NSEC3 RRSIG". And require this to be the last-added NSEC3, just as in the current solution. This idea was proposed by Mark Andrews. Note that solution #4 could be thought of as a special case of the NSEC3 hash calculation function rather than as a special NSEC3 RR. Solutions 2, 3, and 4 all have the property of having something that may be directly looked up by the authoritative server (either primary or secondary), which is known to be efficient. Thoughts? -- 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 Fri Jun 23 11:27:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtnZZ-0007zW-EF for dnsext-archive@lists.ietf.org; Fri, 23 Jun 2006 11:27:53 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtnZY-0004an-S9 for dnsext-archive@lists.ietf.org; Fri, 23 Jun 2006 11:27:53 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtnWS-0001fO-EZ for namedroppers-data@psg.com; Fri, 23 Jun 2006 15:24:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [193.71.199.94] (helo=aibo.runbox.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtnWQ-0001ey-F6 for namedroppers@ops.ietf.org; Fri, 23 Jun 2006 15:24:38 +0000 Received: from [10.9.9.130] (helo=fenris.runbox.com) by greyhound.runbox.com with esmtp (Exim 4.34) id 1FtnWG-0003Xr-BJ; Fri, 23 Jun 2006 17:24:28 +0200 Received: from mail by fenris.runbox.com with local (Exim 4.50) id 1FtnWG-0005b6-7K; Fri, 23 Jun 2006 17:24:28 +0200 Content-Type: text/plain; charset="iso-8859-15" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [129.246.254.14] by secure.runbox.com with http (uid:258406) (RMM 4.0); Fri, 23 Jun 2006 15:24:28 GMT From: "David A. Wheeler" Reply-To: dwheeler@dwheeler.com To: namedroppers@ops.ietf.org CC: ben@algroup.co.uk, roy@nominet.org.uk, geoff@nominet.org.uk Subject: NSEC3 - proposed mods to draft Date: Fri, 23 Jun 2006 11:24:28 -0400 (EDT) X-Sender: 258406 X-Mailer: RMM References: <4499DBD1.3040109@algroup.co.uk> In-Reply-To: Message-Id: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a I know you're trying to meet a Monday deadline for NSEC3. Here are a few proposed _specific_ changes to the spec, which I've tried to make as easy as possible for you; they're basically line-in/line-o= uts; I hope they help: * Nit - section numbering is wrong - in May draft, 11 precedes 10.. need to renumber in order..! * Under "Security Considerations": - Change "DNSSEC already relies on SHA-1 to not collide" to "DNSSEC already relies on the presumption that the cryptographic hash function (such as SHA-1) will not collide." (other hash functions besides SHA-1 are possible, in the long term likely, and the sentence structure was a little odd anyway.) - After the 1st two paragraphs (discussing iterations and salt), add: "Domains can also make discovery of many names much more difficult, if ithey wish, by choosing longer names that are not in any dictionary and do not follow any discernable pattern. They can also insert 'dummy' names that should never be queried, possibly including some easier-to-find names, and then alert an administrat= or when unexpected queries are performed on those names." * Under "Rationale", insert before last paragraph: "Some alternatives to this specification have undesirable side-effects. An unsigned reply denial of existence can be trivially spoofed. Ignoring requests for non-existant names blurs the important distinction between packet loss due to network overcommit/outage, packet loss due to intentional targetted attack, and assertion-of-nonexistence, resulting in excessive useless retransmissions and effective lack of authenticated denial of existence. Signing a denial of existance for each specific name requires that the name= server have a private key for denial of existence; its subversion could then result in large-scale denial of service. Some may find this last result an acceptable tradeoff, but many others will not. This specification provides protection against trivial zone enumeration whi= le (1) providing signed denial of existence and (2) not requiring private keys= in the name servers." (elsewhere is fine too, of course. But I think this is important background information that needs to go SOMEWHERE in the document. If you don't brief= ly document WHY this specification is designed the way it is, the reader will wonder why you did NOT do these "obvious" things. Paul Vixie noted that "the archives are in complete disarray on this topic.= " :-) ). * Add "It is RECOMMENDED that master servers cache a few recent queries that resulted in not-found results, to save processing time" (I reworded the last part). Here is the proposed changed I noted earlier: * section 10, in the phrase "cannot by cryptographically proven", replace "by" with "be". To address NSEC3 issue 10, in the security section note the issue and speci= fically tell the implementors it's okay to drop requests for nonexistent names if t= hey have to, to serve existing names (it's a DoS, but it at least limits the da= mage and is better for most people, so it should be explicitly permitted). Here's some sample text, more or less lifted from the earlier emails (I just don't want this lost, you probably already have this in the draft): "Significantly more work is required for a name server to respond to queries which require negative proofs using NSEC3 than is required for a client to compose and send them. For each such query, the name server must repeat the hash function for the number of iterations specified in the NSEC3 RRs. Consequently, name servers with NSEC3 zones are susceptible to asymmetric DoS attacks. Implementations MAY provide a reduced quality of service for queries which require negative proofs, so that resolution and validation of existing names will not be compromised." (In earlier text I said RECOMMENDED... I think that might be a good idea to recommend, but that's very debatable so I leave it up to you. But telli= ng implementors they at least MAY drop them if necessary is, I think, importan= t). I look forward to seeing the new NSEC3 spec. I agree with adding the hash length field, though that will obviously require a (small) change in implementations... best to find that out NOW than after it's an RFC...! :-). --- David A. Wheeler -- to unsubscribe send a message to namedroppers-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 Jun 23 12:39:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftogi-0003en-QD for dnsext-archive@lists.ietf.org; Fri, 23 Jun 2006 12:39:20 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ftogh-0001PQ-H9 for dnsext-archive@lists.ietf.org; Fri, 23 Jun 2006 12:39:20 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtodQ-0008ED-QK for namedroppers-data@psg.com; Fri, 23 Jun 2006 16:35:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [209.173.57.70] (helo=pine.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtodP-0008Dz-Sj for namedroppers@ops.ietf.org; Fri, 23 Jun 2006 16:35:56 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k5NGZsHp015453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Jun 2006 16:35:54 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FtodO-0006TB-4l; Fri, 23 Jun 2006 12:35:54 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Subject: Last Call: 'DNS Name Server Identifier Option (NSID)' to Proposed Standard (draft-ietf-dnsext-nsid) Reply-to: iesg@ietf.org CC: Message-Id: Date: Fri, 23 Jun 2006 12:35:54 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f The IESG has received a request from the DNS Extensions WG to consider the following document: - 'DNS Name Server Identifier Option (NSID) ' 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 2006-07-07. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dnsext-nsid-02.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 Fri Jun 23 13:54:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftprg-0005RT-CU for dnsext-archive@lists.ietf.org; Fri, 23 Jun 2006 13:54:44 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ftprf-0000ER-1s for dnsext-archive@lists.ietf.org; Fri, 23 Jun 2006 13:54:44 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ftpm3-000Efb-57 for namedroppers-data@psg.com; Fri, 23 Jun 2006 17:48:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,DNS_FROM_RFC_WHOIS,SPF_HELO_PASS, SPF_PASS autolearn=no version=3.1.1 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ftpm2-000EfN-9X for namedroppers@ops.ietf.org; Fri, 23 Jun 2006 17:48:54 +0000 Received: from [10.131.244.197] ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Fri, 23 Jun 2006 13:48:53 -0400 id 002CC0B6.449C2985.00006024 Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <5A8121DB-8360-4F77-B76E-BA7A66896FE4@verisignlabs.com> References: <5A8121DB-8360-4F77-B76E-BA7A66896FE4@verisignlabs.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <65DAC880-49C7-4815-932A-053C632F02BD@verisignlabs.com> Content-Transfer-Encoding: 7bit From: David Blacka Subject: Re: NSEC3 Issue 18: signalling complete NSEC3 chains Date: Fri, 23 Jun 2006 13:48:51 -0400 To: Namedroppers WG X-Mailer: Apple Mail (2.750) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 On Jun 23, 2006, at 10:51 AM, David Blacka wrote: I apparently omitted some critical details about some of these solutions. This is just a followup for clarification. Not that any of it is set in stone. > > 3) Use a special-cased NSEC3 RR named after the zone apex that > isn't part of the chain, but reflects a completed chain's > parameters. That is, an NSEC3 like "example. NSEC3 0 1 100 value> ". This NSEC3 would a) not be part of the NSEC3 chain, and b) not be used to prove the existence or non-existence of anything. That is, it would have to be recognized by the validator as a special NSEC3 and ignored for proof purposes. > 4) special-case the zone apex NSEC3 RR, naming it after the zone > apex. That is, the zone apex NSEC3 RR would be like "example. > NSEC3 0 1 100 > NS SOA DNSKEY NSEC3 RRSIG". And require this to be the last-added > NSEC3, just as in the current solution. This idea was proposed by > Mark Andrews. > > Note that solution #4 could be thought of as a special case of the > NSEC3 hash calculation function rather than as a special NSEC3 RR. So, the way that I imagine that this would be defined is to say that IH(zonename) = . That is, the NSEC3 hash calculation over the zonename would be defined to be the "null" hash. This null hash would be defined to be first in hash order (i.e., sorts before any other hash value). The Next Hashed Ownername field for this zone apex NSEC3 would have the value of the next hash in hash order -- this is the least-valued non-null hash in the zone. And it would deny the existence of names that hashed to values that would sort between the null hash and the least-valued hash. Or, in other words, hashes less than the least-valued non-null hash. The last NSEC3 in hash order would still have the value of the first hash in hash order as its Next Hashed Ownername. However, this would always be the null hash. In wire format, this would be expressed with a Hash Length field set to 0. Some convention would have to be used in presentation format... perhaps "-". -- 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 Fri Jun 23 15:24:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtrGV-0000S0-Rx for dnsext-archive@lists.ietf.org; Fri, 23 Jun 2006 15:24:27 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtrGT-0003sE-B9 for dnsext-archive@lists.ietf.org; Fri, 23 Jun 2006 15:24:27 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtrBh-000MMr-D8 for namedroppers-data@psg.com; Fri, 23 Jun 2006 19:19:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtrBe-000MMG-D2 for namedroppers@ops.ietf.org; Fri, 23 Jun 2006 19:19:26 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1:211:2fff:fed7:7378]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k5NJJOov056465 for ; Fri, 23 Jun 2006 21:19:24 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) Mime-Version: 1.0 (Apple Message framework v750) References: Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-2-984471335" Message-Id: <13A34C0B-58CD-4E3C-84FF-D4A6FCD570FC@NLnetLabs.nl> Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Fwd: Last Call: 'DNS Name Server Identifier Option (NSID)' to Proposed Standard (draft-ietf-dnsext-nsid) Date: Fri, 23 Jun 2006 21:19:22 +0200 To: IETF DNSEXT WG X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.750) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-2-984471335 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed FYI... Begin forwarded message: > From: The IESG > Date: June 23, 2006 6:35:54 PM GMT+02:00 > To: IETF-Announce > Cc: namedroppers@ops.ietf.org > Subject: Last Call: 'DNS Name Server Identifier Option (NSID)' to > Proposed Standard (draft-ietf-dnsext-nsid) > Reply-To: iesg@ietf.org > > The IESG has received a request from the DNS Extensions WG to > consider the > following document: > > - 'DNS Name Server Identifier Option (NSID) ' > 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 2006-07-07. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-nsid-02.txt > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-2-984471335 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFEnD67tN/ca3YJIocRAjluAKDepuGWc7ezMMCYjA94RikAc7eGiwCg5AY0 bB5CHM4boD2VwRcyP/OP9Ig= =n15u -----END PGP SIGNATURE----- --Apple-Mail-2-984471335-- -- to unsubscribe send a message to namedroppers-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 Jun 24 13:39:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuC6B-00027d-Do for dnsext-archive@lists.ietf.org; Sat, 24 Jun 2006 13:39:11 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuC6A-0003h7-2i for dnsext-archive@lists.ietf.org; Sat, 24 Jun 2006 13:39:11 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FuC1B-000OJ7-4v for namedroppers-data@psg.com; Sat, 24 Jun 2006 17:34:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_NEUTRAL autolearn=no version=3.1.1 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FuC19-000OIt-QW for namedroppers@ops.ietf.org; Sat, 24 Jun 2006 17:34:00 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 1CD6733C1B; Sat, 24 Jun 2006 18:33:55 +0100 (BST) Message-ID: <449D7785.6010105@algroup.co.uk> Date: Sat, 24 Jun 2006 18:33:57 +0100 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: David Blacka CC: Namedroppers WG Subject: Re: NSEC3 Issue 18: signalling complete NSEC3 chains References: <5A8121DB-8360-4F77-B76E-BA7A66896FE4@verisignlabs.com> In-Reply-To: <5A8121DB-8360-4F77-B76E-BA7A66896FE4@verisignlabs.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 David Blacka wrote: > > On May 31, 2006, at 9:11 AM, Roy Arends wrote: > >> ISSUE: >> >> A server must use NSEC3 records from a complete chain. How does it know >> what parameters (salt, iterations, algorithm) to use that belong to a >> complete chain. > > I think that the real issue here isn't that there isn't a method for > learning what parameters to use, but that the currently specified method > isn't efficient. > > To recap the currently specified method: Implementations are expected > to find a NSEC3 that corresponds to the zone apex (identified by the > presence of the SOA bit in the type map), and use those parameters. If > there is more than one such NSEC3 record, any of them may be chosen. > The means that, if not atomically adding an entire new NSEC3 chain to a > zone, the zone apex NSEC3 RRset must be added last. > > However, the practice of having the search for the zone apex NSEC3 RR is > not efficient to do post zone loading, and to do it during zone loading > is impractical, or at least distasteful. > > So, there are a number of proposed solutions to this issue: > > 1) Leave the situation as-is. > > 2) Define a new RR that may be queried at the zone apex that will hold > the NSEC3 parameters. This record would be (tentatively) called > NSEC3-PARAMS. It would only have value at the zone apex of an NSEC3 > signed zone. > > 3) Use a special-cased NSEC3 RR named after the zone apex that isn't > part of the chain, but reflects a completed chain's parameters. That > is, an NSEC3 like "example. NSEC3 0 1 100 hashed ownername> ". > > 4) special-case the zone apex NSEC3 RR, naming it after the zone apex. > That is, the zone apex NSEC3 RR would be like "example. NSEC3 0 1 100 > NS SOA DNSKEY NSEC3 > RRSIG". And require this to be the last-added NSEC3, just as in the > current solution. This idea was proposed by Mark Andrews. > > Note that solution #4 could be thought of as a special case of the NSEC3 > hash calculation function rather than as a special NSEC3 RR. > > Solutions 2, 3, and 4 all have the property of having something that may > be directly looked up by the authoritative server (either primary or > secondary), which is known to be efficient. If we're going to change things, then I prefer 2. 3 & 4 both complicate the logic for handling NSEC3 records, for no obvious reason (to save a type code? really?). -- http://www.apache-ssl.org/ben.html http://www.links.org/ "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 Sat Jun 24 22:50:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuKho-0007TF-0k for dnsext-archive@lists.ietf.org; Sat, 24 Jun 2006 22:50:36 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuKhm-0007pt-F1 for dnsext-archive@lists.ietf.org; Sat, 24 Jun 2006 22:50:36 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FuKcT-000CiI-BT for namedroppers-data@psg.com; Sun, 25 Jun 2006 02:45:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FuKcR-000ChU-MV for namedroppers@ops.ietf.org; Sun, 25 Jun 2006 02:45:03 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 25 Jun 2006 03:45:02 +0100 X-IronPort-AV: i="4.06,172,1149462000"; d="scan'208"; a="3780774:sNHT35390544" In-Reply-To: To: dwheeler@dwheeler.com Cc: ben@algroup.co.uk, geoff@nominet.org.uk, namedroppers@ops.ietf.org Subject: Re: NSEC3 - proposed mods to draft MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Roy Arends Date: Sun, 25 Jun 2006 04:44:15 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 06/25/2006 03:44:16 AM, Serialize complete at 06/25/2006 03:44:16 AM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c "David A. Wheeler" wrote on 06/23/2006 05:24:28 PM: > I know you're trying to meet a Monday deadline for NSEC3. > Here are a few proposed _specific_ changes to the spec, which I've > tried to make as easy as possible for you; they're basically line- > in/line-outs; > I hope they help: > > * Nit - section numbering is wrong - in May draft, 11 precedes 10.. > need to renumber in order..! We've done a total rewrite since then, so this was already fixed. > > * Under "Security Considerations": > - Change "DNSSEC already relies on SHA-1 to not collide" to > "DNSSEC already relies on the presumption that the > cryptographic hash function (such as SHA-1) will not collide." > (other hash functions besides SHA-1 are possible, in the long term likely, > and the sentence structure was a little odd anyway.) This is changed to: Note that DNSSEC already relies on the presumption that a cryptographic hash function is second pre-image resistant, since these hash functions are used for generating and validating signatures and DS records. > - After the 1st two paragraphs (discussing iterations and salt), add: > "Domains can also make discovery of many names much more difficult, > if ithey wish, by choosing longer names that are not in any dictionary > and do not follow any discernable pattern. > They can also insert 'dummy' names that should never be queried, > possibly including some easier-to-find names, and then alert an administrator > when unexpected queries are performed on those names." This document describes the workings of the DNSSEC/NSEC3 protocol, and was not ment to be an exhaustive list of all possible defenses against enumeration. > * Under "Rationale", insert before last paragraph: > "Some alternatives to this specification have undesirable side-effects. > An unsigned reply denial of existence can be trivially spoofed. > Ignoring requests for non-existant names blurs the important distinction > between packet loss due to network overcommit/outage, > packet loss due to intentional targetted attack, > and assertion-of-nonexistence, resulting in > excessive useless retransmissions and effective lack of authenticated > denial of existence. > Signing a denial of existance for each specific name requires that > the name server > have a private key for denial of existence; its subversion > could then result in large-scale denial of service. Some may find this > last result an acceptable tradeoff, but many others will not. > This specification provides protection against trivial zone enumeration while > (1) providing signed denial of existence and (2) not requiring > private keys in the > name servers." > (elsewhere is fine too, of course. But I think this is important background > information that needs to go SOMEWHERE in the document. If you don't briefly > document WHY this specification is designed the way it is, the > reader will wonder why you did NOT do these "obvious" things. > Paul Vixie noted that "the archives are in complete disarray on this > topic." :-) ). We can now refer to: http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00794.html :-) Anyway, the validity or limitations of other proposals (i.e. not specified in any draft) should not be listed in this document. It is distracting, and basically not relevant for NSEC3. It is fine to have this in a seperate 'road map' draft or something similar. We have limitted ourselfs to solely list the limitations of NSEC3. > * Add "It is RECOMMENDED that master servers cache a few recent queries that > resulted in not-found results, to save processing time" > (I reworded the last part). > > Here is the proposed changed I noted earlier: > * section 10, in the phrase "cannot by cryptographically proven", > replace "by" with "be". Fixed. > To address NSEC3 issue 10, in the security section note the issue > and specifically > tell the implementors it's okay to drop requests for nonexistent names if they > have to, to serve existing names (it's a DoS, but it at least limitsthe damage > and is better for most people, so it should be explicitly permitted). > Here's some sample text, more or less lifted from the earlier emails > (I just don't want this lost, you probably already have this in the draft): > "Significantly more work is required for a name server to respond to > queries which require negative proofs using NSEC3 than is required for > a client to compose and send them. For each such query, the name > server must repeat the hash function for the number of iterations > specified in the NSEC3 RRs. Consequently, name servers with NSEC3 > zones are susceptible to asymmetric DoS attacks. > Implementations MAY provide a reduced > quality of service for queries which require negative proofs, so that > resolution and validation of existing names will not be compromised." > (In earlier text I said RECOMMENDED... I think that might be a good idea > to recommend, but that's very debatable so I leave it up to you. But telling > implementors they at least MAY drop them if necessary is, I think, important). Will chew on this. > I look forward to seeing the new NSEC3 spec. I agree with adding the > hash length field, though that will obviously require a (small) change in > implementations... best to find that out NOW than after it's an RFC...! :-). Thanks for reading the draft ! Regards, Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 25 23:14:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuhYg-0001VF-51 for dnsext-archive@lists.ietf.org; Sun, 25 Jun 2006 23:14:42 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuhYd-0008He-QM for dnsext-archive@lists.ietf.org; Sun, 25 Jun 2006 23:14:42 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FuhSh-000OUf-O9 for namedroppers-data@psg.com; Mon, 26 Jun 2006 03:08:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [129.188.136.8] (helo=motgate8.mot.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FuhSg-000OUO-Si for namedroppers@ops.ietf.org; Mon, 26 Jun 2006 03:08:31 +0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k5Q38TBL007746 for ; Sun, 25 Jun 2006 20:08:29 -0700 (MST) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k5Q38Trk000714 for ; Sun, 25 Jun 2006 22:08:29 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: draft-eastlake-dnsext-cookies-00.txt Date: Sun, 25 Jun 2006 23:08:28 -0400 Message-ID: <3870C46029D1F945B1472F170D2D97900111F46C@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-eastlake-dnsext-cookies-00.txt Thread-Index: AcaYzcvOeFDeAGMqSnarQkQA+k2J3w== From: "Eastlake III Donald-LDE008" To: X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Hi, So I had this idea for DNS cookies to help ameliorate traffic amplification, cache poisoning, etc. attacks. Anyway, I've written up my idea and the first draft is available as http://www.ietf.org/internet-drafts/draft-eastlake-dnsext-cookies-00.txt . I'd be interested in people's comments. Thanks, Donald -- to unsubscribe send a message to namedroppers-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 Jun 26 03:08:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FulCs-0006ni-FK for dnsext-archive@lists.ietf.org; Mon, 26 Jun 2006 03:08:26 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FulCq-0003h2-Uj for dnsext-archive@lists.ietf.org; Mon, 26 Jun 2006 03:08:26 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ful9P-000JYK-EZ for namedroppers-data@psg.com; Mon, 26 Jun 2006 07:04:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [202.224.39.218] (helo=mails2.asahi-net.or.jp) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ful9M-000JXo-MA for namedroppers@ops.ietf.org; Mon, 26 Jun 2006 07:04:48 +0000 Received: from mailav2.asahi-net.or.jp (mailav2.asahi-net.or.jp [202.224.39.221]) by mails2f.asahi-net.or.jp (Postfix) with SMTP id E9660C60D for ; Mon, 26 Jun 2006 16:04:41 +0900 (JST) Received: from mails1.asahi-net.or.jp ([202.224.39.217]) by mailav2.asahi-net.or.jp (NAVGW 2.5.2.9) with SMTP id M2006062616044129334 for ; Mon, 26 Jun 2006 16:04:41 +0900 Received: from mx0.k2r.org (s163221.ppp.asahi-net.or.jp [220.157.163.221]) by mails1.asahi-net.or.jp (Postfix) with ESMTP id 1324CC60A for ; Mon, 26 Jun 2006 16:04:31 +0900 (JST) Received: (qmail 5863 invoked by uid 1000); 26 Jun 2006 07:04:30 -0000 Date: Mon, 26 Jun 2006 16:04:30 +0900 From: Kenji Rikitake To: Eastlake III Donald-LDE008 Cc: namedroppers@ops.ietf.org Subject: Re: draft-eastlake-dnsext-cookies-00.txt Message-ID: <20060626070430.GA5385%kenji.rikitake@acm.org> References: <3870C46029D1F945B1472F170D2D97900111F46C@de01exm64.ds.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3870C46029D1F945B1472F170D2D97900111F46C@de01exm64.ds.mot.com> User-Agent: Mutt/1.4.2.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 In the message <3870C46029D1F945B1472F170D2D97900111F46C@de01exm64.ds.mot.com> dated Sun, Jun 25, 2006 at 11:08:05PM -0400, Eastlake III Donald-LDE008 writes: > http://www.ietf.org/internet-drafts/draft-eastlake-dnsext-cookies-00.txt > 4.1 Resolver Cookies [...] > A resolver MUST NOT use the same Resolver Cookie value for queries to > all servers. > 4.2 Resolver Cookies [...] > A server MUST NOT use the same Server Cookie value for responses to > all requests. The above "all requests" should "all resolvers" if the Section 4.1 says "all servers". > 5.3 Implementation Requirements > DNS resolvers and servers MUST implement DNS cookies. > DNS resolvers SHOULD operate in and be shipped so as to default to > the Enabled or Enforced mode for all servers. > DNS servers SHOULD operate in and be shipped so as to default to the > Enabled or Enforced mode for all resolvers they are willing to > service. While I agree with the idea that the cookie should be enforced as possible, I also think making it a MUST as the first paragraph in the Section 5.3 could not be feasible, regarding the number of current non-cookie (or just Disabled in Section 5.2) DNS programs. Any perspective on the deployment issues? Some questions come into my mind: * How long (in time, e.g., seconds) or how many DNS packets is a server or a resolver allowed to retain the same cookie to the other end (making a pair of server-resolver relationship)? I guess it depends on the traffic which the server/resolver handles, though I think some minimum values of cookie-rollover timing should be suggested. * SHOULD/MUST a server/resolver change the cookie for each program on the other end? Regards, // Kenji Rikitake -- to unsubscribe send a message to namedroppers-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 Jun 26 10:46:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FusML-0002eu-VH for dnsext-archive@lists.ietf.org; Mon, 26 Jun 2006 10:46:41 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FusML-0007Cm-Ec for dnsext-archive@lists.ietf.org; Mon, 26 Jun 2006 10:46:41 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FusI1-0007sn-8y for namedroppers-data@psg.com; Mon, 26 Jun 2006 14:42:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [85.158.136.35] (helo=mail125.messagelabs.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FusHy-0007sR-49 for namedroppers@ops.ietf.org; Mon, 26 Jun 2006 14:42:11 +0000 X-VirusChecked: Checked X-Env-Sender: Donald.Eastlake@motorola.com X-Msg-Ref: server-13.tower-125.messagelabs.com!1151332926!17391424!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 2802 invoked from network); 26 Jun 2006 14:42:07 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-125.messagelabs.com with SMTP; 26 Jun 2006 14:42:07 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k5QEg5GR018064 for ; Mon, 26 Jun 2006 07:42:06 -0700 (MST) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id k5QEg50b025727 for ; Mon, 26 Jun 2006 09:42:05 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-eastlake-dnsext-cookies-00.txt Date: Mon, 26 Jun 2006 10:41:41 -0400 Message-ID: <3870C46029D1F945B1472F170D2D97900111F5C1@de01exm64.ds.mot.com> In-Reply-To: <20060626070430.GA5385%kenji.rikitake@acm.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-eastlake-dnsext-cookies-00.txt Thread-Index: AcaY7xaOCuWa1VObQVaL6xEhPomfBAAPB34A From: "Eastlake III Donald-LDE008" To: "Kenji Rikitake" Cc: X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Thanks for the comments, see below at @@@=20 -----Original Message----- From: Kenji Rikitake [mailto:kenji.rikitake@acm.org]=20 Sent: Monday, June 26, 2006 3:04 AM To: Eastlake III Donald-LDE008 Cc: namedroppers@ops.ietf.org Subject: Re: draft-eastlake-dnsext-cookies-00.txt In the message <3870C46029D1F945B1472F170D2D97900111F46C@de01exm64.ds.mot.com> dated Sun, Jun 25, 2006 at 11:08:05PM -0400, Eastlake III Donald-LDE008 writes: > http://www.ietf.org/internet-drafts/draft-eastlake-dnsext-cookies-00.t > xt > 4.1 Resolver Cookies [...] > A resolver MUST NOT use the same Resolver Cookie value for queries to > all servers. > 4.2 Resolver Cookies [...] > A server MUST NOT use the same Server Cookie value for responses to > all requests. The above "all requests" should "all resolvers" if the Section 4.1 says "all servers". @@@ Well, the current wording isn't wrong and the situation isn't exactly parallel due to the inclusion of the Resolver Cookie in the Server Cookie calculation. I'll think about it. > 5.3 Implementation Requirements > DNS resolvers and servers MUST implement DNS cookies. > DNS resolvers SHOULD operate in and be shipped so as to default to > the Enabled or Enforced mode for all servers. > DNS servers SHOULD operate in and be shipped so as to default to the > Enabled or Enforced mode for all resolvers they are willing to > service. While I agree with the idea that the cookie should be enforced as possible, I also think making it a MUST as the first paragraph in the Section 5.3 could not be feasible, regarding the number of current non-cookie (or just Disabled in Section 5.2) DNS programs. Any perspective on the deployment issues? @@@ With something as widespread as DNS, there will always be old or simplified new implementations that lack a feature. It's the job of the IETF to say what is the standard. If a new feature is important enough that the IETF feels it should be universally implemented, the mechanism for doing that is to put a mandatory implementation requirement into the standard. If the IETF decides it is not quite so important, you presumably put a "SHOULD be implemented" into the standard and some random amount of time later, partly based on uptake and experience, upgrade that to a MUST. Or you could put in an even lesser implementation requirement initially if you weren't sure at all. Assuming it wanted to go forward with this work, this would initially be a matter for the working group to decide. Some questions come into my mind: * How long (in time, e.g., seconds) or how many DNS packets is a server or a resolver allowed to retain the same cookie to the other end (making a pair of server-resolver relationship)? I guess it depends on the traffic which the server/resolver handles, though I think some minimum values of cookie-rollover timing should be suggested. @@@ If a minimum recommended rollover period was to be included, I'd say a day. * SHOULD/MUST a server/resolver change the cookie for each program on the other end? @@@ Not completely sure I understand what you mean but I would say no. Arguably there is really only one logical DNS entity at a host. Regards, // Kenji Rikitake @@@ Thanks, @@@ Donald -- to unsubscribe send a message to namedroppers-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 Jun 26 10:49:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FusOu-0004xg-LU for dnsext-archive@lists.ietf.org; Mon, 26 Jun 2006 10:49:20 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FusOt-0007SD-AM for dnsext-archive@lists.ietf.org; Mon, 26 Jun 2006 10:49:20 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FusMy-0008P9-PK for namedroppers-data@psg.com; Mon, 26 Jun 2006 14:47:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FusMw-0008On-3y for namedroppers@ops.ietf.org; Mon, 26 Jun 2006 14:47:18 +0000 Received: from [10.31.32.59] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k5QEl8rx020764; Mon, 26 Jun 2006 10:47:09 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Mon, 26 Jun 2006 10:47:25 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: DNAME question Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 If this is my root zone file: $TTL 60 $ORIGIN . @ IN SOA ns0. root.ns0. 1 90 90 60480 60 NS ns0. ns0. A 127.0.0.1 ; tld0. NS ns0. ; tld1. DNAME tld0. tld1. MX 10 mailhost.tld0. ; tld2. NS ns0.tld1. Is it legal to have the following as glue? ns0.tld1. A 127.0.0.2 If it is not legal, can there ever been any name servers inside tld1? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-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 Jun 26 11:01:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FusaC-00039u-Sh for dnsext-archive@lists.ietf.org; Mon, 26 Jun 2006 11:01:00 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FusaB-0000CV-E4 for dnsext-archive@lists.ietf.org; Mon, 26 Jun 2006 11:01:00 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FusXL-0009Vy-KQ for namedroppers-data@psg.com; Mon, 26 Jun 2006 14:58:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FusXK-0009VY-GG; Mon, 26 Jun 2006 14:58:02 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 26 Jun 2006 15:57:58 +0100 X-IronPort-AV: i="4.06,176,1149462000"; d="scan'208"; a="3795151:sNHT149292884" In-Reply-To: To: Edward Lewis Cc: ed.lewis@neustar.biz, namedroppers@ops.ietf.org, owner-namedroppers@ops.ietf.org Subject: Re: DNAME question MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Roy Arends Date: Mon, 26 Jun 2006 16:57:12 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 06/26/2006 03:57:11 PM, Serialize complete at 06/26/2006 03:57:11 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f owner-namedroppers@ops.ietf.org wrote on 06/26/2006 04:47:25 PM: > If this is my root zone file: > > $TTL 60 > $ORIGIN . > @ IN SOA ns0. root.ns0. 1 90 90 60480 60 > NS ns0. > ns0. A 127.0.0.1 > ; > tld0. NS ns0. > ; > tld1. DNAME tld0. > tld1. MX 10 mailhost.tld0. > ; > tld2. NS ns0.tld1. > > Is it legal to have the following as glue? > > ns0.tld1. A 127.0.0.2 It ain't glue, since there is no zone-cut for tld1. It is not legal. > If it is not legal, can there ever been any name servers inside tld1? there is no tld1 zone. Regards, Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 26 11:05:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuset-0007Dx-4r for dnsext-archive@lists.ietf.org; Mon, 26 Jun 2006 11:05:51 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fuser-0000ab-RI for dnsext-archive@lists.ietf.org; Mon, 26 Jun 2006 11:05:51 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fusd5-000ACp-80 for namedroppers-data@psg.com; Mon, 26 Jun 2006 15:03:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fusd2-000ACL-N2 for namedroppers@ops.ietf.org; Mon, 26 Jun 2006 15:03:56 +0000 Received: from [10.31.32.59] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k5QF3e9e020889; Mon, 26 Jun 2006 11:03:41 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 26 Jun 2006 10:59:16 -0400 To: David Blacka From: Edward Lewis Subject: Re: DNAME questions Cc: Namedroppers WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c I've been SMTP issues, so I'm bit slow to respond. At 11:27 -0400 6/16/06, David Blacka wrote: >1. Why does DNAME not match at the DNAME itself? I think this is captured in http://tools.ietf.org/html/2672#section-5.1 It lets the owner name retain as much functionality of a zone apex as needed. I.e., it can retain an A (for a web server maybe), an MX, etc. This wouldn't be possible for CNAME-like behavior. Anyway, that's my guess at what the intention was. >2. Does anyone know of any non-trivial production use of DNAME? I think this was already answered by someone else. >3. Would there be harm in allowing a DNAME and CNAME to both exist at the >same name? I think so - if only because CNAME is a domain hog. CNAME takes over completely and shunts the search elsewhere. DNAME is trying to rewrite the query while retaining what's needed for transitioning a domain. Not much of a difference, really, but enough probably to drive the RFC the way it is. I suppose that DNAME is meant for "sinking" a name from higher in the tree (or closer to the root) down under another name as would be done in a corporate merger/purchase. CNAMEs pretty much go up, down, sideways, etc. >4. Is it OK for caches to synthesize CNAMEs from cached DNAMEs? Ug. I don't like authorities "chasing" CNAMEs as it is, but that's what the good book says they do. I suppose that it could work, I'm not passing judgement on that. PS - I should say that I have no insight into what Matt Crawford was thinking at the time. I'm just trying to read an intent from the RFC. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-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 Jun 26 11:23:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fusvx-0003Ff-0d for dnsext-archive@lists.ietf.org; Mon, 26 Jun 2006 11:23:29 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fusvv-0001EF-Mp for dnsext-archive@lists.ietf.org; Mon, 26 Jun 2006 11:23:29 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FustK-000Bve-Eu for namedroppers-data@psg.com; Mon, 26 Jun 2006 15:20:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,DNS_FROM_RFC_WHOIS,SPF_HELO_PASS, SPF_PASS autolearn=no version=3.1.1 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FustJ-000BvS-G3 for namedroppers@ops.ietf.org; Mon, 26 Jun 2006 15:20:45 +0000 Received: from [10.131.244.197] ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Mon, 26 Jun 2006 11:20:44 -0400 id 002CC161.449FFB4C.00005EDF In-Reply-To: <449FC760.8000804@ntp.isc.org> References: <5A8121DB-8360-4F77-B76E-BA7A66896FE4@verisignlabs.com> <65DAC880-49C7-4815-932A-053C632F02BD@verisignlabs.com> <449FC760.8000804@ntp.isc.org> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1C0DE33B-2A6F-4B32-AE1D-B3809CC9B389@verisignlabs.com> Cc: Namedroppers WG Content-Transfer-Encoding: 7bit From: David Blacka Subject: Re: NSEC3 Issue 18: signalling complete NSEC3 chains Date: Mon, 26 Jun 2006 11:20:34 -0400 To: mayer@ntp.isc.org X-Mailer: Apple Mail (2.750) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 On Jun 26, 2006, at 7:39 AM, Danny Mayer wrote: > David Blacka wrote: >> >> On Jun 23, 2006, at 10:51 AM, David Blacka wrote: >> >> I apparently omitted some critical details about some of these >> solutions. This is just a followup for clarification. Not that >> any of >> it is set in stone. >>> >>> 3) Use a special-cased NSEC3 RR named after the zone apex that isn't >>> part of the chain, but reflects a completed chain's parameters. >>> That >>> is, an NSEC3 like "example. NSEC3 0 1 100 >> next hashed ownername> ". >> >> This NSEC3 would a) not be part of the NSEC3 chain, and b) not be >> used >> to prove the existence or non-existence of anything. That is, it >> would >> have to be recognized by the validator as a special NSEC3 and ignored >> for proof purposes. > > Excuse my ignorance here, but doesn't that mean that an attacker could > intercept this record replace it with it's own which doesn't have > to be > authentic and cause the validation to fail thereby causing a DOS > attack? I didn't mean to imply that this NSEC3 RR wouldn't be verified when it was asked for, just that it would be ignored by validators. -- 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 Mon Jun 26 12:08:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FutdJ-0000NF-Qj for dnsext-archive@lists.ietf.org; Mon, 26 Jun 2006 12:08:17 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FutdG-0004Mw-5g for dnsext-archive@lists.ietf.org; Mon, 26 Jun 2006 12:08:17 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FutaF-000GXA-OD for namedroppers-data@psg.com; Mon, 26 Jun 2006 16:05:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [200.23.30.77] (helo=mail.nic.mx) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FutaD-000GWp-7l for namedroppers@ops.ietf.org; Mon, 26 Jun 2006 16:05:05 +0000 Received: from localhost (localhost.nic.mx [127.0.0.1]) by mail.nic.mx (Postfix) with ESMTP id 51403182FAC; Mon, 26 Jun 2006 11:05:04 -0500 (CDT) Received: from mail.nic.mx ([127.0.0.1]) by localhost (mail.nic.mx [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74577-07; Mon, 26 Jun 2006 11:05:04 -0500 (CDT) Received: from GLOZANO.nic.mx (unknown [200.33.1.76]) by mail.nic.mx (Postfix) with ESMTP id 9A300182EA5; Mon, 26 Jun 2006 11:05:03 -0500 (CDT) Message-Id: <6.2.5.6.2.20060626105457.050ea9a8@nic.mx> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 26 Jun 2006 11:05:02 -0500 To: Olaf M.Kolkman From: Gustavo Lozano Subject: Re: Key rollover work, was Re: RFC2672bis DNAME update document Cc: Namedroppers In-Reply-To: <2805B0B0-CFA9-49E7-8ABD-4279673564D8@NLnetLabs.nl> References: <6.2.5.6.2.20060612102822.03b52c00@ogud.com> <7.0.1.0.2.20060612174002.03d76008@nominum.com> <2805B0B0-CFA9-49E7-8ABD-4279673564D8@NLnetLabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new at nic.mx Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Olaf, I want to know what the status of this proposal is. Do some drafts were revoked by the authors? Thank you. At 03:22 PM 6/13/2006 +0200, Olaf M.Kolkman wrote: >I propose the following. > >1 - All editors off drafts make sure that their drafts are alive in >the repository. (before start of summer, June 21) > >2 - Maybe some editors want to revoke their draft in lessen the >entropy in this space or just because they think another draft is >superior > >3 - We start a reading round of one month. Here we need working group >participants doing real work (!). I would like to see (at least 5?) >people to read _all_ the drafts. (before IETF meeting (?)) > >4 - While reading drafts reviewers create issue lists > >5 - All people that read _all_ drafts (hopefully more than 5) will >provide their motivated preference, say a top 3. Motivation is to be >based on requirements. (There are folk who did proposal comparison. >It would be good if those were reviewed and reposted at that time). > >6- We compile a shortlist of 1 or 2 documents and work to technically >improve those to get a consensus outcome. > > >I am hesitant to spend to much face-2-face time on rehashing previous >discussion. But if we manage to have some review done, issues >identified, and preferences stated, we may actually be able to make >real progress. > >I'd say that committed reviewers need anything between 1 to 3 days to >do this work. > >Any comments, alternative approaches, takers? > >--Olaf > > > >----------------------------------------------------------- >Olaf M. Kolkman >NLnet Labs >http://www.nlnetlabs.nl/ > > > > > gus -- to unsubscribe send a message to namedroppers-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 Jun 26 12:42:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuuA1-00006k-BK for dnsext-archive@lists.ietf.org; Mon, 26 Jun 2006 12:42:05 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuuA0-00084a-2G for dnsext-archive@lists.ietf.org; Mon, 26 Jun 2006 12:42:05 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fuu7Q-000Jbx-R6 for namedroppers-data@psg.com; Mon, 26 Jun 2006 16:39:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [81.91.160.27] (helo=denic.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fuu7P-000Jbd-T8 for namedroppers@ops.ietf.org; Mon, 26 Jun 2006 16:39:24 +0000 Received: by unknown.office.denic.de (Postfix, from userid 501) id 4B4E9313B09; Mon, 26 Jun 2006 18:39:19 +0200 (CEST) Date: Mon, 26 Jun 2006 18:39:19 +0200 From: Peter Koch To: IETF DNSEXT WG Subject: Re: DNAME question Message-ID: <20060626163919.GR409@unknown.office.denic.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a On Mon, Jun 26, 2006 at 04:57:12PM +0200, Roy Arends wrote: > > tld1. DNAME tld0. > > tld1. MX 10 mailhost.tld0. > > ; > > tld2. NS ns0.tld1. > > > > Is it legal to have the following as glue? > > > > ns0.tld1. A 127.0.0.2 > > It ain't glue, since there is no zone-cut for tld1. that's not really the point here. The root applies a 'wide' glue policy, so it maintains glue RRs for every NS RR target for any delegation ("tld2." in this case). However, "ns0.tld1." must not appear on the RHS of the "tld2." NS RR, since it is not immediately resolvable to an address record. So, the problem isn't about glue, but about the NS RR target. > It is not legal. The result is the same at this level. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 26 12:48:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuuFr-000687-Us for dnsext-archive@lists.ietf.org; Mon, 26 Jun 2006 12:48:07 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuuFp-0000os-JN for dnsext-archive@lists.ietf.org; Mon, 26 Jun 2006 12:48:07 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FuuCr-000KCR-QN for namedroppers-data@psg.com; Mon, 26 Jun 2006 16:45:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [144.189.100.103] (helo=motgate3.mot.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FuuCm-000KBV-Ra for namedroppers@ops.ietf.org; Mon, 26 Jun 2006 16:45:01 +0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id k5QGiuGE021395 for ; Mon, 26 Jun 2006 09:44:56 -0700 (MST) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id k5QGitWa028942 for ; Mon, 26 Jun 2006 11:44:55 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: You saw this, right? Date: Mon, 26 Jun 2006 12:44:53 -0400 Message-ID: <3870C46029D1F945B1472F170D2D97900111F6A6@de01exm64.ds.mot.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: You saw this, right? Thread-Index: AcaZO5A1aHIqjLVVRPydzOp+rYEyPQAAbf1A From: "Eastlake III Donald-LDE008" To: "Bill Woodcock" , "David Ulevitch" Cc: X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Hi, Sorry if this wasn't clear. It was a first draft. What I was thinking was, assume you have N anycast hosts who are DNS servers and all receive DNS queries sent to IP address ADDR-0. If they really all think they are just a host at address ADDR-0 and any of these host sends out a DNS query, presumably the anycast nature of their address would mean that the response to that query could come back to a different one than the host which originated the query. So, given this assumption, I would think they wouldn't work very well as recursive servers. But maybe that assumption is wrong and these anycast hosts would each use a distinct unicast IP address (ADDR-1, ADDR-2, ..., ADDR-N) for outgoing queries so the responses would come back to them and could be matched up with queries. In any case, I don't think this point is very important. Multiple NATed resolvers are more likely to be under different management and/or contain some subverted machines while multiple anycasted servers are more likely to be under common management an be relatively secure. Donald -----Original Message----- From: Bill Woodcock [mailto:woody@pch.net]=20 Sent: Monday, June 26, 2006 12:14 PM To: Eastlake III Donald-LDE008; David Ulevitch Cc: namedroppers@ops.ietf.org Subject: Re: You saw this, right? > Anycast accessed servers are > unlikely to be recursive servers or otherwise act as resolvers due to > the confusion that would result in getting responses to their queries > back to the right machine. Hi, Donald. =20 We're having king of hard time figuring out what you're getting at here. =20 Care to clarify it? -Bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 26 13:32:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuuwf-00029m-RJ for dnsext-archive@lists.ietf.org; Mon, 26 Jun 2006 13:32:21 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fuuwd-0003nh-Ga for dnsext-archive@lists.ietf.org; Mon, 26 Jun 2006 13:32:21 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fuuu2-000OsN-9I for namedroppers-data@psg.com; Mon, 26 Jun 2006 17:29:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [144.189.100.105] (helo=motgate5.mot.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fuuu1-000OsA-GG for namedroppers@ops.ietf.org; Mon, 26 Jun 2006 17:29:37 +0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id k5QHTaTH011050 for ; Mon, 26 Jun 2006 10:29:36 -0700 (MST) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id k5QHTZ6M007771 for ; Mon, 26 Jun 2006 12:29:36 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: You saw this, right? Date: Mon, 26 Jun 2006 13:29:34 -0400 Message-ID: <3870C46029D1F945B1472F170D2D97900111F6D1@de01exm64.ds.mot.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: You saw this, right? Thread-Index: AcaZQq+QP/owqWRbREqXcLLxIv3JxQAAsdpw From: "Eastlake III Donald-LDE008" To: "Bill Woodcock" Cc: "David Ulevitch" , X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 See below at @@@=20 -----Original Message----- From: Bill Woodcock [mailto:woody@pch.net]=20 Sent: Monday, June 26, 2006 1:05 PM To: Eastlake III Donald-LDE008 Cc: David Ulevitch; namedroppers@ops.ietf.org Subject: RE: You saw this, right? > What I was thinking was, assume you have N anycast hosts who are DNS > servers and all receive DNS queries sent to IP address ADDR-0. All are capable of receiving, but only one actually receives any specific query... @@@ Yes, sorry I didn't word that well. If they all received the query, it would be multicast, not anycast. > If they really all think they are just a host at address ADDR-0 and=20 > any of these host sends out a DNS query, presumably the anycast=20 > nature of their address would mean that the response to that query > could come back to a different one than the host which originated=20 > the query. Ah, I see what you were getting at. In practice, one never originates a transaction with the anycast address as source. One only originates transactions from the host's unique address. In practice, the anycast service addresses are loopbacks internal to the host, while the actual physical interfaces which are used to originate transactions use the host's unique addresses. So this is never actually a problem. I suppose in the interests of thoroughness, it wouldn't hurt to explain why, so new people don't have to stub their toes on that same corner-case. @@@ OK, thanks, @@@ Donald -Bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 26 14:05:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuvSU-0000nB-8S for dnsext-archive@lists.ietf.org; Mon, 26 Jun 2006 14:05:14 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuvSR-0006QI-Vl for dnsext-archive@lists.ietf.org; Mon, 26 Jun 2006 14:05:14 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FuvPx-0001ur-7V for namedroppers-data@psg.com; Mon, 26 Jun 2006 18:02:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FuvPv-0001ud-Dn for namedroppers@ops.ietf.org; Mon, 26 Jun 2006 18:02:35 +0000 Received: from [10.31.32.59] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k5QI2OCK022199; Mon, 26 Jun 2006 14:02:25 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20060626163919.GR409@unknown.office.denic.de> References: <20060626163919.GR409@unknown.office.denic.de> Date: Mon, 26 Jun 2006 13:57:20 -0400 To: Peter Koch From: Edward Lewis Subject: Re: DNAME question Cc: IETF DNSEXT WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 At 18:39 +0200 6/26/06, Peter Koch wrote: >However, "ns0.tld1." must not appear on the RHS of the "tld2." NS RR, since >it is not immediately resolvable to an address record. So, the problem isn't >about glue, but about the NS RR target. Can there be any name server in the tld1. domain? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-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 Jun 26 14:47:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuw7f-0001Ag-LB for dnsext-archive@lists.ietf.org; Mon, 26 Jun 2006 14:47:47 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fuw7d-0001Lo-Bd for dnsext-archive@lists.ietf.org; Mon, 26 Jun 2006 14:47:47 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fuw4H-0006Jf-95 for namedroppers-data@psg.com; Mon, 26 Jun 2006 18:44:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [129.188.136.8] (helo=motgate8.mot.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fuw4G-0006JT-JN for namedroppers@ops.ietf.org; Mon, 26 Jun 2006 18:44:16 +0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k5QIiFjA003065 for ; Mon, 26 Jun 2006 11:44:15 -0700 (MST) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k5QIiFxN017364 for ; Mon, 26 Jun 2006 13:44:15 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: You saw this, right? / Cookies/ RE: stopping amplification Date: Mon, 26 Jun 2006 14:44:14 -0400 Message-ID: <3870C46029D1F945B1472F170D2D97900111F766@de01exm64.ds.mot.com> In-Reply-To: <20060328183435.0CD7C11425@sa.vix.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: You saw this, right? / Cookies/ RE: stopping amplification Thread-Index: AcZSl249Wk6BjzCjS1Oj5iJB61IN6BGtSJMQ From: "Eastlake III Donald-LDE008" To: X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Sorry the context of these "RE: You saw this, right?" messages was not clear. They are in connection with my draft http://www.ietf.org/internet-drafts/draft-eastlake-dnsext-cookies-00.txt . This tries to help with some problems including some mentioned in http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00450.html. Donald -- to unsubscribe send a message to namedroppers-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 Jun 26 15:09:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuwSF-0000MY-7j for dnsext-archive@lists.ietf.org; Mon, 26 Jun 2006 15:09:03 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuwSD-00039u-Ui for dnsext-archive@lists.ietf.org; Mon, 26 Jun 2006 15:09:03 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FuwPo-00087a-VJ for namedroppers-data@psg.com; Mon, 26 Jun 2006 19:06:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.1.1 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FuwPo-00087O-5x for namedroppers@ops.ietf.org; Mon, 26 Jun 2006 19:06:32 +0000 Received: from zephyr.dhcp.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN matt, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.verisignlabs.com with esmtp; Mon, 26 Jun 2006 15:06:31 -0400 id 002CC0CB.44A03037.00001ED4 Date: Mon, 26 Jun 2006 15:06:30 -0400 From: Matt Larson To: Peter Koch , Edward Lewis Cc: IETF DNSEXT WG Subject: Re: DNAME question Message-ID: <20060626190630.GJ24877@zephyr.dhcp.verisignlabs.com> References: <20060626163919.GR409@unknown.office.denic.de> <20060626163919.GR409@unknown.office.denic.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <20060626163919.GR409@unknown.office.denic.de> User-Agent: Mutt/1.5.11 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab On Mon, 26 Jun 2006, Peter Koch wrote: > So, the problem isn't about glue, but about the NS RR target. I agree with this assessment. On Mon, 26 Jun 2006, Ed Lewis wrote: > Can there be any name server in the tld1. domain? No, because nothing at or below tld1 is a canonical name. I tested something similar recently. Neither a late-model BIND 9 nor the Unbound iterative resolvers could use an NS RR whose RDATA was an alias (i.e., owned by a CNAME). Recall that authoritative servers are going to synthesize CNAMEs from that DNAME, so the DNAME effectively (de)generates to CNAMEs. Matt -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 26 18:20:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuzRI-0002ih-PL for dnsext-archive@lists.ietf.org; Mon, 26 Jun 2006 18:20:16 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuzRG-0005Wm-Dc for dnsext-archive@lists.ietf.org; Mon, 26 Jun 2006 18:20:16 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FuzMz-000OPo-0Y for namedroppers-data@psg.com; Mon, 26 Jun 2006 22:15:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_ZOMBIE autolearn=no version=3.1.1 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FuzMx-000OPY-Oc for namedroppers@ops.ietf.org; Mon, 26 Jun 2006 22:15:47 +0000 Received: from [130.105.12.10] ([130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id k5QMFfZs021236 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 26 Jun 2006 18:15:41 -0400 Date: Mon, 26 Jun 2006 18:15:40 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: "Olaf M. Kolkman" cc: IETF DNSEXT WG , Mark Townsley Subject: Re: nsid last call In-Reply-To: <36D0F62B-7E0A-44E4-A0D7-2DFEEB45FC7A@NLnetLabs.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.8 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Umm it seems that the language for "as long as the content ... over a series of queries" is not included in the new draft -02. "_not_ removing" seems to mean that it should be included. Right? Was this a mistake? Or did I miss something? I certainly missed the legitimate reason to hide anycast instances while seeming to support NSID.... Anyone who doesn't want allow anycast identification doesn't need to permit NSID. Please think of how one would require (say root operators) to support NSID such that Anycast instances have to be identified. With the "as long as the content ... over a series of queries" language, you just require them to support and respond to NSID. Without this language, it becomes much more difficult to specify. The flip side, not giving out NSID information, is easily accomplished by authorization similar to AXFR, etc. And the spoofing of responses is certainly not something that needs to be in a standard. Why do things differently, now? --Dean On Mon, 19 Jun 2006, Olaf M. Kolkman wrote: > > Kind Colleagues, > > I have seen the discussion develop over the last couple of days and I > think it has converged to a point where arguments are being > reiterated. I have not seen a clear consensus building for '_not_ > removing "as long as the content ... over a series of queries"'. > Hence I would like to request the editors to include the above > version of 3.1 in the draft (modulo the possible "Strunk and White" > and "Merriam-Webster" kind of corrections that are needed to turn the > text into plain english). > > > --Olaf > > > ----------------------------------------------------------- > Olaf M. Kolkman > NLnet Labs > http://www.nlnetlabs.nl/ > > > > -- 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 Mon Jun 26 18:46:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuzr7-0008LD-9W for dnsext-archive@lists.ietf.org; Mon, 26 Jun 2006 18:46:57 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fuzr5-0007Y0-SX for dnsext-archive@lists.ietf.org; Mon, 26 Jun 2006 18:46:57 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fuzp8-0000h6-2h for namedroppers-data@psg.com; Mon, 26 Jun 2006 22:44:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fuzp5-0000gq-CG; Mon, 26 Jun 2006 22:44:51 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 26 Jun 2006 23:44:49 +0100 X-IronPort-AV: i="4.06,178,1149462000"; d="scan'208"; a="4243567:sNHT32623356" In-Reply-To: <20060626163919.GR409@unknown.office.denic.de> To: Peter Koch Cc: IETF DNSEXT WG , owner-namedroppers@ops.ietf.org Subject: Re: DNAME question MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Roy Arends Date: Tue, 27 Jun 2006 00:44:04 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 06/26/2006 11:44:01 PM, Serialize complete at 06/26/2006 11:44:01 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 owner-namedroppers@ops.ietf.org wrote on 06/26/2006 06:39:19 PM: > On Mon, Jun 26, 2006 at 04:57:12PM +0200, Roy Arends wrote: > > > > tld1. DNAME tld0. > > > tld1. MX 10 mailhost.tld0. > > > ; > > > tld2. NS ns0.tld1. > > > > > > Is it legal to have the following as glue? > > > > > > ns0.tld1. A 127.0.0.2 > > > > It ain't glue, since there is no zone-cut for tld1. > > that's not really the point here. The root applies a 'wide' glue policy, so it > maintains glue RRs for every NS RR target for any delegation ("tld2." in > this case). > > However, "ns0.tld1." must not appear on the RHS of the "tld2." NS RR, since > it is not immediately resolvable to an address record. So, the problem isn't > about glue, but about the NS RR target. That is not the problem either. The question was: Is it legal to have the following as glue? ns0.tld1. A 127.0.0.2 Regardless if ns0.tld1 A can be resolved or not, if it is a target anywhere, or if you call it wide, narrow, in-bailiwick or super glue, it is not legal to have that address record in the root zone. period. this is explicitly written in rfc2672: If a DNAME RR is present at a node N, there may be other data at N (except a CNAME or another DNAME), but there MUST be no data at any descendant of N. This restriction applies only to records of the same class as the DNAME record. Then I wrote: > > It is not legal. In response to > If it is not legal, can there ever been any name servers inside tld1? Assuming Ed meant NS records with 'name servers'; This is not legal because you can't have a non-APEX NS set and other data (except for DNSSEC records). DNAME is 'other data' in this case. > The result is the same at this level. It is not legal for entirely different reasons. 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 Jun 26 19:06:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv0AH-0001bI-16 for dnsext-archive@lists.ietf.org; Mon, 26 Jun 2006 19:06:45 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv0AF-0002de-OP for dnsext-archive@lists.ietf.org; Mon, 26 Jun 2006 19:06:45 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fuzvu-0001OO-1c for namedroppers-data@psg.com; Mon, 26 Jun 2006 22:51:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fuzvr-0001O6-Ol; Mon, 26 Jun 2006 22:51:51 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 26 Jun 2006 23:51:50 +0100 X-IronPort-AV: i="4.06,178,1149462000"; d="scan'208"; a="3797025:sNHT32704632" In-Reply-To: <20060626190630.GJ24877@zephyr.dhcp.verisignlabs.com> To: Matt Larson Cc: Edward Lewis , IETF DNSEXT WG , owner-namedroppers@ops.ietf.org, Peter Koch Subject: Re: DNAME question MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Roy Arends Date: Tue, 27 Jun 2006 00:51:04 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 06/26/2006 11:51:02 PM, Serialize complete at 06/26/2006 11:51:02 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Matt Larson wrote on 06/26/2006 09:06:30 PM: > On Mon, 26 Jun 2006, Ed Lewis wrote: > > Can there be any name server in the tld1. domain? > > No, because nothing at or below tld1 is a canonical name. _at_ tld1 is still canonical. below tld1 is effectively an alias. 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 Jun 26 19:27:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv0UJ-0007II-Pu for dnsext-archive@lists.ietf.org; Mon, 26 Jun 2006 19:27:27 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv0UH-0004H7-F4 for dnsext-archive@lists.ietf.org; Mon, 26 Jun 2006 19:27:27 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fv0RD-0003yE-Ss for namedroppers-data@psg.com; Mon, 26 Jun 2006 23:24:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.1 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fv0Qh-0003tz-8j for namedroppers@ops.ietf.org; Mon, 26 Jun 2006 23:23:43 +0000 Received: from [192.168.1.13] ([::ffff:70.110.18.119]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Mon, 26 Jun 2006 19:23:42 -0400 id 002D0014.44A06C7E.0000728B Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <20060626190630.GJ24877@zephyr.dhcp.verisignlabs.com> References: <20060626163919.GR409@unknown.office.denic.de> <20060626163919.GR409@unknown.office.denic.de> <20060626190630.GJ24877@zephyr.dhcp.verisignlabs.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1345FD94-4F2F-4FB2-8A46-A202AFD9D4E1@verisignlabs.com> Content-Transfer-Encoding: 7bit From: David Blacka Subject: Re: DNAME question Date: Mon, 26 Jun 2006 19:23:41 -0400 To: IETF DNSEXT WG X-Mailer: Apple Mail (2.750) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 On Jun 26, 2006, at 3:06 PM, Matt Larson wrote: > On Mon, 26 Jun 2006, Peter Koch wrote: >> So, the problem isn't about glue, but about the NS RR target. > > I agree with this assessment. > > On Mon, 26 Jun 2006, Ed Lewis wrote: >> Can there be any name server in the tld1. domain? > > No, because nothing at or below tld1 is a canonical name. I tested > something similar recently. Neither a late-model BIND 9 nor the > Unbound iterative resolvers could use an NS RR whose RDATA was an > alias (i.e., owned by a CNAME). Recall that authoritative servers are > going to synthesize CNAMEs from that DNAME, so the DNAME effectively > (de)generates to CNAMEs. To be clear, what I think Matt is pointing out is that you cannot (reliably) have any nameserver *targets* under "tld1.". So, for example, if: tld1. DNAME tld0. And, in "example.tld0." there exists: sub.example.tld0. NS ns1.example.tld1. sub.example.tld0. NS ns2.example.tld2. then "sub.example.tld0" (or sub.example.tld1.) will not generally be reachable. At least, as I understand it. -- David Blacka Sr. Engineer VeriSign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 26 19:46:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv0mi-0002ZG-RW for dnsext-archive@lists.ietf.org; Mon, 26 Jun 2006 19:46:28 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv0mh-0007JH-IE for dnsext-archive@lists.ietf.org; Mon, 26 Jun 2006 19:46:28 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fv0kW-0005c2-22 for namedroppers-data@psg.com; Mon, 26 Jun 2006 23:44:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fv0kV-0005bo-5W; Mon, 26 Jun 2006 23:44:11 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 27 Jun 2006 00:44:09 +0100 X-IronPort-AV: i="4.06,178,1149462000"; d="scan'208"; a="3797136:sNHT34308204" In-Reply-To: To: Edward Lewis Cc: IETF DNSEXT WG , owner-namedroppers@ops.ietf.org, Peter Koch Subject: Re: DNAME question MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Roy Arends Date: Tue, 27 Jun 2006 01:43:24 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 06/27/2006 12:43:21 AM, Serialize complete at 06/27/2006 12:43:21 AM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Ed Lewis wrote on 06/26/2006 07:57:20 PM: > At 18:39 +0200 6/26/06, Peter Koch wrote: > > >However, "ns0.tld1." must not appear on the RHS of the "tld2." NS RR, since > >it is not immediately resolvable to an address record. So, the problem isn't > >about glue, but about the NS RR target. > > Can there be any name server in the tld1. domain? Trying to finally answer Ed's question. Can there be any name server in the tld1. domain. In the way you wrote your root-zone example, there can't But if you had delegated tld1 out of the root zone, then you can have a DNAME at tld1's apex, together with NS records at the apex, with NSDAME (NS RDATA, or NS targets) at (but not below) or outside tld1. Not below since the NS RDATA of NS record at the tld1's apex and zone cut must be canonical (rfc 2181), while everything under (but not at) the DNAME is effectively an alias. 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 Jun 26 20:44:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv1hG-0000rM-77 for dnsext-archive@lists.ietf.org; Mon, 26 Jun 2006 20:44:54 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv1hE-00043E-MM for dnsext-archive@lists.ietf.org; Mon, 26 Jun 2006 20:44:54 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fv1e4-000ARh-Fv for namedroppers-data@psg.com; Tue, 27 Jun 2006 00:41:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [202.224.39.217] (helo=mails1.asahi-net.or.jp) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fv1e3-000ARS-9C for namedroppers@ops.ietf.org; Tue, 27 Jun 2006 00:41:35 +0000 Received: from mailav1.asahi-net.or.jp (mailav1.asahi-net.or.jp [202.224.39.220]) by mails1f.asahi-net.or.jp (Postfix) with SMTP id 29609C605 for ; Tue, 27 Jun 2006 09:41:34 +0900 (JST) Received: from mails2.asahi-net.or.jp ([202.224.39.218]) by mailav1.asahi-net.or.jp (NAVGW 2.5.2.9) with SMTP id M2006062709413325241 for ; Tue, 27 Jun 2006 09:41:33 +0900 Received: from mx0.k2r.org (s163221.ppp.asahi-net.or.jp [220.157.163.221]) by mails2.asahi-net.or.jp (Postfix) with ESMTP id 692D8C60D for ; Tue, 27 Jun 2006 09:41:33 +0900 (JST) Received: (qmail 30688 invoked by uid 1000); 27 Jun 2006 00:41:33 -0000 Date: Tue, 27 Jun 2006 09:41:33 +0900 From: Kenji Rikitake To: Eastlake III Donald-LDE008 Cc: namedroppers@ops.ietf.org Subject: Re: draft-eastlake-dnsext-cookies-00.txt Message-ID: <20060627004133.GA29959%kenji.rikitake@acm.org> References: <20060626070430.GA5385%kenji.rikitake@acm.org> <3870C46029D1F945B1472F170D2D97900111F5C1@de01exm64.ds.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3870C46029D1F945B1472F170D2D97900111F5C1@de01exm64.ds.mot.com> User-Agent: Mutt/1.4.2.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b In the message <3870C46029D1F945B1472F170D2D97900111F5C1@de01exm64.ds.mot.com> dated Mon, Jun 26, 2006 at 10:41:18AM -0400, Eastlake III Donald-LDE008 writes: > @@@ Well, the current wording isn't wrong and the situation isn't > exactly parallel due to the inclusion of the Resolver Cookie in the > Server Cookie calculation. I'll think about it. I accept, regarding the different requirements you mentioned for the Resolver and Server Cookies. > @@@ With something as widespread as DNS, there will always be old or > simplified new implementations that lack a feature. It's the job of the > IETF to say what is the standard. [...] I understand the background phylosophy and have no objection for the described nature of your I-D. > @@@ If a minimum recommended rollover period was to be included, I'd say > a day. I have no objection so far, though I feel some more studies are needed. It also depends on how many different resolvers a server has to communicate with, for the simultaneous entropy (as in RFC4086) requirement. > * SHOULD/MUST a server/resolver change the cookie for each program on > the other end? > > @@@ Not completely sure I understand what you mean but I would say no. > Arguably there is really only one logical DNS entity at a host. OK, so only one Cookie Secret bound for an IP address. Am I right? Regards, // Kenji Rikitake -- to unsubscribe send a message to namedroppers-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 Jun 27 00:00:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv4l0-0002oE-FL for dnsext-archive@lists.ietf.org; Tue, 27 Jun 2006 00:00:58 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv4kz-0004v3-3H for dnsext-archive@lists.ietf.org; Tue, 27 Jun 2006 00:00:58 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fv4f4-0001R3-0i for namedroppers-data@psg.com; Tue, 27 Jun 2006 03:54:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [129.188.136.8] (helo=motgate8.mot.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fv4f1-0001QO-6z for namedroppers@ops.ietf.org; Tue, 27 Jun 2006 03:54:47 +0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k5R3sg06014210 for ; Mon, 26 Jun 2006 20:54:42 -0700 (MST) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k5R3sfkH019342 for ; Mon, 26 Jun 2006 22:54:41 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-eastlake-dnsext-cookies-00.txt Date: Mon, 26 Jun 2006 23:54:40 -0400 Message-ID: <3870C46029D1F945B1472F170D2D97900111F975@de01exm64.ds.mot.com> In-Reply-To: <20060627004133.GA29959%kenji.rikitake@acm.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-eastlake-dnsext-cookies-00.txt Thread-Index: AcaZgnMhY0/RfvZhQz6iT37zJXa+DwAGizIA From: "Eastlake III Donald-LDE008" To: "Kenji Rikitake" Cc: X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 See below at ###=20 -----Original Message----- From: Kenji Rikitake [mailto:kenji.rikitake@acm.org]=20 Sent: Monday, June 26, 2006 8:42 PM To: Eastlake III Donald-LDE008 Cc: namedroppers@ops.ietf.org Subject: Re: draft-eastlake-dnsext-cookies-00.txt In the message <3870C46029D1F945B1472F170D2D97900111F5C1@de01exm64.ds.mot.com> dated Mon, Jun 26, 2006 at 10:41:18AM -0400, Eastlake III Donald-LDE008 writes: ... > @@@ If a minimum recommended rollover period was to be included, I'd=20 > say a day. I have no objection so far, though I feel some more studies are needed. It also depends on how many different resolvers a server has to communicate with, for the simultaneous entropy (as in RFC4086) requirement. ### Sure, more studies are fine. > * SHOULD/MUST a server/resolver change the cookie for each program on=20 > the other end? >=20 > @@@ Not completely sure I understand what you mean but I would say no. > Arguably there is really only one logical DNS entity at a host. OK, so only one Cookie Secret bound for an IP address. Am I right? ### One per server and one per resolver. Multiple resolver could, due to NATing, appear to a server to be from the same IP address... Regards, // Kenji Rikitake ### Thanks, ### Donald -- to unsubscribe send a message to namedroppers-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 Jun 27 03:55:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv8QH-0002JW-Os for dnsext-archive@lists.ietf.org; Tue, 27 Jun 2006 03:55:49 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv8QG-0005OA-7h for dnsext-archive@lists.ietf.org; Tue, 27 Jun 2006 03:55:49 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fv8Mv-000Nik-V6 for namedroppers-data@psg.com; Tue, 27 Jun 2006 07:52:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fv8Ms-000NiI-7T for namedroppers@ops.ietf.org; Tue, 27 Jun 2006 07:52:18 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1:211:2fff:fed7:7378]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k5R7qDPT050396; Tue, 27 Jun 2006 09:52:13 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: <6.2.5.6.2.20060626105457.050ea9a8@nic.mx> References: <6.2.5.6.2.20060612102822.03b52c00@ogud.com> <7.0.1.0.2.20060612174002.03d76008@nominum.com> <2805B0B0-CFA9-49E7-8ABD-4279673564D8@NLnetLabs.nl> <6.2.5.6.2.20060626105457.050ea9a8@nic.mx> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-17--858642949" Message-Id: <1C71D26A-A127-42B8-948B-F2808A3AC947@NLnetLabs.nl> Cc: Namedroppers Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Recall: Key rollover Work. Date: Tue, 27 Jun 2006 09:52:12 +0200 To: Gustavo Lozano X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.750) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-17--858642949 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed On Jun 26, 2006, at 6:05 PM, Gustavo Lozano asked: > I want to know what the status of this proposal is. Gustavo, Thanks for asking, you are the first person that makes me sure that =20 my mail did not hit everybody's spam filter. In a separate thread the other week I posted a proposal. > 1 - All editors off drafts make sure that their drafts are alive in > the repository. (before start of summer, June 21) > 2 - Maybe some editors want to revoke their draft in lessen the > entropy in this space or just because they think another draft is > superior What we have is currently, without having talked to any of these folk: Expired: http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-=20 trustupdate-threshold I am not sure what Ihren and Manning would like to see happening to =20 this proposal. About to expire: http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-=20 trustupdate-timers I work from the assumption that this is one of the (promising[*]) =20 candidates And from individuals we have: draft-laurie-dnssec-key-distribution-02.txt Finally there is Thieries work: http://tools.ietf.org/wg/dnsext/draft-moreau-dnsext-takrem-dns-02.txt Note that this document (version 2) now has a "Derivative Works =20 Limitation" given RFC3978 that excludes it from becoming a working =20 group document. That also means that it is reasonable to not expect =20 people to put any effort into reviewing and improving it. I am not =20 sure what the procedure is when people want to run with version 1 of =20 the document that was less restrictive. If people think then takrem =20 is the best technology after sliced bread and it should be considered =20= for working group adoption than feel free to post that on the list, =20 we can either work with the author or sort out if it is possible to =20 go from version 1. DLV is not on the table as far as I am concerned. In practice this means that we have 3 documents to consider. > > 3 - We start a reading round of one month. Here we need working group > participants doing real work (!). I would like to see (at least 5?) > people to read _all_ the drafts. (before IETF meeting (?)) > > 4 - While reading drafts reviewers create issue lists > > 5 - All people that read _all_ drafts (hopefully more than 5) will > provide their motivated preference, say a top 3. Motivation is to be > based on requirements. (There are folk who did proposal comparison. > It would be good if those were reviewed and reposted at that time). > Note that Alberto Mart=EDnez Herrera's comparison is still available at: http://docs.nicmxlabs.org.mx/itesm/dnsseckeyrolloverproposals.pdf I recall there is a second comparison but I cannot find it. Still we new more reviewers. By having people comment and choose on =20 proposals we can get forward progression. > 6- We compile a shortlist of 1 or 2 documents and work to technically > improve those to get a consensus outcome. > > > I am hesitant to spend to much face-2-face time on rehashing previous > discussion. But if we manage to have some review done, issues > identified, and preferences stated, we may actually be able to make > real progress. > > I'd say that committed reviewers need anything between 1 to 3 days to > do this work. > > Any comments, alternative approaches, takers? As I am trying to come up with a reasonable way to pick up forward =20 momentum, this is still an open question: comments, alternatives, =20 takers? ---Olaf [*] oops .. there goes your neutral chair. ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-17--858642949 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFEoOOstN/ca3YJIocRAvjBAJwNmqv/hteB5MMmgPiOMdOf81wAJACgru8j aQk7xq0ZbVWMD1JfeC4pTMU= =MCxU -----END PGP SIGNATURE----- --Apple-Mail-17--858642949-- -- to unsubscribe send a message to namedroppers-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 Jun 27 05:53:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvAFr-0005g7-MX for dnsext-archive@lists.ietf.org; Tue, 27 Jun 2006 05:53:11 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvAFq-0003Ki-CS for dnsext-archive@lists.ietf.org; Tue, 27 Jun 2006 05:53:11 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvACc-000Ag4-4j for namedroppers-data@psg.com; Tue, 27 Jun 2006 09:49:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvACa-000Afm-Ns for namedroppers@ops.ietf.org; Tue, 27 Jun 2006 09:49:49 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k5R9ng4X025068; Tue, 27 Jun 2006 11:49:42 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v750) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-22--851598276" Message-Id: <1D1A0F32-0343-4AD0-947C-0ED26ECAFAC2@NLnetLabs.nl> Cc: IETF DNSEXT WG , Mark Townsley Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: nsid last call Date: Tue, 27 Jun 2006 11:49:36 +0200 To: Dean Anderson X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.750) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-22--851598276 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear Dean, You wrote: > Umm it seems that the language for "as long as the content ... over > a series of > queries" is not included in the new draft -02. > > "_not_ removing" seems to mean that it should be included. Right? > > Was this a mistake? Or did I miss something? I made the mistake of using double negations in "I have not seen a clear consensus building for '_not_ removing"... I should have used "There is consensus to remove text that requires the NSID content to remain constant over a series of queries". I agree that this formulation, and earlier use of triple negations, may have caused confusion. But, there was no mistake in determining the rough consensus. I think that I clearly indicated the guiding principle with "a one person call in favor for identifying the any cast instances over a series of queries is not sufficient to overhaul an issue that was brought up pre-last call". (See [1] and reference therein for the pre- last call technical argument for not keeping NSID constant over a series of queries). The determination of rough consensus and the instructions to the editor were in line with this guiding principle. My sincere apologies for the confusion this may have caused. In the future I will try to prevent use multiple negations in last calls and consensus summaries. --Olaf [1] http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg00737.html ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-22--851598276 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFEoP82tN/ca3YJIocRApYqAJ9Arqc2Wnmmy3XpC21sREBdaa+QqwCglC8E j3m76pUejG5/z2RseVRRkuA= =8Y6/ -----END PGP SIGNATURE----- --Apple-Mail-22--851598276-- -- to unsubscribe send a message to namedroppers-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 Jun 27 07:30:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvBmA-0005sG-D6 for dnsext-archive@lists.ietf.org; Tue, 27 Jun 2006 07:30:38 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvBm9-0004w2-3D for dnsext-archive@lists.ietf.org; Tue, 27 Jun 2006 07:30:38 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvBiu-000LQh-Ik for namedroppers-data@psg.com; Tue, 27 Jun 2006 11:27:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,DNS_FROM_RFC_WHOIS,SPF_HELO_PASS, SPF_PASS autolearn=no version=3.1.1 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvBit-000LQC-Pr for namedroppers@ops.ietf.org; Tue, 27 Jun 2006 11:27:15 +0000 Received: from [192.168.1.13] ([::ffff:70.110.18.119]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Tue, 27 Jun 2006 07:27:14 -0400 id 002D002F.44A11612.000053FA In-Reply-To: <44A1147E.3010602@ntp.isc.org> References: <5A8121DB-8360-4F77-B76E-BA7A66896FE4@verisignlabs.com> <65DAC880-49C7-4815-932A-053C632F02BD@verisignlabs.com> <449FC760.8000804@ntp.isc.org> <1C0DE33B-2A6F-4B32-AE1D-B3809CC9B389@verisignlabs.com> <44A1147E.3010602@ntp.isc.org> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Namedroppers WG Content-Transfer-Encoding: 7bit From: David Blacka Subject: Re: NSEC3 Issue 18: signalling complete NSEC3 chains Date: Tue, 27 Jun 2006 07:27:13 -0400 To: mayer@ntp.isc.org X-Mailer: Apple Mail (2.750) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 On Jun 27, 2006, at 7:20 AM, Danny Mayer wrote: > David Blacka wrote: >> >> On Jun 26, 2006, at 7:39 AM, Danny Mayer wrote: >>> >>> Excuse my ignorance here, but doesn't that mean that an attacker >>> could >>> intercept this record replace it with it's own which doesn't have >>> to be >>> authentic and cause the validation to fail thereby causing a DOS >>> attack? >> >> I didn't mean to imply that this NSEC3 RR wouldn't be verified >> when it >> was asked for, just that it would be ignored by validators. >> > > But I thought that it was the validators that would be asking for it. > What else needs it? > In this case (NSEC3 Issue 18), only authoritative servers need it. The issue is that a primary or secondary authoritative servers need to determine what the NSEC3 parameters are from the zone. In the current versions of the draft (-05 and -06), this is done by examining each NSEC3 RR in the zone, looking for the one with the SOA bit set. Some people have pointed out that this sucks. So, the use case here is a server querying its own data, or a secondary querying the primary. -- David Blacka Sr. Engineer VeriSign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 27 08:21:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvCZ9-0006m8-9a for dnsext-archive@lists.ietf.org; Tue, 27 Jun 2006 08:21:15 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvCZ6-0002ei-GO for dnsext-archive@lists.ietf.org; Tue, 27 Jun 2006 08:21:15 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvCWz-00010T-8o for namedroppers-data@psg.com; Tue, 27 Jun 2006 12:19:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvCWw-00010E-FS for namedroppers@ops.ietf.org; Tue, 27 Jun 2006 12:18:58 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id k5RCIcYI020303; Tue, 27 Jun 2006 12:18:38 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id k5RCIcFI020302; Tue, 27 Jun 2006 12:18:38 GMT Date: Tue, 27 Jun 2006 12:18:37 +0000 From: bmanning@vacation.karoshi.com To: "Olaf M. Kolkman" Cc: Gustavo Lozano , Namedroppers Subject: Re: Recall: Key rollover Work. Message-ID: <20060627121837.GA20231@vacation.karoshi.com.> References: <6.2.5.6.2.20060612102822.03b52c00@ogud.com> <7.0.1.0.2.20060612174002.03d76008@nominum.com> <2805B0B0-CFA9-49E7-8ABD-4279673564D8@NLnetLabs.nl> <6.2.5.6.2.20060626105457.050ea9a8@nic.mx> <1C71D26A-A127-42B8-948B-F2808A3AC947@NLnetLabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1C71D26A-A127-42B8-948B-F2808A3AC947@NLnetLabs.nl> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa > Expired: http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext- > trustupdate-threshold > I am not sure what Ihren and Manning would like to see happening to > this proposal. i expect that, based on feedback from the last IETF mtg, there is no interest in this work by the WG. That said, i think this work is perhaps the best way forward - at least for my vision of how the DNS should evolve. That said, i will continue to work on this. > In practice this means that we have 3 documents to consider. > > >3 - We start a reading round of one month. Here we need working group > >participants doing real work (!). I would like to see (at least 5?) > >people to read _all_ the drafts. (before IETF meeting (?)) > > > >4 - While reading drafts reviewers create issue lists > > > >5 - All people that read _all_ drafts (hopefully more than 5) will > >provide their motivated preference, say a top 3. Motivation is to be > >based on requirements. (There are folk who did proposal comparison. > >It would be good if those were reviewed and reposted at that time). > > > > Note that Alberto Martínez Herrera's comparison is still available at: > http://docs.nicmxlabs.org.mx/itesm/dnsseckeyrolloverproposals.pdf i was never able to read this... > [*] oops .. there goes your neutral chair. > > ----------------------------------------------------------- > Olaf M. Kolkman > NLnet Labs > http://www.nlnetlabs.nl/ > > > -- to unsubscribe send a message to namedroppers-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 Jun 27 08:49:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvD0o-0008Rq-GI for dnsext-archive@lists.ietf.org; Tue, 27 Jun 2006 08:49:50 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvD0m-0005ci-3u for dnsext-archive@lists.ietf.org; Tue, 27 Jun 2006 08:49:50 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvCxt-00040R-RX for namedroppers-data@psg.com; Tue, 27 Jun 2006 12:46:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [213.154.224.50] (helo=bartok.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvCxs-0003zN-Pl for namedroppers@ops.ietf.org; Tue, 27 Jun 2006 12:46:49 +0000 Received: from bartok.nlnetlabs.nl (localhost.nlnetlabs.nl [127.0.0.1]) by bartok.nlnetlabs.nl (8.13.6/8.13.6) with ESMTP id k5RCkbwG087311; Tue, 27 Jun 2006 14:46:37 +0200 (CEST) (envelope-from jaap@bartok.nlnetlabs.nl) Message-Id: <200606271246.k5RCkbwG087311@bartok.nlnetlabs.nl> To: bmanning@vacation.karoshi.com cc: "Olaf M. Kolkman" , Gustavo Lozano , Namedroppers Subject: Re: Recall: Key rollover Work. In-reply-to: Your message of Tue, 27 Jun 2006 12:18:37 -0000. <20060627121837.GA20231@vacation.karoshi.com.> Date: Tue, 27 Jun 2006 14:46:37 +0200 From: Jaap Akkerhuis Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 > http://docs.nicmxlabs.org.mx/itesm/dnsseckeyrolloverproposals.pdf i was never able to read this... On a Mac: I actual could open it with safari (directly). It complains about some error (invalid annotation object), but it will continue after you just irnore the error. The Adobe Reader (7.0.5) wil read it in as well, just as Preview does. On FreeBSD: Acroread (7.something) seems to be able to open it. A;so, pdf2dsc turns it intp postscript. Viewing that with gv gives YAE (Yet Another Error but still displays it. I haven't tried to print it yet. jaap -- to unsubscribe send a message to namedroppers-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 Jun 27 08:50:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvD16-0008Sr-Ec for dnsext-archive@lists.ietf.org; Tue, 27 Jun 2006 08:50:08 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvD16-0005dV-DI for dnsext-archive@lists.ietf.org; Tue, 27 Jun 2006 08:50:08 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvD0Z-0005Tm-8u for dnsext-archive@lists.ietf.org; Tue, 27 Jun 2006 08:49:37 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvCyc-00043N-Cg for namedroppers-data@psg.com; Tue, 27 Jun 2006 12:47:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.1 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvCya-000435-J0 for namedroppers@ops.ietf.org; Tue, 27 Jun 2006 12:47:32 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k5RCkYiR027764 for ; Tue, 27 Jun 2006 08:46:34 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAVSaal2; Tue, 27 Jun 06 08:46:26 -0400 Received: from localhost (localhost [127.0.0.1]) by tislabs.com (8.12.9/8.12.9) with ESMTP id k5RCiwtV015306; Tue, 27 Jun 2006 08:44:59 -0400 (EDT) Date: Tue, 27 Jun 2006 08:45:47 -0400 (EDT) From: Sam Weiler X-X-Sender: weiler@lemon.samweiler.com To: "Olaf M. Kolkman" cc: Namedroppers Subject: Re: Recall: Key rollover Work. In-Reply-To: <1C71D26A-A127-42B8-948B-F2808A3AC947@NLnetLabs.nl> Message-ID: References: <6.2.5.6.2.20060612102822.03b52c00@ogud.com> <7.0.1.0.2.20060612174002.03d76008@nominum.com> <2805B0B0-CFA9-49E7-8ABD-4279673564D8@NLnetLabs.nl> <6.2.5.6.2.20060626105457.050ea9a8@nic.mx> <1C71D26A-A127-42B8-948B-F2808A3AC947@NLnetLabs.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 On Tue, 27 Jun 2006, Olaf M. Kolkman wrote: > DLV is not on the table as far as I am concerned. Why is that? I'd like to see the WG members review DLV to see what, if any, problems it may help address -- that may help us scope the work we want to take on within DNSEXT. For those not already aware, there is a DLV draft in the i-d repository: draft-weiler-dnssec-dlv-00.txt Version 01 has been submitted and should appear before the meeting in Montreal. I welcome comments on the document. ISC also published a tech note that purports to describe their implementation. As far as I know, no one has claimed any encumbrance on the technology. -- 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 Jun 27 09:46:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvDtT-0003Ci-D9 for dnsext-archive@lists.ietf.org; Tue, 27 Jun 2006 09:46:19 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvDtS-0008B1-3k for dnsext-archive@lists.ietf.org; Tue, 27 Jun 2006 09:46:19 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvDr2-000AlB-Fy for namedroppers-data@psg.com; Tue, 27 Jun 2006 13:43:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [213.154.224.50] (helo=bartok.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvDr1-000AkT-3G for namedroppers@ops.ietf.org; Tue, 27 Jun 2006 13:43:47 +0000 Received: from bartok.nlnetlabs.nl (localhost.nlnetlabs.nl [127.0.0.1]) by bartok.nlnetlabs.nl (8.13.6/8.13.6) with ESMTP id k5RDhekM087917; Tue, 27 Jun 2006 15:43:40 +0200 (CEST) (envelope-from jaap@bartok.nlnetlabs.nl) Message-Id: <200606271343.k5RDhekM087917@bartok.nlnetlabs.nl> To: "Olaf M. Kolkman" cc: Sam Weiler , Namedroppers Subject: Re: Recall: Key rollover Work. In-reply-to: Your message of Tue, 27 Jun 2006 15:01:53 +0200. <90541EE9-12D8-4A67-8178-22A57D70879E@NLnetLabs.nl> Date: Tue, 27 Jun 2006 15:43:40 +0200 From: Jaap Akkerhuis Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 > On Tue, 27 Jun 2006, Olaf M. Kolkman wrote: > >> DLV is not on the table as far as I am concerned. > > Why is that? Because I thought nobody put it on the table for solving trust-anchor rollover (I may be wrong). Wouldn't you agree that also with DLV you need to have a mechanism to roll te DLV anchor? Note that "to table" has different meanings in different parts of the world. In the US, it is basically putting it to rest, while in the more Anglo Saxion parts it is meant to put for consideration. I think that Olaf uses the latter meaning while Sam might mean the first. Maybe we should not use the term at all. jaap PS: See: http://en.wikipedia.org/wiki/Table_%28verb%29 -- to unsubscribe send a message to namedroppers-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 Jun 27 09:56:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvE3n-0002pq-1e for dnsext-archive@lists.ietf.org; Tue, 27 Jun 2006 09:56:59 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvE3k-00009X-Nu for dnsext-archive@lists.ietf.org; Tue, 27 Jun 2006 09:56:59 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvDxE-000Bc3-Rx for namedroppers-data@psg.com; Tue, 27 Jun 2006 13:50:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvDxE-000Bbd-2B for namedroppers@ops.ietf.org; Tue, 27 Jun 2006 13:50:12 +0000 Received: from [10.31.32.59] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k5RDo2en030235; Tue, 27 Jun 2006 09:50:03 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <90541EE9-12D8-4A67-8178-22A57D70879E@NLnetLabs.nl> References: <6.2.5.6.2.20060612102822.03b52c00@ogud.com> <7.0.1.0.2.20060612174002.03d76008@nominum.com> <2805B0B0-CFA9-49E7-8ABD-4279673564D8@NLnetLabs.nl> <6.2.5.6.2.20060626105457.050ea9a8@nic.mx> <1C71D26A-A127-42B8-948B-F2808A3AC947@NLnetLabs.nl> <90541EE9-12D8-4A67-8178-22A57D70879E@NLnetLabs.nl> Date: Tue, 27 Jun 2006 09:50:26 -0400 To: Namedroppers From: Edward Lewis Subject: Re: Recall: Key rollover Work. Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d At 15:01 +0200 6/27/06, Olaf M. Kolkman wrote: >Because I thought nobody put it on the table for solving trust-anchor >rollover (I may be wrong). Wouldn't you agree that also with DLV you need >to have a mechanism to roll te DLV anchor? I'd have to say no..."shockingly." DLV is being touted as a "temporary, non-scaleable hack" to jump start DNSSEC adoption. As such, long range considerations are not mainstream. Although ... on http://www.nanog.org/mtg-0606/damas.html it does mention DLV as a trust anchor management (avoidance) tool. I'm postulate that DLV is trying to be the 6Bone of IPv6. Perhaps the last DLV will expire on 6/6/6 (as in 3006). ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-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 Jun 27 11:24:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvFQv-0005Ps-OW for dnsext-archive@lists.ietf.org; Tue, 27 Jun 2006 11:24:57 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvDGL-0006Kc-Mg for dnsext-archive@lists.ietf.org; Tue, 27 Jun 2006 09:05:53 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvDED-0005i5-P4 for dnsext-archive@lists.ietf.org; Tue, 27 Jun 2006 09:03:43 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvDCX-0005rD-Ij for namedroppers-data@psg.com; Tue, 27 Jun 2006 13:01:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvDCW-0005qz-KF for namedroppers@ops.ietf.org; Tue, 27 Jun 2006 13:01:56 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k5RD1sMN086634; Tue, 27 Jun 2006 15:01:54 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: References: <6.2.5.6.2.20060612102822.03b52c00@ogud.com> <7.0.1.0.2.20060612174002.03d76008@nominum.com> <2805B0B0-CFA9-49E7-8ABD-4279673564D8@NLnetLabs.nl> <6.2.5.6.2.20060626105457.050ea9a8@nic.mx> <1C71D26A-A127-42B8-948B-F2808A3AC947@NLnetLabs.nl> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-29--840062035" Message-Id: <90541EE9-12D8-4A67-8178-22A57D70879E@NLnetLabs.nl> Cc: Namedroppers Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: Recall: Key rollover Work. Date: Tue, 27 Jun 2006 15:01:53 +0200 To: Sam Weiler X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.750) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.5 (--) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-29--840062035 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Jun 27, 2006, at 2:45 PM, Sam Weiler wrote: > On Tue, 27 Jun 2006, Olaf M. Kolkman wrote: > >> DLV is not on the table as far as I am concerned. > > Why is that? Because I thought nobody put it on the table for solving trust-anchor rollover (I may be wrong). Wouldn't you agree that also with DLV you need to have a mechanism to roll te DLV anchor? --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-29--840062035 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFEoSxBtN/ca3YJIocRAl73AJ0X+VDgWUrn3eea+dXLJQoOwaHAzgCg843q aUOMrhwTQL7NiF+Y/RcIznk= =c0fi -----END PGP SIGNATURE----- --Apple-Mail-29--840062035-- -- to unsubscribe send a message to namedroppers-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 Jun 27 14:26:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvIGC-0002pS-VU for dnsext-archive@lists.ietf.org; Tue, 27 Jun 2006 14:26:04 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvIGA-0008V5-AB for dnsext-archive@lists.ietf.org; Tue, 27 Jun 2006 14:26:04 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvI7d-000Eky-Jc for namedroppers-data@psg.com; Tue, 27 Jun 2006 18:17:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.1 Received: from [157.185.61.2] (helo=M4.sparta.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvI7X-000Eid-7U for namedroppers@ops.ietf.org; Tue, 27 Jun 2006 18:17:09 +0000 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id k5RIGqnH021477; Tue, 27 Jun 2006 13:16:52 -0500 Received: from ponyxpress.rosslyn.ads.sparta.com (861.rosslyn.sparta.com [157.185.86.1]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id k5RIGofc021272; Tue, 27 Jun 2006 13:16:51 -0500 Received: from mailbin.rosslyn.ads.sparta.com ([157.185.85.6]) by ponyxpress.rosslyn.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jun 2006 14:16:50 -0400 Received: from spx.vb.futz.org ([216.27.162.138]) by mailbin.rosslyn.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jun 2006 14:36:06 -0400 Date: Tue, 27 Jun 2006 14:16:42 -0400 From: Robert Story To: Jaap Akkerhuis Cc: "Olaf M. Kolkman" , Sam Weiler , Namedroppers Subject: Re: Recall: Key rollover Work. In-Reply-To: <200606271343.k5RDhekM087917@bartok.nlnetlabs.nl> References: <90541EE9-12D8-4A67-8178-22A57D70879E@NLnetLabs.nl> <200606271343.k5RDhekM087917@bartok.nlnetlabs.nl> Organization: SPARTA X-Mailer: Sylpheed-Claws 2.3.0 (GTK+ 2.8.19; powerpc-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; boundary=Sig_HfNHlB67IQKXe9879GTNbh3; protocol="application/pgp-signature"; micalg=PGP-SHA1 Message-ID: X-OriginalArrivalTime: 27 Jun 2006 18:36:06.0531 (UTC) FILETIME=[8D30B530:01C69A18] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca --Sig_HfNHlB67IQKXe9879GTNbh3 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 27 Jun 2006 15:43:40 +0200 Jaap wrote: JA> > On Tue, 27 Jun 2006, Olaf M. Kolkman wrote: JA> > JA> >> DLV is not on the table as far as I am concerned. JA> > JA> > Why is that? JA> =20 JA> Because I thought nobody put it on the table for solving trust-anch= or =20 JA> rollover (I may be wrong). Wouldn't you agree that also with DLV yo= u =20 JA> need to have a mechanism to roll te DLV anchor? JA> =20 JA> Note that "to table" has different meanings in different parts of JA> the world. In the US, it is basically putting it to rest, while in JA> the more Anglo Saxion parts it is meant to put for consideration. It's a little more complicated than that. "to table" is to delay. e.g. "We're going to table that decision until we have more information. "on the table" is something under consideration. "off the table" is something that is not under consideration. --=20 Robert Story SPARTA --Sig_HfNHlB67IQKXe9879GTNbh3 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEoXYO7/fVLLY1mngRAlTRAJ4m6XIZA+zLp1gNOY1a3oLg9sCGTQCgmF4Y ymito9qQaXcz+OFarpBZF+4= =khTu -----END PGP SIGNATURE----- --Sig_HfNHlB67IQKXe9879GTNbh3-- -- to unsubscribe send a message to namedroppers-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 Jun 27 15:56:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvJfR-00076M-6Z for dnsext-archive@lists.ietf.org; Tue, 27 Jun 2006 15:56:13 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvJfP-000391-Ca for dnsext-archive@lists.ietf.org; Tue, 27 Jun 2006 15:56:12 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvJZf-0001AY-GN for namedroppers-data@psg.com; Tue, 27 Jun 2006 19:50:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [209.173.53.84] (helo=willow.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvJZe-0001AJ-5t for namedroppers@ops.ietf.org; Tue, 27 Jun 2006 19:50:14 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k5RJo39F012496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Jun 2006 19:50:03 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FvJZS-0005J1-VL; Tue, 27 Jun 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-nsec3-06.txt Message-Id: Date: Tue, 27 Jun 2006 15:50:02 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 --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 Hashed Authenticated Denial of Existence Author(s) : B. Laurie, et al. Filename : draft-ietf-dnsext-nsec3-06.txt Pages : 47 Date : 2006-6-27 The DNS Security Extensions introduces the NSEC3 resource record for authenticated denial of existence. This document introduces a new resource record as an alternative to NSEC that provides measures against zone enumeration and allows for gradual expansion of delegation-centric zones. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-nsec3-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-nsec3-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-nsec3-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: <2006-6-27143620.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-nsec3-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-nsec3-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-27143620.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 27 18:56:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvMUG-0003Bu-Nx for dnsext-archive@lists.ietf.org; Tue, 27 Jun 2006 18:56:52 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvMUF-0005xK-9L for dnsext-archive@lists.ietf.org; Tue, 27 Jun 2006 18:56:52 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvMPy-000HcK-3I for namedroppers-data@psg.com; Tue, 27 Jun 2006 22:52:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_ZOMBIE autolearn=no version=3.1.1 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvMPw-000Hc4-Jx for namedroppers@ops.ietf.org; Tue, 27 Jun 2006 22:52:24 +0000 Received: from [130.105.12.10] ([130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id k5RMotRV022528 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 27 Jun 2006 18:51:15 -0400 Date: Tue, 27 Jun 2006 18:50:49 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: "Olaf M. Kolkman" cc: IETF DNSEXT WG , Mark Townsley , Subject: Re: nsid last call In-Reply-To: <1D1A0F32-0343-4AD0-947C-0ED26ECAFAC2@NLnetLabs.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.8 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 On Tue, 27 Jun 2006, Olaf M. Kolkman wrote: > Dear Dean, > > You wrote: > > Umm it seems that the language for "as long as the content ... over > > a series of > > queries" is not included in the new draft -02. > > > > "_not_ removing" seems to mean that it should be included. Right? > > > > Was this a mistake? Or did I miss something? > > > I made the mistake of using double negations in > "I have not seen a clear consensus building for '_not_ removing"... > > I should have used "There is consensus to remove text that requires > the NSID content to remain constant over a series of queries". I > agree that this formulation, and earlier use of triple negations, may > have caused confusion. > > But, there was no mistake in determining the rough consensus. It seems difficult to assert that while several people including the Chair, can be confused and confusing, that consensus is still correctly achieved amid such confusion. > I think that I clearly indicated the guiding principle with "a one > person call in favor for identifying the any cast instances over a > series of queries is not sufficient to overhaul an issue that was > brought up pre-last call". (See [1] and reference therein for the pre- > last call technical argument for not keeping NSID constant over a > series of queries). Well, since I didn't prompt the change you posted on June 13, nor the subsequent discussion of changing this text, (I almost missed it entirely), there are, at the very least, 2 people who agree with identifying anycast instances over a series of queries. So it cannot be a "one person call" At the very minimum, it is a 2 person call. I think perhaps it is even larger. Matt Larson can accept either version, but seems to prefer slightly my version. Quoting Koch's text, he says he can accept it, but prefers the original text (which I think means my text). Alex Bligh agrees that the spoofing provision does not need to be in the standard. But also doesn't see it necessary to remove. William Leibzon is also not convinced by the DOS argument, and asks for the DOS attack to be better explained and added to the Security Considerations section. John Dickinson seems to agree with Peter Koch, but notes that spoofing is a policy decision that has nothing to do with the protocol. It seems he could be happy without it in the standard. And it was my impression that you (Olaf Kolkman) agreed it should not be in the standard, though perhaps your mind was changed... And of course, I (Dean Anderson) strongly object to the spoofing text. Strongly for spoofing: Peter Koch Ed Lewis Andrew Sullivan geoff@nominet.org.uk No one else posted on the subject. > The determination of rough consensus and the instructions to the > editor were in line with this guiding principle. There seems to be confusion on all sides, so I don't assert that you did anything _intentionally_ wrong on the consensus. But I think it was still wrong, though innocently so. [As I've recently asserted some not-innocently wrong claims of consensus in complaint to the IESG, I think it is important to state a distinction between in an innocent mistake and a not-innocent mistake.] I believe this is an innocent mistake on your part, but a mistake. > My sincere apologies for the confusion this may have caused. In the > future I will try to prevent use multiple negations in last calls and > consensus summaries. Thank you very much. > > > --Olaf > > [1] http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00737.html > > > ----------------------------------------------------------- > Olaf M. Kolkman > NLnet Labs > http://www.nlnetlabs.nl/ > > > > -- 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 Tue Jun 27 21:32:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvOv6-0008GT-3f for dnsext-archive@lists.ietf.org; Tue, 27 Jun 2006 21:32:44 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvOv4-0007sU-L3 for dnsext-archive@lists.ietf.org; Tue, 27 Jun 2006 21:32:44 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvOqf-0003xy-MC for namedroppers-data@psg.com; Wed, 28 Jun 2006 01:28:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_NEUTRAL autolearn=no version=3.1.1 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvOqd-0003xk-NE for namedroppers@ops.ietf.org; Wed, 28 Jun 2006 01:28:08 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id A0AD133C1B; Wed, 28 Jun 2006 02:28:05 +0100 (BST) Message-ID: <44A1DB2D.3050704@algroup.co.uk> Date: Wed, 28 Jun 2006 02:28:13 +0100 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: "Olaf M. Kolkman" CC: Gustavo Lozano , Namedroppers Subject: Re: Recall: Key rollover Work. References: <6.2.5.6.2.20060612102822.03b52c00@ogud.com> <7.0.1.0.2.20060612174002.03d76008@nominum.com> <2805B0B0-CFA9-49E7-8ABD-4279673564D8@NLnetLabs.nl> <6.2.5.6.2.20060626105457.050ea9a8@nic.mx> <1C71D26A-A127-42B8-948B-F2808A3AC947@NLnetLabs.nl> In-Reply-To: <1C71D26A-A127-42B8-948B-F2808A3AC947@NLnetLabs.nl> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Olaf M. Kolkman wrote: > > On Jun 26, 2006, at 6:05 PM, Gustavo Lozano asked: > >> I want to know what the status of this proposal is. > > Gustavo, > > Thanks for asking, you are the first person that makes me sure that my > mail did not hit everybody's spam filter. > > In a separate thread the other week I posted a proposal. > > >> 1 - All editors off drafts make sure that their drafts are alive in >> the repository. (before start of summer, June 21) > >> 2 - Maybe some editors want to revoke their draft in lessen the >> entropy in this space or just because they think another draft is >> superior > > > What we have is currently, without having talked to any of these folk: > > Expired: > http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-trustupdate-threshold > I am not sure what Ihren and Manning would like to see happening to this > proposal. > > About to expire: > http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-trustupdate-timers > I work from the assumption that this is one of the (promising[*]) > candidates > > And from individuals we have: > draft-laurie-dnssec-key-distribution-02.txt > > Finally there is Thieries work: > http://tools.ietf.org/wg/dnsext/draft-moreau-dnsext-takrem-dns-02.txt > > Note that this document (version 2) now has a "Derivative Works > Limitation" given RFC3978 that excludes it from becoming a working group > document. That also means that it is reasonable to not expect people to > put any effort into reviewing and improving it. I am not sure what the > procedure is when people want to run with version 1 of the document that > was less restrictive. If people think then takrem is the best technology > after sliced bread and it should be considered for working group > adoption than feel free to post that on the list, we can either work > with the author or sort out if it is possible to go from version 1. > > DLV is not on the table as far as I am concerned. > > In practice this means that we have 3 documents to consider. > > >> >> 3 - We start a reading round of one month. Here we need working group >> participants doing real work (!). I would like to see (at least 5?) >> people to read _all_ the drafts. (before IETF meeting (?)) >> >> 4 - While reading drafts reviewers create issue lists >> >> 5 - All people that read _all_ drafts (hopefully more than 5) will >> provide their motivated preference, say a top 3. Motivation is to be >> based on requirements. (There are folk who did proposal comparison. >> It would be good if those were reviewed and reposted at that time). >> > > Note that Alberto Martínez Herrera's comparison is still available at: > http://docs.nicmxlabs.org.mx/itesm/dnsseckeyrolloverproposals.pdf > > I recall there is a second comparison but I cannot find it. > > Still we new more reviewers. By having people comment and choose on > proposals we can get forward progression. > > >> 6- We compile a shortlist of 1 or 2 documents and work to technically >> improve those to get a consensus outcome. >> >> >> I am hesitant to spend to much face-2-face time on rehashing previous >> discussion. But if we manage to have some review done, issues >> identified, and preferences stated, we may actually be able to make >> real progress. >> >> I'd say that committed reviewers need anything between 1 to 3 days to >> do this work. >> >> Any comments, alternative approaches, takers? > > As I am trying to come up with a reasonable way to pick up forward > momentum, this is still an open question: comments, alternatives, takers? Well, I guess I'm a taker if there's any interest in my approach. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "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 Tue Jun 27 21:38:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvP0u-0005zM-Sj for dnsext-archive@lists.ietf.org; Tue, 27 Jun 2006 21:38:44 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvP0u-0000LK-RH for dnsext-archive@lists.ietf.org; Tue, 27 Jun 2006 21:38:44 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvOvk-00042T-MX for dnsext-archive@lists.ietf.org; Tue, 27 Jun 2006 21:33:26 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvOsz-00049i-8R for namedroppers-data@psg.com; Wed, 28 Jun 2006 01:30:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_NEUTRAL autolearn=no version=3.1.1 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvOsy-00049I-FD for namedroppers@ops.ietf.org; Wed, 28 Jun 2006 01:30:32 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 9A7DD33C24; Wed, 28 Jun 2006 02:30:30 +0100 (BST) Message-ID: <44A1DBBE.8070401@algroup.co.uk> Date: Wed, 28 Jun 2006 02:30:38 +0100 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Edward Lewis CC: Namedroppers Subject: Re: Recall: Key rollover Work. References: <6.2.5.6.2.20060612102822.03b52c00@ogud.com> <7.0.1.0.2.20060612174002.03d76008@nominum.com> <2805B0B0-CFA9-49E7-8ABD-4279673564D8@NLnetLabs.nl> <6.2.5.6.2.20060626105457.050ea9a8@nic.mx> <1C71D26A-A127-42B8-948B-F2808A3AC947@NLnetLabs.nl> <90541EE9-12D8-4A67-8178-22A57D70879E@NLnetLabs.nl> In-Reply-To: X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.3 (--) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Edward Lewis wrote: > At 15:01 +0200 6/27/06, Olaf M. Kolkman wrote: > >> Because I thought nobody put it on the table for solving trust-anchor >> rollover (I may be wrong). Wouldn't you agree that also with DLV you need >> to have a mechanism to roll te DLV anchor? > > I'd have to say no..."shockingly." > > DLV is being touted as a "temporary, non-scaleable hack" to jump start > DNSSEC adoption. As such, long range considerations are not mainstream. That makes it not a candidate for trust anchor rollover, then, surely, since that is a long range consideration. > > Although ... on http://www.nanog.org/mtg-0606/damas.html it does mention > DLV as a trust anchor management (avoidance) tool. > > I'm postulate that DLV is trying to be the 6Bone of IPv6. Perhaps the > last DLV will expire on 6/6/6 (as in 3006). ;) > -- http://www.apache-ssl.org/ben.html http://www.links.org/ "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 Wed Jun 28 01:17:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvSQT-0000Gh-M8 for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 01:17:21 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvSQS-0003dJ-D8 for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 01:17:21 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvSMF-000MII-0r for namedroppers-data@psg.com; Wed, 28 Jun 2006 05:12:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvSM6-000MGz-G7 for namedroppers@ops.ietf.org; Wed, 28 Jun 2006 05:12:50 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id BE6FC11427 for ; Wed, 28 Jun 2006 05:12:49 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Namedroppers Subject: Re: Recall: Key rollover Work. In-Reply-To: Your message of "Wed, 28 Jun 2006 02:28:13 +0100." <44A1DB2D.3050704@algroup.co.uk> References: <6.2.5.6.2.20060612102822.03b52c00@ogud.com> <7.0.1.0.2.20060612174002.03d76008@nominum.com> <2805B0B0-CFA9-49E7-8ABD-4279673564D8@NLnetLabs.nl> <6.2.5.6.2.20060626105457.050ea9a8@nic.mx> <1C71D26A-A127-42B8-948B-F2808A3AC947@NLnetLabs.nl> <44A1DB2D.3050704@algroup.co.uk> X-Mailer: MH-E 7.93; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 28 Jun 2006 05:12:49 +0000 Message-ID: <3827.1151471569@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad > >> Any comments, alternative approaches, takers? > > > > As I am trying to come up with a reasonable way to pick up forward > > momentum, this is still an open question: comments, alternatives, takers? > > Well, I guess I'm a taker if there's any interest in my approach. me too, for the simplified version of johani's work that i proposed. -- to unsubscribe send a message to namedroppers-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 Jun 28 01:47:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvSto-0003OW-Nx for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 01:47:40 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvStn-0005Cl-C2 for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 01:47:40 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvSqa-000OpU-Uf for namedroppers-data@psg.com; Wed, 28 Jun 2006 05:44:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvSqZ-000Op9-KP for namedroppers@ops.ietf.org; Wed, 28 Jun 2006 05:44:19 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1:211:2fff:fed7:7378]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k5S5iHI4027037 for ; Wed, 28 Jun 2006 07:44:17 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <3827.1151471569@sa.vix.com> References: <6.2.5.6.2.20060612102822.03b52c00@ogud.com> <7.0.1.0.2.20060612174002.03d76008@nominum.com> <2805B0B0-CFA9-49E7-8ABD-4279673564D8@NLnetLabs.nl> <6.2.5.6.2.20060626105457.050ea9a8@nic.mx> <1C71D26A-A127-42B8-948B-F2808A3AC947@NLnetLabs.nl> <44A1DB2D.3050704@algroup.co.uk> <3827.1151471569@sa.vix.com> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-35--779916827" Message-Id: <60E47F1C-F4B1-4DC2-B947-97262B39C746@NLnetLabs.nl> Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: Recall: Key rollover Work. Date: Wed, 28 Jun 2006 07:44:18 +0200 To: Namedroppers WG X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.750) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-35--779916827 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Thanks Paul and Ben, But, I am looking for takers for review. It really does not help if we have several parties taking their own proposals. We need to converge relatively fast now. I would really appreciate if the working group did the work on technical review. If that is not going to happen then the chairs may have to pick one of the proposals and have that last called as working group output. I don't think that is appropriate. Paul, your proposal only made it to the mail list and never into a draft, correct? --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-35--779916827 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFEohcytN/ca3YJIocRAiYtAKCJD60MBoi5FSlvXjTkbhFVY3E1zQCdHf/4 sKAqTTcwW5u12rLOBwvWbEs= =yp95 -----END PGP SIGNATURE----- --Apple-Mail-35--779916827-- -- to unsubscribe send a message to namedroppers-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 Jun 28 01:55:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvT19-0000l3-Na for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 01:55:15 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvT18-000631-Ee for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 01:55:15 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvSye-000PZX-1B for namedroppers-data@psg.com; Wed, 28 Jun 2006 05:52:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvSyd-000PZ9-5D for namedroppers@ops.ietf.org; Wed, 28 Jun 2006 05:52:39 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k5S5qY3T027148; Wed, 28 Jun 2006 07:52:34 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: <44A1DBBE.8070401@algroup.co.uk> References: <6.2.5.6.2.20060612102822.03b52c00@ogud.com> <7.0.1.0.2.20060612174002.03d76008@nominum.com> <2805B0B0-CFA9-49E7-8ABD-4279673564D8@NLnetLabs.nl> <6.2.5.6.2.20060626105457.050ea9a8@nic.mx> <1C71D26A-A127-42B8-948B-F2808A3AC947@NLnetLabs.nl> <90541EE9-12D8-4A67-8178-22A57D70879E@NLnetLabs.nl> <44A1DBBE.8070401@algroup.co.uk> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-36--779421255" Message-Id: Cc: Edward Lewis , Namedroppers Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: Recall: Key rollover Work. Date: Wed, 28 Jun 2006 07:52:33 +0200 To: Ben Laurie X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.750) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-36--779421255 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed >> DLV is being touted as a "temporary, non-scaleable hack" to jump >> start >> DNSSEC adoption. As such, long range considerations are not >> mainstream. > > That makes it not a candidate for trust anchor rollover, then, surely, > since that is a long range consideration. When I used "nobody put it on the table" I ment to say that nobody put it up for considerations. Ben and Ed just reworded my technical motivation for saying that I think it should not be considered. Point is that we have reasonable proposals with reasonable editors that all support their own work. I was genuinely thinking that DLV is using a different problem (that of finding all available trust- anchors) and hoped that was not one variable that needed to be added to the equation. We need takers for review. --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-36--779421255 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFEohkitN/ca3YJIocRAq1aAKD72z4oTrZG1KdbdKt7d9q6KfGSswCcD9J3 ngnnhcz7MtEMHf1yg3supsU= =XMwK -----END PGP SIGNATURE----- --Apple-Mail-36--779421255-- -- to unsubscribe send a message to namedroppers-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 Jun 28 02:46:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvToh-0002Og-Vj for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 02:46:27 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvTZs-0008Ib-SN for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 02:31:08 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvTKC-0007XS-OO for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 02:14:59 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvTHo-00026s-37 for namedroppers-data@psg.com; Wed, 28 Jun 2006 06:12:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvTHn-00026X-8H for namedroppers@ops.ietf.org; Wed, 28 Jun 2006 06:12:27 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k5S6BsHT027568; Wed, 28 Jun 2006 08:11:54 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v750) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-39--778260816" Message-Id: <2F38EDB5-28C2-48BE-86A6-56D94D560EA5@NLnetLabs.nl> Cc: IETF DNSEXT WG , Mark Townsley , Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: nsid last call Date: Wed, 28 Jun 2006 08:11:54 +0200 To: Dean Anderson X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.750) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.5 (--) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-39--778260816 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear Dean, Thanks for you reply. I acknowledge receiving your concerns. I think that my last message explained the leading principle in determining the rough consensus and I stand by that consensus determination. --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-39--778260816 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFEoh2qtN/ca3YJIocRAmj9AJ9nO0RebgK2U7I9NgwnrkEJ0xnviACfW/Be 0QeUjoVkMLrwZFk5u0iVdO0= =IoP7 -----END PGP SIGNATURE----- --Apple-Mail-39--778260816-- -- to unsubscribe send a message to namedroppers-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 Jun 28 04:38:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvVZ5-0004fK-WD for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 04:38:28 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvVZ4-0004uX-NA for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 04:38:27 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvVVW-000Gxy-9P for namedroppers-data@psg.com; Wed, 28 Jun 2006 08:34:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.1.1 Received: from [195.177.253.212] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvVVU-000Gvv-EJ for namedroppers@ops.ietf.org; Wed, 28 Jun 2006 08:34:44 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id B32E8C2DFE; Wed, 28 Jun 2006 09:34:42 +0100 (BST) Date: Wed, 28 Jun 2006 09:34:23 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Dean Anderson , "Olaf M. Kolkman" Cc: IETF DNSEXT WG , Mark Townsley , iesg@ietf.org, Alex Bligh Subject: Re: nsid last call Message-ID: <88F7C61AC4C73416D883214B@[192.168.100.25]> In-Reply-To: References: X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 --On 27 June 2006 18:50 -0400 Dean Anderson wrote: > Alex Bligh agrees that the spoofing provision does not need to be in the > standard. But also doesn't see it necessary to remove. What I said (well what I meant to say) is that I do not think there should be a prohibition on opaque NSID (i.e. I am in favour of removing the prohibition), but I do not think the ability to use them needs to be expressly authorised in the standard (I'm not objecting to it doing so per se, I just think its otiose and I understand the argument that we shouldn't be seen to encourage 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 Wed Jun 28 09:54:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvaUf-0001Sf-3T for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 09:54:13 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvaUe-0001pa-GE for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 09:54:13 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvaQM-000KHU-NL for namedroppers-data@psg.com; Wed, 28 Jun 2006 13:49:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [62.221.254.24] (helo=pluto.isd-holland.nl) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvaQJ-000KH7-Ln for namedroppers@ops.ietf.org; Wed, 28 Jun 2006 13:49:44 +0000 Received: from [192.168.2.100] (62-221-195-234.dsl.uwadslprovider.nl [62.221.195.234]) by pluto.isd-holland.nl (Postfix) with ESMTP id B75652FC4DC for ; Wed, 28 Jun 2006 15:49:34 +0200 (CEST) Message-ID: <44A288E8.9060605@nlnetlabs.nl> Date: Wed, 28 Jun 2006 15:49:28 +0200 From: "dr. W.C.A. Wijngaards" User-Agent: Thunderbird 1.5.0.4 (X11/20060614) MIME-Version: 1.0 To: Namedroppers Subject: Trust anchor rollover review X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC96F7FBA88D70A60777D54C3" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC96F7FBA88D70A60777D54C3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, A couple of reviews of the trust rollover drafts I could find. Based on the summaries and comments below my support is to the draft-threshold (I value the query volume highly). The draft-timers comes second (negative is the query volume, key priming could be added separately just like the -threshold draft). These two drafts both satisfy the requirements. The technology for key rollover I like the most is the threshold and timer solutions. Threshold has (slightly, 2x) lower communication costs. More work should be done on message size (should keys be in their own domain names to keep 'em small), and on priming key technology (history playback mechanism to 'roll-forwards' the priming key or something). Rated to requirements in draft-ietf-dnsext-rollover-requirements-02: 5.1. Scalable. -timers yes, -threshold yes. -laurie less so. - DLV solution does not scale. 5.2. IPR (from ietf IPR pages). -takrem has IPR claims, statement about licensing has '.. economic value of the technology appears to lie with the trust anchor issuer role. ..'. License for GPLv2 but no other OSS lisences. -timers and -threshold, IPR claims that have a free use grant. -laurie has no IPR issues at all. 5.3. General Applicability. All do. 5.4. Support Private networks. All do. 5.5. Detection of stale trust anchors. -laurie does not. 5.6. Manual operations permitted. All do 5.7. Planned and unplanned rollovers. All do (research for key in -laurie= ). 5.8. Timeliness. -laurie does not include a timed refresh operation. 5.9. High Availability. All do. 5.10. new RR types. Revocation bit in DNSKEY flags for -timers. 5.11. Support maintenance by adding new anchors. All do. 5.12. Recovery from compromise. -laurie does not. - DLV cannot recover from a compromised dlv key. 5.13. Non-degrading trust. All can, -laurie has an issue with low trust links. draft-laurie-dnssec-key-distribution-02.txt ------------------------------------------- Summary: Using certificates. Everyone signs their keys using certificates. Cross-signing of others' keys. HTTP URLs (stored in cert) have collections of keys, signed by certificates. Hightrust and Lowtrust certificates. Resolver starts with trusted certs. Follows web of trust of cross signing, collect all certificates, extract all trusted keys. Comments: - 'in band mechanism' can be used to keep anchors up to date. Refers to key-rollover within a zone? - centers on trust web. Have to recurse all the trust web to find keys. - PRO: decentralised. - CON: scaling issues, with spidering the trust web. draft-ietf-dnsext-trustupdate-timers-02.txt ------------------------------------------- Summary: Keys sign keys for verification at zone apex of trust point. Timer to wait before add-key, or remove-key. Key compromise can be detected during the wait time. Resolver must detect if key stays in dnskey rrset for the entire duration of the wait time. Resolvers ask for dnskeys at trust points every so often to refresh keys. 'Revoke' bit in dnskey rrtype, sign it by that key and key is revok= ed. Comments: - KeyRem event, could that be due to truncation of a dns reply? If so, it should not have such harsh consequences. - very pretty revocation idea, where you need key private data to revoke. - CON queries for trust keys to refresh them, even if trust point is not in active use. - PRO key compromise handled carefully. draft-ietf-dnsext-trustupdate-threshold-01.txt ---------------------------------------------- Summary: Trustanchor keys have 'SEP' flag set. Want to avoid bogus data because keys are old, called stale keys. Keep a set of dnskeys and rrsigs by all keys at zone apex. At least M trust anchors must verify a new set of keys. The threshold from the title is M-N(number of keys). Keys are flagged as SEP, KSK, ZSK or Priming, no further state for keys. Nit: 3.4, paragraph starts with "If if". Comments: - PRO Handles key compromise - PRO Provides method to escape a stale-keys state to no-keys. - CON regular probes for new keys, less frequent than -timers, once per month. Need to give zone operator influence on this value. - PRO Discusses initial key priming. To bootstrap security. - CON priming keys idea is nice, but really moves all of the issues to the longer lived key. The technology for trust, revocation, parameters of that priming key is listed as external to the proposal. draft-moreau-dnsext-takrem-dns-02.txt ------------------------------------- Not reviewed. IPR claims on namedroppers. 'no derivative works' clause. --------------enigC96F7FBA88D70A60777D54C3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEoojtkDLqNwOhpPgRAtOYAJ9GfxobAvz8vSm2Y5Bsm398aGUVEQCfYE6J BhrbQJeEJdG7pLR4qIWEjNU= =xRQt -----END PGP SIGNATURE----- --------------enigC96F7FBA88D70A60777D54C3-- -- to unsubscribe send a message to namedroppers-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 Jun 28 11:21:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvbr0-0003PX-45 for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 11:21:22 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvbqy-0002qF-Qo for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 11:21:22 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvblG-00028w-FY for namedroppers-data@psg.com; Wed, 28 Jun 2006 15:15:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvblF-00028j-Uc for namedroppers@ops.ietf.org; Wed, 28 Jun 2006 15:15:25 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 83DE911426 for ; Wed, 28 Jun 2006 15:15:25 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Namedroppers WG Subject: Re: Recall: Key rollover Work. In-Reply-To: Your message of "Wed, 28 Jun 2006 07:44:18 +0200." <60E47F1C-F4B1-4DC2-B947-97262B39C746@NLnetLabs.nl> References: <6.2.5.6.2.20060612102822.03b52c00@ogud.com> <7.0.1.0.2.20060612174002.03d76008@nominum.com> <2805B0B0-CFA9-49E7-8ABD-4279673564D8@NLnetLabs.nl> <6.2.5.6.2.20060626105457.050ea9a8@nic.mx> <1C71D26A-A127-42B8-948B-F2808A3AC947@NLnetLabs.nl> <44A1DB2D.3050704@algroup.co.uk> <3827.1151471569@sa.vix.com> <60E47F1C-F4B1-4DC2-B947-97262B39C746@NLnetLabs.nl> X-Mailer: MH-E 7.93; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 28 Jun 2006 15:15:25 +0000 Message-ID: <92325.1151507725@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad > Paul, your proposal only made it to the mail list and never into a draft, > correct? it was presented, so there are slides and notes. i was not planning to write it up as a draft unless someone somewhere spoke for it. note: i'm not saying i want consensus before i write the draft, i just want someone, somewhere, to say it's an attractive approach that they'd like to see "in the running." at the moment, not even johani has said so, and he's the original author. -- to unsubscribe send a message to namedroppers-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 Jun 28 12:00:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvcSU-0005Uz-3L for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 12:00:06 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvcSS-0006w2-O8 for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 12:00:06 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvcQ2-0005oI-IE for namedroppers-data@psg.com; Wed, 28 Jun 2006 15:57:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.1 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvcPz-0005o0-Lx for namedroppers@ops.ietf.org; Wed, 28 Jun 2006 15:57:32 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k5SFuWle025793 for ; Wed, 28 Jun 2006 11:56:32 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAYVaGsY; Wed, 28 Jun 06 11:56:02 -0400 Received: from localhost (localhost [127.0.0.1]) by tislabs.com (8.12.9/8.12.9) with ESMTP id k5SFsWtV017421; Wed, 28 Jun 2006 11:54:36 -0400 (EDT) Date: Wed, 28 Jun 2006 11:55:08 -0400 (EDT) From: Sam Weiler X-X-Sender: weiler@lemon.samweiler.com To: "Olaf M. Kolkman" cc: Namedroppers Subject: Re: Recall: Key rollover Work. In-Reply-To: <90541EE9-12D8-4A67-8178-22A57D70879E@NLnetLabs.nl> Message-ID: References: <6.2.5.6.2.20060612102822.03b52c00@ogud.com> <7.0.1.0.2.20060612174002.03d76008@nominum.com> <2805B0B0-CFA9-49E7-8ABD-4279673564D8@NLnetLabs.nl> <6.2.5.6.2.20060626105457.050ea9a8@nic.mx> <1C71D26A-A127-42B8-948B-F2808A3AC947@NLnetLabs.nl> <90541EE9-12D8-4A67-8178-22A57D70879E@NLnetLabs.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 > Because I thought nobody put [DLV] on the table for solving > trust-anchor rollover (I may be wrong). Well... I think draft-weiler-dnssec-dlv-01.txt and draft-laurie-dnssec-key-distribution-02.txt are solving nearly the same problem. To the extent that one argues that one of the two is in (or out of) scope, I'd expect the same argument to be made about the other. > Wouldn't you agree that also with DLV you need to have a mechanism > to roll te DLV anchor? Arguably, yes. DLV does, however, solve the problem of rolling over other zones' keys. And once we've gotten to the point where we need to roll only one or a few trust anchors, the working group might reasonably decide the gain isn't worth the pain. In other words, while we might use similar technolgy for rollover of hundreds of trust anchors at each resolver as we do for rolling just one trust anchor, the motivation for developing that rollover technology might not be as strong if there's only one trust anchor to roll. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 28 12:04:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvcWU-0001Ko-21 for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 12:04:14 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvcWS-00076y-Pk for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 12:04:14 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvcTT-0006DR-Ik for namedroppers-data@psg.com; Wed, 28 Jun 2006 16:01:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvcTS-0006DB-Sx for namedroppers@ops.ietf.org; Wed, 28 Jun 2006 16:01:07 +0000 Received: from [10.31.32.59] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k5SG0Lgx042644; Wed, 28 Jun 2006 12:00:26 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 28 Jun 2006 12:00:43 -0400 To: Dean Anderson From: Edward Lewis Subject: Re: nsid last call Cc: "Olaf M. Kolkman" , IETF DNSEXT WG , Mark Townsley , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 At 18:50 -0400 6/27/06, Dean Anderson wrote: Corrention: >Strongly for spoofing: s/for/for allowing/ >Ed Lewis My assessment is that spoofing (as you are using the term) is neither an obstacle nor a requirement to achieve interoperability. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Soccer/Futbol. IPv6. Both have lots of 1's and 0's and have a hard time catching on in North America. That tournament in Germany. What's all the fuss? (Get it? "fuss?") -- to unsubscribe send a message to namedroppers-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 Jun 28 12:33:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvczB-0000Nz-9e for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 12:33:53 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvcnl-0008Ks-7d for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 12:22:06 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fvckp-00088I-Ph for namedroppers-data@psg.com; Wed, 28 Jun 2006 16:19:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fvckp-000884-6r for namedroppers@ops.ietf.org; Wed, 28 Jun 2006 16:19:03 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id C8FEA11425 for ; Wed, 28 Jun 2006 16:19:02 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Namedroppers Subject: Re: Recall: Key rollover Work. In-Reply-To: Your message of "Wed, 28 Jun 2006 11:55:08 -0400." References: <6.2.5.6.2.20060612102822.03b52c00@ogud.com> <7.0.1.0.2.20060612174002.03d76008@nominum.com> <2805B0B0-CFA9-49E7-8ABD-4279673564D8@NLnetLabs.nl> <6.2.5.6.2.20060626105457.050ea9a8@nic.mx> <1C71D26A-A127-42B8-948B-F2808A3AC947@NLnetLabs.nl> <90541EE9-12D8-4A67-8178-22A57D70879E@NLnetLabs.nl> X-Mailer: MH-E 7.93; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 28 Jun 2006 16:19:02 +0000 Message-ID: <2567.1151511542@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 > Arguably, yes. DLV does, however, solve the problem of rolling over other > zones' keys. And once we've gotten to the point where we need to roll only > one or a few trust anchors, the working group might reasonably decide the > gain isn't worth the pain. > > In other words, while we might use similar technolgy for rollover of > hundreds of trust anchors at each resolver as we do for rolling just one > trust anchor, the motivation for developing that rollover technology might > not be as strong if there's only one trust anchor to roll. i believe that the ability to roll trust anchors (which are stored outside of DNS) is a separate problem from rolling zone keys (which are stored inside the DNS and which are only sometimes, by policy or because it's the root zone, also trust anchors.) in other words, i do not see DLV as a potential resolution of the trust anchor issue. if we were willing to cut&paste the root zone's key (and by local policy, some other set of trust anchors) into every validator, then there would be no automated trust anchor project going on in this working group. -- to unsubscribe send a message to namedroppers-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 Jun 28 13:28:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvdpf-0001nW-Ir for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 13:28:07 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvdpe-0006xA-AE for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 13:28:07 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fvdmb-000DgK-83 for namedroppers-data@psg.com; Wed, 28 Jun 2006 17:24:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.1 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fvdma-000Dg2-1t for namedroppers@ops.ietf.org; Wed, 28 Jun 2006 17:24:56 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k5SHNvNe009786 for ; Wed, 28 Jun 2006 13:23:57 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAATJaiZs; Wed, 28 Jun 06 13:23:04 -0400 Received: from localhost (localhost [127.0.0.1]) by tislabs.com (8.12.9/8.12.9) with ESMTP id k5SFvdtV017545; Wed, 28 Jun 2006 11:57:40 -0400 (EDT) Date: Wed, 28 Jun 2006 11:58:15 -0400 (EDT) From: Sam Weiler X-X-Sender: weiler@lemon.samweiler.com To: Ben Laurie cc: Edward Lewis , Namedroppers Subject: Re: Recall: Key rollover Work. In-Reply-To: <44A1DBBE.8070401@algroup.co.uk> Message-ID: References: <6.2.5.6.2.20060612102822.03b52c00@ogud.com> <7.0.1.0.2.20060612174002.03d76008@nominum.com> <2805B0B0-CFA9-49E7-8ABD-4279673564D8@NLnetLabs.nl> <6.2.5.6.2.20060626105457.050ea9a8@nic.mx> <1C71D26A-A127-42B8-948B-F2808A3AC947@NLnetLabs.nl> <90541EE9-12D8-4A67-8178-22A57D70879E@NLnetLabs.nl> <44A1DBBE.8070401@algroup.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Ed Lewis writes: >> DLV is being touted as a "temporary, non-scaleable hack" to jump start And Ben Laurie writes: > That makes it not a candidate for trust anchor rollover, then, > surely, since that is a long range consideration. I caution against taking marketing claims about scaling as gospel, whether they're claims that something will scale or that it won't. Perhaps some data would be helpful. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 28 13:48:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fve9f-0002ls-5w for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 13:48:47 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fve9c-0001vh-Oa for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 13:48:47 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fve5O-000F8c-M4 for namedroppers-data@psg.com; Wed, 28 Jun 2006 17:44:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST,HTML_40_50,HTML_MESSAGE autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fve5N-000F8G-Ji for namedroppers@ops.ietf.org; Wed, 28 Jun 2006 17:44:22 +0000 Received: from [10.31.32.59] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k5SHh7Kx043739; Wed, 28 Jun 2006 13:43:07 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <6.2.5.6.2.20060612102822.03b52c00@ogud.com> <7.0.1.0.2.20060612174002.03d76008@nominum.com> <2805B0B0-CFA9-49E7-8ABD-4279673564D8@NLnetLabs.nl> <6.2.5.6.2.20060626105457.050ea9a8@nic.mx> <1C71D26A-A127-42B8-948B-F2808A3AC947@NLnetLabs.nl> <90541EE9-12D8-4A67-8178-22A57D70879E@NLnetLabs.nl> <44A1DBBE.8070401@algroup.co.uk> Date: Wed, 28 Jun 2006 13:43:27 -0400 To: Sam Weiler From: Edward Lewis Subject: Re: Recall: Key rollover Work. Cc: Ben Laurie , Edward Lewis , Namedroppers Content-Type: multipart/alternative; boundary="============_-1060605879==_ma============" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 --============_-1060605879==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 11:58 -0400 6/28/06, Sam Weiler wrote: >I caution against taking marketing claims about scaling as gospel, whether >they're claims that something will scale or that it won't. Perhaps some data >would be helpful. "Being touted as" ... means I am quoting non-specific statements made over time about DLV. But here are two mentions of DLV and scaling, followed by my assessment. Citation 1: http://www.merit.net/mail.archives/nanog/msg00608.html #can you say "does not scale?" or how about "works poorly when a #zone is transferred?" # #i think there is no question that you and isc mean well. but we've #entered the the twisty passages of security. # #randy Citation 2: http://www.dnssec-deployment.org/dnssec20040630.txt #DLV - Paul Vixie # ... # #2. DLV is deliberately simple and, in fact, "crippled" in that it is not # intended to be scalable or to survive for a long period of time." Is that the data you want? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Soccer/Futbol. IPv6. Both have lots of 1's and 0's and have a hard time catching on in North America. That tournament in Germany. What's all the fuss? (Get it? "fuss?") --============_-1060605879==_ma============ Content-Type: text/html; charset="us-ascii" Re: Recall: Key rollover Work.
At 11:58 -0400 6/28/06, Sam Weiler wrote:

>I caution against taking marketing claims about scaling as gospel, whether
>they're claims that something will scale or that it won't. Perhaps some data
>would be helpful.

"Being touted as" ... means I am quoting non-specific statements made over time about DLV.  But here are two mentions of DLV and scaling, followed by my assessment.

Citation 1: http://www.merit.net/mail.archives/nanog/msg00608.html

#can you say "does not scale?"  or how about "works poorly when a
#zone is transferred?"
#
#i think there is no question that you and isc mean well.  but we've
#entered the the twisty passages of security.
#
#randy

Citation 2: http://www.dnssec-deployment.org/dnssec20040630.txt

#DLV - Paul Vixie
#
...
#
#2. DLV is deliberately simple and, in fact, "crippled" in that it is not
#  intended to be scalable or to survive for a long period of time."

Is that the data you want?
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Soccer/Futbol. IPv6.  Both have lots of 1's and 0's and have a hard time
catching on in North America.

That tournament in Germany.  What's all the fuss?  (Get it? "fuss?")
--============_-1060605879==_ma============-- -- to unsubscribe send a message to namedroppers-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 Jun 28 14:06:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FveQq-0003mr-WC for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 14:06:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FveQp-0002r2-Kn for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 14:06:32 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FveNZ-000GXF-JW for namedroppers-data@psg.com; Wed, 28 Jun 2006 18:03:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FveNY-000GX2-OV for namedroppers@ops.ietf.org; Wed, 28 Jun 2006 18:03:08 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 5713111425 for ; Wed, 28 Jun 2006 18:03:08 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Namedroppers Subject: Re: Recall: Key rollover Work. In-Reply-To: Your message of "Wed, 28 Jun 2006 13:43:27 -0400." References: <6.2.5.6.2.20060612102822.03b52c00@ogud.com> <7.0.1.0.2.20060612174002.03d76008@nominum.com> <2805B0B0-CFA9-49E7-8ABD-4279673564D8@NLnetLabs.nl> <6.2.5.6.2.20060626105457.050ea9a8@nic.mx> <1C71D26A-A127-42B8-948B-F2808A3AC947@NLnetLabs.nl> <90541EE9-12D8-4A67-8178-22A57D70879E@NLnetLabs.nl> <44A1DBBE.8070401@algroup.co.uk> X-Mailer: MH-E 7.93; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 28 Jun 2006 18:03:08 +0000 Message-ID: <14942.1151517788@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 > Citation 2: http://www.dnssec-deployment.org/dnssec20040630.txt > > #DLV - Paul Vixie > # > ... > # > #2. DLV is deliberately simple and, in fact, "crippled" in that it is not > # intended to be scalable or to survive for a long period of time." > > Is that the data you want? the dlv draft by sweiler may not be the same thing we implemented in BIND9 and wrote up in . sweiler may be claiming that the dlv in the draft he authored would scale perfectly well. i will not counter-argue, except to say, isc-tn-2006-1 describes a dlv that is deliberately crippled, and that this deliberateness came about partly from our desire not to create a permanent protocol+mechanism through nonconsensus methods (that of writing it up as an ISC technote rather than an IETF i-d, and of implementing it in BIND9 as a local-policy exception rather than as part of an internet standard.) if sweiler has a dlv that's not deliberately crippled, and if the WG wants to consider a permanent mechanism (not just an early deployment aid) that is therefore not-deliberately-crippled, then that's a topic worthy of coverage here. but it has nothing to do with my contention that dlv is about zone key distribution outside of the DS chain, and is therefore a different topic from automated trust key rollover. no amount of dlv, in or out of the standards process, crippled or not, obviates the present need of validator operators to cut and paste trust anchors like root keys (or dlv keys). the reason i'm so keen to point out this difference is that when i "riffed" on johani's key rollover proposal, i considered it unrelated to the need for (and the use of) dlv. if we have automated trust key rollover, we will most likely use it to roll the DLV trust anchor while we wait for the root zone to have a key we can roll instead. -- to unsubscribe send a message to namedroppers-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 Jun 28 14:34:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvero-0000lP-OH for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 14:34:24 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvern-0004R8-Fh for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 14:34:24 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvemB-000IVv-SQ for namedroppers-data@psg.com; Wed, 28 Jun 2006 18:28:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvemB-000IVW-Cl for namedroppers@ops.ietf.org; Wed, 28 Jun 2006 18:28:35 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id EBD0A11425 for ; Wed, 28 Jun 2006 18:28:34 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Your version of M-of-N (was Re: Recall: Key rollover Work.) X-Mailer: MH-E 7.93; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 28 Jun 2006 18:28:34 +0000 Message-ID: <18009.1151519314@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 someone quoted me just now... > > the reason i'm so keen to point out this difference is that when i > > "riffed" on johani's key rollover proposal, [...] and wrote to me, privately: > I've seen your earlier comments about their being slides about this, > but could you please provide a pointer? I'd like to understand how > your proposal (proto-proposal?) differs from the M-of-N draft, since I > don't recall the details (if I ever knew them). i've chosen to answer publically: slides are at . meeting notes are at . -- to unsubscribe send a message to namedroppers-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 Jun 28 14:41:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FveyS-0002nM-MG for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 14:41:16 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FveyR-0006SC-CS for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 14:41:16 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvewG-000JHh-EF for namedroppers-data@psg.com; Wed, 28 Jun 2006 18:39:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,INFO_TLD autolearn=no version=3.1.1 Received: from [207.219.45.62] (helo=mail.libertyrms.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvewF-000JHM-Su for namedroppers@ops.ietf.org; Wed, 28 Jun 2006 18:38:59 +0000 Received: from [10.1.3.231] (helo=roaming1.int.libertyrms.com) by mail.libertyrms.com with esmtp (Exim 4.22) id 1FvewF-00007u-0y for namedroppers@ops.ietf.org; Wed, 28 Jun 2006 14:38:59 -0400 Received: by roaming1.int.libertyrms.com (Postfix, from userid 1019) id 56CB31BE603; Wed, 28 Jun 2006 14:38:50 -0400 (EDT) Date: Wed, 28 Jun 2006 14:38:50 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: nsid last call Message-ID: <20060628183850.GE24929@afilias.info> Reply-To: Andrew Sullivan References: <1D1A0F32-0343-4AD0-947C-0ED26ECAFAC2@NLnetLabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 X-SA-Exim-Mail-From: andrew@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 On Tue, Jun 27, 2006 at 06:50:49PM -0400, Dean Anderson wrote: > Strongly for spoofing: [. . .] > Andrew Sullivan To be clear, I am not "for spoofing". I think I've said enough on the topic, however, so I won't re-hash my arguments here. A -- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 jabber: ajsaf@jabber.org +1 416 646 3304 x4110 -- to unsubscribe send a message to namedroppers-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 Jun 28 15:07:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvfOE-00048P-GU for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 15:07:54 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvfOD-0000p8-6u for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 15:07:54 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvfLs-000LF7-Cb for namedroppers-data@psg.com; Wed, 28 Jun 2006 19:05:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_ZOMBIE autolearn=no version=3.1.1 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvfLr-000LEq-HK for namedroppers@ops.ietf.org; Wed, 28 Jun 2006 19:05:27 +0000 Received: from [130.105.12.10] ([130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id k5SJ3gv8023534 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 28 Jun 2006 15:04:07 -0400 Date: Wed, 28 Jun 2006 15:03:35 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Alex Bligh cc: "Olaf M. Kolkman" , IETF DNSEXT WG , Mark Townsley , Subject: Re: nsid last call In-Reply-To: <88F7C61AC4C73416D883214B@[192.168.100.25]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.8 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Well said. Word of the Day for Monday December 8, 2003 otiose \OH-shee-ohs; OH-tee-\, adjective: 1. Ineffective; futile. 2. Being at leisure; lazy; indolent; idle. 3. Of no use. --Dean On Wed, 28 Jun 2006, Alex Bligh wrote: > > > --On 27 June 2006 18:50 -0400 Dean Anderson wrote: > > > Alex Bligh agrees that the spoofing provision does not need to be in the > > standard. But also doesn't see it necessary to remove. > > What I said (well what I meant to say) is that I do not think there > should be a prohibition on opaque NSID (i.e. I am in favour of removing > the prohibition), but I do not think the ability to use them needs to > be expressly authorised in the standard (I'm not objecting to it > doing so per se, I just think its otiose and I understand the argument > that we shouldn't be seen to encourage it). > > Alex > > -- 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 Wed Jun 28 17:10:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvhJJ-0006DW-NN for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 17:10:57 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvhJI-00079n-9W for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 17:10:57 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvhFP-0006X0-Ay for namedroppers-data@psg.com; Wed, 28 Jun 2006 21:06:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvhFO-0006Wn-L3 for namedroppers@ops.ietf.org; Wed, 28 Jun 2006 21:06:54 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 3743D11425 for ; Wed, 28 Jun 2006 21:06:54 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Namedroppers Subject: Re: Recall: Key rollover Work. In-Reply-To: Your message of "Wed, 28 Jun 2006 16:43:32 -0400." References: <6.2.5.6.2.20060612102822.03b52c00@ogud.com> <7.0.1.0.2.20060612174002.03d76008@nominum.com> <2805B0B0-CFA9-49E7-8ABD-4279673564D8@NLnetLabs.nl> <6.2.5.6.2.20060626105457.050ea9a8@nic.mx> <1C71D26A-A127-42B8-948B-F2808A3AC947@NLnetLabs.nl> <90541EE9-12D8-4A67-8178-22A57D70879E@NLnetLabs.nl> <44A1DBBE.8070401@algroup.co.uk> X-Mailer: MH-E 7.93; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 28 Jun 2006 21:06:54 +0000 Message-ID: <38636.1151528814@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab > > Is that the data you want? > > Not at all. I'm looking for data (numbers, examples, case studies) > supporting the claim that DLV doesn't scale. I've heard Paul's > marketing-speak, and I'm skeptical of it. since i don't know how to prove a negative, i can only say that dlv as currently implemented in bind9 (which may or may not be compatible with dlv as described in sweiler's internet draft) is not intended to scale. the specific place where i expect it to blow chunks is in the number of unsuppressable queries in a dense dlv namespace. no simulations have been done, and the modelling in sweiler's original thesis(*) on dlv makes slightly different assumptions than those implemented today in bind9. (*) S. Weiler, "Deploying DNSSEC Without a Signed Root", Technical report 1999-19, Information Networking Institute, Carnegie Mellon University, April 2004. -- to unsubscribe send a message to namedroppers-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 Jun 28 17:37:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvhip-00058P-TG for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 17:37:19 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvhF8-0006yz-TE for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 17:06:38 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fvh0K-0005v4-CC for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 16:51:28 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvgwC-0004dV-D2 for namedroppers-data@psg.com; Wed, 28 Jun 2006 20:47:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.1 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fvgw9-0004dB-Dv for namedroppers@ops.ietf.org; Wed, 28 Jun 2006 20:47:02 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k5SKk23b005828 for ; Wed, 28 Jun 2006 16:46:02 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAydaOil; Wed, 28 Jun 06 16:45:02 -0400 Received: from localhost (localhost [127.0.0.1]) by tislabs.com (8.12.9/8.12.9) with ESMTP id k5SKgwtV028974; Wed, 28 Jun 2006 16:43:05 -0400 (EDT) Date: Wed, 28 Jun 2006 16:43:32 -0400 (EDT) From: Sam Weiler X-X-Sender: weiler@lemon.samweiler.com To: Edward Lewis cc: Namedroppers Subject: Re: Recall: Key rollover Work. In-Reply-To: Message-ID: References: <6.2.5.6.2.20060612102822.03b52c00@ogud.com> <7.0.1.0.2.20060612174002.03d76008@nominum.com> <2805B0B0-CFA9-49E7-8ABD-4279673564D8@NLnetLabs.nl> <6.2.5.6.2.20060626105457.050ea9a8@nic.mx> <1C71D26A-A127-42B8-948B-F2808A3AC947@NLnetLabs.nl> <90541EE9-12D8-4A67-8178-22A57D70879E@NLnetLabs.nl> <44A1DBBE.8070401@algroup.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab On Wed, 28 Jun 2006, Edward Lewis wrote: >> I caution against taking marketing claims about scaling as gospel, >> whether they're claims that something will scale or that it won't. >> Perhaps some data would be helpful. > > "Being touted as" ... means I am quoting non-specific statements > made over time about DLV. But here are two mentions of DLV and > scaling, followed by my assessment. ... > Is that the data you want? Not at all. I'm looking for data (numbers, examples, case studies) supporting the claim that DLV doesn't scale. I've heard Paul's marketing-speak, and I'm skeptical of it. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 28 18:03:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvi72-0000Wc-PZ for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 18:02:20 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvi2O-0003U5-SM for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 17:57:34 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvhzV-000ABJ-RJ for namedroppers-data@psg.com; Wed, 28 Jun 2006 21:54:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,INFO_TLD, RCVD_IN_SORBS_ZOMBIE autolearn=no version=3.1.1 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvhzU-000AB4-Ik for namedroppers@ops.ietf.org; Wed, 28 Jun 2006 21:54:32 +0000 Received: from [130.105.12.10] ([130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id k5SLsRb9023639 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 28 Jun 2006 17:54:27 -0400 Date: Wed, 28 Jun 2006 17:54:26 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: "Olaf M. Kolkman" cc: namedroppers@ops.ietf.org, Subject: Re: nsid last call (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.3 (+) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Can we have a post WGLC draft with the following changes: Use this wording: 3.1. The NSID Payload The syntax and semantics of the content of the NSID option is deliberately left outside the scope of this specification. It is the prerogative of the server administrator to choose the NSID content as long as the content is unique to each anycast instance so that a remote user is able to match the NSID to the server instance over a series of queries. The NSID can be opaque and encoded such that it can be decoded by the server adminstrator to provide more information. This section describe some of the kinds of data that server administrators might choose to provide as the content of the NSID option, and explains the reasoning behind choosing a simple opaque byte string. Delete this from Section 3.1: o It could be some sort of dynamicly generated identifier so that only the name server operator could tell whether or not any two queries had been answered by the same server. -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ---------- Forwarded message ---------- Date: Wed, 28 Jun 2006 14:38:50 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: nsid last call On Tue, Jun 27, 2006 at 06:50:49PM -0400, Dean Anderson wrote: > Strongly for spoofing: [. . .] > Andrew Sullivan To be clear, I am not "for spoofing". I think I've said enough on the topic, however, so I won't re-hash my arguments here. A -- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 jabber: ajsaf@jabber.org +1 416 646 3304 x4110 -- to 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 Jun 28 18:16:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FviKS-0001Kd-FB for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 18:16:12 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FviKP-0004AU-5o for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 18:16:12 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FviHP-000Bf1-Sx for namedroppers-data@psg.com; Wed, 28 Jun 2006 22:13:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.1 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FviHN-000BeF-Ty for namedroppers@ops.ietf.org; Wed, 28 Jun 2006 22:13:02 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k5SMC3rW015149 for ; Wed, 28 Jun 2006 18:12:03 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAu_aGLD; Wed, 28 Jun 06 18:12:00 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by tislabs.com (8.12.9/8.12.9) with ESMTP id k5SMAetU001703; Wed, 28 Jun 2006 18:10:40 -0400 (EDT) In-Reply-To: <1C71D26A-A127-42B8-948B-F2808A3AC947@NLnetLabs.nl> References: <6.2.5.6.2.20060612102822.03b52c00@ogud.com> <7.0.1.0.2.20060612174002.03d76008@nominum.com> <2805B0B0-CFA9-49E7-8ABD-4279673564D8@NLnetLabs.nl> <6.2.5.6.2.20060626105457.050ea9a8@nic.mx> <1C71D26A-A127-42B8-948B-F2808A3AC947@NLnetLabs.nl> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Cc: Namedroppers Content-Transfer-Encoding: quoted-printable From: Suresh Krishnaswamy Subject: Re: Recall: Key rollover Work. Date: Wed, 28 Jun 2006 18:12:51 -0400 To: "Olaf M. Kolkman" X-Mailer: Apple Mail (2.750) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 On Jun 27, 2006, at 3:52 AM, Olaf M. Kolkman wrote: > > Note that Alberto Mart=EDnez Herrera's comparison is still available = at: > http://docs.nicmxlabs.org.mx/itesm/dnsseckeyrolloverproposals.pdf > > I recall there is a second comparison but I cannot find it. The table at http://www.dnssec-tools.org/docs/trust-anchor-comparison-=20= v02.htm may also be useful. Suresh (on behalf of myself) -- to unsubscribe send a message to namedroppers-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 Jun 28 18:52:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvitq-0001a8-0K for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 18:52:47 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvitp-000173-D7 for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 18:52:45 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvirK-000EV0-QV for namedroppers-data@psg.com; Wed, 28 Jun 2006 22:50:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [209.173.53.70] (helo=oak.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvirJ-000EUT-TX for namedroppers@ops.ietf.org; Wed, 28 Jun 2006 22:50:10 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k5SMo21u006596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Jun 2006 22:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FvirC-0004nY-5u; Wed, 28 Jun 2006 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-bis-updates-03.txt Message-Id: Date: Wed, 28 Jun 2006 18:50:02 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a --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 : Clarifications and Implementation Notes for DNSSECbis Author(s) : R. Austein, S. Weiler Filename : draft-ietf-dnsext-dnssec-bis-updates-03.txt Pages : 12 Date : 2006-6-28 This document is a collection of minor technical clarifications to the DNSSECbis document set. It is meant to serve as a resource to implementors as well as an interim repository of DNSSECbis errata. An index sorted by the section of DNSSECbis being clarified. A list of proposed protocol changes being made in other documents, such as [RFC4470] and [I-D.ietf-dnsext-nsec3]. This document would not make those changes, merely provide an index into the documents that are making changes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-bis-updates-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-bis-updates-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-bis-updates-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-28164816.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-bis-updates-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-bis-updates-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-28164816.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 Jun 28 19:36:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvjad-00027Y-L9 for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 19:36:59 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvjac-0006hb-11 for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 19:36:59 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvjX9-000HmZ-32 for namedroppers-data@psg.com; Wed, 28 Jun 2006 23:33:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [200.23.30.77] (helo=mail.nic.mx) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvjX6-000HmG-Bf for namedroppers@ops.ietf.org; Wed, 28 Jun 2006 23:33:20 +0000 Received: from localhost (localhost.nic.mx [127.0.0.1]) by mail.nic.mx (Postfix) with ESMTP id 8A9B4183C39 for ; Wed, 28 Jun 2006 18:33:19 -0500 (CDT) Received: from mail.nic.mx ([127.0.0.1]) by localhost (mail.nic.mx [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53117-07 for ; Wed, 28 Jun 2006 18:33:19 -0500 (CDT) Received: from GLOZANO.nic.mx (unknown [200.33.1.76]) by mail.nic.mx (Postfix) with ESMTP id 5D0D9183C35 for ; Wed, 28 Jun 2006 18:33:19 -0500 (CDT) Message-Id: <6.2.5.6.2.20060628182608.04874800@nic.mx> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 28 Jun 2006 18:33:18 -0500 To: Namedroppers From: Gustavo Lozano Subject: Is keyrollover neccesary? (was Key rollover Work.) In-Reply-To: <2567.1151511542@sa.vix.com> References: <6.2.5.6.2.20060612102822.03b52c00@ogud.com> <7.0.1.0.2.20060612174002.03d76008@nominum.com> <2805B0B0-CFA9-49E7-8ABD-4279673564D8@NLnetLabs.nl> <6.2.5.6.2.20060626105457.050ea9a8@nic.mx> <1C71D26A-A127-42B8-948B-F2808A3AC947@NLnetLabs.nl> <90541EE9-12D8-4A67-8178-22A57D70879E@NLnetLabs.nl> <2567.1151511542@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new at nic.mx Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c At 04:19 PM 6/28/2006 +0000, Paul Vixie wrote: >if we were willing to cut&paste the root zone's key (and by local >policy, some other set of trust anchors) into every validator, then there >would be no automated trust anchor project going on in this working group. Statements: I don't want to start a flame war. I am committed to review the keyrollover proposals and participate with my two cents. I gave a DNSSEC workshop to a carrier in Mexico months ago. When I mentioned the keyrollover work being done in the IETF they asked me if automatic trust anchor keyrollover is really necessary to deploy DNSSECbis and this question has been in my head since. Since the first time I read about DNSSECbis it became clear the usefulness of having a signed root. I know about the trouble of signing the root, but when the root is finally signed I expect that RSA is broken first before the root zone key is compromised. I expect that the entity chosen for root signing implements the same operational security that Verising uses to guard its root CA private key. If the root is signed and a root key compromise happens, it's going to be "big news" (think of CNN alert news) and people will update. If the root is never signed, IANA can have a list of the trusted anchor currently used by each TLD and we know that communication between IANA and the TLDs is already authenticated. You can think of a lot of operational procedures to propagate this information from IANA to end users: windows update, RHN, cvsup, https GET by the DNS implementation, etc. The trick is that if you don't update your TA in your validator then your client's DNS request will fail and someone is going to scream and you will have to fix it. I expect that TLDs will implement a security infrastructure (here at NIC Mexico cctld .mx we are thinking about FIPS 140-2 level 3 HSMs for example) to protect the key so I think that a key rollover should be an isolated event. Is DNSSECbis deployable without an automatic trust anchor keyrollover feature? Maybe what we need is a key management security guideline in the spirit of RFC3647 or we can add more operational security best practices to the existent dnssec operational practices? Maybe we are trying to make a perfect protocol and we just need a pretty good protocol? Thank you for your comments. Gustavo Lozano NIC Mexico -- to unsubscribe send a message to namedroppers-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 Jun 28 21:30:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvlMG-00085X-67 for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 21:30:16 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvlMF-0002rb-Lr for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 21:30:16 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvlGF-000Pi6-Eb for namedroppers-data@psg.com; Thu, 29 Jun 2006 01:24:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvlGE-000Phr-DM for namedroppers@ops.ietf.org; Thu, 29 Jun 2006 01:24:02 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id E945C11426 for ; Thu, 29 Jun 2006 01:23:59 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Namedroppers Subject: Re: Is keyrollover neccesary? (was Key rollover Work.) In-Reply-To: Your message of "Wed, 28 Jun 2006 18:33:18 EST." <6.2.5.6.2.20060628182608.04874800@nic.mx> References: <6.2.5.6.2.20060612102822.03b52c00@ogud.com> <7.0.1.0.2.20060612174002.03d76008@nominum.com> <2805B0B0-CFA9-49E7-8ABD-4279673564D8@NLnetLabs.nl> <6.2.5.6.2.20060626105457.050ea9a8@nic.mx> <1C71D26A-A127-42B8-948B-F2808A3AC947@NLnetLabs.nl> <90541EE9-12D8-4A67-8178-22A57D70879E@NLnetLabs.nl> <2567.1151511542@sa.vix.com> <6.2.5.6.2.20060628182608.04874800@nic.mx> X-Mailer: MH-E 7.93; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 29 Jun 2006 01:23:59 +0000 Message-ID: <67729.1151544239@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 > ... they asked me if automatic trust anchor keyrollover is really necessary > to deploy DNSSECbis and this question has been in my head since. > > Since the first time I read about DNSSECbis it became clear the usefulness > of having a signed root. I know about the trouble of signing the root, but > when the root is finally signed I expect that RSA is broken first before > the root zone key is compromised. i agree. and yet there are two pressures here. if RSA is somehow broken as quickly as MD5 was broken (in terms of total years of service per key-size), then we'll be rolling over to a new crypto alg before the validator population is large enough that an alg-roll is painful. on the other hand if RSA lasts another ten or fifteen years, the validator population could be very large and many parts of that population will have lost touch with human hands. in the former (and expected) case, validator software will have to be upgraded. in the latter (very possible) case, automation for trust anchor rollover will be the only way that Secure DNS could survive. > ... If the root is signed and a root key compromise happens, it's going to > be "big news" (think of CNN alert news) and people will update. i disagree. people will not update. people do not update their Windows and Macintosh systems, even when the wall street journal and every metropolitan newspaper in the world (plus CNN Nightly News) warns them of the acute need to do so. this problem -- not updating -- is at the heart of why ISP's have no rational course of action when notified of a "botnet" in their customer network. this problem is pervasive, and won't be solved by TCPA or any other initiative announced so far. Secure DNS should not depend on a solution to the well known "not updating" problem. it's possible that one could take the view that validator operators are more technically "savvy" than Windows/Mac users, and will behave more responsibly or with some degree of "rational self interest". this has never been proved or even shown to be likely. i note that root name server addresses which were decommissioned as much as ten years ago still receive hundreds or even thousands of queries per second. updates which involve human action toward static configuration are as unreliable as updates which involve human action toward software revision levels. in other words, not reliable at all. > If the root is never signed, IANA can have a list of the trusted anchor > currently used by each TLD and we know that communication between IANA and > the TLDs is already authenticated. no, it is not. there's been a string of high-profile TLD hijackings by local governments or competing commercial entities over the years. IANA's records have not always been complete and/or authoritative. > You can think of a lot of operational procedures to propagate this > information from IANA to end users: windows update, RHN, cvsup, https GET by > the DNS implementation, etc. The trick is that if you don't update your TA > in your validator then your client's DNS request will fail and someone is > going to scream and you will have to fix it. possibly. but it is equally possible that the lack of automation in key rollover will signal to application developers that Secure DNS is too fragile to be depended upon. and also equally possible that some or many failures due to non-rollover will be undiagnosed or misdiagnosed, causing users and developers to abandon Secure DNS at the first sign of serious instability. > Is DNSSECbis deployable without an automatic trust anchor keyrollover > feature? Maybe what we need is a key management security guideline in the > spirit of RFC3647 or we can add more operational security best practices to > the existent dnssec operational practices? Maybe we are trying to make a > perfect protocol and we just need a pretty good protocol? with an expected population of Secure DNS validators on the order of millions, i assert that the first forced root-key rollover without automation would mean the end of Secure DNS as it then exists. others here have further argued that the "rollover machinery" must be in constant use to ensure its availability and functionality, and that therefore, root key lifetimes should be only a few weeks or at most months in length. (i find those arguments credible, fwiw.) -- to unsubscribe send a message to namedroppers-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 Jun 28 22:05:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvluH-0006Ht-TP for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 22:05:25 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvluE-000772-OD for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 22:05:25 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvlqR-0002SS-23 for namedroppers-data@psg.com; Thu, 29 Jun 2006 02:01:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [216.127.148.226] (helo=mail6.sea.safepages.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvlqP-0002SB-KR for namedroppers@ops.ietf.org; Thu, 29 Jun 2006 02:01:25 +0000 Received: by mail6.sea.safepages.com (Postfix, from userid 1012) id 87EDAEBAF3; Thu, 29 Jun 2006 02:01:24 +0000 (GMT) Received: from connotech.com (unknown [165.154.49.32]) by mail6.sea.safepages.com (Postfix) with ESMTP id 9AF17EBAE8; Thu, 29 Jun 2006 02:01:22 +0000 (GMT) Message-ID: <44A334C4.9060002@connotech.com> Date: Wed, 28 Jun 2006 22:02:44 -0400 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gustavo Lozano Cc: Namedroppers Subject: Re: Is keyrollover neccesary? (was Key rollover Work.) References: <6.2.5.6.2.20060612102822.03b52c00@ogud.com> <7.0.1.0.2.20060612174002.03d76008@nominum.com> <2805B0B0-CFA9-49E7-8ABD-4279673564D8@NLnetLabs.nl> <6.2.5.6.2.20060626105457.050ea9a8@nic.mx> <1C71D26A-A127-42B8-948B-F2808A3AC947@NLnetLabs.nl> <90541EE9-12D8-4A67-8178-22A57D70879E@NLnetLabs.nl> <2567.1151511542@sa.vix.com> <6.2.5.6.2.20060628182608.04874800@nic.mx> In-Reply-To: <6.2.5.6.2.20060628182608.04874800@nic.mx> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Gustavo Lozano wrote: > Is DNSSECbis deployable without an automatic trust anchor keyrollover > feature? For the record, here are the rationales for rolling keys in the first place: o cryptographic strength concerns, i.e. an old key might be cracked, o security operations concerns, i.e. over time, the uninterrupted confidentiality a production private key becomes less trustworthy, o survivability concerns to the extent that a scheduled renewal operation is like a rehearsal for an emergency private key recovery, or an alternative for it (e.g. if the private key breach has no practical impact or it is merely suspected). (from draft-moreau-dnsext-tak-req-00) Actually this does not answer your question, someone has to weight the seriousness of these concerns against the effectiveness and burden/cost of TAK rollover solution at hand. I whished the question would have been addressed seriously by now in DNSEXT. -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 28 23:17:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvn2A-0004eP-Sh for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 23:17:38 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvn27-0005Ut-Hq for dnsext-archive@lists.ietf.org; Wed, 28 Jun 2006 23:17:38 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fvmx0-0007hj-Ty for namedroppers-data@psg.com; Thu, 29 Jun 2006 03:12:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fvmx0-0007hT-4E for namedroppers@ops.ietf.org; Thu, 29 Jun 2006 03:12:18 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k5T3BwUF048793; Wed, 28 Jun 2006 23:11:59 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 28 Jun 2006 23:11:37 -0400 To: Dean Anderson From: Edward Lewis Subject: Re: nsid last call (fwd) Cc: "Olaf M. Kolkman" , namedroppers@ops.ietf.org, Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 At 17:54 -0400 6/28/06, Dean Anderson wrote: >Can we have a post WGLC draft with the following changes: > >Use this wording: > > 3.1. The NSID Payload > > The syntax and semantics of the content of the NSID option is > deliberately left outside the scope of this specification. It is > the prerogative of the server administrator to choose the NSID > content as long as the content is unique to each anycast instance > so that a remote user is able to match the NSID to the server > instance over a series of queries. The NSID can be opaque and > encoded such that it can be decoded by the server adminstrator to > provide more information. This section describe some of the kinds > of data that server administrators might choose to provide as the > content of the NSID option, and explains the reasoning behind > choosing a simple opaque byte string. 1) How does a requirement for uniqueness improve interoperability? 2) How do you enforce this, i.e., how can you detect the difference between one instance relying with 2 different strings and two instances replying with one string each? The requirement for uniqueness is not related to interoperability and is not testable. For those reasons, I think it would be dropped. > >Delete this from Section 3.1: > > o It could be some sort of dynamicly generated identifier so that > only the name server operator could tell whether or not any two > queries had been answered by the same server. IMHO, I don't care about dropping this because I don't think the draft really ought to even bother suggesting particular semantics of the opaque string. I say that from seeing past RFCs that got in hot water for being "too helpful." -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Soccer/Futbol. IPv6. Both have lots of 1's and 0's and have a hard time catching on in North America. That tournament in Germany. What's all the fuss? (Get it? "fuss?") -- to unsubscribe send a message to namedroppers-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 Jun 29 03:54:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvrM9-00016P-BW for dnsext-archive@lists.ietf.org; Thu, 29 Jun 2006 03:54:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvrM4-0003Ed-Ri for dnsext-archive@lists.ietf.org; Thu, 29 Jun 2006 03:54:33 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvrH0-0002y1-IR for namedroppers-data@psg.com; Thu, 29 Jun 2006 07:49:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvrGx-0002xM-2z for namedroppers@ops.ietf.org; Thu, 29 Jun 2006 07:49:11 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1:211:2fff:fed7:7378]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k5T7n3qs043370; Thu, 29 Jun 2006 09:49:03 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-2--686032852" Message-Id: Cc: IETF DNSEXT WG , Mark Townsley Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: nsid last call (fwd) Date: Thu, 29 Jun 2006 09:49:02 +0200 To: Dean Anderson X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-2--686032852 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Jun 28, 2006, at 11:54 PM, Dean Anderson wrote: > Can we have a post WGLC draft with the following changes: Hello Dean, I'm sorry to say, we can not have a post WGLC. Since I determined consensus the work has moved out of the working group and is now in the hands of the IESG. I consider this issue closed. Kind regards, --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-2--686032852 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFEo4XutN/ca3YJIocRAuL4AKCjrzRnx2bxbZ42zDqysaIN2PutuwCfSncI wxZqwEG49X/XBCPF4vghJT8= =Jfvi -----END PGP SIGNATURE----- --Apple-Mail-2--686032852-- -- to unsubscribe send a message to namedroppers-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 Jun 29 08:25:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvvZz-0003fd-4R for dnsext-archive@lists.ietf.org; Thu, 29 Jun 2006 08:25:07 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvtv2-0004nn-Qn for dnsext-archive@lists.ietf.org; Thu, 29 Jun 2006 06:38:44 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fvtgn-0000vg-2p for dnsext-archive@lists.ietf.org; Thu, 29 Jun 2006 06:24:06 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvtdX-000GSG-6V for namedroppers-data@psg.com; Thu, 29 Jun 2006 10:20:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvtdU-000GRS-5u for namedroppers@ops.ietf.org; Thu, 29 Jun 2006 10:20:36 +0000 Received: from [213.154.224.38] (diva.nlnetlabs.nl [213.154.224.38]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k5TAKXwW075236; Thu, 29 Jun 2006 12:20:33 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <44A3A971.902@nlnetlabs.nl> Date: Thu, 29 Jun 2006 12:20:33 +0200 From: Wouter Wijngaards User-Agent: Thunderbird 1.5.0.4 (X11/20060614) MIME-Version: 1.0 To: Namedroppers CC: Paul Vixie Subject: Re: Recall: Key rollover Work. References: <6.2.5.6.2.20060612102822.03b52c00@ogud.com> <7.0.1.0.2.20060612174002.03d76008@nominum.com> <2805B0B0-CFA9-49E7-8ABD-4279673564D8@NLnetLabs.nl> <6.2.5.6.2.20060626105457.050ea9a8@nic.mx> <1C71D26A-A127-42B8-948B-F2808A3AC947@NLnetLabs.nl> <90541EE9-12D8-4A67-8178-22A57D70879E@NLnetLabs.nl> <44A1DBBE.8070401@algroup.co.uk> <38636.1151528814@sa.vix.com> In-Reply-To: <38636.1151528814@sa.vix.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Vixie wrote: >>> Is that the data you want? >> Not at all. I'm looking for data (numbers, examples, case studies) >> supporting the claim that DLV doesn't scale. I've heard Paul's >> marketing-speak, and I'm skeptical of it. > > since i don't know how to prove a negative, i can only say that dlv as > currently implemented in bind9 (which may or may not be compatible with > dlv as described in sweiler's internet draft) is not intended to scale. Well, and the dlv-anchor needs rolling over, for the reasons that Thierry states (keys get old). So I think there need two problems to be solved, the roll over of keys for resolvers that are active on the network. And priming of resolvers that have been inactive for a (long) time. I think the rollover drafts are already Good Enough(tm), and I would like to propose a simple priming idea below. If the -threshold draft were to include some ideas from the other drafts, it can become a super-set of the current drafts: - - revocation of keys (by revoked bit and self-signing) (from the -timers draft). - - H(keyset), included automatically or available, reduces polling bandwidth dramatically. (from paul's idea). - - Parameter information trouble: fix M (I vote at 3), (from paul's idea). Also a simple priming key idea. Priming is configured by a URL. - - The keys are the same SEP keys as those used in key-rollover. - - If your key-rollover fails, then you can get from the URL a reply of history: the versions of the DNSKEY and RRSIG(DNSKEY) rrsets that could have been seen by resolvers. The resolver applies the key-rollover algorithm to this trace and obtains the latest SEP keys. - - protocol to the history service is that the client provides the H(keys) that is the latest he trusts, and the server replies the keyset the followed the keyset of H(keys) so that the resolver can make one rollover. The client can then request with the H(keys) of his result the next keyset, and so on. - - The trust-anchor zone can provide history service for as far back as it wants. - - This makes the priming keys algo as secure as the rollover algo for key compromise and so on. - - This could even be in-band as a new query-opcode to a nameserver. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEo6lwkDLqNwOhpPgRAkdjAJkB/LYuKeq3hxITr7t18ghd8OZidwCgqZLv VivG2BFCZlFG1oxnLSXvWk0= =kp0c -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 29 08:40:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvvoR-0006kb-3f for dnsext-archive@lists.ietf.org; Thu, 29 Jun 2006 08:40:03 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvvoM-00009f-Rb for dnsext-archive@lists.ietf.org; Thu, 29 Jun 2006 08:40:03 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvvkF-0003k3-AA for namedroppers-data@psg.com; Thu, 29 Jun 2006 12:35:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [216.127.148.224] (helo=mail4.sea.safepages.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvvkD-0003jn-PM for namedroppers@ops.ietf.org; Thu, 29 Jun 2006 12:35:41 +0000 Received: by mail4.sea.safepages.com (Postfix, from userid 1012) id 8309D2C414; Thu, 29 Jun 2006 12:35:40 +0000 (GMT) Received: from connotech.com (unknown [165.154.49.145]) by mail4.sea.safepages.com (Postfix) with ESMTP id B0DEE2C2F9 for ; Thu, 29 Jun 2006 12:35:38 +0000 (GMT) Message-ID: <44A3C96D.9000500@connotech.com> Date: Thu, 29 Jun 2006 08:37:01 -0400 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Namedroppers Subject: An out-of-scope analysis of in-scope TAK rollover proposals Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Dear DNSEXT particpants: Your current consideration of TAK rollover issues is appreciated. I assume that the draft-ietf-dnsext-rollover-requirements-02 is about to be last called and thus reflects the IETF view on TAK rollover requirements. I also assume to be applicable the short list of three TAK rollover proposals from http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00829.html, i.e. 1) draft-ietf-dnsext-trustupdate-threshold, 2) draft-ietf-dnsext-trustupdate-timers, and 3) draft-laurie-dnssec-key-distribution (for the purpose of the present message, I do not put into question Olaf's view on the presence of my own proposal in the list of TAK rollover porposal). I assume that either the -threshold or the -timers proposal gets selected as the IETF TAK rollover procedure. See e.g. http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00848.html. Then, the IAB carries the good news to the DNS root zone administrator that DNSSEC protocols are ready for deployment at the root (the privacy issue driving the NSEC3 protocol refinement does not apply to the DNS root zone). Accordingly, the DNS root zone administrators will set up N (>=2) TAKs (i.e. KSK DNSKEY RRs having the SEP bit set to 1). So, the DNS root zone administrator turns to the world with the big news that the DNS will be secured, with N (>=2) TAKs at the root and the reassuring confidence that any simultaneous breach of M ( From owner-namedroppers@ops.ietf.org Thu Jun 29 12:56:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvzog-0001ZJ-Oy for dnsext-archive@lists.ietf.org; Thu, 29 Jun 2006 12:56:34 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvybw-0001CJ-1A for dnsext-archive@lists.ietf.org; Thu, 29 Jun 2006 11:39:20 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvyNi-0006s6-4q for dnsext-archive@lists.ietf.org; Thu, 29 Jun 2006 11:24:39 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvyIm-000K05-Tk for namedroppers-data@psg.com; Thu, 29 Jun 2006 15:19:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvyIl-000Jzk-Uh for namedroppers@ops.ietf.org; Thu, 29 Jun 2006 15:19:32 +0000 Received: from [10.31.32.59] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k5TFJCC5054077; Thu, 29 Jun 2006 11:19:20 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <6.2.5.6.2.20060628182608.04874800@nic.mx> References: <6.2.5.6.2.20060612102822.03b52c00@ogud.com> <7.0.1.0.2.20060612174002.03d76008@nominum.com> <2805B0B0-CFA9-49E7-8ABD-4279673564D8@NLnetLabs.nl> <6.2.5.6.2.20060626105457.050ea9a8@nic.mx> <1C71D26A-A127-42B8-948B-F2808A3AC947@NLnetLabs.nl> <90541EE9-12D8-4A67-8178-22A57D70879E@NLnetLabs.nl> <2567.1151511542@sa.vix.com> <6.2.5.6.2.20060628182608.04874800@nic.mx> Date: Thu, 29 Jun 2006 11:19:29 -0400 To: Gustavo Lozano From: Edward Lewis Subject: Re: Is keyrollover neccesary? (was Key rollover Work.) Cc: Namedroppers Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.2 (--) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 At 18:33 -0500 6/28/06, Gustavo Lozano wrote: >Is DNSSECbis deployable without an automatic trust anchor keyrollover feature? The short answer is "yes, but". Looking backwards in time, IETF protocols generally have been deployed without much consideration for long-term management and care. The result has become that you need to import a particular operational environment when attempting to deploy a protocol off-the-shelf. Take a look at the SiteFinder ( http://en.wikipedia.org/wiki/Sitefinder [1]) incident to see what might happen when a protocol feature is exercised. Although the feature was well within the bounds of the protocol, and even well established, the operational environment was upended and a lot of problems ensued. To what extent DNSSEC will be (cost) effective depends on whether or not there is an automated means to rollover trust anchors. Without it, DNSSEC will "jump the shark" ( http://en.wikipedia.org/wiki/Jump_the_shark [2]) at the first key change - if not before. (Which brings up the question, has DNSSEC already "jumped the shark?") But, if we wait for there to be a trust anchor feature, we may never get further than we already have. [1] Man, there's a wikipedia page for everything! It's better than googling... [2] A page for that too...I'm impressed -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Soccer/Futbol. IPv6. Both have lots of 1's and 0's and have a hard time catching on in North America. That tournament in Germany. What's all the fuss? (Get it? "fuss?") -- to unsubscribe send a message to namedroppers-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 Jun 29 13:22:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw0Dw-0007lp-RV for dnsext-archive@lists.ietf.org; Thu, 29 Jun 2006 13:22:40 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw0Dv-0002qf-FY for dnsext-archive@lists.ietf.org; Thu, 29 Jun 2006 13:22:40 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fw09X-0007Ks-Vi for namedroppers-data@psg.com; Thu, 29 Jun 2006 17:18:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE, SPF_PASS autolearn=no version=3.1.1 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fw09X-0007Kg-9v for namedroppers@ops.ietf.org; Thu, 29 Jun 2006 17:18:07 +0000 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 29 Jun 2006 10:18:07 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,192,1149490800"; d="scan'208"; a="30774681:sNHT21880740" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5THI6YL022572; Thu, 29 Jun 2006 13:18:06 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 29 Jun 2006 13:18:06 -0400 Received: from [161.44.174.209] ([161.44.174.209]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 29 Jun 2006 13:18:05 -0400 Message-ID: <44A40B50.9030406@cisco.com> Date: Thu, 29 Jun 2006 13:18:08 -0400 From: Mark Townsley User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: "Olaf M. Kolkman" CC: Dean Anderson , IETF DNSEXT WG Subject: Re: nsid last call (fwd) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Jun 2006 17:18:05.0486 (UTC) FILETIME=[FBE56CE0:01C69B9F] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Olaf M. Kolkman wrote: > > On Jun 28, 2006, at 11:54 PM, Dean Anderson wrote: > >> Can we have a post WGLC draft with the following changes: > > Hello Dean, > > I'm sorry to say, we can not have a post WGLC. > > Since I determined consensus the work has moved out of the working > group and is now in the hands of the IESG. I consider this issue closed. Amy has already initiated the IETF LC at our request. Dean, can your comments be addressed as IETF LC comments? Thanks, - Mark > > Kind regards, > > --Olaf > > ----------------------------------------------------------- > Olaf M. Kolkman > NLnet Labs > http://www.nlnetlabs.nl/ > > > -- to unsubscribe send a message to namedroppers-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 Jun 29 14:13:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw11a-0008ET-Ou for dnsext-archive@lists.ietf.org; Thu, 29 Jun 2006 14:13:58 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw11Z-0007cn-BA for dnsext-archive@lists.ietf.org; Thu, 29 Jun 2006 14:13:58 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fw0ya-000CnA-1x for namedroppers-data@psg.com; Thu, 29 Jun 2006 18:10:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_ZOMBIE autolearn=no version=3.1.1 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fw0yY-000Cmw-Rx for namedroppers@ops.ietf.org; Thu, 29 Jun 2006 18:10:51 +0000 Received: from [130.105.12.10] ([130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id k5TIAiT5024687 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 29 Jun 2006 14:10:44 -0400 Date: Thu, 29 Jun 2006 14:10:42 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Edward Lewis cc: "Olaf M. Kolkman" , , Subject: Re: nsid last call (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.8 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a On Wed, 28 Jun 2006, Edward Lewis wrote: > At 17:54 -0400 6/28/06, Dean Anderson wrote: > >Can we have a post WGLC draft with the following changes: > > > >Use this wording: > > > > 3.1. The NSID Payload > > > > The syntax and semantics of the content of the NSID option is > > deliberately left outside the scope of this specification. It is > > the prerogative of the server administrator to choose the NSID > > content as long as the content is unique to each anycast instance > > so that a remote user is able to match the NSID to the server > > instance over a series of queries. The NSID can be opaque and > > encoded such that it can be decoded by the server adminstrator to > > provide more information. This section describe some of the kinds > > of data that server administrators might choose to provide as the > > content of the NSID option, and explains the reasoning behind > > choosing a simple opaque byte string. > > 1) How does a requirement for uniqueness improve interoperability? Interoperability doesn't seem relevant, unless clients cannot interoperate with servers, which isn't the issue here. NSID is for debugging, primarily human use. > 2) How do you enforce this, i.e., how can you detect the difference > between one instance relying with 2 different strings and two > instances replying with one string each? You often can't enforce anything. But you can say what should and shouldn't be done by inclusion in the standard. In the cases of Roots and others, they are compelled to comply with the standards, and when non-compliance is discovered there is a basis for a complaint. The difficulty in detection of violation does mean that the issue should be ignored. We may still figure it out (eg we detected 30,000 anycast instances of F root by NSID logging), or someone who knows, blabs. Or a direct question is asked of the operator and an honest answer (indicating non-compliance) is returned. Those who want to spoof, will do so anyway. Just like TCP signature spoofer's. There is no need to include this in the standard. > The requirement for uniqueness is not related to interoperability and > is not testable. For those reasons, I think it would be dropped. Many things are not testable. If we dropped all of them, there would be little left of the ~4K published RFC's. > >Delete this from Section 3.1: > > > > o It could be some sort of dynamicly generated identifier so that > > only the name server operator could tell whether or not any two > > queries had been answered by the same server. > > IMHO, I don't care about dropping this because I don't think the > draft really ought to even bother suggesting particular semantics of > the opaque string. I say that from seeing past RFCs that got in hot > water for being "too helpful." > > -- 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 Thu Jun 29 14:18:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw160-0001Wv-2S for dnsext-archive@lists.ietf.org; Thu, 29 Jun 2006 14:18:32 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw15y-00080n-Ob for dnsext-archive@lists.ietf.org; Thu, 29 Jun 2006 14:18:32 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fw13e-000DMk-SG for namedroppers-data@psg.com; Thu, 29 Jun 2006 18:16:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_ZOMBIE autolearn=no version=3.1.1 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fw13e-000DMY-8x for namedroppers@ops.ietf.org; Thu, 29 Jun 2006 18:16:06 +0000 Received: from [130.105.12.10] ([130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id k5TIFfTr024690 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 29 Jun 2006 14:15:41 -0400 Date: Thu, 29 Jun 2006 14:15:39 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: "Olaf M. Kolkman" cc: IETF DNSEXT WG , Mark Townsley , Subject: Re: nsid last call (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.8 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Then I strongly object to his document, as it is now. --Dean On Thu, 29 Jun 2006, Olaf M. Kolkman wrote: > > On Jun 28, 2006, at 11:54 PM, Dean Anderson wrote: > > > Can we have a post WGLC draft with the following changes: > > Hello Dean, > > I'm sorry to say, we can not have a post WGLC. > > Since I determined consensus the work has moved out of the working > group and is now in the hands of the IESG. I consider this issue closed. > > Kind regards, > > --Olaf > > ----------------------------------------------------------- > Olaf M. Kolkman > NLnet Labs > http://www.nlnetlabs.nl/ > > > > -- 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 Thu Jun 29 14:48:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw1Yi-00037Q-ER for dnsext-archive@lists.ietf.org; Thu, 29 Jun 2006 14:48:12 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw1Yg-0001p0-RG for dnsext-archive@lists.ietf.org; Thu, 29 Jun 2006 14:48:12 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fw1VT-000GGX-0Z for namedroppers-data@psg.com; Thu, 29 Jun 2006 18:44:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.1 Received: from [157.185.61.2] (helo=M4.sparta.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fw1VR-000GGG-DM for namedroppers@ops.ietf.org; Thu, 29 Jun 2006 18:44:50 +0000 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id k5TIif2J026336 for ; Thu, 29 Jun 2006 13:44:46 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id k5TIifV8016864 for ; Thu, 29 Jun 2006 13:44:42 -0500 Received: from [157.185.81.183] ([157.185.81.183]) by nemo.columbia.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jun 2006 14:44:40 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <92325.1151507725@sa.vix.com> References: <6.2.5.6.2.20060612102822.03b52c00@ogud.com> <7.0.1.0.2.20060612174002.03d76008@nominum.com> <2805B0B0-CFA9-49E7-8ABD-4279673564D8@NLnetLabs.nl> <6.2.5.6.2.20060626105457.050ea9a8@nic.mx> <1C71D26A-A127-42B8-948B-F2808A3AC947@NLnetLabs.nl> <44A1DB2D.3050704@algroup.co.uk> <3827.1151471569@sa.vix.com> <60E47F1C-F4B1-4DC2-B947-97262B39C746@NLnetLabs.nl> <92325.1151507725@sa.vix.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <91942F8F-60D9-499A-AEAE-A48F818687D7@sparta.com> Content-Transfer-Encoding: 7bit From: Wesley Griffin Subject: Re: Recall: Key rollover Work. Date: Thu, 29 Jun 2006 14:44:39 -0400 To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 29 Jun 2006 18:44:40.0197 (UTC) FILETIME=[142F6B50:01C69BAC] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 On Jun 28, 2006, at 11:15 AM, Paul Vixie wrote: > > Paul, your proposal only made it to the mail list and never into > a draft, > > correct? > > it was presented, so there are slides and notes. i was not > planning to write > it up as a draft unless someone somewhere spoke for it. note: i'm > not saying > i want consensus before i write the draft, i just want someone, > somewhere, to > say it's an attractive approach that they'd like to see "in the > running." at > the moment, not even johani has said so, and he's the original author. I would like to see your proposal as an ID so that it can be properly considered along with the rest of the proposals. -- to unsubscribe send a message to namedroppers-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 Jun 29 15:02:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw1mQ-00037z-DN for dnsext-archive@lists.ietf.org; Thu, 29 Jun 2006 15:02:22 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw1mO-00033G-2p for dnsext-archive@lists.ietf.org; Thu, 29 Jun 2006 15:02:22 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fw1jb-000Hek-5d for namedroppers-data@psg.com; Thu, 29 Jun 2006 18:59:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_ZOMBIE autolearn=no version=3.1.1 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fw1ja-000HeS-Az for namedroppers@ops.ietf.org; Thu, 29 Jun 2006 18:59:26 +0000 Received: from [130.105.12.10] ([130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id k5TIxMLv024714 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 29 Jun 2006 14:59:22 -0400 Date: Thu, 29 Jun 2006 14:59:22 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Mark Townsley cc: "Olaf M. Kolkman" , IETF DNSEXT WG Subject: Re: nsid last call (fwd) In-Reply-To: <44A40B50.9030406@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.8 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca On Thu, 29 Jun 2006, Mark Townsley wrote: > Olaf M. Kolkman wrote: > > > > On Jun 28, 2006, at 11:54 PM, Dean Anderson wrote: > > > >> Can we have a post WGLC draft with the following changes: > > > > Hello Dean, > > > > I'm sorry to say, we can not have a post WGLC. > > > > Since I determined consensus the work has moved out of the working > > group and is now in the hands of the IESG. I consider this issue closed. > Amy has already initiated the IETF LC at our request. Dean, can your > comments be addressed as IETF LC comments? Maybe, if the text can be altered. If the text cannot be altered directly, I think I'd want the IESG to send it back for another revision. I'd object to publishing it as is. --Dean > Thanks, > > - Mark > > > > Kind regards, > > > > --Olaf > > > > ----------------------------------------------------------- > > Olaf M. Kolkman > > NLnet Labs > > http://www.nlnetlabs.nl/ > > > > > > > > -- 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 Thu Jun 29 15:47:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw2U9-0004XQ-Qo for dnsext-archive@lists.ietf.org; Thu, 29 Jun 2006 15:47:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw2Ik-0005SN-M5 for dnsext-archive@lists.ietf.org; Thu, 29 Jun 2006 15:35:48 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fw2EI-000KhY-Pz for namedroppers-data@psg.com; Thu, 29 Jun 2006 19:31:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_ZOMBIE autolearn=no version=3.1.1 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fw2EH-000KhJ-RW for namedroppers@ops.ietf.org; Thu, 29 Jun 2006 19:31:10 +0000 Received: from [130.105.12.10] ([130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id k5TJV2G7024732 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 29 Jun 2006 15:31:03 -0400 Date: Thu, 29 Jun 2006 15:31:02 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Edward Lewis cc: "Olaf M. Kolkman" , , Subject: Re: nsid last call (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.8 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Err, speaking of typos: On Thu, 29 Jun 2006, Dean Anderson wrote: > On Wed, 28 Jun 2006, Edward Lewis wrote: > > > At 17:54 -0400 6/28/06, Dean Anderson wrote: > > >Can we have a post WGLC draft with the following changes: > > > > > >Use this wording: > > > > > > 3.1. The NSID Payload > > > > > > The syntax and semantics of the content of the NSID option is > > > deliberately left outside the scope of this specification. It is > > > the prerogative of the server administrator to choose the NSID > > > content as long as the content is unique to each anycast instance > > > so that a remote user is able to match the NSID to the server > > > instance over a series of queries. The NSID can be opaque and > > > encoded such that it can be decoded by the server adminstrator to > > > provide more information. This section describe some of the kinds > > > of data that server administrators might choose to provide as the > > > content of the NSID option, and explains the reasoning behind > > > choosing a simple opaque byte string. > > > > 1) How does a requirement for uniqueness improve interoperability? > > Interoperability doesn't seem relevant, unless clients cannot > interoperate with servers, which isn't the issue here. NSID is for > debugging, primarily human use. > > > 2) How do you enforce this, i.e., how can you detect the difference > > between one instance relying with 2 different strings and two > > instances replying with one string each? > > You often can't enforce anything. But you can say what should and > shouldn't be done by inclusion in the standard. In the cases of Roots > and others, they are compelled to comply with the standards, and when > non-compliance is discovered there is a basis for a complaint. The > difficulty in detection of violation does mean that the issue should be That should read: difficulty in detection of violation does _not_ mean that the issue should be > ignored. We may still figure it out (eg we detected 30,000 anycast > instances of F root by NSID logging), or someone who knows, blabs. Or a > direct question is asked of the operator and an honest answer > (indicating non-compliance) is returned. > > Those who want to spoof, will do so anyway. Just like TCP signature > spoofer's. There is no need to include this in the standard. > > > The requirement for uniqueness is not related to interoperability and > > is not testable. For those reasons, I think it would be dropped. > > Many things are not testable. If we dropped all of them, there would be > little left of the ~4K published RFC's. > > > >Delete this from Section 3.1: > > > > > > o It could be some sort of dynamicly generated identifier so that > > > only the name server operator could tell whether or not any two > > > queries had been answered by the same server. > > > > IMHO, I don't care about dropping this because I don't think the > > draft really ought to even bother suggesting particular semantics of > > the opaque string. I say that from seeing past RFCs that got in hot > > water for being "too helpful." > > > > > > -- 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 Thu Jun 29 16:21:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw31R-0002T9-Ki for dnsext-archive@lists.ietf.org; Thu, 29 Jun 2006 16:21:57 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw31Q-0006CU-8E for dnsext-archive@lists.ietf.org; Thu, 29 Jun 2006 16:21:57 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fw2Xb-000MiE-17 for namedroppers-data@psg.com; Thu, 29 Jun 2006 19:51:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [209.173.57.84] (helo=cypress.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fw2Xa-000Mhv-DZ for namedroppers@ops.ietf.org; Thu, 29 Jun 2006 19:51:06 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k5TJo2jx010154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 29 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fw2WX-0003SQ-WC; Thu, 29 Jun 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 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-04.txt Message-Id: Date: Thu, 29 Jun 2006 15:50:01 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 --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-04.txt Pages : 16 Date : 2006-6-29 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. It is a snapshot of the DNSEXT working group discussion of June 2004. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-trans-04.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-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-trans-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-29105913.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-trans-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-trans-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-29105913.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 Jun 29 16:21:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw31T-0002UD-1n for dnsext-archive@lists.ietf.org; Thu, 29 Jun 2006 16:21:59 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw31R-0006CU-Nu for dnsext-archive@lists.ietf.org; Thu, 29 Jun 2006 16:21:59 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fw2Wb-000MRq-VM for namedroppers-data@psg.com; Thu, 29 Jun 2006 19:50:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [209.173.53.84] (helo=willow.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fw2Wb-000MRA-7s for namedroppers@ops.ietf.org; Thu, 29 Jun 2006 19:50:05 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k5TJo39F012811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 29 Jun 2006 19:50:03 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fw2WZ-0003Vu-LP; Thu, 29 Jun 2006 15:50:03 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-2929bis-03.txt Message-Id: Date: Thu, 29 Jun 2006 15:50:03 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 --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 : Domain Name System (DNS) IANA Considerations Author(s) : D. Eastlake 3rd Filename : draft-ietf-dnsext-2929bis-03.txt Pages : 19 Date : 2006-6-29 Internet Assigned Number Authority (IANA) parameter assignment considerations are specified for the allocation of Domain Name System (DNS) Classes, RR Types, operation codes, error codes, RR header bits, and AFSDB subtypes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-2929bis-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-2929bis-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-2929bis-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-29140734.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-2929bis-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-2929bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-29140734.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 Jun 30 10:07:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwJef-0000ZP-Ic for dnsext-archive@lists.ietf.org; Fri, 30 Jun 2006 10:07:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwJee-0001RI-57 for dnsext-archive@lists.ietf.org; Fri, 30 Jun 2006 10:07:33 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FwJX1-000Otf-Kd for namedroppers-data@psg.com; Fri, 30 Jun 2006 13:59:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [199.212.90.4] (helo=monster.hopcount.ca) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FwJX0-000OtT-9G for namedroppers@ops.ietf.org; Fri, 30 Jun 2006 13:59:38 +0000 Received: from octopus.hopcount.ca ([199.212.90.5]) by monster.hopcount.ca with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.61 (FreeBSD)) (envelope-from ) id 1FwJWt-000CI9-Jg; Fri, 30 Jun 2006 13:59:32 +0000 In-Reply-To: <3870C46029D1F945B1472F170D2D97900111F6A6@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D97900111F6A6@de01exm64.ds.mot.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8B9B0B02-F87D-477C-A4FE-95A98DBD44A0@ca.afilias.info> Cc: "Bill Woodcock" , "David Ulevitch" , Content-Transfer-Encoding: 7bit From: Joe Abley Subject: Re: You saw this, right? Date: Fri, 30 Jun 2006 09:59:30 -0400 To: Eastlake III Donald-LDE008 X-Mailer: Apple Mail (2.752.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 I'm not seeing any of Woody's responses to your mail, for some reason. But in any case, I think a small amount of additional clarity might be useful here: On 26-Jun-2006, at 12:44, Eastlake III Donald-LDE008 wrote: > What I was thinking was, assume you have N anycast hosts who are DNS > servers and all receive DNS queries sent to IP address ADDR-0. If they > really all think they are just a host at address ADDR-0 and any of > these > host sends out a DNS query, presumably the anycast nature of their > address would mean that the response to that query could come back > to a > different one than the host which originated the query. So, given this > assumption, I would think they wouldn't work very well as recursive > servers. If a client sends a request to a service address which is anycast, then the response from whichever node receives the request will be sourced from the anycast address. Since the destination address of the response is unambiguous, however, there is no problem reaching the right client. Many people have successfully distributed DNS service using anycast, including both authority and recursive servers. If a host which is providing some anycast service originates a request of its own for something (e.g. an anycast DNS server wants to do a zone transfer) it will normally be originated from a globally- unique (non-anycast) unicast address, in order to ensure that the response to the request is routed back to the right node. There is at least one document example of deployed servers where requests from an anycast node are sourced from the anycast service address in order to accommodate address-based filters. Such requests (in the example I'm thinking of) are made with the foreknowledge that many of them will fail. For more on this particular example, see section 5.2. Joe -- to unsubscribe send a message to namedroppers-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 Jun 30 10:38:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwK8j-0007NG-7t for dnsext-archive@lists.ietf.org; Fri, 30 Jun 2006 10:38:37 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwK8h-0002QU-Hd for dnsext-archive@lists.ietf.org; Fri, 30 Jun 2006 10:38:37 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FwK5z-0003uv-39 for namedroppers-data@psg.com; Fri, 30 Jun 2006 14:35:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [129.188.136.8] (helo=motgate8.mot.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FwK5w-0003u0-D4 for namedroppers@ops.ietf.org; Fri, 30 Jun 2006 14:35:44 +0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k5UEZdWB017689 for ; Fri, 30 Jun 2006 07:35:43 -0700 (MST) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id k5UEZcSx026725 for ; Fri, 30 Jun 2006 09:35:38 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: I-D ACTION:draft-ietf-dnsext-2929bis-03.txt Date: Fri, 30 Jun 2006 10:35:37 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790011643B1@de01exm64.ds.mot.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-dnsext-2929bis-03.txt Thread-Index: Acabtq579UbZQms2QvGKquSsqnJ9xgAmUWkg From: "Eastlake III Donald-LDE008" To: X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Hi, The last feedback I got from the working group on this draft was that it was in good shape except for the need for some specific guidelines for the designated RR type allocation expert. So this updated version has such guidelines in section 3.1.3. Hopefully this version, or perhaps -04 is some minor changes are needed, will be ready for WG last call. Thanks, Donald -----Original Message----- From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Thursday, June 29, 2006 3:50 PM To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org Subject: I-D ACTION:draft-ietf-dnsext-2929bis-03.txt=20 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 : Domain Name System (DNS) IANA Considerations Author(s) : D. Eastlake 3rd Filename : draft-ietf-dnsext-2929bis-03.txt Pages : 19 Date : 2006-6-29 =09 Internet Assigned Number Authority (IANA) parameter assignment considerations are specified for the allocation of Domain Name System (DNS) Classes, RR Types, operation codes, error codes, RR header bits, and AFSDB subtypes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-2929bis-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. =20 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-2929bis-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-2929bis-03.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- to unsubscribe send a message to namedroppers-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 Jun 30 10:47:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwKHb-0007t4-H8 for dnsext-archive@lists.ietf.org; Fri, 30 Jun 2006 10:47:47 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwJsM-0001k2-8w for dnsext-archive@lists.ietf.org; Fri, 30 Jun 2006 10:21:42 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FwJfd-0006J7-JI for dnsext-archive@lists.ietf.org; Fri, 30 Jun 2006 10:08:35 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FwJdN-0000H2-3f for namedroppers-data@psg.com; Fri, 30 Jun 2006 14:06:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FwJdK-0000Eu-G6 for namedroppers@ops.ietf.org; Fri, 30 Jun 2006 14:06:10 +0000 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 30 Jun 2006 07:06:11 -0700 X-IronPort-AV: i="4.06,197,1149490800"; d="scan'208"; a="326736668:sNHT33143824" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k5UE6AIG006760; Fri, 30 Jun 2006 07:06:10 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k5UE69CU024647; Fri, 30 Jun 2006 07:06:09 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 30 Jun 2006 07:06:09 -0700 Received: from [192.168.2.10] ([10.21.81.146]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 30 Jun 2006 07:06:08 -0700 Message-ID: <44A52FC7.2020705@cisco.com> Date: Fri, 30 Jun 2006 10:05:59 -0400 From: Mark Townsley User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: Dean Anderson CC: "Olaf M. Kolkman" , IETF DNSEXT WG Subject: Re: nsid last call (fwd) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jun 2006 14:06:09.0177 (UTC) FILETIME=[560DE090:01C69C4E] DKIM-Signature: a=rsa-sha1; q=dns; l=1342; t=1151676370; x=1152540370; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=townsley@cisco.com; z=From:Mark=20Townsley=20 |Subject:Re=3A=20nsid=20last=20call=20(fwd); X=v=3Dcisco.com=3B=20h=3DwWyKoHqDySsJfZSAbDfIVQLhyVU=3D; b=kE3laE0ut00q7TF4Q/Ko00GrmK3tJwOQyJnPqnUI8WOv92DYhgRk/Ki4xsUP0HJ6RsFaPt+q sujVSuV4CD/9uo+zy9KtI0HunbGamko21Lt8Ku83POoioYa0L3Ru23Ld; Authentication-Results: sj-dkim-1.cisco.com; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com verified; ); Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Dean Anderson wrote: > On Thu, 29 Jun 2006, Mark Townsley wrote: > > >> Olaf M. Kolkman wrote: >> >>> On Jun 28, 2006, at 11:54 PM, Dean Anderson wrote: >>> >>> >>>> Can we have a post WGLC draft with the following changes: >>>> >>> Hello Dean, >>> >>> I'm sorry to say, we can not have a post WGLC. >>> >>> Since I determined consensus the work has moved out of the working >>> group and is now in the hands of the IESG. I consider this issue closed. >>> >> Amy has already initiated the IETF LC at our request. Dean, can your >> comments be addressed as IETF LC comments? >> > > Maybe, if the text can be altered. If the text cannot be altered > directly, I think I'd want the IESG to send it back for another > revision. I'd object to publishing it as is. > There will, of course, need to be consensus to change the text. Can you briefly summarize the issue in your IETF LC comment? The email I saw cc'd to the IESG simply stated a general objection against publishing. Thanks, - Mark > --Dean > > >> Thanks, >> >> - Mark >> >>> Kind regards, >>> >>> --Olaf >>> >>> ----------------------------------------------------------- >>> Olaf M. Kolkman >>> NLnet Labs >>> http://www.nlnetlabs.nl/ >>> >>> >>> >>> >> > > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From baimaggiem@0451.com Fri Jun 30 13:50:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwN8c-0005Wl-LS; Fri, 30 Jun 2006 13:50:42 -0400 Received: from adsl196-38-40-217-196.adsl196-10.iam.net.ma ([196.217.40.38] helo=user-3wm2ver2su) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwN8O-0001Gm-27; Fri, 30 Jun 2006 13:50:42 -0400 Message-ID: <662161c806047692aiyo81k3b2dwr7ha2z3gko0to9z0@mail.0451.com> Date: Fri, 30 Jun 2006 17:50:25 0000 From: "Josiah Madden" To: dnsext-archive@lists.ietf.org Subject: Your money, mosaic disease MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam: Not detected X-Spam-Score: 1.1 (+) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Even if you have no erectin problems SOFT CIAzLIS would help you to make BETTER SE X MORE OFTEN! and to bring unimagnable plesure to her. Just disolve half a pil under your tongue and get ready for action in 15 minutes. The tests showed that the majority of men after taking this medic ation were able to have PERFECT ER ECTI ON during 36 hours! VISIT US, AND GET OUR SPECIAL 70% DISC OUNT OFER! http://UOEIYIH.spitefew.com ========== "Touched him with a wingtip! Brought him to life! The Son of the I went past the parking lot. There was a checkpoint there. There were "We're not ready!" said Henry Calvin Gull. "We're not welcome! We're "Are you trying to tell me that you're not a stalker?" flashing one hundred fifty miles per hour past his instructor. He pulled But then, just as I was heading up the stairs, I suddenly saw the double-diamond formation, wingtips almost overlapping. They came across "Thank you. How do you feel about turboplatforms?" From owner-namedroppers@ops.ietf.org Fri Jun 30 14:44:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwNyk-0007qV-FA for dnsext-archive@lists.ietf.org; Fri, 30 Jun 2006 14:44:34 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwNyh-0005P1-TF for dnsext-archive@lists.ietf.org; Fri, 30 Jun 2006 14:44:34 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FwNuh-000EnD-No for namedroppers-data@psg.com; Fri, 30 Jun 2006 18:40:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FwNue-000EmM-SS for namedroppers@ops.ietf.org; Fri, 30 Jun 2006 18:40:21 +0000 Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k5UIeGsZ011250 for ; Fri, 30 Jun 2006 14:40:16 -0400 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.13.6/8.13.6) with SMTP id k5UIe0QD016719 for ; Fri, 30 Jun 2006 14:40:01 -0400 (EDT) From: "Scott Rose" To: Subject: RE: I-D ACTION:draft-ietf-dnsext-2929bis-03.txt Date: Fri, 30 Jun 2006 14:40:02 -0400 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: <3870C46029D1F945B1472F170D2D9790011643B1@de01exm64.ds.mot.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 I have one comment on the new text (or maybe this was old, but I the first time I saw it). Unfortunately, it is a high level politics thing. The first paragraph in Section 3.1.3 has the sentence "The Expert should reject any RRTYPE allocation request...". That makes it sound like a much more formal process than the rest of the document lays out. From what I gathered, it is more of a "recommend/not recommend" thing. The Expert's job should be more of an endorsement, or failing the criteria, helping the proponents meet whatever goal they have for the draft. Yes, this is a process issue and not a technical one, but something that may catch some poor WG member acting as a expert in the future. Scott **************************************** Scott Rose Adv. Network Tech. Div., NIST +1 301-975-8439 https://www-x.antd.nist.gov/dnssec/ http://www.dnssec-deployment.org/ **************************************** > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Eastlake III > Donald-LDE008 > Sent: Friday, June 30, 2006 10:36 AM > To: namedroppers@ops.ietf.org > Subject: RE: I-D ACTION:draft-ietf-dnsext-2929bis-03.txt > > > Hi, > > The last feedback I got from the working group on this draft was that it > was in good shape except for the need for some specific guidelines for > the designated RR type allocation expert. So this updated version has > such guidelines in section 3.1.3. Hopefully this version, or perhaps -04 > is some minor changes are needed, will be ready for WG last call. > > Thanks, > Donald > > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Thursday, June 29, 2006 3:50 PM > To: i-d-announce@ietf.org > Cc: namedroppers@ops.ietf.org > Subject: I-D ACTION:draft-ietf-dnsext-2929bis-03.txt > > 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 : Domain Name System (DNS) IANA Considerations > Author(s) : D. Eastlake 3rd > Filename : draft-ietf-dnsext-2929bis-03.txt > Pages : 19 > Date : 2006-6-29 > > Internet Assigned Number Authority (IANA) parameter assignment > considerations are specified for the allocation of Domain Name System > (DNS) Classes, RR Types, operation codes, error codes, RR header bits, > and AFSDB subtypes. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-2929bis-03.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-ietf-dnsext-2929bis-03.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-dnsext-2929bis-03.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 30 15:45:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwOvZ-0007Uo-4Z for dnsext-archive@lists.ietf.org; Fri, 30 Jun 2006 15:45:21 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwOvY-00023R-Kb for dnsext-archive@lists.ietf.org; Fri, 30 Jun 2006 15:45:21 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FwOs6-000OFy-AT for namedroppers-data@psg.com; Fri, 30 Jun 2006 19:41:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,INFO_TLD autolearn=no version=3.1.1 Received: from [207.219.45.62] (helo=mail.libertyrms.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FwOs5-000OFj-9v for namedroppers@ops.ietf.org; Fri, 30 Jun 2006 19:41:45 +0000 Received: from [10.1.3.236] (helo=roaming6.int.libertyrms.com) by mail.libertyrms.com with esmtp (Exim 4.22) id 1FwOs4-0007pS-TY for namedroppers@ops.ietf.org; Fri, 30 Jun 2006 15:41:44 -0400 Received: by roaming6.int.libertyrms.com (Postfix, from userid 1019) id E55B01C37FF; Fri, 30 Jun 2006 15:41:16 -0400 (EDT) Date: Fri, 30 Jun 2006 15:41:16 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: Recall: Key rollover Work. Message-ID: <20060630194116.GG595@afilias.info> Reply-To: Andrew Sullivan References: <6.2.5.6.2.20060612102822.03b52c00@ogud.com> <7.0.1.0.2.20060612174002.03d76008@nominum.com> <2805B0B0-CFA9-49E7-8ABD-4279673564D8@NLnetLabs.nl> <6.2.5.6.2.20060626105457.050ea9a8@nic.mx> <1C71D26A-A127-42B8-948B-F2808A3AC947@NLnetLabs.nl> <44A1DB2D.3050704@algroup.co.uk> <3827.1151471569@sa.vix.com> <60E47F1C-F4B1-4DC2-B947-97262B39C746@NLnetLabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <60E47F1C-F4B1-4DC2-B947-97262B39C746@NLnetLabs.nl> User-Agent: Mutt/1.5.11 X-SA-Exim-Mail-From: andrew@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 On Wed, Jun 28, 2006 at 07:44:18AM +0200, Olaf M. Kolkman wrote: > I would really appreciate if the working group did the work on > technical review. Colleagues, In response to the request above, I either reviewed or started to review four documents, in order to compare them to draft-ietf-dnsext-rollover-requirements-02.txt, and determine which (if any) meet the requirements set out in that document (I call it "the requirements" below). The documents in question are these: draft-ietf-dnsext-trustupdate-threshold-01.txt draft-ietf-dnsext-trustupdate-timers-02.txt draft-laurie-dnssec-key-distribution-02.txt draft-moreau-dnsext-takrem-dns-02.txt I did not review draft-weiler-dnssec-dlv-01.txt yet, because I did not initially think that it was a candidate to satisfy the requirements. I'm happy to do so, however (is that wanted?). I thought to send these comments now anyway, in the (perhaps misguided) hope that they'll be helpful to others in the context of the discussion. I quickly concluded that draft-moreau-dnsext-takrem-dns-02.txt could not meet requirement 5.2, because it is published with a "no derivative works" rider, and because there are restrictions on the type of license under which software based on it could be released. I therefore did not read the document, and cannot comment on its quality. (I did read the table of contents, and the document looks like it would be interesting to read.) I read draft-laurie-dnssec-key-distribution-02.txt. I think it is a good draft, and that it is an excellent idea for how to handle the problem of which keys may be trusted when getting SEPs set up. It does not, however, appear to be a general solution for trust anchor management: it seems to violate requirements 5.3 and 5.11. Unlike another reviewer, I do not think there are scaling problems with it. I believe it provides a useful mechanism for getting DNSSEC "off the ground" in the absence of the signing of the root, so I think it should be pursued, but not as a solution to the problems laid out in the requirements. Of the remaining two drafts (to which I'll refer as -threshold and -timers), I believe either one has the potential to meet the requirements. In my opinion, there are some advantages to each. If I have to pick just one, I slightly prefer -threshold, just because no bit assignment is required and because its approach to the problem feels natural to me. But I don't put any great stock in that preference: I could support either of these drafts. Both of the drafts appear more or less to meet all the requirements. In what follows, I discuss ways in which I think one or the other is slightly weaker in meeting the requirements as they are written. In the case of requirements I don't mention at all, both drafts meet the requirement equally and adequately in my opinion. The first caveat is that there is an IPR claim against both of drafts. The registered claim appears to meet requirement 5.2; but it is not plain to me, since I was unable to find actual terms of use. My view is that -timers is slightly less scalable (requirement 5.1) than is -threshold, because of the way -timers queries, but I think the additional load is almost certainly too little to be worthy of consideration. I have a tiny worry about manual operation (5.6) and -timers. It appears to me that the wrong kind of manual operation will result in the Missing state. I think this could be addressed in the draft, however. I think that all-key compromise could be slightly worse for -threshold than it is for -timers, in that under a total key compromise, -threshold devolves to STALE, whereas I've managed to convince myself that the same case in -timers just puts the zone back into an unsecured state (I may yet un-convince myself of that. Clue sticks are welcome). This is somewhat related to Thierry Moreau's comment in ; but my view is ultimately that no protocol is going to save operators from key mismanagement. I think both drafts work well in the presence of good key management regimes. I do have a worry about -timers in the case of single key compromise, in that the hold-down period is at minimum 30 days. One advantage I see for -threshold in this case is that the rollover acceptance policy is determined by the client. So each of these meets the "unplanned" requirement of section 5.7 (they both handle planned rolls just fine, as near as I can tell), but with different potential issues. A similar set of considerations apply to requirement 5.8. (I'm particularly concerned about timeliness in the context of unplanned events, so that's how I read 5.8.) I think that -threshold might fail requirement 5.9 in the event of multiple key compromise or expiry. This may be a matter of correct maintenance, though. While neither document requires a new RR type (5.10), -timers does need a bit assignment. Requirements 5.11 itself is slightly confusing to me, because I don't think there's really any such thing as "replac[ing] an existing Trust Anchor with another." It's more exactly a matter of adding one, and removing another. Assuming that's what the requirement authors mean (and I believe it is), I think both drafts meet this. Because -threshold relies on multiple keys to make up the threshold, it is entirely possible that in normal operation it would violate requirement 5.12 (specifically, the "at least one" formulation therein). This is true by design, and I think that -threshold's approach is in keeping with the sentiment behind 5.12 (recovery should be possible in case of some compromises, but maybe not total compromise); but -threshold nevertheless cannot meet this requirement as written. I believe it is possible to get either -timers or -threshold to violate requirement 5.13, if you change enough keys fast enough, but I suspect that would be true of any implementable specification. Any comments I have on the documents themselves I'll send under separate heading. Best regards, A -- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 jabber: ajsaf@jabber.org +1 416 646 3304 x4110 -- to unsubscribe send a message to namedroppers-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 Jun 30 16:19:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwPSi-0005uy-8h for dnsext-archive@lists.ietf.org; Fri, 30 Jun 2006 16:19:36 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwPSg-0004vz-RW for dnsext-archive@lists.ietf.org; Fri, 30 Jun 2006 16:19:36 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FwPPT-00024m-9O for namedroppers-data@psg.com; Fri, 30 Jun 2006 20:16:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.1.1 Received: from [204.74.78.17] (helo=atlas.centergate.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FwPPS-00024b-E4 for namedroppers@ops.ietf.org; Fri, 30 Jun 2006 20:16:14 +0000 Received: from john-kristoffs-computer.local (atlas.centergate.com [127.0.0.1]) by atlas.centergate.com (8.13.1/8.13.1) with SMTP id k5UKGDMj002585 for ; Fri, 30 Jun 2006 13:16:13 -0700 Message-Id: <200606302016.k5UKGDMj002585@atlas.centergate.com> Date: Fri, 30 Jun 2006 15:16:12 -0500 From: John Kristoff To: namedroppers@ops.ietf.org Subject: Re: draft-eastlake-dnsext-cookies-00.txt In-Reply-To: <3870C46029D1F945B1472F170D2D97900111F46C@de01exm64.ds.mot.com> References: <3870C46029D1F945B1472F170D2D97900111F46C@de01exm64.ds.mot.com> X-Mailer: Sylpheed version 2.2.2 (GTK+ 2.8.12; i386-apple-darwin8.5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 On Sun, 25 Jun 2006 23:08:28 -0400 "Eastlake III Donald-LDE008" wrote: > So I had this idea for DNS cookies to help ameliorate traffic > amplification, cache poisoning, etc. attacks. Anyway, I've written up > my idea and the first draft is available as > http://www.ietf.org/internet-drafts/draft-eastlake-dnsext-cookies-00.txt > I'd be interested in people's comments. This is a topic I'm interested in so I wanted to provide some feedback. Hopefully it is helpful. I did some experimentation with putting RRs in the additional section of requests and found that most servers seem to silently ignore them. However, I did find one case, where servers that fingerprint (fpdns) as a Microsoft Windows DNS 2000 implementation will first send back a FORMERR. Though some servers stop there, I've seen others that then follow up immediately with an answer if the query was otherwise valid. In the case of adding a cookie to the additional section in a response, what if there is no room for the cookie, particularly if the policy for them is set to "enforced"? Does it take precedence over other records? My understanding of this draft is that this attempts to offset the DoS reflection/amplification attack by trying to avoid having servers respond to illegimate requests. For the resolver, it attempts to help avoid cache poisoning by essentially requiring an attacker to forge another, hopefully not easily knowable, set of bits. From the perspective of minimizing the DoS attacks, the server has no incentive, and in fact probably has a disincentive to set the policy to enabled, rather than disabled or enforced. The resolvers have some incentive to set their policy to enabled. Unless I'm missing something, there is this policy disconnect that will prohibit deployment without the impossible "flag day". The whole notion of having to have the resolvers and servers "learn" the cookies based on past queries and answers in the first place seems problematic. There seems to be a race condition here that an attacker would be able to exploit, either by having the other side learn it's illegimate cookie first or when a valid cookie expires. In the case of a forwarding server, what should happen? Will a cookie be forwarded along with the request or should it be stripped, or even stripped and replaced with a new cookie, while doing validation on the cookie it received and vice versa with the original querier (if it has support for any of this functionality at all). I found a handful of small grammatical problems, shoot me and email offlist if you want to hear about those at this stage. 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: