From owner-namedroppers@ops.ietf.org Mon Nov 3 00:10:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06935 for ; Mon, 3 Nov 2003 00:10:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGWp6-00081D-Cj for namedroppers-data@psg.com; Mon, 03 Nov 2003 05:00:16 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGWos-0007zs-Lh for namedroppers@ops.ietf.org; Mon, 03 Nov 2003 05:00:03 +0000 Received: from ENGILL.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id hA34vduI093806 for ; Sun, 2 Nov 2003 23:57:45 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.0.0.22.2.20031102214330.01fc4e20@localhost> X-Sender: post@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Sun, 02 Nov 2003 21:59:17 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: DNSSECbis-records-05 compression issue Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk (Not sure if this is nit or protocol issue, so it goes to namedroppers). Currently Sections 3.1.7 and 4.1.1 say Sender MUST NOT compress and receiver SHOULD decompress if it receives compress domain name embedded in the RDATA of RRSIG and NSEC. This is in violation of RFC3597 which outlaws any compression in records defined after its publication or with number higher than 42. I propose that the text in above sections be changed to say: Domain name compression on MUST NOT be performed[RFC3597]. The reason to make this explicit is it will allow more rapid detection of compression attempts, than if recipients silently decompress. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 3 03:53:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24099 for ; Mon, 3 Nov 2003 03:53:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGaOf-000GUL-R2 for namedroppers-data@psg.com; Mon, 03 Nov 2003 08:49:13 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGaOT-000GU2-GF for namedroppers@ops.ietf.org; Mon, 03 Nov 2003 08:49:01 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id DB6824EE24; Mon, 3 Nov 2003 09:49:00 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id EE57F4EE2E; Mon, 3 Nov 2003 09:48:59 +0100 (CET) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id hA38mxHl021009; Mon, 3 Nov 2003 09:48:59 +0100 Date: Mon, 3 Nov 2003 09:48:59 +0100 From: "Olaf M. Kolkman" To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: Section 4 of dnssec-protocol-03 Message-Id: <20031103094859.2fb263cf.olaf@ripe.net> In-Reply-To: References: Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-RIPE-Spam-Status: N 0.437867 X-RIPE-Signature: d2cbb2dfdbb4755a2a9b7d577e81422a X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable >=20 > really? the last thing i heard from -editors was that it was all about > clarifying 2535. apparently then, rolling up TCR et al will come later? Forward (and backward) reference: From: =D3lafur Gudmundsson/DNSEXT co-chair To: namedroppers@ops.ietf.org Subject: DNSSEC editing process (Periodic posting) Date: Fri, 31 Oct 2003 20:23:11 -0500 Sender: owner-namedroppers@ops.ietf.org X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 "The DNSEXT working group has started a rewrite of the DNSSEC specification into a documents that better reflect the protocol and allow a test plan to be constructed from the specification. (...) If clarifications are needed due to conflicting definitions, imprecise specification, omission or other reason, the editors MUST bring these issues to the attention of the working group on the namedroppers mailing list. (...) " We need closure on the document set so let us not revisit issues that have been fixed through the submission and acceptance of drafts that where needed to clarify the specs. On the other hand, do bring issues to the list. It is a sign of thourough review. If an issue has been covered we have the archives and/or the specs to point to. -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 3 13:17:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13225 for ; Mon, 3 Nov 2003 13:17:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGj70-000Dr0-NH for namedroppers-data@psg.com; Mon, 03 Nov 2003 18:07:34 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGj6g-000DqC-Mb for namedroppers@ops.ietf.org; Mon, 03 Nov 2003 18:07:14 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 85D3F1394B for ; Mon, 3 Nov 2003 18:07:13 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Section 4 of dnssec-protocol-03 In-Reply-To: Message from "Olaf M. Kolkman" of "Mon, 03 Nov 2003 09:48:59 +0100." <20031103094859.2fb263cf.olaf@ripe.net> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 03 Nov 2003 18:07:13 +0000 Message-Id: <20031103180713.85D3F1394B@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > ... thing i heard from -editors was that it was all about clarifying > > 2535. apparently then, rolling up TCR et al will come later? > > Forward (and backward) reference: > > From: Ólafur Gudmundsson/DNSEXT co-chair > To: namedroppers@ops.ietf.org > Subject: DNSSEC editing process (Periodic posting) > Date: Fri, 31 Oct 2003 20:23:11 -0500 > > "The DNSEXT working group has started a rewrite of the DNSSEC > specification into a documents that better reflect the protocol > and allow a test plan to be constructed from the specification. in other words it should include TCR and anything else that's changed the protocol in the post-2535 era? > (...) > If clarifications are needed due to conflicting definitions, > imprecise specification, omission or other reason, the editors MUST > bring these issues to the attention of the working group on the > namedroppers mailing list. > (...) > " does passing WGLC meet the standard for "bring to the working group"? if so, then dnssec-bis will have to be fully inclusive of all post-2535 work, and as far as i know, it is not as of this time. > We need closure on the document set so let us not revisit issues that > have been fixed through the submission and acceptance of drafts that > where needed to clarify the specs. > > On the other hand, do bring issues to the list. It is a sign of > thourough review. If an issue has been covered we have the archives > and/or the specs to point to. i guess we've been asking the wrong question so let me start over. is dnssec-bis supposed to be fully inclusive of all post-2535 work, such that an implementor can just read that one doc set, or is it just a clarification of 2535, and an implementor will have to read dnssec-bis PLUS every post-2535 document? the answer to this will radically influence the document review process. -- to unsubscribe send a message to namedroppers-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 Nov 3 13:42:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14083 for ; Mon, 3 Nov 2003 13:42:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGjZV-000F7S-Qe for namedroppers-data@psg.com; Mon, 03 Nov 2003 18:37:01 +0000 Received: from [65.201.175.62] (helo=cliffie.verisignlabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGjZJ-000F6u-M2 for namedroppers@ops.ietf.org; Mon, 03 Nov 2003 18:36:49 +0000 Received: from pinion.admin.cto.netsol.com ([::ffff:172.25.170.10]) (AUTH: LOGIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by cliffie.verisignlabs.com with esmtp; Mon, 03 Nov 2003 13:36:49 -0500 From: David Blacka Organization: Verisign, Inc. To: namedroppers@ops.ietf.org Subject: Re: Section 2 of draft-ietf-dnsext-dnssec-protocol-03 Date: Mon, 3 Nov 2003 13:36:48 -0500 User-Agent: KMail/1.5.3 References: <6.0.0.22.2.20031028183020.032a6d10@localhost> In-Reply-To: <6.0.0.22.2.20031028183020.032a6d10@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200311031336.48605.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday 28 October 2003 08:11 pm, Mike StJohns wrote: > 2.2 pg7, 4th para after bullets beginning "There MUST be..." This > continues to feel like the tail wagging the dog. The DS RR was added to > prevent the requirement for close consultation between parent and child and > this seems to have way too close coordination between parent and child. It > also seems strange to require every RRset in a zone to be signed by ALL > algorithms... The reason why this paragraph doesn't make sense is that it is only half of a solution to a problem that was discussed on this list. I will quote the paragraph here (protocol-03, section 2.2): There MUST be an RRSIG for each RRset generated using at least one DNSKEY of each algorithm in the parent zone's DS RRset and each additional algorithm, if any, in the apex DNSKEY RRset. The apex DNSKEY RRset itself MUST be signed by each algorithm appearing in the DS RRset. The purpose of this paragraph (I think) is to prevent a downgrade attack. However, it doesn't make any sense at the moment, because there is no language describing the downgrade that this rule would prevent. Unless I'm totally misinterpreting things here, this is from Sam's suggestion about how to deal with unknown algorithms (or, alternately, how we might make it possible to one day move from RSA to some other algorithm). The idea, as I understood it, was for resolver to treat zones (or answers) as valid but insecure if it was only signed by unknown algorithms. However, this language does not appear in protocol-03. Actually, I couldn't find any direction on what to do with RRSIGs with unknown algorithms at all. Personally, I feel that Sam's proposal on this matter is important and should be completely included. -- David Blacka Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 3 15:01:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17859 for ; Mon, 3 Nov 2003 15:01:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGknl-000Jbv-7Q for namedroppers-data@psg.com; Mon, 03 Nov 2003 19:55:49 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGknX-000Jau-Ha for namedroppers@ops.ietf.org; Mon, 03 Nov 2003 19:55:35 +0000 Received: from ENGILL.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id hA3JrDuG096351; Mon, 3 Nov 2003 14:53:14 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.0.0.22.2.20031103144117.0296c7b0@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 03 Nov 2003 14:55:19 -0500 To: Paul Vixie , namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: Re: Section 4 of dnssec-protocol-03 In-Reply-To: <20031103180713.85D3F1394B@sa.vix.com> References: <20031103180713.85D3F1394B@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable At 13:07 2003-11-03, Paul Vixie wrote: > > > ... thing i heard from -editors was that it was all about clarifying > > > 2535. apparently then, rolling up TCR et al will come later? > > > > Forward (and backward) reference: > > > > From: =D3lafur Gudmundsson/DNSEXT co-chair > > To: namedroppers@ops.ietf.org > > Subject: DNSSEC editing process (Periodic posting) > > Date: Fri, 31 Oct 2003 20:23:11 -0500 > > > > "The DNSEXT working group has started a rewrite of the DNSSEC > > specification into a documents that better reflect the protocol > > and allow a test plan to be constructed from the specification. > >in other words it should include TCR and anything else that's changed >the protocol in the post-2535 era? Yes. > > (...) > > If clarifications are needed due to conflicting definitions, > > imprecise specification, omission or other reason, the editors MUST > > bring these issues to the attention of the working group on the > > namedroppers mailing list. > > (...) > > " > >does passing WGLC meet the standard for "bring to the working group"? >if so, then dnssec-bis will have to be fully inclusive of all post-2535 >work, and as far as i know, it is not as of this time. In most cases publication request by chair is the trigger for editors to incorporate the work. In some cases chairs have instructed editors to wait for the IESG before making changes, this happened with the= clarification of the AD bit (now or soon to be RFC3655) Another exception is if the WG shows strong preference to change the format (not semantic content) of NSEC, chairs may ask the AD for permission to allow the DNSSEC-records document make that change. > > We need closure on the document set so let us not revisit issues that > > have been fixed through the submission and acceptance of drafts that > > where needed to clarify the specs. > > > > On the other hand, do bring issues to the list. It is a sign of > > thourough review. If an issue has been covered we have the archives > > and/or the specs to point to. > >i guess we've been asking the wrong question so let me start over. > >is dnssec-bis supposed to be fully inclusive of all post-2535 work, such >that an implementor can just read that one doc set, or is it just a >clarification of 2535, and an implementor will have to read dnssec-bis >PLUS every post-2535 document? Yes, reading the DNSSECbis set is supposed to be sufficient. In the case of implementor has a question about why certain choices where made she/he may need to check some of the older documents. Example: for insertion of NSEC records in wildcard cases reading the wildcard-clarify might be a good idea. >the answer to this will radically influence the document review process. Yes it will affect the review. Please bring up any issues with the document not being a complete replacement for one or more of the RFC's/ID's that update RFC2535 and thus form the bases for DNSSEC version 3. Hope this helps, sorry for any misunderstanding chairs may have caused on this issue. Olafur (DNSEXT co-chair)=20 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 3 15:11:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18944 for ; Mon, 3 Nov 2003 15:11:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGky8-000KHV-A6 for namedroppers-data@psg.com; Mon, 03 Nov 2003 20:06:32 +0000 Received: from [65.201.175.62] (helo=cliffie.verisignlabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGkxt-000KGE-Du for namedroppers@ops.ietf.org; Mon, 03 Nov 2003 20:06:17 +0000 Received: from pinion.admin.cto.netsol.com ([::ffff:172.25.170.10]) (AUTH: LOGIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by cliffie.verisignlabs.com with esmtp; Mon, 03 Nov 2003 15:06:16 -0500 From: David Blacka Organization: Verisign, Inc. To: namedroppers@ops.ietf.org Subject: Question about Section 4 of protocol-03 Date: Mon, 3 Nov 2003 15:06:16 -0500 User-Agent: KMail/1.5.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200311031506.16525.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The third to last paragraph of section 4 in draft-ietf-dnsext-dnssec-protocol-03 says: A security-aware resolver SHOULD cache each response as a single atomic entry, indexed by the triple , with the single atomic entry containing the entire answer, including the named RRset and any associated DNSSEC RRs. The resolver SHOULD discard the entire atomic entry when any of the RRs contained in it expire. I think I missed the conversation that ended up advocating this. I seems to me that this is a radical departure from how most DNS software currently caches data (although I could be wrong). I do understand that caches must not return NSEC records inappropriately (and that is stated elsewhere in the document, somewhere in section 3), but is there a problem with caching other signed RRsets separately? Or even returning cached NSEC records when directly queried for them? For instance, lets say a security-aware resolver gets the following response: HEADER: QR AA RCODE=3 QUESTION: www.example.net IN A ANSWER AUTHORITY example.net IN SOA ... example.net IN RRSIG SOA ... web.example.net IN NSEC example.net A NSEC RRSIG web.example.net IN RRSIG NSEC ... ADDITIONAL And then subsequently gets a query for "example.net IN SOA". Following the advice above, the resolver would have to re-query. And would there by any harm in returning the results to "web.example.net IN NSEC" from 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 Mon Nov 3 15:14:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19324 for ; Mon, 3 Nov 2003 15:14:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGl1W-000KSs-5Z for namedroppers-data@psg.com; Mon, 03 Nov 2003 20:10:02 +0000 Received: from [195.47.254.20] (helo=mail.rfc.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGl1I-000KRj-UH for namedroppers@ops.ietf.org; Mon, 03 Nov 2003 20:09:49 +0000 Received: from criollo.schlyter.se (criollo.schlyter.se [195.47.254.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rfc.se (Postfix) with ESMTP id C78DC195D9; Mon, 3 Nov 2003 21:09:47 +0100 (CET) Date: Mon, 3 Nov 2003 21:09:47 +0100 (CET) From: Jakob Schlyter To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: Section 4 of dnssec-protocol-03 In-Reply-To: <20031103180713.85D3F1394B@sa.vix.com> Message-ID: References: <20031103180713.85D3F1394B@sa.vix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 3 Nov 2003, Paul Vixie wrote: > is dnssec-bis supposed to be fully inclusive of all post-2535 work, such > that an implementor can just read that one doc set, or is it just a > clarification of 2535, and an implementor will have to read dnssec-bis > PLUS every post-2535 document? as I understand it an implementor only need to read dnssec-bis. -- cut -- This document and its two companions update and obsolete RFCs 2535 [RFC2535], 3008 [RFC3008], 3090 [RFC3090], 3226 [RFC3226], and 3445 [RFC3445], as well as several works in progress: "Redefinition of the AD bit" [I-D.ietf-dnsext-ad-is-secure], "Legacy Resolver Compatibility for Delegation Signer" [I-D.ietf-dnsext-dnssec-2535typecode-change], and "Delegation Signer Resource Record" [I-D.ietf-dnsext-delegation-signer]. -- cut -- jakob -- to unsubscribe send a message to namedroppers-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 Nov 3 15:37:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20314 for ; Mon, 3 Nov 2003 15:37:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGlPE-000M1R-Mc for namedroppers-data@psg.com; Mon, 03 Nov 2003 20:34:32 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGlP2-000M0W-Ki for namedroppers@ops.ietf.org; Mon, 03 Nov 2003 20:34:20 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 738A61394B for ; Mon, 3 Nov 2003 20:34:20 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Question about Section 4 of protocol-03 In-Reply-To: Message from David Blacka of "Mon, 03 Nov 2003 15:06:16 EST." <200311031506.16525.davidb@verisignlabs.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 03 Nov 2003 20:34:20 +0000 Message-Id: <20031103203420.738A61394B@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > The third to last paragraph of section 4 in > draft-ietf-dnsext-dnssec-protocol-03 says: > > A security-aware resolver SHOULD cache each response as a single > atomic entry, indexed by the triple , with the > single atomic entry containing the entire answer, including the named > RRset and any associated DNSSEC RRs. The resolver SHOULD discard the > entire atomic entry when any of the RRs contained in it expire. > > I think I missed the conversation that ended up advocating this. I seems > to me that this is a radical departure from how most DNS software > currently caches data (although I could be wrong). i do not think that you're wrong about this. > I do understand that caches must not return NSEC records inappropriately > (and that is stated elsewhere in the document, somewhere in section 3), > but is there a problem with caching other signed RRsets separately? Or > even returning cached NSEC records when directly queried for them? > > For instance, lets say a security-aware resolver gets the following > response: > > HEADER: QR AA RCODE=3 > QUESTION: > www.example.net IN A > ANSWER > AUTHORITY > example.net IN SOA ... > example.net IN RRSIG SOA ... > web.example.net IN NSEC example.net A NSEC RRSIG > web.example.net IN RRSIG NSEC ... > ADDITIONAL > > And then subsequently gets a query for "example.net IN SOA". Following the > advice above, the resolver would have to re-query. in this case your example is suboptimal since SOAs are never supposed to be cached even in the pre-dnssec protocol. however, your question is valid if there were other authority data such as an NS RRset. requery should not be necessary in the non-SOA case. > And would there by any harm in returning the results to "web.example.net IN > NSEC" from the cache? not in my opinion. -- to unsubscribe send a message to namedroppers-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 Nov 3 16:23:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22357 for ; Mon, 3 Nov 2003 16:23:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGm3R-000ObI-6s for namedroppers-data@psg.com; Mon, 03 Nov 2003 21:16:05 +0000 Received: from [2002:425c:4242:0:250:daff:fe82:1c39] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGm2q-000OZU-GO for namedroppers@ops.ietf.org; Mon, 03 Nov 2003 21:15:28 +0000 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 6510918E2 for ; Mon, 3 Nov 2003 16:15:26 -0500 (EST) Date: Mon, 03 Nov 2003 16:15:26 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Question about Section 4 of protocol-03 In-Reply-To: <200311031506.16525.davidb@verisignlabs.com> References: <200311031506.16525.davidb@verisignlabs.com> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20031103211526.6510918E2@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Mon, 3 Nov 2003 15:06:16 -0500, David Blacka wrote: > > The third to last paragraph of section 4 in > draft-ietf-dnsext-dnssec-protocol-03 says: > > A security-aware resolver SHOULD cache each response as a single > atomic entry, indexed by the triple , with the > single atomic entry containing the entire answer, including the named > RRset and any associated DNSSEC RRs. The resolver SHOULD discard the > entire atomic entry when any of the RRs contained in it expire. > > I think I missed the conversation that ended up advocating this. Q-13, which timed out due to (apparent) WG apathy on the subject. This came out of advice we received from several workshops, as well as some analysis that Roy and I did a while back (and discussed with the WG in, um, Yokohama, maybe -- in any case, those present at that WG meeting appeared to agree that this was the right approach to take). The basic problem is that there are two DNSSEC RR types which are so weird that it's almost better not to think of them as normal RRs at all. RRSIG is really more a property of an RRset than it is an RR in its own right (see previous discussion about RRSIG not forming proper RRsets). NSEC RRs are even stranger, because they're assertions about zone structure and what they mean is somewhat context-sensitive. The choice of SHOULD was deliberate, and was intended to guide implementors to the least complex approach. YMMV. > I seems to me that this is a radical departure from how most DNS > software currently caches data (although I could be wrong). You're right for most traditional resolver implementations (the ones I know about, anyway), although I gather that this may be changing for folks who implement DNSSEC, due to the complexity of keeping track of NSEC and RRSIG RRs. > I do understand that caches must not return NSEC records inappropriately > (and that is stated elsewhere in the document, somewhere in section 3), > but is there a problem with caching other signed RRsets separately? Or > even returning cached NSEC records when directly queried for them? ... > And then subsequently gets a query for "example.net IN SOA". Following the > advice above, the resolver would have to re-query. > > And would there by any harm in returning the results to "web.example.net IN > NSEC" from the cache? I agree that it would be harmless to let the resolver find such an SOA, and that it probably would be harmless to return the result from that NSEC query as well. Not sure how useful the latter would be, given the restrictions on synthesizing negative responses and so forth, but that's a separate question and not the one you asked. -- to unsubscribe send a message to namedroppers-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 Nov 3 18:07:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01566 for ; Mon, 3 Nov 2003 18:07:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGngm-0003cS-TW for namedroppers-data@psg.com; Mon, 03 Nov 2003 23:00:48 +0000 Received: from [2002:425c:4242:0:250:daff:fe82:1c39] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGnga-0003bl-D4 for namedroppers@ops.ietf.org; Mon, 03 Nov 2003 23:00:36 +0000 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 0E96518E2 for ; Mon, 3 Nov 2003 18:00:35 -0500 (EST) Date: Mon, 03 Nov 2003 18:00:34 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: DNSSECbis-records-05 compression issue In-Reply-To: <6.0.0.22.2.20031102214330.01fc4e20@localhost> References: <6.0.0.22.2.20031102214330.01fc4e20@localhost> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Message-Id: <20031103230035.0E96518E2@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable At Sun, 02 Nov 2003 21:59:17 -0500, =D3lafur Gu=F0mundsson wrote: >=20 > Currently Sections 3.1.7 and 4.1.1 say Sender MUST NOT compress and > receiver SHOULD decompress if it receives compress domain name embedded > in the RDATA of RRSIG and NSEC. >=20 > This is in violation of RFC3597 which outlaws any compression in records > defined after its publication or with number higher than 42. >=20 > I propose that the text in above sections be changed to say: > Domain name compression on MUST NOT be performed[RFC3597]. >=20 > The reason to make this explicit is it will allow more rapid detection > of compression attempts, than if recipients silently decompress. Current text was based on the Robustness Principle, but of course this is the WG's decision to make, not the editors'. I happen to believe that applying the Robustness Principle is correct here. YMMV. -- to unsubscribe send a message to namedroppers-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 Nov 3 18:38:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03795 for ; Mon, 3 Nov 2003 18:38:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGoDq-0005Ft-Cs for namedroppers-data@psg.com; Mon, 03 Nov 2003 23:34:58 +0000 Received: from [65.201.175.62] (helo=cliffie.verisignlabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGoDc-0005FA-4L for namedroppers@ops.ietf.org; Mon, 03 Nov 2003 23:34:44 +0000 Received: from pinion.admin.cto.netsol.com ([::ffff:172.25.170.10]) (AUTH: LOGIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by cliffie.verisignlabs.com with esmtp; Mon, 03 Nov 2003 18:34:43 -0500 From: David Blacka Organization: Verisign, Inc. To: namedroppers@ops.ietf.org Subject: Re: Question about Section 4 of protocol-03 Date: Mon, 3 Nov 2003 18:34:42 -0500 User-Agent: KMail/1.5.3 References: <200311031506.16525.davidb@verisignlabs.com> <20031103211526.6510918E2@thrintun.hactrn.net> In-Reply-To: <20031103211526.6510918E2@thrintun.hactrn.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200311031834.42779.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday 03 November 2003 04:15 pm, Rob Austein wrote: > The basic problem is that there are two DNSSEC RR types which are so > weird that it's almost better not to think of them as normal RRs at > all. RRSIG is really more a property of an RRset than it is an RR in > its own right (see previous discussion about RRSIG not forming proper > RRsets). NSEC RRs are even stranger, because they're assertions about > zone structure and what they mean is somewhat context-sensitive. [ I forgot to note that this behavior is actually mandated by section 3.2: A security-aware recursive name server MUST NOT attempt to answer a query by piecing together cached data it received in response to previous queries that requested different QNAMEs, QTYPEs, or QCLASSes. ] I guess I'm arguing that this approach is too restrictive, as we can think of a few examples where "piecing together cached data" is perfectly OK. Of course, feel free to point out that I totally missed the point and am horribly wrong. I think it might be better to explain what caches MUST NOT do with these records. I am thinking, in particular they MUST NOT use NSEC records inappropriately (this is already done in Section 3.2, I believe), and MUST NOT expire RRSIG records independently of the RRset that it covers (or something to that effect, I imagine). The repercussions of this is that a cache cannot (at least) synthesize negative responses. Actually the other sentences in the indicated paragraph in section 3.2 have some weasel-room in them: A security-aware recursive name server MUST NOT use NSEC RRs from one negative response to synthesize a response for a different query. So...the cache can use NSECs that appear as part of referrals? Or, alternatively, the rational for mandating this caching approach could be put into the document. > The choice of SHOULD was deliberate, and was intended to guide > implementors to the least complex approach. YMMV. Then I think that it should be labeled as such: a simple approach that meets the requirements. As it stands, the reasons for implementing the cache this particular way are unclear, so an implementer would have a difficult time understanding when this SHOULD could be ignored (and indeed, the text from section 3.2 argues that it essentially should be a MUST anyway). -- David Blacka Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 3 19:40:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05969 for ; Mon, 3 Nov 2003 19:40:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGpAV-0008aH-4E for namedroppers-data@psg.com; Tue, 04 Nov 2003 00:35:35 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGpAJ-0008ZX-DQ for namedroppers@ops.ietf.org; Tue, 04 Nov 2003 00:35:23 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 2370D13967 for ; Tue, 4 Nov 2003 00:35:23 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: DNSSECbis-records-05 compression issue In-Reply-To: Message from Rob Austein of "Mon, 03 Nov 2003 18:00:34 EST." <20031103230035.0E96518E2@thrintun.hactrn.net> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 04 Nov 2003 00:35:23 +0000 Message-Id: <20031104003523.2370D13967@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > I propose that the text in above sections be changed to say: > > Domain name compression on MUST NOT be performed[RFC3597]. > > > > The reason to make this explicit is it will allow more rapid detection > > of compression attempts, than if recipients silently decompress. and i agree, for that reason. > > > I happen to believe that applying the Robustness Principle is correct > here. YMMV. > > i think silent failure-to-fail is a bad idea, and that the robustness principal is in need of an update in at least that regard. -- to unsubscribe send a message to namedroppers-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 Nov 3 20:02:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06530 for ; Mon, 3 Nov 2003 20:02:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGpX1-0009h4-Hm for namedroppers-data@psg.com; Tue, 04 Nov 2003 00:58:51 +0000 Received: from [2001:470:1f00:820:208:74ff:fe9f:eeae] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGpWp-0009fc-66 for namedroppers@ops.ietf.org; Tue, 04 Nov 2003 00:58:39 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9p2/8.12.9) with ESMTP id hA40wXCh018175; Tue, 4 Nov 2003 11:58:33 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200311040058.hA40wXCh018175@drugs.dv.isc.org> To: David Blacka Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: Question about Section 4 of protocol-03 In-reply-to: Your message of "Mon, 03 Nov 2003 18:34:42 CDT." <200311031834.42779.davidb@verisignlabs.com> Date: Tue, 04 Nov 2003 11:58:33 +1100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > The repercussions of this is that a cache cannot (at least) synthesize > negative responses. Actually the other sentences in the indicated > paragraph in section 3.2 have some weasel-room in them: > > A security-aware recursive name server MUST NOT use NSEC > RRs from one negative response to synthesize a response for a > different query. This precludes caching NXDOMAIN independent of query type which is in direct opposition to RFC 2308. We synthesis NXDOMAIN responses all the time in the non- DNSSEC world. The only time this is a problem is when you have broken authoritative servers. I really have no problem with caches using the NSEC bitmask (or whatever replaces it) to generate NODATA responses to different query types. If you have a NODATA response for example.net/IN/A and the bitmask says that AAAA doesn't exist you have all the information required to return a NODATA response to example.net/IN/AAAA. The only difference in the two responses above is in the QTYPE of the question. Again the only time this would be a problem is when you have broken authoritative servers. You can't do this synthesis in the non-DNSSEC world but it make perfect sense to do it in the DNSSEC world. Failure to allow resolvers to synthesis NODATA responses will increase network traffic and cache memory footprints for absolutely no benefits. What is hard to do correctly is to synthesis NXDOMAIN responses to different QNAMES. Mark -- Mark Andrews, Internet Software Consortium 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 Nov 4 03:53:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04394 for ; Tue, 4 Nov 2003 03:53:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGwnl-0001wo-SK for namedroppers-data@psg.com; Tue, 04 Nov 2003 08:44:37 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGwnZ-0001wD-FT for namedroppers@ops.ietf.org; Tue, 04 Nov 2003 08:44:25 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id D962E4E55C; Tue, 4 Nov 2003 09:44:24 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 3F6574ECAD for ; Tue, 4 Nov 2003 09:44:24 +0100 (CET) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id hA48iOHl025547 for ; Tue, 4 Nov 2003 09:44:24 +0100 Date: Tue, 4 Nov 2003 09:44:24 +0100 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: DNSEXT Agenda IETF58 Message-Id: <20031104094424.06d55053.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.6 (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-Status: N 0.499565 X-RIPE-Signature: ddb8a0c4a7ab3aa606bdde123ee58d87 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ---NOTE THE LAST MINUTE CHANGE IN THE IETF AGENDA. THE MEETING IS ON THURSDAY--- DNS Extensions WG (dnsext) Time: Thursday, November 13, 1300-15:00 Afternoon Sessions I Location: TBD. Chairs: Olafur Gudmundsson and Olaf Kolkman. Charter: http://www.ietf.org/html.charters/dnsext-charter.html - Administrivia 5 min agenda bashing appointing scribes - Working group Document status 5 min - Call for Interoperabilty report volunteers 5 min - Wild card clarify 10 min http://www.ietf.org/internet-drafts/draft-ietf-dnsext-wcard-clarify-02.txt - DNSSEC-bis session 90 min http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-intro-07.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-records-05.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-protocol-03.txt This session will be broken down into at least following subsections DNSSEC-bis editors report Open issues list and open mike NSEC type code representation Caching and reuse of DNSSEC RRsets Compression guidelines Protocol constraints on algorithm use (eg does DNSKEY RR of alg X imply zone is signed with alg X). RRSIG TTL use, follow corresponding RRset or RFC2181 Document status, next steps and schedule Request for intent/status of implementations Wrap up 5 min. Olafur and Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Nov 4 05:29:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07479 for ; Tue, 4 Nov 2003 05:29:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGyMP-0006np-5v for namedroppers-data@psg.com; Tue, 04 Nov 2003 10:24:29 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGyMB-0006mu-KK for namedroppers@ops.ietf.org; Tue, 04 Nov 2003 10:24:16 +0000 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id hA4AO8N26389; Tue, 4 Nov 2003 17:24:10 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id hA4ANuJ00707; Tue, 4 Nov 2003 17:23:59 +0700 (ICT) From: Robert Elz To: Paul Vixie cc: namedroppers@ops.ietf.org Subject: Re: Question about Section 4 of protocol-03 In-Reply-To: <20031103203420.738A61394B@sa.vix.com> References: <20031103203420.738A61394B@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 04 Nov 2003 17:23:56 +0700 Message-ID: <960.1067941436@munnari.OZ.AU> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Mon, 03 Nov 2003 20:34:20 +0000 From: Paul Vixie Message-ID: <20031103203420.738A61394B@sa.vix.com> Off topic, but ... | in this case your example is suboptimal since SOAs are never supposed to | be cached even in the pre-dnssec protocol. Where does that theory originate? 1034 actually says (page 27, sect 4.3.4) ... SOA RRs may be cached due to direct SOA queries (the section is about other issues, but the direct words that say they may be cached, in a context meaning that one must be aware of that, is still pretty compelling evidence against your theory). The closest I can come to a suggestion in line with your remark is in 3.1.1. of 1035 (page 11)... For example, SOA records are always distributed with a zero TTL to prohibit caching. (which is part of the definition of the TTL field in RRs). That, by itself, doesn't say that SOAs cannot be cached, at most it suggests that servers should send a 0 TTL to prevent caching - but it doesn't say whether that is because of anything that the DNS demands, of whether it is just what a server may want to achieve. It isn't even clear here whether this is something that was thought likely to be true of SOAs in general, or whether this is just an example of what someone might want to do. It is clear however, that in practice neither 0 TTL for SOA, nor don't cache SOA are widely seen behaviours, eg: ; <<>> DiG 9.2.0rc10 <<>> @ns1.gnac.com. vix.com. soa ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9646 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 5 ;; QUESTION SECTION: ;vix.com. IN SOA ;; ANSWER SECTION: vix.com. 3600 IN SOA ns.lh.vix.com. hostmaster.vix.com. 2003101800 3600 1800 604800 3600 Note the TTL - not 0 on that SOA response. What's more, from a different system (and not asking one of t he auth servers directly, but just he local back end ...) ; <<>> DiG 8.3 <<>> vix.com. soa ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 5 ;; QUERY SECTION: ;; vix.com, type = SOA, class = IN ;; ANSWER SECTION: vix.com. 54m2s IN SOA ns.lh.vix.com. hostmaster.vix.com. ( 2003101800 ; serial 1H ; refresh 30M ; retry 1W ; expiry 1H ) ; minimum The answer does not have AA (came from a cache) and the TTL has been decremented a bit from the 3600 secs (hour) that the auth servers give out... Neither the net nor the DNS seems to suffer from this, so I can't think of any reason to attempt to retroactively create a rule like the one you suggested exists. kre ps: and see sect 7.2 of 2181. -- to unsubscribe send a message to namedroppers-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 Nov 4 07:41:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12312 for ; Tue, 4 Nov 2003 07:41:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AH0P0-000CxA-1h for namedroppers-data@psg.com; Tue, 04 Nov 2003 12:35:18 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AH0Ol-000Cux-0M for namedroppers@ops.ietf.org; Tue, 04 Nov 2003 12:35:03 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.8p2/8.12.8) with ESMTP id h9VMlKBk087103; Fri, 31 Oct 2003 23:47:20 +0100 (CET) (envelope-from miekg@atoom.net) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.10/8.12.10/Debian-4) with ESMTP id h9VMlsfZ028593; Fri, 31 Oct 2003 23:47:55 +0100 Received: (from miekg@localhost) by elektron.atoom.net (8.12.10/8.12.10/Debian-4) id h9VMlsdi028592; Fri, 31 Oct 2003 23:47:54 +0100 Date: Fri, 31 Oct 2003 23:47:54 +0100 From: Miek Gieben To: Rob Austein Cc: namedroppers@ops.ietf.org Subject: Re: Q18: TTL values for RRSIG vs. RFC2181 Message-ID: <20031031224754.GB25401@atoom.net> Mail-Followup-To: Rob Austein , namedroppers@ops.ietf.org References: <010e01c39fe0$ad7766c0$b9370681@barnacle> <6.0.0.22.2.20031031145555.0285c848@localhost> <20031031202739.783AA20B9@thangorodrim.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031031202739.783AA20B9@thangorodrim.hactrn.net> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 31 Oct, @21:27, Rob wrote in "Re: Q18: TTL values for RRSIG ..."] > > > I don't like "meta type" ('cause then we'd have to explain what it > means, which would almost certainly be harder than just saying > whatever it is that we do mean in the first place...), but I think > that the editors can handle the wordsmithing unless the WG feels a > strong need to constrain us to specific text. > > The question before the WG is whether we've understood the content > issue correctly. > > I feel that making this exception for the SIG's TTL is the right thing to do. grtz Miek -- to unsubscribe send a message to namedroppers-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 Nov 4 10:14:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17843 for ; Tue, 4 Nov 2003 10:14:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AH2mk-000Lfw-ML for namedroppers-data@psg.com; Tue, 04 Nov 2003 15:07:58 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AH2mX-000Ley-5D for namedroppers@ops.ietf.org; Tue, 04 Nov 2003 15:07:45 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 8E8DB4E5F8; Tue, 4 Nov 2003 16:07:44 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id F281E4E0A7 for ; Tue, 4 Nov 2003 16:07:43 +0100 (CET) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id hA4F7hHl018277 for ; Tue, 4 Nov 2003 16:07:43 +0100 Date: Tue, 4 Nov 2003 16:07:43 +0100 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: Re: Large typecodes and DNSSEC Message-Id: <20031104160743.61bb91d0.olaf@ripe.net> In-Reply-To: <200310281402.41950.davidb@verisignlabs.com> References: <200310281402.41950.davidb@verisignlabs.com> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.6 (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-Status: N 0.079189 X-RIPE-Signature: 79ca343af939582fff533d5748021f36 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The discussion on this topic died out. I think I can summarize that the WG seems to think that a not-backward-compatible NSEC 'bitmap' is the thing to work toward. To focus the discussion on one particular proposal I'd like to invite comments on Michaels proposal (*) as is with one modifications: Drop format 0. Retain only "compressed" type lists (format 1). This addresses Paul's worry about the data size limits and Andreas' worry about the possibility that two different formats can be choosen to calculate the same information resulting in possible RRSIG ambiguities. (I hope I summarized that one correctly :-) ) What does the working group think? Any security issues that are opened up by this change in representation? What are we missing? --Olaf DNSEXT Co-Chair. (*) Michaels proposal is in http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg02005.html PS. As for 'silly state' we use the language as currently defined in proto-3 (2.3: "The type bitmap of every NSEC resource record in a signed zone MUST indicate the presence of both the NSEC record itself and its corresponding RRSIG record.", and 5.4 "Since a verified NSEC RR proves the existence of both itself and its corresponding RRSIG RR, a verifier MUST ignore the settings of the NSEC and RRSIG bits in an NSEC RR.") We asked for text to modify this it was not supplied so I consider this issue closed. (see http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01851.html) Lets stick to the issue at hand, the representation of the bitmap, not the semantics of the NSEC 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 Tue Nov 4 14:45:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00566 for ; Tue, 4 Nov 2003 14:45:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AH6zh-000E8X-Lj for namedroppers-data@psg.com; Tue, 04 Nov 2003 19:37:37 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AH6zV-000E7n-2v for namedroppers@ops.ietf.org; Tue, 04 Nov 2003 19:37:25 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id hA4JbA0T026267 for ; Tue, 4 Nov 2003 14:37:15 -0500 (EST) Message-ID: <017e01c3a30b$0d7d9e90$b9370681@barnacle> From: "Scott Rose" To: Subject: Q19: supression of duplicate RRs in an RRset Date: Tue, 4 Nov 2003 14:37:11 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is (probably) another non-issue, but for procedural completeness: Q19: Should multiple instances of identical RRs in an RRset be reduced to a single RR during the signing process? Consider the zone file: a.example.com IN A 1.2.3.4 a.example.com IN A 4.3.2.1 b.example.com IN A 1.2.3.5 ... a.example.com IN A 1.2.3.4 Going through the signing process. Would the signer be justified in dropping the second "a.example.com" RR from the "a.example.com A" and leaving it as 2 RRs in the set? That would effect the signature generation process - it would be different if there was the third RR in the set. Note that this is for the signature generation process and not loading or serving the zone. RFC 2181 cover duplicate RRs in a set for an operational DNS zone (see Section 5). The suggested text would be in line with RFC 2181 but for the signing process. Suggested text is to add text to Section 6.3 (Canonical Ordering in an RRset) of the Resource Records DNSSECbis draft stating that a duplicate RR should be dropped from an RRset when generating a signature for the set. Comments/questions welcome, Silence will be taken in favor of adding the check and performing the action during the signing process. DNSSECbis editors -- to unsubscribe send a message to namedroppers-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 Nov 4 16:07:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05768 for ; Tue, 4 Nov 2003 16:07:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AH8Jv-000J9q-MS for namedroppers-data@psg.com; Tue, 04 Nov 2003 21:02:35 +0000 Received: from [65.201.175.62] (helo=cliffie.verisignlabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AH8Jj-000J9T-JD for namedroppers@ops.ietf.org; Tue, 04 Nov 2003 21:02:23 +0000 Received: from pinion.admin.cto.netsol.com ([::ffff:172.25.170.10]) (AUTH: LOGIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by cliffie.verisignlabs.com with esmtp; Tue, 04 Nov 2003 16:02:22 -0500 From: David Blacka Organization: Verisign, Inc. To: namedroppers@ops.ietf.org Subject: Re: Q19: supression of duplicate RRs in an RRset Date: Tue, 4 Nov 2003 16:02:22 -0500 User-Agent: KMail/1.5.3 References: <017e01c3a30b$0d7d9e90$b9370681@barnacle> In-Reply-To: <017e01c3a30b$0d7d9e90$b9370681@barnacle> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200311041602.22257.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday 04 November 2003 02:37 pm, Scott Rose wrote: > This is (probably) another non-issue, but for procedural completeness: > > Q19: Should multiple instances of identical RRs in an RRset be reduced to a > single RR during the signing process? Yes. Signatures obviously don't work if what is signed isn't what is served. -- 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 Nov 4 16:44:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07178 for ; Tue, 4 Nov 2003 16:44:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AH8tT-000LLO-KG for namedroppers-data@psg.com; Tue, 04 Nov 2003 21:39:19 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AH8tH-000LKB-FB for namedroppers@ops.ietf.org; Tue, 04 Nov 2003 21:39:07 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id AD1041395D for ; Tue, 4 Nov 2003 21:39:06 +0000 (GMT) (envelope-from vixie@sa.vix.com) To: namedroppers@ops.ietf.org Subject: Re: Q19: supression of duplicate RRs in an RRset In-Reply-To: Message from "Scott Rose" of "Tue, 04 Nov 2003 14:37:11 EST." <017e01c3a30b$0d7d9e90$b9370681@barnacle> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 04 Nov 2003 21:39:06 +0000 From: Paul Vixie Message-Id: <20031104213906.AD1041395D@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > This is (probably) another non-issue, but for procedural completeness: > > Q19: Should multiple instances of identical RRs in an RRset be reduced to a > single RR during the signing process? arguably not. these should be removed during the process of reading/loading/ importing the zone, and so the signer should never see them, nor should axfr be able to transfer them, or query be able to return them. this is how bind8 and bind9 work in the case shown below: > Consider the zone file: > > a.example.com IN A 1.2.3.4 > a.example.com IN A 4.3.2.1 > b.example.com IN A 1.2.3.5 > ... > a.example.com IN A 1.2.3.4 duplicate rdata is just too hard to think about. -- to unsubscribe send a message to namedroppers-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 Nov 4 18:56:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12119 for ; Tue, 4 Nov 2003 18:56:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHAxf-0001eg-En for namedroppers-data@psg.com; Tue, 04 Nov 2003 23:51:47 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHAxL-0001e9-7k for namedroppers@ops.ietf.org; Tue, 04 Nov 2003 23:51:27 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id hA4NnQ1w001213 for ; Tue, 4 Nov 2003 18:49:26 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAW9aGxc; Tue, 4 Nov 03 18:49:26 -0500 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id hA4No1a3009914; Tue, 4 Nov 2003 18:50:01 -0500 (EST) Date: Tue, 4 Nov 2003 18:50:01 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: Scott Rose cc: namedroppers@ops.ietf.org Subject: Re: Q19: supression of duplicate RRs in an RRset In-Reply-To: <017e01c3a30b$0d7d9e90$b9370681@barnacle> Message-ID: References: <017e01c3a30b$0d7d9e90$b9370681@barnacle> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Q19: Should multiple instances of identical RRs in an RRset be > reduced to a single RR during the signing process? Absolutely. See the discussion about ambiguous formats in the large typecode thread. -- 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 Nov 4 19:31:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13033 for ; Tue, 4 Nov 2003 19:31:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHBUW-0003Ov-Cj for namedroppers-data@psg.com; Wed, 05 Nov 2003 00:25:44 +0000 Received: from [2002:c08b:2e21:3:250:baff:fe2d:b704] (helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHBUB-0003Nd-CL for namedroppers@ops.ietf.org; Wed, 05 Nov 2003 00:25:30 +0000 Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [205.150.200.247]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id h9T1DUk01276 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Tue, 28 Oct 2003 20:13:35 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9T14W7L000515 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 28 Oct 2003 20:04:33 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9T14WlA000511 for ; Tue, 28 Oct 2003 20:04:32 -0500 To: namedroppers@ops.ietf.org Subject: Re: Large typecodes and DNSSEC In-reply-to: Your message of "Tue, 28 Oct 2003 23:56:12 +0100." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 28 Oct 2003 20:04:32 -0500 Message-ID: <510.1067389472@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Samuel" == Samuel Weiler writes: Samuel> Yup -- we need to do that. How's this: If you see the zero bit Samuel> set AND THE NSEC VALIDATES, treat this name as unsecured unless Samuel> you have evidence to the contrary (ie. a validated RRset)? This sounds like the minimum that we can do. Samuel> I think we can get away with putting this off -- we have the Samuel> extension mechanism in place and can deal with it later. With Samuel> the current typecode burn rate, the current format will outlast a Samuel> resolver replacement cycle. Maybe two. Samuel> But if folks really insist, let's get it done quickly. I'm sure Samuel> we can settle on a format. Can we get multiple interoperable Samuel> implementations out the door before Minneapolis? Seriously -- I Samuel> want to get this rev out. I suggest that the chairs decline the Samuel> change unless we have two pieces of interoperable code within Samuel> some short amount of time, perferably pre-MSP. Why do we need two interop's in order to publish 2535bis? ] Collecting stories about my dad: http://www.sandelman.ca/cjr/ | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP58SHYqHRg3pndX9AQGQ+QQAwNEgpqWmitz+TcxEMfqd99Ircz7/h5e9 XjjuZqIWn1r9h8gSEDa1puchzoRqYhuaDwFdyjdpAUc5Ag5TrJH4NoI5aZozNp9w LQQVbE0tQAqq4Y3OZydQX71JUXFoAoqD0J/v/hLLfy+F3tIUwCY7RYEdY3JeKSMx ivdwnld6nio= =h1Vs -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Nov 4 20:16:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14699 for ; Tue, 4 Nov 2003 20:16:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHCDH-0005S9-U0 for namedroppers-data@psg.com; Wed, 05 Nov 2003 01:11:59 +0000 Received: from [2002:425c:4242:0:250:daff:fe82:1c39] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHCD5-0005Rk-Rq for namedroppers@ops.ietf.org; Wed, 05 Nov 2003 01:11:48 +0000 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 206C618E8 for ; Tue, 4 Nov 2003 20:11:46 -0500 (EST) Date: Tue, 04 Nov 2003 20:11:46 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Q19: supression of duplicate RRs in an RRset In-Reply-To: <20031104213906.AD1041395D@sa.vix.com> References: <017e01c3a30b$0d7d9e90$b9370681@barnacle> <20031104213906.AD1041395D@sa.vix.com> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20031105011146.206C618E8@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Tue, 04 Nov 2003 21:39:06 +0000, Paul Vixie wrote: > > > This is (probably) another non-issue, but for procedural completeness: > > > > Q19: Should multiple instances of identical RRs in an RRset be reduced to a > > single RR during the signing process? > > arguably not. these should be removed during the process of reading/loading/ > importing the zone, and so the signer should never see them, nor should axfr > be able to transfer them, or query be able to return them. But if for some reason a zone signer were somehow to see such duplicates, said zone signer should generate signatures based on the RRset with the duplicates removed. Right? -- to unsubscribe send a message to namedroppers-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 Nov 4 20:40:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15588 for ; Tue, 4 Nov 2003 20:40:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHCaG-0006Z8-Qg for namedroppers-data@psg.com; Wed, 05 Nov 2003 01:35:44 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHCa4-0006Yd-NF for namedroppers@ops.ietf.org; Wed, 05 Nov 2003 01:35:32 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id C2EE51394C; Wed, 5 Nov 2003 01:35:19 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Rob Austein Cc: namedroppers@ops.ietf.org Subject: Re: Q19: supression of duplicate RRs in an RRset In-Reply-To: Message from Rob Austein of "Tue, 04 Nov 2003 20:11:46 EST." <20031105011146.206C618E8@thrintun.hactrn.net> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 05 Nov 2003 01:35:19 +0000 Message-Id: <20031105013519.C2EE51394C@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > arguably not. these should be removed during the process of > > reading/loading/ importing the zone, and so the signer should never > > see them, nor should axfr be able to transfer them, or query be able > > to return them. > > But if for some reason a zone signer were somehow to see such > duplicates, said zone signer should generate signatures based on the > RRset with the duplicates removed. Right? ideally not. a zone signer should signal an error and give up under those conditions. silently ignoring bad data is not always a favour, especially where security, and zone identity, are concerned. -- to unsubscribe send a message to namedroppers-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 Nov 4 21:21:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16656 for ; Tue, 4 Nov 2003 21:21:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHDD1-0008Mp-Lt for namedroppers-data@psg.com; Wed, 05 Nov 2003 02:15:47 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHDCp-0008M2-BB for namedroppers@ops.ietf.org; Wed, 05 Nov 2003 02:15:35 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id hA52DYki007103 for ; Tue, 4 Nov 2003 21:13:34 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA7raW3n; Tue, 4 Nov 03 21:13:33 -0500 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id hA52ECHR013328; Tue, 4 Nov 2003 21:14:12 -0500 (EST) Date: Tue, 4 Nov 2003 21:14:12 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: Mike StJohns cc: namedroppers@ops.ietf.org Subject: Re: Section 2 of draft-ietf-dnsext-dnssec-protocol-03 In-Reply-To: <6.0.0.22.2.20031029104228.02f72148@localhost> Message-ID: References: <6.0.0.22.2.20031028183020.032a6d10@localhost> <01b801c39e2d$de040c30$b9370681@barnacle> <6.0.0.22.2.20031029104228.02f72148@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 29 Oct 2003, Mike StJohns wrote: > ... that's the wrong answer I think. If we don't mandate the set > of algorithms the resolver has to implement, then its possible that the > resolver won't be able to resolve part of the tree if its signed by an > algorithm the resolver doesn't understand. Mandating how the tree is > signed is the wrong answer - because we can't control what people > do. Mandating how the resolver works is the right answer. It's not that the resolver won't be able to resolve that part of the tree, it's just that that part of the tree will appear as insecure, which is fine and dandy. The alternative is to forbid zone owners from ever experimenting with new algorithms. Oops -- that's back to imposing constraints on the zone owner. You're partially right: we need to mandate client behavior when a zone is signed with a non-understood algorithm and when a zone doesn't follow the rules. But we need the rules, too. See Olaf's message on 24 September for pointers to the lengthy discussion (Subject: DNSSECbis Q-2: degradation attack). Note, in particular, the safety property: properly signing a zone should not cause the zone to be less resolvable. This is the same premise that drove the type code roll. > We still have the problem where we add new algorithms, delete old ones and > haven't updated the resolvers, but that seems to be a lot less problematic > than the current language (e.g. its a "lesser included offense" :-) As should surprise no one who followed the discussion of the algorithm rules, I disagree. If we ignored this, it would be difficult if not impossible to deploy new algorithms, and I would agree with Paul's assessment (on 18 August) that we should just manadate RSA/SHA-1 and give up on ever switching algorithms. Remove all of the algorithm fields, get rid of the IANA registries which have been plaguing the TCR draft (even after IESG approval), and plow ahead with a single algorithm for all time (or until RSA or SHA-1 is broken and we have to work on DNSSECbisbis). -- to unsubscribe send a message to namedroppers-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 Nov 4 21:31:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16963 for ; Tue, 4 Nov 2003 21:31:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHDOZ-000905-If for namedroppers-data@psg.com; Wed, 05 Nov 2003 02:27:43 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHDOM-0008zS-PO for namedroppers@ops.ietf.org; Wed, 05 Nov 2003 02:27:30 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id hA52PULV007651 for ; Tue, 4 Nov 2003 21:25:30 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAk9aq8o; Tue, 4 Nov 03 21:25:29 -0500 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id hA52Q9kY013716 for ; Tue, 4 Nov 2003 21:26:09 -0500 (EST) Date: Tue, 4 Nov 2003 21:26:08 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org Subject: Re: Large typecodes and DNSSEC In-Reply-To: Message-ID: References: <200310281402.41950.davidb@verisignlabs.com> <200310281647.45423.davidb@verisignlabs.com> <200310281848.26163.davidb@verisignlabs.com> <20031029154141.GA27166@chinook.rgy.netsol.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I'm not moved by Paul's concern that the new and improved NSEC must be able to list every typecode, and I'd still prefer the 16-bit list. With this format, we run the risk that an implementer will assume that, at least for the life of whatever piece of code he's writing, there will never be types with non-zero prefixes (or even greater than 128) and optimize by not processing more than one block (or the negative format). That said... In Micheal's draft, section 6.1 needs to make it clearer that the count/high/data blocks can repeat -- now that's not obvious until the example. While the HIGH-ORDER description mentions increasing order, it's not being completely clear that what's being sorted are count/high/data blocks. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Nov 5 03:21:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25431 for ; Wed, 5 Nov 2003 03:21:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHIns-000Njb-5b for namedroppers-data@psg.com; Wed, 05 Nov 2003 08:14:12 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHInf-000Niz-SJ for namedroppers@ops.ietf.org; Wed, 05 Nov 2003 08:14:00 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 4664D4ECA8; Wed, 5 Nov 2003 09:13:59 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id D9E214E1D3; Wed, 5 Nov 2003 09:13:58 +0100 (CET) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id hA58DwHl000556; Wed, 5 Nov 2003 09:13:58 +0100 Date: Wed, 5 Nov 2003 09:13:58 +0100 From: "Olaf M. Kolkman" To: Paul Vixie Cc: sra+namedroppers@hactrn.net, namedroppers@ops.ietf.org Subject: Re: Q19: supression of duplicate RRs in an RRset Message-Id: <20031105091358.726eeb3e.olaf@ripe.net> In-Reply-To: <20031105013519.C2EE51394C@sa.vix.com> References: <20031105011146.206C618E8@thrintun.hactrn.net> <20031105013519.C2EE51394C@sa.vix.com> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.6 (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-Status: N 0.018098 X-RIPE-Signature: 6659a74bbbe2536553a67cef440cfe7d X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 05 Nov 2003 01:35:19 +0000 Paul Vixie wrote: > > > arguably not. these should be removed during the process of > > > reading/loading/ importing the zone, and so the signer should never > > > see them, nor should axfr be able to transfer them, or query be able > > > to return them. But it is not only the signer that is able to get duplicates the validator may get them too. -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Nov 5 09:01:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05863 for ; Wed, 5 Nov 2003 09:01:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHO4p-000Fk8-Cq for namedroppers-data@psg.com; Wed, 05 Nov 2003 13:52:03 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHO4c-000Fja-IG for namedroppers@ops.ietf.org; Wed, 05 Nov 2003 13:51:50 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id hA5DpP0T029888 for ; Wed, 5 Nov 2003 08:51:25 -0500 (EST) Message-ID: <01cc01c3a3a3$e848d5b0$b9370681@barnacle> From: "Scott Rose" To: References: <20031104213906.AD1041395D@sa.vix.com> Subject: Re: Q19: supression of duplicate RRs in an RRset Date: Wed, 5 Nov 2003 08:51:26 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Paul Vixie" To: Sent: Tuesday, November 04, 2003 4:39 PM Subject: Re: Q19: supression of duplicate RRs in an RRset > > This is (probably) another non-issue, but for procedural completeness: > > > > Q19: Should multiple instances of identical RRs in an RRset be reduced to a > > single RR during the signing process? > > arguably not. these should be removed during the process of reading/loading/ > importing the zone, and so the signer should never see them, nor should axfr > be able to transfer them, or query be able to return them. > The signature generataion process could be seperate from the zone loading/serving process. A duplicate RR in a set may slip through the signer, then be caught by a name server during reading. By then, it is too late, the RRSIG is incorrect and will not be verified by a resolver. The idea that it should not be silently ignored is probably better. That is another option to state/replace in the drafts. Scott -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Nov 5 13:09:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15279 for ; Wed, 5 Nov 2003 13:09:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHRxt-00053h-Hf for namedroppers-data@psg.com; Wed, 05 Nov 2003 18:01:09 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHRxa-00052E-Tn for namedroppers@ops.ietf.org; Wed, 05 Nov 2003 18:00:50 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id AE9F613967 for ; Wed, 5 Nov 2003 18:00:50 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Q19: supression of duplicate RRs in an RRset In-Reply-To: Message from "Olaf M. Kolkman" of "Wed, 05 Nov 2003 09:13:58 +0100." <20031105091358.726eeb3e.olaf@ripe.net> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 05 Nov 2003 18:00:50 +0000 Message-Id: <20031105180050.AE9F613967@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > > > arguably not. these should be removed during the process of > > > > reading/loading/ importing the zone, and so the signer should never > > > > see them, nor should axfr be able to transfer them, or query be able > > > > to return them. > > But it is not only the signer that is able to get duplicates the validator > may get them too. since that would unambiguously be a protocol error rather than a MIM attack, i think it would be correct to signal an error under those conditions, too. -- to unsubscribe send a message to namedroppers-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 Nov 5 13:32:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16181 for ; Wed, 5 Nov 2003 13:31:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHSM2-0006s9-Ec for namedroppers-data@psg.com; Wed, 05 Nov 2003 18:26:06 +0000 Received: from [216.168.237.102] (helo=heron.verisign.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHSLp-0006rg-3s for namedroppers@ops.ietf.org; Wed, 05 Nov 2003 18:25:53 +0000 Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by heron.verisign.com (8.12.10/8.12.10) with ESMTP id hA5IPqha027875 for ; Wed, 5 Nov 2003 13:25:52 -0500 (EST) Received: from chinook.rgy.netsol.com (host49-130-valks2.corppc.vrsn.com [10.131.130.49]) by VSVAPOSTALGW1.prod.netsol.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id V9Q67RFN; Wed, 5 Nov 2003 13:25:51 -0500 Received: by chinook.rgy.netsol.com (Postfix, from userid 500) id B7A879BE20; Wed, 5 Nov 2003 13:25:47 -0500 (EST) Date: Wed, 5 Nov 2003 13:25:47 -0500 From: Matt Larson To: namedroppers@ops.ietf.org Subject: Re: Large typecodes and DNSSEC Message-ID: <20031105182547.GA14265@chinook.rgy.netsol.com> References: <200310281402.41950.davidb@verisignlabs.com> <20031104160743.61bb91d0.olaf@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031104160743.61bb91d0.olaf@ripe.net> User-Agent: Mutt/1.5.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 04 Nov 2003, Olaf M. Kolkman wrote: > To focus the discussion on one particular proposal I'd like to invite > comments on Michaels proposal (*) as is with one modifications: Drop > format 0. Retain only "compressed" type lists (format 1). I agree with Sam's sentiments expressed in an earlier message and propose the opposite: that we retain format 0 (simple 16-bit type list) and drop format 1, which is clever but complicated. It strikes me as unnecessariy optimization. > This addresses Paul's worry about the data size limits I don't think this concern is realistic. The protocol need not accommodate an NSEC specifying every possible type. There are similar trade-offs elsewhere. For example, the protocol currently allows 127 levels of name space depth and 63-octet labels, but places a realistic limit of 255 characters on the length of a domain name. Or: the speedometer in my car goes up to 160 miles per hour but the tires supplied by the manufacturer are not rated for that speed. Real-world experience shows that the vast majority of names have just a few types. Format 0 would still accommodate the outliers by allowing well over 32,000 types. Let's not over-optimize and over-complicate. Matt -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Nov 5 13:55:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17022 for ; Wed, 5 Nov 2003 13:55:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHSkx-0008OD-3f for namedroppers-data@psg.com; Wed, 05 Nov 2003 18:51:51 +0000 Received: from [2002:425c:4242:0:250:daff:fe82:1c39] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHSkc-0008N2-BD for namedroppers@ops.ietf.org; Wed, 05 Nov 2003 18:51:30 +0000 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 8EA8518E4 for ; Wed, 5 Nov 2003 13:51:28 -0500 (EST) Date: Wed, 05 Nov 2003 13:51:28 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Large typecodes and DNSSEC In-Reply-To: <20031105182547.GA14265@chinook.rgy.netsol.com> References: <200310281402.41950.davidb@verisignlabs.com> <20031104160743.61bb91d0.olaf@ripe.net> <20031105182547.GA14265@chinook.rgy.netsol.com> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20031105185128.8EA8518E4@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I think Matt's pegged it. Format 1 is clever but more complicated than the problem at hand seems to merit. My preference would be either format 0 or David's trivial optimization on format 0. -- to unsubscribe send a message to namedroppers-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 Nov 5 14:16:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17872 for ; Wed, 5 Nov 2003 14:16:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHT3h-0009ix-FA for namedroppers-data@psg.com; Wed, 05 Nov 2003 19:11:13 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHT3V-0009iO-Te for namedroppers@ops.ietf.org; Wed, 05 Nov 2003 19:11:01 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id B1D891394C for ; Wed, 5 Nov 2003 19:11:01 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Large typecodes and DNSSEC In-Reply-To: Message from Rob Austein of "Wed, 05 Nov 2003 13:51:28 EST." <20031105185128.8EA8518E4@thrintun.hactrn.net> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 05 Nov 2003 19:11:01 +0000 Message-Id: <20031105191101.B1D891394C@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I think Matt's pegged it. Format 1 is clever but more complicated > than the problem at hand seems to merit. My preference would be > either format 0 or David's trivial optimization on format 0. i very nearly agree, but if so then the draft needs an explaination of the fact that no secured name can have more than 32000 type codes in use. -- to unsubscribe send a message to namedroppers-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 Nov 5 14:17:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17920 for ; Wed, 5 Nov 2003 14:17:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHT5n-0009r9-FI for namedroppers-data@psg.com; Wed, 05 Nov 2003 19:13:23 +0000 Received: from [128.9.144.145] (helo=gamma.isi.edu) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHT5a-0009qN-GK for namedroppers@ops.ietf.org; Wed, 05 Nov 2003 19:13:10 +0000 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id hA5JD2W16447; Wed, 5 Nov 2003 11:13:02 -0800 (PST) Message-Id: <200311051913.hA5JD2W16447@gamma.isi.edu> To: IETF-Announce: ; Subject: RFC 3655 on Redefinition of DNS Authenticated Data (AD) bit Cc: rfc-editor@rfc-editor.org, namedroppers@ops.ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 05 Nov 2003 11:13:02 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-19.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME,USER_IN_DEF_WHITELIST autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3655 Title: Redefinition of DNS Authenticated Data (AD) bit Author(s): B. Wellington, O. Gudmundsson Status: Standards Track Date: November 2003 Mailbox: Brian.Wellington@nominum.com, ogud@ogud.com Pages: 8 Characters: 15646 Updates: 2535 I-D Tag: draft-ietf-dnsext-ad-is-secure-06.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3655.txt This document alters the specification defined in RFC 2535. Based on implementation experience, the Authenticated Data (AD) bit in the DNS header is not useful. This document redefines the AD bit such that it is only set if all answers or records proving that no answers exist in the response has been cryptographically verified or otherwise meets the server's local security policy. This document is a product of the DNS Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <031105111113.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3655 --OtherAccess Content-Type: Message/External-body; name="rfc3655.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <031105111113.RFC@RFC-EDITOR.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 Nov 5 15:55:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23339 for ; Wed, 5 Nov 2003 15:55:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHUay-000Iu5-3j for namedroppers-data@psg.com; Wed, 05 Nov 2003 20:49:40 +0000 Received: from [205.150.200.166] (helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHUag-000InS-D1 for namedroppers@ops.ietf.org; Wed, 05 Nov 2003 20:49:22 +0000 Received: from sandelman.ottawa.on.ca ([2002:cd96:c8f7::1]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id h9TLrXm06196 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Wed, 29 Oct 2003 16:53:34 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9TLj77L015636 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 29 Oct 2003 16:45:07 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9TLj6Ga015632 for ; Wed, 29 Oct 2003 16:45:06 -0500 To: namedroppers@ops.ietf.org Subject: Re: Large typecodes and DNSSEC In-reply-to: Your message of "Wed, 29 Oct 2003 15:43:32 EST." <8F2EA9A2-0A50-11D8-A3BA-000393C783A2@isi.edu> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 29 Oct 2003 16:45:06 -0500 Message-ID: <15631.1067463906@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- My opinion: >>>>> "Daniel" == Daniel Massey writes: Daniel> e NSECbis has "ordered list" and replaces NSEC [2] With ordered list as specified by Graff's "compressed" format as the only format. Or the basic one. I don't care. Daniel> A simple list is more likely be done correctly. ] Collecting stories about my dad: http://www.sandelman.ca/cjr/ | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP6A04IqHRg3pndX9AQFLtQP/YbfcE7txOOUQOUrY8Hecgsdnv1NWY/qW ZjZ6KNos+ib3zeEoPZMjOuIPs9avCoVfQrrzv/UczSCbj6InLiRA+J2XhqTGkV8J 8NsoTkjde6j3U0TL5VDrd+D1ZDZNJ5UdnWA/COIYT8jZy/E2ULZyWgw26O8plP5K wb8BXemHJAA= =XTND -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Nov 5 15:55:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23355 for ; Wed, 5 Nov 2003 15:55:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHUbC-000Iux-Mr for namedroppers-data@psg.com; Wed, 05 Nov 2003 20:49:54 +0000 Received: from [205.150.200.166] (helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHUak-000InS-H0 for namedroppers@ops.ietf.org; Wed, 05 Nov 2003 20:49:26 +0000 Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [205.150.200.247]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id h9TIXXk05288 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Wed, 29 Oct 2003 13:33:39 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9TINH7L031677 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 29 Oct 2003 13:23:18 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9TINGl9031673; Wed, 29 Oct 2003 13:23:17 -0500 To: Michael Graff cc: namedroppers@ops.ietf.org Subject: Re: Large typecodes and DNSSEC In-reply-to: Your message of "Wed, 29 Oct 2003 17:21:49 GMT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 29 Oct 2003 13:23:16 -0500 Message-ID: <31672.1067451796@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Michael" == Michael Graff writes: Michael> And here it is. :) Thank you. I suggest that the working group adopt this document. Michael> F The encoding format used. 0 indicates a simple list of 16-bit Michael> type codes. 1 indicates a slightly compressed type code list. Michael> 6 - Format 1: compressed type code list Minimally complicated, sure. Probably really easy to implement. I'm not even sure it is worth it. Likely not even worth my words to ask if it is worth it. Just do it. ] Collecting stories about my dad: http://www.sandelman.ca/cjr/ | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP6AFkoqHRg3pndX9AQFZyQP8D3tR6Q8O6GrUauqK5Dwcr0V2RVYHFLAc xKUjACdCulCVpxW99ot1si65UFXMlsQdnMrvsMhkASC6TjyXFZ+R8myIMIyGzggu XDaRt35i9MOQQs5PK2gojmIy/FwzB0Gm5Fr+iweHj5qjV1PiO/bOkaZcU1ITm56h f9KkX9dE0ys= =/obH -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Nov 5 15:56:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23379 for ; Wed, 5 Nov 2003 15:56:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHUbV-000IxJ-L4 for namedroppers-data@psg.com; Wed, 05 Nov 2003 20:50:13 +0000 Received: from [205.150.200.166] (helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHUal-000InS-Po for namedroppers@ops.ietf.org; Wed, 05 Nov 2003 20:49:27 +0000 Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [205.150.200.247]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id h9T13Vq01213 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Tue, 28 Oct 2003 20:03:38 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9T0pr7L032572 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 28 Oct 2003 19:51:54 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9T0poQi032568; Tue, 28 Oct 2003 19:51:50 -0500 To: David Blacka cc: namedroppers@ops.ietf.org Subject: Re: Large typecodes and DNSSEC In-reply-to: Your message of "Tue, 28 Oct 2003 16:47:45 EST." <200310281647.45423.davidb@verisignlabs.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 28 Oct 2003 19:51:50 -0500 Message-ID: <32567.1067388710@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "David" == David Blacka writes: David> At this point, having read through long threads discussion what we David> might have to do if RSA is broken, I am at a loss to understand David> why this issue hasn't been considered important. Actually, I am Fatigue. It was my understanding that when this topic last came up, that the WG was pretty exhausted about other things. David> Why not take a position? I'll take a position: DNSSEC is not David> complete without the ability to handle types > 127. Just because David> there aren't any now is no excuse. I concur, and we should fix it. David> - use the remaining 7 bits in the first octet as a count of David> single-byte typecodes, called N. The next N octets are an ordered David> list of 8-bit integers representing typecodes <= 255. The David> remaining RDATA is an ordered list of 16-bit big-endian unsigned David> integers, each representing one type present. Works for me. ] Collecting stories about my dad: http://www.sandelman.ca/cjr/ | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP58PJIqHRg3pndX9AQG/rQQAyJ1ZTg7CJGhh4avX1wohkFc4f5PykZSs D0br1XqMzGQTlW2I19TiSJ1hRlbiwV7JvYrp55+W6dnioaBSQ56hpapgUHYpSHy0 EI6wYaAsVwpAfYAfUwkl3d/V/hIDconNo3lD9eTNp0kYYPLKThK/o4Aao74tfOyj gJvAZn07LZg= =SLKg -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Nov 5 16:30:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24985 for ; Wed, 5 Nov 2003 16:30:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHVAQ-000PYk-0X for namedroppers-data@psg.com; Wed, 05 Nov 2003 21:26:18 +0000 Received: from [2001:4f8:3:ba:230:48ff:fe41:674c] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHVAD-000PXg-8G for namedroppers@ops.ietf.org; Wed, 05 Nov 2003 21:26:05 +0000 Received: from [10.0.1.4] (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 075F51B202C; Wed, 5 Nov 2003 15:19:54 -0600 (CST) In-Reply-To: <32567.1067388710@marajade.sandelman.ottawa.on.ca> References: <32567.1067388710@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: namedroppers From: Ted Lemon Subject: Re: Large typecodes and DNSSEC Date: Wed, 5 Nov 2003 15:26:01 -0600 To: Michael Richardson X-Mailer: Apple Mail (2.606) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Oct 28, 2003, at 6:51 PM, Michael Richardson wrote: > David> - use the remaining 7 bits in the first octet as a count of > David> single-byte typecodes, called N. The next N octets are an > ordered > David> list of 8-bit integers representing typecodes <= 255. The > David> remaining RDATA is an ordered list of 16-bit big-endian > unsigned > David> integers, each representing one type present. > > Works for me. Er, if we're going to change the format anyway, why not avoid having a flag bit? -- to unsubscribe send a message to namedroppers-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 Nov 5 17:15:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26932 for ; Wed, 5 Nov 2003 17:15:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHVqQ-0001pY-BV for namedroppers-data@psg.com; Wed, 05 Nov 2003 22:09:42 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHVqD-0001p0-Lj for namedroppers@ops.ietf.org; Wed, 05 Nov 2003 22:09:29 +0000 Received: by shell-ng.nominum.com (Postfix, from userid 11053) id DDC465686D; Wed, 5 Nov 2003 14:09:28 -0800 (PST) Date: Wed, 5 Nov 2003 14:09:28 -0800 From: Stephen Jacob To: namedroppers Subject: Re: Large typecodes and DNSSEC Message-ID: <20031105220928.GA28784@shell-ng.nominum.com> References: <32567.1067388710@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-message-flag: MS Outlook sucks. If you must use Windows, try Eudora. X-URI: http://www.nominum.com/ Organization: Nominum, Inc. X-URI-Personal: http://www.sjacob.org/ User-Agent: Mutt/1.5.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, Nov 05, 2003 at 03:26:01PM -0600, Ted Lemon wrote: > On Oct 28, 2003, at 6:51 PM, Michael Richardson wrote: > > David> - use the remaining 7 bits in the first octet as a count of > > David> single-byte typecodes, called N. The next N octets are an > >ordered > > David> list of 8-bit integers representing typecodes <= 255. The > > David> remaining RDATA is an ordered list of 16-bit big-endian > >unsigned > > David> integers, each representing one type present. > > > > Works for me. > > Er, if we're going to change the format anyway, why not avoid having a > flag bit? I have to say I dislike the scheme suggested above (David's). With Michael Graff's format 1 (compressed), you get a homogenous list of lists (with each sub-list having a 'header', for wont of a better word). With David's scheme, you have a 'header' byte and then a list in one format, followed by a list in a different format (so the format of the data change part way through). Michael's scheme makes more intuitive sense to me and doesn't seem like it would be any burden on implementors. I tend to think that his draft, with format 0 (uncompressed; list of 16-bit codes) removed would be the best solution to the problem. Regards, sj -- Stephen Jacob | Stephen.Jacob@nominum.com | +1 650 381 6051 Nominum, Inc. | http://www.nominum.com/ | "Communication by Name" -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Nov 6 15:19:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28064 for ; Thu, 6 Nov 2003 15:19:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHqQi-0002pa-PZ for namedroppers-data@psg.com; Thu, 06 Nov 2003 20:08:32 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHqQa-0002oO-GC for namedroppers@ops.ietf.org; Thu, 06 Nov 2003 20:08:24 +0000 Received: from ENGILL.ogud.com (mail.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id hA6K7BAh000786 for ; Thu, 6 Nov 2003 15:07:13 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.0.0.22.2.20031106143303.034cf008@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 06 Nov 2003 15:07:40 -0500 To: namedroppers From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: New IANA considerations for Typecode-rollover-05 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_00,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This proposed text replaces what is in the tcr-05. Summary: The main problem is to keep DNSEKY and KEY algorithm numbers in sync, and possibly allow the definition DNS wire format for algorithms that are not used by DNS, (for example ECC). Solution is to create a separate DNS Security algorithm registry that is not type dependant, then create one registry for each type that stores KEY information that inherits definitions. This allows central definition of DNS wireformat for public keys and then allow the application specific type records (KEY, DNSKEY, IPSECKEY etc.) to pick the algorithms they need. Please send in corrections/suggestions to make this text better Olafur --------- 5. 0 IANA Considerations This document updates the IANA registry for DNS Resource Record Types by assigning types 46, 47 and 48 to the RRSIG, NSEC, and DNSKEY RRs, respectively. This document updates the IANA registry for DNS Resource Record Types by assigning types 46, 47 and 48 to the RRSIG, NSEC, and DNSKEY RRs, respectively. Type 30 NXT is marked as obsolete. Types 24 and 26 (SIG and KEY) are retained for SIG(0) [RFC2931] and TKEY [RFC2930] use only. For use representing Public Key's in DNS the DNS Security Algorithm Registry is changed from being type KEY specific to a RR type independent, there is no change in the current contents of the registry. Updating this Registry requires IETF Standards Action. When a RR type inherits a definition from this registry, it uses the same one byte value to identify the algorithm as in this registry, unless specified otherwise for that type. Initial contents of this registry is: 0 Reserved [RFC-ietf-dnsext-dnssec-2535typecode-change-04.txt] 1 RSA/MD5 [RFC2537] 2 Diffie-Hellman [RFC2539] 3 DSA/SHA1 [RFC2536] 4 Unassigned (IETF Standards action required) 5 RSA/SHA-1 [RFC3110] 6-252 Unassigned (IETF Standards action required) 253 Private algorithms - domain name [RFC2535] 254 Private algorithms - OID [RFC2535] 255 Reserved [RFC-ietf-dnsext-dnssec-2535typecode-change-04.txt] For type KEY open a new registry named "KEY Algorithm registry" that inherits the following the definitions currently in DNSSEC Security Algorithm Registry, with the same algorithm number and mnemonics. Specifying a new Algorithm from the DNS Security Algorithm Registry requires IETF Consensus and a definition of a signature format for SIG RR type. Initial contents of this registry is: 1 RSA/MD5 [RFC2537] 2 Diffie-Hellman [RFC2539] 3 DSA/SHA1 [RFC2536] 4 Unassigned (IETF Standards action required) 5 RSA/SHA-1 [RFC3110] 6-252 Unassigned (IETF Standards action required) 253 Private algorithms - domain name [RFC2535] 254 Private algorithms - OID [RFC2535] 255 Reserved [RFC-ietf-dnsext-dnssec-2535typecode-change-04.txt] For type DNSKEY open a new registry named "DNSKEY algorithm registry" that inherits following definitions from DNS Security Algorithm Registry: 3 DSA/SHA1 [RFC2536] 5 RSA/SHA-1 [RFC3110] 253 Private algorithms - domain name [RFC2535] 254 Private algorithms - OID [RFC2535] RRSIG and DS Records use these values in their Algorithm value. Other values from the DNS Security Algorithm Numbers registry are available for assignment and require IETF Standards Action and a definition of a RRSIG signature format. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Nov 9 13:28:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05544 for ; Sun, 9 Nov 2003 13:28:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AIuA8-0006jt-Hl for namedroppers-data@psg.com; Sun, 09 Nov 2003 18:19:48 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AIu9y-0006ir-CA for namedroppers@ops.ietf.org; Sun, 09 Nov 2003 18:19:38 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.8p2/8.12.8) with ESMTP id hA58iFBk021555; Wed, 5 Nov 2003 09:44:15 +0100 (CET) (envelope-from roy@logmess.com) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.10/8.12.10/Debian-4) with ESMTP id hA58iCC8021469; Wed, 5 Nov 2003 09:44:14 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.10/8.12.10/Debian-4) with ESMTP id hA58iCDK021466; Wed, 5 Nov 2003 09:44:12 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 5 Nov 2003 09:44:12 +0100 (CET) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: Paul Vixie cc: namedroppers@ops.ietf.org Subject: Re: Q19: supression of duplicate RRs in an RRset In-Reply-To: <20031104213906.AD1041395D@sa.vix.com> Message-ID: References: <20031104213906.AD1041395D@sa.vix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 4 Nov 2003, Paul Vixie wrote: > > This is (probably) another non-issue, but for procedural completeness: > > > > Q19: Should multiple instances of identical RRs in an RRset be reduced to a > > single RR during the signing process? > > arguably not. these should be removed during the process of reading/loading/ > importing the zone, and so the signer should never see them, nor should axfr > be able to transfer them, or query be able to return them. Lets do worst case, and go with robustness principle. Disambiguate the RRset for cryptographic processing _only_. The disambiguation algorithm is documented, and has no bearing on whatever format the RRset itself leaves or arrives on the wire. Duplicate records in a RRset are legal and used for (imaginary) load balancing purposes (yes, I don't like it either). Roy > this is how bind8 and bind9 work in the case shown below: > > > Consider the zone file: > > > > a.example.com IN A 1.2.3.4 > > a.example.com IN A 4.3.2.1 > > b.example.com IN A 1.2.3.5 > > ... > > a.example.com IN A 1.2.3.4 > > duplicate rdata is just too hard to think about. > > > -- > to 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 Sun Nov 9 17:29:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12989 for ; Sun, 9 Nov 2003 17:29:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AIxzW-000HQM-Kb for namedroppers-data@psg.com; Sun, 09 Nov 2003 22:25:06 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AIxzT-000HPr-K7 for namedroppers@ops.ietf.org; Sun, 09 Nov 2003 22:25:03 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id hA9MMwcR010895 for ; Sun, 9 Nov 2003 17:22:58 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAX9aWrv; Sun, 9 Nov 03 17:22:57 -0500 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id hA9MNgwQ001741 for ; Sun, 9 Nov 2003 17:23:42 -0500 (EST) Date: Sun, 9 Nov 2003 17:23:42 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: namedroppers Subject: Re: New IANA considerations for Typecode-rollover-05 In-Reply-To: <6.0.0.22.2.20031106143303.034cf008@localhost> Message-ID: References: <6.0.0.22.2.20031106143303.034cf008@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_00,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This attempts to force algorithms to use the same number across functions, which tcr-05 does informally with the phrase: "... suggested, but not required, that it be assigned the same number in both registries". That's a fine idea, but actually copying the registry data around seems certain to lead to confusion, particularly if we say that the algorithm numbers may be changed during the copying. If the WG really wants to go this route, I suggest making the current registry generic and adding applicability list registries. As in: The "DNS Transaction Security Algorithm Applicability" registry lists those algorithms from the "DNS Security Algorithm Numbers" registry that are usable by the DNS transaction security mechanims (SIG(0) and TKEY) and, in particular, usable in KEY and SIG records. It initially includes algorithm numbers 1, 2, 3, 5, 252, 253, and 254. Personally, I think tcr-05's solution is adequate, particularly if the relevant sentence is copied into the registries to remind IANA of what to do. I'd be happy to consider some stronger text in that paragraph, if anyone has something to suggest. As in: "If an algorithm is defined in only one registry, it is suggested that the number assigned to it not be assigned in the other registry." Furthermore, the proposed text misstates the current assignments (it misses Indirect and the ECC reservation) and doesn't add the mnemonics to the registry, which TCR-05 tries to fix. -- 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 Sun Nov 9 20:26:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21490 for ; Sun, 9 Nov 2003 20:26:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJ0ju-000P4b-CI for namedroppers-data@psg.com; Mon, 10 Nov 2003 01:21:10 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJ0js-000P4I-5X for namedroppers@ops.ietf.org; Mon, 10 Nov 2003 01:21:08 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id hAA1J2R0019627 for ; Sun, 9 Nov 2003 20:19:02 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAimaqvM; Sun, 9 Nov 03 20:19:01 -0500 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id hAA1JhV4004862; Sun, 9 Nov 2003 20:19:43 -0500 (EST) Date: Sun, 9 Nov 2003 20:19:43 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: Roy Arends cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: Q19: supression of duplicate RRs in an RRset In-Reply-To: Message-ID: References: <20031104213906.AD1041395D@sa.vix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 5 Nov 2003, Roy Arends wrote: > Disambiguate the RRset for cryptographic processing _only_. The > disambiguation algorithm is documented, and has no bearing on whatever > format the RRset itself leaves or arrives on the wire. You mean by suppressing duplicates, right? > Duplicate records in a RRset are legal and used for (imaginary) load > balancing purposes (yes, I don't like it either). RFC2181 (proposed standard), Section 5: "It is meaningless for two records to ever have label, class, type and data all equal - servers should suppress such duplicates if encountered." Since a 2181 compliant server should [1] suppress duplicates, it would be foolish to assume than duplicates will reliably reach a validator. If we want to change that and come up with a disambiguation scheme that accomodates duplicates, then we need something other than 2181-compliant servers transporting the data. In other words, we should give up now. -- Sam [1] 2181, section 3: This memo does not use the oft used expressions MUST, SHOULD, MAY, or their negative forms. In some sections it may seem that a specification is worded mildly, and hence some may infer that the specification is optional. That is not correct. Anywhere that this memo suggests that some action should be carried out, or must be carried out, or that some behaviour is acceptable, or not, that is to be considered as a fundamental aspect of this specification, regardless of the specific words used. If some behaviour or action is truly optional, that will be clearly specified by the text. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Nov 9 23:23:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24594 for ; Sun, 9 Nov 2003 23:23:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJ3WF-000Eb6-N8 for namedroppers-data@psg.com; Mon, 10 Nov 2003 04:19:15 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJ3WC-000Eam-5c for namedroppers@ops.ietf.org; Mon, 10 Nov 2003 04:19:12 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.8p2/8.12.8) with ESMTP id hAA4IloQ058761; Mon, 10 Nov 2003 05:18:47 +0100 (CET) (envelope-from roy@logmess.com) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.10/8.12.10/Debian-4) with ESMTP id hAA4Iitp004272; Mon, 10 Nov 2003 05:18:44 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.10/8.12.10/Debian-4) with ESMTP id hAA4Ih8j004269; Mon, 10 Nov 2003 05:18:43 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Mon, 10 Nov 2003 05:18:43 +0100 (CET) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: Samuel Weiler cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: Q19: supression of duplicate RRs in an RRset In-Reply-To: Message-ID: References: <20031104213906.AD1041395D@sa.vix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sun, 9 Nov 2003, Samuel Weiler wrote: > On Wed, 5 Nov 2003, Roy Arends wrote: > > > Disambiguate the RRset for cryptographic processing _only_. The > > disambiguation algorithm is documented, and has no bearing on whatever > > format the RRset itself leaves or arrives on the wire. > > You mean by suppressing duplicates, right? Yep, for crypto purposes only. It is okay to have dupes on the wire or in presentation format. > > Duplicate records in a RRset are legal and used for (imaginary) load > > balancing purposes (yes, I don't like it either). > > RFC2181 (proposed standard), Section 5: "It is meaningless for two > records to ever have label, class, type and data all equal - servers > should suppress such duplicates if encountered." > > Since a 2181 compliant server should [1] suppress duplicates, it would > be foolish to assume than duplicates will reliably reach a validator. Not at all. There might be implementations written by folk who interpret "should" less stringent as others. > If we want to change that and come up with a disambiguation scheme > that accomodates duplicates, then we need something other than > 2181-compliant servers transporting the data. > > In other words, we should give up now. Sure. We agree. Disambigation text (canonical form for RRsets) needs to include text on surpressing dupes. Lets not put any restrictions on the wire and presentation format. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 10 00:05:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25610 for ; Mon, 10 Nov 2003 00:05:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJ4B1-000Ivs-MB for namedroppers-data@psg.com; Mon, 10 Nov 2003 05:01:23 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AJ4Ay-000IvQ-AH for namedroppers@ops.ietf.org; Mon, 10 Nov 2003 05:01:20 +0000 Received: (qmail 54505 invoked from network); 10 Nov 2003 05:07:59 -0000 Received: from dyn140-174.ietf58.ietf.org (HELO necom830.hpcl.titech.ac.jp) (130.129.140.174) by necom830.hpcl.titech.ac.jp with SMTP; 10 Nov 2003 05:07:59 -0000 Message-ID: <3FAF1BFD.9030105@necom830.hpcl.titech.ac.jp> Date: Mon, 10 Nov 2003 14:02:53 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: masataka ohta CC: Rob Austein , namedroppers@ops.ietf.org, dnsop@cafax.se Subject: Re: Reality check (was Re: Wildcard NS and DNSSEC) References: <20031027142404.GB15077@atoom.net> <200310282352.h9SNqI8Y001833@drugs.dv.isc.org> <20031029012822.C263718DD@thrintun.hactrn.net> <3FA08FF3.2000708@necom830.hpcl.titech.ac.jp> In-Reply-To: <3FA08FF3.2000708@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I'm posting to both DNSEXT and DNSOP. As I post to DNSEXT ML, > I do love simple approaches. > > However, in this case, the complexity is not in wildcard but > in DNSSEC. > > So, the proper question is > > do we need DNSSEC? > > and the reality is that we don't. > > Just discard DNSSEC and move along. I think secure DNS, with its complexity, is hard to deploy and does not worth the deployment effot. Given that securty problem on small ID space is solvable (as was discussed recently with subject "preventing cache contamination"), do we still have to try secure DNS deployed (in vain)? Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 10 08:30:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18859 for ; Mon, 10 Nov 2003 08:30:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJC0x-000EYc-0p for namedroppers-data@psg.com; Mon, 10 Nov 2003 13:23:31 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJC0v-000EYK-8l for namedroppers@ops.ietf.org; Mon, 10 Nov 2003 13:23:29 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 82A4E1396E for ; Mon, 10 Nov 2003 13:23:28 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Q19: supression of duplicate RRs in an RRset In-Reply-To: Message from Roy Arends of "Mon, 10 Nov 2003 05:18:43 +0100." X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 10 Nov 2003 13:23:28 +0000 Message-Id: <20031110132328.82A4E1396E@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ... It is okay to have dupes on the wire or in presentation format. i don't agree. > > Since a 2181 compliant server should [1] suppress duplicates, it would > > be foolish to assume than duplicates will reliably reach a validator. > > Not at all. There might be implementations written by folk who interpret > "should" less stringent as others. 2181 explains exactly what it means by "should". > Lets not put any restrictions on the wire and presentation format. we have to. otherwise the rrset which is being signed and validated is materially different from the one the zone administrator thinks that she created. if there are rdata duplicates then both the signer and validator should signal an error. -- to unsubscribe send a message to namedroppers-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 Nov 10 08:35:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18969 for ; Mon, 10 Nov 2003 08:35:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJC80-000FNe-9D for namedroppers-data@psg.com; Mon, 10 Nov 2003 13:30:48 +0000 Received: from [127.0.0.1] (helo=roam.psg.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJC7y-000FNN-Oq for namedroppers@ops.ietf.org; Mon, 10 Nov 2003 13:30:46 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJC7y-0000Z4-Vi for namedroppers@ops.ietf.org; Mon, 10 Nov 2003 07:30:47 -0600 Message-ID: <20031110072529.GA3354@outpost.ds9a.nl> Mail-Followup-To: bert hubert , Masataka Ohta , Rob Austein , namedroppers@ops.ietf.org, dnsop@cafax.se References: <20031027142404.GB15077@atoom.net> <200310282352.h9SNqI8Y001833@drugs.dv.isc.org> <20031029012822.C263718DD@thrintun.hactrn.net> <3FA08FF3.2000708@necom830.hpcl.titech.ac.jp> <3FAF1BFD.9030105@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FAF1BFD.9030105@necom830.hpcl.titech.ac.jp> Date: Mon, 10 Nov 2003 08:25:29 +0100 From: bert hubert To: Masataka Ohta Cc: Rob Austein , namedroppers@ops.ietf.org, dnsop@cafax.se Subject: Re: Reality check (was Re: Wildcard NS and DNSSEC) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] On Mon, Nov 10, 2003 at 02:02:53PM +0900, Masataka Ohta wrote: > >Just discard DNSSEC and move along. > > I think secure DNS, with its complexity, is hard to deploy and does > not worth the deployment effot. Some days ago I wrote http://ds9a.nl/secure-dns.html which may be relevant. Bert. -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing & Traffic Control HOWTO -- to unsubscribe send a message to namedroppers-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 Nov 10 09:55:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21707 for ; Mon, 10 Nov 2003 09:55:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJDMY-000Ob3-N1 for namedroppers-data@psg.com; Mon, 10 Nov 2003 14:49:54 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJDMX-000Oaq-4v for namedroppers@ops.ietf.org; Mon, 10 Nov 2003 14:49:53 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id F350813969 for ; Mon, 10 Nov 2003 14:49:52 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Q19: supression of duplicate RRs in an RRset In-Reply-To: Message from Olaf M.Kolkman of "Mon, 10 Nov 2003 08:46:56 CST." X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 10 Nov 2003 14:49:52 +0000 Message-Id: <20031110144952.F350813969@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > .. if there are rdata duplicates then both the signer and validator > > should signal an error. > > And still be liberal in what they expect, i.e. forward the answer with > duplicates stripped and final answer verified to the application? no. a validating forwarder would turn an answer with dup rdata's into the same condition as "signature failed to validate" which means, i think, dropping it. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 10 09:57:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21785 for ; Mon, 10 Nov 2003 09:57:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJDJk-000O8m-Gx for namedroppers-data@psg.com; Mon, 10 Nov 2003 14:47:00 +0000 Received: from [130.129.139.239] (helo=ernie.secret-wg.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJDJi-000O7g-0J for namedroppers@ops.ietf.org; Mon, 10 Nov 2003 14:46:58 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by ernie.secret-wg.org (Postfix) with ESMTP id 92A21178254; Mon, 10 Nov 2003 08:46:57 -0600 (CST) In-Reply-To: <20031110132328.82A4E1396E@sa.vix.com> References: <20031110132328.82A4E1396E@sa.vix.com> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org From: "Olaf M.Kolkman" Subject: Re: Q19: supression of duplicate RRs in an RRset Date: Mon, 10 Nov 2003 08:46:56 -0600 To: Paul Vixie X-Mailer: Apple Mail (2.606) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > created. if there are rdata duplicates then both the signer and > validator > should signal an error. > And still be liberal in what they expect, i.e. forward the answer with duplicates stripped and final answer verified to the application? -- to unsubscribe send a message to namedroppers-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 Nov 10 12:43:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02734 for ; Mon, 10 Nov 2003 12:43:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJFzK-000III-Kb for namedroppers-data@psg.com; Mon, 10 Nov 2003 17:38:06 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AJFzH-000IHq-O9 for namedroppers@ops.ietf.org; Mon, 10 Nov 2003 17:38:04 +0000 Received: (qmail 56533 invoked from network); 10 Nov 2003 17:44:52 -0000 Received: from dyn074-234.ietf58.ietf.org (HELO necom830.hpcl.titech.ac.jp) (130.129.74.234) by necom830.hpcl.titech.ac.jp with SMTP; 10 Nov 2003 17:44:52 -0000 Message-ID: <3FAFCD5A.9020607@necom830.hpcl.titech.ac.jp> Date: Tue, 11 Nov 2003 02:39:38 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: bert hubert CC: Rob Austein , namedroppers@ops.ietf.org, dnsop@cafax.se Subject: Re: Reality check (was Re: Wildcard NS and DNSSEC) References: <20031027142404.GB15077@atoom.net> <200310282352.h9SNqI8Y001833@drugs.dv.isc.org> <20031029012822.C263718DD@thrintun.hactrn.net> <3FA08FF3.2000708@necom830.hpcl.titech.ac.jp> <3FAF1BFD.9030105@necom830.hpcl.titech.ac.jp> <20031110072529.GA3354@outpost.ds9a.nl> In-Reply-To: <20031110072529.GA3354@outpost.ds9a.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Bert; >>>Just discard DNSSEC and move along. >> >>I think secure DNS, with its complexity, is hard to deploy and does >>not worth the deployment effot. > Some days ago I wrote http://ds9a.nl/secure-dns.html which may be relevant. I mostly agree (of course). But, note that it was intended to provide confidentiality by sharing an IPSEC session key with public keys of a host obtained from secure DNS, though it is not practical with reasons you mentioned. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 10 14:12:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06487 for ; Mon, 10 Nov 2003 14:12:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJHKS-0001kb-0M for namedroppers-data@psg.com; Mon, 10 Nov 2003 19:04:00 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJHKL-0001jy-OH for namedroppers@ops.ietf.org; Mon, 10 Nov 2003 19:03:53 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.8p2/8.12.8) with ESMTP id hAAJ3ToQ008739; Mon, 10 Nov 2003 20:03:29 +0100 (CET) (envelope-from roy@logmess.com) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.10/8.12.10/Debian-4) with ESMTP id hAAJ3QrU019738; Mon, 10 Nov 2003 20:03:26 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.10/8.12.10/Debian-4) with ESMTP id hAAJ3PmA019735; Mon, 10 Nov 2003 20:03:26 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Mon, 10 Nov 2003 20:03:25 +0100 (CET) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: Paul Vixie cc: namedroppers@ops.ietf.org Subject: Re: Q19: supression of duplicate RRs in an RRset In-Reply-To: <20031110144952.F350813969@sa.vix.com> Message-ID: References: <20031110144952.F350813969@sa.vix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 10 Nov 2003, Paul Vixie wrote: > > > .. if there are rdata duplicates then both the signer and validator > > > should signal an error. > > > > And still be liberal in what they expect, i.e. forward the answer with > > duplicates stripped and final answer verified to the application? > > no. a validating forwarder would turn an answer with dup rdata's into > the same condition as "signature failed to validate" which means, i > think, dropping it. Paul, before the forwarder validates, it would surpress duplicates inside RRsets. The same is done before the signer signs the RRsets. Duplicates on wire can't be outlawed by the DNSSEC rewrite. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 10 14:27:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07291 for ; Mon, 10 Nov 2003 14:27:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJHaY-00039Z-JY for namedroppers-data@psg.com; Mon, 10 Nov 2003 19:20:38 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJHa9-00036t-KA for namedroppers@ops.ietf.org; Mon, 10 Nov 2003 19:20:13 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 9DEB113969 for ; Mon, 10 Nov 2003 19:20:12 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Q19: supression of duplicate RRs in an RRset In-Reply-To: Message from Roy Arends of "Mon, 10 Nov 2003 20:03:25 +0100." X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 10 Nov 2003 19:20:12 +0000 Message-Id: <20031110192012.9DEB113969@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Paul, before the forwarder validates, it would surpress duplicates inside > RRsets. The same is done before the signer signs the RRsets. this means that what's being signed and validated is different from what the zone administrator believes. consider that someone who mistakenly uses duplicate rdata to indicate load balancing preferences will end up not changing the signature of the resulting rrset, even if the difference is the removal of a duplicate, or the addition of duplicates beyond just one. this yields interesting MIM possibilities since a forwarder could remove OR ADD duplicates, perhaps lots of duplicates, without making the rrset's signature invalid. > Duplicates on wire can't be outlawed by the DNSSEC rewrite. you're right, but only because 2181 already did so. -- to unsubscribe send a message to namedroppers-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 Nov 10 18:52:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24056 for ; Mon, 10 Nov 2003 18:52:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJLih-0007ke-51 for namedroppers-data@psg.com; Mon, 10 Nov 2003 23:45:19 +0000 Received: from [130.129.142.25] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJLif-0007kR-FQ for namedroppers@ops.ietf.org; Mon, 10 Nov 2003 23:45:17 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9p2/8.12.9) with ESMTP id hAANjBfj000457 for ; Tue, 11 Nov 2003 10:45:11 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200311102345.hAANjBfj000457@drugs.dv.isc.org> To: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: alternative NSEC encoding Date: Tue, 11 Nov 2003 10:45:11 +1100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The following a simple windowed bitmap alternative encoding to consider of NSEC. It is a logical extension of the current NXT encoding and while not as efficient as Micheal's should be easier to implement without errors. We take the type space and split it into 256 windows and present a bitmap for each window that has a active type. This is endcode as a window octet, bitmap length octet (1..32) and a bitmap in network bit order (similar to NXT). Trailing zero octets in the bitmap MUST be removed. Each window is presented in numerical order. [ ] + The zero window is types 0..255. e.g. NSEC example. A 7 'e' 'x' 'a' 'm' 'p' 'l' 'e' 0 0 1 64 NSEC example. A TYPE3000 7 'e' 'x' 'a' 'm' 'p' 'l' 'e' 0 0 1 64 11 23 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 128 In the worst case the encoding the bitmaps give 8704 octets (type in last 8 types of each window). Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 10 23:01:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03682 for ; Mon, 10 Nov 2003 23:01:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJPem-0006GB-5s for namedroppers-data@psg.com; Tue, 11 Nov 2003 03:57:32 +0000 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJPek-0006Fy-J7 for namedroppers@ops.ietf.org; Tue, 11 Nov 2003 03:57:30 +0000 Received: from isi.edu (dyn132-215.ietf58.ietf.org [130.129.132.215]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id hAB3vMa04595; Mon, 10 Nov 2003 19:57:22 -0800 (PST) Date: Mon, 10 Nov 2003 22:57:20 -0500 Subject: Q20: expanding wildcards in the authority section Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Daniel Massey To: namedroppers@ops.ietf.org From: Daniel Massey Content-Transfer-Encoding: 7bit Message-Id: <265EC638-13FB-11D8-9A3D-000393C783A2@isi.edu> X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, When placing an NSEC RR in the authority section, should the wildcard be expanded? For example, see the NO DATA reply in section B.7 of the protocol draft. (rough version below) ;; Question a.z.w.example. IN AAAA ;; Answer (empty) ;; Authority example. 3600 IN SOA ns1.example. bugs.ns1.example. ( snip ) example. 3600 RRSIG SOA 1 1 3600 20031108232541 ( snip ) x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC (snip) x.y.w.example. 3600 RRSIG NSEC 1 4 3600 20031108232541 (snip) *.w.example. 3600 NSEC x.w.example. MX RRSIG NSEC (snip) *.w.example. 3600 RRSIG NSEC 1 2 3600 20031108232541 (snip) ;; Additional (empty) Note the last two entries in the authority section are "*.w.example." Is this unexpanded wildcard correct or should the wildcard have been expanded to "a.z.w.example" instead? This question is (hopefully) just a sanity check that the current protocol text (wildcard is not expanded) is correct and does not reflect any change from past documents, but a clear answer from past documents is elusive so the issue is posted here as question 20. Dan -- to unsubscribe send a message to namedroppers-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 Nov 11 01:45:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08822 for ; Tue, 11 Nov 2003 01:45:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJSA7-000Kno-K5 for namedroppers-data@psg.com; Tue, 11 Nov 2003 06:38:03 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJSA2-000KnF-Jw for namedroppers@ops.ietf.org; Tue, 11 Nov 2003 06:37:58 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.8p2/8.12.8) with ESMTP id hAB6bpGl003629; Tue, 11 Nov 2003 07:37:52 +0100 (CET) (envelope-from roy@logmess.com) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.10/8.12.10/Debian-4) with ESMTP id hAB6bnPo000972; Tue, 11 Nov 2003 07:37:49 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.10/8.12.10/Debian-4) with ESMTP id hAB6bmDq000969; Tue, 11 Nov 2003 07:37:48 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Tue, 11 Nov 2003 07:37:48 +0100 (CET) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: Paul Vixie cc: namedroppers@ops.ietf.org Subject: Re: Q19: supression of duplicate RRs in an RRset In-Reply-To: <20031110192012.9DEB113969@sa.vix.com> Message-ID: References: <20031110192012.9DEB113969@sa.vix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 10 Nov 2003, Paul Vixie wrote: > > Paul, before the forwarder validates, it would surpress duplicates inside > > RRsets. The same is done before the signer signs the RRsets. > > this means that what's being signed and validated is different from what > the zone administrator believes. consider that someone who mistakenly > uses duplicate rdata to indicate load balancing preferences will end up > not changing the signature of the resulting rrset, even if the difference > is the removal of a duplicate, or the addition of duplicates beyond just > one. this yields interesting MIM possibilities since a forwarder could > remove OR ADD duplicates, perhaps lots of duplicates, without making the > rrset's signature invalid. The MIM properties are not that interesting. One attack would be to influence the load balancing envisioned by the zone admin. I think we agree that load balancing using dupes are atrocious to begin with. So whoever wants to do loadbalancing is susceptible of this attack, which is minor to begin with. If the plan would be to DoS one of the balanced server to begin with, and the possibility of MiM'ing is a requirement to deploy the attack. The actual DoS would be much simpler to implement by just flipping a random bit, causing a sig to fail. > > Duplicates on wire can't be outlawed by the DNSSEC rewrite. > > you're right, but only because 2181 already did so. No contest. What we could probably agree on is that duplicates would/should not reach a signer/validator, since it would/should be dropped on inception by the server/resolver, due to 2181. So there is no need to specify anything on duplicates, right ? 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 Nov 11 12:01:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10071 for ; Tue, 11 Nov 2003 12:01:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJbm3-0006eL-O9 for namedroppers-data@psg.com; Tue, 11 Nov 2003 16:53:51 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJbm1-0006dx-8F for namedroppers@ops.ietf.org; Tue, 11 Nov 2003 16:53:49 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 3299013966 for ; Tue, 11 Nov 2003 16:53:48 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Q19: supression of duplicate RRs in an RRset In-Reply-To: Message from Roy Arends of "Tue, 11 Nov 2003 07:37:48 +0100." X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 11 Nov 2003 16:53:48 +0000 Message-Id: <20031111165348.3299013966@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > The MIM properties are not that interesting. ... I agree. It was just an example. The covert channel argument is another. > If the plan would be to DoS one of the balanced server to begin with, and > the possibility of MiM'ing is a requirement to deploy the attack. The > actual DoS would be much simpler to implement by just flipping a random > bit, causing a sig to fail. This is off topic but I don't agree just the same. > What we could probably agree on is that duplicates would/should not reach > a signer/validator, since it would/should be dropped on inception by the > server/resolver, due to 2181. Yes. > So there is no need to specify anything on duplicates, right ? That will have the right effect, yes. An overly liberal signer will still generate signatures for rrsets containing duplicate rdatas, but those signatures will be different depending on how many (including zero) duplicates are encountered. Therefore cooperating overly liberal endpoints can sign and validate rrsets containing duplicate rdatas, and strict 2181 implementations can treat duplicate rdatas as format errors. But it's possible that this should be spelled out explicitly in the docset, since it's been observed to be a complex and difficult subject. -- to unsubscribe send a message to namedroppers-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 Nov 11 12:46:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12946 for ; Tue, 11 Nov 2003 12:46:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJcUf-000BlJ-L2 for namedroppers-data@psg.com; Tue, 11 Nov 2003 17:39:57 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJcUV-000BkT-17 for namedroppers@ops.ietf.org; Tue, 11 Nov 2003 17:39:47 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.8p2/8.12.8) with ESMTP id hABHdiGl007399; Tue, 11 Nov 2003 18:39:44 +0100 (CET) (envelope-from roy@logmess.com) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.10/8.12.10/Debian-4) with ESMTP id hABHdfPo012602; Tue, 11 Nov 2003 18:39:41 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.10/8.12.10/Debian-4) with ESMTP id hABHdfSh012599; Tue, 11 Nov 2003 18:39:41 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Tue, 11 Nov 2003 18:39:41 +0100 (CET) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: Paul Vixie cc: namedroppers@ops.ietf.org Subject: Re: Q19: supression of duplicate RRs in an RRset In-Reply-To: <20031111165348.3299013966@sa.vix.com> Message-ID: References: <20031111165348.3299013966@sa.vix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 11 Nov 2003, Paul Vixie wrote: > > So there is no need to specify anything on duplicates, right ? > > That will have the right effect, yes. An overly liberal signer will still > generate signatures for rrsets containing duplicate rdatas, but those > signatures will be different depending on how many (including zero) > duplicates are encountered. Therefore cooperating overly liberal endpoints > can sign and validate rrsets containing duplicate rdatas, and strict > 2181 implementations can treat duplicate rdatas as format errors. > > But it's possible that this should be spelled out explicitly in the docset, > since it's been observed to be a complex and difficult subject. I agree, a description of behaviour, including reiterating 2181 on surpressing duplicates would be good. No _new_ specification though on hard requirements for the signer/validator to drop signatures on RRsets containing duplicates, that would be too conservative for my taste. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Nov 12 21:46:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23378 for ; Wed, 12 Nov 2003 21:46:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AK7NS-000LTB-Bh for namedroppers-data@psg.com; Thu, 13 Nov 2003 02:38:34 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AK7NQ-000LSu-6e for namedroppers@ops.ietf.org; Thu, 13 Nov 2003 02:38:32 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id hAD2aO99026777 for ; Wed, 12 Nov 2003 21:36:24 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA3Yaat0; Wed, 12 Nov 03 21:36:24 -0500 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id hAD2b9qI029774 for ; Wed, 12 Nov 2003 21:37:09 -0500 (EST) Date: Wed, 12 Nov 2003 21:37:09 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: namedroppers Subject: Re: New IANA considerations for Typecode-rollover-05 In-Reply-To: <6.0.0.22.2.20031106143303.034cf008@localhost> Message-ID: References: <6.0.0.22.2.20031106143303.034cf008@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_00,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Here's a possible TCR IANA section that makes the existing registry generic and adds two applicability lists. Again, I'd rather keep the TCR-05 solution, but I prefer the below to having a no-op registry that other registries may copy, copy with changes, or even ignore. Comments? Is the TCR-05 solution adequate? Do we need this? This document updates the IANA registry for DNS Resource Record Types by assigning types 46, 47, and 48 to the RRSIG, NSEC, and DNSKEY RRs, respectively. Types 24 and 25 (SIG and KEY) are retained for SIG(0) [RFC2931] and TKEY [RFC2930] use only. Type 30 (NXT) should be marked as Obsolete. In order to allow zone signing (DNSSEC) and transaction security mechanisms (SIG(0) and TKEY) to use different sets of algorithms and key formats, the existing "DNS Security Algorithm Numbers" registry will become a generic registry that isn't specific to any RR type. Two new registries are created, "DNS Transaction Security Algorithm Applicability" and "DNS Zone Signing Algorithm Applicability". (Alternate names: "KEY and SIG Algorithm Applicability" and "DNSKEY, DS, and RRSIG Algorithm Applicability") Each requires IETF Standards Action to change. "DNS Transaction Security Algorithm Applicability" lists those algorithms from the "DNS Security Algorithm Numbers" registry that are usable by the DNS transaction security mechanims (SIG(0) and TKEY) and, in particular, usable in KEY and SIG records. It initially includes algorithm numbers 1, 2, 3, 5, 252, 253, and 254. "DNS Zone Signing Algorithm Applicability" lists those algorithms from the "DNS Security Algorithm Numbers" registry that are usable for zone signing, and, in particular, the DNSKEY, DS, and RRSIG records. It initially includes algorithm numbers 2, 3, 5, 253, and 254. Additionally, presentation format mnemonics as defined in RFC2535 Section 7 are added to the "DNS Security Algorithm Numbers" registry. This document assigns RSA/SHA-1 (type 5) the mnemonic RSASHA1. As in RFC2535, IETF Standards Action is required to change this registry. At this time, values 4 and 6-251 are available for assignment, with 4 reserved for eliptic curve keys. -- to unsubscribe send a message to namedroppers-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 Nov 12 22:03:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24177 for ; Wed, 12 Nov 2003 22:03:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AK7gv-000Nlj-Lg for namedroppers-data@psg.com; Thu, 13 Nov 2003 02:58:41 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AK7gt-000NlW-Pq for namedroppers@ops.ietf.org; Thu, 13 Nov 2003 02:58:39 +0000 Received: from ENGILL.ogud.com (mail.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id hAD2ucAj035784 for ; Wed, 12 Nov 2003 21:56:41 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.0.0.22.2.20031112140426.02d6a1d0@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 12 Nov 2003 14:52:25 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: Re: DNSEXT Agenda IETF58 In-Reply-To: <20031104094424.06d55053.olaf@ripe.net> References: <20031104094424.06d55053.olaf@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,DATE_IN_PAST_06_12 autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is an update to the agenda affecting only the list of DNSSEC-bis open issues. At 03:44 2003-11-04, Olaf M. Kolkman wrote: > DNS Extensions WG (dnsext) > Time: Thursday, November 13, 1300-15:00 Afternoon Sessions I > Location: TBD. Location: Salon D. > Chairs: Olafur Gudmundsson and Olaf Kolkman. > Charter: http://www.ietf.org/html.charters/dnsext-charter.html > > > - DNSSEC-bis session 90 min > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-intro-07.txt > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-records-05.txt > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-protocol-03.txt > > This session will be broken down into at least following subsections > DNSSEC-bis editors report DNSSEC Editors report Open issues Q18: RRsig TTL can violate RFC2181 Q19: Suppression of duplications Q20: expand wildcard in Authority section? Q21: Caching and Reuse of NSEC RDATA Compression Guidelines NSEC types present revision > Document status, next steps and schedule > > Request for intent/status of implementations Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Nov 12 22:06:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24238 for ; Wed, 12 Nov 2003 22:06:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AK7iH-000O0f-LZ for namedroppers-data@psg.com; Thu, 13 Nov 2003 03:00:05 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AK7iE-000Nzk-5f for namedroppers@ops.ietf.org; Thu, 13 Nov 2003 03:00:02 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id hAD2vsBp028195 for ; Wed, 12 Nov 2003 21:57:54 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA2Vaqe3; Wed, 12 Nov 03 21:57:54 -0500 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id hAD2wdLo000254 for ; Wed, 12 Nov 2003 21:58:39 -0500 (EST) Date: Wed, 12 Nov 2003 21:58:39 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-dnssec-2535typecode-change-05.txt In-Reply-To: <200310131955.PAA23807@ietf.org> Message-ID: References: <200310131955.PAA23807@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Title : Legacy Resolver Compatibility for Delegation Signer > Author(s) : S. Weiler > Filename : draft-ietf-dnsext-dnssec-2535typecode-change-05.txt > Pages : 5 > Date : 2003-10-13 ... > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-2535typecode-change-05.txt There is a trivial but obvious bug in this document. The thing that disturbs me is that it took almost a month for anyone (besides the editor) to find it, or at least to point it out. Thanks to Rob Payne for actually reading the document. For being the first to mention the bug to me, Rob wins a pint of his choice at Brit's Pub or some other fine Minneapolis watering hole. (Read the docs. You might be surprised at what is (not) in them. And if you embarrass the doc editor(s) enough, you might even get free beer.) -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Nov 12 22:22:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24589 for ; Wed, 12 Nov 2003 22:22:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AK80j-000Py5-KS for namedroppers-data@psg.com; Thu, 13 Nov 2003 03:19:09 +0000 Received: from [129.6.16.93] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AK80f-000Pxl-Dx for namedroppers@ops.ietf.org; Thu, 13 Nov 2003 03:19:05 +0000 Received: from lapdancer ([129.6.220.2]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id hAD3Id18007361 for ; Wed, 12 Nov 2003 22:18:39 -0500 (EST) Message-ID: <005401c3a994$e11a0a60$e2868182@lapdancer> From: "Scott Rose" To: "namedroppers" References: <6.0.0.22.2.20031106143303.034cf008@localhost> Subject: Re: New IANA considerations for Typecode-rollover-05 Date: Wed, 12 Nov 2003 22:18:58 -0500 Organization: NIST MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_00,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This means there will be 3 registries for algorithm codes? (did I read that right?) If so, that seems a bit excessive since the 2 new registries get their values from the base registry. Scott Oh, and is the "trivial bug" in the -05 TCR draft the fact that you mention SIG RRs might be present in a zone (covered by a RRSIG)? Why would a SIG(0) RR have a RRSIG? ;-) ----- Original Message ----- From: "Samuel Weiler" To: "namedroppers" Sent: Wednesday, November 12, 2003 9:37 PM Subject: Re: New IANA considerations for Typecode-rollover-05 > Here's a possible TCR IANA section that makes the existing registry > generic and adds two applicability lists. Again, I'd rather keep the > TCR-05 solution, but I prefer the below to having a no-op registry > that other registries may copy, copy with changes, or even ignore. > > Comments? Is the TCR-05 solution adequate? Do we need this? > > This document updates the IANA registry for DNS Resource Record > Types by assigning types 46, 47, and 48 to the RRSIG, NSEC, and > DNSKEY RRs, respectively. > > Types 24 and 25 (SIG and KEY) are retained for SIG(0) [RFC2931] and > TKEY [RFC2930] use only. Type 30 (NXT) should be marked as > Obsolete. > > In order to allow zone signing (DNSSEC) and transaction security > mechanisms (SIG(0) and TKEY) to use different sets of algorithms > and key formats, the existing "DNS Security Algorithm Numbers" > registry will become a generic registry that isn't specific to any > RR type. > > Two new registries are created, "DNS Transaction Security Algorithm > Applicability" and "DNS Zone Signing Algorithm Applicability". > (Alternate names: "KEY and SIG Algorithm Applicability" and > "DNSKEY, DS, and RRSIG Algorithm Applicability") Each requires IETF > Standards Action to change. > > "DNS Transaction Security Algorithm Applicability" lists those > algorithms from the "DNS Security Algorithm Numbers" registry that > are usable by the DNS transaction security mechanims (SIG(0) and > TKEY) and, in particular, usable in KEY and SIG records. It > initially includes algorithm numbers 1, 2, 3, 5, 252, 253, and 254. > > "DNS Zone Signing Algorithm Applicability" lists those algorithms > from the "DNS Security Algorithm Numbers" registry that are usable > for zone signing, and, in particular, the DNSKEY, DS, and RRSIG > records. It initially includes algorithm numbers 2, 3, 5, 253, and > 254. > > Additionally, presentation format mnemonics as defined in RFC2535 > Section 7 are added to the "DNS Security Algorithm Numbers" > registry. This document assigns RSA/SHA-1 (type 5) the mnemonic > RSASHA1. As in RFC2535, IETF Standards Action is required to change > this registry. At this time, values 4 and 6-251 are available for > assignment, with 4 reserved for eliptic curve keys. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Nov 12 22:39:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25163 for ; Wed, 12 Nov 2003 22:39:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AK8Hs-00025b-8D for namedroppers-data@psg.com; Thu, 13 Nov 2003 03:36:52 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AK8Hq-00025N-6J for namedroppers@ops.ietf.org; Thu, 13 Nov 2003 03:36:50 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 17B005684B; Wed, 12 Nov 2003 19:36:49 -0800 (PST) Message-Id: <6.0.0.22.2.20031112223535.038ddaf0@localhost> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 12 Nov 2003 22:36:53 -0500 To: Samuel Weiler , namedroppers@ops.ietf.org From: Mike StJohns Subject: Re: I-D ACTION:draft-ietf-dnsext-dnssec-2535typecode-change-05.txt In-Reply-To: References: <200310131955.PAA23807@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hi Sam - I actually didn't read this because it should be (e.g. I assumed it was) subsumed by the -protocol document. Was the obvious bug carried over to -protocol? Later, mike At 09:58 PM 11/12/2003, Samuel Weiler wrote: > > Title : Legacy Resolver Compatibility for Delegation Signer > > Author(s) : S. Weiler > > Filename : draft-ietf-dnsext-dnssec-2535typecode-change-05.txt > > Pages : 5 > > Date : 2003-10-13 >... > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-2535typecode-change-05.txt > >There is a trivial but obvious bug in this document. The thing that >disturbs me is that it took almost a month for anyone (besides the >editor) to find it, or at least to point it out. > >Thanks to Rob Payne for actually reading the document. For being the >first to mention the bug to me, Rob wins a pint of his choice at >Brit's Pub or some other fine Minneapolis watering hole. > >(Read the docs. You might be surprised at what is (not) in them. >And if you embarrass the doc editor(s) enough, you might even get free >beer.) > >-- 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: -- to unsubscribe send a message to namedroppers-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 Nov 12 22:51:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25645 for ; Wed, 12 Nov 2003 22:51:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AK8T3-0003oh-Jz for namedroppers-data@psg.com; Thu, 13 Nov 2003 03:48:25 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AK8T1-0003oP-Nq for namedroppers@ops.ietf.org; Thu, 13 Nov 2003 03:48:23 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id hAD3kGcl001576 for ; Wed, 12 Nov 2003 22:46:16 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAT4aaed; Wed, 12 Nov 03 22:46:14 -0500 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id hAD3kv65001415; Wed, 12 Nov 2003 22:46:57 -0500 (EST) Date: Wed, 12 Nov 2003 22:46:57 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: Mike StJohns cc: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-dnssec-2535typecode-change-05.txt In-Reply-To: <6.0.0.22.2.20031112223535.038ddaf0@localhost> Message-ID: References: <200310131955.PAA23807@ietf.org> <6.0.0.22.2.20031112223535.038ddaf0@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I actually didn't read this because it should be (e.g. I assumed it was) > subsumed by the -protocol document. Was the obvious bug carried over to > -protocol? No, it was not. It still may be worthwhile to read the document since, among other things, it makes IANA changes. While the bis doc set will include the relevant protocol details, it will presumably not repeat the IANA actions, and the IANA actions are the most signifigant changes between -04 and -05. This draft also discusses some of the motivation and history for the type code roll. FWIW, the bug in question presumably would have been fixed by the RFC Editor before publication. (Or in -06, since the IANA section still seems to be of concern to some.) -- 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 Nov 13 08:58:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26762 for ; Thu, 13 Nov 2003 08:58:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKHse-0007ww-E2 for namedroppers-data@psg.com; Thu, 13 Nov 2003 13:51:28 +0000 Received: from [127.0.0.1] (helo=roam.psg.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKHsX-0007vX-LY for namedroppers@ops.ietf.org; Thu, 13 Nov 2003 13:51:21 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKHQw-0001qN-Ko for namedroppers@ops.ietf.org; Thu, 13 Nov 2003 07:22:50 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: From: Matus UHLAR - fantomas Subject: What are valid reasons to have wildcards in DNS? Newsgroups: comp.protocols.dns.std Date: Thu, 06 Nov 2003 15:56:51 -0000 To: undisclosed-recipients:; X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Hello, for last two months there were many discussions and clarifications about wildcards in DNS. There is a question that seems to me still unanswered: what are legal and valid reasons to have wildcards in domains? >From my point of view, wildcards are used: 1. by admins lazy to set up higher number of hostnames od MX records 2. for lame people not able to use some reasonable defaults (e.g. *.museum versus www.museum) when we take into consideration all problems happening caused by using wildcard domain names - all of them were named in when verisgn introduced wildcards in .com and .net zones: http://lists.megacity.org/pipermail/rfci-discuss/2003-September/001759.html http://www.icann.org/announcements/advisory-03oct03.htm And when we look at the discussions in this group, wouldn't it be much better to disable wildcards in DNS at all? -- Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/ Warning: I don't wish to receive e-mail advertising to this address. Varovanie: Nezelam si na tuto adresu dostavat akukolvek reklamnu postu. Honk if you love peace and quiet. -- to unsubscribe send a message to namedroppers-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 Nov 13 10:09:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00981 for ; Thu, 13 Nov 2003 10:09:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKJ1V-000HIQ-Ot for namedroppers-data@psg.com; Thu, 13 Nov 2003 15:04:41 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKJ1J-000HGf-8C for namedroppers@ops.ietf.org; Thu, 13 Nov 2003 15:04:29 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 9150B13972 for ; Thu, 13 Nov 2003 15:04:28 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: What are valid reasons to have wildcards in DNS? In-Reply-To: Message from Matus UHLAR - fantomas of "Thu, 06 Nov 2003 15:56:51 GMT." X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 13 Nov 2003 15:04:28 +0000 Message-Id: <20031113150428.9150B13972@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ... > And when we look at the discussions in this group, wouldn't it be much > better to disable wildcards in DNS at all? no. the protocol community has no concrete or complete idea of why a zone adminstrator might use wildcards. all we know is that they are in wide use for many purposes, and that they are often used incorrectly or unnecessarily. but more importantly, current dns does wildcard synthesis in the authority server, not in the resolvers. this means two things. first, there's no workload being placed on or shifted toward resolvers by the use of wildcards. second, a zone administrator could synthesize data for their own purposes, with or without wildcard rules, as long as she controlled all of her authority servers (and therefore did not depend on axfr to carry the synthesis marker, as wildcards do.) therefore there's not only nothing we SHOULD do to restrict the use of wildcards, there's also nothing we COULD do to restrict such use. the recent discussions about the *.COM and *.NET wildcards ended by pointing up the fact that the "zone administrator" function is not singularly held by any one entity, and that the putative zone administrator apparently lacks the full autonomy needed to synthesize responses to nonexisting names in the way a non-gTLD zone administrator would normally be able to do. i hope you will agree that this is a problem for the lawyers, not for the protocol community, to resolve. -- to unsubscribe send a message to namedroppers-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 Nov 13 10:28:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02815 for ; Thu, 13 Nov 2003 10:28:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKJL7-000KIL-3T for namedroppers-data@psg.com; Thu, 13 Nov 2003 15:24:57 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AKJL2-000KEQ-Eb for namedroppers@ops.ietf.org; Thu, 13 Nov 2003 15:24:52 +0000 Received: (qmail 69660 invoked from network); 13 Nov 2003 15:32:23 -0000 Received: from dyn051-172.ietf58.ietf.org (HELO necom830.hpcl.titech.ac.jp) (130.129.51.172) by necom830.hpcl.titech.ac.jp with SMTP; 13 Nov 2003 15:32:23 -0000 Message-ID: <3FB3A29E.5010001@necom830.hpcl.titech.ac.jp> Date: Fri, 14 Nov 2003 00:26:22 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: What are valid reasons to have wildcards in DNS? References: <20031113150428.9150B13972@sa.vix.com> In-Reply-To: <20031113150428.9150B13972@sa.vix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie; >>And when we look at the discussions in this group, wouldn't it be much >>better to disable wildcards in DNS at all? > no. the protocol community has no concrete or complete idea of why a > zone adminstrator might use wildcards. all we know is that they are > in wide use for many purposes, and that they are often used incorrectly > or unnecessarily. Both of you should read 4.3.3 of 1034, though you are free to argue against it. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Nov 13 10:44:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03809 for ; Thu, 13 Nov 2003 10:44:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKJbB-000N96-VL for namedroppers-data@psg.com; Thu, 13 Nov 2003 15:41:33 +0000 Received: from [130.129.128.66] (helo=ernie.secret-wg.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKJb9-000N8X-4c for namedroppers@ops.ietf.org; Thu, 13 Nov 2003 15:41:31 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by ernie.secret-wg.org (Postfix) with ESMTP id E685317CF16; Thu, 13 Nov 2003 09:41:33 -0600 (CST) In-Reply-To: <3FB3A29E.5010001@necom830.hpcl.titech.ac.jp> References: <20031113150428.9150B13972@sa.vix.com> <3FB3A29E.5010001@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, Paul Vixie From: "Olaf M.Kolkman" Subject: Re: What are valid reasons to have wildcards in DNS? Date: Thu, 13 Nov 2003 09:41:32 -0600 To: Masataka Ohta X-Mailer: Apple Mail (2.606) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Nov 13, 2003, at 9:26 AM, Masataka Ohta wrote: >>> And when we look at the discussions in this group, wouldn't it be >>> much >>> better to disable wildcards in DNS at all? > >> no. the protocol community has no concrete or complete idea of why a >> zone adminstrator might use wildcards. all we know is that they are >> in wide use for many purposes, and that they are often used >> incorrectly >> or unnecessarily. > > Both of you should read 4.3.3 of 1034, though you are free to > argue against it. Ohta San, Could you expand; it not quite clear, to me at least, what you are trying to argue with providing the reference. --Olaf Kolkman namedropper. -- to unsubscribe send a message to namedroppers-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 Nov 13 11:14:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05338 for ; Thu, 13 Nov 2003 11:14:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKK1D-0001x1-6p for namedroppers-data@psg.com; Thu, 13 Nov 2003 16:08:27 +0000 Received: from [62.6.242.6] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKK1A-0001wa-BA for namedroppers@ops.ietf.org; Thu, 13 Nov 2003 16:08:24 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [62.6.242.9]) by gromit.rfc1035.com (8.10.1/8.9.0) with ESMTP id hADG7vh22634; Thu, 13 Nov 2003 16:07:58 GMT To: Paul Vixie cc: namedroppers@ops.ietf.org Subject: Re: What are valid reasons to have wildcards in DNS? In-reply-to: Your message of "Thu, 13 Nov 2003 15:04:28 GMT." <20031113150428.9150B13972@sa.vix.com> Date: Thu, 13 Nov 2003 16:07:56 +0000 Message-ID: <22632.1068739676@gromit.rfc1035.com> From: Jim Reid X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Paul" == Paul Vixie writes: Paul> therefore there's not only nothing we SHOULD do to restrict Paul> the use of wildcards, there's also nothing we COULD do to Paul> restrict such use. Not even a BCP which says "Wildcard RRs are considered harmful. Don't use them unless you really know what you're doing. Which you obviously don't if you have to read this BCP..."? I agree 100% there's nothing we could or should do to restrict usage of wildcards. However we could discourage their use and so do a little to help make the internet a better place. -- to unsubscribe send a message to namedroppers-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 Nov 13 11:50:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07214 for ; Thu, 13 Nov 2003 11:50:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKKWT-0006uH-JE for namedroppers-data@psg.com; Thu, 13 Nov 2003 16:40:45 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AKKWR-0006tr-17 for namedroppers@ops.ietf.org; Thu, 13 Nov 2003 16:40:43 +0000 Received: (qmail 69963 invoked from network); 13 Nov 2003 16:48:26 -0000 Received: from dyn135-178.ietf58.ietf.org (HELO necom830.hpcl.titech.ac.jp) (130.129.135.178) by necom830.hpcl.titech.ac.jp with SMTP; 13 Nov 2003 16:48:26 -0000 Message-ID: <3FB3B46D.2090405@necom830.hpcl.titech.ac.jp> Date: Fri, 14 Nov 2003 01:42:21 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: "Olaf M.Kolkman" CC: namedroppers@ops.ietf.org, Paul Vixie Subject: Re: What are valid reasons to have wildcards in DNS? References: <20031113150428.9150B13972@sa.vix.com> <3FB3A29E.5010001@necom830.hpcl.titech.ac.jp> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Olaf M.Kolkman wrote: >>>> And when we look at the discussions in this group, wouldn't it be much >>>> better to disable wildcards in DNS at all? >> >> >>> no. the protocol community has no concrete or complete idea of why a >>> zone adminstrator might use wildcards. all we know is that they are >>> in wide use for many purposes, and that they are often used incorrectly >>> or unnecessarily. >> >> >> Both of you should read 4.3.3 of 1034, though you are free to >> argue against it. > > > Ohta San, > > Could you expand; it not quite clear, to me at least, what you are > trying to argue with providing the reference. There is a description why a zone administrator might use wildcards. And, my understanding is that wildcard is useful if there are many or huge number of names sharing same properties and a zone administrator do not want or can't modify zone everytime a new name appears. I also think it is unlikely that the reasons are applicable to A RR that there will be a confusion if people, ignoring the example in 1034, think DNS is a system to retrieve addresses. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Nov 13 12:12:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08566 for ; Thu, 13 Nov 2003 12:12:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKKwa-000BHz-Vy for namedroppers-data@psg.com; Thu, 13 Nov 2003 17:07:44 +0000 Received: from [216.220.241.233] (helo=nic-naa.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKKwY-000BHg-BT for namedroppers@ops.ietf.org; Thu, 13 Nov 2003 17:07:42 +0000 Received: from nic-naa.net (localhost.wampumpeag.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id hADHCKCA088898 for ; Thu, 13 Nov 2003 12:12:20 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200311131712.hADHCKCA088898@nic-naa.net> To: namedroppers@ops.ietf.org Subject: Re: What are valid reasons to have wildcards in DNS? In-Reply-To: Your message of "Thu, 13 Nov 2003 15:04:28 GMT." <20031113150428.9150B13972@sa.vix.com> Date: Thu, 13 Nov 2003 12:12:20 -0500 From: Eric Brunner-Williams in Portland Maine X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul Vixie wrote: > no. the protocol community has no concrete or complete idea of why a > zone adminstrator might use wildcards. all we know is that they are > in wide use for many purposes, and that they are often used incorrectly > or unnecessarily. Masataka Ohta commented: > Both of you should read 4.3.3 of 1034, though you are free to > argue against it. I'm looking at a .museum, which apparently uses wildcards for a purpose not apparently described in section 4.3.3 of 1034. Eric -- to unsubscribe send a message to namedroppers-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 Nov 13 12:52:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10731 for ; Thu, 13 Nov 2003 12:52:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKLWa-000Glx-4C for namedroppers-data@psg.com; Thu, 13 Nov 2003 17:44:56 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKLWX-000GlL-UU for namedroppers@ops.ietf.org; Thu, 13 Nov 2003 17:44:53 +0000 Received: by sa.vix.com (Postfix, from userid 716) id C151513972; Thu, 13 Nov 2003 17:44:53 +0000 (GMT) To: namedroppers@ops.ietf.org Subject: Re: What are valid reasons to have wildcards in DNS? References: <20031113150428.9150B13972@sa.vix.com> From: Paul Vixie Date: 13 Nov 2003 17:44:53 +0000 In-Reply-To: Message-ID: Lines: 14 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Masataka Ohta writes: > Both of you should read 4.3.3 of 1034, though you are free to > argue against it. i have reread it. please point out the part that i seem not to agree with. the only part that stands out as relevant to the original questioner is... >> This facility is most often used to create a zone which will be used to >> forward mail from the Internet to some other mail system. ...and while i agree with this, i also note that "most often" is nonexclusive. -- Paul Vixie -- to unsubscribe send a message to namedroppers-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 Nov 13 12:59:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10916 for ; Thu, 13 Nov 2003 12:59:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKLhC-000IRr-Al for namedroppers-data@psg.com; Thu, 13 Nov 2003 17:55:54 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKLhA-000IRa-Ch for namedroppers@ops.ietf.org; Thu, 13 Nov 2003 17:55:52 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 31D1513973 for ; Thu, 13 Nov 2003 17:55:52 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: What are valid reasons to have wildcards in DNS? In-Reply-To: Message from Jim Reid of "Thu, 13 Nov 2003 16:07:56 GMT." <22632.1068739676@gromit.rfc1035.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 13 Nov 2003 17:55:52 +0000 Message-Id: <20031113175552.31D1513973@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Not even a BCP which says "Wildcard RRs are considered harmful. Don't > use them unless you really know what you're doing. Which you obviously > don't if you have to read this BCP..."? not even that, nope. > I agree 100% there's nothing we could or should do to restrict usage > of wildcards. However we could discourage their use and so do a little > to help make the internet a better place. sounds like a dnsop issue. -- to unsubscribe send a message to namedroppers-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 Nov 13 14:04:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13017 for ; Thu, 13 Nov 2003 14:04:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKMgG-0000CN-LJ for namedroppers-data@psg.com; Thu, 13 Nov 2003 18:59:00 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKMgE-0000C8-K5 for namedroppers@ops.ietf.org; Thu, 13 Nov 2003 18:58:58 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id hADIuoOD001356 for ; Thu, 13 Nov 2003 13:56:50 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA1NayPc; Thu, 13 Nov 03 13:56:50 -0500 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id hADIvWHM009772; Thu, 13 Nov 2003 13:57:32 -0500 (EST) Date: Thu, 13 Nov 2003 13:57:32 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: Masataka Ohta cc: namedroppers@ops.ietf.org Subject: Re: What are valid reasons to have wildcards in DNS? In-Reply-To: <3FB3B46D.2090405@necom830.hpcl.titech.ac.jp> Message-ID: References: <20031113150428.9150B13972@sa.vix.com> <3FB3A29E.5010001@necom830.hpcl.titech.ac.jp> <3FB3B46D.2090405@necom830.hpcl.titech.ac.jp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 14 Nov 2003, Masataka Ohta wrote: > And, my understanding is that wildcard is useful if there are many > or huge number of names sharing same properties and a zone administrator > do not want or can't modify zone everytime a new name appears. Synthesis would be useful in such cases, but not the standardized wildcard. I suggest reading draft-ietf-dnsext-wcard-clarify-02.txt, particularly the first paragraph on page three. -- 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 Nov 13 14:20:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13913 for ; Thu, 13 Nov 2003 14:20:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKMv4-0001qi-TQ for namedroppers-data@psg.com; Thu, 13 Nov 2003 19:14:18 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AKMuz-0001pl-Pt for namedroppers@ops.ietf.org; Thu, 13 Nov 2003 19:14:14 +0000 Received: (qmail 70710 invoked from network); 13 Nov 2003 19:21:58 -0000 Received: from dyn129-43.ietf58.ietf.org (HELO necom830.hpcl.titech.ac.jp) (130.129.129.43) by necom830.hpcl.titech.ac.jp with SMTP; 13 Nov 2003 19:21:58 -0000 Message-ID: <3FB3D869.6060208@necom830.hpcl.titech.ac.jp> Date: Fri, 14 Nov 2003 04:15:53 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Samuel Weiler CC: namedroppers@ops.ietf.org Subject: Re: What are valid reasons to have wildcards in DNS? References: <20031113150428.9150B13972@sa.vix.com> <3FB3A29E.5010001@necom830.hpcl.titech.ac.jp> <3FB3B46D.2090405@necom830.hpcl.titech.ac.jp> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Samuel Weiler; >>And, my understanding is that wildcard is useful if there are many >>or huge number of names sharing same properties and a zone administrator >>do not want or can't modify zone everytime a new name appears. > Synthesis would be useful in such cases, but not the standardized > wildcard. Wild card is the standard way of "synthesis", which means it works over standardized zone transfer. > I suggest reading draft-ietf-dnsext-wcard-clarify-02.txt, particularly > the first paragraph on page three. I checked it again but found no useful information in the paragraph. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Nov 13 15:33:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18970 for ; Thu, 13 Nov 2003 15:33:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKO6H-000B5K-3F for namedroppers-data@psg.com; Thu, 13 Nov 2003 20:29:57 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKO6D-000B56-8W for namedroppers@ops.ietf.org; Thu, 13 Nov 2003 20:29:53 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id hADKRjHa008034 for ; Thu, 13 Nov 2003 15:27:45 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA3taiSp; Thu, 13 Nov 03 15:27:44 -0500 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id hADKSTho014480; Thu, 13 Nov 2003 15:28:29 -0500 (EST) Date: Thu, 13 Nov 2003 15:28:29 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: Masataka Ohta cc: namedroppers@ops.ietf.org Subject: Re: What are valid reasons to have wildcards in DNS? In-Reply-To: <3FB3D869.6060208@necom830.hpcl.titech.ac.jp> Message-ID: References: <20031113150428.9150B13972@sa.vix.com> <3FB3A29E.5010001@necom830.hpcl.titech.ac.jp> <3FB3B46D.2090405@necom830.hpcl.titech.ac.jp> <3FB3D869.6060208@necom830.hpcl.titech.ac.jp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > I suggest reading draft-ietf-dnsext-wcard-clarify-02.txt, particularly > > the first paragraph on page three. > > I checked it again but found no useful information in the paragraph. Then perhaps I should be more plain, or you should read the paragraph yet again. I'll quote it here to make it easy to find: Note that a wild card domain name has no special impact on the search for a query type (QTYPE). If a domain name is found that matches the QNAME (exact or a wild card) but the QTYPE is not found at that point, the proper response is that there is no data available. The search does not continue on to seek other wild cards that might match the QTYPE. To illustrate, a wild card owning an MX RR does not 'cover' other names in the zone that own an A RR. ... > >>And, my understanding is that wildcard is useful if there are many > >>or huge number of names sharing same properties and a zone administrator > >>do not want or can't modify zone everytime a new name appears. I think your understanding is incorrect. The cited paragraph says that if a name exists, the standard wildcard has no effect on it. So the standard wildcard won't be useful unless the "huge number of names" you refer to is either every possible name in the zone or every possible name except for explicitly instantiated ones. -- 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 Nov 13 15:53:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19947 for ; Thu, 13 Nov 2003 15:53:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKOQO-000Din-IK for namedroppers-data@psg.com; Thu, 13 Nov 2003 20:50:44 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AKOQK-000DiJ-15 for namedroppers@ops.ietf.org; Thu, 13 Nov 2003 20:50:40 +0000 Received: (qmail 71088 invoked from network); 13 Nov 2003 20:58:24 -0000 Received: from dyn129-43.ietf58.ietf.org (HELO necom830.hpcl.titech.ac.jp) (130.129.129.43) by necom830.hpcl.titech.ac.jp with SMTP; 13 Nov 2003 20:58:24 -0000 Message-ID: <3FB3EF00.7090606@necom830.hpcl.titech.ac.jp> Date: Fri, 14 Nov 2003 05:52:16 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Samuel Weiler CC: namedroppers@ops.ietf.org Subject: Re: What are valid reasons to have wildcards in DNS? References: <20031113150428.9150B13972@sa.vix.com> <3FB3A29E.5010001@necom830.hpcl.titech.ac.jp> <3FB3B46D.2090405@necom830.hpcl.titech.ac.jp> <3FB3D869.6060208@necom830.hpcl.titech.ac.jp> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Samuel Weiler; >>>>And, my understanding is that wildcard is useful if there are many >>>>or huge number of names sharing same properties and a zone administrator >>>>do not want or can't modify zone everytime a new name appears. > I think your understanding is incorrect. Why? > The cited paragraph says > that if a name exists, the standard wildcard has no effect on it. Correct, so far. > So > the standard wildcard won't be useful unless the "huge number of > names" you refer to is either every possible name in the zone or every > possible name except for explicitly instantiated ones. I never said "if and only if". Paul wrote "no concrete or complete idea", and I gave a reference to an idea. Then, I'm still puzzled because I think "if a name exists, the standard wildcard has no effect on it" has no relevance to my point. Just FYI, wildcard may appear anywhere in a zone not necessarily at the top. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Nov 13 17:13:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23831 for ; Thu, 13 Nov 2003 17:13:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKPck-000MU7-98 for namedroppers-data@psg.com; Thu, 13 Nov 2003 22:07:34 +0000 Received: from [192.94.41.1] (helo=koro.off.connect.com.au) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKPcf-000MTk-Ok for namedroppers@ops.ietf.org; Thu, 13 Nov 2003 22:07:29 +0000 Received: from pcm170.cca.off.connect.com.au (fastethernet0.fw.mel.off.connect.com.au [210.8.4.34]) by koro.off.connect.com.au (Postfix) with SMTP id D4DD44F52D for ; Fri, 14 Nov 2003 09:07:28 +1100 (EST) From: Nathan Jones To: namedroppers@ops.ietf.org Subject: Re: What are valid reasons to have wildcards in DNS? Date: Fri, 14 Nov 2003 09:07:28 +1100 Message-ID: References: In-Reply-To: X-Mailer: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-1.4 required=5.0 tests=BAYES_20 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >what are legal and valid reasons to have wildcards in domains? Here is one example that springs to mind... A company (Foo) provides web sites to real estate businesses. Each business hosts its domain somewhere different and needs traffic to reach the Foo web server. Foo tells its 400 customers to use CNAMEs, like this: www.ocean-realty.example. IN CNAME server.foo.example. ...so that if Foo's network must be renumbered, they don't have to make 400 real estate agents update DNS. Of course, sometimes the customer wants "ocean-realty.example" to work in a browser, so they break their DNS with: @ IN CNAME server.foo.example. >wouldn't it be much better to disable wildcards in DNS at all? No. Only to educate DNS Admins about the possible problems. -- Nathan Jones -- to unsubscribe send a message to namedroppers-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 Nov 13 19:57:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02274 for ; Thu, 13 Nov 2003 19:57:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKS4z-000FUB-Vm for namedroppers-data@psg.com; Fri, 14 Nov 2003 00:44:53 +0000 Received: from [129.9.82.74] (helo=fxodpr13.extra.daimlerchrysler.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKS4u-000FTo-Ms for namedroppers@ops.ietf.org; Fri, 14 Nov 2003 00:44:48 +0000 Received: (from uucp@localhost) by fxodpr13.extra.daimlerchrysler.com (8.12.8/8.9.0) id hAE0ildH029456 for ; Thu, 13 Nov 2003 19:44:47 -0500 (EST) Received: from unknown(53.231.71.24) by fxodpr13.extra.daimlerchrysler.com via csmap (V6.0) id srcAAAYQa4H5; Thu, 13 Nov 03 19:44:47 -0500 Received: from odconpr2-hme0.oddc.chrysler.com ([127.0.0.1]) by odconpr2-hme0.oddc.chrysler.com (Mail-Gear 2.0.0 bld 66) with SMTP id M2003111319444626959 for ; Thu, 13 Nov 2003 19:44:46 -0500 Received: from odmrspr2-hme0.oddc.chrysler.com ([53.231.2.113]) by odconpr2-hme0.oddc.chrysler.com (SAVSMTP 3.1.1.32) with SMTP id M2003111319444607450 for ; Thu, 13 Nov 2003 19:44:46 -0500 Received: from wokcdts1.is.chrysler.com (wokcdts1.is.chrysler.com [53.230.102.164]) by odmrspr2-hme0.oddc.chrysler.com (8.12.10/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id hAE0ilnf001882 for ; Thu, 13 Nov 2003 19:44:47 -0500 (EST) Received: from daimlerchrysler.com (wokcdts1.is.chrysler.com [53.230.102.164]) by wokcdts1.is.chrysler.com (8.12.10/8.9.1) with ESMTP id hAE0iEhL002769 for ; Thu, 13 Nov 2003 19:44:14 -0500 (EST) Message-ID: <3FB4255D.1020109@daimlerchrysler.com> Date: Thu, 13 Nov 2003 19:44:13 -0500 From: Kevin Darcy User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: What are valid reasons to have wildcards in DNS? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Matus UHLAR - fantomas wrote: >[ post by non-subscriber. with the massive amount of spam, it is easy to miss > and therefore delete posts by non-subscribers. if you wish to regularly > post from an address that is not subscribed to this mailing list, send a > message to -owner@ops.ietf.org and ask to have the alternate > address added to the list of addresses from which submissions are > automatically accepted. ] > >Hello, > >for last two months there were many discussions and clarifications about >wildcards in DNS. There is a question that seems to me still unanswered: > >what are legal and valid reasons to have wildcards in domains? > >>From my point of view, wildcards are used: >1. by admins lazy to set up higher number of hostnames od MX records > Lazy? What if you have an internal-root architecture, sitting behind proxy-style firewalls for *all* protocols (including SMTP) and you want to control your outgoing mail routes centrally via MX records (controlling mail routing is, after all, what MX records are for)? Short of adding a duplicate entry for *every*possible*Internet*mail*destination* to your internal DNS, you're pretty much committed to using wildcard MXes. It's a little presumptuous IMO to call that "lazy". Oh sure, I know that plenty of folks with such network architectures plug *static* mail routes into every one of their internal mail server's configurations. But, think about it, isn't that conceptually like inserting a huge *root* wildcard MX record into every one of those boxes' brains? Given a choice, I'd prefer to use real-life wildcard MXes in DNS centrally, than have to be responsible for maintaining static routing configs -- pseudo-wildcard-MXes, if you will -- on hundreds of servers. But then, that's just me. >when we take into consideration all problems happening caused by using >wildcard domain names - all of them were named in when verisgn introduced >wildcards in .com and .net zones: > So, yet again we have a proposal to address an administrative/organizational/political/social problem with a technological quick-fix, i.e. disallow wildcards altogether. Wildcards are a tool; like most tools, they can be misused or abused. Don't blame the tool: blame the people who misuse or abuse it. Those of us who use the tool wisely and carefully and productively don't appreciate your attempts to take away our functionality. - Kevin -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From mglnews@altavista.net Fri Nov 14 01:05:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14190 for ; Fri, 14 Nov 2003 01:05:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKX5l-0006l2-00 for dnsext-archive@ietf.org; Fri, 14 Nov 2003 01:06:01 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AKX5l-0006kU-00 for dnsext-archive@ietf.org; Fri, 14 Nov 2003 01:06:01 -0500 Received: from [219.145.220.144] (helo=ietf.org) by manatick with smtp (Exim 4.24) id 1AKX0j-0001Tl-Kf for dnsext-archive@ietf.org; Fri, 14 Nov 2003 01:00:53 -0500 Reply-To: "ConstruNews" From: "Temas "Patrulhados"" To: dnsext-archive@ietf.org Subject: Lindenberg: opiniőes "politicamente incorretas" vęm sendo marginalizadas ref.: gnx X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 MIME-Version: 1.0 Content-Type: text/html Message-Id: Date: Fri, 14 Nov 2003 01:00:53 -0500

inf EnEspañol - InEnglish

Temas "patrulhados"

Opiniões "politicamente incorretas" vêm sendo marginalizadas no debate nacional, diz Lindenberg

* Patrulhamento...

Em meios empresariais e religiosos continua repercutindo o livro "Os católicos e a economia de mercado", de autoria de Adolpho Lindenberg. O trabalho denuncia uma política com viés esquerdista que visa censurar, marginalizar ou encobrir com um manto de silêncio, notícias, comentários, livros, reportagens e opiniões "politicamente incorretas", não afinadas com as assim denominadas "causas sociais". Noutras palavras, os meios de comunicação, e a própria sociedade brasileira, estão sendo "patrulhados".

* Antídoto

O antídoto para esta situação de violência psicológica e espiritual consiste na difusão - por meios alternativos, se preciso for - de informações idôneas, capazes de esclarecer a opinião pública e provocar debates construtivos. Com efeito, uma vez rompidos os anteparos da censura, cada um em seu próprio ambiente poderá, sem medo, manifestar sua opinião sobre os assuntos 'patrulhados'. É a proposta inovadora de um programa de libertação ideológica, impulsionado pela coragem, em defesa do esclarecimento popular.

* Esclarecimento!

Esse programa tem alcance prático, especialmente para os católicos. O destaque que, há muitos anos, a mídia vem dando aos pronunciamentos de bispos e sacerdotes (em geral ligados à CNBB), que favorecem as invasões de terras promovidas pelos MST, bem como às repetidas críticas à Área de Livre Comércio das Américas (ALCA), às privatizações, à alegada ameaça das multinacionais e do capital estrangeiro, e até mesmo ao plantio de transgênicos, apresenta dois inconvenientes sérios. Em primeiro lugar, tais pronunciamentos podem criar a impressão de que a maioria do Episcopado e dos setores mais responsáveis do Clero brasileiro pensa como esses prelados. Em segundo, de que as teses da Teologia da Libertação têm fundamentos sólidos na doutrina católica. Tudo isso tem muita importância prática. Com efeito, na vasta rede de movimentos contestatários, ativa no país inteiro, a ala progressista religiosa se sobressai hoje como o setor mais ativo e mais radical nas proposições.

* Temáticas

Diante deste cenário e visando alertar a opinião pública católica, o livro acima citado procura debater as seguintes temáticas:

- Capitalismo, globalização, neoliberalismo e privatizações seriam os grandes responsáveis pelos bolsões de misérias, desigualdades sociais e dependência externa (isto é, dos Estados Unidos)?

- Os programas sociais estatais seriam a solução para combater a fome, o analfabetismo, o atraso e a indigência das classes mais pobres do Brasil?

- O materialismo, o anonimato, a exclusão social, o relacionamento burocrático entre as pessoas são causados muito especialmente pelo crescimento desordenado das cidades ou sobretudo pela descristianização de nossos hábitos?

* Informe-se!

Informe-se desses assuntos - e ainda de vários outros - no livro "Os católicos e a economia de mercado". Você pode adquiri-lo, clicando nos links abaixo. E complemente seus dados com artigos de Adolpho Lindenberg que lhe serão enviados gratuitamente (clique nos links abaixo). O autor analisa tais assuntos com base na doutrina social católica, expressa nas encíclicas: discorre sobre as relações entre a economia e a moral, liberdade e responsabilidade dos atos econômicos, direito de propriedade, respeito às leis naturais no mercado, liceidade do lucro, assistência social, relações humanas na empresa e na vida civil.

* Destaque

E, por fim, um ponto com merecido destaque em "Os católicos e a economia de mercado": como as reivindicações "sociais" têm como fim o socorro aos necessitados e a diminuição de desigualdades sociais, é indispensável ter em vista que esse objetivo só poderia ser alcançado com a elevação significativa do padrão de vida do povo (para o autor, por uma dose maior de capitalismo autêntico) e sobretudo pela recristianização da sociedade. A assistência aos necessitados deve, além do mais, sempre que possível, ter um tom pessoal, familiar, típico das sociedades orgânicas harmonicamente diferenciadas, das quais ainda se encontram reflexos vivos em antigas cidades do interior brasileiro. Ali ainda hoje subsistem hospitais, creches, asilos, de iniciativa religiosa e particular, que atendem aos necessitados de modo mais humano e eficaz que a assistência estatal prestada nas grandes metrópoles.

LINKS DE OPINIÃO:

Entre aqueles que enviarem sua valiosa opinião a respeito do texto acima, até 30 de novembro, usando qualquer um dos três links seguintes, serão sorteados 10 exemplares do livro "Os católicos e a economia de mercado". Os favorecidos serão comunicados por e-mail e deverão enviar o endereço postal para receberem os exemplares do livro, por Correio).

Lindenberg:Concordo (pode simplesmente enviar seu voto virtual, e acrescentar seu comentário caso desejar)

Lindenberg:Discordo (idem)

Lindenberg:MinhaOpinião (para enviar sua valiosa opinião, assim como sugerir a Lindenberg temas relacionados com a temática apresentada, a serem abordados em seus próximos artigos)

LINKS PARA ADQUIRIR O LIVRO

Lindenberg:DesejoAdquirirLivroEditora (receberá por e-mail o link para adquirir o livro impresso, diretamente da Editora, com cartão de crédito ou boleto bancário; preço: R$ 30,00 mais SEDEX)

Lindenberg:DesejoAdquirirE-Book (para adquirir o livro, em formato Word, que será enviado por e-mail; receberá número de conta bancária para efetuar transferência; preço promocional do e-book, até 30 de novembro: R$ 8,80)

LINKS PARA RECEBER ARTIGOS GRATUITOS:

PaginasGratuitas (para receber gratuitamente, por e-mail, Índice e Introdução à edição brasileira do livro de Lindenberg)

GratuitamenteArtigosAnteriores

GratuitamenteProximosArtigos

GratuitamenteTodosOsArtigos

Para solicitar alguns títulos específicos:

Artigo1 "Acabemos com mais uma exclusão: o Brasil precisa ouvir a voz do Clero sem-microfone"

Artigo2 "Moral e Economia"

Artigo3 "Assistência Social e Capitalismo não precisam estar em guerra: podem dar o abraço da paz"

Artigo4 "Intervencionismo estatal e fermentação revolucionária versus assistência particular e personalizada"

Próximos temas:

"Capitalismo, globalização, neoliberalismo, privatizações"

"Economia de Mercado, Neoliberalismo"

"Estatização da Economia"

LINK DE REMOÇÃO

ConstruNews:Remover dnsext-archive@ietf.org

LINK PARA TOMAR CONTATO COM LINDENBERG

Lindenberg:TomarContato (também pode ligar diretamente, se desejar, ao 11- 92527873, em São Paulo)

A difusão e o conteúdo desta mensagem são de exclusiva responsabilidade da ConstruNews

 

 

From owner-namedroppers@ops.ietf.org Tue Nov 18 21:18:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01891 for ; Tue, 18 Nov 2003 21:18:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMHl8-000MGP-KL for namedroppers-data@psg.com; Wed, 19 Nov 2003 02:07:58 +0000 Received: from [210.22.146.172] (helo=asbmx.sbell.com.cn) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMHkm-000MFS-Al for namedroppers@ops.ietf.org; Wed, 19 Nov 2003 02:07:36 +0000 Received: from asbwebshld.sbell.com.cn (asbwebshld [172.24.208.38]) by asbmx.sbell.com.cn (8.12.10+Sun/8.12.3) with SMTP id hAJ22rdH016378 for ; Wed, 19 Nov 2003 10:03:11 +0800 (CST) Received: FROM bellnet-mail4.sbell.com.cn BY asbwebshld.sbell.com.cn ; Wed Nov 19 10:09:52 2003 +0800 Received: from BELLNET-MAIL3.sbell.com.cn ([172.24.208.23]) by bellnet-mail4.sbell.com.cn with Microsoft SMTPSVC(5.0.2195.6713); Wed, 19 Nov 2003 10:09:52 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3AE42.37AD8229" Subject: Issue: Add a new QTYPE X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 19 Nov 2003 10:09:52 +0800 Message-ID: <8634B809B90D6E4AACA4AB0562A1F072045DE7@bellnet-mail3.sbell.com.cn> Thread-Topic: Issue: Add a new QTYPE Thread-Index: AcOuQYvA4Sbg6SCjRWSWN9n17R1BpAAAD6jA From: "CTO WEI Renxiang" To: X-OriginalArrivalTime: 19 Nov 2003 02:09:52.0392 (UTC) FILETIME=[37CF6880:01C3AE42] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=0.1 required=5.0 tests=BAYES_44,HTML_MESSAGE autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3AE42.37AD8229 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable > issue: Propose to add a QTYPE to support dual-stack host. >=20 > name: Renxiang Yan > email: renxiang.wei@alcatel-sbell.com.cn > date: 2003-11-18 > Type: T > Priority: F >=20 > Currently, the DNS resolver libraries on a dual-stack host have = to initiates two DNS query=20 > for a specific host, one with QTYPE AAAA(or A6), the other with QTYPE = A. The disadvantages are:=20 > 1. increasing the delay in communication. > 2. waste network bandwidth. >=20 > Also, while DNS resolver libraries get two record, it have to = decision to filter or order DNS results, > and this process have not been specified.=20 >=20 > I suppose in this mail to: > 1. add a new QTYPE ( which could be named "DS", means Dual Stack") = to indicate both AAAA (A6)=20 > and A record. DNS resolver libraries can initiate just one DNS query = to get both IPv4 and IPv6 DNS > record from DNS server. > 2. To promote the IPv6 deployment, DNS results for a dual-stack = host returned by DNS resolver > is suggested to be ordered in IPv6-IPv4. >=20 > R.G. > Renxiang Yan >=20 ------_=_NextPart_001_01C3AE42.37AD8229 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable Issue: Add a new QTYPE

issue: Propose to = add a QTYPE to support dual-stack host.

name: Renxiang = Yan
email: = renxiang.wei@alcatel-sbell.com.cn
date:   = 2003-11-18
Type: = T
Priority: = F

     Currently, the DNS resolver = libraries on  a dual-stack host have to initiates two DNS query =
for a specific = host, one with QTYPE AAAA(or A6), the other with QTYPE A. The = disadvantages are:
     1. increasing the delay in = communication.
     2. waste network = bandwidth.

    = Also, while DNS resolver libraries get two record, it have to decision = to filter or order DNS results,
and this = process  have not been specified.

    = I suppose in this mail to:
    1. add a new QTYPE ( which could be = named "DS", means Dual Stack") to indicate both AAAA (A6) =
and A record. DNS = resolver libraries can initiate just one DNS query to get both IPv4 and = IPv6 DNS
record from DNS = server.
   = 2.  To promote the IPv6 deployment, DNS results for a dual-stack = host returned by DNS resolver
is suggested to = be ordered in IPv6-IPv4.

R.G.
Renxiang = Yan

------_=_NextPart_001_01C3AE42.37AD8229-- -- to unsubscribe send a message to namedroppers-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 Nov 19 04:22:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09847 for ; Wed, 19 Nov 2003 04:22:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMONw-000Id5-2L for namedroppers-data@psg.com; Wed, 19 Nov 2003 09:12:28 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMONi-000IcX-Ps for namedroppers@ops.ietf.org; Wed, 19 Nov 2003 09:12:14 +0000 Received: (from bmanning@localhost) by karoshi.com (8.11.6/8.11.6 - yeah right) id hAJ9DQo11158; Wed, 19 Nov 2003 01:13:26 -0800 From: bill Message-Id: <200311190913.hAJ9DQo11158@karoshi.com> Subject: Re: Issue: Add a new QTYPE To: Renxiang.WEI@alcatel-sbell.com.cn (CTO WEI Renxiang) Date: Wed, 19 Nov 2003 01:13:26 -0800 (PST) Cc: namedroppers@ops.ietf.org In-Reply-To: <8634B809B90D6E4AACA4AB0562A1F072045DE7@bellnet-mail3.sbell.com.cn> from "CTO WEI Renxiang" at Nov 19, 2003 10:09:52 AM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit two comments: there is not enough functional distinction laid out in the arguments to justify a new QTYPE, they are both QUERY's but for different address classes. there already exists an RR with type "DS" and overloading memnonics has never been a good idea. > This is a multi-part message in MIME format. > > ------_=_NextPart_001_01C3AE42.37AD8229 > Content-Type: text/plain; > charset="gb2312" > Content-Transfer-Encoding: quoted-printable > > > > issue: Propose to add a QTYPE to support dual-stack host. > >=20 > > name: Renxiang Yan > > email: renxiang.wei@alcatel-sbell.com.cn > > date: 2003-11-18 > > Type: T > > Priority: F > >=20 > > Currently, the DNS resolver libraries on a dual-stack host have = > to initiates two DNS query=20 > > for a specific host, one with QTYPE AAAA(or A6), the other with QTYPE = > A. The disadvantages are:=20 > > 1. increasing the delay in communication. > > 2. waste network bandwidth. > >=20 > > Also, while DNS resolver libraries get two record, it have to = > decision to filter or order DNS results, > > and this process have not been specified.=20 > >=20 > > I suppose in this mail to: > > 1. add a new QTYPE ( which could be named "DS", means Dual Stack") = > to indicate both AAAA (A6)=20 > > and A record. DNS resolver libraries can initiate just one DNS query = > to get both IPv4 and IPv6 DNS > > record from DNS server. > > 2. To promote the IPv6 deployment, DNS results for a dual-stack = > host returned by DNS resolver > > is suggested to be ordered in IPv6-IPv4. > >=20 > > R.G. > > Renxiang Yan > >=20 > > ------_=_NextPart_001_01C3AE42.37AD8229 > Content-Type: text/html; > charset="gb2312" > Content-Transfer-Encoding: quoted-printable > > > > > charset=3Dgb2312"> > 6.0.6249.1"> > Issue: Add a new QTYPE > > > >
> >

issue: Propose to = > add a QTYPE to support dual-stack host. >

> >

name: Renxiang = > Yan > >
email: = > renxiang.wei@alcatel-sbell.com.cn > >
date:   = > 2003-11-18 > >
Type: = > T > >
Priority: = > F >

> >

FACE=3D"Arial">     Currently, the DNS resolver = > libraries on  a dual-stack host have to initiates two DNS query = > > >
for a specific = > host, one with QTYPE AAAA(or A6), the other with QTYPE A. The = > disadvantages are: > >
FACE=3D"Arial">     1. increasing the delay in = > communication. > >
FACE=3D"Arial">     2. waste network = > bandwidth. >

> >

    = > Also, while DNS resolver libraries get two record, it have to decision = > to filter or order DNS results, > >
and this = > process  have not been specified. >

> >

    = > I suppose in this mail to: > >
FACE=3D"Arial">    1. add a new QTYPE ( which could be = > named "DS", means Dual Stack") to indicate both AAAA (A6) = > > >
and A record. DNS = > resolver libraries can initiate just one DNS query to get both IPv4 and = > IPv6 DNS > >
record from DNS = > server. > >
   = > 2.  To promote the IPv6 deployment, DNS results for a dual-stack = > host returned by DNS resolver > >
is suggested to = > be ordered in IPv6-IPv4. >

> >

R.G. > >
Renxiang = > Yan >

> > > > ------_=_NextPart_001_01C3AE42.37AD8229-- > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Nov 19 05:28:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11146 for ; Wed, 19 Nov 2003 05:28:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMPTb-000NHI-26 for namedroppers-data@psg.com; Wed, 19 Nov 2003 10:22:23 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMPTJ-000NG3-Qf for namedroppers@ops.ietf.org; Wed, 19 Nov 2003 10:22:06 +0000 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id hAJAM1g18081; Wed, 19 Nov 2003 17:22:01 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id hAJALcP02791; Wed, 19 Nov 2003 17:21:46 +0700 (ICT) From: Robert Elz To: bill cc: Renxiang.WEI@alcatel-sbell.com.cn (CTO WEI Renxiang), namedroppers@ops.ietf.org Subject: Re: Issue: Add a new QTYPE In-Reply-To: <200311190913.hAJ9DQo11158@karoshi.com> References: <200311190913.hAJ9DQo11158@karoshi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 19 Nov 2003 17:21:38 +0700 Message-ID: <5360.1069237298@munnari.OZ.AU> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Wed, 19 Nov 2003 01:13:26 -0800 (PST) From: bill Message-ID: <200311190913.hAJ9DQo11158@karoshi.com> | there is not enough functional distinction laid out in the arguments | to justify a new QTYPE, they are both QUERY's but for different address | classes. No, it is clear what is being requested, that's the invention of a meta query for IP type addresses. This has been discussed before, meta queries just don't work if you actually care about the answers (but are fine if you don't really care - the ANY query is an example, the proposed query is just a subset ANY really). The namedroppers archives contain plenty os material on just why meta queries don't work, so I don't think we need to repeat it all here. A more feasible (but still not easy) solution to the problem raised, as much as it actually is a problem, is to do one query with multiple questions. That doesn't really work with standard DNS that's deployed, but can be made to work with suitable levels of EDNS added in (I forget which EDNSn is required for it nor if it is even agreed yet). | there already exists an RR with type "DS" and overloading memnonics | has never been a good idea. Indeed, but if that were the only issue, fixing it would not be hard... kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Nov 19 08:35:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16078 for ; Wed, 19 Nov 2003 08:35:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMSO6-0009Yl-NM for namedroppers-data@psg.com; Wed, 19 Nov 2003 13:28:54 +0000 Received: from [207.65.203.98] (helo=goose.ehsco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMSNm-0009Y3-Rr for namedroppers@ops.ietf.org; Wed, 19 Nov 2003 13:28:34 +0000 Received: from [207.65.3.26] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 4.1.3) with ESMTP-TLS id 644135; Wed, 19 Nov 2003 11:14:17 -0600 Message-ID: <3FBB6FFE.7070107@ehsco.com> Date: Wed, 19 Nov 2003 07:28:30 -0600 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Elz CC: bill , CTO WEI Renxiang , namedroppers@ops.ietf.org Subject: Re: Issue: Add a new QTYPE References: <200311190913.hAJ9DQo11158@karoshi.com> <5360.1069237298@munnari.OZ.AU> In-Reply-To: <5360.1069237298@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jim Reid put out a draft that was useful and promising as I recollect. Robert Elz wrote: > No, it is clear what is being requested, that's the invention of a meta > query for IP type addresses. This has been discussed before, meta > queries just don't work if you actually care about the answers (but > are fine if you don't really care - the ANY query is an example, the > proposed query is just a subset ANY really). Ah, yeah we have, but QTYPE=ADDR wasn't a subset of QTYPE=ANY. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Nov 19 09:52:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18751 for ; Wed, 19 Nov 2003 09:52:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMTZW-000Ek6-OZ for namedroppers-data@psg.com; Wed, 19 Nov 2003 14:44:46 +0000 Received: from [216.168.237.102] (helo=heron.verisign.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMTZK-000Ehg-Ba for namedroppers@ops.ietf.org; Wed, 19 Nov 2003 14:44:34 +0000 Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by heron.verisign.com (8.12.10/8.12.10) with ESMTP id hAJEiXha024527 for ; Wed, 19 Nov 2003 09:44:33 -0500 (EST) Received: from chinook.rgy.netsol.com (host49-130-valks2.corppc.vrsn.com [10.131.130.49]) by VSVAPOSTALGW1.prod.netsol.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XFK174V3; Wed, 19 Nov 2003 09:44:32 -0500 Received: by chinook.rgy.netsol.com (Postfix, from userid 500) id CB9D59BE20; Wed, 19 Nov 2003 09:44:32 -0500 (EST) Date: Wed, 19 Nov 2003 09:44:32 -0500 From: Matt Larson To: Namedroppers Mailing List Subject: Q-21: Can NSEC records in the cache be re-used? Message-ID: <20031119144432.GP15349@chinook.rgy.netsol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Q-21: Can NSEC records in the cache be re-used? Section 3.2, second paragraph, of draft-ietf-dnsext-dnssec-protocol-03.txt refers to the re-use of NSEC records from the cache: A security-aware recursive name server MUST NOT use NSEC RRs from one negative response to synthesize a response for a different query. Some reviewers have suggested that this language is overly restrictive. The editors propose this additional text immediately following the above sentence to allow for a specific case of re-use: A security-aware recursive name server MAY use an NSEC RR from a previous response to generate a NODATA response to a current query, provided that the QNAME and QCLASS of the current query match the owner name and class, respectively, of the cached NSEC RR. Does the working group have any objection to this added text? -- to unsubscribe send a message to namedroppers-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 Nov 19 12:14:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27608 for ; Wed, 19 Nov 2003 12:14:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMVo7-000NvN-RI for namedroppers-data@psg.com; Wed, 19 Nov 2003 17:07:59 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMVnv-000NuV-Nk for namedroppers@ops.ietf.org; Wed, 19 Nov 2003 17:07:47 +0000 Received: (from bmanning@localhost) by karoshi.com (8.11.6/8.11.6 - yeah right) id hAJH8vU14621; Wed, 19 Nov 2003 09:08:57 -0800 From: bill Message-Id: <200311191708.hAJH8vU14621@karoshi.com> Subject: Re: Issue: Add a new QTYPE To: kre@munnari.OZ.AU (Robert Elz) Date: Wed, 19 Nov 2003 09:08:57 -0800 (PST) Cc: bmanning@karoshi.com (bill), Renxiang.WEI@alcatel-sbell.com.cn (CTO WEI Renxiang), namedroppers@ops.ietf.org In-Reply-To: <5360.1069237298@munnari.OZ.AU> from "Robert Elz" at Nov 19, 2003 05:21:38 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > Date: Wed, 19 Nov 2003 01:13:26 -0800 (PST) > From: bill > Message-ID: <200311190913.hAJ9DQo11158@karoshi.com> > > | there is not enough functional distinction laid out in the arguments > | to justify a new QTYPE, they are both QUERY's but for different address > | classes. > > No, it is clear what is being requested, that's the invention of a meta > query for IP type addresses. > ... > The namedroppers archives contain plenty os material on just why meta > queries don't work, so I don't think we need to repeat it all here. > > A more feasible (but still not easy) solution to the problem raised, > as much as it actually is a problem, is to do one query with multiple > questions. That doesn't really work with standard DNS that's deployed, > but can be made to work with suitable levels of EDNS added in (I forget > which EDNSn is required for it nor if it is even agreed yet). or.... one query with multiple, valid replies. see also (DISCOVER) > kre > --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Nov 19 12:23:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27847 for ; Wed, 19 Nov 2003 12:23:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMVyF-000OQc-AY for namedroppers-data@psg.com; Wed, 19 Nov 2003 17:18:27 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMVy2-000OQE-JZ for namedroppers@ops.ietf.org; Wed, 19 Nov 2003 17:18:14 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 55FF41396A for ; Wed, 19 Nov 2003 17:18:14 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Issue: Add a new QTYPE In-Reply-To: Message from Robert Elz of "Wed, 19 Nov 2003 17:21:38 +0700." <5360.1069237298@munnari.OZ.AU> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 19 Nov 2003 17:18:14 +0000 Message-Id: <20031119171814.55FF41396A@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ... > The namedroppers archives contain plenty os material on just why meta > queries don't work, so I don't think we need to repeat it all here. there's meta and then there's meta. had we specified that AAAA responses had additional data processing of the form "add any matching A RRsets" then a single AAAA query, either to an authority or a cache, would give us all of the data we'd want in one query. (note that these would be added even if the AAAA response set was empty.) it's not too late for that by the way. > A more feasible (but still not easy) solution to the problem raised, > as much as it actually is a problem, is to do one query with multiple > questions. That doesn't really work with standard DNS that's deployed, > but can be made to work with suitable levels of EDNS added in (I forget > which EDNSn is required for it nor if it is even agreed yet). it was part of edns1 as proposed, but that was shot down as "too complex" because of the other things that had to be optioned (like first match vs. all matches, and recursive vs. really recursive). my strong recommendation is still that we include A RR's in the additional data section of any response to AAAA. then if clients who want "whichever exists" or even "both if possible" simply ask for AAAA first, and if they happen to be talking to an aaaa-additional-a capable server, they can get what they want in one RTT. when talking to older servers they still have to pay two RTTs but that's no worse than today. -- to unsubscribe send a message to namedroppers-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 Nov 19 12:36:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28575 for ; Wed, 19 Nov 2003 12:36:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMWAY-000PIn-K1 for namedroppers-data@psg.com; Wed, 19 Nov 2003 17:31:10 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMWAE-000PHt-Nz for namedroppers@ops.ietf.org; Wed, 19 Nov 2003 17:30:50 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 8A1661394B for ; Wed, 19 Nov 2003 17:30:50 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Namedroppers Mailing List Subject: Re: Q-21: Can NSEC records in the cache be re-used? In-Reply-To: Message from Matt Larson of "Wed, 19 Nov 2003 09:44:32 EST." <20031119144432.GP15349@chinook.rgy.netsol.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 19 Nov 2003 17:30:50 +0000 Message-Id: <20031119173050.8A1661394B@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ... > A security-aware recursive name server MUST NOT use NSEC RRs from > one negative response to synthesize a response for a different > query. > > Some reviewers have suggested that this language is overly > restrictive. The editors propose this additional text immediately > following the above sentence to allow for a specific case of re-use: > > A security-aware recursive name server MAY use an NSEC RR from a > previous response to generate a NODATA response to a current query, > provided that the QNAME and QCLASS of the current query match the > owner name and class, respectively, of the cached NSEC RR. > > Does the working group have any objection to this added text? i think so but i'm not sure. dnssec pseudo-rr's are really just metadata and i'm uncomfortable with anything that unbinds them from their carrier primary data. if the above wording makes dnssec metadata atomic with respect to its the data it pertains to then i have no objection. but, i can't tell from here. -- to unsubscribe send a message to namedroppers-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 Nov 19 13:15:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00951 for ; Wed, 19 Nov 2003 13:15:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMWkO-0001Yv-NQ for namedroppers-data@psg.com; Wed, 19 Nov 2003 18:08:12 +0000 Received: from [129.6.16.93] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMWkC-0001Xz-0T for namedroppers@ops.ietf.org; Wed, 19 Nov 2003 18:08:00 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id hAJI7Z18008229 for ; Wed, 19 Nov 2003 13:07:35 -0500 (EST) Message-ID: <034f01c3aec8$0356ac90$b9370681@barnacle> From: "Scott Rose" To: References: <20031119173050.8A1661394B@sa.vix.com> Subject: Re: Q-21: Can NSEC records in the cache be re-used? Date: Wed, 19 Nov 2003 13:07:36 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Paul Vixie" > > i think so but i'm not sure. dnssec pseudo-rr's are really just metadata > and i'm uncomfortable with anything that unbinds them from their carrier > primary data. if the above wording makes dnssec metadata atomic with > respect to its the data it pertains to then i have no objection. but, i > can't tell from here. > > another thing to think about is if it is safe to use cached data to form a negative reply out of RRs from a previous negative reply. off topic for Q21 (re: dnssec rrs): In a way, yes. NSEC RRs could be queried for the information they do contain, since they contain more non-security information than RRSIGs. I can imagine a scenario where a application may want to issue NSEC queries instead of "name. IN ANY" queries, for example. An RRSIG isn't that informative without the RR set it covers. A NSEC RR contains some information that could be used in a non-DNSSEC manner. > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Nov 19 13:38:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02364 for ; Wed, 19 Nov 2003 13:38:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMX8m-00036T-M2 for namedroppers-data@psg.com; Wed, 19 Nov 2003 18:33:24 +0000 Received: from [65.201.175.62] (helo=cliffie.verisignlabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMX8H-00033U-5V for namedroppers@ops.ietf.org; Wed, 19 Nov 2003 18:32:53 +0000 Received: from pinion.admin.cto.netsol.com ([::ffff:172.25.170.10]) (AUTH: LOGIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by cliffie.verisignlabs.com with esmtp; Wed, 19 Nov 2003 13:32:51 -0500 From: David Blacka Organization: Verisign, Inc. To: namedroppers@ops.ietf.org Subject: Re: Q-21: Can NSEC records in the cache be re-used? Date: Wed, 19 Nov 2003 13:32:51 -0500 User-Agent: KMail/1.5.3 References: <20031119144432.GP15349@chinook.rgy.netsol.com> In-Reply-To: <20031119144432.GP15349@chinook.rgy.netsol.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200311191332.51401.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday 19 November 2003 09:44 am, Matt Larson wrote: > Q-21: Can NSEC records in the cache be re-used? > > Section 3.2, second paragraph, of > draft-ietf-dnsext-dnssec-protocol-03.txt refers to the re-use of NSEC > records from the cache: > > A security-aware recursive name server MUST NOT use NSEC RRs from > one negative response to synthesize a response for a different > query. I'm not even sure this sentence accomplishes what was originally intended. What about NSEC RRs that were part of a positive response (i.e., a referral)? > Some reviewers have suggested that this language is overly > restrictive. The editors propose this additional text immediately > following the above sentence to allow for a specific case of re-use: While this sentence may be too restrictive, the previous sentence in that paragraph certainly is: A security-aware recursive name server MUST NOT attempt to answer a query by piecing together cached data it received in response to previous queries that requested different QNAMEs, QTYPEs, or QCLASSes. > A security-aware recursive name server MAY use an NSEC RR from a > previous response to generate a NODATA response to a current query, > provided that the QNAME and QCLASS of the current query match the > owner name and class, respectively, of the cached NSEC RR. > > Does the working group have any objection to this added text? One of my issues is that I (and perhaps the WG as a whole) don't really understand the issue well enough to judge. Ultimately, what I would like to see is language describing what the caching nameserver MUST NOT do with cached NSEC records, and have that MUST NOT be defined as narrowly as possible. Additonally, I would like to see language describing WHY caches MUST NOT use NSEC records in that fashion. But I think the first step is making sure we understand the problem in the first place. -- David Blacka Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Nov 19 13:39:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02380 for ; Wed, 19 Nov 2003 13:39:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMXBY-0003L2-NS for namedroppers-data@psg.com; Wed, 19 Nov 2003 18:36:16 +0000 Received: from [192.150.250.67] (helo=fuchsia.noi.kre.to) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMXAj-0003G5-2N for namedroppers@ops.ietf.org; Wed, 19 Nov 2003 18:35:42 +0000 Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.noi.kre.to with ESMTP id hAJIYK0H027890; Thu, 20 Nov 2003 01:34:23 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id hAJIVv416706; Thu, 20 Nov 2003 01:32:05 +0700 (ICT) From: Robert Elz To: Paul Vixie cc: namedroppers@ops.ietf.org Subject: Re: Issue: Add a new QTYPE In-Reply-To: <20031119171814.55FF41396A@sa.vix.com> References: <20031119171814.55FF41396A@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 20 Nov 2003 01:31:57 +0700 Message-ID: <9192.1069266717@munnari.OZ.AU> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Wed, 19 Nov 2003 17:18:14 +0000 From: Paul Vixie Message-ID: <20031119171814.55FF41396A@sa.vix.com> | my strong recommendation is still that we include A RR's in the additional | data section of any response to AAAA. That might work, if we can get enough servers to actually implement it. But it is a short term hack, which we'd need to eradicate eventually, and that's one reason I don't think it is a good idea. That is it would work now, as in practice, just about everything has an A record, so you'd either expect to get one, or assume the server is old and do a second query. But if/when we reach the state where many names have only AAAA, then not getting the A just means there isn't one - unless of course, it is an old server for which we need an extra A query. The effect of this is that as the number of A records decreases, the number of A queries increases. That's not a good property. Doing it just this way (and not also saying "add AAAA as additional in any A query") is also assuming that AAAA is a 2nd class type of address, and that everyone is really going to need the A that goes along with it. That's not the message to send either. So, I wouldn't support this (I actually don't really believe that simply doing both an A and an AAAA query is all that bad - hosts can prefer one, and only do the other if the preferred one is NODATA - or they can simply send 2 queries in parallel, and get back both answers). Briefly in reply to a couple of other messages ... Eric - as I recall the ADDR query wasn't quite a subset of ANY, but to get that more or less abandoned reasonable caching - which is the real problem with all meta queries, they simply don't play well with caches, and caches are more important. In any case, those discussions are in the archives too... The point of my original reply was that the suggested idea is not new, and has never gotten anywhere before. Bill - I can't even begin to imagine what discover has to do with any of this. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Nov 19 14:10:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04274 for ; Wed, 19 Nov 2003 14:10:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMXdq-0005Yn-Mx for namedroppers-data@psg.com; Wed, 19 Nov 2003 19:05:30 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMXdd-0005Ws-Fa for namedroppers@ops.ietf.org; Wed, 19 Nov 2003 19:05:17 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 4DB811396E for ; Wed, 19 Nov 2003 19:05:17 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Q-21: Can NSEC records in the cache be re-used? In-Reply-To: Message from "Scott Rose" of "Wed, 19 Nov 2003 13:07:36 EST." <034f01c3aec8$0356ac90$b9370681@barnacle> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 19 Nov 2003 19:05:17 +0000 Message-Id: <20031119190517.4DB811396E@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ... > off topic for Q21 (re: dnssec rrs): > In a way, yes. NSEC RRs could be queried for the information they do > contain, since they contain more non-security information than RRSIGs. I > can imagine a scenario where a application may want to issue NSEC queries > instead of "name. IN ANY" queries, for example. An RRSIG isn't that > informative without the RR set it covers. A NSEC RR contains some > information that could be used in a non-DNSSEC manner. let me emphasize what i mean by metadata. i'd like to see NSEC, RRSIG, and DNSKEY treated more like AXFR and IXFR, such that one could never query for them directly. their only existence should be as part of zone transfers or responses containing signed data. -- to unsubscribe send a message to namedroppers-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 Nov 19 14:19:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04807 for ; Wed, 19 Nov 2003 14:19:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMXl3-0005t0-2Y for namedroppers-data@psg.com; Wed, 19 Nov 2003 19:12:57 +0000 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMXkq-0005sC-2g for namedroppers@ops.ietf.org; Wed, 19 Nov 2003 19:12:44 +0000 Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.11.7p1+Sun/8.11.6/TechFak/2003/04/16/pk) with ESMTP id hAJJCg129055 for ; Wed, 19 Nov 2003 20:12:42 +0100 (MET) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id hAJJCgT26670 for ; Wed, 19 Nov 2003 20:12:42 +0100 (MET) Message-Id: <200311191912.hAJJCgT26670@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org Subject: Re: Issue: Add a new QTYPE In-reply-to: Your message of "Thu, 20 Nov 2003 01:31:57 +0700." <9192.1069266717@munnari.OZ.AU> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26666.1069269161.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Wed, 19 Nov 2003 20:12:42 +0100 From: Peter Koch X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Robert Elz wrote: > doing both an A and an AAAA query is all that bad - hosts can prefer one, > and only do the other if the preferred one is NODATA - or they can simply > send 2 queries in parallel, and get back both answers). what one can see at an "edge nameserver" is an amount of queries for AAAA and A6 which each is around 50% of the number of A queries. That's far higher than justified by the currently deployed IPv6 base. One "culprit" is a popular nameserver implementation. Another share is due to the usually lower TTLs for negative answers. So A stays in the cache, the NODATA for AAAA doesn't. While I think the multiple-queries-approach deserves some further investigation I'm not too sure it would help in significantly reducing the number of queries and thus RTT. There's simply no way to influence the lifetime of a particular negative response and there's no other way to say "I have no AAAA for foo.example.com and won't for the next day". Paul's suggestion to piggy-back the A RRs onto the AAAA responses won't really help unless the queries are sent non-recursively (to the local resolver/cache). -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Nov 19 14:19:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04825 for ; Wed, 19 Nov 2003 14:19:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMXkd-0005rq-Dd for namedroppers-data@psg.com; Wed, 19 Nov 2003 19:12:31 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMXkQ-0005r1-Cm for namedroppers@ops.ietf.org; Wed, 19 Nov 2003 19:12:18 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 2D9F61395D for ; Wed, 19 Nov 2003 19:12:18 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Issue: Add a new QTYPE In-Reply-To: Message from Robert Elz of "Thu, 20 Nov 2003 01:31:57 +0700." <9192.1069266717@munnari.OZ.AU> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 19 Nov 2003 19:12:18 +0000 Message-Id: <20031119191218.2D9F61395D@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ... > That might work, if we can get enough servers to actually implement it. > But it is a short term hack, which we'd need to eradicate eventually, > and that's one reason I don't think it is a good idea. for it to be a short term hack in need of eventual eradication, there would have to be a large difference in expected lifetime between "names for which A RR's exist" and "clients who need A RR's". i think that those two lifetimes are in the same rough order of magnitude, and that by the time you'd be thinking of eradicating it because the additional data wasn't generally useful, the data itself would go into end-of-life. > ... > Bill - I can't even begin to imagine what discover has to do with any > of this. agreed. DISCOVER is about finding servers, not finding answers. -- to unsubscribe send a message to namedroppers-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 Nov 19 14:30:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05446 for ; Wed, 19 Nov 2003 14:30:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMXtp-0006ky-Oo for namedroppers-data@psg.com; Wed, 19 Nov 2003 19:22:01 +0000 Received: from [131.107.3.125] (helo=mail1.microsoft.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMXtd-0006kW-CE for namedroppers@ops.ietf.org; Wed, 19 Nov 2003 19:21:49 +0000 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 19 Nov 2003 11:21:03 -0800 Received: from 157.54.8.23 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 19 Nov 2003 11:21:48 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 19 Nov 2003 11:21:44 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 19 Nov 2003 11:21:53 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 19 Nov 2003 11:21:48 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7097.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue: Add a new QTYPE Date: Wed, 19 Nov 2003 11:21:51 -0800 Message-ID: Thread-Topic: Issue: Add a new QTYPE Thread-Index: AcOuzRR0NzoutYN/Rhyo3QF+5GQwyAABNQCA From: "Christian Huitema" To: "Robert Elz" , "Paul Vixie" Cc: X-OriginalArrivalTime: 19 Nov 2003 19:21:48.0757 (UTC) FILETIME=[60D6F050:01C3AED2] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > | my strong recommendation is still that we include A RR's in the > additional > | data section of any response to AAAA. >=20 > That might work, if we can get enough servers to actually implement it. > But it is a short term hack, which we'd need to eradicate eventually, > and that's one reason I don't think it is a good idea. We actually discussed and rejected the additional processing suggestion -- it was present in the original draft of 1886. The argument was pretty much the one Robert just gave: we will have to remove the processing requirement eventually. It was also not clear that it would be useful in most cases. OTOH, I don't believe that the protocol police will jail you if you actually return the A records in the additional section of an AAAA query, especially if the AAAA record set is empty. -- Christian Huitema -- to unsubscribe send a message to namedroppers-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 Nov 19 14:38:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05725 for ; Wed, 19 Nov 2003 14:38:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMY3K-0007Qb-Pq for namedroppers-data@psg.com; Wed, 19 Nov 2003 19:31:50 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMY38-0007Ps-9l for namedroppers@ops.ietf.org; Wed, 19 Nov 2003 19:31:38 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 1535B1396D for ; Wed, 19 Nov 2003 19:31:38 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Issue: Add a new QTYPE In-Reply-To: Message from "Christian Huitema" of "Wed, 19 Nov 2003 11:21:51 PST." X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 19 Nov 2003 19:31:38 +0000 Message-Id: <20031119193138.1535B1396D@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > We actually discussed and rejected the additional processing suggestion > -- it was present in the original draft of 1886. The argument was pretty > much the one Robert just gave: we will have to remove the processing > requirement eventually. It was also not clear that it would be useful in > most cases. i believed i had shown during the debate over 1886, and i believe i have shown again here today, that the lifetime of the data will be the same as the lifetime of its usefulness. this really is not a bad idea, folks. > OTOH, I don't believe that the protocol police will jail you if you > actually return the A records in the additional section of an AAAA > query, especially if the AAAA record set is empty. isc has sometimes been accused of "legislating from the bench" by using the power of the bind installed base to get things into the protocols that ietf did not otherwise think was a good idea. we won't be doing that here. unless there's consensus that adding A RR's as additional data for AAAA responses (empty or not) is non-harmful, it won't happen, or at least, it won't happen in bind. -- to unsubscribe send a message to namedroppers-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 Nov 19 14:43:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05924 for ; Wed, 19 Nov 2003 14:43:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMY9g-00081W-U0 for namedroppers-data@psg.com; Wed, 19 Nov 2003 19:38:24 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMY9T-000806-SE for namedroppers@ops.ietf.org; Wed, 19 Nov 2003 19:38:11 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 947381395D for ; Wed, 19 Nov 2003 19:38:11 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Issue: Add a new QTYPE In-Reply-To: Message from Peter Koch of "Wed, 19 Nov 2003 20:12:42 +0100." <200311191912.hAJJCgT26670@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 19 Nov 2003 19:38:11 +0000 Message-Id: <20031119193811.947381395D@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Paul's suggestion to piggy-back the A RRs onto the AAAA responses > won't really help unless the queries are sent non-recursively (to the > local resolver/cache). when a recursive server has no AAAA and so forwards the AAAA query to an authority, if that authority includes A as additional data then it will land in the same recursive cache as the AAAA. -- to unsubscribe send a message to namedroppers-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 Nov 19 14:58:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06671 for ; Wed, 19 Nov 2003 14:58:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMYOH-0008x0-Be for namedroppers-data@psg.com; Wed, 19 Nov 2003 19:53:29 +0000 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMYO4-0008wA-Pp for namedroppers@ops.ietf.org; Wed, 19 Nov 2003 19:53:17 +0000 Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.11.7p1+Sun/8.11.6/TechFak/2003/04/16/pk) with ESMTP id hAJJrF101111 for ; Wed, 19 Nov 2003 20:53:15 +0100 (MET) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id hAJJrF726864 for ; Wed, 19 Nov 2003 20:53:15 +0100 (MET) Message-Id: <200311191953.hAJJrF726864@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org Subject: Re: Issue: Add a new QTYPE In-reply-to: Your message of "Wed, 19 Nov 2003 19:38:11 GMT." <20031119193811.947381395D@sa.vix.com> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26860.1069271594.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Wed, 19 Nov 2003 20:53:14 +0100 From: Peter Koch X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > when a recursive server has no AAAA and so forwards the AAAA query to > an authority, if that authority includes A as additional data then it > will land in the same recursive cache as the AAAA. sure, but if there's no AAAA you learn that from the cache, provided the NODATA is there. If it is, the A-RRs may be put into the answer packet (out of the cache) or the application has to query again. Local traffic, no problem. Now, if there's neither an AAAA (maybe it really doesn't exist) nor a NODATA (which has expired), you can only learn the NODATA from an authoritative server. NODATA will expire frequently, so you'll have to ask an authoritative server again and again, although the A RR will still sit in your cache. If you first check your cache and use whatever is in there and only ask for AAAA if the cache is empty (i.e. has neither A nor AAAA), there's lesser RTT and lesser queries. Obviously for this to work positive TTLs for A and AAAA need to be the same. Maybe we should stick AAAA RRs in the additional section for A responses instead. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Nov 19 15:17:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08722 for ; Wed, 19 Nov 2003 15:17:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMYhp-000ABy-5t for namedroppers-data@psg.com; Wed, 19 Nov 2003 20:13:41 +0000 Received: from [24.61.21.229] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMYhd-000ABe-J3 for namedroppers@ops.ietf.org; Wed, 19 Nov 2003 20:13:29 +0000 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id A7AEB18DE for ; Wed, 19 Nov 2003 15:13:28 -0500 (EST) Date: Wed, 19 Nov 2003 15:13:28 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Issue: Add a new QTYPE In-Reply-To: <200311191912.hAJJCgT26670@grimsvotn.TechFak.Uni-Bielefeld.DE> References: <9192.1069266717@munnari.OZ.AU> <200311191912.hAJJCgT26670@grimsvotn.TechFak.Uni-Bielefeld.DE> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20031119201328.A7AEB18DE@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Wed, 19 Nov 2003 20:12:42 +0100, Peter Koch wrote: > > what one can see at an "edge nameserver" is an amount of queries for AAAA and > A6 which each is around 50% of the number of A queries. That's far higher than > justified by the currently deployed IPv6 base. One "culprit" is a popular > nameserver implementation. Another share is due to the usually lower TTLs > for negative answers. So A stays in the cache, the NODATA for AAAA doesn't. Another known culprit is a certain (otherwise rather nice) open source web browser, which apparently includes its own resolver implementation and which issues not just AAAA but also A6 queries for every new name it sees in a URL. (One finds the oddest things running dnstop....) Point here is not to slam the browser authors, it's to underscore that even with negative caching there's a limit how much we can hold down the traffic generated by a busy little dual-stack application. -- to unsubscribe send a message to namedroppers-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 Nov 19 15:19:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08994 for ; Wed, 19 Nov 2003 15:19:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMYgn-000A8j-TD for namedroppers-data@psg.com; Wed, 19 Nov 2003 20:12:37 +0000 Received: from [207.65.203.98] (helo=goose.ehsco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMYef-000A3z-M4 for namedroppers@ops.ietf.org; Wed, 19 Nov 2003 20:10:25 +0000 Received: from [207.65.3.26] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 4.1.3) with ESMTP-TLS id 644212; Wed, 19 Nov 2003 17:56:08 -0600 Message-ID: <3FBBCE2D.7040909@ehsco.com> Date: Wed, 19 Nov 2003 14:10:21 -0600 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Elz CC: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: Issue: Add a new QTYPE References: <20031119171814.55FF41396A@sa.vix.com> <9192.1069266717@munnari.OZ.AU> In-Reply-To: <9192.1069266717@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Robert Elz wrote: > Eric - as I recall the ADDR query wasn't quite a subset of ANY, but > to get that more or less abandoned reasonable caching - which is the > real problem with all meta queries, they simply don't play well with > caches, and caches are more important. In any case, those discussions > are in the archives too... The point of my original reply was that > the suggested idea is not new, and has never gotten anywhere before. It's true that all of the proposals have gone nowhere, but that's because they all share the same problem, which is that empty RRsets of alternate addresses can't be represented in the answer -- you can't give AAAA RRs and an NXDATA for (non-existent) A RRs in the same answer, so resolvers are forced to assume that any incomplete answer is truly incomplete, essentially requiring multiple queries to find out for sure. This problem exists for qtype=ADDR and just-include alike. If it is explicitly addressed in either proposal (such as including some kind of flag, or including an SOA, or whatever), it can also be addressed in the other. We need to figure out the preferred mechanism for representing incomplete answers in the zone versus incomplete answers in the cache, and then we can back-design whatever mechanism we want to use for the query part. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Nov 19 15:35:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10520 for ; Wed, 19 Nov 2003 15:35:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMYxI-000BHd-SR for namedroppers-data@psg.com; Wed, 19 Nov 2003 20:29:40 +0000 Received: from [211.30.118.161] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMYww-000BGN-MF for namedroppers@ops.ietf.org; Wed, 19 Nov 2003 20:29:18 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9p2/8.12.9) with ESMTP id hAJKTHDW029284 for ; Thu, 20 Nov 2003 07:29:17 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200311192029.hAJKTHDW029284@drugs.dv.isc.org> Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: Issue: Add a new QTYPE In-reply-to: Your message of "Thu, 20 Nov 2003 01:31:57 +0700." <9192.1069266717@munnari.OZ.AU> Date: Thu, 20 Nov 2003 07:29:17 +1100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-2.1 required=5.0 tests=BAYES_00,NO_REAL_NAME, RCVD_IN_DYNABLOCK autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk One way around this is to publish the IPv4 address as mapped addresses in the AAAA records and only look for A records if there are no mapped records. For this to work in the long term a cut off date for looking for A records when there are no mapped IPv4 addresses in the answer would have to be set. A zone verifier would check for inconsistancies between the A / AAAA records and correct / report them. Correcting could be one of "mapped from A" or "A from mapped" or "add missing". An UPDATE to a A/AAAA record would perform the corresponding change on the other RRset. Delete all A records would delete all mapped AAAA records. -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Nov 19 15:37:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10609 for ; Wed, 19 Nov 2003 15:37:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMYz2-000BRu-DX for namedroppers-data@psg.com; Wed, 19 Nov 2003 20:31:28 +0000 Received: from [24.61.21.229] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMYy9-000BNT-Vh for namedroppers@ops.ietf.org; Wed, 19 Nov 2003 20:30:34 +0000 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 5F7B018DE for ; Wed, 19 Nov 2003 15:30:33 -0500 (EST) Date: Wed, 19 Nov 2003 15:30:33 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Issue: Add a new QTYPE In-Reply-To: <3FBBCE2D.7040909@ehsco.com> References: <20031119171814.55FF41396A@sa.vix.com> <9192.1069266717@munnari.OZ.AU> <3FBBCE2D.7040909@ehsco.com> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20031119203033.5F7B018DE@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Wed, 19 Nov 2003 14:10:21 -0600, Eric A. Hall wrote: > > We need to figure out the preferred mechanism for representing incomplete > answers in the zone versus incomplete answers in the cache, and then we > can back-design whatever mechanism we want to use for the query part. Is it just me, or have others started to wonder whether this thread feeds back into DNSSECbis Q-21? -- to unsubscribe send a message to namedroppers-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 Nov 19 16:11:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11746 for ; Wed, 19 Nov 2003 16:11:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMZWf-000Dfq-Vr for namedroppers-data@psg.com; Wed, 19 Nov 2003 21:06:13 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMZWT-000Df6-4F for namedroppers@ops.ietf.org; Wed, 19 Nov 2003 21:06:01 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id D245C13966 for ; Wed, 19 Nov 2003 21:06:00 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Issue: Add a new QTYPE In-Reply-To: Message from Peter Koch of "Wed, 19 Nov 2003 20:53:14 +0100." <200311191953.hAJJrF726864@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 19 Nov 2003 21:06:00 +0000 Message-Id: <20031119210600.D245C13966@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ... > Now, if there's neither an AAAA (maybe it really doesn't exist) nor a > NODATA (which has expired), you can only learn the NODATA from an > authoritative server. NODATA will expire frequently, so you'll have > to ask an authoritative server again and again, although the A RR will > still sit in your cache. but that's how it would be anyway, since these are AAAA queries we're talking about. in what way will we have made this case worse? -- to unsubscribe send a message to namedroppers-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 Nov 19 16:55:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16405 for ; Wed, 19 Nov 2003 16:55:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMaCz-000GKx-Ow for namedroppers-data@psg.com; Wed, 19 Nov 2003 21:49:57 +0000 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMaCj-000GJo-Le for namedroppers@ops.ietf.org; Wed, 19 Nov 2003 21:49:41 +0000 Received: from [65.123.202.247] (wireless247.east.isi.edu [65.123.202.247]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id hAJLnXa17029; Wed, 19 Nov 2003 13:49:33 -0800 (PST) In-Reply-To: <20031119190517.4DB811396E@sa.vix.com> References: <20031119190517.4DB811396E@sa.vix.com> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <425BB8AA-1ADA-11D8-989D-000393C783A2@isi.edu> Content-Transfer-Encoding: 7bit Cc: Daniel Massey From: Daniel Massey Subject: Re: Q-21: Can NSEC records in the cache be re-used? Date: Wed, 19 Nov 2003 16:49:32 -0500 To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.606) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Nov 19, 2003, at 2:05 PM, Paul Vixie wrote: >> ... >> off topic for Q21 (re: dnssec rrs): >> In a way, yes. NSEC RRs could be queried for the information they do >> contain, since they contain more non-security information than >> RRSIGs. I >> can imagine a scenario where a application may want to issue NSEC >> queries >> instead of "name. IN ANY" queries, for example. An RRSIG isn't >> that >> informative without the RR set it covers. A NSEC RR contains some >> information that could be used in a non-DNSSEC manner. > > let me emphasize what i mean by metadata. i'd like to see NSEC, RRSIG, > and DNSKEY treated more like AXFR and IXFR, such that one could never > query for them directly. their only existence should be as part of > zone > transfers or responses containing signed data. This is appropriate for the RRSIG and an explicit query for RRSIG has the subtyping problem (and related TTL problem, etc.) This NSEC RR as metadata also makes sense to me. Note that if an NSEC RR is missing from a response, the resolver doesn't usually what QNAME to query anyway. So calling this metadata that could never be queried directly is not much of a loss. Note however this view directly contradicts the current protocol draft text and says explicit query for NSEC is a MUST. Section 4 of protocol says: A security-aware resolver MUST attempt to retrieve a missing NSEC RR which the resolver needs to authenticate a NODATA response. In general it is not possible for a resolver to retrieve missing NSEC RRs, since the resolver will have no way of knowing the owner name of the missing NSEC RR, but in the specific case of a NODATA response, the resolver does know the name of the missing NSEC RR, and must therefore attempt to retrieve it. I disagree that DNSKEY should be treated as metadata. There are times when an explicit query for a DNSKEY is required and there is no ambiguity about subtyping/query name/whatever. Explicit queries for DNSKEY and DS are needed in my view. Dan -- to unsubscribe send a message to namedroppers-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 Nov 19 17:23:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18448 for ; Wed, 19 Nov 2003 17:23:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMafF-000I9S-Vd for namedroppers-data@psg.com; Wed, 19 Nov 2003 22:19:09 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMaf3-000I8k-Kb for namedroppers@ops.ietf.org; Wed, 19 Nov 2003 22:18:57 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 4EE9C13960 for ; Wed, 19 Nov 2003 22:18:57 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Q-21: Can NSEC records in the cache be re-used? In-Reply-To: Message from Daniel Massey of "Wed, 19 Nov 2003 16:49:32 EST." <425BB8AA-1ADA-11D8-989D-000393C783A2@isi.edu> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 19 Nov 2003 22:18:57 +0000 Message-Id: <20031119221857.4EE9C13960@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I disagree that DNSKEY should be treated as metadata. There are times when > an explicit query for a DNSKEY is required and there is no ambiguity about > subtyping/query name/whatever. Explicit queries for DNSKEY and DS are > needed in my view. ok by me. -- to unsubscribe send a message to namedroppers-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 Nov 19 22:51:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02140 for ; Wed, 19 Nov 2003 22:51:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMfiO-0007Tn-0t for namedroppers-data@psg.com; Thu, 20 Nov 2003 03:42:44 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMfiB-0007TP-V3 for namedroppers@ops.ietf.org; Thu, 20 Nov 2003 03:42:32 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id hAK3eK2a005991 for ; Wed, 19 Nov 2003 22:40:20 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAPFaWSl; Wed, 19 Nov 03 22:40:19 -0500 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id hAK3f9EH001724 for ; Wed, 19 Nov 2003 22:41:10 -0500 (EST) Date: Wed, 19 Nov 2003 22:41:09 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org Subject: Re: Q-21: Can NSEC records in the cache be re-used? In-Reply-To: <425BB8AA-1ADA-11D8-989D-000393C783A2@isi.edu> Message-ID: References: <20031119190517.4DB811396E@sa.vix.com> <425BB8AA-1ADA-11D8-989D-000393C783A2@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 19 Nov 2003, Daniel Massey wrote: > This NSEC RR as metadata also makes sense to me. Note that if an NSEC > RR is missing from a response, the resolver doesn't usually what QNAME > to query anyway. So calling this metadata that could never be queried > directly is not much of a loss. I'm forgetting how we resolved the RRSIG(NSEC) truncation problem: is it still possible to get an NSEC but not the RRSIG(NSEC)? If so, then querying for NSEC is the most efficient way (presumably) to get RRSIG(NSEC). Either way, you'd need to query for RRSIG or NSEC. (This is why I wanted the NSEC included, even if RRSIG(NSEC) didn't fit -- at least then you know what NSEC to ask for.) > Explicit queries for DNSKEY and DS are needed in my view. Concur. If one server is authoritative for both parent and child, a DS record will not be returned in response to a random query in the child zone. Will it be returned in response to an NS query for the zone cut? If not, then explicit DS queries are needed And if we want to change that, section 2.2.1.2 of the DS draft, which discusses the grandparent problem, includes a QTYPE=DS example. -- 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 Nov 20 04:35:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26589 for ; Thu, 20 Nov 2003 04:35:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMl6y-000Mhi-Kk for namedroppers-data@psg.com; Thu, 20 Nov 2003 09:28:28 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMl6e-000Mga-4f for namedroppers@ops.ietf.org; Thu, 20 Nov 2003 09:28:08 +0000 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id hAK9Rmg00197; Thu, 20 Nov 2003 16:27:53 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id hAK9Rcu09403; Thu, 20 Nov 2003 16:27:39 +0700 (ICT) From: Robert Elz To: Paul Vixie cc: namedroppers@ops.ietf.org Subject: Re: Issue: Add a new QTYPE In-Reply-To: <20031119193138.1535B1396D@sa.vix.com> References: <20031119193138.1535B1396D@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 20 Nov 2003 16:27:38 +0700 Message-ID: <19642.1069320458@munnari.OZ.AU> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Wed, 19 Nov 2003 19:31:38 +0000 From: Paul Vixie Message-ID: <20031119193138.1535B1396D@sa.vix.com> I actually believe that Christian's suggestion is a good one. | isc has sometimes been accused of "legislating from the bench" by using | the power of the bind installed base to get things into the protocols | that ietf did not otherwise think was a good idea. But this isn't that - no-one is actually saying that including A with AAAA query isn't a good idea, what is being said is that legislating that it must happen is not a good idea. There isn't a lot about the additional section in the RFCs really, most of what is there is an indication of what data should be added (A when doing an NS or MX lookup, for example). There isn't anything which says what may not be there. 1035 says about the section just ... the additional records section contains RRs which relate to the query, but are not strictly answers for the question. I think it is entirely reasonable to claim that A records relate to an AAAA query (and AAAA records relate to an A query), and simply include them - if the server author believes the additional information will be useful. We don't want to legislate it, because then you'd have to keep doing it, long after it stopped being useful. Simply doing it allows you to simply stop doing it either when it is determined to not be useful (or no longer be useful) without having to wait years for some IETF working group to create a new RFC and remove the "AAAA causes A additional section processing" rule. As an additional example, if anyone actually used WKS records for anything, it would be entirely reasonable to include WKS as additional information in any A (or AAAA) lookup - allow the client to determine what services are supported at the host they're considering contacting, so they can avoid sending a SYN to a port that the server owner has stated in the WKS has no server listening. Of course, no-one actually uses WKS, so this would be an utter waste of time and bytes - but back in the early days when WKS was considered a good thing, this would be been entirely reasonable for a server to have done - the available port information is clearly relevant to many address lookups. If some RFC had said to do that, I suspect that BIND would still be adding WKS in the additional section (assuming they exist in the zone of course), even though everyone knows that no client uses WKS records for anything, and that bothering to send them is pointless. | we won't be doing | that here. unless there's consensus that adding A RR's as additional | data for AAAA responses (empty or not) is non-harmful, it won't happen, | or at least, it won't happen in bind. I don't think anyone is claiming it is harmful, so I think you can just about take that as a consensus already. What some of us don't want to do is actually tell people that they should do this, or suggest to any client that they can actually expect it to happen. Just allow the A to land in the local cache when the AAAA lookup is done, making a later AAAA query much quicker. I don't see that hurting, regardless of whether ANCOUNT==0 or ANCOUNT>0 in the response. In another message you said ... | for it to be a short term hack in need of eventual eradication, there would | have to be a large difference in expected lifetime between "names for which | A RR's exist" and "clients who need A RR's". i think that those two | lifetimes are in the same rough order of magnitude, and that by the time | you'd be thinking of eradicating it because the additional data wasn't | generally useful, the data itself would go into end-of-life. I believe that one possible scenario (not necessarily the one that will happen, but certainly one possibility, that we need to allow for) is that eventually all the backbones, will be IPv6 alone, and all hosts that matter at end sites will have IPv6 enabled (essentially we'd have a complete IPv6 net). However, I expect IPv4 hosts to still be quite common in appliance type devices (old ones perhaps) - say switches, bridges, ... for quite a long time - as long as they are still working just fine, and so no replacements needed. Those things generally need only be accessed locally - which is fortunate for this. To do that, I'd expect local IPv4 routing to still exist inside end sites (and even private inside transit sites) long after the backbone has stopped routing any IPv4 addresses. In effect, the entire IPv4 address space will have moved into the 1918 class. If we reach that state, then we could simply allow people to populate their local DNS with A records for those hosts that are IPv4 only, and perhaps for a few servers that they need to be able to contact. As long as everyone (those ancient hosts excluded of course) does AAAA lookups first, and attempts an A lookup only if the AAAA fails (NODATA), then all this works, without needing any two faced DNS (or DNS views, or anything else as ugly) to support it. But at this point we most certainly do not want to include A records with the AAAA responses. This is easy if it is OK to simply install a DNS server that doesn't do that - much harder if there's an RFC out there somewhere that says that A additional records in AAAA answers should be done, and consequently all DNS servers do that. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Nov 20 07:44:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02120 for ; Thu, 20 Nov 2003 07:44:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMo4w-0005hv-Gx for namedroppers-data@psg.com; Thu, 20 Nov 2003 12:38:34 +0000 Received: from [129.6.16.93] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMo4k-0005hX-62 for namedroppers@ops.ietf.org; Thu, 20 Nov 2003 12:38:22 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id hAKCcB18028012; Thu, 20 Nov 2003 07:38:12 -0500 (EST) Message-ID: <009801c3af63$2a4a6e90$b9370681@barnacle> From: "Scott Rose" To: "Samuel Weiler" , References: <20031119190517.4DB811396E@sa.vix.com> <425BB8AA-1ADA-11D8-989D-000393C783A2@isi.edu> Subject: Re: Q-21: Can NSEC records in the cache be re-used? Date: Thu, 20 Nov 2003 07:38:13 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Samuel Weiler" > On Wed, 19 Nov 2003, Daniel Massey wrote: > > > This NSEC RR as metadata also makes sense to me. Note that if an NSEC > > RR is missing from a response, the resolver doesn't usually what QNAME > > to query anyway. So calling this metadata that could never be queried > > directly is not much of a loss. > > I'm forgetting how we resolved the RRSIG(NSEC) truncation problem: > is it still possible to get an NSEC but not the RRSIG(NSEC)? If so, > then querying for NSEC is the most efficient way (presumably) to get > RRSIG(NSEC). Either way, you'd need to query for RRSIG or NSEC. (This > is why I wanted the NSEC included, even if RRSIG(NSEC) didn't fit -- > at least then you know what NSEC to ask for.) > Are you talking about the NSEC and RRSIG(NSEC) in the authority section in a negative response? The protocol document states that they MUST be included together. If the RRSIG caused truncation, the TC bit is set, and the message is truncated like traditional DNS. I think we eliminated almost every case where a resolver would have the RRset but not the RRSIG. This was on purpose to avoid a query for type RRSIG. Scott > > Explicit queries for DNSKEY and DS are needed in my view. > > Concur. > > If one server is authoritative for both parent and child, a DS record > will not be returned in response to a random query in the child zone. > Will it be returned in response to an NS query for the zone cut? If > not, then explicit DS queries are needed > > And if we want to change that, section 2.2.1.2 of the DS draft, which > discusses the grandparent problem, includes a QTYPE=DS example. > > -- 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: > -- to unsubscribe send a message to namedroppers-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 Nov 20 15:16:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23132 for ; Thu, 20 Nov 2003 15:16:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMv1k-0006et-AQ for namedroppers-data@psg.com; Thu, 20 Nov 2003 20:03:44 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMv11-0006bN-TZ for namedroppers@ops.ietf.org; Thu, 20 Nov 2003 20:02:59 +0000 Received: by sa.vix.com (Postfix, from userid 716) id 676BD13969; Thu, 20 Nov 2003 20:02:59 +0000 (GMT) To: namedroppers@ops.ietf.org Subject: Re: Issue: Add a new QTYPE References: <20031119193138.1535B1396D@sa.vix.com> From: Paul Vixie Date: 20 Nov 2003 20:02:59 +0000 In-Reply-To: Message-ID: Lines: 21 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Robert Elz writes: > ... > I think it is entirely reasonable to claim that A records relate > to an AAAA query (and AAAA records relate to an A query), and simply > include them - if the server author believes the additional information > will be useful. > > We don't want to legislate it, because then you'd have to keep doing it, > long after it stopped being useful. Simply doing it allows you to > simply stop doing it either when it is determined to not be useful (or > no longer be useful) without having to wait years for some IETF working > group to create a new RFC and remove the "AAAA causes A additional section > processing" rule. > ... and yet if bind is the only implementation who does it, it won't have much impact. so how about instead of legislating it, we (namedroppers) authorize it as an optional practice, and perhaps recommend that it be configurable? -- Paul Vixie -- to unsubscribe send a message to namedroppers-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 Nov 21 15:31:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01077 for ; Fri, 21 Nov 2003 15:31:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ANHnK-0005rV-8g for namedroppers-data@psg.com; Fri, 21 Nov 2003 20:22:22 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1ANHn6-0005qi-Ut for namedroppers@ops.ietf.org; Fri, 21 Nov 2003 20:22:10 +0000 Received: (qmail 96427 invoked by uid 1016); 21 Nov 2003 20:22:24 -0000 Date: 21 Nov 2003 20:22:24 -0000 Message-ID: <20031121202224.96426.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: Issue: Add a new QTYPE References: <8634B809B90D6E4AACA4AB0562A1F072045DE7@bellnet-mail3.sbell.com.cn> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-1.5 required=5.0 tests=BAYES_01 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This circle of problems would never have occurred if IPv6 addresses had simply been returned as 16-byte A records. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Nov 21 16:20:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03340 for ; Fri, 21 Nov 2003 16:20:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ANIc1-0008rT-Mv for namedroppers-data@psg.com; Fri, 21 Nov 2003 21:14:45 +0000 Received: from [205.150.200.166] (helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ANIbo-0008r1-23 for namedroppers@ops.ietf.org; Fri, 21 Nov 2003 21:14:32 +0000 Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hALLEUt21388 for ; Fri, 21 Nov 2003 16:14:30 -0500 (EST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hALLHji25384 for ; Fri, 21 Nov 2003 16:17:45 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id hALLCB3g009505 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 21 Nov 2003 16:12:12 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id hALLCAa3009501 for ; Fri, 21 Nov 2003 16:12:10 -0500 To: namedroppers@ops.ietf.org Subject: Re: Issue: Add a new QTYPE In-reply-to: Your message of "Wed, 19 Nov 2003 20:12:42 +0100." <200311191912.hAJJCgT26670@grimsvotn.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 21 Nov 2003 16:12:09 -0500 Message-ID: <9500.1069449129@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I'd rather that we just defined a QTYPE of "all" which just returns everything. Given IPSECKEY and SSHKEY and other possible stuff, this just makes sense to me. Particularly for the client stub resolver to do. Special rules about A/AAAA just seem short-sighted to me. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP75/p4qHRg3pndX9AQH55QP9EwBO7wHE6AmenQC9vW7Vj8KTUtZCtyp3 au0NIymKngRVYd11ElK+msWFXXEzy75SOeJdnlbPayBdaXKp8Jm3k3X7jykP0YrR Jju18FQqkvQ4JsGg7xmeZnMTYLz+J1u7UMwkOAPuoaBCVRkHMBK7nwsxvYtwPV71 DqX7QawJlD0= =FAZT -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Nov 21 18:17:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11723 for ; Fri, 21 Nov 2003 18:17:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ANKRm-000Ece-Gf for namedroppers-data@psg.com; Fri, 21 Nov 2003 23:12:18 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ANKRa-000EbV-4L for namedroppers@ops.ietf.org; Fri, 21 Nov 2003 23:12:06 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id E53C313956 for ; Fri, 21 Nov 2003 23:12:05 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Issue: Add a new QTYPE In-Reply-To: Message from Michael Richardson of "Fri, 21 Nov 2003 16:12:09 EST." <9500.1069449129@marajade.sandelman.ottawa.on.ca> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 21 Nov 2003 23:12:05 +0000 Message-Id: <20031121231205.E53C313956@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I'd rather that we just defined a QTYPE of "all" which just returns > everything. Given IPSECKEY and SSHKEY and other possible stuff, this > just makes sense to me. Particularly for the client stub resolver to do. > > Special rules about A/AAAA just seem short-sighted to me. check the working group minutes from DNSIND, where an EDNS1 proposal was shot down on the basis of complexity around this exact issue. if you think we're ready to move forward on multiple qtype matches where the cache may have only seen one qtype even though others exist, such that an RRD flag is required to force a fetch against the authority server, then you're living in a dream world. -- to unsubscribe send a message to namedroppers-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 Nov 21 18:55:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12772 for ; Fri, 21 Nov 2003 18:55:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ANL49-000GWz-LO for namedroppers-data@psg.com; Fri, 21 Nov 2003 23:51:57 +0000 Received: from [129.9.82.74] (helo=fxodpr13.extra.daimlerchrysler.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ANL3x-000GWl-9r for namedroppers@ops.ietf.org; Fri, 21 Nov 2003 23:51:45 +0000 Received: (from uucp@localhost) by fxodpr13.extra.daimlerchrysler.com (8.12.8/8.9.0) id hALNphi1017536 for ; Fri, 21 Nov 2003 18:51:43 -0500 (EST) Received: from unknown(53.231.71.24) by fxodpr13.extra.daimlerchrysler.com via csmap (V6.0) id srcAAAiqa4pI; Fri, 21 Nov 03 18:51:43 -0500 Received: from odconpr2-hme0.oddc.chrysler.com ([127.0.0.1]) by odconpr2-hme0.oddc.chrysler.com (Mail-Gear 2.0.0 bld 66) with SMTP id M2003112118514229923 for ; Fri, 21 Nov 2003 18:51:43 -0500 Received: from shmrspr2-hme0.shdc.chrysler.com ([129.9.145.240]) by odconpr2-hme0.oddc.chrysler.com (SAVSMTP 3.1.1.32) with SMTP id M2003112118514213089 for ; Fri, 21 Nov 2003 18:51:42 -0500 Received: from wokcdts1.is.chrysler.com (wokcdts1.is.chrysler.com [53.230.102.164]) by shmrspr2-hme0.shdc.chrysler.com (8.12.10/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id hALNpgCO017795 for ; Fri, 21 Nov 2003 18:51:42 -0500 (EST) Received: from daimlerchrysler.com (wokcdts1.is.chrysler.com [53.230.102.164]) by wokcdts1.is.chrysler.com (8.12.10/8.9.1) with ESMTP id hALNpAhp008527 for ; Fri, 21 Nov 2003 18:51:10 -0500 (EST) Message-ID: <3FBEA4EE.3060504@daimlerchrysler.com> Date: Fri, 21 Nov 2003 18:51:10 -0500 From: Kevin Darcy User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: Issue: Add a new QTYPE References: <9500.1069449129@marajade.sandelman.ottawa.on.ca> In-Reply-To: <9500.1069449129@marajade.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Michael Richardson wrote: >-----BEGIN PGP SIGNED MESSAGE----- > > >I'd rather that we just defined a QTYPE of "all" which just returns >everything. Given IPSECKEY and SSHKEY and other possible stuff, this >just makes sense to me. Particularly for the client stub resolver to do. > >Special rules about A/AAAA just seem short-sighted to me. > I tend to agree. We already have QTYPE=*, but it has been rendered unreliable because BIND and AFAIK most other implementations never bother recursing for QTYPE=* queries (even as they advertise the RA bit to the client, natch). Instead of a new QTYPE, perhaps we just need to tighten up the specs to require recursive resolvers to recurse for QTYPE=* queries, when necessary (i.e. whenever they are unable to synthesize an answer from the cached results of a previous QTYPE=* query). Whatever resource/capacity reasons, if any, went into the original decisions to emasculate QTYPE=* are probably mooted by EDNS0. -Kevin -- to unsubscribe send a message to namedroppers-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 Nov 21 19:24:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13573 for ; Fri, 21 Nov 2003 19:24:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ANLW5-000I41-RC for namedroppers-data@psg.com; Sat, 22 Nov 2003 00:20:49 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1ANLVr-000I2S-BC for namedroppers@ops.ietf.org; Sat, 22 Nov 2003 00:20:35 +0000 Received: (qmail 91485 invoked by uid 1016); 22 Nov 2003 00:20:08 -0000 Date: 22 Nov 2003 00:20:08 -0000 Message-ID: <20031122002008.91484.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: Issue: Add a new QTYPE References: <9500.1069449129@marajade.sandelman.ottawa.on.ca> <3FBEA4EE.3060504@daimlerchrysler.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-3.4 required=5.0 tests=BAYES_00,NO_OBLIGATION autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Kevin Darcy writes: > We already have QTYPE=*, but it has been rendered unreliable because BIND BIND is under no obligation to support your delusions regarding QTYPE=*. RFC 1034, section 6.2.2, has a clear example of a cache providing _some_ of the SRI-NIC.ARPA records in response to a SRI-NIC.ARPA QTYPE=* query. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Nov 21 20:59:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15885 for ; Fri, 21 Nov 2003 20:59:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ANMww-000NJE-RE for namedroppers-data@psg.com; Sat, 22 Nov 2003 01:52:38 +0000 Received: from [129.9.80.165] (helo=fxshpr08.extra.daimlerchrysler.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ANMwl-000NIl-0I for namedroppers@ops.ietf.org; Sat, 22 Nov 2003 01:52:27 +0000 Received: (from uucp@localhost) by fxshpr08.extra.daimlerchrysler.com (8.12.8/8.9.0) id hAM1lQ97014677 for ; Fri, 21 Nov 2003 20:47:26 -0500 (EST) Received: from nodnsquery(129.9.147.104) by fxshpr08.extra.daimlerchrysler.com via csmap (V6.0) id srcAAAEoaGQC; Fri, 21 Nov 03 20:47:26 -0500 Received: from shconpr2-hme0.shdc.chrysler.com ([127.0.0.1]) by shconpr2-hme0.shdc.chrysler.com (Mail-Gear 2.0.0 bld 66) with SMTP id M2003112120522516304 for ; Fri, 21 Nov 2003 20:52:25 -0500 Received: from odmrspr2-hme0.oddc.chrysler.com ([53.231.2.113]) by shconpr2-hme0.shdc.chrysler.com (SAVSMTP 3.1.1.32) with SMTP id M2003112120522523619 for ; Fri, 21 Nov 2003 20:52:25 -0500 Received: from wokcdts1.is.chrysler.com (wokcdts1.is.chrysler.com [53.230.102.164]) by odmrspr2-hme0.oddc.chrysler.com (8.12.10/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id hAM1qPvl020664 for ; Fri, 21 Nov 2003 20:52:25 -0500 (EST) Received: from daimlerchrysler.com (wokcdts1.is.chrysler.com [53.230.102.164]) by wokcdts1.is.chrysler.com (8.12.10/8.9.1) with ESMTP id hAM1prhp009213 for ; Fri, 21 Nov 2003 20:51:53 -0500 (EST) Message-ID: <3FBEC139.70400@daimlerchrysler.com> Date: Fri, 21 Nov 2003 20:51:53 -0500 From: Kevin Darcy User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: Issue: Add a new QTYPE References: <9500.1069449129@marajade.sandelman.ottawa.on.ca> <3FBEA4EE.3060504@daimlerchrysler.com> <20031122002008.91484.qmail@cr.yp.to> In-Reply-To: <20031122002008.91484.qmail@cr.yp.to> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-3.4 required=5.0 tests=BAYES_00,NO_OBLIGATION autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit D. J. Bernstein wrote: >Kevin Darcy writes: > > >>We already have QTYPE=*, but it has been rendered unreliable because BIND >> >> > >BIND is under no obligation to support your delusions regarding QTYPE=*. >RFC 1034, section 6.2.2, has a clear example of a cache providing _some_ >of the SRI-NIC.ARPA records in response to a SRI-NIC.ARPA QTYPE=* query. > In response to a *non-recursive* (RD=0) query, yes (see the second sentence of the Section 6.2 intro). That doesn't disprove my point in the slightest. I certainly wouldn't expect a resolver to provide recursion that wasn't requested in the first place... - Kevin -- to unsubscribe send a message to namedroppers-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 Nov 21 21:35:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16591 for ; Fri, 21 Nov 2003 21:35:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ANNYA-000P2r-2s for namedroppers-data@psg.com; Sat, 22 Nov 2003 02:31:06 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ANNXy-000P2K-Bm for namedroppers@ops.ietf.org; Sat, 22 Nov 2003 02:30:54 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 299E81395D for ; Sat, 22 Nov 2003 02:30:54 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Issue: Add a new QTYPE In-Reply-To: Message from Kevin Darcy of "Fri, 21 Nov 2003 18:51:10 EST." <3FBEA4EE.3060504@daimlerchrysler.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sat, 22 Nov 2003 02:30:54 +0000 Message-Id: <20031122023054.299E81395D@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > >Special rules about A/AAAA just seem short-sighted to me. > > I tend to agree. We already have QTYPE=*, but it has been rendered > unreliable because BIND and AFAIK most other implementations never bother > recursing for QTYPE=* queries (even as they advertise the RA bit to the > client, natch). that's just not true. if a nameserver (bind or any other recursive server) gets a QTYPE=* query and it has no rrsets cached for that QNAME then it will recurse. however, if it has learned an rrset it will return that rrset even though an authority server might return additional rrsets that the recursive server has not had occasion to see or store. > Instead of a new QTYPE, perhaps we just need to tighten up the specs > to require recursive resolvers to recurse for QTYPE=* queries, when > necessary (i.e. whenever they are unable to synthesize an answer from > the cached results of a previous QTYPE=* query). > > Whatever resource/capacity reasons, if any, went into the original > decisions to emasculate QTYPE=* are probably mooted by EDNS0. it wasn't resource/capacity, but rather complexity, which took this functionality off the table. see http://sa.vix.com/~vixie/edns1.txt, and the working group minutes from DNSIND. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Nov 22 00:27:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20769 for ; Sat, 22 Nov 2003 00:27:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ANQEj-0006GH-6E for namedroppers-data@psg.com; Sat, 22 Nov 2003 05:23:13 +0000 Received: from [129.9.80.165] (helo=fxshpr08.extra.daimlerchrysler.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ANQEW-0006Fy-6D for namedroppers@ops.ietf.org; Sat, 22 Nov 2003 05:23:00 +0000 Received: (from uucp@localhost) by fxshpr08.extra.daimlerchrysler.com (8.12.8/8.9.0) id hAM5HxU4019958 for ; Sat, 22 Nov 2003 00:17:59 -0500 (EST) Received: from nodnsquery(129.9.147.104) by fxshpr08.extra.daimlerchrysler.com via csmap (V6.0) id srcAAAWMaO_M; Sat, 22 Nov 03 00:17:59 -0500 Received: from shconpr2-hme0.shdc.chrysler.com ([127.0.0.1]) by shconpr2-hme0.shdc.chrysler.com (Mail-Gear 2.0.0 bld 66) with SMTP id M2003112200225908379 for ; Sat, 22 Nov 2003 00:22:59 -0500 Received: from shmrspr2-hme0.shdc.chrysler.com ([129.9.145.240]) by shconpr2-hme0.shdc.chrysler.com (SAVSMTP 3.1.1.32) with SMTP id M2003112200225824494 for ; Sat, 22 Nov 2003 00:22:58 -0500 Received: from wokcdts1.is.chrysler.com (wokcdts1.is.chrysler.com [53.230.102.164]) by shmrspr2-hme0.shdc.chrysler.com (8.12.10/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id hAM5MwCO016092 for ; Sat, 22 Nov 2003 00:22:58 -0500 (EST) Received: from daimlerchrysler.com (wokcdts1.is.chrysler.com [53.230.102.164]) by wokcdts1.is.chrysler.com (8.12.10/8.9.1) with ESMTP id hAM5MRhp010879 for ; Sat, 22 Nov 2003 00:22:27 -0500 (EST) Message-ID: <3FBEF293.5010409@daimlerchrysler.com> Date: Sat, 22 Nov 2003 00:22:27 -0500 From: Kevin Darcy User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: Issue: Add a new QTYPE References: <20031122023054.299E81395D@sa.vix.com> In-Reply-To: <20031122023054.299E81395D@sa.vix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: >>>Special rules about A/AAAA just seem short-sighted to me. >>> >>> >>I tend to agree. We already have QTYPE=*, but it has been rendered >>unreliable because BIND and AFAIK most other implementations never bother >>recursing for QTYPE=* queries (even as they advertise the RA bit to the >>client, natch). >> >> > >that's just not true. if a nameserver (bind or any other recursive server) >gets a QTYPE=* query and it has no rrsets cached for that QNAME then it will >recurse. > Yes, you're correct. My statement swept too broadly. Recursion will happen if nothing is cached for the name. >however, if it has learned an rrset it will return that rrset even >though an authority server might return additional rrsets that the recursive >server has not had occasion to see or store. > Right, and _this_ is the part that makes QTYPE=* queries too unreliable, since the query results might vary depending on the vicissitudes of whatever the caching server happens to have cached at what time. Granted, there will always be an irreducible amount of "unreliability" whenever one takes caching into consideration, but this should not IMO extend beyond the TTL constraints of any *given* RRset. What the current behavior does is extend the unreliablity of QTYPE=* queries *across* RRsets of differing TTL scales (i.e. just because an RRset with a high TTL sits in a cache, it inhibits the resolver's ability to fetch other RRsets with possibly much smaller TTLs in response to QTYPE=* queries of the same name). IMO this raises the unreliability of the QTYPE to a whole new level, and I think it's why QTYPE=* has been abandoned for the most part (e.g. by sendmail), even in situations where it could be a useful optimization. >Instead of a new QTYPE, perhaps we just need to tighten up the specs >to require recursive resolvers to recurse for QTYPE=* queries, when >necessary (i.e. whenever they are unable to synthesize an answer from >the cached results of a previous QTYPE=* query). > >Whatever resource/capacity reasons, if any, went into the original >decisions to emasculate QTYPE=* are probably mooted by EDNS0. > > > >it wasn't resource/capacity, but rather complexity, which took this >functionality off the table. see http://sa.vix.com/~vixie/edns1.txt, >and the working group minutes from DNSIND. > I did dig back through the archives, and saw a message from you (<20020823012804.B594528B6C@as.vix.com >) admitting that QTYPE=* wasn't really germane ("it was a debugging wish rather than an operational expectation") to the RRD-flag part of the EDNS1 proposal, and a statement of intention that you were going to remove that reference from the draft. There was, however, no subsequent published revision of the draft, so the verbiage still remains. As far as I can tell, there has been no attempt to clarify QTYPE=* recursivity independently of the EDNS1 proposal. Even having read that old thread, I still don't see the insurmountable complexity, in protocol terms, in requiring resolvers to honor their recursion obligations with respect to QTYPE=* queries. Either you can respond from cached data, or you recurse, same as for any other QTYPE. The only complexity that comes to mind is in the implementation's housekeeping mechanisms i.e. it needs to keep an independent accounting of QTYPE=* queries in order to confirm whether and when synthesis-from-cache for subsequent QTYPE=* queries of the same name is legitimate. But that is, as they say, merely a matter of programming... (In the relatively unusual case where a previously-unknown RRset gets into the cache before the most recent QTYPE=* pseudo-cache-entry for the same name expires (with its expiration to be based on the lowest associated RRset's TTL), I'd say just take the conservative approach and flush the obviously-invalid pseudo-cache-entry. Folks who rapidly create and delete whole RRsets on the fly will just have to tolerate the extra traffic this will generate for QTYPE=* queries) - Kevin -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Nov 22 04:15:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07315 for ; Sat, 22 Nov 2003 04:15:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ANThz-000FNU-O5 for namedroppers-data@psg.com; Sat, 22 Nov 2003 09:05:39 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1ANThn-000FMR-DL for namedroppers@ops.ietf.org; Sat, 22 Nov 2003 09:05:27 +0000 Received: (qmail 7645 invoked from network); 22 Nov 2003 09:15:47 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 22 Nov 2003 09:15:47 -0000 Message-ID: <3FBF274B.9000206@necom830.hpcl.titech.ac.jp> Date: Sat, 22 Nov 2003 18:07:23 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Kevin Darcy CC: namedroppers@ops.ietf.org Subject: Re: Issue: Add a new QTYPE References: <20031122023054.299E81395D@sa.vix.com> <3FBEF293.5010409@daimlerchrysler.com> In-Reply-To: <3FBEF293.5010409@daimlerchrysler.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kevin Darcy; >> that's just not true. if a nameserver (bind or any other recursive >> server) >> gets a QTYPE=* query and it has no rrsets cached for that QNAME then >> it will >> recurse. > > Yes, you're correct. My statement swept too broadly. Recursion will > happen if nothing is cached for the name. What happens if an answer of an empty set for a previous non-wildcard query is cached for the name? Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Nov 22 11:38:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15664 for ; Sat, 22 Nov 2003 11:38:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ANaes-000CEO-HL for namedroppers-data@psg.com; Sat, 22 Nov 2003 16:30:54 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ANaeg-000CDm-4V for namedroppers@ops.ietf.org; Sat, 22 Nov 2003 16:30:42 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 83E6013966 for ; Sat, 22 Nov 2003 16:30:32 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Issue: Add a new QTYPE In-Reply-To: Message from Kevin Darcy of "Sat, 22 Nov 2003 00:22:27 EST." <3FBEF293.5010409@daimlerchrysler.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sat, 22 Nov 2003 16:30:32 +0000 Message-Id: <20031122163032.83E6013966@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ... IMO this raises the unreliability of the QTYPE to a whole new > level, and I think it's why QTYPE=* has been abandoned for the most > part (e.g. by sendmail), even in situations where it could be a useful > optimization. sendmail was incorrect in its usage of QTYPE=* and when they "abandoned" it, it was to fix the bug in their code where they had used it at all. > > ... it wasn't resource/capacity, but rather complexity, which took > > this functionality off the table. see http://sa.vix.com/~vixie/edns1.txt > > and the working group minutes from DNSIND. > > I did dig back through the archives, and saw a message from you > > admitting that QTYPE=* wasn't really germane ("it was a debugging wish > rather than an operational expectation") to the RRD-flag part of the EDNS1 > proposal, and a statement of intention that you were going to remove that > reference from the draft. There was, however, no subsequent published > revision of the draft, so the verbiage still remains. the draft is expired. the DNSIND working group decided to scrap everything therein. my offer to pull out RRD was insufficient; the wg wanted the whole thing killed. > As far as I can tell, there has been no attempt to clarify QTYPE=* > recursivity independently of the EDNS1 proposal. there is no way to "clarify" QTYPE=* short of a protocol extension. the current behaviour is perfectly well understood and there are no incorrect implementations of it. there's no document quality issue around QTYPE=*, and all extant implementations are fully interoperable regarding QTYPE=*. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Nov 22 13:25:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18039 for ; Sat, 22 Nov 2003 13:25:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ANcKC-000Gul-Mk for namedroppers-data@psg.com; Sat, 22 Nov 2003 18:17:40 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ANcK1-000GuH-3y for namedroppers@ops.ietf.org; Sat, 22 Nov 2003 18:17:29 +0000 Received: by sa.vix.com (Postfix, from userid 716) id EC5441396B; Sat, 22 Nov 2003 18:17:28 +0000 (GMT) To: namedroppers@ops.ietf.org Subject: Re: Issue: Add a new QTYPE References: <20031122023054.299E81395D@sa.vix.com> <3FBEF293.5010409@daimlerchrysler.com> From: Paul Vixie Date: 22 Nov 2003 18:17:28 +0000 In-Reply-To: Message-ID: Lines: 10 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ... > What happens if an answer of an empty set for a previous non-wildcard > query is cached for the name? > Masataka Ohta this was one of the concerns expressed by the wg when it killed RRD and QDCOUNT>1. negative caching gets a LOT more complicated when the query that produced the cached result has to match the query being answered. -- Paul Vixie -- to unsubscribe send a message to namedroppers-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 Nov 24 00:23:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12137 for ; Mon, 24 Nov 2003 00:23:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AO92E-0009eN-5s for namedroppers-data@psg.com; Mon, 24 Nov 2003 05:13:18 +0000 Received: from [207.65.203.98] (helo=goose.ehsco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AO920-0009dB-HP for namedroppers@ops.ietf.org; Mon, 24 Nov 2003 05:13:04 +0000 Received: from [207.65.3.26] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 4.1.3) with ESMTP-TLS id 644715 for namedroppers@ops.ietf.org; Mon, 24 Nov 2003 02:58:46 -0600 Message-ID: <3FC1935C.8020101@ehsco.com> Date: Sun, 23 Nov 2003 23:13:00 -0600 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: indicating data/nodata simultaneously Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On the subject of trying to provide answer data along with an indicator that some other data does not exist... After some thinking, it seems like it would be pretty simple to patch the qtype=addr proposal to handle this. Since the original proposal already requires intermediary servers to chase down the A and AAAA RRsets to ensure that all of the data is being provided, supporting servers can already provide the necessary clues: if the question section of the response message shows qtype=addr, then any missing RRsets in the answer section are actually missing from the zone, or else they would have been found as part of the discovery process (in the case of authoritative servers responses, you'd even have proof positive by way of the A flag). So since we're that far already, really the only part that's actually missing here is to provide negative cache timers for the missing RRsets, so that the complete answer (including any known data as well as known missing data) can be cached and reused, without causing all subsequent queries to non-authoritative servers to re-query the authoritative servers to find out for sure. The easiest way to deal with this is to mimic the Type 1 NODATA response as described in RFC 2308. Specifically: 1) if the question section contains qtype=addr -and- 2) if the RCODE is set to NOERROR -and- 3) if the answer section is missing one or both of A/AAAA RRsets -and- 4) the authority section contains an SOA RR of the controlling zone -then- treat the answer as complete, and cache the provided and missing data according to the existing rules In that scenario, the full view of the data could be provided, cached, relayed and processed by any compliant system in the query path. The complexities start when the Type 2 and 3 NODATA responses are encountered in response to independent queries for one or both address types, as will particularly be the case with authoritative servers that don't support qtype=addr. Although it's possible to reuse some of the logic from RFC 2308 here, I think it might actually be easier to just require implementations to explicitly query for the SOA RR if they find themselves in this situation. The upside to this approach is that this would guarantee complete answers were formed and relayed throughout the query path. The downside is that a compliant caching server would have to generate three distinct queries if the chosen authoritative server doesn't support qtype=addr and doesn't provide a Type 1 NODATA response to either of the discrete A or AAAA lookups. However, since that approach would allow the negative data to be cached and relayed, this should in theory result in fewer overall queries than providing no hinting data whatsoever (the current situation), so even in the worst case it should still be cheaper than not provide any cachable hinting data. I can write this into an update of the draft unless anybody sees anything totally stupid about it. btw--the old qtype=addr draft expired long ago, but there's a copy online at http://www.ehsco.com/misc/draft-hall-qtype-addr-00.txt -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 24 15:31:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27276 for ; Mon, 24 Nov 2003 15:31:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AONEm-000B3E-CQ for namedroppers-data@psg.com; Mon, 24 Nov 2003 20:23:12 +0000 Received: from [207.65.203.98] (helo=goose.ehsco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AONEY-000B26-QR for namedroppers@ops.ietf.org; Mon, 24 Nov 2003 20:22:58 +0000 Received: from [207.65.3.26] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 4.1.3) with ESMTP-TLS id 644793 for namedroppers@ops.ietf.org; Mon, 24 Nov 2003 18:08:41 -0600 Message-ID: <3FC2689E.7000403@ehsco.com> Date: Mon, 24 Nov 2003 14:22:54 -0600 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: incorporating just-include; dealing with truncation Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Although I've argued against just-include-AAAA as a prima strategy (and for good reasons), that approach does have significant merit in those cases where A RRs would be included as additional data, but where AAAA RRs would not. Thus, even though I'm not backing that approach for all queries, I do plan on incorporating it into the updated qtype=addr draft as a secondary mechanism for use whenever another query would produce A RRs as additional data. This approach seems to recognize and incorporate the strengths of both models, but without mandating that the weaknesses of either model in isolation also be embraced as a cost of doing business. Specifically, I'm specifying that qtype=addr be provided as a way for dual-stack systems to request all of the addressing RRs defined for a target domain name, and also specifying a just-include algorithm that should be used with lookups that would produce A RRs as additional data. One of the sticky points that I raised about just-include has to do with message size, and what to do with truncated answer sets. What I'm going to propose here is that if only one of the addressing RRsets can fit in the message without causing truncation, favor the address type that matches the protocol used by the query. For example, if the query arrived via IPv4, then favor the A RRs in the answer and truncate the AAAA RRs if necessary. Similarly, if a query arrived via IPv6, then favor the AAAA RRs in the answer and truncate the A RRs if necessary. This rule would take effect whenever a response would include A RRs as additional data, such as responses to MX queries, glue data, and so forth. The nice thing about this approach is that it's transitional; as hosts are defined with single-stack addresses (either with IPv4 now, or IPv6 in the distant future), the focus naturally moves along towards the single addressing syntax in use, and the burden is (appropriately) at its highest as hosts are defined with dual-stack addresses. I've got a couple of relatively minor issues here. First of all, what should be done about the TC flag? Since this rule would only apply to additional data, the TC flag isn't mandatory (and has some associated costs) but it would be useful (and its absence would also have costs). On the one hand, if the TC flag is enabled for incomplete responses, then single-stack hosts may end up burning costs on TCP requeries for no meaningful data. On the other hand, if the TC is not enabled, then dual-stack hosts won't be able to tell that the target supports multiple address types. Since the planned algorithm favors the address family in use, however, this may not be so bad (EG, who cares if a dual-stack host doesn't learn about IPv4 addresses, if it wanted to use IPv6 addresses anyway). Of course, just because a particular client uses IPv6 for DNS lookups doesn't necessarily mean that all of the other applications on that host are capable of supporting IPv6, so the absence of the information can be critical. I can go either way on this, but I think that in general it would be easiest to disable TC in these responses, and put the onus on (the relatively newer) IPv6-aware resolvers to either issue followup requests for the missing data, or to use EDNS, or whatever. That seems to be easier than forcing legacy IPv4 resolvers to use TCP to get meaningless data. Secondary issue is procedural/administrative: since this algorithm will affect all of those scenarios where IPv4 address RRs are returned as additional data, does this document need to "update" all of those specs? -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 24 15:38:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28172 for ; Mon, 24 Nov 2003 15:38:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AONNX-000BYW-P9 for namedroppers-data@psg.com; Mon, 24 Nov 2003 20:32:15 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AONNJ-000BXc-9w for namedroppers@ops.ietf.org; Mon, 24 Nov 2003 20:32:01 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27369; Mon, 24 Nov 2003 15:31:45 -0500 (EST) Message-Id: <200311242031.PAA27369@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dns-threats-05.txt Date: Mon, 24 Nov 2003 15:31:45 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 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 : Threat Analysis Of The Domain Name System Author(s) : D. Atkins, R. Austein Filename : draft-ietf-dnsext-dns-threats-05.txt Pages : 15 Date : 2003-11-24 Although the DNS Security Extensions (DNSSEC) have been under development for most of the last decade, the IETF has never written down the specific set of threats against which DNSSEC is designed to protect. Among other drawbacks, this cart-before-the-horse situation has made it difficult to determine whether DNSSEC meets its design goals, since its design goals are not well specified. This note attempts to document some of the known threats to the DNS, and, in doing so, attempts to measure to what extent (if any) DNSSEC is a useful tool in defending against these threats. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-threats-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-dns-threats-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dns-threats-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-11-24152331.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dns-threats-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dns-threats-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-11-24152331.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Nov 24 22:45:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18947 for ; Mon, 24 Nov 2003 22:45:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOU0u-0009s8-90 for namedroppers-data@psg.com; Tue, 25 Nov 2003 03:37:20 +0000 Received: from [129.9.82.74] (helo=fxodpr13.extra.daimlerchrysler.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOU0h-0009rX-52 for namedroppers@ops.ietf.org; Tue, 25 Nov 2003 03:37:07 +0000 Received: (from uucp@localhost) by fxodpr13.extra.daimlerchrysler.com (8.12.8/8.9.0) id hAP3b6kX002393 for ; Mon, 24 Nov 2003 22:37:06 -0500 (EST) Received: from unknown(53.231.71.24) by fxodpr13.extra.daimlerchrysler.com via csmap (V6.0) id srcAAAmbaaRe; Mon, 24 Nov 03 22:37:06 -0500 Received: from odconpr2-hme0.oddc.chrysler.com ([127.0.0.1]) by odconpr2-hme0.oddc.chrysler.com (Mail-Gear 2.0.0 bld 66) with SMTP id M2003112422370507438 for ; Mon, 24 Nov 2003 22:37:05 -0500 Received: from odmrspr2-hme0.oddc.chrysler.com ([53.231.2.113]) by odconpr2-hme0.oddc.chrysler.com (SAVSMTP 3.1.1.32) with SMTP id M2003112422370511543 for ; Mon, 24 Nov 2003 22:37:05 -0500 Received: from wokcdts1.is.chrysler.com (wokcdts1.is.chrysler.com [53.230.102.164]) by odmrspr2-hme0.oddc.chrysler.com (8.12.10/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id hAP3b5qV021614 for ; Mon, 24 Nov 2003 22:37:05 -0500 (EST) Received: from daimlerchrysler.com (wokcdts1.is.chrysler.com [53.230.102.164]) by wokcdts1.is.chrysler.com (8.12.10/8.9.1) with ESMTP id hAP3aWhp000946 for ; Mon, 24 Nov 2003 22:36:33 -0500 (EST) Message-ID: <3FC2CE40.8000002@daimlerchrysler.com> Date: Mon, 24 Nov 2003 22:36:32 -0500 From: Kevin Darcy User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: Issue: Add a new QTYPE References: <20031122163032.83E6013966@sa.vix.com> In-Reply-To: <20031122163032.83E6013966@sa.vix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: >>... IMO this raises the unreliability of the QTYPE to a whole new >>level, and I think it's why QTYPE=* has been abandoned for the most >>part (e.g. by sendmail), even in situations where it could be a useful >>optimization. >> >> > >sendmail was incorrect in its usage of QTYPE=* and when they "abandoned" >it, it was to fix the bug in their code where they had used it at all. > > > >>>... it wasn't resource/capacity, but rather complexity, which took >>>this functionality off the table. see http://sa.vix.com/~vixie/edns1.txt >>>and the working group minutes from DNSIND. >>> >>> >>I did dig back through the archives, and saw a message from you >> >>admitting that QTYPE=* wasn't really germane ("it was a debugging wish >>rather than an operational expectation") to the RRD-flag part of the EDNS1 >>proposal, and a statement of intention that you were going to remove that >>reference from the draft. There was, however, no subsequent published >>revision of the draft, so the verbiage still remains. >> >> > >the draft is expired. the DNSIND working group decided to scrap everything >therein. my offer to pull out RRD was insufficient; the wg wanted the whole >thing killed. > > > >>As far as I can tell, there has been no attempt to clarify QTYPE=* >>recursivity independently of the EDNS1 proposal. >> >> > >there is no way to "clarify" QTYPE=* short of a protocol extension. the >current behaviour is perfectly well understood and there are no incorrect >implementations of it. there's no document quality issue around QTYPE=*, >and all extant implementations are fully interoperable regarding QTYPE=*. > Paul, The current behavior is fine as long as one puts on blinders with respect to correctness and completeness of answer content. In my opinion, giving out a known-incomplete answer to *any* query, when a complete answer is available via recursion and where recursion was both requested and its availability advertised, is a violation of the spirit if not the precise wording of the standards (and let's face it, RFC 1034&1035 leave a lot to the imagination wrt how QTYPE=* queries are actually supposed to work). Just as partial-RRset answers were outlawed in in RFC 2181, partial answers at owner-name level (i.e. with RRsets missing) should never IMO be returned to recursive QTYPE=* queries either. The fact that all extant implementations (arguably) violate the standard in the same, interoperable way does not mean the behavior is correct -- that is, after all, the defining difference between _de_facto_ standards and _de_jure_ ones. More importantly, a faithful implementation of QTYPE=* recursivity might rescue that QTYPE from its current state of dubious usefulness (at best) and/or near-obsolescence (at worst), and put an end to all of these new-metatype proposals without the overreaching that EDNS1 represented or was perceived to represent. I can understand why you'd be bitter about how EDNS1 turned out, but that doesn't mean a more modest approach, one that stays within the existing RFC 1034/1035 framework without requiring extensions, can't or shouldn't work. - Kevin -- to unsubscribe send a message to namedroppers-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 Nov 24 23:57:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20631 for ; Mon, 24 Nov 2003 23:57:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOVBw-000DlY-O6 for namedroppers-data@psg.com; Tue, 25 Nov 2003 04:52:48 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOVBj-000Dkw-Km for namedroppers@ops.ietf.org; Tue, 25 Nov 2003 04:52:35 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 37F171396F for ; Tue, 25 Nov 2003 04:52:35 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Issue: Add a new QTYPE In-Reply-To: Message from Kevin Darcy of "Mon, 24 Nov 2003 22:36:32 EST." <3FC2CE40.8000002@daimlerchrysler.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 25 Nov 2003 04:52:35 +0000 Message-Id: <20031125045235.37F171396F@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > >there is no way to "clarify" QTYPE=* short of a protocol extension. the > >current behaviour is perfectly well understood and there are no incorrect > >implementations of it. there's no document quality issue around QTYPE=*, > >and all extant implementations are fully interoperable regarding QTYPE=*. > > The current behavior is fine as long as one puts on blinders with > respect to correctness and completeness of answer content. In my opinion, > giving out a known-incomplete answer to *any* query, when a complete answer > is available via recursion and where recursion was both requested and its > availability advertised, is a violation of the spirit if not the precise > wording of the standards (and let's face it, RFC 1034&1035 leave a lot to > the imagination wrt how QTYPE=* queries are actually supposed to work). thanks for your sharing your opinion. here's mine. QTYPE=* is a wonderful debugging aid designed to let me find out what's in a middlebox cache, much better than successive RD=0 queries. > The fact that all extant implementations (arguably) violate the > standard in the same, interoperable way does not mean the behavior is > correct -- that is, after all, the defining difference between > _de_facto_ standards and _de_jure_ ones. the standard is completely clear on this topic. you might not agree with it but there is no possible reading of 1034/1035 that makes it acceptable to do anything other than return whatever partial results are in cache: | RFC 1034 Domain Concepts and Facilities November 1987 | | If a similar query was directed to two name servers which are not | authoritative for SRI-NIC.ARPA, the responses might be: | | +---------------------------------------------------+ | Header | OPCODE=SQUERY, RESPONSE | | +---------------------------------------------------+ | Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=* | | +---------------------------------------------------+ | Answer | SRI-NIC.ARPA. 12345 IN A 26.0.0.73 | | | A 10.0.0.51 | | +---------------------------------------------------+ | Authority | | | +---------------------------------------------------+ | Additional | | | +---------------------------------------------------+ | | and | | +---------------------------------------------------+ | Header | OPCODE=SQUERY, RESPONSE | | +---------------------------------------------------+ | Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=* | | +---------------------------------------------------+ | Answer | SRI-NIC.ARPA. 1290 IN HINFO DEC-2060 TOPS20 | | +---------------------------------------------------+ | Authority | | | +---------------------------------------------------+ | Additional | | | +---------------------------------------------------+ | | Neither of these answers have AA set, so neither response comes from | authoritative data. The different contents and different TTLs suggest | that the two servers cached data at different times, and that the first | server cached the response to a QTYPE=A query and the second cached the | response to a HINFO query. | | Mockapetris [Page 42] i dearly wish that every part of The Spec were as clear as this! > More importantly, a faithful implementation of QTYPE=* recursivity might > rescue that QTYPE from its current state of dubious usefulness (at best) > and/or near-obsolescence (at worst), and put an end to all of these > new-metatype proposals without the overreaching that EDNS1 represented or > was perceived to represent. I can understand why you'd be bitter about how > EDNS1 turned out, but that doesn't mean a more modest approach, one that > stays within the existing RFC 1034/1035 framework without requiring > extensions, can't or shouldn't work. it's not bitterness. it's that without a protocol change, there is no way for a requestor to signal that it desires "the new behaviour", nor any way for a responder to signal that it performed "the new behaviour." therefore even if the standard weren't clear on this point (but it is!) there would be no effective way to fix "the problem" (but there isn't one.) -- to unsubscribe send a message to namedroppers-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 Nov 25 13:14:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00209 for ; Tue, 25 Nov 2003 13:14:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOhYV-0004z1-VV for namedroppers-data@psg.com; Tue, 25 Nov 2003 18:04:55 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOhXL-0004tE-4t for namedroppers@ops.ietf.org; Tue, 25 Nov 2003 18:03:43 +0000 Received: from ENGILL.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id hAPI01gR009523 for ; Tue, 25 Nov 2003 13:00:02 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.0.0.22.2.20031125125949.02e2e708@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Tue, 25 Nov 2003 13:03:30 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: IETF-58 DNSEXT Draft minutes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,OPT_IN autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk These are the draft minutes, please send in comments/corrections ASAP. --------- DNSEXT WG meeting, November 13, 2003. Accompanying slide set is available in PDF at: https://www.ietf.org/proceedings/03nov/slides/dnsext-1.pdf Item 0: Agenda Administrivia 5 min Working Group Docs 5 min Call for Interop Report 5 min Wild Card Clarify discussion 10 min DNSSECbis Doc discussion 90 min Evidenced by the time allotted on the agenda, the predominate focus of the meeting is on the latest round of DNSSEC definition document, dnssec-intro, dnssec-records, and dnssec-protocol. The other burning issue to be discussed lies in the wcard-clarify draft, which, although not discussing DNSSEC itself, has altered some of the work needed to finish off DNSSEC. Item 1: Administrivia (Note all agenda items are accompanied by a slide set.) Minutes from the Vienna meeting (July 2003) were posted http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01541.html An issue tracker has been introduced to manage comments and changes to working group documents. The purpose is to make sure all changes corresponding to WG decisions are made and that all changes are because of WG decisions (consensus). One issue tracker instance is as https://roundup.machshav.com/dnsext/index document editors can choose to use others. Item 2: WG Documents All of this is in slides. Documents seeing recent activity (with the focus of the WG): wcard-clarify and the three DNSSECbis documents. Docs in final stages: mdns, tkey renewal, case insensitive clarifications Docs stalled: 2536bis and 2539bis, DSA and Diff-Hellman KEY RR algorithms At IESG: AXFR clarify, DS RR, type code roll, key signing bit, opt-in, dhc-id, dns threats, discovery, others? Item 3: Call for Interop Reports In the past decade, many documents have made it to Proposed Standard, but none have made it to Draft Standard. An important ingredient for draft standard is a demonstration and documentation of interoperability. The WG has many documents to promote from proposed to draft standards, and this is an open call for work in this area. One interoperability report is making it's way through the process. I think this is TSIG, no progress has been made recently. Question from the floor: where should folks focus? Answer: Milestones on the charter page list what's needed, sequencing can be adjusted. Item 4: wcard-clarify Discussion This document was begun in January, became a WG item during the March 2003 SF meetings, and made progress through the Vienna meeting in July. A change in editor was requested by the first editor and a new one, Robert Elz, has been installed. Remaining issues include: a) Cache use of unexpanded wild card records b) Use of the "*" label in the interior of a name c) Handling of a CNAME RR at a wild card name d) Handling of a NS RR at a wild card name e) Procedural question - split document between clarify an fix Discussion started with (e): room recommendation is to keep the document as one. (Originally the document treated pre and post DNSSEC, now it treats only pre-DNSSEC.) Even though it is "clarifications," adjustments to the original definition are to be considered and included. The rationale for not splitting is that if it were done, we'd have too many documents in the process. Issue (4a): RFC 1034 says that a cache must not make use of a wild card record. (As opposed to a wild card record in the authoritative date.) While it makes sense that a cache must not synthesize records from a cached wild card record (because the cache doesn't have enough information), there's little reason that a cache can't answer with the record if the QNAME is for the wild card exactly. (I.e., *.example. IN A 1.1.1.1 in cache could be used for a query of [*.example. IN A].) The room's proposal was to allow the cache to answer if the record was an exact match for the data, leaving the restriction of not allowing cache synthesis from the record. Issue (4b): Whether or not "*" can be in the middle of a name. There was no discussion in the room on this one. The basic issue is that the draft goes to great length to talk about how this is handled. Later on, someone noticed that 1034 discourages this. Although there is no sentiment to allow these names, nor is there any common use, if the names are barred as in 1034, then more rules are needed to specify what happens when they are (mistakenly?) seen. If the rules aren't specified then behavior is unpredicatable - perhaps in ways that don't matter very much. An older mail list discussion leaned toward staying with 1034's definition. Issue (4c): Whether CNAME's are "chase" has been the most significant issue in this work. As it stands now, a CNAME RR at a wild card means that the wild card only comes into play when the query is for the wild card name itself and for the type CNAME. Implementers have suggested letting a CNAME at a wild card play the same role as a CNAME at an exact match, meaning that one step in the algorithm in 1034/4.3.2 would be altered. (Noting that the algorithm is a suggestion and not a specification.) This is the central issue on whether or not the document is merely a clarification or an adjustment to 1034. The sense seems to be to allow CNAMEs to be "chased" at a wild card, regardless of whether this is a clarification or an adjustment. One other suggestion was that DNAMEs ought to also be included in the discussion. Originally they were, and there still may be a blurb in the draft, but the DNAME specification has been seen as too confusing to clarify at this point. Issue (4d): Whether a wild card NS is permitted. For a while (since Vienna) it seemed that this would be viable. However, no one has cited a concrete application for this. In addition, there is a rule that only the authoritative source can synthesize an answer to a query, when issuing a referral, the answering party is inherently not authoritative. The sense of the room seemed to be for banning NS RR from wild cards. The downside to this is that enforcement should be defined. E.g., what happens on zone load, dynamic update addition, or records seen in an answer. (Also, when it comes to DNSSEC, how the signer treats this.) Other issues - one person asked about a restriction on SOA (a counter to the NS record). SOA's are already barred from being anywhere other than the apex. Item #5: The DNSSECbis documents The discussion centered around the dnssec-editor's list of 'official' questions. For convienence, the questions will be listed by number here and not by content. (Content is available in the slides.) The discussion began by listing the following questions as haven been recently settled: Q6, Q11, Q16, and Q17. In addition, Q15 was moved from open to settled during the week. The rest of the dicussion was organized by the open questions, followed by an issue concerning compression of names and the encoding of the NSEC RR. The current list of open questions are Q18, Q19, Q20, and Q21. Q18: conflicting rules between TTL settings on the RRSIG RR According to RFC 2181 the RRSIG's at a name comprise a set, ergo all should have the same TTL. According to RFC 2535 the (RR)SIG's ought to have the same TTL as their covering set. The discussion came down to a choice between making signature records a special case (RRSIG, SIG, or both) or adopting a means to make the dilemma disappear. E.g., adopting a bit in the RR type field to signify that the record was a signature. While there was a sentiment to "not break DNS to secure it" there was a stronger opinion to just recognize that the signature was an infrastructure record and therefore treat it as special. Hence it should take up the TTL from the RRset it signes and it is allowed for individual RRs in a SIG RRset to have different TTLs. Q19: suppression of duplicates The original specification leans toward but does not explicitly forbid the transmission of duplicate RR's (same envelope and RDATA). DNSSEC needs to define a canonical form so that the signer and verifier can work together. If not, there would be crypto-level errors which are hard to detect and isolate. There wasn't a clear mandate to alter the base DNS state on this. However, it was clear that there needs to be a canonical form between signer and verifier. Besides suppression of duplicates, sequencing and downcasing also have to be preserved. This isn't necesarily an on-the-wire issue, as both ends of the crypto process can repeat the same canonicalization process. Q20: expansion of wild card in authority section A wild card record would be appear in the authority section in a few cases. One might be the expansion of an NS RR - but wild card NS RR's seem to be on the road to elimination. (See the discussion on them in the wcard doc.) In the case of an NXDOMAIN, there would be a NSEC for the exact match and for the wild card, and with allowing CNAME's at a wild card to have the effect of continuing the lookup, possibly more. But none of these would involve expansion. The remaining case is the inclusion of a wild card NSEC record in a "no data" situation. The query name does not have an answer, but a wild card synthesis rule is in effect. However, the desired type is not represented. The sense of the room was to leave this name in the wild card form. Using the record for synthesis would appear to be confusing - first an NSEC claims the name does not exist and then there's an NSEC (synthesized) for the name. In either case, a resolver could figure this out given the label count, but the expansion serves no purpose. One other comment was that the result of this ought to be included in the wcard clarify draft - cleansing the issue of DNSSEC. IOW, under what conditions are sythesized records places in the authority section. Q21: (re)use of NSEC in cache According to NCACHE (RFC 2038), a cached negative answer can only be used by a cache to answer a newer query if the QNAME, QCLASS, and QTYPE match. With the NSEC RR, it is possible to reuse the negative answer for a match involving just the QNAME and QCLASS, if the QTYPE is absent from the bit field. The debate centered around if such a discussion was appropriate here or in an update to NCACHE (RFC 2308). On the other hand, the words in the proposed text used MAY - as in the cache MAY take advantage of this. As opposed to a MUST or SHOULD which actively promote the adoption of this "shortcut", MAY is neutral, encouraging experimentation. MUST NOT or SHOULD NOT are too strong in the other direction. Compression Guidelines: New DNS records are not supposed to be compressed. A discussion along the lines of "conservative on send, liberal on receive" ensued. Servers ought not compress, resolvers ought not have a fit over compressed data. The conversation was to be moved to the list over the wording of enforcement. NSEC encoding: The NXT record defines the encoding of types 1-127 and leave the rest open to future definition. This needed to be solved for NSEC. Working group chairs announced an appointment of a Document Editor for an Internet Draft processing this change: Jakob Schlyter. Five proposals were listed and briefly described. a) Extend bitmap for all types (0-127 are coverd by a simple bitmap) b) List types in sorted order c) Approach optimized for the first 256 types d) Approach optimized for the size of the record (skiplist of blocks) e) Approach close to d, using bitmap within blocks Comments: b & c don't allow a name to have 64K types simultaneously, max around half that. 'Course, a name with this is unlikely. The goal was to decide on one approach to seek a further definition. What followed was a beauty contest. In the first round, approaches b,c and e were chosen (people humming for more than one). In the second round, approach e was selected for further work. Wrap-up The three DNSSECbis documents are planned to be in WG last call by the end of the year. Following soon will be two authoritative implementations - BIND 9 and NSD. Two recursive servers will also be available - BIND 9 and IDsA (http://www.idsa.prd.fr). Acknowledgements These minutes are based on the notes made by Ed Lewis and Jaap Akkerhuis and the Jabber log by Andrew Newton. We would like to thank them for their quick submission and precise record of the meeting. Thanks to those who contributed to the constructive and productive admosphere during the meeting. Olafur and Olaf. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Nov 25 13:34:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01019 for ; Tue, 25 Nov 2003 13:34:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOhuj-0006U3-PC for namedroppers-data@psg.com; Tue, 25 Nov 2003 18:27:53 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOhuX-0006TB-MX for namedroppers@ops.ietf.org; Tue, 25 Nov 2003 18:27:41 +0000 Received: from ENGILL.ogud.com (ns.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id hAPINugR009581; Tue, 25 Nov 2003 13:23:56 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.0.0.22.2.20031125131911.02e3b810@localhost> X-Sender: post@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Tue, 25 Nov 2003 13:27:26 -0500 To: Kevin Darcy , namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: Issue: Add a new QTYPE In-Reply-To: <3FC2CE40.8000002@daimlerchrysler.com> References: <20031122163032.83E6013966@sa.vix.com> <3FC2CE40.8000002@daimlerchrysler.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 22:36 2003-11-24, Kevin Darcy wrote: >The fact that all extant implementations (arguably) violate the standard >in the same, interoperable way does not mean the behavior is correct -- >that is, after all, the defining difference between _de_facto_ standards >and _de_jure_ ones. None of the implementations IMHO violate the standard. QTYPE=* is a debugging tool only. >More importantly, a faithful implementation of QTYPE=* recursivity might >rescue that QTYPE from its current state of dubious usefulness (at best) >and/or near-obsolescence (at worst), and put an end to all of these >new-metatype proposals without the overreaching that EDNS1 represented or >was perceived to represent. I can understand why you'd be bitter about how >EDNS1 turned out, but that doesn't mean a more modest approach, one that >stays within the existing RFC 1034/1035 framework without requiring >extensions, can't or shouldn't work. If you want all the types just ask an authoritative server directly. There is no need to complicate caches. (If you are stuck behind a firewall that does not allow you to bypass the cache, you are out of luck, but that is a well known problem. Olafur > > - Kevin > > > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Nov 25 23:42:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24779 for ; Tue, 25 Nov 2003 23:42:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOqqS-000B2p-RO for namedroppers-data@psg.com; Wed, 26 Nov 2003 04:00:04 +0000 Received: from [129.9.82.74] (helo=fxodpr13.extra.daimlerchrysler.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOqqF-000B1P-Pa for namedroppers@ops.ietf.org; Wed, 26 Nov 2003 03:59:51 +0000 Received: (from uucp@localhost) by fxodpr13.extra.daimlerchrysler.com (8.12.8/8.9.0) id hAQ3xp5c007106 for ; Tue, 25 Nov 2003 22:59:51 -0500 (EST) Received: from unknown(53.231.71.24) by fxodpr13.extra.daimlerchrysler.com via csmap (V6.0) id srcAAAN_ai4n; Tue, 25 Nov 03 22:59:51 -0500 Received: from odconpr2-hme0.oddc.chrysler.com ([127.0.0.1]) by odconpr2-hme0.oddc.chrysler.com (Mail-Gear 2.0.0 bld 66) with SMTP id M2003112522595027771 for ; Tue, 25 Nov 2003 22:59:50 -0500 Received: from odmrspr2-hme0.oddc.chrysler.com ([53.231.2.113]) by odconpr2-hme0.oddc.chrysler.com (SAVSMTP 3.1.1.32) with SMTP id M2003112522595022054 for ; Tue, 25 Nov 2003 22:59:50 -0500 Received: from wokcdts1.is.chrysler.com (wokcdts1.is.chrysler.com [53.230.102.164]) by odmrspr2-hme0.oddc.chrysler.com (8.12.10/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id hAQ3xoqV010860 for ; Tue, 25 Nov 2003 22:59:50 -0500 (EST) Received: from daimlerchrysler.com (wokcdts1.is.chrysler.com [53.230.102.164]) by wokcdts1.is.chrysler.com (8.12.10/8.9.1) with ESMTP id hAQ3xJhp010891 for ; Tue, 25 Nov 2003 22:59:19 -0500 (EST) Message-ID: <3FC42517.4090404@daimlerchrysler.com> Date: Tue, 25 Nov 2003 22:59:19 -0500 From: Kevin Darcy User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: Issue: Add a new QTYPE References: <20031122163032.83E6013966@sa.vix.com> <3FC2CE40.8000002@daimlerchrysler.com> <6.0.0.22.2.20031125131911.02e3b810@localhost> In-Reply-To: <6.0.0.22.2.20031125131911.02e3b810@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit O'lafur Gu?mundsson wrote: > > At 22:36 2003-11-24, Kevin Darcy wrote: > >> The fact that all extant implementations (arguably) violate the >> standard in the same, interoperable way does not mean the behavior is >> correct -- that is, after all, the defining difference between >> _de_facto_ standards and _de_jure_ ones. > > > None of the implementations IMHO violate the standard. The standard describes the basic resolver algorithm as a) answer from your cache if you can, or b) if recursion was requested and you're willing to provide it, go get the answer from an authoritative server or upstream resolver. Now, it's hard for me to read into that that a known *incomplete* answer from cache is acceptable to pass back to the client even though a complete answer is available via recursion. As was clarified later, dropping individual RRs from an answer RRset is illegal (except for properly-flagged truncation scenarios), why should it be any more legal to drop whole RRsets from a QTYPE=* response for any reason other than properly-flagged truncation or the fact that the only way to provide the missing RRset(s) would be to recurse, and recursion was either not requested or not available? > QTYPE=* is a debugging tool only. That is arguably what it has become. I still don't agree that that is what was originally intended or specified. >> More importantly, a faithful implementation of QTYPE=* recursivity >> might rescue that QTYPE from its current state of dubious usefulness >> (at best) and/or near-obsolescence (at worst), and put an end to all >> of these new-metatype proposals without the overreaching that EDNS1 >> represented or was perceived to represent. I can understand why you'd >> be bitter about how EDNS1 turned out, but that doesn't mean a more >> modest approach, one that stays within the existing RFC 1034/1035 >> framework without requiring extensions, can't or shouldn't work. > > > If you want all the types just ask an authoritative server directly. > There is no need to complicate caches. > (If you are stuck behind a firewall that does not allow you to bypass the > cache, you are out of luck, but that is a well known problem. It's not just a matter of connectivity, it's also a matter of resources and capacity. Bypassing one's upstream resolver may consume resources that one's network administrator never expected or provisioned for. Is conserving those resources worth the caching complexity that a robust implementation of QTYPE=* would require? Hard to generalize: in some cases, yes, some cases no. But this is something IMO that each administrator should decide for himself/herself (it's legal for them to simply REFUSE all QTYPE=* queries after all); it shouldn't be decided pre-emptively for them by software-implementation decisions based on questionable interpretations of the RFC. Also, just because a problem is well known doesn't mean it cannot or should not be solved. - Kevin -- to unsubscribe send a message to namedroppers-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 Nov 25 23:42:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24783 for ; Tue, 25 Nov 2003 23:42:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOqlh-000Ani-Vx for namedroppers-data@psg.com; Wed, 26 Nov 2003 03:55:09 +0000 Received: from [129.9.82.74] (helo=fxodpr13.extra.daimlerchrysler.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOqlJ-000AmC-0E for namedroppers@ops.ietf.org; Wed, 26 Nov 2003 03:54:45 +0000 Received: (from uucp@localhost) by fxodpr13.extra.daimlerchrysler.com (8.12.8/8.9.0) id hAQ3si36006956 for ; Tue, 25 Nov 2003 22:54:44 -0500 (EST) Received: from unknown(53.231.71.24) by fxodpr13.extra.daimlerchrysler.com via csmap (V6.0) id srcAAAT_ayLn; Tue, 25 Nov 03 22:54:44 -0500 Received: from odconpr2-hme0.oddc.chrysler.com ([127.0.0.1]) by odconpr2-hme0.oddc.chrysler.com (Mail-Gear 2.0.0 bld 66) with SMTP id M2003112522544215091 for ; Tue, 25 Nov 2003 22:54:43 -0500 Received: from odmrspr2-hme0.oddc.chrysler.com ([53.231.2.113]) by odconpr2-hme0.oddc.chrysler.com (SAVSMTP 3.1.1.32) with SMTP id M2003112522544322025 for ; Tue, 25 Nov 2003 22:54:43 -0500 Received: from wokcdts1.is.chrysler.com (wokcdts1.is.chrysler.com [53.230.102.164]) by odmrspr2-hme0.oddc.chrysler.com (8.12.10/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id hAQ3shqV009688 for ; Tue, 25 Nov 2003 22:54:43 -0500 (EST) Received: from daimlerchrysler.com (wokcdts1.is.chrysler.com [53.230.102.164]) by wokcdts1.is.chrysler.com (8.12.10/8.9.1) with ESMTP id hAQ3sChp010873 for ; Tue, 25 Nov 2003 22:54:12 -0500 (EST) Message-ID: <3FC423E4.5060201@daimlerchrysler.com> Date: Tue, 25 Nov 2003 22:54:12 -0500 From: Kevin Darcy User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: Issue: Add a new QTYPE References: <20031125045235.37F171396F@sa.vix.com> In-Reply-To: <20031125045235.37F171396F@sa.vix.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: >>>there is no way to "clarify" QTYPE=* short of a protocol extension. the >>>current behaviour is perfectly well understood and there are no incorrect >>>implementations of it. there's no document quality issue around QTYPE=*, >>>and all extant implementations are fully interoperable regarding QTYPE=*. >>> >>> >> The current behavior is fine as long as one puts on blinders with >>respect to correctness and completeness of answer content. In my opinion, >>giving out a known-incomplete answer to *any* query, when a complete answer >>is available via recursion and where recursion was both requested and its >>availability advertised, is a violation of the spirit if not the precise >>wording of the standards (and let's face it, RFC 1034&1035 leave a lot to >>the imagination wrt how QTYPE=* queries are actually supposed to work). >> >> > >thanks for your sharing your opinion. here's mine. QTYPE=* is a wonderful >debugging aid designed to let me find out what's in a middlebox cache, much >better than successive RD=0 queries. > Why "successive" RD=0 queries? Even if QTYPE=* recursed properly, you'd still have the option of using a *single* RD=0 QTYPE=* query if all you want to do is debug a middlebox'es cache. What I've been discussing all along is fulfilling the stated need for a way to reliably fetch *complete* multiple-RRset answers for a given name in a single query/response transaction, preferably without actually extending the protocol. An RD=1 QTYPE=* query *can* fulfill and IMO *should*always*have* fulfilled that need, regardless of whatever debugging capabilities its non-recursive counterpart might possess. >>The fact that all extant implementations (arguably) violate the >>standard in the same, interoperable way does not mean the behavior is >>correct -- that is, after all, the defining difference between >>_de_facto_ standards and _de_jure_ ones. >> >> > >the standard is completely clear on this topic. you might not agree with >it but there is no possible reading of 1034/1035 that makes it acceptable >to do anything other than return whatever partial results are in cache: > >| RFC 1034 Domain Concepts and Facilities November 1987 >| >| If a similar query was directed to two name servers which are not >| authoritative for SRI-NIC.ARPA, the responses might be: >| >| +---------------------------------------------------+ >| Header | OPCODE=SQUERY, RESPONSE | >| +---------------------------------------------------+ >| Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=* | >| +---------------------------------------------------+ >| Answer | SRI-NIC.ARPA. 12345 IN A 26.0.0.73 | >| | A 10.0.0.51 | >| +---------------------------------------------------+ >| Authority | | >| +---------------------------------------------------+ >| Additional | | >| +---------------------------------------------------+ >| >| and >| >| +---------------------------------------------------+ >| Header | OPCODE=SQUERY, RESPONSE | >| +---------------------------------------------------+ >| Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=* | >| +---------------------------------------------------+ >| Answer | SRI-NIC.ARPA. 1290 IN HINFO DEC-2060 TOPS20 | >| +---------------------------------------------------+ >| Authority | | >| +---------------------------------------------------+ >| Additional | | >| +---------------------------------------------------+ >| >| Neither of these answers have AA set, so neither response comes from >| authoritative data. The different contents and different TTLs suggest >| that the two servers cached data at different times, and that the first >| server cached the response to a QTYPE=A query and the second cached the >| response to a HINFO query. >| >| Mockapetris [Page 42] > >i dearly wish that every part of The Spec were as clear as this! > As I pointed out to DJB, those examples are responses to *non-recursive* queries, and thus not particularly relevant to what I'm talking about. Use RD=0 QTYPE=* queries to debug caches, and RD=1 QTYPE=* queries if you're really serious about getting all of the RRsets owned by the name. Unfortunately, there were no RD=1 QTYPE=* examples in RFC 1034, and I think that's what led to the implementation confusion. >>More importantly, a faithful implementation of QTYPE=* recursivity might >>rescue that QTYPE from its current state of dubious usefulness (at best) >>and/or near-obsolescence (at worst), and put an end to all of these >>new-metatype proposals without the overreaching that EDNS1 represented or >>was perceived to represent. I can understand why you'd be bitter about how >>EDNS1 turned out, but that doesn't mean a more modest approach, one that >>stays within the existing RFC 1034/1035 framework without requiring >>extensions, can't or shouldn't work. >> >> > >it's not bitterness. it's that without a protocol change, there is no way >for a requestor to signal that it desires "the new behaviour", nor any way >for a responder to signal that it performed "the new behaviour." > I don't see how any client could be relying on the old behavior, since the old behavior is so non-deterministic. Conversely, no client can *prevent* a caching resolver from giving it a full answer in response to a QTYPE=* query, i.e. the new behavior, so it must already be prepared for that contingency. If nothing relies on the old behavior, and the new behavior is known to cause no problems, what would be the issue with simply switching over to the new behavior, _sans_ signalling or versioning or whatnot? >therefore >even if the standard weren't clear on this point (but it is!) there would >be no effective way to fix "the problem" (but there isn't one.) > For me, this isn't really about "fix[ing] 'the problem'", it's more about realizing the potential of QTYPE=* and using it to head off other, arguably ill-advised metatypes, such as the "dual stack" metatype proposed by the initiator of this thread... - Kevin -- to unsubscribe send a message to namedroppers-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 Nov 26 00:19:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25624 for ; Wed, 26 Nov 2003 00:19:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOs08-000EL9-4Z for namedroppers-data@psg.com; Wed, 26 Nov 2003 05:14:08 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOrzw-000EKK-DT for namedroppers@ops.ietf.org; Wed, 26 Nov 2003 05:13:56 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 2BF031394C for ; Wed, 26 Nov 2003 05:13:56 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Issue: Add a new QTYPE In-Reply-To: Message from Kevin Darcy of "Tue, 25 Nov 2003 22:54:12 EST." <3FC423E4.5060201@daimlerchrysler.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 26 Nov 2003 05:13:56 +0000 Message-Id: <20031126051356.2BF031394C@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > For me, this isn't really about "fix[ing] 'the problem'", it's more about > realizing the potential of QTYPE=* and using it to head off other, arguably > ill-advised metatypes, such as the "dual stack" metatype proposed by the > initiator of this thread... there is no protocol element that can be used to tell a cache to send a packet toward an authority server, other than perhaps QTYPE=SOA. if RD=1 QTYPE=* meant what you wish it meant, then this would be used all the time, by applications whose authors "wanted to be certain". if you propose a new protocol element which bypasses caching in this way, then implementations will be free to support it or not, and operators will be free to enable it or not (or rate limit it). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Nov 26 00:29:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24777 for ; Tue, 25 Nov 2003 23:42:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOr9w-000Bws-FG for namedroppers-data@psg.com; Wed, 26 Nov 2003 04:20:12 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOr9k-000BvY-0A for namedroppers@ops.ietf.org; Wed, 26 Nov 2003 04:20:00 +0000 Received: from ENGILL.ogud.com (mail.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id hAQ4G4gR011198; Tue, 25 Nov 2003 23:16:07 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.0.0.22.2.20031111220137.03119710@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Tue, 25 Nov 2003 23:19:36 -0500 To: Thomas Narten From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: Re: Document review: draft-brand-drip-02.txt Cc: namedroppers@ops.ietf.org, rsbx@acm.org, laurence@sherzer.net, ietf-drip-draft@spamblock.gamerz.net In-Reply-To: <6.0.0.22.2.20031016161952.0268eaa0@localhost> References: <6.0.0.22.2.20031016161952.0268eaa0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable At 21:54 2003-10-17, =D3lafur Gudmundsson/DNSEXT co-chair wrote: >This document has been submitted to the RFC editor for publication. >The IESG has asked the working group to comment on the DNS protocol aspects >of this document. This is one of the roles this working group has >in its charter. > >The URI for the document is: >http://www.ietf.org/internet-drafts/draft-brand-drip-02.txt The working group did not have any comments on this document. This chair reviewed the document for possible violations of the DNS protocol, there are none. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Nov 26 02:22:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17748 for ; Wed, 26 Nov 2003 02:22:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOtx7-000KGm-GX for namedroppers-data@psg.com; Wed, 26 Nov 2003 07:19:09 +0000 Received: from [207.65.203.98] (helo=goose.ehsco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOtwv-000KGS-SH for namedroppers@ops.ietf.org; Wed, 26 Nov 2003 07:18:57 +0000 Received: from [207.65.3.26] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 4.1.3) with ESMTP-TLS id 645092 for namedroppers@ops.ietf.org; Wed, 26 Nov 2003 05:04:40 -0600 Message-ID: <3FC453DE.4030506@ehsco.com> Date: Wed, 26 Nov 2003 01:18:54 -0600 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: Issue: Add a new QTYPE References: <20031125045235.37F171396F@sa.vix.com> <3FC423E4.5060201@daimlerchrysler.com> In-Reply-To: <3FC423E4.5060201@daimlerchrysler.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kevin Darcy wrote: > arguably ill-advised metatypes, such as the "dual stack" metatype > proposed by the initiator of this thread... I agree with you that RD=1 should work as you suggest. But that wouldn't be better than a 'metatype' as you call it, given that the answer sets for qtype=* would often be much larger than an answer set for (say) MX+A, and thus much less efficient. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Nov 26 02:22:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17964 for ; Wed, 26 Nov 2003 02:22:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOtuT-000KBO-1P for namedroppers-data@psg.com; Wed, 26 Nov 2003 07:16:25 +0000 Received: from [207.65.203.98] (helo=goose.ehsco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOtuF-000KAl-Ao for namedroppers@ops.ietf.org; Wed, 26 Nov 2003 07:16:11 +0000 Received: from [207.65.3.26] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 4.1.3) with ESMTP-TLS id 645094 for namedroppers@ops.ietf.org; Wed, 26 Nov 2003 05:01:54 -0600 Message-ID: <3FC45337.6030705@ehsco.com> Date: Wed, 26 Nov 2003 01:16:07 -0600 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: Issue: Add a new QTYPE References: <20031126051356.2BF031394C@sa.vix.com> In-Reply-To: <20031126051356.2BF031394C@sa.vix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: > if RD=1 QTYPE=* meant what you wish it meant, then this would be used all > the time, by applications whose authors "wanted to be certain". If RD=1 were interpreted as it usually is, the cache would answer from the results of a previous qtype=* query. So it wouldn't really be useful for 'get me the latest' because the normal behavior would only get the cached results, not the authoritative data. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Nov 26 03:35:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27376 for ; Wed, 26 Nov 2003 03:35:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOv4D-000NjG-3D for namedroppers-data@psg.com; Wed, 26 Nov 2003 08:30:33 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOv3q-000Nhg-Q5 for namedroppers@ops.ietf.org; Wed, 26 Nov 2003 08:30:10 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id D13AA4FE5A; Wed, 26 Nov 2003 09:30:09 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 60B434FE2B; Wed, 26 Nov 2003 09:30:09 +0100 (CET) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id hAQ8U99U018943; Wed, 26 Nov 2003 09:30:09 +0100 Date: Wed, 26 Nov 2003 09:30:09 +0100 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Cc: Margaret.Wasserman@nokia.com, Thomas Narten Subject: Post-IETF 58 DNSEXT Summary Message-Id: <20031126093009.4939fa97.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.6 (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-Status: N 0.128905 X-RIPE-Signature: 43539f2f647209f57748f56c96faf428 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,OPT_IN autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Summary of the IETF 58 DNSEXT meeting. This summary is an addition to the draft minutes. (http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg02168.html) Documents to go to last call: -none- Documents in wg-last call: + draft-ietf-dnsext-mdns-24 Needs WGLC summary and minor edits + draft-ietf-dnsext-tkey-renewal-mode + draft-ietf-dnsext-case-insensitive Both have WGLC completed, they need a summary and a ID nits review before being send to IESG Stalled docs + draft-ietf-dnsext-rfc2536bis-dsa-4 + draft-ietf-dnsext-rfc2536bis-dhk-4 + draft-ietf-dnsext-ecc-key-4 all waiting for DNSSECbis to be finished. Active docs + draft-ietf-dnsext-wildcard-clarify-02 + draft-ietf-dnsext-dnssec-intro-06 + draft-ietf-dnsext-dnssec-protocol-03 + draft-ietf-dnsext-dnssec-records-05 Wildcard clarify had the 4 outstanding issues discussed. Summary of discussion and outstanding issues will be posted to the list. DNSSEC editors team gave update on the document set. Open questions where discussed and solutions where suggested. These will be resolved further via the list. Goal is WGLC by end December. Documents in IESG. + draft-ietf-dnsext-axfr-clarify-05 Waiting for AD writeup + draft-ietf-dnsext-delegation-signer In RFC queue + draft-ietf-dnesxt-dnssec-2535typecode-change (TCR) Needs IANA considerations fixed. + draft-ietf-dnesxt-keyrr-key-signing-flag Needs IANA considerations fixed (dependency on TCR) + draft-ietf-dnsext-dnssec-opt-in-05 WG to provide boilerplate indicating non-standard track status (stalled until 2535bis has been done). + draft-ietf-dnsext-dhcid-rr-07 Waiting for DHC WG. + draft-ietf-dnsext-dns-threats-04 AD evaluation + draft-dnsext-opcode-discover Waiting for editorial changes Charter The charter was not discussed as it was recently updated and there is no further need for change. The milestones will be updated shortly. Action Items - Chairs (OK): Post summaries of discussions on wildcard clarify to the list. - Chairs (OK): Get consensus on the open DNSSEC issues - DNSSEC-editors: post updated DNSSECbis documents to the list by December - Chairs (OK&OG): Update milestones - Chairs (OG): Publish link to dnssec-editors archive. - Doc Ed. (Weiler) + Chairs (OG): fix IANA considerations on Typecode change - Doc Ed. (OK): fix IANA considerations on KeyFlag - Chairs (OG): Track DHC WG for dhcid-rr input - Doc Ed (Manning): Editorial Change to dnsext-opcode-discover -- to unsubscribe send a message to namedroppers-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 Nov 26 04:25:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28586 for ; Wed, 26 Nov 2003 04:25:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOvrV-000025-Rh for namedroppers-data@psg.com; Wed, 26 Nov 2003 09:21:29 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOvrH-000Q0l-Kb for namedroppers@ops.ietf.org; Wed, 26 Nov 2003 09:21:16 +0000 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id hAQ9L1n17330; Wed, 26 Nov 2003 16:21:06 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id hAQ9Kad00273; Wed, 26 Nov 2003 16:20:37 +0700 (ICT) From: Robert Elz To: Kevin Darcy cc: namedroppers@ops.ietf.org Subject: Re: Issue: Add a new QTYPE In-Reply-To: <3FC42517.4090404@daimlerchrysler.com> References: <3FC42517.4090404@daimlerchrysler.com> <20031122163032.83E6013966@sa.vix.com> <3FC2CE40.8000002@daimlerchrysler.com> <6.0.0.22.2.20031125131911.02e3b810@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 26 Nov 2003 16:20:36 +0700 Message-ID: <5523.1069838436@munnari.OZ.AU> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Tue, 25 Nov 2003 22:59:19 -0500 From: Kevin Darcy Message-ID: <3FC42517.4090404@daimlerchrysler.com> | The standard describes the basic resolver algorithm as a) answer from | your cache if you can, or b) if recursion was requested and you're | willing to provide it, go get the answer from an authoritative server or | upstream resolver. Now, it's hard for me to read into that that a known | *incomplete* answer from cache is acceptable to pass back to the client | even though a complete answer is available via recursion. What is a "known incomplete answer"? How can the cache possibly know whether what is cached is complete or not? The effect of enforcing the protocol that you're suggesting should be enforced, is that any QTYPE=* RD=1 query must be sent to an auth server, and the reply forwarded back to the client - a cache could cache the results, but not for use in any later QTYPE=* query, only specific queries. Since caches are a primary object in the DNS, and everything is designed around making caches effective, it is almost impossible to conceive that a query that explicitly avoids the cache could possibly have been intended. If the client wants to defeat caching, let the client talk directly to an auth server for the name (and do the extra work to find that server). Explicitly requiring caches to defeat their reason for existing would be absurd. | As was | clarified later, dropping individual RRs from an answer RRset is illegal | (except for properly-flagged truncation scenarios), why should it be any | more legal to drop whole RRsets from a QTYPE=* response for any reason | other than properly-flagged truncation or the fact that the only way to | provide the missing RRset(s) would be to recurse, and recursion was | either not requested or not available? They're not being dropped, they simply aren't available at the server queried to ask. I'm actually somewhat skeptical of having a cache to a QTYPE=* request of the auth server if it has no data about the name, I think I'd prefer to have it simply return NODATA in that case (or NXDOMAIN if it knows the name doesn't exist) - the only real problem with that would be the possibility of getting a NODATA for a name which really doesn't exist (or perhaps a NXDOMAIN for a name that does if that was the selected response to an ANY query for a name not in the cache). | That is arguably what it has become. I still don't agree that that is | what was originally intended or specified. Nothing says why it was originally specified, in fact, it isn't clear that there was any reason at all, other than "this looks nice and easy" (which turned out to be wrong on both counts - if t hat was the explanation). I support leaving QTYPE=* defined as it has been implemented everywhere. Return any data in the server receiving the query (ignoring RD if there is any such data) - if there is none, then send a non-auth NODATA (or a referral, I guess, that would be better) (again regardless of RD). Implementations that choose to honour RD when there is no data are OK, as from the outside no-one can tell if the data existed before the query or only after it was received - so returning the answer from a query is OK (as I guess is an implementation which actually always does a query of the auth server when RD=1 - though I'd never deploy such a thing). kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Nov 26 12:41:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18697 for ; Wed, 26 Nov 2003 12:41:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AP3UD-000Ons-L9 for namedroppers-data@psg.com; Wed, 26 Nov 2003 17:29:57 +0000 Received: from [207.65.203.98] (helo=goose.ehsco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AP3U0-000On1-Fa for namedroppers@ops.ietf.org; Wed, 26 Nov 2003 17:29:44 +0000 Received: from [207.65.3.26] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 4.1.3) with ESMTP-TLS id 645180 for namedroppers@ops.ietf.org; Wed, 26 Nov 2003 15:15:26 -0600 Message-ID: <3FC4E304.3040706@ehsco.com> Date: Wed, 26 Nov 2003 11:29:40 -0600 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: [Fwd: I-D ACTION:draft-hall-qtype-addr-01.txt] Content-Type: multipart/mixed; boundary="------------050004010100060603080307" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,MIME_SUSPECT_NAME autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------050004010100060603080307 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit FYI. [note that the announcement didn't pick up the new draft title--it's no longer limited to qtype=addr] This version resolves the issues which were raised wrt coexistence of data/nodata in qtype=addr answers, adds rules for A+AAAA in the additional data section of other messages, introduces rules for managing truncated response messages, and incorporates some cleaning. I'm still not advocating this as a WG work-item, at least not yet anyway. However, in the absence of documentation for other approaches with the same level of data- and behavioral-consistency, it seems that this is the direction we should go when this subject comes up again. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ --------------050004010100060603080307 Content-Type: message/rfc822; name="I-D ACTION:draft-hall-qtype-addr-01.txt" Content-Disposition: inline; filename="I-D ACTION:draft-hall-qtype-addr-01.txt" Return-Path: Received: from asgard.ietf.org ([132.151.6.40] verified) by goose.ehsco.com (CommuniGate Pro SMTP 4.1.3) with ESMTP id 645162 for lists@ehsco.com; Wed, 26 Nov 2003 14:00:40 -0600 Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1AP1iV-0004OS-0J for ietf-announce-list@asgard.ietf.org; Wed, 26 Nov 2003 10:36:35 -0500 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1AP1dd-0004LM-Py for all-ietf@asgard.ietf.org; Wed, 26 Nov 2003 10:31:33 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12122 for ; Wed, 26 Nov 2003 10:31:19 -0500 (EST) Message-Id: <200311261531.KAA12122@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-hall-qtype-addr-01.txt Date: Wed, 26 Nov 2003 10:31:18 -0500 Sender: owner-ietf-announce@ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The ADDR DNS Query-Type Author(s) : E. Hall Filename : draft-hall-qtype-addr-01.txt Pages : 13 Date : 2003-11-26 This document defines mechanisms for providing all IP address resource records (specifically including any A and AAAA resource records) in DNS response messages. Specifically, this document defines an 'ADDR' query-type which allows a system to issue a single lookup for all of the addressing resource records associated with a domain name (explicitly including any IPv4 and IPv6 resource records), and also defines an algorithm for DNS servers to use when returning supplemental address data in the additional-data section of a response message. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hall-qtype-addr-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-hall-qtype-addr-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-hall-qtype-addr-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: <2003-11-26103539.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hall-qtype-addr-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-hall-qtype-addr-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-11-26103539.I-D@ietf.org> --OtherAccess-- --NextPart-- --------------050004010100060603080307-- -- to unsubscribe send a message to namedroppers-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 Nov 26 18:38:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04329 for ; Wed, 26 Nov 2003 18:38:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AP96V-000JYu-3N for namedroppers-data@psg.com; Wed, 26 Nov 2003 23:29:51 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AP95m-000JWd-O5 for namedroppers@ops.ietf.org; Wed, 26 Nov 2003 23:29:06 +0000 Received: (qmail 31806 invoked by uid 1016); 26 Nov 2003 23:29:27 -0000 Date: 26 Nov 2003 23:29:27 -0000 Message-ID: <20031126232927.31805.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: Issue: Add a new QTYPE References: <20031122163032.83E6013966@sa.vix.com> <3FC2CE40.8000002@daimlerchrysler.com> <6.0.0.22.2.20031125131911.02e3b810@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > QTYPE=* is a debugging tool only. QTYPE=* can be used to check for CNAME records. RFC 1034 prohibits non-CNAME records at a name that has a CNAME record, so if QTYPE=* returns any non-CNAME records then there are no CNAME records. This is widely used in Internet mail: clients check for CNAME records and use them to rewrite SMTP MAIL/RCPT commands. Clients that fail to do this are in violation of RFC 1123. (In theory, QTYPE=CNAME would also work. In practice, QTYPE=CNAME triggers an old BIND bug---see http://cr.yp.to/im/cname.html---so QTYPE=* is the de-facto standard solution.) All of this is changing. We mail implementors have agreed that this SMTP rewriting is a bad thing; meanwhile, many DNS proposals violate the RFC 1034 non-CNAME prohibition. So a three-step transition is in progress: (1) mail administrators will stop relying on SMTP rewriting; and then (2) clients will stop looking specially for CNAME records; and then (3) the RFC 1034 non-CNAME prohibition can be safely violated. In the meantime, however, the statement that ``QTYPE=* is a debugging tool only'' is simply wrong. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Nov 26 18:39:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04348 for ; Wed, 26 Nov 2003 18:39:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AP9By-000JrL-LY for namedroppers-data@psg.com; Wed, 26 Nov 2003 23:35:30 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AP9Bm-000Jqj-Ty for namedroppers@ops.ietf.org; Wed, 26 Nov 2003 23:35:18 +0000 Received: (qmail 37952 invoked by uid 1016); 26 Nov 2003 23:35:40 -0000 Date: 26 Nov 2003 23:35:40 -0000 Message-ID: <20031126233540.37951.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: TTLs in QTYPE=* caching References: <20031122163032.83E6013966@sa.vix.com> <3FC2CE40.8000002@daimlerchrysler.com> <6.0.0.22.2.20031125131911.02e3b810@localhost> <3FC42517.4090404@daimlerchrysler.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Kevin, could you please explain _exactly_ how you think a cache should handle recursive QTYPE=* queries? Suppose, for example, that a name has a 3600-second A record and a 60-second MX record. The cache receives a QTYPE=* query for that name. Two minutes later, it receives another. What happens? If you're going to use words such as ``incomplete'' in your answer, please define those words first. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Nov 27 04:13:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01009 for ; Thu, 27 Nov 2003 04:13:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1API7d-000GA4-Oq for namedroppers-data@psg.com; Thu, 27 Nov 2003 09:07:37 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1API79-000G7o-J8 for namedroppers@ops.ietf.org; Thu, 27 Nov 2003 09:07:07 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 29E924E2F8; Thu, 27 Nov 2003 10:07:06 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id AAB7D4E257 for ; Thu, 27 Nov 2003 10:07:05 +0100 (CET) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id hAR9759U020299 for ; Thu, 27 Nov 2003 10:07:05 +0100 Date: Thu, 27 Nov 2003 10:07:05 +0100 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: Q22: Failure Mode for compressed names. Message-Id: <20031127100705.11c1c0fe.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.6 (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-Status: N 0.003695 X-RIPE-Signature: 39ce7fb9da0dcd509d96c9ca95780b3b X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit With reference to the DNSSECbis docset and based on the discussion during IETF58, here is another little issue. Q22: Failure Mode for compressed names. What should the failure mode be if compressed names are encountered in RRs other than the "well-known" RRs; Should the verifier be liberal or fail. (Remember compression is only allowd for "well known RRs, RFC3597 section 4 and RFC1123) The sense of the room at IETF58 that senders should not send RRs with compressed data and receivers should "not throw a fit". Since, in contrast to Q19, the canonicalization for the signer and the verifier are specified (records section 6.2) so the question is if the "robustness principle" should be specified at all? Process: If you think that there should be language to specify how to apply the robustness principle for when RRs other than the "well known" RRs are compressed than please supply text to go into one of the DNSSECbis draft. Default action will be not to add recomendations about compression and decompression before sending or after receiving. This issue will be evaluated Mon 8 Dec. -- Olaf DNSEXT Co-Chair ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Nov 27 04:13:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01034 for ; Thu, 27 Nov 2003 04:13:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1API83-000GBT-SC for namedroppers-data@psg.com; Thu, 27 Nov 2003 09:08:03 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1API7Y-000G9a-WB for namedroppers@ops.ietf.org; Thu, 27 Nov 2003 09:07:33 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 3EEE64EDA3; Thu, 27 Nov 2003 10:07:32 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 6DE5A4E2A8 for ; Thu, 27 Nov 2003 10:07:31 +0100 (CET) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id hAR97U9U020574 for ; Thu, 27 Nov 2003 10:07:30 +0100 Date: Thu, 27 Nov 2003 10:07:30 +0100 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: DNSSECbis Questions Update Message-Id: <20031127100730.7d17e2ea.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.6 (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-Status: N 0.499523 X-RIPE-Signature: f296289fb80e0a30cc79c854f299b43c X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Colleagues. DNSSEC editors questions list. Below is the updates complete list of questions. I've added text there where there are status changes with respect to my previous posting (http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01983.html) The list of questions. Q1 - resolved Q2 - resolved Although marked as resolved we never declared what the actual consensus on this issue is. Hereby we fix the omission: The original question is: Should we move DSA to "optional" and have RSA/SHA1 be the only mandatory to implement algorithm? *Consensus? * _most_ of the discussion concentrated in the thread starting at: http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01770.html The consensus is that DSA should be moved to OPTIONAL and that the term OPTIONAL is to vague. RFC2119 language is to be added e.g: RSA - Mandatory (MUST be implemented) DSA - Optional (SHOULD be implemented) Q3 - resolved Q4 - mistake in numbering, there is no Q4 Q5 - resolved Q6 - resolved Q7 - resolved Q8 - resolved Q9 - resolved Q10 - resolved Q11 - resolved Q12 - resolved Q13 - resolved But note that this question has been revisited in Q21. Q14 - resolved Q15 - resolved Q16 - resolved Q17 - resolved Please reply to these questions in-thread. Shortly after this list has been posted we will post follow-ups on each individual question indicating what has been listed below. Q18: RRsig TTL violating 2181 Default action, based on sense of the room at IETF58, is to permit the TTL of SIG RRs with same ownername and CLASS to be different and to have the TTL of the SIG RRs bound to the TTL of the TYPE of the RR they sign. If there is no further prohibitive objections by December 8 this will be taken as consensus of the working group. Q19: Suppression of duplications This issue is about the canonicalization process by the signer and the verifier. Duplicates are specifically forbidden. On the list there have been several opinions with regards to how to deal with this issue. We propose the following text as consensus position: Duplicate RR records are not allowed exist according to [RFC2181]. Implementations MUST therefore treat duplicate RR records as protocol errors. Signers and verifiers MUST canonicalize duplicate RR sets by removing duplicate RRs from the set if the implementation is designed to be liberal in handling protocol errors. If there is no further prohibitive objections by December 8 this will be taken as consensus of the working group. Q20: Expansion of wild cards in the authority section. Default action, based on sense of the room at IETF58, is to not expand the owner names of e.g. wildcard NSEC RRs. If there is no further prohibitive objections by December 5 this will be taken as consensus of the working group. Q21: Caching and reuse of NSEC RRs Default action, based on sense of the room at IETF58, is to change the text not to strongly prohibit any reuse of cached NSEC RRs, but to allow, and not encourage, (MAY language) reuse to synthesize negative answers for which QNAME, QLASS has an NSEC RR of same ONAME and CLASS in cache that proves the non existance of QTYPE. If there is no further prohibitive objections by December 8 this will be taken as consensus of the working group. Q22: Failure Mode for compressed names. What should the failure mode be if compressed names are encountered in RRs other than the "well-known" RRs; Should the verifier be liberal or fail. (Remember compression is only allowd for "well known RRs, RFC3597 section 4 and RFC1123) The sense of the room at IETF58 that senders should not send RRs with compressed data and receivers should "not throw a fit". Since, in contrast to Q19, the canonicalization for the signer and the verifier are specified (records section 6.2) so the question is if the "robustness principle" should be specified at all? If you think that there should be language to specify how to apply the robustness principle for when RRs other than the "well known" RRs are compressed than please supply text to go into one of the DNSSECbis draft. Default action will be not to add recomendations about compression and decompression before sending or after receiving. This issue will be evaluated Mon 8 Dec. -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Nov 27 04:13:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01047 for ; Thu, 27 Nov 2003 04:13:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1API5H-000G0C-De for namedroppers-data@psg.com; Thu, 27 Nov 2003 09:05:11 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1API2D-000FqW-5F for namedroppers@ops.ietf.org; Thu, 27 Nov 2003 09:04:48 +0000 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id hAR90Zn15561 for ; Thu, 27 Nov 2003 16:00:35 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id hAR8xJ521031 for ; Thu, 27 Nov 2003 15:59:21 +0700 (ICT) From: Robert Elz To: namedroppers@ops.ietf.org Subject: Re: TTLs in QTYPE=* caching In-Reply-To: <20031126233540.37951.qmail@cr.yp.to> References: <20031126233540.37951.qmail@cr.yp.to> <20031122163032.83E6013966@sa.vix.com> <3FC2CE40.8000002@daimlerchrysler.com> <6.0.0.22.2.20031125131911.02e3b810@localhost> <3FC42517.4090404@daimlerchrysler.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 Nov 2003 15:59:19 +0700 Message-ID: <21135.1069923559@munnari.OZ.AU> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: 26 Nov 2003 23:35:40 -0000 From: "D. J. Bernstein" Message-ID: <20031126233540.37951.qmail@cr.yp.to> | Suppose, for example, that a name has a 3600-second A record and a | 60-second MX record. The cache receives a QTYPE=* query for that name. | Two minutes later, it receives another. What happens? Kevin, if you respond to this - also explain what happens when the cache receives a QTYPE=* query 30 seconds after the initial query (with all of the same config as above). kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Nov 27 04:20:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01218 for ; Thu, 27 Nov 2003 04:20:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1APIFM-000Gj8-DX for namedroppers-data@psg.com; Thu, 27 Nov 2003 09:15:36 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1APIF2-000Ggv-HO for namedroppers@ops.ietf.org; Thu, 27 Nov 2003 09:15:16 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id ED5DE4EE2E; Thu, 27 Nov 2003 10:15:15 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 980AB4E2F8 for ; Thu, 27 Nov 2003 10:15:15 +0100 (CET) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id hAR9FF9U022626 for ; Thu, 27 Nov 2003 10:15:15 +0100 Date: Thu, 27 Nov 2003 10:15:15 +0100 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: Re: Q18: TTL values for RRSIG vs. RFC2181 Message-Id: <20031127101515.15dc936f.olaf@ripe.net> In-Reply-To: <010e01c39fe0$ad7766c0$b9370681@barnacle> References: <010e01c39fe0$ad7766c0$b9370681@barnacle> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.6 (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-Status: N 0.036287 X-RIPE-Signature: 8137f12cc2333342dfab7ac79f510b9b X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Q18: RRsig TTL violating 2181 Default action, based on sense of the room at IETF58 and the discussion on the list, is to permit the TTLs of SIGs in a SIG RRset (same ownername and class) to be different and to have the TTL of the SIG RRs bound to the TTL of the TYPE of the RR they sign. (Nit: this would make DNSSECbis update 2181) If there is no further prohibitive objections by December 8 this will be taken as consensus of the working group. -- Olaf DNSEXT co-chair ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Nov 27 04:20:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01239 for ; Thu, 27 Nov 2003 04:20:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1APIFZ-000Gku-BR for namedroppers-data@psg.com; Thu, 27 Nov 2003 09:15:49 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1APIF6-000GhL-Bf for namedroppers@ops.ietf.org; Thu, 27 Nov 2003 09:15:20 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id BF3504EF9A; Thu, 27 Nov 2003 10:15:19 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 6B9434EE2E for ; Thu, 27 Nov 2003 10:15:19 +0100 (CET) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id hAR9FJ9U022647 for ; Thu, 27 Nov 2003 10:15:19 +0100 Date: Thu, 27 Nov 2003 10:15:19 +0100 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: Re: Q19: supression of duplicate RRs in an RRset Message-Id: <20031127101519.076a9890.olaf@ripe.net> In-Reply-To: <017e01c3a30b$0d7d9e90$b9370681@barnacle> References: <017e01c3a30b$0d7d9e90$b9370681@barnacle> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.6 (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-Status: N 0.172054 X-RIPE-Signature: a273feafad0b4e056efe78d0d0f853cd X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Q19: Suppression of duplications This issue is about the canonicalization process by the signer and the verifier. Duplicates are specifically forbidden. On the list there have been several oposite opinions with regards to how to deal with this issue. We propose the following text as consensus position: Duplicate RR records are not allowed exist according to [RFC2181]. Implementations MUST therefore treat duplicate RR records as protocol errors. Signers and verifiers MUST canonicalize duplicate RR sets by removing duplicate RRs from the set if the implementation is designed to be liberal in handling protocol errors. If there is no further prohibitive objections by December 8 this will be taken as consensus of the working group. -- Olaf DNSEXT co-chair ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Nov 27 04:23:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01338 for ; Thu, 27 Nov 2003 04:23:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1APIIU-000GtU-Rn for namedroppers-data@psg.com; Thu, 27 Nov 2003 09:18:50 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1APIIJ-000Gt6-3A for namedroppers@ops.ietf.org; Thu, 27 Nov 2003 09:18:39 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 8A3CB4EFAB; Thu, 27 Nov 2003 10:16:27 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 2EB234E2F8 for ; Thu, 27 Nov 2003 10:16:27 +0100 (CET) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id hAR9GR9U022729 for ; Thu, 27 Nov 2003 10:16:27 +0100 Date: Thu, 27 Nov 2003 10:16:27 +0100 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: Re: Q20: expanding wildcards in the authority section Message-Id: <20031127101627.667a2ad0.olaf@ripe.net> In-Reply-To: <265EC638-13FB-11D8-9A3D-000393C783A2@isi.edu> References: <265EC638-13FB-11D8-9A3D-000393C783A2@isi.edu> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.6 (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-Status: N 0.483301 X-RIPE-Signature: 67517866ba102e691dd5c570a1298c22 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Q20: Expansion of wild cards in the authority section. Default action, based on sense of the room at IETF58, is to not expand the owner names of e.g. wildcard NSEC RRs. If there is no further prohibitive objections by December 8 this will be taken as consensus of the working group. -- Olaf DNSEXT co-cair ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Nov 27 04:23:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01364 for ; Thu, 27 Nov 2003 04:23:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1APIIm-000Gud-3Z for namedroppers-data@psg.com; Thu, 27 Nov 2003 09:19:08 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1APIIK-000GtH-9Z for namedroppers@ops.ietf.org; Thu, 27 Nov 2003 09:18:40 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 992BE4FDC1; Thu, 27 Nov 2003 10:18:13 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 42D294FDA6 for ; Thu, 27 Nov 2003 10:18:13 +0100 (CET) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id hAR9ID9U022851 for ; Thu, 27 Nov 2003 10:18:13 +0100 Date: Thu, 27 Nov 2003 10:18:13 +0100 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: Re: Q-21: Can NSEC records in the cache be re-used? Message-Id: <20031127101813.1c35a5e0.olaf@ripe.net> In-Reply-To: <20031119144432.GP15349@chinook.rgy.netsol.com> References: <20031119144432.GP15349@chinook.rgy.netsol.com> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.6 (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-Status: N 0.352906 X-RIPE-Signature: cd71d23dd0d278fdad47ac6ce3765855 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Q21: Caching and reuse of NSEC RRs Default action, based on sense of the room at IETF58, is to change the text not to strongly prohibit any reuse of cached NSEC RRs, but to allow, and not encourage, (MAY language) reuse to synthesize negative answers for which QNAME, QLASS has an NSEC RR of same ONAME and CLASS in cache that proves the non existance of QTYPE. If there is no further prohibitive objections by December 8 this will be taken as consensus of the working group. -- Olaf DNSEXT co-chair ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Nov 27 10:30:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10562 for ; Thu, 27 Nov 2003 10:30:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1APNxu-0007JN-0n for namedroppers-data@psg.com; Thu, 27 Nov 2003 15:21:58 +0000 Received: from [195.47.254.20] (helo=mail.rfc.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1APNxi-0007J4-6R for namedroppers@ops.ietf.org; Thu, 27 Nov 2003 15:21:46 +0000 Received: from d43.nic-se.se (d43.nic-se.se [212.247.3.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rfc.se (Postfix) with ESMTP id 5A11F19573 for ; Thu, 27 Nov 2003 16:21:44 +0100 (CET) Date: Thu, 27 Nov 2003 16:21:41 +0100 (CET) From: Jakob Schlyter To: IETF DNSEXT WG Subject: nsec++ Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk my initial version of the draft respecifying the rdata format for nsec has been submitted to the drafts editor and can also be found at the following address: http://www.rfc.se/~jakob/ietf/draft-ietf-dnsext-nsec-rdata-00.txt please send comments to namedroppers, jakob -- to unsubscribe send a message to namedroppers-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 Nov 27 10:39:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10900 for ; Thu, 27 Nov 2003 10:39:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1APOAa-00086I-RZ for namedroppers-data@psg.com; Thu, 27 Nov 2003 15:35:04 +0000 Received: from [207.65.203.98] (helo=goose.ehsco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1APOAO-000855-3H for namedroppers@ops.ietf.org; Thu, 27 Nov 2003 15:34:52 +0000 Received: from [207.65.3.26] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 4.1.3) with ESMTP-TLS id 645281 for namedroppers@ops.ietf.org; Thu, 27 Nov 2003 13:20:34 -0600 Message-ID: <3FC61998.1020506@ehsco.com> Date: Thu, 27 Nov 2003 09:34:48 -0600 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: TTLs in QTYPE=* caching References: <20031126233540.37951.qmail@cr.yp.to> <20031122163032.83E6013966@sa.vix.com> <3FC2CE40.8000002@daimlerchrysler.com> <6.0.0.22.2.20031125131911.02e3b810@localhost> <3FC42517.4090404@daimlerchrysler.com> <21135.1069923559@munnari.OZ.AU> In-Reply-To: <21135.1069923559@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Robert Elz wrote: > Date: 26 Nov 2003 23:35:40 -0000 > From: "D. J. Bernstein" > Message-ID: <20031126233540.37951.qmail@cr.yp.to> > > | Suppose, for example, that a name has a 3600-second A record and a > | 60-second MX record. The cache receives a QTYPE=* query for that name. > | Two minutes later, it receives another. What happens? > > Kevin, if you respond to this - also explain what happens when the > cache receives a QTYPE=* query 30 seconds after the initial query > (with all of the same config as above). Easiest approach to making these queries cachable is to synchronize the TTLs of all the RRs in the response, and set a flag somewhere that a qtype=* query was made for the owner name. If there's any RRs for that name in memory, then you've got all of the RRs. This wouldn't be the first qtype to require extra processing. Being a little different doesn't mean impossible. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Nov 28 06:27:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24016 for ; Fri, 28 Nov 2003 06:27:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1APgcN-000DLa-VF for namedroppers-data@psg.com; Fri, 28 Nov 2003 11:16:59 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1APgbz-000DKz-Rp for namedroppers@ops.ietf.org; Fri, 28 Nov 2003 11:16:36 +0000 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id hASBGVn13318; Fri, 28 Nov 2003 18:16:32 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id hASBGCZ04508; Fri, 28 Nov 2003 18:16:13 +0700 (ICT) From: Robert Elz To: "Eric A. Hall" cc: namedroppers@ops.ietf.org Subject: Re: TTLs in QTYPE=* caching In-Reply-To: <3FC61998.1020506@ehsco.com> References: <3FC61998.1020506@ehsco.com> <20031126233540.37951.qmail@cr.yp.to> <20031122163032.83E6013966@sa.vix.com> <3FC2CE40.8000002@daimlerchrysler.com> <6.0.0.22.2.20031125131911.02e3b810@localhost> <3FC42517.4090404@daimlerchrysler.com> <21135.1069923559@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 Nov 2003 18:16:11 +0700 Message-ID: <25973.1070018171@munnari.OZ.AU> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Thu, 27 Nov 2003 09:34:48 -0600 From: "Eric A. Hall" Message-ID: <3FC61998.1020506@ehsco.com> | Easiest approach to making these queries cachable is to synchronize the | TTLs of all the RRs in the response, and set a flag somewhere that a | qtype=* query was made for the owner name. If there's any RRs for that | name in memory, then you've got all of the RRs. Aside from all the extra mechanism you'd have to assume was existing in the cache, before you could safely use this, this simply does not work. Assuming that all TTLs were already the same (the way people used to make master files, with the only TTL setting being the copy out of the SOA.minimum field), so the cache doesn't have to force it, this still doesn't work. Let that common TTL be 3600. Do a query at time X, get all the RR's. At time X+200 the auth servers all add a new RR to the name queried. Now, at X+500, send a QTYPE=* query (RD=1) (again) to the cache for the same name. Is the new RR included in the reply or not? If not, does the answer include all the RR's, as has been demanded that it include? If it does, how does it get there? This problem doesn't exist for normal (single type) queries, as the TTL is a promise (mostly ignored by admins, but that's not the protocol's fault) that the data will returned will remain valid for TTL seconds. It isn't even a problem for negative answers, as those include the SOA, and the SOA.minimum is supposed to indicate just how long you can cache a non-existence report. But here, we get neither - we have no TTL for the RR (RRset) of the new RR, so nothing to rely upon. We have no SOA so no information on how long we can hand out "doesn't exist" information. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Nov 28 11:13:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02519 for ; Fri, 28 Nov 2003 11:13:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1APl7A-000Nl1-Cg for namedroppers-data@psg.com; Fri, 28 Nov 2003 16:05:04 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1APl6x-000Nk6-PZ for namedroppers@ops.ietf.org; Fri, 28 Nov 2003 16:04:51 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id E6CE14E66F; Fri, 28 Nov 2003 17:04:50 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 6DEF94E4FF; Fri, 28 Nov 2003 17:04:50 +0100 (CET) Received: from x53.ripe.net (x53.ripe.net [193.0.1.53]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id hASG4o9V013290; Fri, 28 Nov 2003 17:04:50 +0100 Date: Fri, 28 Nov 2003 17:04:49 +0100 (CET) From: Bruce Campbell X-X-Sender: bc@x53.ripe.net To: Robert Elz Cc: "Eric A. Hall" , namedroppers@ops.ietf.org Subject: Re: TTLs in QTYPE=* caching In-Reply-To: <25973.1070018171@munnari.OZ.AU> Message-ID: References: <3FC61998.1020506@ehsco.com> <20031126233540.37951.qmail@cr.yp.to> <20031122163032.83E6013966@sa.vix.com> <3FC2CE40.8000002@daimlerchrysler.com> <6.0.0.22.2.20031125131911.02e3b810@localhost> <3FC42517.4090404@daimlerchrysler.com> <21135.1069923559@munnari.OZ.AU> <25973.1070018171@munnari.OZ.AU> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RIPE-Spam-Status: N 0.256365 X-RIPE-Signature: cc64bb9909f4ea405f7db5c3ccd305c2 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 28 Nov 2003, Robert Elz wrote: > From: "Eric A. Hall" > | Easiest approach to making these queries cachable is to synchronize the > | TTLs of all the RRs in the response, and set a flag somewhere that a > | qtype=* query was made for the owner name. If there's any RRs for that > | name in memory, then you've got all of the RRs. > > Let that common TTL be 3600. Do a query at time X, get all the RR's. > At time X+200 the auth servers all add a new RR to the name queried. > Now, at X+500, send a QTYPE=* query (RD=1) (again) to the cache for > the same name. Is the new RR included in the reply or not? Assuming the cache has not requeried between X and X+500, the X+200 RR will not be in the cache or in the answer supplied. > If not, does the answer include all the RR's, as has been demanded that > it include? The answer contains all of the RR's as of the previous time that the cache queried the auth nameservers (time X), as expected. For the cache to have knowledge of RRs added since the previous time, it must have requeried for the information, thus defeating the purpose of having a cache. So any answers for QTYPE=* that are fulfilled by a cache are only valid for when the cache last made that query, and may bear little, if any, relationship to the current RR set for QTYPE=* returned by the auth servers. For situations where there isn't a common TTL, after the expiration of the shortest TTL, the cache should forget that all those RRs were the result of QTYPE=* (ie, remove the association between them) and then let them expire in their own individual time as per normal. --==-- Bruce. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Nov 29 01:12:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24738 for ; Sat, 29 Nov 2003 01:12:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1APyC0-000AfG-Bv for namedroppers-data@psg.com; Sat, 29 Nov 2003 06:02:56 +0000 Received: from [18.7.21.83] (helo=pacific-carrier-annex.mit.edu) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1APyBo-000AeH-6s for namedroppers@ops.ietf.org; Sat, 29 Nov 2003 06:02:44 +0000 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id hAT62hkT015706 for ; Sat, 29 Nov 2003 01:02:43 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id hAT62gIT015222 for ; Sat, 29 Nov 2003 01:02:42 -0500 (EST) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id hAT62cRY010567 for ; Sat, 29 Nov 2003 01:02:40 -0500 (EST) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id hAT62Yse016301; Sat, 29 Nov 2003 01:02:34 -0500 Subject: Re: Issue: Add a new QTYPE From: Greg Hudson To: namedroppers@ops.ietf.org In-Reply-To: <20031126232927.31805.qmail@cr.yp.to> References: <20031122163032.83E6013966@sa.vix.com> <3FC2CE40.8000002@daimlerchrysler.com> <6.0.0.22.2.20031125131911.02e3b810@localhost> <20031126232927.31805.qmail@cr.yp.to> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1070085753.14143.85.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Sat, 29 Nov 2003 01:02:34 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_NJABL, RCVD_IN_NJABL_RELAY autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2003-11-26 at 18:29, D. J. Bernstein wrote: > QTYPE=* can be used to check for CNAME records. RFC 1034 prohibits > non-CNAME records at a name that has a CNAME record, so if QTYPE=* > returns any non-CNAME records then there are no CNAME records. Pardon my confusion here. Let's say that we have foo.example.com CNAME bar.example.com bar.example.com MX 0 baz.example.com baz.example.com A 1.2.3.4 If I make a query to a recursive nameserver for foo.example.com MX, I should see the CNAME and MX records in the answer section, as far as I know. I can do my SMTP rewriting by looking at the value of the CNAME record. Why do I have to do a * query? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Nov 30 14:14:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09034 for ; Sun, 30 Nov 2003 14:14:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AQWsF-000LaJ-HS for namedroppers-data@psg.com; Sun, 30 Nov 2003 19:04:51 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AQWs2-000LZq-V6 for namedroppers@ops.ietf.org; Sun, 30 Nov 2003 19:04:39 +0000 Received: (qmail 65468 invoked by uid 1016); 30 Nov 2003 19:05:00 -0000 Date: 30 Nov 2003 19:05:00 -0000 Message-ID: <20031130190500.65467.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: Issue: Add a new QTYPE References: <20031122163032.83E6013966@sa.vix.com> <3FC2CE40.8000002@daimlerchrysler.com> <6.0.0.22.2.20031125131911.02e3b810@localhost> <20031126232927.31805.qmail@cr.yp.to> <1070085753.14143.85.camel@error-messages.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Greg Hudson writes: > I make a query to a recursive nameserver for foo.example.com MX [ then the response shows whether foo.example.com has a CNAME record ] That's just as hard to parse as *, sometimes slower, and never faster. What point are you trying to make? If you're thinking ``I get the CNAME information for free because I'm doing an MX query anyway,'' you're correct for RCPT commands---but the RFC 1123 non-CNAME requirement also applies to MAIL commands. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: