From owner-namedroppers@ops.ietf.org Sun May 1 02:39:36 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21756 for ; Sun, 1 May 2005 02:39:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DS82k-0004ZS-FC for namedroppers-data@psg.com; Sun, 01 May 2005 06:35:06 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DS82i-0004Yh-9f for namedroppers@ops.ietf.org; Sun, 01 May 2005 06:35:04 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 4A6BD24B70; Sun, 1 May 2005 08:35:03 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 3ED2624C6F for ; Sun, 1 May 2005 08:35:02 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id j416Z2et012675 for ; Sun, 1 May 2005 08:35:02 +0200 Received: (from olaf@localhost) by x50.ripe.net (8.12.10/8.12.6) id j416Z2AE004169 for namedroppers@ops.ietf.org; Sun, 1 May 2005 08:35:02 +0200 Date: Sun, 1 May 2005 08:35:02 +0200 From: Olaf Kolkman Message-Id: <200505010635.j416Z2AE004169@x50.ripe.net> To: namedroppers@ops.ietf.org Subject: DNSEXT list policy X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: U 0.490526 / -5.9 X-RIPE-Signature: e6c54b93e7cbd19b8e0ceb6a8fca2d4d X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk - 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 May 6 10:33:12 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20892 for ; Fri, 6 May 2005 10:33:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DU3nu-000KSu-UO for namedroppers-data@psg.com; Fri, 06 May 2005 14:27:46 +0000 Received: from [144.189.100.105] (helo=motgate5.mot.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DU3nt-000KSe-0J for namedroppers@ops.ietf.org; Fri, 06 May 2005 14:27:45 +0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id j46EWYAs003240 for ; Fri, 6 May 2005 07:32:35 -0700 (MST) Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id j46ETkRa029416 for ; Fri, 6 May 2005 09:29:47 -0500 (CDT) Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.72) id ; Fri, 6 May 2005 10:27:41 -0400 Message-ID: <62173B970AE0A044AED8723C3BCF238109316BE1@ma19exm01.e6.bcs.mot.com> From: Eastlake III Donald-LDE008 To: namedroppers@ops.ietf.org Subject: RE: RFC 4034 typographical error ? Date: Fri, 6 May 2005 10:27:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk There haven't been any comments on this. I'll submit an errata to the RFC editor in a couple of weeks unless I hear something to the contrary. Thanks, Donald -----Original Message----- From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Eastlake III Donald-LDE008 Sent: Sunday, April 10, 2005 11:02 PM To: 'Abhijit Hayatnagarkar' Cc: namedroppers@ops.ietf.org Subject: RE: RFC 4034 typographical error ? This is indeed a typo. It should be the 3rd and 2nd to last octets. When I designed the key tag for RSA, I didn't want to use the bottom octet as the bottom bit is always on and their might be other patterns in the relative occurance of values in the bottom octet. So I decided to ignore the bottom octet and take the next two. Thanks, Donald -----Original Message----- From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Abhijit Hayatnagarkar Sent: Thursday, April 07, 2005 10:11 AM To: namedroppers@ops.ietf.org Subject: RFC 4034 typographical error ? [ Moderators note: This post needed manual approval. Either it was posted by a non-subscribed address, or the posting was too large ( > 20000bytes ) for this list. With the massive amount of spam, it is easy to miss and therefore delete posts that need manual approval. Please use your subscribed address to post, or shorten your postings by using links instead of attachments. ] Appendix B.1 of RFC 4034 says: " For a DNSKEY RR with algorithm 1, the key tag is defined to be the most significant 16 bits of the least significant 24 bits in the public key modulus (in other words, the 4th to last and 3rd to last octets of the public key modulus). " Thus, if the last 4 octets of the public key modulus are 0x11223344, then this would mean that the keytag will have the value 0x2233. If so, should the part in parenthesis be changed to "(in other words, the 3rd to last and 2nd to last octets of the public key modulus) " ? Thanks, Abhijit Hayatngarkar Senior Engineer SPARTA, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to namedroppers-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 May 9 05:59:32 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22459 for ; Mon, 9 May 2005 05:59:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DV4wW-0008hC-NZ for namedroppers-data@psg.com; Mon, 09 May 2005 09:52:52 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DV4wT-0008gp-LQ for namedroppers@ops.ietf.org; Mon, 09 May 2005 09:52:49 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id E94D9251F3; Mon, 9 May 2005 11:52:48 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 1A48F251F1; Mon, 9 May 2005 11:52:48 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id j499qmet005457; Mon, 9 May 2005 11:52:48 +0200 Date: Mon, 9 May 2005 11:52:47 +0200 From: "Olaf M. Kolkman" To: Eastlake III Donald-LDE008 Cc: namedroppers@ops.ietf.org Subject: Re: RFC 4034 typographical error ? Message-Id: <20050509115247.4d3c3fdb.olaf@ripe.net> In-Reply-To: <62173B970AE0A044AED8723C3BCF238109316BE1@ma19exm01.e6.bcs.mot.com> References: <62173B970AE0A044AED8723C3BCF238109316BE1@ma19exm01.e6.bcs.mot.com> Organization: RIPE NCC X-Mailer: Sylpheed version 1.0.3 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.001884 / -5.9 X-RIPE-Signature: bcc167c08df368044f6dea7c4411c01a X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 6 May 2005 10:27:40 -0400 Eastlake III Donald-LDE008 wrote: > There haven't been any comments on this. I'll submit an errata to the RFC editor in a couple of weeks unless I hear something to the contrary. > I concur, thanks for keeping an eye on this Donald. Besides this typo should be mentioned in the "clarification and implementation notes" draft that Weiler et al ("et al" still to be determined) are maintaining (draft-weiler-dnsext-dnssec-bis-updates-00, to be published as draft-ietf-dnsext-dnssec-bis-updates-00) -- 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 May 9 09:05:27 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08945 for ; Mon, 9 May 2005 09:05:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DV7td-000MXP-R9 for namedroppers-data@psg.com; Mon, 09 May 2005 13:02:05 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DV7ta-000MWy-3D for namedroppers@ops.ietf.org; Mon, 09 May 2005 13:02:02 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 5D89324F37; Mon, 9 May 2005 15:02:01 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 7B95B24FFD; Mon, 9 May 2005 15:02:00 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id j49D20et003746; Mon, 9 May 2005 15:02:00 +0200 Date: Mon, 9 May 2005 15:02:00 +0200 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Cc: Spencer.Shepler@sun.com, beepy@netapp.com, ogud@ogud.com, okolkman@ripe.net, Rick Mesta Subject: draft-mesta-nfs4id-dns-rr-01 Message-Id: <20050509150200.28002bb0.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 1.0.3 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.000000 / -5.9 X-RIPE-Signature: 496d779e687274b45c796214c4420fbe X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear colleagues, Rick Mesta has recently posted the following I-D: A DNS RR for NFSv4 ID Domains draft-mesta-nfs4id-dns-rr-01 The document would benefit from some review by the DNS community. I've had some private communication with the editor and one of the issues that came up during the conversation was that the NFS client is supposed to know its "default domain". (The "default domain" being what e.g. the res_init() function would return). AFAIK the "default domain" is not something that is part of the DNS specs but I am afraid I am overlooking something. What would be a proper specification or reference for the "default domain"? Please try to CC the list on issues that are within scope and try to keep out-of-scope issues off list. Thanks a lot. -- 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 Tue May 10 04:52:11 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29479 for ; Tue, 10 May 2005 04:52:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVQOq-000FXQ-A6 for namedroppers-data@psg.com; Tue, 10 May 2005 08:47:32 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DVQOn-000FWy-Vk for namedroppers@ops.ietf.org; Tue, 10 May 2005 08:47:30 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 83D0E2DE62; Tue, 10 May 2005 10:47:26 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 81E622DE5A; Tue, 10 May 2005 10:47:26 +0200 (CEST) Date: Tue, 10 May 2005 10:47:26 +0200 (CEST) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: namedroppers@ops.ietf.org, Samuel Weiler cc: "Olaf M. Kolkman" , =?iso-8859-1?Q?=D3lafur_Gudmundsson?= Subject: rfc 4035 examples nits Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk WG-chairs, Sam, et alii, Would you be so kind and have these added to the dnssec-bis-errata document? A few nits found in the examples section of rfc4035 C.1. Authenticating an Answer The text in both paragraphs refer to the examples in B.1 as "x.w.example.com" while B.1 is "x.w.example". This is painfully obvious in the second paragraph where it states that the RRSIG labels field value of 3 indicates that the answer was not the result of wildcard expansion. This is true for "x.w.example" but not for "x.w.example.com", which ofcourse has a label count of 4 (antithetically, a label count of 3 would imply the answer _was_ the result of a wildcard expansion). C.1.1 Authenticating the Example DNSKEY RR This example shows the logical authentication process that starts from the a configured root DNSKEY (or DS RR) and moves down the tree to authenticate the desired "example" DNSKEY RR. second sentence: "the a" should be "a" C.6. Wildcard Expansion first paragraph: ... is the result of wildcard expansion, as the "a.z.w.example" name contains 4 labels. The name "a.z.w.w.example" is replaced by "*.w.example", the MX RRset is placed in canonical form, and, ... In the second sentence quoted above, "a.z.w.w.example" should be "a.z.w.example". Thanks, Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue May 10 09:33:56 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25966 for ; Tue, 10 May 2005 09:33:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVUmv-000IyW-PV for namedroppers-data@psg.com; Tue, 10 May 2005 13:28:41 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DVUmt-000Iy1-Ss for namedroppers@ops.ietf.org; Tue, 10 May 2005 13:28:40 +0000 Received: from [10.31.32.227] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j4ADSVj5028163; Tue, 10 May 2005 09:28:32 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <200504270345.j3R3jSbX013225@drugs.dv.isc.org> <26a4754c6cdbfbc778f45293c5eb819f@ucd.ie> Date: Tue, 10 May 2005 09:28:30 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: Who hates the DNAME? Cc: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 20:55 +0100 4/27/05, Niall O'Reilly wrote: >What it comes down to is, not mixing the kinds of synthesis you use. > >Simple terminal (non-NS, non-DNAME) wildcard specifies a synthesis which >might be called "default terminal substitution". This is synthesis because >the given QNAME does not match the NAME of any existing RR; an RRset is >brought into existence on demand. ... >Simple DNAME specifies "non-terminal substitution". This is >synthesis because, >just like the simple wildcard case, the given QNAME does not match the NAME of >any existing RR. About 2 trans-oceanic flights ago, I began to reply to this but put it aside. Just know I came to grok the message - sometimes a message haunts you for a reason. "* DNAME" is attempting a "simple terminal synthesis of a non-terminal substitution rule." This is "non-deterministic synthesis" of a *rule*, not data, which is at the heart of the conflict with the operation of caching (non-authoritative, recursive, etc.) servers. When rules are generated in a non-deterministic manner and fed to different caches, coherency of the database is lost. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue May 10 09:41:47 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26355 for ; Tue, 10 May 2005 09:41:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVUxX-000Jux-M4 for namedroppers-data@psg.com; Tue, 10 May 2005 13:39:39 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DVUxW-000Juj-TO for namedroppers@ops.ietf.org; Tue, 10 May 2005 13:39:39 +0000 Received: from [10.31.32.227] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j4ADdVFf028222; Tue, 10 May 2005 09:39:32 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Tue, 10 May 2005 09:39:30 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: * DNAME text in wcard Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Comments on this? ... 4.4 DNAME RRSet at a Wild Card Domain Name Ownership of a DNAME RRSet by a wild card domain name represents a threat to the coherency of the DNS and is to be avoided or outright rejected. Such a DNAME RRSet represents non-deterministic synthesis of rules fed to different caches. As caches are fed the different rules (in an unpredictable manner) the caches will cease to be coherent. For example, assume one cache, responding to a recursive request, obtains the record "a.b.example. DNAME foo.bar.tld." and another cache obtains "b.example. DNAME foo.bar.tld.", both generated from the record "*.example. DNAME foo.bar.tld." by an authoritative server. Queries for "sub.a.b.example. A" will be rewritten as "sub.foo.bar.tld. A" by the former caching server and rewritten as "sub.a.foo.bar.tld. A" by the latter. Coherency is lost, an operational nightmare ensues. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue May 10 11:24:06 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05703 for ; Tue, 10 May 2005 11:24:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVWXj-0002LI-RF for namedroppers-data@psg.com; Tue, 10 May 2005 15:21:07 +0000 Received: from [204.152.189.154] (helo=gusto.araneus.fi) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DVWXh-0002L2-JQ for namedroppers@ops.ietf.org; Tue, 10 May 2005 15:21:05 +0000 Received: from guava.araneus.fi ([195.238.197.162]) by gusto.araneus.fi (8.12.10/8.12.10) with ESMTP id j4AFKtqX019320; Tue, 10 May 2005 08:20:56 -0700 (PDT) Received: from guava.araneus.fi (localhost [127.0.0.1]) by guava.araneus.fi (8.12.10/8.11.6) with ESMTP id j4AFKtLG019104; Tue, 10 May 2005 18:20:55 +0300 (EEST) Received: (from gson@localhost) by guava.araneus.fi (8.12.10/8.12.6/Submit) id j4AFKsiu007568; Tue, 10 May 2005 18:20:54 +0300 (EEST) Date: Tue, 10 May 2005 18:20:54 +0300 (EEST) Message-Id: <200505101520.j4AFKsiu007568@guava.araneus.fi> To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: * DNAME text in wcard In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.4.1 From: gson@araneus.fi (Andreas Gustafsson) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward Lewis writes: > Comments on this? > > 4.4 DNAME RRSet at a Wild Card Domain Name > > Ownership of a DNAME RRSet by a wild card domain name represents a > threat to the coherency of the DNS and is to be avoided or outright > rejected. Such a DNAME RRSet represents non-deterministic synthesis > of rules fed to different caches. As caches are fed the different > rules (in an unpredictable manner) the caches will cease to be coherent. > > For example, assume one cache, responding to a recursive request, obtains > the record "a.b.example. DNAME foo.bar.tld." and another cache > obtains "b.example. DNAME foo.bar.tld.", both generated from the record > "*.example. DNAME foo.bar.tld." by an authoritative server. > > Queries for "sub.a.b.example. A" will be rewritten as "sub.foo.bar.tld. A" > by the former caching server and rewritten as "sub.a.foo.bar.tld. A" by > the latter. Coherency is lost, an operational nightmare ensues. At the risk of repeating myself: caching servers that actually follow the algorithm in RFC2672 section 4.2, "Processing by Resolvers", will _not_ perform the rewrites described in the last paragraph. Caching servers that do perform such rewrites should be fixed, not declared correct by saying that the rewrite "will" happen. This probably should be clarified in the DNAME specification rather than the wildcard one, but if you want to discuss it on the wildcard side, the text should look more like this: 4.4 DNAME RRSet at a Wild Card Domain Name When a wild card domain name owns a DNAME RRset, queries for type DNAME or type ANY at multiple names matching the wild card will answered with multiple synthesized DNAME RRsets representing mutually conflicting DNAME rewrite rules, and these RRsets may be cached by caching servers. To preserve the coherency of the DNS, it is important that caching DNS servers do not themselves perform DNAME rewrites based on such cached DNAME RRsets. For example, assume one cache, responding to a recursive request, obtains the record "a.b.example. DNAME foo.bar.tld." and another cache obtains "b.example. DNAME foo.bar.tld.", both generated from the record "*.example. DNAME foo.bar.tld." by an authoritative server. If the caches did DNAME rewrites based on the cached DNAMEs, queries for "sub.a.b.example. A" would be rewritten as "sub.foo.bar.tld. A" by the former caching server and rewritten as "sub.a.foo.bar.tld. A" by the latter. Coherency would be lost, and an operational nightmare would ensue. -- Andreas Gustafsson, gson@araneus.fi -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue May 10 12:16:35 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09588 for ; Tue, 10 May 2005 12:16:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVXMp-0006iU-Ti for namedroppers-data@psg.com; Tue, 10 May 2005 16:13:55 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DVXMo-0006iF-Oo for namedroppers@ops.ietf.org; Tue, 10 May 2005 16:13:55 +0000 Received: from [10.31.32.227] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j4AGDe5O029070; Tue, 10 May 2005 12:13:42 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200505101520.j4AFKsiu007568@guava.araneus.fi> References: <200505101520.j4AFKsiu007568@guava.araneus.fi> Date: Tue, 10 May 2005 12:13:42 -0400 To: gson@araneus.fi (Andreas Gustafsson) From: Edward Lewis Subject: Re: * DNAME text in wcard Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Now I am more confused than before. At 18:20 +0300 5/10/05, Andreas Gustafsson wrote: >Edward Lewis writes: >> Comments on this? >> >> 4.4 DNAME RRSet at a Wild Card Domain Name >> >> Ownership of a DNAME RRSet by a wild card domain name represents a >> threat to the coherency of the DNS and is to be avoided or outright >> rejected. Such a DNAME RRSet represents non-deterministic synthesis >> of rules fed to different caches. As caches are fed the different >> rules (in an unpredictable manner) the caches will cease to be coherent. >> >> For example, assume one cache, responding to a recursive request, obtains >> the record "a.b.example. DNAME foo.bar.tld." and another cache >> obtains "b.example. DNAME foo.bar.tld.", both generated from the record >> "*.example. DNAME foo.bar.tld." by an authoritative server. >> >> Queries for "sub.a.b.example. A" will be rewritten as "sub.foo.bar.tld. A" >> by the former caching server and rewritten as "sub.a.foo.bar.tld. A" by >> the latter. Coherency is lost, an operational nightmare ensues. > >At the risk of repeating myself: caching servers that actually follow >the algorithm in RFC2672 section 4.2, "Processing by Resolvers", will >_not_ perform the rewrites described in the last paragraph. > >Caching servers that do perform such rewrites should be fixed, not >declared correct by saying that the rewrite "will" happen. >This probably should be clarified in the DNAME specification rather >than the wildcard one, but if you want to discuss it on the wildcard >side, the text should look more like this: I agree that the DNAME ought to be cleaned up elsewhere in general, but I do need to deal with the wild card issues with DNAME here. BTW - thanks for sending text. > 4.4 DNAME RRSet at a Wild Card Domain Name > > When a wild card domain name owns a DNAME RRset, queries for > type DNAME or type ANY at multiple names matching the > wild card will answered with multiple synthesized DNAME RRsets > representing mutually conflicting DNAME rewrite rules, > and these RRsets may be cached by caching servers. > > To preserve the coherency of the DNS, it is important that > caching DNS servers do not themselves perform DNAME rewrites > based on such cached DNAME RRsets. What do you mean by "such cached DNAME RRsets?" Are you referring to DNAME RRsets cached upon receipt having been synthesized by the sender? How could the recursive server tell them apart? I was under the assumption that RFC 2672 "directs" caches to do DNAME rewrites... In 4.2/step 4.d, this lays the received DNAME in the cache. d. if the response shows a DNAME and that is not the answer itself, cache the DNAME. If substitution of the DNAME's for its in the SNAME would overflow the legal size for a , return an implementation-dependent error to the application; otherwise perform the substitution and go to step 1. In 4.2/step 1, a later query sees: A resolver or a server providing recursive service must be modified to treat a DNAME as somewhat analogous to a CNAME. The resolver algorithm of [DNSCF] section 5.3.3 is modified to renumber step 4.d as 4.e and insert a new 4.d. The complete algorithm becomes: 1. See if the answer is in local information, and if so return it to the client. I would interpret this as saying that the DNAME rewrite happens here. I don't see anywhere that a recursing server has the option to ignore the presence of DNAME RRsets. > For example, assume one cache, responding to a recursive request, obtains > the record "a.b.example. DNAME foo.bar.tld." and another cache > obtains "b.example. DNAME foo.bar.tld.", both generated from the record > "*.example. DNAME foo.bar.tld." by an authoritative server. > > If the caches did DNAME rewrites based on the cached DNAMEs, > queries for "sub.a.b.example. A" would be rewritten as "sub.foo.bar.tld. A" > by the former caching server and rewritten as "sub.a.foo.bar.tld. A" by > the latter. Coherency would be lost, and an operational nightmare > would ensue. "If [they] ... did" - I 1) don't see that there's an option not to do so, and 2) if this is an option, is it an implementation weakness/bug to do so? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue May 10 12:23:09 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09904 for ; Tue, 10 May 2005 12:23:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVXTK-0007Fk-5I for namedroppers-data@psg.com; Tue, 10 May 2005 16:20:38 +0000 Received: from [192.96.22.18] (helo=citadel.cequrux.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DVXTH-0007Ej-68 for namedroppers@ops.ietf.org; Tue, 10 May 2005 16:20:36 +0000 Received: (from nobody@localhost) by citadel.cequrux.com (8.12.11/8.12.11) id j4AGKO0u053838 for ; Tue, 10 May 2005 18:20:24 +0200 (SAST) (envelope-from apb@cequrux.com) Received: by citadel.cequrux.com via recvmail id 53836; Tue, 10 May 2005 18:20:24 +0200 (SAST) X-Authentication-Warning: apb-laptoy.apb.alt.za: apb set sender to apb@cequrux.com using -f Date: Tue, 10 May 2005 18:20:23 +0200 From: Alan Barrett To: namedroppers@ops.ietf.org Subject: Re: * DNAME text in wcard Message-ID: <20050510162023.GG9155@apb-laptoy.apb.alt.za> References: <200505101520.j4AFKsiu007568@guava.araneus.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200505101520.j4AFKsiu007568@guava.araneus.fi> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 10 May 2005, Andreas Gustafsson wrote: > > Queries for "sub.a.b.example. A" will be rewritten as > > "sub.foo.bar.tld. A" by the former caching server and rewritten > > as "sub.a.foo.bar.tld. A" by the latter. Coherency is lost, an > > operational nightmare ensues. > > At the risk of repeating myself: caching servers that actually follow > the algorithm in RFC2672 section 4.2, "Processing by Resolvers", will > _not_ perform the rewrites described in the last paragraph. RFC2672 section 4.2 step 1 says "see if the answer is in local information, and if so return it to the client". Step 4d says "... cache the DNAME ...". I believe that the clear intent of these two rules is to allow the cache to use a cached DNAME to perform CNAME synthesis (and then to use the CNAME to to answer the query). Any reading of this algorithm that prohibits treating a cached DNAME as suitable "local information" for the purposes of step 1 would also appear to prohibit treating a cached CNAME as suitable "local information" for step 1. Since we know that it is common practice to use cached CNAMES in that way, such a prohibition would be absurd, and was clearly not intended by the authors of RFC2672. > Caching servers that do perform such rewrites should be fixed, not > declared correct by saying that the rewrite "will" happen. No, if there is any scope for misinterpretation of the algorithm in RFC2672 section 4.2, the algorithm should be clarified. Use of DNAMES for synthesis by caches was always intended to be part of the spec as I understood it. --apb (Alan Barrett) -- to unsubscribe send a message to namedroppers-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 May 10 12:40:04 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13843 for ; Tue, 10 May 2005 12:40:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVXjc-0008YL-HQ for namedroppers-data@psg.com; Tue, 10 May 2005 16:37:28 +0000 Received: from [192.96.22.18] (helo=citadel.cequrux.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DVXja-0008Xr-1A for namedroppers@ops.ietf.org; Tue, 10 May 2005 16:37:27 +0000 Received: (from nobody@localhost) by citadel.cequrux.com (8.12.11/8.12.11) id j4AGbMuX054270 for ; Tue, 10 May 2005 18:37:22 +0200 (SAST) (envelope-from apb@cequrux.com) Received: by citadel.cequrux.com via recvmail id 54268; Tue, 10 May 2005 18:37:21 +0200 (SAST) X-Authentication-Warning: apb-laptoy.apb.alt.za: apb set sender to apb@cequrux.com using -f Date: Tue, 10 May 2005 18:37:20 +0200 From: Alan Barrett To: namedroppers@ops.ietf.org Subject: Re: * DNAME text in wcard Message-ID: <20050510163720.GH9155@apb-laptoy.apb.alt.za> Reply-To: namedroppers@ops.ietf.org References: <200505101520.j4AFKsiu007568@guava.araneus.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 10 May 2005, Edward Lewis wrote: > Now I am more confused than before. You described the failure case correctly before. I agree with you that the best solution would to prohibit (or at least strongly advise against) wildcard DNAME records. --apb (Alan Barrett) -- to unsubscribe send a message to namedroppers-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 May 10 13:54:57 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26764 for ; Tue, 10 May 2005 13:54:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVYsv-000EIt-ML for namedroppers-data@psg.com; Tue, 10 May 2005 17:51:09 +0000 Received: from [204.152.189.154] (helo=gusto.araneus.fi) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DVYsh-000EGi-64 for namedroppers@ops.ietf.org; Tue, 10 May 2005 17:50:55 +0000 Received: from guava.araneus.fi ([195.238.197.162]) by gusto.araneus.fi (8.12.10/8.12.10) with ESMTP id j4AHoiqX014574; Tue, 10 May 2005 10:50:45 -0700 (PDT) Received: from guava.araneus.fi (localhost [127.0.0.1]) by guava.araneus.fi (8.12.10/8.11.6) with ESMTP id j4AHoiLG025168; Tue, 10 May 2005 20:50:44 +0300 (EEST) Received: (from gson@localhost) by guava.araneus.fi (8.12.10/8.12.6/Submit) id j4AHohCK015472; Tue, 10 May 2005 20:50:43 +0300 (EEST) Date: Tue, 10 May 2005 20:50:43 +0300 (EEST) Message-Id: <200505101750.j4AHohCK015472@guava.araneus.fi> To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: * DNAME text in wcard In-Reply-To: References: <200505101520.j4AFKsiu007568@guava.araneus.fi> X-Mailer: VM 7.17 under Emacs 21.4.1 From: gson@araneus.fi (Andreas Gustafsson) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward Lewis writes: > > To preserve the coherency of the DNS, it is important that > > caching DNS servers do not themselves perform DNAME rewrites > > based on such cached DNAME RRsets. > > What do you mean by "such cached DNAME RRsets?" Are you referring to > DNAME RRsets cached upon receipt having been synthesized by the > sender? How could the recursive server tell them apart? I have a short answer and a long answer... The short answer is that if you follow the algorithm in RFC2672 section 4.2 literally, you will not do rewrites based on _any_ cached DNAMEs. The long answer is that in some cases you actually can tell whether the DNAME could have been synthesized or not, and I don't want to explicitly outlaw implementations taking advantage of that. Specifically, a DNAME cached in step 4.d of the algorithm rather than step 4.a can't be synthetic, and I suspect DNSSEC may allow you to tell in other cases, too. But to keep things simple, let's restrict the discussion to the "short answer" case. > I was under the assumption that RFC 2672 "directs" caches to do DNAME > rewrites... > > In 4.2/step 4.d, this lays the received DNAME in the cache. > > d. if the response shows a DNAME and that is not the answer > itself, cache the DNAME. No - the caching happens in step 4.a. The DNAME must be an answer to the question, because that is the only case where wildcard synthesis of DNAMEs happens in the authoritative server. > In 4.2/step 1, a later query sees: > > A resolver or a server providing recursive service must be modified > to treat a DNAME as somewhat analogous to a CNAME. The resolver > algorithm of [DNSCF] section 5.3.3 is modified to renumber step 4.d > as 4.e and insert a new 4.d. The complete algorithm becomes: > > 1. See if the answer is in local information, and if so return it to > the client. > > I would interpret this as saying that the DNAME rewrite happens here. I would not interpret it that way. The cached DNAME is not "the answer" - its name does not match the QNAME, and its type does not match the QTYPE. The answer simply is not in "local information" in this case, and we continue to step 2. > I don't see anywhere that a recursing server has the option to ignore > the presence of DNAME RRsets. It's not a question of ignoring them - it's a question of not looking for them. In section 4.2, there is no mention of looking for a DNAME at the "last node matched" as there is in section 4.1. > > If the caches did DNAME rewrites based on the cached DNAMEs, > > queries for "sub.a.b.example. A" would be rewritten as "sub.foo.bar.tld. A" > > by the former caching server and rewritten as "sub.a.foo.bar.tld. A" by > > the latter. Coherency would be lost, and an operational nightmare > > would ensue. > > "If [they] ... did" - I 1) don't see that there's an option not to do > so, and 2) if this is an option, is it an implementation weakness/bug > to do so? I don't see that there is an option to _do_ the rewrite, and I would say that an implementation that does the rewrite has a bug. -- Andreas Gustafsson, gson@araneus.fi -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue May 10 14:23:02 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29378 for ; Tue, 10 May 2005 14:23:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVZLy-000HDm-1y for namedroppers-data@psg.com; Tue, 10 May 2005 18:21:10 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DVZLv-000HDF-Qx for namedroppers@ops.ietf.org; Tue, 10 May 2005 18:21:08 +0000 Received: from [10.31.32.227] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j4AIKv30029723; Tue, 10 May 2005 14:20:58 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200505101750.j4AHohCK015472@guava.araneus.fi> References: <200505101520.j4AFKsiu007568@guava.araneus.fi> <200505101750.j4AHohCK015472@guava.araneus.fi> Date: Tue, 10 May 2005 14:20:59 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: * DNAME text in wcard Cc: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 20:50 +0300 5/10/05, Andreas Gustafsson wrote: >Edward Lewis writes: >> I would interpret this as saying that the DNAME rewrite happens here. > >I would not interpret it that way. The cached DNAME is not "the Ahh, the very symptom of a bad specification. I.e., no "you're wrong" but instead an exchange of "would" and "would not" interpret. >answer" - its name does not match the QNAME, and its type does not >match the QTYPE. The answer simply is not in "local information" >in this case, and we continue to step 2. I don't want to travel down the path of fixing that RFC now, I'll move on. >> I don't see anywhere that a recursing server has the option to ignore >> the presence of DNAME RRsets. > >It's not a question of ignoring them - it's a question of not looking >for them. In section 4.2, there is no mention of looking for a DNAME >at the "last node matched" as there is in section 4.1. Granted. I understand. Unlike CNAMEs, which are at the sought name, DNAMEs would be sitting higher up in the domain tree. There's no reason a lookup (note, not a search) would have anything but tunnel vision for the sought data. My assumption has been that the intent of the DNAME RFC was to have recursing servers modify their "lookup" algorithm to include a "search" for the DNAME. Based on this assumption, I found the idea of the DNAME abhorrent (hence the "who hates the DNAME" subject line). However, my assumption still holds - that it is the intent of the DNAME in a cache to "cut off" further queries to the authoritative server for the same zone. Does anyone familiar with the debate back then have an answer to the question of "what was the intent?" I wasn't involved in the work then, I was still stuck on DNSSEC-only issues. >> > If the caches did DNAME rewrites based on the cached DNAMEs, >> > queries for "sub.a.b.example. A" would be rewritten as >>"sub.foo.bar.tld. A" >> > by the former caching server and rewritten as "sub.a.foo.bar.tld. A" by >> > the latter. Coherency would be lost, and an operational nightmare >> > would ensue. >> >> "If [they] ... did" - I 1) don't see that there's an option not to do >> so, and 2) if this is an option, is it an implementation weakness/bug >> to do so? > >I don't see that there is an option to _do_ the rewrite, and I would >say that an implementation that does the rewrite has a bug. Hmmmm. Any other opinions on this? (I mean other implementers who disagree?) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue May 10 19:56:42 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05402 for ; Tue, 10 May 2005 19:56:41 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVeWi-000IHl-U3 for namedroppers-data@psg.com; Tue, 10 May 2005 23:52:36 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DVeWh-000IHS-96 for namedroppers@ops.ietf.org; Tue, 10 May 2005 23:52:35 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 44C65677F6 for ; Tue, 10 May 2005 23:52:33 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id j4AMKnuj015414; Wed, 11 May 2005 08:20:50 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200505102220.j4AMKnuj015414@drugs.dv.isc.org> To: Edward Lewis Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: * DNAME text in wcard In-reply-to: Your message of "Tue, 10 May 2005 14:20:59 -0400." Date: Wed, 11 May 2005 08:20:49 +1000 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > However, my assumption still holds - that it is the intent of the > DNAME in a cache to "cut off" further queries to the authoritative > server for the same zone. > > Does anyone familiar with the debate back then have an answer to the > question of "what was the intent?" I wasn't involved in the work > then, I was still stuck on DNSSEC-only issues. The intent was to make/let caches synthesis the result. It is also clear from the text as this restriction would not be needed otherwise. 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. This rule assures predictable results when a DNAME record is cached by a server which is not authoritative for the record's zone. It MUST be enforced when authoritative zone data is loaded. Together with the rules for DNS zone authority [DNSCLR] it implies that DNAME and NS records can only coexist at the top of a zone which has only one node. -- 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 May 10 20:11:33 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06206 for ; Tue, 10 May 2005 20:11:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVen8-000KOu-Gl for namedroppers-data@psg.com; Wed, 11 May 2005 00:09:34 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DVen7-000KOa-4m for namedroppers@ops.ietf.org; Wed, 11 May 2005 00:09:33 +0000 Received: from [10.31.32.227] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j4B09Jhr031347; Tue, 10 May 2005 20:09:20 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200505102220.j4AMKnuj015414@drugs.dv.isc.org> References: <200505102220.j4AMKnuj015414@drugs.dv.isc.org> Date: Tue, 10 May 2005 20:09:24 -0400 To: Mark Andrews From: Edward Lewis Subject: Re: * DNAME text in wcard Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 8:20 +1000 5/11/05, Mark Andrews wrote: >> However, my assumption still holds - that it is the intent of the >> DNAME in a cache to "cut off" further queries to the authoritative >> server for the same zone. >> >> Does anyone familiar with the debate back then have an answer to the >> question of "what was the intent?" I wasn't involved in the work >> then, I was still stuck on DNSSEC-only issues. > > The intent was to make/let caches synthesis the result. It is > also clear from the text as this restriction would not be > needed otherwise. > > 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. > > This rule assures predictable results when a DNAME record is cached > by a server which is not authoritative for the record's zone. It > MUST be enforced when authoritative zone data is loaded. Together > with the rules for DNS zone authority [DNSCLR] it implies that DNAME > and NS records can only coexist at the top of a zone which has only > one node. But that does not rule out '* DNAME'. I thought it did for a while, that was before Niall's haunting message came back at me for one more 'boo.' You see, "*." won't ever generate a descendant of itself, just certain descendents of . But wait, I suppose there is one contorted way in which "this rule" does outlaw '* DNAME' and that is because, ahem, let me try some algebra... Let the wild card domain name be "*.A" Let there be some label, B, that is not an immediate descendent of A. Collarary 1 - there exists a label C that does not exist that is a descendent of the B (which also does not exist). Since '*.A DNAME' can synthesize both 'C.B.A. DNAME' and 'B.A. DNAME' in violation of "this rule" then "*.A DNAME" cannot be allowed unless there are is no way to find two labels below A. (Latter added because a domain name has a fixed upper bound on length.) Eh? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue May 10 20:34:43 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07827 for ; Tue, 10 May 2005 20:34:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVf8a-000MDQ-Ti for namedroppers-data@psg.com; Wed, 11 May 2005 00:31:44 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DVf8X-000MCv-0p for namedroppers@ops.ietf.org; Wed, 11 May 2005 00:31:41 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 1E97D677EF for ; Wed, 11 May 2005 00:31:39 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.1/8.13.1) with ESMTP id j4B0Us17025815; Wed, 11 May 2005 10:30:54 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200505110030.j4B0Us17025815@drugs.dv.isc.org> To: Edward Lewis Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: * DNAME text in wcard In-reply-to: Your message of "Tue, 10 May 2005 20:09:24 -0400." Date: Wed, 11 May 2005 10:30:54 +1000 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > At 8:20 +1000 5/11/05, Mark Andrews wrote: > >> However, my assumption still holds - that it is the intent of the > >> DNAME in a cache to "cut off" further queries to the authoritative > >> server for the same zone. > >> > >> Does anyone familiar with the debate back then have an answer to the > >> question of "what was the intent?" I wasn't involved in the work > >> then, I was still stuck on DNSSEC-only issues. > > > > The intent was to make/let caches synthesis the result. It is > > also clear from the text as this restriction would not be > > needed otherwise. > > > > 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. > > > > This rule assures predictable results when a DNAME record is cached > > by a server which is not authoritative for the record's zone. It > > MUST be enforced when authoritative zone data is loaded. Together > > with the rules for DNS zone authority [DNSCLR] it implies that DNAME > > and NS records can only coexist at the top of a zone which has only > > one node. > > But that does not rule out '* DNAME'. I thought it did for a while, > that was before Niall's haunting message came back at me for one more > 'boo.' You see, "*." won't ever generate a descendant of > itself, just certain descendents of . > > But wait, I suppose there is one contorted way in which "this rule" > does outlaw '* DNAME' and that is because, ahem, let me try some > algebra... > > Let the wild card domain name be "*.A" Let there be some label, B, > that is not an immediate descendent of A. Collarary 1 - there exists > a label C that does not exist that is a descendent of the B (which > also does not exist). Since '*.A DNAME' can synthesize both 'C.B.A. > DNAME' and 'B.A. DNAME' in violation of "this rule" then "*.A DNAME" > cannot be allowed unless there are is no way to find two labels below > A. (Latter added because a domain name has a fixed upper bound on > length.) > > Eh? Why are we argueing about whether "* DNAME" is already prohibited or not? The existing text is obviously not clear enough if it is there and we need text to make it explictly clear that "* DNAME" is to be rejected at load/update time. There are also other things that need to be addressed when the DS review comes up. (e.g. does a DNAME occult data when added via UPDATE in a similar way as NS occults data when added via UPDATE. BIND 9 does this but it is definitely not clear if this is correct or not though it does fit the spirit of the UPDATE spec. Can the chairs at this question to the issue tracker so that it doesn't get lost please.) Now you asked a question about intent. Do you agree that the above text makes the intent clear or not. 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 Tue May 10 22:37:37 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14939 for ; Tue, 10 May 2005 22:37:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVh1o-0006ui-An for namedroppers-data@psg.com; Wed, 11 May 2005 02:32:52 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DVh1m-0006uE-F9 for namedroppers@ops.ietf.org; Wed, 11 May 2005 02:32:50 +0000 Received: from [10.31.32.227] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j4B2WaI1031820; Tue, 10 May 2005 22:32:37 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200505110030.j4B0Us17025815@drugs.dv.isc.org> References: <200505110030.j4B0Us17025815@drugs.dv.isc.org> Date: Tue, 10 May 2005 22:32:39 -0400 To: Mark Andrews From: Edward Lewis Subject: Re: * DNAME text in wcard Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 10:30 +1000 5/11/05, Mark Andrews wrote: > Why are we argueing about whether "* DNAME" is already prohibited > or not? The existing text is obviously not clear enough if it is > there and we need text to make it explictly clear that "* DNAME" > is to be rejected at load/update time. There are also other things > that need to be addressed when the DS review comes up. (e.g. does > a DNAME occult data when added via UPDATE in a similar way as NS > occults data when added via UPDATE. BIND 9 does this but it is > definitely not clear if this is correct or not though it does fit > the spirit of the UPDATE spec. Can the chairs at this question > to the issue tracker so that it doesn't get lost please.) > > Now you asked a question about intent. Do you agree that the > above text makes the intent clear or not. Remember that my effort is to edit a wildcard clarifications document. One of the unclear points is what does it mean for a wildcard to be a DNAME record. The need to clarify this empirically demonstrated in the lengthy discussions on why '* DNAME' is a bad idea. Perhaps one or a few people have seen this clearly, but apparently the knowledge is not widespread. As to your last sentence, my answer is, well, truthfully, "huh, what?" What are you asking? ;) I'm not sure what you mean at all, in addition to the "or not" part of the sentence. (The impact of DNAME on UPDATE isn't of concern for the wildcard clarify document.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed May 11 04:38:49 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13461 for ; Wed, 11 May 2005 04:38:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVmfi-0008Gc-Br for namedroppers-data@psg.com; Wed, 11 May 2005 08:34:26 +0000 Received: from [204.152.189.154] (helo=gusto.araneus.fi) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DVmfe-0008GK-UL for namedroppers@ops.ietf.org; Wed, 11 May 2005 08:34:23 +0000 Received: from guava.araneus.fi ([195.238.197.162]) by gusto.araneus.fi (8.12.10/8.12.10) with ESMTP id j4B8XnqX025207; Wed, 11 May 2005 01:33:51 -0700 (PDT) Received: from guava.araneus.fi (localhost [127.0.0.1]) by guava.araneus.fi (8.12.10/8.11.6) with ESMTP id j4B8XsLG010697; Wed, 11 May 2005 11:33:54 +0300 (EEST) Received: (from gson@localhost) by guava.araneus.fi (8.12.10/8.12.6/Submit) id j4B8Xqe6003740; Wed, 11 May 2005 11:33:52 +0300 (EEST) Date: Wed, 11 May 2005 11:33:52 +0300 (EEST) Message-Id: <200505110833.j4B8Xqe6003740@guava.araneus.fi> To: Alan Barrett Cc: namedroppers@ops.ietf.org Subject: Re: * DNAME text in wcard In-Reply-To: <20050510162023.GG9155@apb-laptoy.apb.alt.za> References: <200505101520.j4AFKsiu007568@guava.araneus.fi> <20050510162023.GG9155@apb-laptoy.apb.alt.za> X-Mailer: VM 7.17 under Emacs 21.4.1 From: gson@araneus.fi (Andreas Gustafson) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Alan Barrett writes: > Any reading of this algorithm that prohibits treating a cached DNAME > as suitable "local information" for the purposes of step 1 would > also appear to prohibit treating a cached CNAME as suitable "local > information" for step 1. Good point. Looks like the use of cached CNAMEs _and_ DNAMEs is equally underspecified. -- Andreas Gustafsson, gson@araneus.fi -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed May 11 06:36:19 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20869 for ; Wed, 11 May 2005 06:36:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVoWh-000GqQ-FQ for namedroppers-data@psg.com; Wed, 11 May 2005 10:33:15 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DVoWg-000Gq6-83 for namedroppers@ops.ietf.org; Wed, 11 May 2005 10:33:14 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 949F62DE6E; Wed, 11 May 2005 12:33:11 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 931FB2DE6D for ; Wed, 11 May 2005 12:33:11 +0200 (CEST) Date: Wed, 11 May 2005 12:33:11 +0200 (CEST) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: namedroppers@ops.ietf.org Subject: rfc4035: missing text on empty-non-terminal proof Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk WG, RFC4035 lacks an example of 'empty non-terminal' (ENT) proof, nor does section 5.4 (Authenticated Denial of Existence), second bullet handle the case where a security-aware resolver encounters a NODATA because of ENT. Since this particular NODATA proof is different then normal NODATA proof, I've written a small erratum for section 5.4, listed below, and a addendum to section B.3 and C.3 (respectively labeled: B.3.1 and C.3.1). Comments are welcome, Thanks, Roy 5.4. Authenticated Denial of Existence **original text at second bullet: o If the requested RR name would appear after an authenticated NSEC RR's owner name and before the name listed in that NSEC RR's Next Domain Name field according to the canonical DNS name order defined in [RFC4034], then no RRsets with the requested name exist in the zone. However, it is possible that a wildcard could be used to match the requested RR owner name and type, so proving that the requested RRset does not exist also requires proving that no possible wildcard RRset exists that could have been used to generate a positive response. **suggested text for second bullet: o If the requested RR name would appear after an authenticated NSEC RR's owner name and before the name listed in that NSEC RR's Next Domain Name field according to the canonical DNS name order defined in [RFC4034], then no RRsets with the requested name exist in the zone. If the name listed in that NSEC RR's Next Domain Name field is a subdomain of the requested RR name, then the requested RR name is an empty non-terminal. Since the requested RR name implicitly exists, there is no need to prove the existence of a possible wildcard match. However, if the name listed in that NSEC RR's Next Domain Name field is not a subdomain of the requested RR name, it is possible that a wildcard could be used to match the requested RR owner name and type, so proving that the requested RRset does not exist also requires proving that no possible wildcard RRset exists that could have been used to generate a positive response. B.3.1. No Data Error, Empty Non-terminal A "no data" response for an empty non-terminal. The NSEC RR proves that the name implicitly exists. It exists because a subdomain exists. ;; Header: QR AA DO RCODE=0 ;; ;; Question y.w.example. IN A ;; Answer ;; (empty) ;; Authority example. 3600 IN SOA ns1.example. bugs.x.w.example. ( 1081539377 3600 300 3600000 3600 ) example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( 20040409183619 38519 example. ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB jV7j86HyQgM5e7+miRAz8V01b0I= ) x.w.example. 3600 NSEC x.y.w.example. MX RRSIG NSEC x.w.example. 3600 RRSIG NSEC 5 3 3600 20040509183619 ( 20040409183619 38519 example. aRbpHftxggzgMXdDlym9SsADqMZovZZl2QWK vw8J0tZEUNQByH5Qfnf5N1FqH/pS46UA7A4E mcWBN9PUA1pdPY6RVeaRlZlCr1IkVctvbtaI NJuBba/VHm+pebTbKcAPIvL9tBOoh+to1h6e IjgiM8PXkBQtxPq37wDKALkyn7Q= ) ;; Additional ;; (empty) C.3.1. No Data Error, Empty Non-terminal The query in Appendix B.3.1 returned an NSEC RR that proves that the requested name implicitly exists. The value of the Next Owner Name of the NSEC is a subdomain of the QNAME. The negative reply is authenticated by verifying the NSEC RR. The NSEC RR is authenticated in a manner identical to that of the MX RRset discussed above. Since the NSEC record proves the existence of the requested name, there is no need to prove existence of a wildcard RR. -- to unsubscribe send a message to namedroppers-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 May 11 15:52:48 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14003 for ; Wed, 11 May 2005 15:52:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVxBj-0006pN-7W for namedroppers-data@psg.com; Wed, 11 May 2005 19:48:11 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DVxBi-0006p7-1W for namedroppers@ops.ietf.org; Wed, 11 May 2005 19:48:10 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13606; Wed, 11 May 2005 15:48:05 -0400 (EDT) Message-Id: <200505111948.PAA13606@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-wcard-clarify-06.txt Date: Wed, 11 May 2005 15:48:05 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : The Role of Wildcards in the Domain Name System Author(s) : E. Lewis Filename : draft-ietf-dnsext-wcard-clarify-06.txt Pages : 0 Date : 2005-5-11 This is an update to the wildcard definition of RFC 1034. The interaction with wildcards and CNAME is changed, an error condition removed, and the words defining some concepts central to wildcards are changed. The overall goal is not to change wildcards, but to refine the definition of RFC 1034. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-wcard-clarify-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-wcard-clarify-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-wcard-clarify-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-11160200.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-wcard-clarify-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-wcard-clarify-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-11160200.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 May 11 16:14:18 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19530 for ; Wed, 11 May 2005 16:14:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVxZ8-0009B1-KP for namedroppers-data@psg.com; Wed, 11 May 2005 20:12:22 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DVxZ6-0009Ai-KU for namedroppers@ops.ietf.org; Wed, 11 May 2005 20:12:21 +0000 Received: from [10.31.32.227] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j4BKCATS035952; Wed, 11 May 2005 16:12:12 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200505111948.PAA13606@ietf.org> References: <200505111948.PAA13606@ietf.org> Date: Wed, 11 May 2005 16:12:11 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: I-D ACTION:draft-ietf-dnsext-wcard-clarify-06.txt Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 15:48 -0400 5/11/05, Internet-Drafts@ietf.org wrote: > Filename : draft-ietf-dnsext-wcard-clarify-06.txt >http://www.ietf.org/internet-drafts/draft-ietf-dnsext-wcard-clarify-06.txt The substantial differences are in section 4 (NS, DNAME, etc.). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu May 12 05:51:06 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10128 for ; Thu, 12 May 2005 05:51:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DWAG2-000EyI-5D for namedroppers-data@psg.com; Thu, 12 May 2005 09:45:30 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DWAFx-000Exy-CO for namedroppers@ops.ietf.org; Thu, 12 May 2005 09:45:25 +0000 Received: by postman.ripe.net (Postfix, from userid 4008) id 73A3024CA9; Thu, 12 May 2005 11:45:24 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 8B53E24ED5; Thu, 12 May 2005 11:45:21 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id j4C9jL45000330; Thu, 12 May 2005 11:45:21 +0200 Date: Thu, 12 May 2005 11:45:21 +0200 From: "Olaf M. Kolkman" To: Edward Lewis Cc: namedroppers@ops.ietf.org, ed.lewis@neustar.biz Subject: Re: I-D ACTION:draft-ietf-dnsext-wcard-clarify-06.txt Message-Id: <20050512114521.2f6d8f1b.olaf@ripe.net> In-Reply-To: References: <200505111948.PAA13606@ietf.org> Organization: RIPE NCC X-Mailer: Sylpheed version 1.0.3 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00,BIZ_TLD X-RIPE-Spam-Status: N 0.053597 / -3.6 X-RIPE-Signature: ce5530914d4026c2dfe83881dbf6df26 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,BIZ_TLD autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 11 May 2005 16:12:11 -0400 Edward Lewis wrote: > At 15:48 -0400 5/11/05, Internet-Drafts@ietf.org wrote: > > > Filename : draft-ietf-dnsext-wcard-clarify-06.txt > > >http://www.ietf.org/internet-drafts/draft-ietf-dnsext-wcard-clarify-06.txt > > The substantial differences are in section 4 (NS, DNAME, etc.). Also see: http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-wcard-clarify/ which provides a very nice interface for tracking the changes. -- 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 Thu May 12 09:11:26 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21813 for ; Thu, 12 May 2005 09:11:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DWDPu-00045R-1Y for namedroppers-data@psg.com; Thu, 12 May 2005 13:07:54 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DWDPr-00044t-5F for namedroppers@ops.ietf.org; Thu, 12 May 2005 13:07:51 +0000 Received: from [10.31.32.227] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j4CD7gPg041185; Thu, 12 May 2005 09:07:43 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20050512114521.2f6d8f1b.olaf@ripe.net> References: <200505111948.PAA13606@ietf.org> <20050512114521.2f6d8f1b.olaf@ripe.net> Date: Thu, 12 May 2005 09:07:43 -0400 To: "Olaf M. Kolkman" From: Edward Lewis Subject: Re: I-D ACTION:draft-ietf-dnsext-wcard-clarify-06.txt Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,BIZ_TLD autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:45 +0200 5/12/05, Olaf M. Kolkman wrote: >On Wed, 11 May 2005 16:12:11 -0400 >Edward Lewis wrote: > >> At 15:48 -0400 5/11/05, Internet-Drafts@ietf.org wrote: >> >> > Filename : draft-ietf-dnsext-wcard-clarify-06.txt >> >> >http://www.ietf.org/internet-drafts/draft-ietf-dnsext-wcard-clarify-06.txt >> >> The substantial differences are in section 4 (NS, DNAME, etc.). > > >Also see: > http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-wcard-clarify/ >which provides a very nice interface for tracking the changes. Looks like I need to word wrap it again...the next edition will be only changes to that. (I thought the word wrap was 78 chars. Some tool told me 72 and I trimmed to that. Now this tool tells me some lines are 1 byte too long.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu May 12 09:11:44 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21844 for ; Thu, 12 May 2005 09:11:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DWDQ6-000475-U4 for namedroppers-data@psg.com; Thu, 12 May 2005 13:08:06 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DWDQ5-00046J-95 for namedroppers@ops.ietf.org; Thu, 12 May 2005 13:08:05 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id j4CD80KN002092; Thu, 12 May 2005 13:08:00 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id j4CD80Fr002089; Thu, 12 May 2005 13:08:00 GMT Date: Thu, 12 May 2005 13:08:00 +0000 From: bmanning@vacation.karoshi.com To: "Olaf M. Kolkman" Cc: Edward Lewis , namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-wcard-clarify-06.txt Message-ID: <20050512130800.GA1901@vacation.karoshi.com.> References: <200505111948.PAA13606@ietf.org> <20050512114521.2f6d8f1b.olaf@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050512114521.2f6d8f1b.olaf@ripe.net> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,BIZ_TLD, NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk for some reason, when i ask the ietf site for this doc, it claims it does not yet exist or has expired. :( --bill On Thu, May 12, 2005 at 11:45:21AM +0200, Olaf M. Kolkman wrote: > On Wed, 11 May 2005 16:12:11 -0400 > Edward Lewis wrote: > > > At 15:48 -0400 5/11/05, Internet-Drafts@ietf.org wrote: > > > > > Filename : draft-ietf-dnsext-wcard-clarify-06.txt > > > > >http://www.ietf.org/internet-drafts/draft-ietf-dnsext-wcard-clarify-06.txt > > > > The substantial differences are in section 4 (NS, DNAME, etc.). > > > Also see: > http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-wcard-clarify/ > which provides a very nice interface for tracking the changes. > > > -- 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 Thu May 12 09:27:41 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23110 for ; Thu, 12 May 2005 09:27:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DWDhG-0005RV-L9 for namedroppers-data@psg.com; Thu, 12 May 2005 13:25:50 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DWDhD-0005Qm-Gf for namedroppers@ops.ietf.org; Thu, 12 May 2005 13:25:48 +0000 Received: from [10.31.32.227] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j4CDPeLi041275; Thu, 12 May 2005 09:25:41 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20050512130800.GA1901@vacation.karoshi.com.> References: <200505111948.PAA13606@ietf.org> <20050512114521.2f6d8f1b.olaf@ripe.net> <20050512130800.GA1901@vacation.karoshi.com.> Date: Thu, 12 May 2005 09:25:40 -0400 To: bmanning@vacation.karoshi.com From: Edward Lewis Subject: Re: I-D ACTION:draft-ietf-dnsext-wcard-clarify-06.txt Cc: "Olaf M. Kolkman" , Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,BIZ_TLD autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk me too. I went to ftp.ietf.org via an olde-tyme ftp client, "cd internet-drafts" and did an mget on "*wcard*6*" and it was there. At 13:08 +0000 5/12/05, bmanning@vacation.karoshi.com wrote: >for some reason, when i ask the ietf site for this doc, it claims it does >not yet exist or has expired. :( > >--bill > >On Thu, May 12, 2005 at 11:45:21AM +0200, Olaf M. Kolkman wrote: >> On Wed, 11 May 2005 16:12:11 -0400 >> Edward Lewis wrote: >> >> > At 15:48 -0400 5/11/05, Internet-Drafts@ietf.org wrote: >> > >> > > Filename : draft-ietf-dnsext-wcard-clarify-06.txt >> > >> > >http://www.ietf.org/internet-drafts/draft-ietf-dnsext-wcard-clarify-06.txt >> > >> > The substantial differences are in section 4 (NS, DNAME, etc.). >> >> >> Also see: >> http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-wcard-clarify/ >> which provides a very nice interface for tracking the changes. >> >> >> -- 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: -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu May 12 16:06:23 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01291 for ; Thu, 12 May 2005 16:06:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DWJqy-00044q-CJ for namedroppers-data@psg.com; Thu, 12 May 2005 20:00:16 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DWJqx-00044c-Hk for namedroppers@ops.ietf.org; Thu, 12 May 2005 20:00:15 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28398; Thu, 12 May 2005 16:00:12 -0400 (EDT) Message-Id: <200505122000.QAA28398@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-bis-updates-00.txt Date: Thu, 12 May 2005 16:00:12 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Clarifications and Implementation Notes for DNSSECbis Author(s) : S. Weiler Filename : draft-ietf-dnsext-dnssec-bis-updates-00.txt Pages : 10 Date : 2005-5-12 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 possible DNSSECbis errata. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-bis-updates-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-bis-updates-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-bis-updates-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-12160255.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-bis-updates-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-bis-updates-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-12160255.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 May 12 16:14:09 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03873 for ; Thu, 12 May 2005 16:14:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DWK1Z-0005DA-Cs for namedroppers-data@psg.com; Thu, 12 May 2005 20:11:13 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DWK1X-0005Cg-Ee for namedroppers@ops.ietf.org; Thu, 12 May 2005 20:11:11 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j4CK7Jc8015083 for ; Thu, 12 May 2005 16:07:19 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA8OaaqD; Thu, 12 May 05 16:06:50 -0400 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j4CK7wjX025457; Thu, 12 May 2005 16:07:59 -0400 (EDT) Date: Thu, 12 May 2005 16:07:58 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@filbert To: Roy Arends cc: namedroppers@ops.ietf.org Subject: Re: rfc4035: missing text on empty-non-terminal proof In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Since this particular NODATA proof is different then normal NODATA proof, > I've written a small erratum for section 5.4, listed below, and a addendum > to section B.3 and C.3 (respectively labeled: B.3.1 and C.3.1). As a purely editorial matter, I've been trying to describe and fix the deficiencies of the bis docs without actually rewriting them in place. Being as this is the second issue with the non-existence proof section, though, I'm wondering if something more invasive may be needed in this case. The other issue is documented in Section 6 of dnssec-bis-updates-00 (you can see the discussion that led to this in the namedroppers archives from March 9-10) -- I'd be delighted to have specific suggestions as to how present both of these most clearly. Here's the text: 6. Clarifications on Non-Existence Proofs RFC4035 Section 5.4 slightly underspecifies the algorithm for checking non-existence proofs. In particular, the algorithm there might incorrectly allow the NSEC from the parent side of a zone cut to prove the non-existence of either other RRs at that name in the child zone or other names in the child zone. A parent-side delegation NSEC (one with the NS bit set, but no SOA bit set, and with a singer field that's shorter than the owner name) must not be used to assume non-existence of any RRs below that zone cut (both RRs at that ownername and at ownernames with more leading labels, no matter their content). -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu May 12 16:52:04 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01290 for ; Thu, 12 May 2005 16:06:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DWJr3-00045Q-V3 for namedroppers-data@psg.com; Thu, 12 May 2005 20:00:21 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DWJr3-00045B-6B for namedroppers@ops.ietf.org; Thu, 12 May 2005 20:00:21 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28413; Thu, 12 May 2005 16:00:18 -0400 (EDT) Message-Id: <200505122000.QAA28413@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-online-signing-00.txt Date: Thu, 12 May 2005 16:00:18 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Minimally Covering NSEC Records and DNSSEC On-line Signing Author(s) : S. Weiler, J. Ihren Filename : draft-ietf-dnsext-dnssec-online-signing-00.txt Pages : 10 Date : 2005-5-12 This document describes how to construct DNSSEC NSEC resource records that cover a smaller range of names than called for by RFC4034. By generating and signing these records on demand, authoritative name servers can effectively stop the disclosure of zone contents otherwise made possible by walking the chain of NSEC records in a signed zone. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-online-signing-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-online-signing-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-online-signing-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-12160306.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-online-signing-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-online-signing-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-12160306.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 May 12 19:21:51 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19614 for ; Thu, 12 May 2005 19:21:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DWMw7-000L5B-Cs for namedroppers-data@psg.com; Thu, 12 May 2005 23:17:47 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DWMw6-000L4z-Ov for namedroppers@ops.ietf.org; Thu, 12 May 2005 23:17:46 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j4CNDvIv002846 for ; Thu, 12 May 2005 19:13:57 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAQ5aOJf; Thu, 12 May 05 19:13:54 -0400 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j4CNFoVT000874 for ; Thu, 12 May 2005 19:15:50 -0400 (EDT) Date: Thu, 12 May 2005 19:15:50 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-dnssec-bis-updates-00.txt In-Reply-To: <200505122000.QAA28398@ietf.org> Message-ID: References: <200505122000.QAA28398@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This document has four new sections, starting with Section 6. Comments on the completeness and correctness of these new sections would be especially welcome. As always, proposed text is much appreciated. The new sections are: -- A clarification to the non-existence proof algorithm, based on the namedroppers discussion started by Roy Badami on March 9th. -- An error in the algorithm 1 key tag specification, found by Abhijit Hayatnagakar. -- A caution about the limits of local policy when multiple RRSIGs are present, inspired by Ron Aitchison. -- Corrections to the examples, provided by Roy Arends. In -01, I'm going to try to restructure the document to be more useful. Suggestions would be welcome. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon May 16 11:31:09 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26484 for ; Mon, 16 May 2005 11:31:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DXhTE-0009Le-Vp for namedroppers-data@psg.com; Mon, 16 May 2005 15:25:28 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DXhTC-0009LN-3q for namedroppers@ops.ietf.org; Mon, 16 May 2005 15:25:26 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 64389139A3 for ; Mon, 16 May 2005 15:25:25 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: dlv paper published in IEICE Transactions X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 16 May 2005 15:25:25 +0000 Message-Id: <20050516152525.64389139A3@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable in we see: --- IEICE Transactions on Communications 2005 E88-B(4):1326-1330; doi:10.1093/ietcom/e88-b.4.1326=20 Copyright =A9 2005 The Institute of Electronics, Information and Communication Engineers=20 Special Section on Internet Technology V -- Papers Preventing Child Neglect in DNSSECbis Using Lookaside Validation (DLV)*=20 Paul VIXIE (1) 1 The author is with Internet Systems Consortium, Redwood City, CA 94063-3110, USA. E-mail: vixie@isc.org=20 The DNSSECbis data model has key introduction follow the delegation chain, thus requiring a zone's parent to become secure before a zone itself can be secured. Ultimately this leads to non-deployability since the root zone will probably not be secured any time soon. We describe an early deployment aid for DNSSECbis whereby key introduction can be done via cooperating third parties.=20 Key Words: DNS, domain name system, DNS security, DNSSEC, secure DNS, Internet Manuscript received October 5, 2004.=20=20 =20 * This work was supported by Keio University. --- i regret that while this paper describes sam weiler's contributions (among others including david conrad, johan ihren, mark kosters, and others), it fails to cite sam's prior published work in this area, which was: S. Weiler, "Deploying DNSSEC Without a Signed Root", Technical report 1999-19, Information Networking Institute, Carnegie Mellon University, April 2004. i suppose there's no harm in publishing the draft isc technote on dlv, now. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon May 16 15:41:58 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00157 for ; Mon, 16 May 2005 15:41:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DXlPU-0001Zk-I4 for namedroppers-data@psg.com; Mon, 16 May 2005 19:37:52 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DXlPT-0001ZH-M7 for namedroppers@ops.ietf.org; Mon, 16 May 2005 19:37:51 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29472; Mon, 16 May 2005 15:37:48 -0400 (EDT) Message-Id: <200505161937.PAA29472@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-wcard-clarify-07.txt Date: Mon, 16 May 2005 15:37:48 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : The Role of Wildcards in the Domain Name System Author(s) : E. Lewis Filename : draft-ietf-dnsext-wcard-clarify-07.txt Pages : 0 Date : 2005-5-16 This is an update to the wildcard definition of RFC 1034. The interaction with wildcards and CNAME is changed, an error condition removed, and the words defining some concepts central to wildcards are changed. The overall goal is not to change wildcards, but to refine the definition of RFC 1034. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-wcard-clarify-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-wcard-clarify-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-wcard-clarify-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-16151918.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-wcard-clarify-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-wcard-clarify-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-16151918.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 May 17 16:09:07 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08844 for ; Tue, 17 May 2005 16:09:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DY8Hs-000Jm4-Et for namedroppers-data@psg.com; Tue, 17 May 2005 20:03:32 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DY8Hp-000JlM-8f for namedroppers@ops.ietf.org; Tue, 17 May 2005 20:03:29 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 885A233C33; Tue, 17 May 2005 21:03:26 +0100 (BST) Message-ID: <428A4DFE.2080700@algroup.co.uk> Date: Tue, 17 May 2005 21:03:10 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Olaf M. Kolkman" Cc: Edward Lewis , namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-wcard-clarify-06.txt References: <200505111948.PAA13606@ietf.org> <20050512114521.2f6d8f1b.olaf@ripe.net> In-Reply-To: <20050512114521.2f6d8f1b.olaf@ripe.net> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,BIZ_TLD autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Olaf M. Kolkman wrote: > On Wed, 11 May 2005 16:12:11 -0400 > Edward Lewis wrote: > > >>At 15:48 -0400 5/11/05, Internet-Drafts@ietf.org wrote: >> >> >>> Filename : draft-ietf-dnsext-wcard-clarify-06.txt >> >>>http://www.ietf.org/internet-drafts/draft-ietf-dnsext-wcard-clarify-06.txt >> >>The substantial differences are in section 4 (NS, DNAME, etc.). > > > > Also see: > http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-wcard-clarify/ > which provides a very nice interface for tracking the changes. Anyone who hasn't discovered wdiff needs to :-) -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed May 18 10:34:28 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26462 for ; Wed, 18 May 2005 10:34:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DYPY2-000Cyg-Cq for namedroppers-data@psg.com; Wed, 18 May 2005 14:29:22 +0000 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DYPY1-000CyR-Ef for namedroppers@ops.ietf.org; Wed, 18 May 2005 14:29:21 +0000 Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j4IET4DN019323 for ; Wed, 18 May 2005 10:29:04 -0400 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id j4IESD6u016998 for ; Wed, 18 May 2005 10:28:13 -0400 (EDT) From: "Scott Rose" To: Subject: RE:I-D ACTION:draft-ietf-dnsext-dnssec-bis-updates-00.txt Date: Wed, 18 May 2005 10:28:14 -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: <200505122000.QAA28398@ietf.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I finally had a chance to read over the draft, and it seems like the start of a good catch-all of some grey areas and mistakes in the DNSSECbis docs. One question on section 2 (last paragraph): Shouldn't it be the validator discarding DS RR's with unknown algorithms? Minor terminology bit of seperation of functions (resolver/validator). Scott > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of > Internet-Drafts@ietf.org > Sent: Thursday, May 12, 2005 4:00 PM > To: i-d-announce@ietf.org > Cc: namedroppers@ops.ietf.org > Subject: {Blocked Content} I-D > ACTION:draft-ietf-dnsext-dnssec-bis-updates-00.txt > > > Warning: This message has had one or more attachments removed > Warning: (not named). > Warning: Please read the "VirusWarning.txt" attachment(s) for > more information. > > 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) : S. Weiler > Filename : draft-ietf-dnsext-dnssec-bis-updates-00.txt > Pages : 10 > Date : 2005-5-12 > > 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 possible DNSSECbis > errata. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-bis-u > pdates-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the > body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with > the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-dnsext-dnssec-bis-updates-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-dnsext-dnssec-bis-updates-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -- to unsubscribe send a message to namedroppers-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 May 18 13:09:49 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13499 for ; Wed, 18 May 2005 13:09:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DYRxm-00022Y-Pl for namedroppers-data@psg.com; Wed, 18 May 2005 17:04:06 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DYRxk-00022F-Bh for namedroppers@ops.ietf.org; Wed, 18 May 2005 17:04:04 +0000 Received: by postman.ripe.net (Postfix, from userid 4008) id 46C2B25693; Wed, 18 May 2005 18:43:24 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 4E53425170 for ; Wed, 18 May 2005 18:43:23 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id j4IGhM45030705 for ; Wed, 18 May 2005 18:43:22 +0200 Received: (from olaf@localhost) by x50.ripe.net (8.12.10/8.12.6) id j4IGhMNO006969 for namedroppers@ops.ietf.org; Wed, 18 May 2005 18:43:22 +0200 Received: from [192.18.98.36] (helo=brmea-mail-4.sun.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DYRRz-000Lwt-Dq for namedroppers@ops.ietf.org; Wed, 18 May 2005 16:31:15 +0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j4IGV60R020571; Wed, 18 May 2005 10:31:06 -0600 (MDT) Received: from minas-tirith.Central.Sun.COM (minas-tirith.Central.Sun.COM [129.153.128.154]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j4IGV2EN027678; Wed, 18 May 2005 10:31:02 -0600 (MDT) Received: from minas-tirith.Central.Sun.COM (localhost [127.0.0.1]) by minas-tirith.Central.Sun.COM (8.12.11+Sun/8.12.11) with ESMTP id j4IGWftg010777; Wed, 18 May 2005 11:32:41 -0500 (CDT) Received: (from rmesta@localhost) by minas-tirith.Central.Sun.COM (8.12.11+Sun/8.12.11/Submit) id j4IGWdxZ010776; Wed, 18 May 2005 11:32:39 -0500 (CDT) Date: Wed, 18 May 2005 11:32:39 -0500 From: Rick Mesta To: "Olaf M. Kolkman" Cc: namedroppers@ops.ietf.org, Spencer.Shepler@sun.com, beepy@netapp.com, ogud@ogud.com, okolkman@ripe.net, Rick Mesta , nfsv4@ietf.org Subject: Re: draft-mesta-nfs4id-dns-rr-01 Message-ID: <20050518163239.GA10343@minas-tirith.central.sun.com> Reply-To: Rick Mesta References: <20050509150200.28002bb0.olaf@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050509150200.28002bb0.olaf@ripe.net> User-Agent: Mutt/1.4.2.1i X-RIPE-Spam-Tests: BAYES_00 X-RIPE-Spam-Status: N 0.006396 / -2.6 X-RIPE-Signature: 096148df42b3caae3057945f444661af X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: This post needed manual approval. Either it was posted by a non-subscribed address, or the posting was too large ( > 20000bytes ) for this list. With the massive amount of spam, it is easy to miss and therefore delete posts that need manual approval. Please use your subscribed address to post, or shorten your postings by using links instead of attachments. ] Hi Olaf, And thx for posting to the alias =:), On Mon, May 09, 2005 at 03:02:00PM +0200, Olaf M. Kolkman wrote: | | | Dear colleagues, | | | Rick Mesta has recently posted the following I-D: | A DNS RR for NFSv4 ID Domains | draft-mesta-nfs4id-dns-rr-01 | | The document would benefit from some review by the DNS community. | | I've had some private communication with the editor and one of the issues | that came up during the conversation was that the NFS client is supposed | to know its "default domain". | | (The "default domain" being what e.g. the res_init() function would | return). | | AFAIK the "default domain" is not something that is part of the DNS | specs but I am afraid I am overlooking something. What would be a | proper specification or reference for the "default domain"? In case there is no bonafide DNS specification DNS for a "default domain", I wonder if having "default domain" be loosely defined as being an Operating Environment artifact (e.g. the configured /etc/resolv.conf domain, for UNIX type systems) would be good enough for a specification. Thoughts ? rick | | Please try to CC the list on issues that are within scope and try to | keep out-of-scope issues off list. | | Thanks a lot. | | -- 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 Thu May 19 14:24:55 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02926 for ; Thu, 19 May 2005 14:24:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DYpc3-000OjL-QE for namedroppers-data@psg.com; Thu, 19 May 2005 18:19:15 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DYpc1-000Oj7-Vl for namedroppers@ops.ietf.org; Thu, 19 May 2005 18:19:14 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j4JIFMUp010407 for ; Thu, 19 May 2005 14:15:22 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAGqaytu; Thu, 19 May 05 14:15:19 -0400 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j4JIHEOH015907 for ; Thu, 19 May 2005 14:17:15 -0400 (EDT) Date: Thu, 19 May 2005 14:17:14 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org Subject: RE:I-D ACTION:draft-ietf-dnsext-dnssec-bis-updates-00.txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > One question on section 2 (last paragraph): Shouldn't it be the validator > discarding DS RR's with unknown algorithms? Minor terminology bit of > seperation of functions (resolver/validator). Probably so. I'll make that change. As before, suggestions about what to do with the validation algorithm discussion would be most welcome -- see Roy's message with Subject: "rfc4035: missing text on empty-non-terminal proof" and my follow-up. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu May 19 14:58:42 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07195 for ; Thu, 19 May 2005 14:58:41 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DYqBa-0001JL-Ip for namedroppers-data@psg.com; Thu, 19 May 2005 18:55:58 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DYqBX-0001Iw-QP for namedroppers@ops.ietf.org; Thu, 19 May 2005 18:55:55 +0000 Received: from [10.131.244.227] ([::ffff:172.25.170.10]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.verisignlabs.com with esmtp; Thu, 19 May 2005 14:55:54 -0400 id 0059464F.428CE13A.00007633 Message-ID: <428CE13A.4070503@verisignlabs.com> Date: Thu, 19 May 2005 14:55:54 -0400 From: David Blacka Organization: VeriSign, Inc. User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: validating a qtype=* response X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit It occurred to me that is isn't totally obvious how a DNSSEC validator should validate a (non rcode=3) response to a qtype=* (or qtype=ANY, if you will) query. I can think of 2 approaches: 1. Verify any answer section rrsets (that match qname+qclass, that is). If there are no answer section rrsets, validate via a authority section NSEC that qname is, in fact, an empty-non-terminal. Validate the authority section as normal. 2. Don't validate it at all, don't set the AD bit. Opinions? #1 makes the most sense to me, but I see an appeal in #2 (less work, what is the qtype=* query used for anyway?). Does this need additional clarification? I'm thinking that this sort of thing might go into Sam's bis-updates document, but it could've been obvious to everyone else. -- David Blacka Sr. Engineer VeriSign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu May 19 15:42:19 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14100 for ; Thu, 19 May 2005 15:42:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DYqry-0004Gf-1y for namedroppers-data@psg.com; Thu, 19 May 2005 19:39:46 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DYqrw-0004GQ-9l for namedroppers@ops.ietf.org; Thu, 19 May 2005 19:39:44 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13806; Thu, 19 May 2005 15:39:41 -0400 (EDT) Message-Id: <200505191939.PAA13806@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-interop3597-02.txt Date: Thu, 19 May 2005 15:39:41 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : RFC 3597 Interoperability Report Author(s) : J. Schlyter Filename : draft-ietf-dnsext-interop3597-02.txt Pages : 6 Date : 2005-5-19 This memo documents the result from the RFC 3597 (Handling of Unknown DNS Resource Record Types) interoperability testing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-interop3597-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-interop3597-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-interop3597-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-19153406.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-interop3597-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-interop3597-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-19153406.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 May 19 16:03:58 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20563 for ; Thu, 19 May 2005 16:03:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DYrDM-0006CR-6G for namedroppers-data@psg.com; Thu, 19 May 2005 20:01:52 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DYrDL-0006C9-6R for namedroppers@ops.ietf.org; Thu, 19 May 2005 20:01:51 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j4JK1fRo080139; Thu, 19 May 2005 16:01:42 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <428CE13A.4070503@verisignlabs.com> References: <428CE13A.4070503@verisignlabs.com> Date: Thu, 19 May 2005 16:01:53 -0400 To: David Blacka From: Edward Lewis Subject: Re: validating a qtype=* response Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I'm going to top-post this since it's a general opinion. From what I see, the AD bit is set when the sender thinks all data in the Answer and Authority sections are authentic. I didn't see any mention of relevant. I also didn't see any mention of "complete." On the receiver side, the AD bit is only of value if the channel between the receiver and the sender is secure - TSIG'd, IPSEC'd, guns&dogs around the facility. The protocol elements can't "know" if the channel is secure though, so you can't programatically code that assumption in. IMHO, if a record set is not germane to the query, then the response message is suspect. For all queries other than qtype=* you can tell if the response message is complete (with DNSSEC). You might think that, with the NSEC record you can tell - but no, not really. The qtype=* isn't qtype=ALL, it's qtype=ANY. If you ask a "cache" there is no requirement it go find the other records. (Especially if it doesn't offer to do recursion for you.) IOW, if the cache excludes a certain RRSet listed in the NSEC record (or even the NSEC), the cache might not be lying. I would take option #1 - but I don't get the empty non-terminal bit. There's no law stating that a query can't be made for an empty non-terminal's "any" records. Is it possible that a non-empty non-terminal's descendent may have been the object of a previous query and so the cache may have "constructed" a tree including the now queried-for-name? (Maybe a dumb question.) At 14:55 -0400 5/19/05, David Blacka wrote: >It occurred to me that is isn't totally obvious how a DNSSEC validator should >validate a (non rcode=3) response to a qtype=* (or qtype=ANY, if you will) >query. > >I can think of 2 approaches: > >1. Verify any answer section rrsets (that match qname+qclass, that is). If >there are no answer section rrsets, validate via a authority section NSEC that >qname is, in fact, an empty-non-terminal. Validate the authority section as >normal. > >2. Don't validate it at all, don't set the AD bit. > >Opinions? #1 makes the most sense to me, but I see an appeal in #2 (less >work, what is the qtype=* query used for anyway?). > >Does this need additional clarification? I'm thinking that this sort of >thing might go into Sam's bis-updates document, but it could've been obvious >to everyone else. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu May 19 16:42:05 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29181 for ; Thu, 19 May 2005 16:42:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DYrnS-0008rZ-K5 for namedroppers-data@psg.com; Thu, 19 May 2005 20:39:10 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DYrnQ-0008rI-TD for namedroppers@ops.ietf.org; Thu, 19 May 2005 20:39:08 +0000 Received: from [10.131.244.227] ([::ffff:172.25.170.10]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.verisignlabs.com with esmtp; Thu, 19 May 2005 16:39:07 -0400 id 00594694.428CF96B.000011E3 Message-ID: <428CF96B.4090806@verisignlabs.com> Date: Thu, 19 May 2005 16:39:07 -0400 From: David Blacka Organization: VeriSign, Inc. User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Edward Lewis CC: namedroppers@ops.ietf.org Subject: Re: validating a qtype=* response References: <428CE13A.4070503@verisignlabs.com> In-Reply-To: X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward Lewis wrote: > I would take option #1 - but I don't get the empty non-terminal bit. > There's no law stating that a query can't be made for an empty > non-terminal's "any" records. My thinking was that if a NODATA response comes back from a qtype=* query, then either qname is a ENT or the server should have recursed (and found rrsets), but this could be wrong. Does qtype=* imply no recursion? Should a NODATA response also be accepted as valid, then? -- David Blacka Sr. Engineer VeriSign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu May 19 17:08:59 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01588 for ; Thu, 19 May 2005 17:08:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DYsDk-000B3T-7T for namedroppers-data@psg.com; Thu, 19 May 2005 21:06:20 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DYsDi-000B30-5G for namedroppers@ops.ietf.org; Thu, 19 May 2005 21:06:18 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j4JL683m080419; Thu, 19 May 2005 17:06:09 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <428CF96B.4090806@verisignlabs.com> References: <428CE13A.4070503@verisignlabs.com> <428CF96B.4090806@verisignlabs.com> Date: Thu, 19 May 2005 17:06:20 -0400 To: David Blacka From: Edward Lewis Subject: Re: validating a qtype=* response Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 16:39 -0400 5/19/05, David Blacka wrote: >Edward Lewis wrote: > >> I would take option #1 - but I don't get the empty non-terminal bit. There's >>no law stating that a query can't be made for an empty non-terminal's "any" >>records. > >My thinking was that if a NODATA response comes back from a qtype=* query, >then either qname is a ENT or the server should have recursed (and found >rrsets), but this could be wrong. Does qtype=* imply no recursion? Answering the last question - no. What I was referring to can be seen by: dig chia.arin.net any @f.gtld-servers.net I offer this a cache that isn't willing to go look for you, but is happy to tell you what it already knows. You'll see the A record for chia.arin.net in the answer, but not the AAAA it owns. >Should a NODATA response also be accepted as valid, then? Let's say this is in the zone (meaning, if I asked an auth server): $ORIGIN example. ... label-a A 127.0.0.1 label-a TXT "A non-empty non-terminal" label1.label-a A 127.0.0.1 label2.label-a A 127.0.0.1 -----end of the zone data Assume there's a caching/recursive server I am using and issue these queries against it (right after start up): dig label1.label-a A dig label2.label-a A dig label-a ANY ...I would expect that either the cache recurses as it hasn't seen data for label-a before OR the cache returns NODATA as it knows the name exists but has no data for it. The latter option might be the only one for unwilling-to-recurse caches. dig label-a A ...I would expect recursion to kick in, getting the A and returning it dig label-a ANY ...returns the cached A record. (Assuming TTL is long enough.) dig label-a TXT ...gets and returns the TXT record dig label-a ANY ...returns the cached TXT and A record. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From PaulaNieves@crucibles.com Fri May 20 00:52:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13032 for ; Fri, 20 May 2005 00:52:06 -0400 (EDT) Received: from 12-207-90-74.client.mchsi.com ([12.207.90.74]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DYzlm-0005uE-5V for dnsext-archive@ietf.org; Fri, 20 May 2005 01:10:02 -0400 Received: from HsS@localhost by 0dpb.int (8.11.6/8.11.6); Fri, 20 May 2005 00:48:42 -0500 Message-ID: From: "Vicki Rangel" Reply-To: "Vicki Rangel" To: dnsext-archive@ietf.org Subject: 0nline software, Download AutoCAD, XP Pro & others Instantly Date: Fri, 20 May 2005 03:45:42 -0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: PaulaNieves@crucibles.com Content-Type: multipart/mixed; boundary="--iFNRZsoiqbBvFGRmCFU" X-Spam-Score: 5.2 (+++++) X-Spam-Flag: YES X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 IMQ ----iFNRZsoiqbBvFGRmCFU Content-Type: text/html; Content-Transfer-Encoding: quoted-printable D
Opt-in Email Special Offer &n= bsp;   unsubscribe me
<= td class=3Dsmall align=3Dmiddle bgColor=3D#ffffdd width=3D707>
=
<= td width=3D5 bgcolor=3D#000080>
SEARCH

TOP 10 NEW TITLES

=

 = ON SALE NOW!

 1 Offi= ce Pro 2003
 2 Windows XP= Pro
 3 Adobe Creative S= uite Premium
 4 Norton An= tivirus 2005
 5 Flash MX = 2004
 6 Corel Draw 12
 7 Adobe Acrobat= 7.0
 8 Windows 2003 Ser= ver
 9 Alias Maya 6 Wave= frt
 10 Adobe Premiere
  See more by this m= anufacturer
   Microsoft
   Apple Software
  Customers also bought
   these other ite= ms...



Microsoft Office Professional Editi= on *2003*
Micro= soft
Choose:
 
 List Price:$899.00
Price:$69.99
You Save= :$830.01 (92%)



Availability: Available for INSTANT download!
<= b>Coupon Code: ISe229
Media: CD-ROM / Download
<= br> System requirements=   |  Accessories  |&= nbsp; Other Versions

Features:

  • Analyze and manage business information using Access d= atabases
  • Exchange data with = other systems using enhanced XML technology
  • Control information sharing rules with enhanced IRM techno= logy
  • Easy-to-use wizards to = create e-mail newsletters and printed marketing materials
    • More than 20 preformatted business reports <= /font>
Sales Rank: #1
Shipping: International/US or via instant download
D= ate Coupon Expires: June 30th, 2005
A= verage Customer Review: 3D"5 Based on 1,768 reviews. Write a review.
Microsoft Wind= ows XP Professional or Longhorn Edition
Microsoft
Choose:
 

=
List Price:$279.00
Price:= $49.99
You Save:$229.01 (85%)


Availability: Available for INSTANT download!
Coupon Code:= ISe229
Media: CD-ROM / Download

System requirements  |&n= bsp; Accessories  |  Other Versions

Fea= tures:

  • Designed for businesses of all sizes
  • Manage digital pictures, music, video, DVDs, and more
  • More security with the ability t= o encrypt files and folders
  • = Built-in voice, video, and instant messaging support
  • Integration with Windows servers and management s= olutions

Sales Rank: #2
= Shipping: International/US or via instant download
= Date Coupon Expires: June 30th, 2005
Average Customer Review: 3D"5 Based on 868 reviews. Write a review.

Adobe Photoshop= CS2 V 9.0
Adob= e
Choose:
 

List Pri= ce: $599.00
Pric= e:$69.99
You Save:<= span class=3Dprice>$529.01 (90%)


=
Availability: Available for INSTANT download!
Coupon Co= de: ISe229
Media: CD-ROM / Download

System requirements  = |  Accessories  |  Other Versions

Features:

  • Customized workspace; save personalized workspace and tool se= ttings; create customized shortcuts
  • Unparalleled efficiency--automate production tasks with built-in = or customized scripts
  • Improv= ed file management, new design possibilities, and a more intuitive way to = create for the Web
  • Support f= or 16-bit images, digital camera raw data, and non-square pixels
  • Create or modify photos using paintin= g, drawing, and retouching tools

Sales Rank: #3
Shipping: International= /US or via instant download
Date Coupon Expires: June 30th, 200= 5
Average Customer Review: 3D"5 B= ased on 498 reviews. Write a review.

= ----iFNRZsoiqbBvFGRmCFU-- From owner-namedroppers@ops.ietf.org Fri May 20 08:57:32 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10428 for ; Fri, 20 May 2005 08:57:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DZ703-000MbD-H1 for namedroppers-data@psg.com; Fri, 20 May 2005 12:53:11 +0000 Received: from [216.168.239.71] (helo=falcon.verisign.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DZ701-000Mag-OE for namedroppers@ops.ietf.org; Fri, 20 May 2005 12:53:09 +0000 Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by falcon.verisign.com (8.12.10/8.12.10) with ESMTP id j4KCkAoi021170; Fri, 20 May 2005 08:46:10 -0400 (EDT) Received: from chinook ([10.131.31.52]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 May 2005 08:52:31 -0400 Received: by chinook (Postfix, from userid 500) id 9B9D421300C; Fri, 20 May 2005 08:52:31 -0400 (EDT) Date: Fri, 20 May 2005 08:52:31 -0400 From: Matt Larson To: Edward Lewis Cc: David Blacka , namedroppers@ops.ietf.org Subject: Glue (was Re: validating a qtype=* response) Message-ID: <20050520125231.GE17267@chinook.corpit.vrsn.com> References: <428CE13A.4070503@verisignlabs.com> <428CF96B.4090806@verisignlabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-OriginalArrivalTime: 20 May 2005 12:52:31.0658 (UTC) FILETIME=[C94B78A0:01C55D3A] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk (Taking us off topic for this thread...), On Thu, 19 May 2005, Edward Lewis wrote: > At 16:39 -0400 5/19/05, David Blacka wrote: > >Does qtype=* imply no recursion? > > Answering the last question - no. What I was referring to can be seen by: > > dig chia.arin.net any @f.gtld-servers.net > > I offer this a cache that isn't willing to go look for you, but is > happy to tell you what it already knows. You'll see the A record for > chia.arin.net in the answer, but not the AAAA it owns. The situation you describe regarding a cache's behavior is valid, but that isn't what's happening here: f.gtld-servers.net is an authoritative-only name server with no iterative resolver component and therefore no cache. The A record for chia.arin.net is present because it's glue (for the arin.net zone and perhaps others). ARIN could register an AAAA record for chia.arin.net as glue through its registrar and then that record would be returned, too. Matt -- Matt Larson VeriSign Naming and Directory 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 May 20 10:20:20 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21350 for ; Fri, 20 May 2005 10:20:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DZ8JI-00033T-FJ for namedroppers-data@psg.com; Fri, 20 May 2005 14:17:08 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DZ8JG-00033E-Lo for namedroppers@ops.ietf.org; Fri, 20 May 2005 14:17:06 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j4KEGx0x083996; Fri, 20 May 2005 10:17:00 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20050520125231.GE17267@chinook.corpit.vrsn.com> References: <428CE13A.4070503@verisignlabs.com> <428CF96B.4090806@verisignlabs.com> <20050520125231.GE17267@chinook.corpit.vrsn.com> Date: Fri, 20 May 2005 10:10:02 -0400 To: Matt Larson From: Edward Lewis Subject: Re: Glue (was Re: validating a qtype=* response) Cc: Edward Lewis , David Blacka , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 8:52 -0400 5/20/05, Matt Larson wrote: >The situation you describe regarding a cache's behavior is valid, but >that isn't what's happening here: f.gtld-servers.net is an >authoritative-only name server with no iterative resolver component >and therefore no cache. The A record for chia.arin.net is present >because it's glue (for the arin.net zone and perhaps others). ARIN >could register an AAAA record for chia.arin.net as glue through its >registrar and then that record would be returned, too. Exactly. I'm using it as an example of a cache not fetching (and not required to fetch) the other data sets because of a qtype=* query. I.e., the fact that the AAAA record is "omitted" is not a security issue, it's an artifact of the protocol. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From CharleyAbel@shoeshines.net Fri May 20 11:56:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00897 for ; Fri, 20 May 2005 11:56:09 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZA8W-0005k9-Nh for dnsext-archive@ietf.org; Fri, 20 May 2005 12:14:11 -0400 Received: from cm143.omega44.maxonline.com.sg ([218.186.44.143] helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1DZ9qz-0005a8-82 for dnsext-archive@ietf.org; Fri, 20 May 2005 11:56:02 -0400 Received: from 9m7@localhost by o4i1.int (8.11.6/8.11.6); Sat, 21 May 2005 00:28:29 +0300 Message-ID: From: "Randall Wills" Reply-To: "Randall Wills" To: dnsext-archive@ietf.org Subject: QHA All Xennica1 on sale now from Obrien Industries 3cpEjanR Date: Fri, 20 May 2005 20:29:29 -0100 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: CharleyAbel@shoeshines.net Content-Type: multipart/mixed; boundary="--L0hT06F1mrEuUS4a" X-Spam-Score: 4.8 (++++) X-Scan-Signature: ceb20e3ccfd90d068e2ad6c8a4781b53 6sEQ ----L0hT06F1mrEuUS4a Content-Type: text/html; Content-Transfer-Encoding: quoted-printable 242VqxOrkWjBZBx

R

N
L
N
S
L

G

T
t
 

W
M
M
S
A
P
A
H
-
V
X

o
ow
o
hi
ic

et

ak
ak
 
 
ei
us
en
ki
nt
ai
ll
ea
--
 i		  
- V

mor
est
Pre
ppe
ens

 yo

e a
ing
  
 
ght
cle
's
n C
i D
n R
erg
rt
---
 s
isi
 
e l
 Pr
scr
d t
ed

ur

 st
 ad
  

 Lo
 Re
Hea
are
epr
eli
y R
Bur
 FA
i t		  
t Ou

ong
ices
ipti
o yo
& Ap

Medi

ep i
vant
   
Prod
ss
laxe
lth
   
essi
ef 
elie
n Ca
ST 
  O
r On

doct
 Gua
on N
ur d
prov

cine

nto
age
   
ucts
   <
rs <
   <
   <
on <
   <
f  <
re <
 FAS
u r


li

or
ra
ee
oo
ed

 O

th
of
 

Xe
So
Vi
Re
Pr
Ce
Cl
Ne
T
 S


ne

 v
nt
de
r
!

nl

e
 o
 

ni
ma
ag
no
oz
le
ar
xi

 i

 
 Dru

isit
eed!
d !
in 2


ine

futu
ur o
   

cal>
, Za
ra,
va,
ac,
brex
itin
um,P
 SHI
 t e


gs

s!

 
4


an

re
nl
 

 
na
Le
Re
Pa
, 
,
ri
PP
 


to



 
Ho


d

 &
in
 

 
fl
vi
ti
xi
Vi
Zy
lo
IN
T 


re




ur


Sa

 j
e
 

 
ex
tr
n-
l,
co
rt
se
G
o 


 &




s!


ve

oi
se
 
Pr
 
>
a,
A>
 Z
di
ec
c,
!
d 


 S







!

n
rv
 
ic
 

 C
 
ol
n>
>
Pr
--
a 


av









th
ic

e
 

ia

of
 

va
--
y


e!









e
es

pe


li

t>


ci
--
!












mi
..

r


s>




d>

 












ll
.

pi
 $
 $
 $
 $
 $
 $
 $
 $

 












ions


ll
1
1
4
40
1
3
1.5
2

 

http://netflo.biz

 

 

r3m0v3 m3

http://I73.net/a.php

 

----L0hT06F1mrEuUS4a-- From owner-namedroppers@ops.ietf.org Fri May 20 16:30:38 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11572 for ; Fri, 20 May 2005 16:30:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DZE5H-00038o-Pk for namedroppers-data@psg.com; Fri, 20 May 2005 20:27:03 +0000 Received: from [67.52.51.34] (helo=backbone.schlitt.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DZE5G-00038S-UY for namedroppers@ops.ietf.org; Fri, 20 May 2005 20:27:03 +0000 Received: from footbone.schlitt.net ([67.52.51.37] helo=schlitt.net) by backbone.schlitt.net with esmtp (Exim 4.50) id 1DZE4y-0004jF-Bx for namedroppers@ops.ietf.org; Fri, 20 May 2005 15:27:01 -0500 To: "IETF DNSEXT WG" From: wayne Mail-Copies-To: nobody Reply-To: "IETF DNSEXT WG" Content-Type: text/plain; charset=US-ASCII Date: Fri, 20 May 2005 15:26:43 -0500 Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.schlitt.net: domain of schlitt.net designates 67.52.51.37 as permitted sender) client-ip=67.52.51.37; envelope-from=wayne@schlitt.net; helo=schlitt.net; X-SA-Exim-Connect-IP: 67.52.51.37 X-SA-Exim-Rcpt-To: namedroppers@ops.ietf.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: SPF I-D for review: draft-schlitt-spf-classic-01.txt X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on backbone.schlitt.net) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk fyi; There is a new I-D for the SPF email anti-forgery system available for review. This draft tries to document the current practices of the ~1,000,000[1] published SPF records and ~10,000[1] deployed SPF systems that are checking 20-100million emails per day. See: http://www.ietf.org/internet-drafts/draft-schlitt-spf-classic-01.txt Discussions about this, and previous, drafts have been taking place on the spf-discuss@v2.listbox.com mailing list. To subscribe or read the archives, see http://spf.pobox.com/mailinglist.html While I have been reading this mailing list for many months and will note any comments posted here, sending email to the spf-discuss list or to me personally is probably better than flooding this list. I realize that the whole subject of SPF (and similar systems) has a certain amount of controversy to it, but for the purposes of this draft, I am very reluctant to try debate these issues. The goal is to document a de-facto standard. Debates about better techniques, why SPF is evil, etc. are probably best discussed on things like the IRTF ASRG list, SPAM-L, the NANAE newsgroup, or on spf-discuss on a separate thread/subject. While SPF mostly deals with the [2]821 SMTP level, it also relies heavily on DNS to communicate between the domain owner, and the email receiver. This I-D also makes provisions to create a new RR that is just a clone of the TXT RR type. We had a lively discussion here a few months ago when the -00 draft was reviewed. I hope people will read the I-D over and again give me feedback. My intention is that after a two week review, I will make a "final" revised draft and ask the IESG to consider it for a Proposed Standard status. -wayne [1] These numbers are estimates as of earlier this year. They were pretty solid back then, and have probably grown since. I have data to back them up and they are almost certainly underestimating the real numbers. -- to unsubscribe send a message to namedroppers-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 May 20 16:49:45 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12774 for ; Fri, 20 May 2005 16:49:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DZEPY-0004Ue-8B for namedroppers-data@psg.com; Fri, 20 May 2005 20:48:00 +0000 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DZEPS-0004U4-IK for namedroppers@ops.ietf.org; Fri, 20 May 2005 20:47:55 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-1) with ESMTP id j4KKldYH016610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 20 May 2005 22:47:45 +0200 From: Simon Josefsson To: namedroppers@ops.ietf.org Subject: RFC 2538bis OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:050520:namedroppers@ops.ietf.org::5fA2h6U+WOc0/KjV:38ci Date: Fri, 20 May 2005 22:47:12 +0200 Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Dear WG, I am about to submit -02. The changes are those discussed in: http://article.gmane.org/gmane.ietf.dnsext/6939 http://article.gmane.org/gmane.ietf.dnsext/7024 which has resulted in the following diff so far: http://josefsson.org/rfc2538bis/draft-ietf-dnsext-rfc2538bis-from--01.diff.html You can review the new document from: http://josefsson.org/rfc2538bis/ Or directly as: http://josefsson.org/rfc2538bis/draft-ietf-dnsext-rfc2538bis.txt The text for the SPKI type now reads: The SPKI type is reserved to indicate the SPKI certificate format [13], for use when the SPKI documents are moved from experimental status. Is there a better way to say that? What? The problem is that the SPKI spec is on the experimental track, so we can't reference it normatively. I have not seen any interest in SPKI support for CERT records, though, so reserving the type until SPKI hit the full standards track was what I thought was simplest. Please comment. The IANA considerations section include the text proposed by Sam. I like for people to review whether the changes properly address the open issues. I'm not entirely certain the IANA part is closed by this; Sam, can you confirm one way or the other? I intend to submit -02 within a week. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri May 20 17:18:35 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11573 for ; Fri, 20 May 2005 16:30:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DZE2F-0002x9-Q5 for namedroppers-data@psg.com; Fri, 20 May 2005 20:23:55 +0000 Received: from [80.91.229.2] (helo=ciao.gmane.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DZE2B-0002wo-Gb for namedroppers@ops.ietf.org; Fri, 20 May 2005 20:23:51 +0000 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1DZDzH-00018d-JN for namedroppers@ops.ietf.org; Fri, 20 May 2005 22:20:51 +0200 Received: from footbone.schlitt.net ([67.52.51.37]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 May 2005 22:20:51 +0200 Received: from wayne by footbone.schlitt.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 May 2005 22:20:51 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org From: wayne Subject: SPF I-D for review: draft-schlitt-spf-classic-01.txt Date: Fri, 20 May 2005 15:12:48 -0500 Lines: 47 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: footbone.schlitt.net User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) Cancel-Lock: sha1:rWIPiOIAZkGuOfs3QhL2d+FuTqg= X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk fyi; There is a new I-D for the SPF email anti-forgery system available for review. This draft tries to document the current practices of the ~1,000,000[1] published SPF records and ~10,000[1] deployed SPF systems that are checking 20-100million emails per day. See: http://www.ietf.org/internet-drafts/draft-schlitt-spf-classic-01.txt Discussions about this, and previous, drafts have been taking place on the spf-discuss@v2.listbox.com mailing list. To subscribe or read the archives, see http://spf.pobox.com/mailinglist.html While I have been reading this mailing list for many months and will note any comments posted here, sending email to the spf-discuss list or to me personally is probably better than flooding this list. I realize that the whole subject of SPF (and similar systems) has a certain amount of controversy to it, but for the purposes of this draft, I am very reluctant to try debate these issues. The goal is to document a de-facto standard. Debates about better techniques, why SPF is evil, etc. are probably best discussed on things like the IRTF ASRG list, SPAM-L, the NANAE newsgroup, or on spf-discuss on a separate thread/subject. While SPF mostly deals with the [2]821 SMTP level, it also relies heavily on DNS to communicate between the domain owner, and the email receiver. This I-D also makes provisions to create a new RR that is just a clone of the TXT RR type. My intention is that after a two week review, I will make a "final" revised draft and ask the IESG to consider it for a Proposed Standard status. -wayne [1] These numbers are estimates as of earlier this year. They were pretty solid back then, and have probably grown since. I have data to back them up and they are almost certainly underestimating the real numbers. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From JennyWesley@approvedproducts.co.uk Sat May 21 08:07:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06344 for ; Sat, 21 May 2005 07:41:45 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZIK7-00075O-3T for dnsext-archive@ietf.org; Fri, 20 May 2005 20:58:40 -0400 Received: from cpe-69-203-223-65.nyc.res.rr.com ([69.203.223.65]) by mx2.foretec.com with smtp (Exim 4.24) id 1DZI2M-0007Wq-PR for dnsext-archive@ietf.org; Fri, 20 May 2005 20:40:18 -0400 Received: from jHm@localhost by 4dhb.int (8.11.6/8.11.6); Fri, 20 May 2005 19:25:37 -0300 Message-ID: <0zsfP4J6gXBpw11eZAFbJGsY@artsupdate.co.uk> From: "Maxwell Mullen" Reply-To: "Maxwell Mullen" To: dnsext-archive@ietf.org Subject: Pb1 Casino Spring Fling Competition :) FRE:rJuLzJ Date: Fri, 20 May 2005 15:26:37 -0700 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: JennyWesley@approvedproducts.co.uk Content-Type: multipart/mixed; boundary="--rX7vvGsUgyEN9fC5UtZ" X-Spam-Score: 2.8 (++) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 4ti ----rX7vvGsUgyEN9fC5UtZ Content-Type: text/html; Content-Transfer-Encoding: quoted-printable lrTe0WhHZ07n

Welcome to MS@Casin0 - a REVOLUTION in = Online Gambling!
MS@Casin0 establishes a turning point in casin0 history by
uniquely allowing players worldwide to play as dealer thus
receiving some of the most favorable odds normally reserved for
the casin0.

MS@Casin0 offers popular games, including Blackjack, Roulette,
Slot Machines and Video Poker all featuring unmatched graphics and sounds.=

You may play with REAL Money or just play for Fun (no bank details needed)=

Questions and Answers
--------------------

Q: MS@casin0 offers matchless credibility and it's easy to check. How ? A: Robert as Player and Graham as Dealer enter one of the games. Once the = game
is over, they verify that one's losing sum is the other's winning sum.
=
Q: MS@casin0 offers the highest payouts available. How is that possible? A: Payouts are constant in games like Blackjack and Roulette (and for all<= br> games with the same rules). MS@casin0 's unique concept allows players to<= br> become the Dealer, which improves their winning odds, thus increasing
their payout rates.

The top daily player (determined at 23:59) gets $200 bonus!

Winnings generated from playing as Dealer are also accumulated.

The scoreboard will be updated every hour.

Visit our site http://4highrollers.net - try your luck & no dep= osit required ! ! !

Best regards,

Benjamin Stein
Casin0 Manager

----rX7vvGsUgyEN9fC5UtZ-- From MariaDaley@biguanide.net Sat May 21 12:41:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04846 for ; Sat, 21 May 2005 12:41:09 -0400 (EDT) Date: Sat, 21 May 2005 12:41:09 -0400 (EDT) From: MariaDaley@biguanide.net Message-Id: <200505211641.MAA04846@ietf.org> Received: from [60.63.38.50] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DZXJo-0001hf-9l for dnsext-archive@ietf.org; Sat, 21 May 2005 12:59:24 -0400 Received: from 4[3 X-Spam-Score: 11.4 (+++++++++++) X-Spam-Flag: YES X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 From owner-namedroppers@ops.ietf.org Sun May 22 07:50:14 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08585 for ; Sun, 22 May 2005 07:50:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DZosD-000LRw-7Y for namedroppers-data@psg.com; Sun, 22 May 2005 11:44:01 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DZosB-000LRP-Ct for namedroppers@ops.ietf.org; Sun, 22 May 2005 11:43:59 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id D1F8D2DE35; Sun, 22 May 2005 13:43:55 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id CEA412DE19; Sun, 22 May 2005 13:43:55 +0200 (CEST) Date: Sun, 22 May 2005 13:43:55 +0200 (CEST) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: namedroppers@ops.ietf.org cc: weiler@tislabs.com Subject: draft-ietf-dnsext-bis-updates-0: DNAME Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Please note that section 6 "clarification on Non-Existence Proofs" does not handle DNAME. i.e. b.example DNAME other b.example NSEC c.example DNAME NSEC RRSIG It is trivial to construct a negative response for qname=a.b.example using the "b.example NSEC c.example" which is (falsely) used to prove non-existence of a.b.example. Therefor, the algorithm must have a clause where it checks for DNAME. 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 AllisonVickers@distoma.com Mon May 23 15:50:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04837 for ; Mon, 23 May 2005 15:50:35 -0400 (EDT) Received: from cpe-69-133-78-208.columbus.res.rr.com ([69.133.78.208]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DaJEg-0002lC-Qp for dnsext-archive@ietf.org; Mon, 23 May 2005 16:09:15 -0400 Received: from usP@localhost by 26n.int (8.11.6/8.11.6); Tue, 24 May 2005 00:01:38 +0300 Message-ID: From: "Norah Holbrook" Reply-To: "Norah Holbrook" To: dnsext-archive@ietf.org Subject: Microsoft Special Deals Date: Mon, 23 May 2005 18:02:38 -0300 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: AllisonVickers@distoma.com Content-Type: multipart/mixed; boundary="--3aBO4bqTJjAXwoXJLPlx" X-Spam-Score: 3.7 (+++) X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 87z ----3aBO4bqTJjAXwoXJLPlx Content-Type: text/html; Content-Transfer-Encoding: quoted-printable K
Opt-in Email Special Offer &n= bsp;   unsubscribe me
<= td class=3Dsmall align=3Dmiddle bgColor=3D#ffffdd width=3D707>
=
<= td width=3D5 bgcolor=3D#000080>
SEARCH

TOP 10 NEW TITLES

=

 = ON SALE NOW!

 1 Offi= ce Pro 2003
 2 Windows XP= Pro
 3 Adobe Creative S= uite Premium
 4 Norton An= tivirus 2005
 5 Flash MX = 2004
 6 Corel Draw 12
 7 Adobe Acrobat= 7.0
 8 Windows 2003 Ser= ver
 9 Alias Maya 6 Wave= frt
 10 Adobe Premiere
  See more by this m= anufacturer
   Microsoft
   Apple Software
  Customers also bought
   these other ite= ms...



Microsoft Office Professional Editi= on *2003*
Micro= soft
Choose:
 
 List Price:$899.00
Price:$69.99
You Save= :$830.01 (92%)



Availability: Available for INSTANT download!
<= b>Coupon Code: ISe229
Media: CD-ROM / Download
<= br> System requirements=   |  Accessories  |&= nbsp; Other Versions

Features:

  • Analyze and manage business information using Access d= atabases
  • Exchange data with = other systems using enhanced XML technology
  • Control information sharing rules with enhanced IRM techno= logy
  • Easy-to-use wizards to = create e-mail newsletters and printed marketing materials
    • More than 20 preformatted business reports <= /font>
Sales Rank: #1
Shipping: International/US or via instant download
D= ate Coupon Expires: June 30th, 2005
A= verage Customer Review: 3D"5 Based on 1,768 reviews. Write a review.
Microsoft Wind= ows XP Professional or Longhorn Edition
Microsoft
Choose:
 

=
List Price:$279.00
Price:= $49.99
You Save:$229.01 (85%)


Availability: Available for INSTANT download!
Coupon Code:= ISe229
Media: CD-ROM / Download

System requirements  |&n= bsp; Accessories  |  Other Versions

Fea= tures:

  • Designed for businesses of all sizes
  • Manage digital pictures, music, video, DVDs, and more
  • More security with the ability t= o encrypt files and folders
  • = Built-in voice, video, and instant messaging support
  • Integration with Windows servers and management s= olutions

Sales Rank: #2
= Shipping: International/US or via instant download
= Date Coupon Expires: June 30th, 2005
Average Customer Review: 3D"5 Based on 868 reviews. Write a review.

Adobe Photoshop= CS2 V 9.0
Adob= e
Choose:
 

List Pri= ce: $599.00
Pric= e:$69.99
You Save:<= span class=3Dprice>$529.01 (90%)


=
Availability: Available for INSTANT download!
Coupon Co= de: ISe229
Media: CD-ROM / Download

System requirements  = |  Accessories  |  Other Versions

Features:

  • Customized workspace; save personalized workspace and tool se= ttings; create customized shortcuts
  • Unparalleled efficiency--automate production tasks with built-in = or customized scripts
  • Improv= ed file management, new design possibilities, and a more intuitive way to = create for the Web
  • Support f= or 16-bit images, digital camera raw data, and non-square pixels
  • Create or modify photos using paintin= g, drawing, and retouching tools

Sales Rank: #3
Shipping: International= /US or via instant download
Date Coupon Expires: June 30th, 200= 5
Average Customer Review: 3D"5 B= ased on 498 reviews. Write a review.

= ----3aBO4bqTJjAXwoXJLPlx-- From owner-namedroppers@ops.ietf.org Mon May 23 18:19:59 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04565 for ; Mon, 23 May 2005 18:19:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DaLBp-00082S-Au for namedroppers-data@psg.com; Mon, 23 May 2005 22:14:25 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DaLBm-000825-DR for namedroppers@ops.ietf.org; Mon, 23 May 2005 22:14:22 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j4NMATRF010463 for ; Mon, 23 May 2005 18:10:29 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAazaOBu; Mon, 23 May 05 18:10:26 -0400 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j4NMCGSR002441; Mon, 23 May 2005 18:12:21 -0400 (EDT) Date: Mon, 23 May 2005 18:12:16 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@filbert To: Simon Josefsson cc: namedroppers@ops.ietf.org Subject: Re: rfc2538bis IANA considerations In-Reply-To: Message-ID: References: <6.1.2.0.2.20041011160917.070d8ec0@localhost> <20041012080533.GA17012@nic.fr> <6.1.2.0.2.20041012100511.0766efd0@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I'm not entirely certain the IANA part is closed by > this; Sam, can you confirm one way or the other? The new text resolves one issue (cleaning up the documentation), but still leaves the below questions unanswered. Unless the WG breaks its resounding silence on them, I propose that we pretend to be ostriches, stick our heads in the sand, and leave this for another generation to sort out. -- Sam On Tue, 22 Mar 2005, Samuel Weiler wrote: > I think there are two remaining open questions related to the CERT RR > and the DNSSEC algorithm number registry. Any input? Do we want to > allow CERT RRs to contain ALL algorithm types specified in this > registry, or do we want to add another applicability list? > > > > -- Can CERTs use private algorithms (type 253/254)? If so, do you > > > still want to use the same encoding as for KEY/DNSKEY, with the > > > algorithm in the RDATA? Some explicit mention of the private > > > algorithms might be a good idea, in any case. Also note David > > > Blacka's DNSSEC experiment draft, which encourages use of > > > the private algorithms. > > > > I have no idea how to address this, nor can I answer the question. I > > hope that others will give input on this. > > > > > -- Given that 3755 added applicablility columns to the algorithm > > > registry (see the registry itself and 3755 for details), do you > > > want another column for CERT, along with a requirement that new > > > algorithm definitions say whether they can be used for CERTs or > > > not? > > > > It seem to require some work for new algorithm definers. My > > experience is that the key tag and algorithm fields of CERT RRs are > > rarely useful, nor consistently populated. So the additional work > > will lead to little practical advantage, in my opinion. That would > > suggest we shouldn't worry about this. > > > > However, this seem to be more of a process issue, than a technical > > concern, so I'd be interested to hear what others feel. -- to unsubscribe send a message to namedroppers-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 May 23 18:29:54 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05422 for ; Mon, 23 May 2005 18:29:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DaLO7-0008o7-AN for namedroppers-data@psg.com; Mon, 23 May 2005 22:27:07 +0000 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DaLO4-0008nM-W7 for namedroppers@ops.ietf.org; Mon, 23 May 2005 22:27:05 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-1) with ESMTP id j4NMQxG0012227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 May 2005 00:26:59 +0200 From: Simon Josefsson To: Samuel Weiler Cc: namedroppers@ops.ietf.org Subject: Re: rfc2538bis IANA considerations References: <6.1.2.0.2.20041011160917.070d8ec0@localhost> <20041012080533.GA17012@nic.fr> <6.1.2.0.2.20041012100511.0766efd0@localhost> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:050523:weiler@tislabs.com::Zn3WJTMWOEHExrU7:8YG4 X-Hashcash: 1:21:050523:namedroppers@ops.ietf.org::sELFPO/iFJzfKddh:4QJR Date: Tue, 24 May 2005 00:26:58 +0200 In-Reply-To: (Samuel Weiler's message of "Mon, 23 May 2005 18:12:16 -0400 (EDT)") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Samuel Weiler writes: >> I'm not entirely certain the IANA part is closed by >> this; Sam, can you confirm one way or the other? > > The new text resolves one issue (cleaning up the documentation), but > still leaves the below questions unanswered. Unless the WG breaks its > resounding silence on them, I propose that we pretend to be ostriches, > stick our heads in the sand, and leave this for another generation to > sort out. That would work for me. My impression is that these parts have little practical purpose today anyway. I have submitted the draft, if there are further comments about this from the WG, I can update it. Thanks, Simon > -- Sam > > On Tue, 22 Mar 2005, Samuel Weiler wrote: > >> I think there are two remaining open questions related to the CERT RR >> and the DNSSEC algorithm number registry. Any input? Do we want to >> allow CERT RRs to contain ALL algorithm types specified in this >> registry, or do we want to add another applicability list? >> >> > > -- Can CERTs use private algorithms (type 253/254)? If so, do you >> > > still want to use the same encoding as for KEY/DNSKEY, with the >> > > algorithm in the RDATA? Some explicit mention of the private >> > > algorithms might be a good idea, in any case. Also note David >> > > Blacka's DNSSEC experiment draft, which encourages use of >> > > the private algorithms. >> > >> > I have no idea how to address this, nor can I answer the question. I >> > hope that others will give input on this. >> > >> > > -- Given that 3755 added applicablility columns to the algorithm >> > > registry (see the registry itself and 3755 for details), do you >> > > want another column for CERT, along with a requirement that new >> > > algorithm definitions say whether they can be used for CERTs or >> > > not? >> > >> > It seem to require some work for new algorithm definers. My >> > experience is that the key tag and algorithm fields of CERT RRs are >> > rarely useful, nor consistently populated. So the additional work >> > will lead to little practical advantage, in my opinion. That would >> > suggest we shouldn't worry about this. >> > >> > However, this seem to be more of a process issue, than a technical >> > concern, so I'd be interested to hear what others feel. -- to unsubscribe send a message to namedroppers-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 May 23 18:52:13 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09670 for ; Mon, 23 May 2005 18:52:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DaLkD-000ABW-3k for namedroppers-data@psg.com; Mon, 23 May 2005 22:49:57 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DaLkB-000ABG-FA for namedroppers@ops.ietf.org; Mon, 23 May 2005 22:49:55 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j4NMk2Nk013013 for ; Mon, 23 May 2005 18:46:02 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAMiaiAz; Mon, 23 May 05 18:45:59 -0400 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j4NMlvOL003499; Mon, 23 May 2005 18:47:57 -0400 (EDT) Date: Mon, 23 May 2005 18:47:57 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@filbert To: David Blacka cc: namedroppers@ops.ietf.org Subject: Re: validating a qtype=* response In-Reply-To: <428CE13A.4070503@verisignlabs.com> Message-ID: References: <428CE13A.4070503@verisignlabs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I like option #1, also clarifying that NXDOMAIN and NODATA both need non-existence proofs (1+ NSEC RRs). > 1. Verify any answer section rrsets (that match qname+qclass, that is). > If there are no answer section rrsets, validate via a authority > section NSEC that qname is, in fact, an empty-non-terminal. Validate > the authority section as normal. > 2. Don't validate it at all, don't set the AD bit. Given that our current signaling mechanism for validation results (the AD bit) is so coarse, option #2 worries me. Can that unvalidated RRset be cached? Can a resolver give out the (unvalidated) A record received in response to qtype=* when answering qtype=A? Can it use that (unvalidated) A record when chasing a referral? This sounds like it could lead to cache poisoning problems if not handled very carefully. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon May 23 19:14:14 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12764 for ; Mon, 23 May 2005 19:14:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DaM6C-000CS0-4Z for namedroppers-data@psg.com; Mon, 23 May 2005 23:12:40 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DaM6A-000CRj-Eo for namedroppers@ops.ietf.org; Mon, 23 May 2005 23:12:38 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j4NN8ifh015399 for ; Mon, 23 May 2005 19:08:44 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAABHa4cE; Mon, 23 May 05 19:08:41 -0400 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j4NNAX10004235; Mon, 23 May 2005 19:10:34 -0400 (EDT) Date: Mon, 23 May 2005 19:10:33 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@filbert To: Roy Arends cc: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-bis-updates-0: DNAME In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Please note that section 6 "clarification on Non-Existence Proofs" does > not handle DNAME. To answer's Ed's question from April 15th: "I hate the DNAME". I'll add this to the bis-updates doc. Good catch. -- 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 May 24 01:06:30 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02931 for ; Tue, 24 May 2005 01:06:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DaRZ3-000DnD-0i for namedroppers-data@psg.com; Tue, 24 May 2005 05:02:49 +0000 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DaRZ0-000DmC-Nm for namedroppers@ops.ietf.org; Tue, 24 May 2005 05:02:48 +0000 Received: from orodruin.hactrn.net (unknown [IPv6:2001:4f8:3:bb:2e0:98ff:fe8a:e85c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "orodruin.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id 2B858F7; Tue, 24 May 2005 01:02:25 -0400 (EDT) Received: from orodruin.hactrn.net (localhost [IPv6:::1]) by orodruin.hactrn.net (Postfix) with ESMTP id 04756E2; Tue, 24 May 2005 05:02:04 +0000 (GMT) Date: Mon, 23 May 2005 22:02:04 -0700 From: Rob Austein To: Rick Mesta Cc: "Olaf M. Kolkman" , namedroppers@ops.ietf.org, Spencer.Shepler@sun.com, beepy@netapp.com, ogud@ogud.com, okolkman@ripe.net, nfsv4@ietf.org Subject: Re: draft-mesta-nfs4id-dns-rr-01 In-Reply-To: <20050518163239.GA10343@minas-tirith.central.sun.com> References: <20050509150200.28002bb0.olaf@ripe.net> <20050518163239.GA10343@minas-tirith.central.sun.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) 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: <20050524050204.04756E2@orodruin.hactrn.net> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Default domain" is not a DNS concept per se. It's sometimes a DNS user interface issue, but you won't find it anywhere in the protocol. "Default domain", as implemented by some DNS user interfaces or APIs, is really a degenerate case of a more general thing called a "search path". Search paths can be useful, but also dangerous, both in the sense that they can produce unexpected results (see, eg, RFC 1535) and in the sense that an attacker who can control your search path can influence the questions you ask, so even DNSSEC may not protect you if you're not checking to make sure the answers you're getting have some sane relationship to the question you intended. Some other protocols do have a concept of a "default domain", but that's a matter for those protocols to define, and there are sometimes nuances specific to that particular application protocol (eg, there are DHCP options that play in this space, and Kerberos realms are sort of like domain names, but the interactions between DHCP and Kerberos may be underspecified and could be excessively entertaining...). -- to unsubscribe send a message to namedroppers-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 May 24 09:08:59 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27695 for ; Tue, 24 May 2005 09:08:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DaZ5X-000Mny-To for namedroppers-data@psg.com; Tue, 24 May 2005 13:04:51 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DaZ5W-000Mng-40 for namedroppers@ops.ietf.org; Tue, 24 May 2005 13:04:50 +0000 Received: from [10.131.244.227] ([::ffff:172.25.170.10]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.verisignlabs.com with esmtp; Tue, 24 May 2005 09:04:48 -0400 id 00594876.42932670.0000454C Message-ID: <42932670.9060106@verisignlabs.com> Date: Tue, 24 May 2005 09:04:48 -0400 From: David Blacka Organization: VeriSign, Inc. User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Edward Lewis CC: Matt Larson , namedroppers@ops.ietf.org Subject: Re: Glue (was Re: validating a qtype=* response) References: <428CE13A.4070503@verisignlabs.com> <428CF96B.4090806@verisignlabs.com> <20050520125231.GE17267@chinook.corpit.vrsn.com> In-Reply-To: X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward Lewis wrote: > At 8:52 -0400 5/20/05, Matt Larson wrote: > >> The situation you describe regarding a cache's behavior is valid, but >> that isn't what's happening here: f.gtld-servers.net is an >> authoritative-only name server with no iterative resolver component >> and therefore no cache. The A record for chia.arin.net is present >> because it's glue (for the arin.net zone and perhaps others). ARIN >> could register an AAAA record for chia.arin.net as glue through its >> registrar and then that record would be returned, too. > > > Exactly. I'm using it as an example of a cache not fetching (and not > required to fetch) the other data sets because of a qtype=* query. I.e., > the fact that the AAAA record is "omitted" is not a security issue, it's > an artifact of the protocol. Huh? This isn't an example of a "cache not fetching" anything. There is no cache involved in your example. I think that it is well understood by this WG that qtype=* won't cause a cache to attempt to fetch "all" records of the qtype/qclass. But what is a caching resolver required to do when there are zero records matching qname/qclass in its cache? How does this affect validation? -- 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 May 24 09:16:53 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28454 for ; Tue, 24 May 2005 09:16:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DaZFb-000NkE-VL for namedroppers-data@psg.com; Tue, 24 May 2005 13:15:15 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DaZFb-000Njz-CD for namedroppers@ops.ietf.org; Tue, 24 May 2005 13:15:15 +0000 Received: from [10.131.244.227] ([::ffff:172.25.170.10]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.verisignlabs.com with esmtp; Tue, 24 May 2005 09:15:14 -0400 id 005948B3.429328E2.00004795 Message-ID: <429328E2.5070709@verisignlabs.com> Date: Tue, 24 May 2005 09:15:14 -0400 From: David Blacka Organization: VeriSign, Inc. User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Samuel Weiler CC: namedroppers@ops.ietf.org Subject: Re: validating a qtype=* response References: <428CE13A.4070503@verisignlabs.com> In-Reply-To: X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Samuel Weiler wrote: > I like option #1, also clarifying that NXDOMAIN and NODATA both need > non-existence proofs (1+ NSEC RRs). I like option #1, too. But we need to understand the NODATA case, I think. >>1. Verify any answer section rrsets (that match qname+qclass, that is). >> If there are no answer section rrsets, validate via a authority >>section NSEC that qname is, in fact, an empty-non-terminal. Validate >>the authority section as normal. > > >>2. Don't validate it at all, don't set the AD bit. > > > Given that our current signaling mechanism for validation results (the > AD bit) is so coarse, option #2 worries me. Can that unvalidated > RRset be cached? Can a resolver give out the (unvalidated) A record > received in response to qtype=* when answering qtype=A? Can it use > that (unvalidated) A record when chasing a referral? This sounds like > it could lead to cache poisoning problems if not handled very > carefully. I don't think that this is as worrisome as you think. 1) Caches already need to be able to distinguish between validated an unvalidated rrsets (think CD=1, think signed rrsets that couldn't be validated due to chain of trust). 2) If a validating resolver were to use this unvalidated A rrset in a different response, it should attempt to validate that rrset then, or choose not to use it in a non CD=1 context. 3) Can it use an unvalidated rrset when chasing a referral? I don't see why not. 4) It is true that a cache will have to be careful to avoid poison, but it has to do that anyway. That being said, I don't necessarily see any reason NOT to validate that qtype=* response, other than I'm not exactly certain how it should be done. -- 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 May 24 10:19:30 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04180 for ; Tue, 24 May 2005 10:19:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DaaCi-0002hs-JI for namedroppers-data@psg.com; Tue, 24 May 2005 14:16:20 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DaaCY-0002gg-Qr for namedroppers@ops.ietf.org; Tue, 24 May 2005 14:16:11 +0000 Received: by postman.ripe.net (Postfix, from userid 4008) id BFD8D24F96; Tue, 24 May 2005 16:16:09 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 1671F25094; Tue, 24 May 2005 16:14:29 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id j4OEES45000935; Tue, 24 May 2005 16:14:28 +0200 Date: Tue, 24 May 2005 16:14:28 +0200 From: "Olaf M. Kolkman" To: David Blacka Cc: Ed.Lewis@neustar.biz, mlarson@verisign.com, namedroppers@ops.ietf.org Subject: Re: Glue (was Re: validating a qtype=* response) Message-Id: <20050524161428.22a09964.olaf@ripe.net> In-Reply-To: <42932670.9060106@verisignlabs.com> References: <428CE13A.4070503@verisignlabs.com> <428CF96B.4090806@verisignlabs.com> <20050520125231.GE17267@chinook.corpit.vrsn.com> <42932670.9060106@verisignlabs.com> Organization: RIPE NCC X-Mailer: Sylpheed version 1.0.3 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.009725 / -5.9 X-RIPE-Signature: d62591095eaed274d0de6d5741ffcdcf X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 24 May 2005 09:04:48 -0400 David Blacka wrote: > I think that it is well understood by this WG that qtype=* won't cause a > cache to attempt to fetch "all" records of the qtype/qclass. But what > is a caching resolver required to do when there are zero records > matching qname/qclass in its cache? How does this affect validation? Sending back an NOERROR packet with an empty answer section, _without_ the NSEC to proof it, ad bit set. Any client that would want to "proof" this answer would need to take into account that it queried QTYPE="*" and that a completely empty packet is one of the things that can be returned. I'd think... -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC ---------------------------------| JID: olaf at jabber.secret-wg.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue May 24 10:56:00 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07416 for ; Tue, 24 May 2005 10:56:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Daan0-0005Id-5m for namedroppers-data@psg.com; Tue, 24 May 2005 14:53:50 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Daamy-0005IB-5M for namedroppers@ops.ietf.org; Tue, 24 May 2005 14:53:48 +0000 Received: by postman.ripe.net (Postfix, from userid 4008) id DF4E3247B8; Tue, 24 May 2005 16:53:43 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 3F06524BBF; Tue, 24 May 2005 16:53:42 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id j4OErg45014131; Tue, 24 May 2005 16:53:42 +0200 Date: Tue, 24 May 2005 16:53:42 +0200 From: "Olaf M. Kolkman" To: Simon Josefsson Cc: weiler@tislabs.com, namedroppers@ops.ietf.org Subject: Re: rfc2538bis IANA considerations Message-Id: <20050524165342.0a726d2b.olaf@ripe.net> In-Reply-To: References: <6.1.2.0.2.20041011160917.070d8ec0@localhost> <20041012080533.GA17012@nic.fr> <6.1.2.0.2.20041012100511.0766efd0@localhost> Organization: RIPE NCC X-Mailer: Sylpheed version 1.0.3 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.000000 / -5.9 X-RIPE-Signature: fbdada65fe09be1ee8fc6af401d6769a X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit My 0.02 Euro: If we can identify cases where the algorithm number match between KEY/DNSKEY/CERT _will_ lead to (interoperability) problems we should make sure we address those problems. If the match _might_ lead to problems --- and nobody really knows how to catch that in text that would fit into the draft --- then I'd say lets get this beast moving. --Olaf > > -- Sam > > > > On Tue, 22 Mar 2005, Samuel Weiler wrote: > > > >> I think there are two remaining open questions related to the CERT RR > >> and the DNSSEC algorithm number registry. Any input? Do we want to > >> allow CERT RRs to contain ALL algorithm types specified in this > >> registry, or do we want to add another applicability list? > >> > >> > > -- Can CERTs use private algorithms (type 253/254)? If so, do you > >> > > still want to use the same encoding as for KEY/DNSKEY, with the > >> > > algorithm in the RDATA? Some explicit mention of the private > >> > > algorithms might be a good idea, in any case. Also note David > >> > > Blacka's DNSSEC experiment draft, which encourages use of > >> > > the private algorithms. > >> > > >> > I have no idea how to address this, nor can I answer the question. I > >> > hope that others will give input on this. > >> > > >> > > -- Given that 3755 added applicablility columns to the algorithm > >> > > registry (see the registry itself and 3755 for details), do you > >> > > want another column for CERT, along with a requirement that new > >> > > algorithm definitions say whether they can be used for CERTs or > >> > > not? > >> > > >> > It seem to require some work for new algorithm definers. My > >> > experience is that the key tag and algorithm fields of CERT RRs are > >> > rarely useful, nor consistently populated. So the additional work > >> > will lead to little practical advantage, in my opinion. That would > >> > suggest we shouldn't worry about this. > >> > > >> > However, this seem to be more of a process issue, than a technical > >> > concern, so I'd be interested to hear what others feel. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC ---------------------------------| JID: olaf at jabber.secret-wg.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue May 24 11:03:54 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08351 for ; Tue, 24 May 2005 11:03:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Daaud-0006CC-8u for namedroppers-data@psg.com; Tue, 24 May 2005 15:01:43 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DaauZ-0006BV-HY for namedroppers@ops.ietf.org; Tue, 24 May 2005 15:01:40 +0000 Received: from [10.31.32.74] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j4OF1Qqw028394; Tue, 24 May 2005 11:01:30 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <42932670.9060106@verisignlabs.com> References: <428CE13A.4070503@verisignlabs.com> <428CF96B.4090806@verisignlabs.com> <20050520125231.GE17267@chinook.corpit.vrsn.com> <42932670.9060106@verisignlabs.com> Date: Tue, 24 May 2005 11:01:32 -0400 To: David Blacka From: Edward Lewis Subject: Re: Glue (was Re: validating a qtype=* response) Cc: Edward Lewis , Matt Larson , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 9:04 -0400 5/24/05, David Blacka wrote: >I think that it is well understood by this WG that qtype=* won't cause a >cache to attempt to fetch "all" records of the qtype/qclass. But what >is a caching resolver required to do when there are zero records matching >qname/qclass in its cache? How does this affect validation? For the first question - it seems that BIND (as an example DNS implementation) will recursively issue the query if recursion is available. For the second question - each individual RRSet in the answer ought to be validated of course. This includes pertinence to the question asked - in this case, just the name and type have to be exact matches. There is a dilemma over the setting of the AD bit though. On the one hand, the AD bit is supposed to indicate the "security" of the records in the answer and authority section. On the other hand, DNSSEC promises "data integrity." The difference is the records that might "fall out" of the answer section in a qtype=* answer. The qtype=* processing never promised data integrity - so I don't think it is fair to expect that DNSSEC will promise this now. So, my expectation would be to set the AD bit if all the present RRSets are pertinent (and germane) and pass the authentication/integrity checks as if the RRSet was standing alone in a request for its type. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue May 24 11:20:03 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09806 for ; Tue, 24 May 2005 11:20:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dab8E-0007c5-OC for namedroppers-data@psg.com; Tue, 24 May 2005 15:15:46 +0000 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Dab8D-0007bf-EN for namedroppers@ops.ietf.org; Tue, 24 May 2005 15:15:45 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-1) with ESMTP id j4OFFbwG031494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 May 2005 17:15:39 +0200 From: Simon Josefsson To: "Olaf M. Kolkman" Cc: weiler@tislabs.com, namedroppers@ops.ietf.org Subject: Re: rfc2538bis IANA considerations References: <6.1.2.0.2.20041011160917.070d8ec0@localhost> <20041012080533.GA17012@nic.fr> <6.1.2.0.2.20041012100511.0766efd0@localhost> <20050524165342.0a726d2b.olaf@ripe.net> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:050524:olaf@ripe.net::aTEi9NXUZS4oS98q:3bQ/ X-Hashcash: 1:21:050524:namedroppers@ops.ietf.org::YJZBGu4kCXEwoaht:5lWt X-Hashcash: 1:21:050524:weiler@tislabs.com::52HhNd7xB5M9ApDP:UQzW Date: Tue, 24 May 2005 17:15:37 +0200 In-Reply-To: <20050524165342.0a726d2b.olaf@ripe.net> (Olaf M. Kolkman's message of "Tue, 24 May 2005 16:53:42 +0200") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk My input on this would be that none of my uses of CERT pay much attention to the algorithm number field (nor the key tag) anyway. So from my point of view, I cannot identify any scenario where this will matter. Input from others appreciated. Thanks, Simon "Olaf M. Kolkman" writes: > My 0.02 Euro: > > If we can identify cases where the algorithm number match between > KEY/DNSKEY/CERT _will_ lead to (interoperability) problems we should > make sure we address those problems. If the match _might_ lead to > problems --- and nobody really knows how to catch that in text that would > fit into the draft --- then I'd say lets get this beast moving. > > --Olaf > > > >> > -- Sam >> > >> > On Tue, 22 Mar 2005, Samuel Weiler wrote: >> > >> >> I think there are two remaining open questions related to the CERT RR >> >> and the DNSSEC algorithm number registry. Any input? Do we want to >> >> allow CERT RRs to contain ALL algorithm types specified in this >> >> registry, or do we want to add another applicability list? >> >> >> >> > > -- Can CERTs use private algorithms (type 253/254)? If so, do you >> >> > > still want to use the same encoding as for KEY/DNSKEY, with the >> >> > > algorithm in the RDATA? Some explicit mention of the private >> >> > > algorithms might be a good idea, in any case. Also note David >> >> > > Blacka's DNSSEC experiment draft, which encourages use of >> >> > > the private algorithms. >> >> > >> >> > I have no idea how to address this, nor can I answer the question. I >> >> > hope that others will give input on this. >> >> > >> >> > > -- Given that 3755 added applicablility columns to the algorithm >> >> > > registry (see the registry itself and 3755 for details), do you >> >> > > want another column for CERT, along with a requirement that new >> >> > > algorithm definitions say whether they can be used for CERTs or >> >> > > not? >> >> > >> >> > It seem to require some work for new algorithm definers. My >> >> > experience is that the key tag and algorithm fields of CERT RRs are >> >> > rarely useful, nor consistently populated. So the additional work >> >> > will lead to little practical advantage, in my opinion. That would >> >> > suggest we shouldn't worry about this. >> >> > >> >> > However, this seem to be more of a process issue, than a technical >> >> > concern, so I'd be interested to hear what others feel. >> >> -- >> to unsubscribe send a message to namedroppers-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: >> > > > -- > > ---------------------------------| Olaf M. Kolkman > ---------------------------------| RIPE NCC > ---------------------------------| JID: olaf at jabber.secret-wg.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue May 24 15:18:52 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03742 for ; Tue, 24 May 2005 15:18:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DaeqU-00012P-UB for namedroppers-data@psg.com; Tue, 24 May 2005 19:13:42 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DaeqT-000128-1X for namedroppers@ops.ietf.org; Tue, 24 May 2005 19:13:41 +0000 Received: from [10.131.244.227] ([::ffff:172.25.170.10]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.verisignlabs.com with esmtp; Tue, 24 May 2005 15:13:39 -0400 id 005948D3.42937CE3.0000149B Message-ID: <42937CE3.7020105@verisignlabs.com> Date: Tue, 24 May 2005 15:13:39 -0400 From: David Blacka Organization: VeriSign, Inc. User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Edward Lewis CC: namedroppers@ops.ietf.org Subject: Re: Glue (was Re: validating a qtype=* response) References: <428CE13A.4070503@verisignlabs.com> <428CF96B.4090806@verisignlabs.com> <20050520125231.GE17267@chinook.corpit.vrsn.com> <42932670.9060106@verisignlabs.com> In-Reply-To: X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward Lewis wrote: > At 9:04 -0400 5/24/05, David Blacka wrote: > >> I think that it is well understood by this WG that qtype=* won't cause a >> cache to attempt to fetch "all" records of the qtype/qclass. But what >> is a caching resolver required to do when there are zero records matching >> qname/qclass in its cache? How does this affect validation? > > > For the first question - it seems that BIND (as an example DNS > implementation) will recursively issue the query if recursion is available. > > For the second question - each individual RRSet in the answer ought to > be validated of course. This includes pertinence to the question asked > - in this case, just the name and type have to be exact matches. There > is a dilemma over the setting of the AD bit though. > > On the one hand, the AD bit is supposed to indicate the "security" of > the records in the answer and authority section. On the other hand, > DNSSEC promises "data integrity." The difference is the records that > might "fall out" of the answer section in a qtype=* answer. > > The qtype=* processing never promised data integrity - so I don't think > it is fair to expect that DNSSEC will promise this now. Agreed. > So, my expectation would be to set the AD bit if all the present RRSets > are pertinent (and germane) and pass the authentication/integrity checks > as if the RRSet was standing alone in a request for its type. Fair enough. This is the positive response case, and I think that it is reasonable. Let's look at negative responses. RCODE=3 (Name Error) responses to qtype=* look to be no different from the normal case. NOERROR/NODATA responses to qtype=* are questionable, in my mind. And the central question is this: must a NOERROR/NODATA response to a qtype=* query have a validated NSEC in authority section proving that qname is an empty non-terminal to be considered valid? Another way of asking this question is: are (full/caching/recursive) resolvers required to recurse on a qtype=* query if no records with qname+qclass are present in the cache (even if a child of qname *is* present in the cache)? -- 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 May 24 15:42:51 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06239 for ; Tue, 24 May 2005 15:42:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DafGq-0002qo-Qd for namedroppers-data@psg.com; Tue, 24 May 2005 19:40:56 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DafGp-0002qO-2Q for namedroppers@ops.ietf.org; Tue, 24 May 2005 19:40:55 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05835; Tue, 24 May 2005 15:40:52 -0400 (EDT) Message-Id: <200505241940.PAA05835@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-bis-updates-01.txt Date: Tue, 24 May 2005 15:40:52 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Clarifications and Implementation Notes for DNSSECbis Author(s) : S. Weiler Filename : draft-ietf-dnsext-dnssec-bis-updates-01.txt Pages : 11 Date : 2005-5-24 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 possible DNSSECbis errata. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-bis-updates-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-bis-updates-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-bis-updates-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-24154908.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-bis-updates-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-bis-updates-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-24154908.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 May 24 15:44:35 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06657 for ; Tue, 24 May 2005 15:44:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DafIv-00031R-2j for namedroppers-data@psg.com; Tue, 24 May 2005 19:43:05 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DafIt-000312-BV for namedroppers@ops.ietf.org; Tue, 24 May 2005 19:43:03 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id C4265677EF for ; Tue, 24 May 2005 19:43:02 +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.3/8.13.1) with ESMTP id j4OJgiRc006056; Wed, 25 May 2005 05:42:44 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200505241942.j4OJgiRc006056@drugs.dv.isc.org> To: David Blacka Cc: Edward Lewis , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Glue (was Re: validating a qtype=* response) In-reply-to: Your message of "Tue, 24 May 2005 15:13:39 -0400." <42937CE3.7020105@verisignlabs.com> Date: Wed, 25 May 2005 05:42:44 +1000 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Edward Lewis wrote: > > At 9:04 -0400 5/24/05, David Blacka wrote: > > > >> I think that it is well understood by this WG that qtype=* won't cause a > >> cache to attempt to fetch "all" records of the qtype/qclass. But what > >> is a caching resolver required to do when there are zero records matching > >> qname/qclass in its cache? How does this affect validation? > > > > > > For the first question - it seems that BIND (as an example DNS > > implementation) will recursively issue the query if recursion is available. > > > > For the second question - each individual RRSet in the answer ought to > > be validated of course. This includes pertinence to the question asked > > - in this case, just the name and type have to be exact matches. There > > is a dilemma over the setting of the AD bit though. > > > > On the one hand, the AD bit is supposed to indicate the "security" of > > the records in the answer and authority section. On the other hand, > > DNSSEC promises "data integrity." The difference is the records that > > might "fall out" of the answer section in a qtype=* answer. > > > > The qtype=* processing never promised data integrity - so I don't think > > it is fair to expect that DNSSEC will promise this now. > > Agreed. > > > So, my expectation would be to set the AD bit if all the present RRSets > > are pertinent (and germane) and pass the authentication/integrity checks > > as if the RRSet was standing alone in a request for its type. > > Fair enough. This is the positive response case, and I think that it is > reasonable. Let's look at negative responses. > > RCODE=3 (Name Error) responses to qtype=* look to be no different from > the normal case. > > NOERROR/NODATA responses to qtype=* are questionable, in my mind. And > the central question is this: must a NOERROR/NODATA response to a > qtype=* query have a validated NSEC in authority section proving that > qname is an empty non-terminal to be considered valid? This is the correct response to a empty non-terminal. One can cache this response and validate this response. > Another way of asking this question is: are (full/caching/recursive) > resolvers required to recurse on a qtype=* query if no records with > qname+qclass are present in the cache (even if a child of qname *is* > present in the cache)? > > -- > 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 Tue May 24 16:40:41 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22841 for ; Tue, 24 May 2005 16:40:41 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dag9R-0007RW-PB for namedroppers-data@psg.com; Tue, 24 May 2005 20:37:21 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Dag9Q-0007RF-Ot for namedroppers@ops.ietf.org; Tue, 24 May 2005 20:37:21 +0000 Received: from [10.31.32.74] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j4OKbAmP029723; Tue, 24 May 2005 16:37:10 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <42937CE3.7020105@verisignlabs.com> References: <428CE13A.4070503@verisignlabs.com> <428CF96B.4090806@verisignlabs.com> <20050520125231.GE17267@chinook.corpit.vrsn.com> <42932670.9060106@verisignlabs.com> <42937CE3.7020105@verisignlabs.com> Date: Tue, 24 May 2005 16:37:14 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: Glue (was Re: validating a qtype=* response) Cc: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Apologies in advance for this being somewhat disoriented... At 15:13 -0400 5/24/05, David Blacka wrote: ... >Let's look at negative responses. ... >NOERROR/NODATA responses to qtype=* are questionable, in my mind. And >the central question is this: must a NOERROR/NODATA response to a >qtype=* query have a validated NSEC in authority section proving that >qname is an empty non-terminal to be considered valid? > >Another way of asking this question is: are (full/caching/recursive) >resolvers required to recurse on a qtype=* query if no records with >qname+qclass are present in the cache (even if a child of qname *is* >present in the cache)? You'll never get a NOERROR/NODATA response for qtype=* queries of leaf nodes. So this boils down to cases of non-terminals. Since we are talking about resolvers (as in RFC 1034 5.3's definition here), the scripture we want is in section 5.3.3, beginning with: # 1. See if the answer is in local information, and if so return # it to the client. # # 2. Find the best servers to ask. For step 1, here's a head-scratcher. Is the existence of a non-terminal name inferred by the presence of data for any of its descendents? An answer is in local information if it has been asked for before (within the TTL). Local information could be positive answers or the negative cache. If the non-terminal is inferred (the head scratching question), then NOERROR/NODATA is appropriate, but this can't be supported with any records from the cache. For this reason I don't think "inferred names" ought to be in the cache. Answering about things you don't know about is like synthesizing wild cards in the cache. If the non-terminal is empty, then if it is "in local information" it will be in the negative cache. (I.e., someone asked for it, and got no answer records.) A query of qtype=* will return NOERROR/NODATA with the negative cache "proof." If the non-terminal has data (at least as it is present in the cache), then there won't be a NOERROR/NODATA return. In other cases, the non-terminal is not known and you resume with step 2. So - in summary, what I am saying is that you should only return NOERROR/NODATA for a qtype=* when the name is a previously sought empty non-terminal, in the negative cache. The existence of names ought never be inferred by a cache, if a name is not explicitly in local information, and recursion is permitted, the server ought to recurse. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From WinnieHill@kitars.com Wed May 25 03:57:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16767 for ; Wed, 25 May 2005 03:57:58 -0400 (EDT) Received: from [61.73.93.25] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dar4Q-0005Ca-En for dnsext-archive@ietf.org; Wed, 25 May 2005 04:16:57 -0400 Received: from De1@localhost by qS3.int (8.11.6/8.11.6); Wed, 25 May 2005 04:18:45 -0500 Message-ID: From: "Winnie Fulton" Reply-To: "Winnie Fulton" To: dnsext-archive@ietf.org Subject: Photoshop Products available for Download Date: Wed, 25 May 2005 07:27:45 -0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: WinnieHill@kitars.com Content-Type: multipart/mixed; boundary="--tPPWsZuuIEzQ0jNsf" X-Spam-Score: 6.2 (++++++) X-Spam-Flag: YES X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935 zGt ----tPPWsZuuIEzQ0jNsf Content-Type: text/html; Content-Transfer-Encoding: quoted-printable o
Opt-in Email Special Offer &n= bsp;   unsubscribe me
<= tbody><= /td>
=
SEARCH

<= td vAlign=3Dbottom>

TOP 10 NEW TITLES

<= td width=3D4>  Microsoft=

 = ON SALE NOW!

 1 Office Pro 2003
 2 Windows XP Pro
 3 Adobe Creative Suite Premium
&nbs= p;4 Norton Antivirus 2005
 5 Flash MX 2004
 6 Corel Draw 12
 7 Adobe Acrobat 7.0
 8 Windows 2003 Server
 9 Alias Maya 6 Wavefrt
10 Adobe Premiere
 = See more by this manufacturer=
  
&= nbsp;  Apple Software
  Customers also bought
   these oth= er items...



Microsoft Office Professional= Edition *2003*
Microsoft
<= td vAlign=3Dtop noWrap>
Choose:
<= tr>
 
List Price:$899.00
Price:$69.99<= /b>
You Save:$830.01 (92= %)



Availability:= Available for INSTANT download!
Coupon Code: ISe229
Media: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

Featur= es:

  • Analyze and manage business information using Access databases
  • Exchange data with other systems u= sing enhanced XML technology
  • Control information sharing rules with enhanced IRM technology
  • Easy-to-use wizards to create e-mail n= ewsletters and printed marketing materials
  • = More than 20 preformatted business reports
    • Sales Rank: #1
    Ship= ping: International/US or via instant download
    Date Coupon Expi= res: June 30th, 2005
    Average Customer= Review: 3D"5 Based on 1,768 reviews. Write a review.
    <= td class=3Dsmall vAlign=3Dtop noWrap align=3Dright height=3D18 width=3D73>= List Price:
    Microsoft Windows XP= Professional or Longhorn Edition
    Microsoft
    Choose:
     

    <= a href=3Dhttp://expansionsoft.com/?8>

    $279.00
    Price:$49.99
    You Save= :$229.01 (85%)



    Availability: Available for INSTANT download!<= br> Coupon Code: ISe229
    Media: CD-ROM / Download

    System = requirements  |  Acces= sories  |  Other Versi= ons

    Features:=

    • Designed for businesses o= f all sizes
    • Manage digital p= ictures, music, video, DVDs, and more
    • More security with the ability to encrypt files and folders
    • Built-in voice, video, and insta= nt messaging support
    • Integra= tion with Windows servers and management solutions

    Sales Rank: #2
    Shipping: In= ternational/US or via instant download
    Date Coupon Expires: Jun= e 30th, 2005
    Average Customer Review:= 3D"5 Based on 868 reviews. Writ= e a review.

    Adobe Photoshop CS2 V 9.0
    Adobe
    Choose:
     

    List Price: $599.00
    Price:$69.99
    You Save:$529.01 (90%)


    Availability: Available for INSTANT download!
    Coupon Code:= ISe229
    Media: CD-ROM / Download

    System requirements&nb= sp; |  Accessories  |&= nbsp; Other Versions

    <= p>Features:

      Customized workspace; save personalized wor= kspace and tool settings; create customized shortcuts
    • Unparalleled efficiency--automate production ta= sks with built-in or customized scripts
    • Improved file management, new design possibilities, and a more= intuitive way to create for the Web
    • Support for 16-bit images, digital camera raw data, and non-squar= e pixels
    • Create or modify ph= otos using painting, drawing, and retouching tools

    Sales Rank: #3
    Shipping:= International/US or via instant download
    Date Coupon Expires:<= /b> June 30th, 2005
    Average Customer Revi= ew: 3D"5 Based on 498 reviews. Write a review.

----tPPWsZuuIEzQ0jNsf-- From LyndaEnriquez@churchism.com Wed May 25 14:04:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05160 for ; Wed, 25 May 2005 14:04:14 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Db0XF-0004V3-CE for dnsext-archive@ietf.org; Wed, 25 May 2005 14:23:18 -0400 Received: from c192-215.i03-1.onvol.net ([213.217.192.215]) by mx2.foretec.com with smtp (Exim 4.24) id 1Db0Dj-0006bt-Ul for dnsext-archive@ietf.org; Wed, 25 May 2005 14:03:09 -0400 Received: from caKN@localhost by 4avU.int (8.11.6/8.11.6); Thu, 26 May 2005 01:05:15 +0600 Message-ID: From: "Kelly Neufeld" Reply-To: "Kelly Neufeld" To: dnsext-archive@ietf.org Subject: OEM software wholesale savings Win XP Date: Wed, 25 May 2005 23:08:15 +0400 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: LyndaEnriquez@churchism.com Content-Type: multipart/mixed; boundary="--BheC7hDwE3jp9KmNx" X-Spam-Score: 6.1 (++++++) X-Spam-Flag: YES X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 fuM ----BheC7hDwE3jp9KmNx Content-Type: text/html; Content-Transfer-Encoding: quoted-printable m
Opt-in Email Special Offer &n= bsp;   unsubscribe me
<= td class=3Dsmall align=3Dmiddle bgColor=3D#ffffdd width=3D707>
=
<= td width=3D5 bgcolor=3D#000080>
SEARCH

TOP 10 NEW TITLES

=

 = ON SALE NOW!

 1 Offi= ce Pro 2003
 2 Windows XP= Pro
 3 Adobe Creative S= uite Premium
 4 Norton An= tivirus 2005
 5 Flash MX = 2004
 6 Corel Draw 12
 7 Adobe Acrobat= 7.0
 8 Windows 2003 Ser= ver
 9 Alias Maya 6 Wave= frt
 10 Adobe Premiere
  See more by this m= anufacturer
   Microsoft
   Apple Software
  Customers also bought
   these other ite= ms...



Microsoft Office Professional Editi= on *2003*
Micro= soft
Choose:
 
 List Price:$899.00
Price:$69.99
You Save= :$830.01 (92%)



Availability: Available for INSTANT download!
<= b>Coupon Code: ISe229
Media: CD-ROM / Download
<= br> System requirements=   |  Accessories  |&= nbsp; Other Versions

Features:

  • Analyze and manage business information using Access d= atabases
  • Exchange data with = other systems using enhanced XML technology
  • Control information sharing rules with enhanced IRM techno= logy
  • Easy-to-use wizards to = create e-mail newsletters and printed marketing materials
    • More than 20 preformatted business reports <= /font>
Sales Rank: #1
Shipping: International/US or via instant download
D= ate Coupon Expires: June 30th, 2005
A= verage Customer Review: 3D"5 Based on 1,768 reviews. Write a review.
Microsoft Wind= ows XP Professional or Longhorn Edition
Microsoft
Choose:
 

=
List Price:$279.00
Price:= $49.99
You Save:$229.01 (85%)


Availability: Available for INSTANT download!
Coupon Code:= ISe229
Media: CD-ROM / Download

System requirements  |&n= bsp; Accessories  |  Other Versions

Fea= tures:

  • Designed for businesses of all sizes
  • Manage digital pictures, music, video, DVDs, and more
  • More security with the ability t= o encrypt files and folders
  • = Built-in voice, video, and instant messaging support
  • Integration with Windows servers and management s= olutions

Sales Rank: #2
= Shipping: International/US or via instant download
= Date Coupon Expires: June 30th, 2005
Average Customer Review: 3D"5 Based on 868 reviews. Write a review.

Adobe Photoshop= CS2 V 9.0
Adob= e
Choose:
 

List Pri= ce: $599.00
Pric= e:$69.99
You Save:<= span class=3Dprice>$529.01 (90%)


=
Availability: Available for INSTANT download!
Coupon Co= de: ISe229
Media: CD-ROM / Download

System requirements  = |  Accessories  |  Other Versions

Features:

  • Customized workspace; save personalized workspace and tool se= ttings; create customized shortcuts
  • Unparalleled efficiency--automate production tasks with built-in = or customized scripts
  • Improv= ed file management, new design possibilities, and a more intuitive way to = create for the Web
  • Support f= or 16-bit images, digital camera raw data, and non-square pixels
  • Create or modify photos using paintin= g, drawing, and retouching tools

Sales Rank: #3
Shipping: International= /US or via instant download
Date Coupon Expires: June 30th, 200= 5
Average Customer Review: 3D"5 B= ased on 498 reviews. Write a review.

= ----BheC7hDwE3jp9KmNx-- From owner-namedroppers@ops.ietf.org Wed May 25 15:51:38 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15685 for ; Wed, 25 May 2005 15:51:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Db1qD-000OoD-2W for namedroppers-data@psg.com; Wed, 25 May 2005 19:46:57 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Db1qB-000On7-85 for namedroppers@ops.ietf.org; Wed, 25 May 2005 19:46:55 +0000 Received: from [10.31.32.74] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j4PJkjbo034474; Wed, 25 May 2005 15:46:46 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Wed, 25 May 2005 15:46:02 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: wild cards Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In case anyone hadn't noticed, there's a -07 wcard draft out there. I have no outstanding items to include in a next version other than to paginate it and add a table of contents. I'm waiting to do that until the subject matter settled down. If there are more items to include, please speak up. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed May 25 15:54:53 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16360 for ; Wed, 25 May 2005 15:54:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Db1vu-000PIl-KQ for namedroppers-data@psg.com; Wed, 25 May 2005 19:52:50 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Db1vr-000PIH-Rh for namedroppers@ops.ietf.org; Wed, 25 May 2005 19:52:48 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15875; Wed, 25 May 2005 15:52:45 -0400 (EDT) Message-Id: <200505251952.PAA15875@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-rfc2538bis-02.txt Date: Wed, 25 May 2005 15:52:45 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Storing Certificates in the Domain Name System (DNS) Author(s) : S. Josefsson Filename : draft-ietf-dnsext-rfc2538bis-02.txt Pages : 14 Date : 2005-5-25 Cryptographic public key are frequently published and their authenticity demonstrated by certificates. A CERT resource record (RR) is defined so that such certificates and related certificate revocation lists can be stored in the Domain Name System (DNS). See for more information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2538bis-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-rfc2538bis-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-rfc2538bis-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-25160039.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-rfc2538bis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-rfc2538bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-25160039.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 May 25 20:07:45 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10189 for ; Wed, 25 May 2005 20:07:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Db5nv-000NYW-Ek for namedroppers-data@psg.com; Thu, 26 May 2005 00:00:51 +0000 Received: from [168.61.5.27] (helo=harry.mail-abuse.org) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Db5nt-000NYE-Lo for namedroppers@ops.ietf.org; Thu, 26 May 2005 00:00:49 +0000 Received: from SJC-Office-DHCP-156.Mail-Abuse.ORG (SJC-Office-DHCP-156.Mail-Abuse.ORG [168.61.10.156]) by harry.mail-abuse.org (Postfix) with ESMTP id 4A64C414F5 for ; Wed, 25 May 2005 17:00:49 -0700 (PDT) Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt From: Douglas Otis To: IETF DNSEXT WG In-Reply-To: References: Content-Type: text/plain Date: Wed, 25 May 2005 17:00:48 -0700 Message-Id: <1117065648.14235.151.camel@SJC-Office-DHCP-156.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 2005-05-20 at 15:26 -0500, wayne wrote: > My intention is that after a two week review, I will make a "final" > revised draft and ask the IESG to consider it for a Proposed Standard > status. There is a request on the spf-discuss list that those who consider SPF flawed place their comments at: http://www.imc.org/ietf-mxcomp/index.html -Doug -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From FranGrimes@4window.co.uk Thu May 26 02:55:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04023 for ; Thu, 26 May 2005 02:55:16 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbCZW-0000b6-3g for dnsext-archive@ietf.org; Thu, 26 May 2005 03:14:28 -0400 Received: from c-24-14-49-243.hsd1.il.comcast.net ([24.14.49.243]) by mx2.foretec.com with smtp (Exim 4.24) id 1DbCGw-0000SB-WB for dnsext-archive@ietf.org; Thu, 26 May 2005 02:55:15 -0400 Received: from CIqY@localhost by FD8.int (8.11.6/8.11.6); Thu, 26 May 2005 11:22:24 +0300 Message-ID: <24bBicr5YltHrGQH0kdP@agribusiness.co.uk> From: "Barbara Wray" Reply-To: "Barbara Wray" To: dnsext-archive@ietf.org Subject: MS Office XP Pro $49.95 XP Pro Date: Thu, 26 May 2005 03:17:24 -0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: FranGrimes@4window.co.uk Content-Type: multipart/mixed; boundary="--dmHRj3BSd4S8GvLk" X-Spam-Score: 0.3 (/) X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935 Mu4L ----dmHRj3BSd4S8GvLk Content-Type: text/html; Content-Transfer-Encoding: quoted-printable U
Opt-in Email Special Offer &n= bsp;   unsubscribe me
<= tbody><= /td>
=
SEARCH

<= td vAlign=3Dbottom>

TOP 10 NEW TITLES

<= td width=3D4>  Microsoft=

 = ON SALE NOW!

 1 Office Pro 2003
 2 Windows XP Pro
 3 Adobe Creative Suite Premium
&nbs= p;4 Norton Antivirus 2005
 5 Flash MX 2004
 6 Corel Draw 12
 7 Adobe Acrobat 7.0
 8 Windows 2003 Server
 9 Alias Maya 6 Wavefrt
10 Adobe Premiere
 = See more by this manufacturer=
  
&= nbsp;  Apple Software
  Customers also bought
   these oth= er items...



Microsoft Office Professional= Edition *2003*
Microsoft
<= td vAlign=3Dtop noWrap>
Choose:
<= tr>
 
List Price:$899.00
Price:$69.99<= /b>
You Save:$830.01 (92= %)



Availability:= Available for INSTANT download!
Coupon Code: ISe229
Media: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

Featur= es:

  • Analyze and manage business information using Access databases
  • Exchange data with other systems u= sing enhanced XML technology
  • Control information sharing rules with enhanced IRM technology
  • Easy-to-use wizards to create e-mail n= ewsletters and printed marketing materials
  • = More than 20 preformatted business reports
    • Sales Rank: #1
    Ship= ping: International/US or via instant download
    Date Coupon Expi= res: June 30th, 2005
    Average Customer= Review: 3D"5 Based on 1,768 reviews. Write a review.
    <= td class=3Dsmall vAlign=3Dtop noWrap align=3Dright height=3D18 width=3D73>= List Price:
    Microsoft Windows XP= Professional or Longhorn Edition
    Microsoft
    Choose:
     

    <= a href=3Dhttp://expansionsoft.com/?b>

    $279.00
    Price:$49.99
    You Save= :$229.01 (85%)



    Availability: Available for INSTANT download!<= br> Coupon Code: ISe229
    Media: CD-ROM / Download

    System = requirements  |  Acces= sories  |  Other Versi= ons

    Features:=

    • Designed for businesses o= f all sizes
    • Manage digital p= ictures, music, video, DVDs, and more
    • More security with the ability to encrypt files and folders
    • Built-in voice, video, and insta= nt messaging support
    • Integra= tion with Windows servers and management solutions

    Sales Rank: #2
    Shipping: In= ternational/US or via instant download
    Date Coupon Expires: Jun= e 30th, 2005
    Average Customer Review:= 3D"5 Based on 868 reviews. Writ= e a review.

    Adobe Photoshop CS2 V 9.0
    Adobe
    Choose:
     

    List Price: $599.00
    Price:$69.99
    You Save:$529.01 (90%)


    Availability: Available for INSTANT download!
    Coupon Code:= ISe229
    Media: CD-ROM / Download

    System requirements&nb= sp; |  Accessories  |&= nbsp; Other Versions

    <= p>Features:

      Customized workspace; save personalized wor= kspace and tool settings; create customized shortcuts
    • Unparalleled efficiency--automate production ta= sks with built-in or customized scripts
    • Improved file management, new design possibilities, and a more= intuitive way to create for the Web
    • Support for 16-bit images, digital camera raw data, and non-squar= e pixels
    • Create or modify ph= otos using painting, drawing, and retouching tools

    Sales Rank: #3
    Shipping:= International/US or via instant download
    Date Coupon Expires:<= /b> June 30th, 2005
    Average Customer Revi= ew: 3D"5 Based on 498 reviews. Write a review.

----dmHRj3BSd4S8GvLk-- From owner-namedroppers@ops.ietf.org Thu May 26 10:22:20 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02276 for ; Thu, 26 May 2005 10:22:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DbJ9w-000MMP-BC for namedroppers-data@psg.com; Thu, 26 May 2005 14:16:28 +0000 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DbJ9t-000MM5-NB for namedroppers@ops.ietf.org; Thu, 26 May 2005 14:16:25 +0000 Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j4QEFuaN013147 for ; Thu, 26 May 2005 10:15:57 -0400 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id j4QEFi6u020060 for ; Thu, 26 May 2005 10:15:45 -0400 (EDT) From: "Scott Rose" To: "DNSEXT WG" Subject: First draft of EDNS0 interop test Date: Thu, 26 May 2005 10:15:44 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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.1478 Importance: Normal X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This probably won't be posted as an official Internet Draft yet, since it's only a test plan and not an interoperability test. Comments most welcome - looking to make this test plan better before producing the formal write up of the EDNS0 interop test. Please note the comment on Test 10 below - it addresses Section 5.3 in RFC2671, which has been noted before on namedroppers to be a possible ambiguity in the spec. Scott ---------------------------------------------------------------------------- -- Network Working Group J. Quanaim Internet-Draft Lucent Expires: November 27, 2005 S. Rose NIST May 26, 2005 Interoperability Test for Extension Mechanism for DNS (EDNS) Version 0 draft-qr-rfc2671-interop-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 27, 2005. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract The Extension Mechanism for DNS (EDNS) is described in RFC 2671 and is a base pre-requisite for other extensions to the DNS such as DNSSEC and IPv6 support. This document lays out a plan to test the interoperability of clients and servers that claim EDNS version 0 implementation. Quanaim & Rose Expires November 27, 2005 [Page 1] Internet-Draft EDNS0-Interop May 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 Non-EDNS0 Aware Client Request to a Non-EDNS0 Aware Server . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2 Non-EDNS0 Aware Client Request to an EDNS0 Aware Server . 4 2.3 EDNS0 Aware Client Request to a Non-EDNS0 Aware Server . . 4 2.4 EDNS0 Client Request to an EDNS0 Aware Server . . . . . . 5 3. Candidate Software . . . . . . . . . . . . . . . . . . . . . . 7 4. External issues . . . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1 Normative References . . . . . . . . . . . . . . . . . . . 11 7.2 Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . 12 Quanaim & Rose Expires November 27, 2005 [Page 2] Internet-Draft EDNS0-Interop May 2005 1. Introduction The Extension Mechanisms for DNS (EDNS0) expands the DNS message format allowing for larger DNS packets, additional signaling, and more error types. It does this while preserving the original format of the DNS message and should therefore be backwards compatible. EDNS0 defines a new RR, OPT to provide this functionality. Please refer to RFC2671 [1] for further details. Quanaim & Rose Expires November 27, 2005 [Page 3] Internet-Draft EDNS0-Interop May 2005 2. Tests The following matrix shows the possible interactions between a client and server of which each may or may not be EDNS0 aware. Furthermore, a server may be either authoritative or caching. The section describing the exchange is listed in the corresponding cell. .---------------------------------. | non-EDNS0 server | EDNS0 server | .------------------+------------------+--------------| | non-EDNS0 client | 1 | 2 | |------------------+------------------+--------------| | EDNS0 client | 3 | 4 | '----------------------------------------------------' To test a caching server, a valid EDNS0 client and server are needed. The caching server should be placed between them to resolve requests. 2.1 Non-EDNS0 Aware Client Request to a Non-EDNS0 Aware Server There are no test cases as this should be considered within RFC 1035. EDNS0 does not affect these transactions. 2.2 Non-EDNS0 Aware Client Request to an EDNS0 Aware Server A DNS response message should never contain an unsolicited OPT RR. An OPT RR should only be provided in a response to a request that contained an OPT RR. Therefore, no EDNS0 functionally is expected in these tests. Test 1: Send non-EDNS0 query with expected result < 512 bytes. Expected result: Non-EDNS0 response Test 2: Send non-EDNS0 query with expected result > 512 bytes Expected result: Non-EDNS0 response truncated (TC bit set) Test 3: Send non-EDNS0 query for DNSSEC type (QTYPE=DNSKEY) Expected result: Non-EDNS0 response 2.3 EDNS0 Aware Client Request to a Non-EDNS0 Aware Server A non-EDNS0 aware server may generate any of the basic DNS error Quanaim & Rose Expires November 27, 2005 [Page 4] Internet-Draft EDNS0-Interop May 2005 responses such as NOTIMPL, FORMERR, or SERVFAIL in response to an EDNS0 request. Additionally, a DNS server not supporting EDNS0 may ignore the OPT RR and respond without such functionality. Test 4: Send EDNS0 request Expected result: Error response or request dropped Test 5: Send request for OPT RR (QTYPE=OPT) Expected result: Error response 2.4 EDNS0 Client Request to an EDNS0 Aware Server In these series of tests, both the client and server use EDNS0 as documented in RFC2671[1]. However, a client may introduce other extensions or later versions of EDNS to test server response codes. Test 6: Send request with a single OPT RR using normal EDNS0 semantics. Expected result: Normal DNS response with EDNS0 enabled Test 7: Send request with two OPT RRs of different values. Expected result: Error response (BADVERS) Test 8: Send request with EDNS0 version = 3 Expected result: Error response of BADVER Test 9: Send request for OPT RR (QTYPE=OPT) Expected result: Error response AUTHOR'S COMMENT: The next test may be unnecessary. However, it is the author's opinion that Section 5.3 of RFC 2671 [1] does not fully address how receivers should handle unknown extensions provided that the version numbers match. Test 10: Send request with unknown extension in OPT RDATA Quanaim & Rose Expires November 27, 2005 [Page 5] Internet-Draft EDNS0-Interop May 2005 Expected result: Undefined, possible error code response. Quanaim & Rose Expires November 27, 2005 [Page 6] Internet-Draft EDNS0-Interop May 2005 3. Candidate Software Below is the first list of possible candidate software for the interoperability tests described above. Non-EDNS aware servers and clients are necessary for the tests described in Sections 2.1 and 2.2. This list is by no means complete and suggestions for additional implementations are welcome. Authoritative Servers: BIND (8.4.X, 9.3.X), NSD (2.1.X, 2.2.X), dnsjava. Caching Servers: BIND (8.4.X, 9.3.X) Clients: dnsjava, dig(libresolv), NET::DNS (perl). No EDNS Support: MaraDNS, djbdns, Posadis. Quanaim & Rose Expires November 27, 2005 [Page 7] Internet-Draft EDNS0-Interop May 2005 4. External issues While outside the scope of this document, many existing firewall implementations block DNS packets using EDNS0 because of an outdated belief that DNS UDP packets should not exceed the size of 512 bytes. Quanaim & Rose Expires November 27, 2005 [Page 8] Internet-Draft EDNS0-Interop May 2005 5. IANA Considerations This document does not specify any new IANA considerations. Quanaim & Rose Expires November 27, 2005 [Page 9] Internet-Draft EDNS0-Interop May 2005 6. Security Considerations This document does not address any security considerations with using ENDS. Quanaim & Rose Expires November 27, 2005 [Page 10] Internet-Draft EDNS0-Interop May 2005 7. References 7.1 Normative References [1] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. 7.2 Informative References [2] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. [5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. Authors' Addresses Joe Quanaim Lucent Technologies 2C-338 600-700 Mountain Avenue Murray Hill, NJ 07974 USA Email: jdq@lucent.com Scott Rose National Institute for Standards and Technology 100 Bureau Drive Gaithersburg, MD 20899-8920 USA Email: scott.rose@nist.gov Quanaim & Rose Expires November 27, 2005 [Page 11] Internet-Draft EDNS0-Interop May 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP 11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2005). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Quanaim & Rose Expires November 27, 2005 [Page 12] Internet-Draft EDNS0-Interop May 2005 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Quanaim & Rose Expires November 27, 2005 [Page 13] -- to unsubscribe send a message to namedroppers-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 May 26 15:50:06 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27796 for ; Thu, 26 May 2005 15:50:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DbOJ8-000Nia-2E for namedroppers-data@psg.com; Thu, 26 May 2005 19:46:18 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DbOJ7-000NiL-9u for namedroppers@ops.ietf.org; Thu, 26 May 2005 19:46:17 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27003; Thu, 26 May 2005 15:46:14 -0400 (EDT) Message-Id: <200505261946.PAA27003@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-mdns-40.txt Date: Thu, 26 May 2005 15:46:14 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Linklocal Multicast Name Resolution (LLMNR) Author(s) : B. Aboba, et al. Filename : draft-ietf-dnsext-mdns-40.txt Pages : 28 Date : 2005-5-26 Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a Domain Name System (DNS) server. The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache. Since LLMNR only operates on the local link, it cannot be considered a substitute for DNS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-40.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-mdns-40.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-mdns-40.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-26161644.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-40.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-40.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-26161644.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 TerriHaney@innovations.com Sun May 29 02:20:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24019 for ; Sun, 29 May 2005 02:20:16 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcHSq-0001cT-Uv for dnsext-archive@ietf.org; Sun, 29 May 2005 02:40:04 -0400 Received: from [211.59.103.31] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1DcH9f-000348-Q4 for dnsext-archive@ietf.org; Sun, 29 May 2005 02:20:12 -0400 Received: from kbM@localhost by sQzZ.int (8.11.6/8.11.6); Sun, 29 May 2005 13:18:10 +0600 Message-ID: From: "Melanie Godfrey" Reply-To: "Melanie Godfrey" To: dnsext-archive@ietf.org Subject: MS Office XP Pro $49.95 Adobe Date: Sun, 29 May 2005 12:12:10 +0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: TerriHaney@innovations.com Content-Type: multipart/mixed; boundary="--MGdlNLvDQUpoT6Y" X-Spam-Score: 16.9 (++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 FaMC ----MGdlNLvDQUpoT6Y Content-Type: text/html; Content-Transfer-Encoding: quoted-printable e
Opt-in Email Special Offer &n= bsp;   unsubscribe me=
= = List Price:
SEARCH

TOP 10 NEW TITLES

= =

 = ON SALE NOW!

 1 Office Pro 2003
 2 W= indows XP Pro
 3 Adob= e Creative Suite Premium
 4<= a href=3Dhttp://playoffsoft.com/?Z> Norton Antivirus 2005
 = 5 Flash MX 2004
 6 Corel Draw 12
 7= Adobe Acrobat 7.0
 8 Windows 2003 Server
 = ;9 Alias Maya 6 Wavefrt
&= nbsp;10 Adobe Premiere
&= nbsp; See more by this manufacturer
   Microsoft
   Apple Softwar= e
  Customers also b= ought
   these other items...



Microsoft Office Professional Edition *2003*
Microsoft
Choose:
 
$899.00
Price:$69.99
You Save= :$830.01 (92%)



Availability: Available for INSTANT download!<= br> Coupon Code: ISe229
Media: CD-ROM / Download

System re= quirements  |  Accessori= es  |  Other Versions

Features:

  • Analyze and manage business inform= ation using Access databases
  • Exchange data with other systems using enhanced XML technology
  • Control information sharing rules with= enhanced IRM technology
  • Eas= y-to-use wizards to create e-mail newsletters and printed marketing materi= als
  • More than 20 preformatte= d business reports
Sales Ra= nk: #1
Shipping: International/US or via insta= nt download
Date Coupon Expires: June 30th, 2005
Average Customer Review: 3D"5 Based on 1,768 re= views. Write a review.
Microsoft Windows XP Professional or Longhorn Edition
<= span class=3Dsmall>Microsoft
Choose:
 = ;

= = =
List Price:$279.0= 0
Price:$49.99
You Save:$229.01 (85%)



Availability: Available for = INSTANT download!
Coupon Code: ISe229
Media: CD-ROM = / Download

System requirements  |  Accessories  |  Other Versions

Features:

  • Designed for = businesses of all sizes
  • Mana= ge digital pictures, music, video, DVDs, and more
  • More security with the ability to encrypt files and f= olders
  • Built-in voice, video= , and instant messaging support
  • Integration with Windows servers and management solutions

    • Sales Rank: #2
    Shippin= g: International/US or via instant download
    Date Coupon Expires= : June 30th, 2005
    Average Customer Re= view: 3D"5 Based on 868 reviews. Write a review.

    Adobe Photoshop CS2 V 9.0
    = Adobe
    =
    Choose:
     

    List Price:<= /td> $599.00
    Price:$69.99
    You Save:$529.01 (90%)


    Availability: Available for INSTANT download!
    Coupon Code:= ISe229
    Media: CD-ROM / Download

    System requirements = ; |  Accessories  | = ; Other Versions

    <= font size=3D1>Features:

    • Customized workspace; save personalized workspace= and tool settings; create customized shortcuts
    • Unparalleled efficiency--automate production tasks wi= th built-in or customized scripts
    • Improved file management, new design possibilities, and a more intui= tive way to create for the Web
    • Support for 16-bit images, digital camera raw data, and non-square pixel= s
    • Create or modify photos us= ing painting, drawing, and retouching tools

    Sales Rank: #3
    Shipping: In= ternational/US or via instant download
    Date Coupon Expires: Jun= e 30th, 2005
    Average Customer Review:= 3D"5 Based on 498 reviews. Write = a review.

----MGdlNLvDQUpoT6Y-- From JuliaWolfensohn@impositive.com Sun May 29 02:21:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25406 for ; Sun, 29 May 2005 02:21:53 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcHUS-0001fE-3h for dnsext-archive@ietf.org; Sun, 29 May 2005 02:41:41 -0400 Received: from cable-211143.myviscom.com ([209.62.211.143]) by mx2.foretec.com with smtp (Exim 4.24) id 1DcHBF-00034w-FO for dnsext-archive@ietf.org; Sun, 29 May 2005 02:21:50 -0400 Received: from 24.2.81.46 by 209.62.211.143; Sun, 29 May 2005 04:41:29 -0300 Message-ID: From: "Barbara Sweet" Reply-To: "Barbara Sweet" To: dnsext-archive@ietf.org Cc: 6054@ietf.org Subject: Thousands of academic software titles, 80% off, Instant Download Date: Sun, 29 May 2005 10:36:29 +0300 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.1 X-Sender: JuliaWolfensohn@impositive.com Organization: . Content-Type: multipart/mixed; boundary="--iInjP5SAEqFIgOjGdY" X-Spam-Score: 2.6 (++) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 ----iInjP5SAEqFIgOjGdY Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Q
Opt-in Email Special Offer &n= bsp;   unsubscribe me
<= td class=3Dsmall align=3Dmiddle bgColor=3D#ffffdd width=3D707>
=
<= td width=3D5 bgcolor=3D#000080>
SEARCH

TOP 10 NEW TITLES

=

 = ON SALE NOW!

 1 Offi= ce Pro 2003
 2 Windows XP= Pro
 3 Adobe Creative S= uite Premium
 4 Norton An= tivirus 2005
 5 Flash MX = 2004
 6 Corel Draw 12
 7 Adobe Acrobat= 7.0
 8 Windows 2003 Ser= ver
 9 Alias Maya 6 Wave= frt
 10 Adobe Premiere
  See more by this m= anufacturer
   Microsoft
   Apple Software
  Customers also bought
   these other ite= ms...



Microsoft Office Professional Editi= on *2003*
Micro= soft
Choose:
 
 List Price:$899.00
Price:$69.99
You Save= :$830.01 (92%)



Availability: Available for INSTANT download!
<= b>Coupon Code: ISe229
Media: CD-ROM / Download
<= br> System requirements=   |  Accessories  |&= nbsp; Other Versions

Features:

  • Analyze and manage business information using Access d= atabases
  • Exchange data with = other systems using enhanced XML technology
  • Control information sharing rules with enhanced IRM techno= logy
  • Easy-to-use wizards to = create e-mail newsletters and printed marketing materials
    • More than 20 preformatted business reports <= /font>
Sales Rank: #1
Shipping: International/US or via instant download
D= ate Coupon Expires: June 30th, 2005
A= verage Customer Review: 3D"5 Based on 1,768 reviews. Write a review.
Microsoft Wind= ows XP Professional or Longhorn Edition
Microsoft
Choose:
 

=
List Price:$279.00
Price:= $49.99
You Save:$229.01 (85%)


Availability: Available for INSTANT download!
Coupon Code:= ISe229
Media: CD-ROM / Download

System requirements  |&n= bsp; Accessories  |  Other Versions

Fea= tures:

  • Designed for businesses of all sizes
  • Manage digital pictures, music, video, DVDs, and more
  • More security with the ability t= o encrypt files and folders
  • = Built-in voice, video, and instant messaging support
  • Integration with Windows servers and management s= olutions

Sales Rank: #2
= Shipping: International/US or via instant download
= Date Coupon Expires: June 30th, 2005
Average Customer Review: 3D"5 Based on 868 reviews. Write a review.

Adobe Photoshop= CS2 V 9.0
Adob= e
Choose:
 

List Pri= ce: $599.00
Pric= e:$69.99
You Save:<= span class=3Dprice>$529.01 (90%)


=
Availability: Available for INSTANT download!
Coupon Co= de: ISe229
Media: CD-ROM / Download

System requirements  = |  Accessories  |  Other Versions

Features:

  • Customized workspace; save personalized workspace and tool se= ttings; create customized shortcuts
  • Unparalleled efficiency--automate production tasks with built-in = or customized scripts
  • Improv= ed file management, new design possibilities, and a more intuitive way to = create for the Web
  • Support f= or 16-bit images, digital camera raw data, and non-square pixels
  • Create or modify photos using paintin= g, drawing, and retouching tools

Sales Rank: #3
Shipping: International= /US or via instant download
Date Coupon Expires: June 30th, 200= 5
Average Customer Review: 3D"5 B= ased on 498 reviews. Write a review.

= ----iInjP5SAEqFIgOjGdY-- From LaurenceElliot@agriculturalfinance.co.uk Tue May 31 05:50:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22465 for ; Tue, 31 May 2005 05:50:39 -0400 (EDT) Received: from adsl-66-138-72-27.dsl.rcsntx.swbell.net ([66.138.72.27]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dd3gd-0006WO-Ge for dnsext-archive@ietf.org; Tue, 31 May 2005 06:10:56 -0400 Received: from Kt48@localhost by klu.int (8.11.6/8.11.6); Tue, 31 May 2005 11:29:11 -0400 Message-ID: From: "Laura Stephenson" Reply-To: "Laura Stephenson" To: dnsext-archive@ietf.org Subject: MS Office 2003 Pro $69.95 XP Date: Tue, 31 May 2005 19:25:11 +0400 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: LaurenceElliot@agriculturalfinance.co.uk Content-Type: multipart/mixed; boundary="--AG7sfayM8YpExARQ" X-Spam-Score: 2.8 (++) X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 66Cc ----AG7sfayM8YpExARQ Content-Type: text/html; Content-Transfer-Encoding: quoted-printable P
Opt-in Email Special Offer &n= bsp;   unsubscribe me



SEARCH
<= /td>

TOP 10 NEW TITLES

=

 = ON SALE NOW!

 1 Offi= ce Pro 2003
 2 Windows XP= Pro
 3 Adobe Creative S= uite Premium
 4 Norton An= tivirus 2005
 5 Flash MX = 2004
 6 Corel Draw 12
 7 Adobe Acrobat 7.0=
 8 Windows 2003 Server
 9 Alias Maya 6 Wavefrt
 10 Adobe Premiere
  See more by this manufacturer=
 &nb= sp; Microsoft
   A= pple Software
  Cus= tomers also bought
   these other items...
Microsoft Office Professional Edition *2003*
Microsoft
=
Choose:
 
List Pric= e:$899.00
Price:<= /b>$69.99
You Save:$830.01 (92%)



= Availability: Available for INSTANT download!
Coupon Code:<= /b> ISe229
Media: CD-ROM / Download

System requirements  |&nb= sp; Accessories  |  Other Versions

Feature= s:

  • Analyze and manage business information using Access databases
  • Exchange data with other systems usin= g enhanced XML technology
  • Co= ntrol information sharing rules with enhanced IRM technology
    • =
  • Easy-to-use wizards to create e-mail news= letters and printed marketing materials
  • More than 20 preformatted business reports
<= /span>Sales Rank: #1
Shippin= g: International/US or via instant download
Date Coupon Expires= : June 30th, 2005
Average Customer Re= view: 3D"5 Based on 1,768 reviews. = Write a review.
Microsoft Windows XP Professio= nal or Longhorn Edition
Microsoft
Choose:
<= select name=3DD1>  

<= img height=3D201 src=3Dhttp://images.amazon.com/images/P/B00005MOTH.01.LZZ= ZZZZZ.jpg width=3D160 align=3Dleft border=3D0 name=3Dprod_image hspace=3D5= >

List Price:$279.00
Price:= $49.99
You Save:$229.01 (8= 5%)



Availability: Ava= ilable for INSTANT download!
Coupon Code: ISe229
Media:<= /b> CD-ROM / Download

System requirements  |  Accessories  |  Oth= er Versions

Features:

  • Designed for busi= nesses of all sizes
  • Manage d= igital pictures, music, video, DVDs, and more
  • More security with the ability to encrypt files and fold= ers
  • Built-in voice, video, a= nd instant messaging support
  • Integration with Windows servers and management solutions

    • Sales Rank: #2
    Shipping= : International/US or via instant download
    Date Coupon Expires:= June 30th, 2005
    Average Customer Rev= iew: 3D"5 Based on 868 reviews. Wri= te a review.

    Adobe Photoshop CS2 V 9.0
    Adobe
    <= b class=3Dsmall>Choose:
    =  

    List Price: $599.00
    Price:$69.99
    You Save:$529.01 (90= %)



    Availability: Availa= ble for INSTANT download!
    Coupon Code: ISe229
    Media:= CD-ROM / Download

    System requirements  |  Accessories  |  Other = Versions

    Features:

    • Customized workspac= e; save personalized workspace and tool settings; create customized shortc= uts
    • Unparalleled efficiency= --automate production tasks with built-in or customized scripts
    • Improved file management, new design p= ossibilities, and a more intuitive way to create for the Web
      • =
    • Support for 16-bit images, digital camera= raw data, and non-square pixels
    • Create or modify photos using painting, drawing, and retouching tools=

    Sales Rank: #3
    <= b class=3Dtiny>Shipping: International/US or via instant download
    = Date Coupon Expires: June 30th, 2005
    = Average Customer Review: 3D"5 Based on 498 reviews. Write a review.

    <= /tr> ----AG7sfayM8YpExARQ-- From LaurenceElliot@agriculturalfinance.co.uk Tue May 31 05:51:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22491 for ; Tue, 31 May 2005 05:51:07 -0400 (EDT) Received: from f6053.upc-f.chello.nl ([80.56.6.53]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dd3iU-0006Yd-Cw for dnsext-archive@ietf.org; Tue, 31 May 2005 06:11:24 -0400 Received: from Kt48@localhost by klu.int (8.11.6/8.11.6); Tue, 31 May 2005 11:29:11 -0400 Message-ID: From: "Laura Stephenson" Reply-To: "Laura Stephenson" To: dnsext-archive@ietf.org Subject: MS Office 2003 Pro $69.95 XP Date: Tue, 31 May 2005 19:25:11 +0400 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: LaurenceElliot@agriculturalfinance.co.uk Content-Type: multipart/mixed; boundary="--AG7sfayM8YpExARQ" X-Spam-Score: 6.2 (++++++) X-Spam-Flag: YES X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 66Cc ----AG7sfayM8YpExARQ Content-Type: text/html; Content-Transfer-Encoding: quoted-printable P
    Opt-in Email Special Offer &n= bsp;   unsubscribe me



    SEARCH
    <= /td>

    TOP 10 NEW TITLES

    =

     = ON SALE NOW!

     1 Offi= ce Pro 2003
     2 Windows XP= Pro
     3 Adobe Creative S= uite Premium
     4 Norton An= tivirus 2005
     5 Flash MX = 2004
     6 Corel Draw 12
     7 Adobe Acrobat 7.0=
     8 Windows 2003 Server
     9 Alias Maya 6 Wavefrt
     10 Adobe Premiere
      See more by this manufacturer=
     &nb= sp; Microsoft
       A= pple Software
      Cus= tomers also bought
       these other items...
    Microsoft Office Professional Edition *2003*
    Microsoft
    =
    Choose:
     
    List Pric= e:$899.00
    Price:<= /b>$69.99
    You Save:$830.01 (92%)



    = Availability: Available for INSTANT download!
    Coupon Code:<= /b> ISe229
    Media: CD-ROM / Download

    System requirements  |&nb= sp; Accessories  |  Other Versions

    Feature= s:

    • Analyze and manage business information using Access databases
    • Exchange data with other systems usin= g enhanced XML technology
    • Co= ntrol information sharing rules with enhanced IRM technology
      • =
    • Easy-to-use wizards to create e-mail news= letters and printed marketing materials
    • More than 20 preformatted business reports
    <= /span>Sales Rank: #1
    Shippin= g: International/US or via instant download
    Date Coupon Expires= : June 30th, 2005
    Average Customer Re= view: 3D"5 Based on 1,768 reviews. = Write a review.
    Microsoft Windows XP Professio= nal or Longhorn Edition
    Microsoft
    Choose:
    <= select name=3DD1>  

    <= img height=3D201 src=3Dhttp://images.amazon.com/images/P/B00005MOTH.01.LZZ= ZZZZZ.jpg width=3D160 align=3Dleft border=3D0 name=3Dprod_image hspace=3D5= >

    List Price:$279.00
    Price:= $49.99
    You Save:$229.01 (8= 5%)



    Availability: Ava= ilable for INSTANT download!
    Coupon Code: ISe229
    Media:<= /b> CD-ROM / Download

    System requirements  |  Accessories  |  Oth= er Versions

    Features:

    • Designed for busi= nesses of all sizes
    • Manage d= igital pictures, music, video, DVDs, and more
    • More security with the ability to encrypt files and fold= ers
    • Built-in voice, video, a= nd instant messaging support
    • Integration with Windows servers and management solutions

      • Sales Rank: #2
      Shipping= : International/US or via instant download
      Date Coupon Expires:= June 30th, 2005
      Average Customer Rev= iew: 3D"5 Based on 868 reviews. Wri= te a review.

      Adobe Photoshop CS2 V 9.0
      Adobe
      <= b class=3Dsmall>Choose:
      =  

      List Price: $599.00
      Price:$69.99
      You Save:$529.01 (90= %)



      Availability: Availa= ble for INSTANT download!
      Coupon Code: ISe229
      Media:= CD-ROM / Download

      System requirements  |  Accessories  |  Other = Versions

      Features:

      • Customized workspac= e; save personalized workspace and tool settings; create customized shortc= uts
      • Unparalleled efficiency= --automate production tasks with built-in or customized scripts
      • Improved file management, new design p= ossibilities, and a more intuitive way to create for the Web
        • =
      • Support for 16-bit images, digital camera= raw data, and non-square pixels
      • Create or modify photos using painting, drawing, and retouching tools=

      Sales Rank: #3
      <= b class=3Dtiny>Shipping: International/US or via instant download
      = Date Coupon Expires: June 30th, 2005
      = Average Customer Review: 3D"5 Based on 498 reviews. Write a review.

      <= /tr> ----AG7sfayM8YpExARQ-- From owner-namedroppers@ops.ietf.org Wed Jun 1 03:56:43 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03324 for ; Wed, 1 Jun 2005 03:56:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DdO2g-000KJN-69 for namedroppers-data@psg.com; Wed, 01 Jun 2005 07:53:34 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DdO2d-000KIe-3I for namedroppers@ops.ietf.org; Wed, 01 Jun 2005 07:53:31 +0000 Received: by postman.ripe.net (Postfix, from userid 4008) id 1FF6C2486C; Wed, 1 Jun 2005 09:36:42 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 96A962481E for ; Wed, 1 Jun 2005 09:36:38 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id j517ab45015509 for ; Wed, 1 Jun 2005 09:36:37 +0200 Received: (from olaf@localhost) by x50.ripe.net (8.12.10/8.12.6) id j517abmB018132 for namedroppers@ops.ietf.org; Wed, 1 Jun 2005 09:36:37 +0200 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DdFPC-0009dL-1V for namedroppers@ops.ietf.org; Tue, 31 May 2005 22:40:14 +0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j4VMeDGJ008022 for ; Tue, 31 May 2005 15:40:13 -0700 (PDT) Received: from leviathan.Central.Sun.COM (leviathan.Central.Sun.COM [129.153.128.98]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j4VMeA75003091 for ; Tue, 31 May 2005 16:40:13 -0600 (MDT) Received: from leviathan.Central.Sun.COM (localhost [127.0.0.1]) by leviathan.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j4VMa0uC015480; Tue, 31 May 2005 17:36:00 -0500 (CDT) Received: (from rmesta@localhost) by leviathan.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j4VMZuaj015479; Tue, 31 May 2005 17:35:56 -0500 (CDT) Date: Tue, 31 May 2005 17:35:56 -0500 From: Rick Mesta To: Andreas Gustafsson , Rob Austein Cc: Olafur Gudmundsson , Olaf Kolkman , namedroppers@ops.ietf.org, Brian Pawlowski , Spencer Shepler , nfsv4@ietf.org, Rick Mesta Subject: Re: draft-mesta-nfs4id-dns-rr-01 Message-ID: <20050531223556.GA15396@leviathan.sun.com> Reply-To: Rick Mesta References: <20050509150200.28002bb0.olaf@ripe.net> <20050518163239.GA10343@minas-tirith.central.sun.com> <200505271120.j4RBKvun019031@guava.araneus.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200505271120.j4RBKvun019031@guava.araneus.fi> User-Agent: Mutt/1.4.2.1i X-RIPE-Spam-Tests: BAYES_00 X-RIPE-Spam-Status: U 0.339217 / -2.6 X-RIPE-Signature: f71563419e250f756688d6accd5417b6 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: This post needed manual approval. Either it was posted by a non-subscribed address, or the posting was too large ( > 20000bytes ) for this list. With the massive amount of spam, it is easy to miss and therefore delete posts that need manual approval. Please use your subscribed address to post, or shorten your postings by using links instead of attachments. ] Hi Rob / Andreas, I believe we're slowly diverging from the original intent of this draft. In the I-D, I incorrectly emphasized the aspect of "default domain" and how it is derived when using it as a motivating example. It is primarily an implementation suggestion to use the DNS domain as the NFSv4 domain in the absence of other configuration information. I would have been more correct to talk about the use of the "current DNS domain". What we're really trying to accomplish by the introduction of the NFS4ID RR is to provide a way to determine the NFSv4 domain name for a given DNS domain. NFSv4 clients and servers may interact with multiple other clients and servers in many different DNS domains. While it is suggested that the NFSv4 domain be exactly the DNS domain, it is not required. Therefore, for the system to use the correct domain for user and group, it needs to know what the NFSv4 domain, for the given DNS domain, is. DHCP is primarily for providing per-host configuration parameters. Not unlike an MX record, the NFSv4 domain is a per DNS domain parameter. Using a DNS record allows: 1) A DNS domain wide configuration of a NFSv4 domain name that is different from the DNS domain. For example, a domain hierarchy that has a flat user space may want a common "foo.com" NFSv4 domain similar to how organizations place all e-mail accounts in the highest common domain. 2) An NFSv4 node may be interacting with multiple other nodes in different domains and need to know the other's NFSv4 domain name. The interaction may be dynamic and such that there is no apriori knowledge of which domains it will access. Thus it is not reasonable to configure DHCP to provide all possible domains via DHCP. 3) NFSv4 is not necessarily a single per-host service. There are user level (e.g. browsers) implementations that may not desire to have the common per-host DHCP parameters. The NFSv4 domain name is a per domain network parameter that needs also to be visible between domains. Therefore, a per host protocol such as DHCP is not appropriate. rick On Fri, May 27, 2005 at 02:20:57PM +0300, Andreas Gustafsson wrote: | I have some comments on draft-mesta-nfs4id-dns-rr-01. | | As others have pointed out, the DNS protocol and the DNS standards | have no concept of a "default domain". Some stub resolver | implementations do, but even there it tends to be deprecated in favor | of a "domain search list". | | It seems to me that there is no need to create, or any advantage to | creating, a connection or dependency between NFSv4 and the DNS other | than simply saying that the thing following the @ has the syntactic | form of a domain name, and _by convention_ it is equal to some DNS | domain belonging to the organization at hand. | | Rather than tying the NFSv4 ID to the ill-defined concept of a | "default domain", it should simply be configured separately, using the | same mechanisms used to configure other network parameters of the | host. Typically this would be DHCP, or if DHCP cannot be used, a | configuration file. Instead of defining a NFS4ID RR type, it would | therefore make more sense to define a NFS4ID DHCP option. | | Regards, | -- | Andreas Gustafsson, gson@araneus.fi -- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: