From owner-namedroppers@ops.ietf.org Sat Apr 1 05:07:14 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07703 for ; Sat, 1 Apr 2000 05:07:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12bJxr-000Gr9-00 for namedroppers-data@psg.com; Sat, 01 Apr 2000 01:13:07 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12bJxr-000Gr3-00 for namedroppers@ops.ietf.org; Sat, 01 Apr 2000 01:13:07 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12bJxq-0002ZR-00 for namedroppers@ops.ietf.org; Sat, 01 Apr 2000 01:13:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19398D273324D3118A2B0008C7E9A5690AD7151E@SIT.platinum.corp.microsoft.com> From: Levon Esibov To: "'namedroppers@ops.ietf.org'" Subject: Is there any DNS client implementation that supports DNSSEC but d oesn't support EDNS0 Date: Fri, 31 Mar 2000 17:24:52 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I'd like to find out whether there is any DNS client implementation that supports DNSSEC but doesn't support EDNS0. Here is why I ask this question: Currently majority of the deployed DNS clients do not support DNSSEC. Introduction of the DNS servers supporting DNSSEC and deployment of the DNSSEC will generate useless (for the DNS clients that don't support DNSSEC) traffic. The useless traffic that I refer to is associated with a scenario when the response to a query will be longer than 512 because response contains the DNSSEC-specific records and the truncation bit will be set and the client will reissue a query over tcp and will receive the tcp response that contains the DNSSEC-specific records that are not used by the clients. We could reduce such traffic if the DNS servers will include DNSSEC-specific records when responding only to those queries that contain OPT RR. The question is: can we assume that if client doesn't support EDNS0 (i.e. its queries don't contain OPT RR), then it also doesn't support DNSSEC? Comments? Thanks, Levon. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Apr 1 13:41:19 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10778 for ; Sat, 1 Apr 2000 13:41:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12bRa8-000Jm7-00 for namedroppers-data@psg.com; Sat, 01 Apr 2000 09:21:08 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12bRa7-000Jm1-00 for namedroppers@ops.ietf.org; Sat, 01 Apr 2000 09:21:07 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12bRa6-0004SI-00 for namedroppers@ops.ietf.org; Sat, 01 Apr 2000 09:21:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200004011606.IAA88657@redpaul.mibh.net> To: "'namedroppers@ops.ietf.org'" Subject: Re: Is there any DNS client implementation that supports DNSSEC but d oesn't support EDNS0 In-reply-to: Your message of "Fri, 31 Mar 2000 17:24:52 PST." <19398D273324D3118A2B0008C7E9A5690AD7151E@SIT.platinum.corp.microsoft.com> Date: Sat, 01 Apr 2000 08:06:16 -0800 From: Paul A Vixie Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The question is: can we assume that if client doesn't support EDNS0 (i.e. > its queries don't contain OPT RR), then it also doesn't support DNSSEC? Yes. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 3 15:39:13 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22799 for ; Mon, 3 Apr 2000 15:39:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12cBgJ-00027U-00 for namedroppers-data@psg.com; Mon, 03 Apr 2000 11:34:35 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12cBgJ-00027O-00 for namedroppers@ops.ietf.org; Mon, 03 Apr 2000 11:34:35 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12cBgI-000J3e-00 for namedroppers@ops.ietf.org; Mon, 03 Apr 2000 11:34:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 3 Apr 2000 20:32:16 +0200 (CEST) From: Roy Arends To: DNSEXT WG Mailing list Subject: Question regarding the AD bit according to RFC2535. Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I've a little trouble understanding the value of the AD bit in a response. According to RFC2535: 1. In section 6.1 it states: "The AD (authentic data) bit indicates in a response that all the data included in the answer and authority portion of the response has been authenticated by the server according to the policies of that server." The definition of authenticated data: 2. In section 6. it states: "Authenticated means that the data has a valid SIG under a KEY traceable via a chain of zero or more SIG and KEY RRs allowed by the resolvers policies to a KEY staticly configured at the resolver." But is seems to contradict with the following statement in: 3. In section 6.1 last paragraph: "For non-security aware resolvers or security aware resolvers requesting service by having the CD bit clear, security aware servers MUST return only Authenticated or Insecure data in the answer and authority sections with the AD bit set in the response." And also with the statement in: 4. Appendix B: part 9: "The AD bit only indicates that the answer and authority sections of the response are authoritative." In short: 1 and 2 looks like the AD bit is indicating that the returned data is cryptographically checked. 3 and 4 looks like the AD bit is indicating that the returned data is either cryptographically secure or is data from an insecure zone. Can anyone clearify this matter ? TIA, regards, Roy Arends -- roy@nlnetlabs.nl NLnet Labs tel +31208884551 Kruislaan 419 |\ || _ _|_ | _ |_ _ 1098 VA Amsterdam | \||__| )(-|_ |__(_||_)_) The Netherlands to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Apr 4 11:04:31 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05691 for ; Tue, 4 Apr 2000 11:04:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12cUAB-000AP2-00 for namedroppers-data@psg.com; Tue, 04 Apr 2000 07:18:39 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12cUAA-000AOw-00 for namedroppers@ops.ietf.org; Tue, 04 Apr 2000 07:18:38 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12cUAA-000Ddf-00 for namedroppers@ops.ietf.org; Tue, 04 Apr 2000 07:18:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 4 Apr 2000 14:06:40 +0200 (CEST) From: Roy Arends To: Edward Lewis cc: DNSEXT WG Mailing list Subject: Re: Question regarding the AD bit according to RFC2535. In-Reply-To: Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 4 Apr 2000, Edward Lewis wrote: > At 2:32 PM -0400 4/3/00, Roy Arends wrote: > >1 and 2 looks like the AD bit is indicating that the returned data is > >cryptographically checked. > > > >3 and 4 looks like the AD bit is indicating that the returned data is > >either cryptographically secure or is data from an insecure zone. > > IMHO, the intent is the latter. (Lemme, check first, the set of data > meeting the first criterion is a subset of the set of data meeting the > second, right?) Right. Thanks for clearing this up. > That being said, there has been further discussion on the meaning of the AD > bit. Some implementers have been questioning having it include data in > the additional sections, e.g., glue data. > > It is possible that the definition of the AD bit could represent an > amplification tool for denial of service attacks. By having arbitrarily > long additional sections, an attacker could have a secure resolver spend > CPU cycles verifying unrelated data just to achieve the AD setting. This > may not be true, but it has come up in discussions. The additional records section contains RRs which relate to the query, but are not strictly answers for the question. Having them verified is extra work that might not be neccesary. OTOH, not verifing it might result in another query for data previously in the additional section, and now this data has to be checked alltogether, which is more demanding (ergo larger DOS potential) then the first. Thanks, regards, Roy. > PS - I thought the WG had determined that there would be an AD-bit > clarification draft in the future, to summarize these ideas and propose a > (potentially) safer meaning to the 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. From owner-namedroppers@ops.ietf.org Tue Apr 4 11:10:59 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05692 for ; Tue, 4 Apr 2000 11:04:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12cU3b-000AKE-00 for namedroppers-data@psg.com; Tue, 04 Apr 2000 07:11:51 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12cU3a-000AK8-00 for namedroppers@ops.ietf.org; Tue, 04 Apr 2000 07:11:50 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12cU3a-000DbX-00 for namedroppers@ops.ietf.org; Tue, 04 Apr 2000 07:11:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: Date: Tue, 4 Apr 2000 07:07:31 -0400 To: Roy Arends From: Edward Lewis Subject: Re: Question regarding the AD bit according to RFC2535. Cc: DNSEXT WG Mailing list Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 2:32 PM -0400 4/3/00, Roy Arends wrote: >1 and 2 looks like the AD bit is indicating that the returned data is >cryptographically checked. > >3 and 4 looks like the AD bit is indicating that the returned data is >either cryptographically secure or is data from an insecure zone. IMHO, the intent is the latter. (Lemme, check first, the set of data meeting the first criterion is a subset of the set of data meeting the second, right?) That being said, there has been further discussion on the meaning of the AD bit. Some implementers have been questioning having it include data in the additional sections, e.g., glue data. It is possible that the definition of the AD bit could represent an amplification tool for denial of service attacks. By having arbitrarily long additional sections, an attacker could have a secure resolver spend CPU cycles verifying unrelated data just to achieve the AD setting. This may not be true, but it has come up in discussions. PS - I thought the WG had determined that there would be an AD-bit clarification draft in the future, to summarize these ideas and propose a (potentially) safer meaning to the bit. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "Trying is the first step to failure." - Homer Simpson "No! Try not. Do... or do not. There is no try." - Yoda "It takes years of training to know when to do nothing" - Dogbert 1/21/00 Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Apr 4 13:35:58 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10029 for ; Tue, 4 Apr 2000 13:35:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12cWfH-000CDk-00 for namedroppers-data@psg.com; Tue, 04 Apr 2000 09:58:55 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12cWfH-000CDd-00 for namedroppers@ops.ietf.org; Tue, 04 Apr 2000 09:58:55 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12cWfH-000EX3-00 for namedroppers@ops.ietf.org; Tue, 04 Apr 2000 09:58:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 4 Apr 2000 18:37:18 +0200 (CEST) From: Roy Arends To: "Donald E. Eastlake 3rd" cc: DNSEXT WG Mailing list Subject: Re: Question regarding the AD bit according to RFC2535. In-Reply-To: <200004041616.MAA00604@torque.pothole.com> Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 4 Apr 2000, Donald E. Eastlake 3rd wrote: > Hi, > > >Hello, > > > >I've a little trouble understanding the value of the AD bit in a response. [cut] > >3 and 4 looks like the AD bit is indicating that the returned data is > >either cryptographically secure or is data from an insecure zone. > > That was the intent, where "insecure" is defined from the point of > view of that server and depends on what keys it has staticly > configured, what algorithms it implements, etc. > > Hope this is helpful, > Donald Very helpful. Thanks, regards, Roy. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Apr 4 13:37:54 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10088 for ; Tue, 4 Apr 2000 13:37:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12cWci-000CBH-00 for namedroppers-data@psg.com; Tue, 04 Apr 2000 09:56:16 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12cWci-000CBB-00 for namedroppers@ops.ietf.org; Tue, 04 Apr 2000 09:56:16 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12cWci-000EWB-00 for namedroppers@ops.ietf.org; Tue, 04 Apr 2000 09:56:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200004041616.MAA00604@torque.pothole.com> To: Roy Arends cc: DNSEXT WG Mailing list Subject: Re: Question regarding the AD bit according to RFC2535. In-reply-to: Your message of "Mon, 03 Apr 2000 20:32:16 +0200." Date: Tue, 04 Apr 2000 12:16:20 -0400 From: "Donald E. Eastlake 3rd" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, From: Roy Arends Date: Mon, 3 Apr 2000 20:32:16 +0200 (CEST) To: DNSEXT WG Mailing list Message-ID: >Hello, > >I've a little trouble understanding the value of the AD bit in a response. > >According to RFC2535: > >1. In section 6.1 it states: > "The AD (authentic data) bit indicates in a response that all the data > included in the answer and authority portion of the response has been > authenticated by the server according to the policies of that server." The intent was to mean that the data had passed all the checks the server was going to impose. This includes data that can not be cryptographically verified because it is in an unsigned zone or a zone such that the server does not have a key for that zone, or an ancestor, staticly configured etc... Note that it specifies the answer and authority portions so, by impliation, the AD bit was intended to say nothing about the additional information section. >The definition of authenticated data: > >2. In section 6. it states: > "Authenticated means that the data has a valid SIG under a KEY > traceable via a chain of zero or more SIG and KEY RRs allowed by the > resolvers policies to a KEY staticly configured at the resolver." The use of the word "Authenenticated" in the above qutoed sentence was in reference to the data statuses of Authenticated, Pending, Insecure, and Bad defined in Section 6. This usage is confusing. Perhpas it would have been better if this special usage of Authenticated were replaced by "Cryptographically Verified". >But is seems to contradict with the following statement in: > >3. In section 6.1 last paragraph: > "For non-security aware resolvers or security aware resolvers > requesting service by having the CD bit clear, security aware servers > MUST return only Authenticated or Insecure data in the answer and > authority sections with the AD bit set in the response." The above quoted sentence correctly describes the intent. >And also with the statement in: > >4. Appendix B: part 9: > "The AD bit only indicates that the answer and authority sections of > the response are authoritative." Appendix B is the list of changes from the previous version. The use of the word "authoritative" in the above quoted sentence is confusing because of the special meaning of "authoritative" in the DNS. This sentence is just pointing out that the additional information section isn't covered by the AD bit, something which RFC 2535 tries to clarify. The full section is: 9. It was clarified that the presence of the AD bit in a response does not apply to the additional information section or to glue address or delegation point NS RRs. The AD bit only indicates that the answer and authority sections of the response are authoritative. >In short: > >1 and 2 looks like the AD bit is indicating that the returned data is >cryptographically checked. The intent was to indicate that the data has passed whatever checks the server cares to impose, which should be cryptographic where possible, but can not in zones that are insecure from that server's point of view. >3 and 4 looks like the AD bit is indicating that the returned data is >either cryptographically secure or is data from an insecure zone. That was the intent, where "insecure" is defined from the point of view of that server and depends on what keys it has staticly configured, what algorithms it implements, etc. >Can anyone clearify this matter ? > >TIA, regards, > >Roy Arends >-- >roy@nlnetlabs.nl NLnet Labs >tel +31208884551 Kruislaan 419 >|\ || _ _|_ | _ |_ _ 1098 VA Amsterdam >| \||__| )(-|_ |__(_||_)_) The Netherlands Hope this is helpful, Donald =================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 65 Shindegan Hill Rd, RR#1 lde008@dma.isg.mot.com Carmel, NY 10512 USA +1 914-276-2668(h) +1 508-261-5434(w) to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Apr 6 11:26:24 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09767 for ; Thu, 6 Apr 2000 11:26:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12dDDG-0008hh-00 for namedroppers-data@psg.com; Thu, 06 Apr 2000 07:24:50 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12dDDF-0008hb-00 for namedroppers@ops.ietf.org; Thu, 06 Apr 2000 07:24:49 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12dDDF-0008Uo-00 for namedroppers@ops.ietf.org; Thu, 06 Apr 2000 07:24:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 6 Apr 2000 14:28:57 +0200 (CEST) From: Roy Arends To: DNSEXT WG Mailing list Subject: dnssec: super/subzone NULL keys Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, When a null-key for a subzone appears in its superzone, while the subzone itself has a key, the subzone key is more authoritative then the null key in its parent. Is there any problem for this superzone to keep the null key in its zone ? The reason I ask this is when a large delegation only zone (g/ccTLD's for instance) is secure, and it has subs that are not willing to (or can not) include keys, the super has to have null-keys for them. Instead of having a null-key for allmost every single delegation (at first, most delegated zones will not be secure), a wild-card null key (* KEY 49408 3 3) can be added, making the zone less redundant. Are there any problems with this sceme ? (I know about the additional complexity (regarding NXT RR) due to wildcards). TIA Roy Arends -- roy@nlnetlabs.nl NLnetLabs tel +31208884551 Kruislaan 419 |\ || _ _|_ | _ |_ _ 1098 VA Amsterdam | \||__| )(-|_ |__(_||_)_) The Netherlands to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Apr 6 12:18:18 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10535 for ; Thu, 6 Apr 2000 12:18:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12dEE7-0009Cd-00 for namedroppers-data@psg.com; Thu, 06 Apr 2000 08:29:47 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12dEE6-0009CX-00 for namedroppers@ops.ietf.org; Thu, 06 Apr 2000 08:29:46 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12dEE6-0008oR-00 for namedroppers@ops.ietf.org; Thu, 06 Apr 2000 08:29:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Roy Arends Cc: DNSEXT WG Mailing list Subject: Re: dnssec: super/subzone NULL keys In-Reply-To: Your message of "Thu, 06 Apr 2000 14:28:57 +0200." Date: Fri, 07 Apr 2000 01:27:55 +1000 Message-Id: <7610.955034875@munnari.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Thu, 6 Apr 2000 14:28:57 +0200 (CEST) From: Roy Arends Message-ID: | a null-key for allmost every single delegation (at first, most delegated | zones will not be secure), a wild-card null key (* KEY 49408 3 3) can be | added, making the zone less redundant. No it can't, wildcards don't work like 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. From owner-namedroppers@ops.ietf.org Thu Apr 6 12:35:03 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10866 for ; Thu, 6 Apr 2000 12:35:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12dEeM-0009T1-00 for namedroppers-data@psg.com; Thu, 06 Apr 2000 08:56:54 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12dEeM-0009Sv-00 for namedroppers@ops.ietf.org; Thu, 06 Apr 2000 08:56:54 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12dEeL-0008wN-00 for namedroppers@ops.ietf.org; Thu, 06 Apr 2000 08:56:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200004061549.IAA24847@sh.lh.vix.com> To: Roy Arends cc: DNSEXT WG Mailing list Subject: Re: dnssec: super/subzone NULL keys In-reply-to: Your message of "Thu, 06 Apr 2000 14:28:57 +0200." Date: Thu, 06 Apr 2000 08:49:57 -0700 From: Jerry Scharf Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In the latest rev of secure DNS, the the delegation logic was changed such that the parent is no longer reqiured to keep the key for the child if the child is secure. So if you find a parent zone running secure and no null key, you have to go to the child's NS list and ask for the keys if they don't come in the authority section of a query. There were strong operational drives to get the live keys out of the parent zone. Since the null key is an explicit statement that the zone is not secured, your solution seems to create a level of ambiguiry. I would fear that could cause too many implementation depenent actions. jerry to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body.