From ben at algroup.co.uk Fri Sep 1 07:08:49 2006 From: ben at algroup.co.uk (Ben Laurie) Date: Fri, 01 Sep 2006 12:08:49 +0100 Subject: [dnssec-deployment] KSK, ZSK and registry data escrow In-Reply-To: References: Message-ID: <44F814C1.3020400@algroup.co.uk> Peter Koch wrote: > Steve, > >> Thanks for bringing this up. I hadn't tracked this through the >> entire process, but I think I did say something about this during the >> comment process. > > the comments were a bit tedious to walk through due to the interface and their > sheer number, being dominated by the pricing issue. Apologies, I must have > missed your response. > >> If want to suggest something more appropriate, I'll be glad to >> shepherd it through the ICANN system. > > Well, I couldn't claim stating something "more" appropriate without having > seen what was already said to this topic, and even then ... > > Trust anchor rollover comes to mind as a reason to keep/reuse the old key, > but would it still be "good" for this operation? Only if you think the root is not the one true trust anchor - and although I think that, I'll bet ICANN don't. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff From galvin at elistx.com Sun Sep 3 13:33:37 2006 From: galvin at elistx.com (James M Galvin) Date: Sun, 03 Sep 2006 13:33:37 -0400 Subject: meeting scheduled for 13 September 2006 Message-ID: This is a reminder that we will not be having a plenary meeting on Wednesday, 6 September 2006. The plenary meeting has been scheduled for Wednesday, 13 September 2006, at the usual time (3pm Eastern). The agenda will focus on test beds, what is available, how to use them, what results we get, and how they fit into the transition. There will be more to say later in the week. Jim From marcus.sachs at sri.com Wed Sep 6 09:47:39 2006 From: marcus.sachs at sri.com (Marcus H. Sachs - SRI) Date: Wed, 6 Sep 2006 09:47:39 -0400 Subject: BIND DNSSEC vulnerability Message-ID: <03ac01c6d1bb$050ac800$b15030c0@CSLWDC> This was made public late yesterday. Marc Marcus H. Sachs, P.E. SRI International 1100 Wilson Blvd Suite 2800, Arlington VA 22209 tel +1 703 247 8717 fax +1 703 247 8569 mob +1 703 932 3984 marcus.sachs at sri.com ======= http://www.kb.cert.org/vuls/id/915404 Vulnerability Note VU#915404 BIND vulnerable to an assertion failure when querying for SIG records Overview A vulnerability in the BIND name server could allow a remote attacker to cause a denial of service against an affected system. I. Description The Berkeley Internet Name Domain (BIND) is a popular Domain Name System (DNS) implementation from Internet Systems Consortium (ISC). A flaw exists in the way that some versions of BIND handle DNS Security Extensions (DNSSEC) signed Resource Record Sets (RRsets). The specific impact of this vulnerability is slightly different depending on the type of DNS server involved. For recursive servers, queries for SIG records will trigger a assertion failure if more than one SIG(covered) RRset is returned. For authoritative servers, if a nameserver is serving a RFC 2535 DNSSEC zone and is queried for the SIG records where there are multiple SIG(covered) RRsets (e.g. a zone apex) then the name server daemon will trigger a assertion failure when it tries to construct the response. This vulnerability affects BIND 9.3.x versions 9.3.0, 9.3.1, 9.3.2, 9.3.3b, and 9.3.3rc1 and BIND 9.4.x versions 9.4.0a1, 9.4.0a2, 9.4.0a3, 9.4.0a4, 9.4.0a5, 9.4.0a6 and 9.4.0b1. II. Impact A remote attacker may be able to cause the name server daemon to crash, thereby causing a denial of service for DNS operations. III. Solution Apply a patch from the vendor Patches have been released in response to this issue. Please see the Systems Affected section of this document. Upgrade Users who compile their own versions of BIND from the original ISC source code are encouraged to upgrade to BIND 9.3.2-P1. Patches for this issue are also included in BIND versions 9.3.3rc2 and 9.4.0b2. Patched versions of the software are available from the BIND download page. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4688 bytes Desc: not available Url : http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20060906/f19254c6/attachment.bin From bmanning at vacation.karoshi.com Wed Sep 6 09:57:25 2006 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 6 Sep 2006 13:57:25 +0000 Subject: [dnssec-deployment] BIND DNSSEC vulnerability In-Reply-To: References: Message-ID: <20060906135725.GA7396@vacation.karoshi.com.> patched vulnerable systems over the past weekend. (had to patch the patch! :) --bill On Wed, Sep 06, 2006 at 09:47:39AM -0400, Marcus H. Sachs - SRI wrote: > This was made public late yesterday. > > Marc > > > Marcus H. Sachs, P.E. > SRI International > 1100 Wilson Blvd Suite 2800, Arlington VA 22209 > tel +1 703 247 8717 fax +1 703 247 8569 > mob +1 703 932 3984 marcus.sachs at sri.com > > > ======= > http://www.kb.cert.org/vuls/id/915404 > > Vulnerability Note VU#915404 > BIND vulnerable to an assertion failure when querying for SIG records > > Overview > A vulnerability in the BIND name server could allow a remote attacker to > cause a denial of service against an affected system. > > I. Description > The Berkeley Internet Name Domain (BIND) is a popular Domain Name System > (DNS) implementation from Internet Systems Consortium (ISC). A flaw exists > in the way that some versions of BIND handle DNS Security Extensions > (DNSSEC) signed Resource Record Sets (RRsets). > > The specific impact of this vulnerability is slightly different depending on > the type of DNS server involved. For recursive servers, queries for SIG > records will trigger a assertion failure if more than one SIG(covered) RRset > is returned. For authoritative servers, if a nameserver is serving a RFC > 2535 DNSSEC zone and is queried for the SIG records where there are multiple > SIG(covered) RRsets (e.g. a zone apex) then the name server daemon will > trigger a assertion failure when it tries to construct the response. > > This vulnerability affects BIND 9.3.x versions 9.3.0, 9.3.1, 9.3.2, 9.3.3b, > and 9.3.3rc1 and BIND 9.4.x versions 9.4.0a1, 9.4.0a2, 9.4.0a3, 9.4.0a4, > 9.4.0a5, 9.4.0a6 and 9.4.0b1. > > II. Impact > A remote attacker may be able to cause the name server daemon to crash, > thereby causing a denial of service for DNS operations. > > III. Solution > Apply a patch from the vendor > > Patches have been released in response to this issue. Please see the Systems > Affected section of this document. > > Upgrade > > Users who compile their own versions of BIND from the original ISC source > code are encouraged to upgrade to BIND 9.3.2-P1. Patches for this issue are > also included in BIND versions 9.3.3rc2 and 9.4.0b2. Patched versions of the > software are available from the BIND download page. From bmanning at vacation.karoshi.com Wed Sep 6 16:23:33 2006 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 6 Sep 2006 20:23:33 +0000 Subject: been up too long for this Message-ID: <20060906202333.GA10275@vacation.karoshi.com.> Sep 6 13:20:20 bit named[24789]: not insecure resolving '31.83.in-addr.arpa/DS/IN': 2001:478:3::0:42#53 ... not insecure resolving... ??? --bill From bmanning at vacation.karoshi.com Thu Sep 7 16:26:25 2006 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 7 Sep 2006 20:26:25 +0000 Subject: yet another resource constraint Message-ID: <20060907202625.GA18494@vacation.karoshi.com.> so... disk size has come up. yeah, the zones get bigger. this might be more fun. in a default configuration (with DNSSEC enabled) and trusted keys only for the root... (yeah, its my own private hell) -rw-r--r-- 1 root root 1609523200 Sep 6 20:22 daemon in a 30 hour window... with lots and lots of this ... Sep 7 12:40:40 dot named[767]: no valid DS resolving '901560.50.197.16.69.in-addr.arpa/SOA/IN': 209.59.139.20#53 Sep 7 12:40:40 dot named[767]: no valid DS resolving '609735.50.197.16.69.in-addr.arpa/SOA/IN': 209.59.139.20#53 Sep 7 12:40:40 dot named[767]: no valid DS resolving '317084.50.197.16.69.in-addr.arpa/SOA/IN': 209.59.139.20#53 Sep 7 12:40:40 dot named[767]: no valid DS resolving '25303.50.197.16.69.in-addr.arpa/SOA/IN': 209.59.139.20#53 Sep 7 12:40:41 dot named[767]: no valid DS resolving '925700.176.187.59.69.in-addr.arpa/SOA/IN': 216.93.160.11#53 Sep 7 12:40:41 dot named[767]: no valid DS resolving '633639.176.187.59.69.in-addr.arpa/SOA/IN': 216.93.160.16#53 Sep 7 12:40:41 dot named[767]: no valid DS resolving '341245.176.187.59.69.in-addr.arpa/SOA/IN': 216.93.160.16#53 Sep 7 12:40:41 dot named[767]: no valid DS resolving '49407.176.187.59.69.in-addr.arpa/SOA/IN': 216.93.160.16#53 Sep 7 12:40:41 dot named[767]: not insecure resolving '72.69.in-addr.arpa/DS/IN': 2001:478:6::c620:242#53 Sep 7 12:40:41 dot named[767]: not insecure resolving '59.69.in-addr.arpa/DS/IN': 198.32.2.66#53 Sep 7 12:40:41 dot named[767]: not insecure resolving '201850.249.68.137.70.in-addr.arpa/SOA/IN': 198.32.2.66#53 Sep 7 12:40:41 dot named[767]: no valid DS resolving '113556743.234.3.87.70.in-addr.arpa/SOA/IN': 70.86.61.136#53 Sep 7 12:40:41 dot named[767]: no valid DS resolving '822358837.234.3.87.70.in-addr.arpa/SOA/IN': 70.86.61.133#53 Sep 7 12:40:41 dot named[767]: no valid DS resolving '529979750.234.3.87.70.in-addr.arpa/SOA/IN': 70.87.7.71#53 Sep 7 12:40:41 dot named[767]: no valid DS resolving '237175238.234.3.87.70.in-addr.arpa/SOA/IN': 70.87.7.72#53 Sep 7 12:40:41 dot named[767]: not insecure resolving '87.70.in-addr.arpa/DS/IN': 2001:478:6::c620:242#53 Sep 7 12:40:42 dot named[767]: unexpected RCODE (SERVFAIL) resolving '264426.240.75.97.129.in-addr.arpa/SOA/IN': 198.32.2.66#53 Sep 7 12:40:42 dot named[767]: unexpected RCODE (SERVFAIL) resolving '663667.240.75.97.129.in-addr.arpa/SOA/IN': 198.32.2.66#53 --bill From steve at shinkuro.com Thu Sep 7 16:42:48 2006 From: steve at shinkuro.com (Steve Crocker) Date: Thu, 7 Sep 2006 16:42:48 -0400 Subject: [dnssec-deployment] yet another resource constraint In-Reply-To: References: Message-ID: My age is showing. I don't understand what you're trying to convey. Can you translate into English? Thanks, Steve Steve Crocker steve at shinkuro.com Try Shinkuro's collaboration technology. Visit www.shinkuro.com. I am steve!shinkuro.com. On Sep 7, 2006, at 4:26 PM, bmanning at vacation.karoshi.com wrote: > > so... disk size has come up. > > yeah, the zones get bigger. > > this might be more fun. in a default configuration (with DNSSEC > enabled) and > trusted keys only for the root... (yeah, its my own private hell) > > -rw-r--r-- 1 root root 1609523200 Sep 6 20:22 daemon > > in a 30 hour window... > > with lots and lots of this ... > > > Sep 7 12:40:40 dot named[767]: no valid DS resolving > '901560.50.197.16.69.in-addr.arpa/SOA/IN': 209.59.139.20#53 > Sep 7 12:40:40 dot named[767]: no valid DS resolving > '609735.50.197.16.69.in-addr.arpa/SOA/IN': 209.59.139.20#53 > Sep 7 12:40:40 dot named[767]: no valid DS resolving > '317084.50.197.16.69.in-addr.arpa/SOA/IN': 209.59.139.20#53 > Sep 7 12:40:40 dot named[767]: no valid DS resolving > '25303.50.197.16.69.in-addr.arpa/SOA/IN': 209.59.139.20#53 > Sep 7 12:40:41 dot named[767]: no valid DS resolving > '925700.176.187.59.69.in-addr.arpa/SOA/IN': 216.93.160.11#53 > Sep 7 12:40:41 dot named[767]: no valid DS resolving > '633639.176.187.59.69.in-addr.arpa/SOA/IN': 216.93.160.16#53 > Sep 7 12:40:41 dot named[767]: no valid DS resolving > '341245.176.187.59.69.in-addr.arpa/SOA/IN': 216.93.160.16#53 > Sep 7 12:40:41 dot named[767]: no valid DS resolving > '49407.176.187.59.69.in-addr.arpa/SOA/IN': 216.93.160.16#53 > Sep 7 12:40:41 dot named[767]: not insecure resolving '72.69.in- > addr.arpa/DS/IN': 2001:478:6::c620:242#53 > Sep 7 12:40:41 dot named[767]: not insecure resolving '59.69.in- > addr.arpa/DS/IN': 198.32.2.66#53 > Sep 7 12:40:41 dot named[767]: not insecure resolving > '201850.249.68.137.70.in-addr.arpa/SOA/IN': 198.32.2.66#53 > Sep 7 12:40:41 dot named[767]: no valid DS resolving > '113556743.234.3.87.70.in-addr.arpa/SOA/IN': 70.86.61.136#53 > Sep 7 12:40:41 dot named[767]: no valid DS resolving > '822358837.234.3.87.70.in-addr.arpa/SOA/IN': 70.86.61.133#53 > Sep 7 12:40:41 dot named[767]: no valid DS resolving > '529979750.234.3.87.70.in-addr.arpa/SOA/IN': 70.87.7.71#53 > Sep 7 12:40:41 dot named[767]: no valid DS resolving > '237175238.234.3.87.70.in-addr.arpa/SOA/IN': 70.87.7.72#53 > Sep 7 12:40:41 dot named[767]: not insecure resolving '87.70.in- > addr.arpa/DS/IN': 2001:478:6::c620:242#53 > Sep 7 12:40:42 dot named[767]: unexpected RCODE (SERVFAIL) > resolving '264426.240.75.97.129.in-addr.arpa/SOA/IN': 198.32.2.66#53 > Sep 7 12:40:42 dot named[767]: unexpected RCODE (SERVFAIL) > resolving '663667.240.75.97.129.in-addr.arpa/SOA/IN': 198.32.2.66#53 > > > --bill > > > ############################################################# > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > A public archive is available here: Lists/dnssec-deployment/> > and older material is at > From thierry.moreau at connotech.com Thu Sep 7 16:53:05 2006 From: thierry.moreau at connotech.com (Thierry Moreau) Date: Thu, 07 Sep 2006 16:53:05 -0400 Subject: [dnssec-deployment] yet another resource constraint In-Reply-To: References: Message-ID: <450086B1.7060809@connotech.com> bmanning at vacation.karoshi.com wrote: > so... disk size has come up. > > yeah, the zones get bigger. > > this might be more fun. in a default configuration (with DNSSEC enabled) and > trusted keys only for the root... (yeah, its my own private hell) > > -rw-r--r-- 1 root root 1609523200 Sep 6 20:22 daemon > > in a 30 hour window... > May I suggest you don't panic too fast before the bulk of this huge log file is cleaned up by straightforward actions (my 0.02 cents advice): 1) Part of the SLD (and below) in .arpa zone is signed (by ripe NCC). This would explain the "no valid DS" messages. So, extend your own private thing to sign the .arpa zone with the DS records that correspond to the trusted keys by ripe NCC, or go to step 2) 2) Once a particular log message is understood and considered harmless, isn't it normal to remove it at the source? I.e. it seems that either your "default configuration" setup needs refined configuration and/or the bind source code require patch about which log message gets which priority, class , category, or whatever. Anyway, thanks for sharing this snapshot from your lab bench with us. > with lots and lots of this ... > > > Sep 7 12:40:40 dot named[767]: no valid DS resolving '901560.50.197.16.69.in-addr.arpa/SOA/IN': 209.59.139.20#53 > Sep 7 12:40:40 dot named[767]: no valid DS resolving '609735.50.197.16.69.in-addr.arpa/SOA/IN': 209.59.139.20#53 > Sep 7 12:40:40 dot named[767]: no valid DS resolving '317084.50.197.16.69.in-addr.arpa/SOA/IN': 209.59.139.20#53 > Sep 7 12:40:40 dot named[767]: no valid DS resolving '25303.50.197.16.69.in-addr.arpa/SOA/IN': 209.59.139.20#53 > Sep 7 12:40:41 dot named[767]: no valid DS resolving '925700.176.187.59.69.in-addr.arpa/SOA/IN': 216.93.160.11#53 > Sep 7 12:40:41 dot named[767]: no valid DS resolving '633639.176.187.59.69.in-addr.arpa/SOA/IN': 216.93.160.16#53 > Sep 7 12:40:41 dot named[767]: no valid DS resolving '341245.176.187.59.69.in-addr.arpa/SOA/IN': 216.93.160.16#53 > Sep 7 12:40:41 dot named[767]: no valid DS resolving '49407.176.187.59.69.in-addr.arpa/SOA/IN': 216.93.160.16#53 > Sep 7 12:40:41 dot named[767]: not insecure resolving '72.69.in-addr.arpa/DS/IN': 2001:478:6::c620:242#53 > Sep 7 12:40:41 dot named[767]: not insecure resolving '59.69.in-addr.arpa/DS/IN': 198.32.2.66#53 > Sep 7 12:40:41 dot named[767]: not insecure resolving '201850.249.68.137.70.in-addr.arpa/SOA/IN': 198.32.2.66#53 > Sep 7 12:40:41 dot named[767]: no valid DS resolving '113556743.234.3.87.70.in-addr.arpa/SOA/IN': 70.86.61.136#53 > Sep 7 12:40:41 dot named[767]: no valid DS resolving '822358837.234.3.87.70.in-addr.arpa/SOA/IN': 70.86.61.133#53 > Sep 7 12:40:41 dot named[767]: no valid DS resolving '529979750.234.3.87.70.in-addr.arpa/SOA/IN': 70.87.7.71#53 > Sep 7 12:40:41 dot named[767]: no valid DS resolving '237175238.234.3.87.70.in-addr.arpa/SOA/IN': 70.87.7.72#53 > Sep 7 12:40:41 dot named[767]: not insecure resolving '87.70.in-addr.arpa/DS/IN': 2001:478:6::c620:242#53 > Sep 7 12:40:42 dot named[767]: unexpected RCODE (SERVFAIL) resolving '264426.240.75.97.129.in-addr.arpa/SOA/IN': 198.32.2.66#53 > Sep 7 12:40:42 dot named[767]: unexpected RCODE (SERVFAIL) resolving '663667.240.75.97.129.in-addr.arpa/SOA/IN': 198.32.2.66#53 > > -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau at connotech.com From bmanning at vacation.karoshi.com Thu Sep 7 17:05:52 2006 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 7 Sep 2006 21:05:52 +0000 Subject: [dnssec-deployment] yet another resource constraint In-Reply-To: <450086B1.7060809@connotech.com> References: <450086B1.7060809@connotech.com> Message-ID: <20060907210552.GA18645@vacation.karoshi.com.> On Thu, Sep 07, 2006 at 04:53:05PM -0400, Thierry Moreau wrote: > bmanning at vacation.karoshi.com wrote: > > >so... disk size has come up. > > > > yeah, the zones get bigger. > > > >this might be more fun. in a default configuration (with DNSSEC enabled) > >and > >trusted keys only for the root... (yeah, its my own private hell) > > > >-rw-r--r-- 1 root root 1609523200 Sep 6 20:22 daemon > > > >in a 30 hour window... > > > > May I suggest you don't panic too fast before the bulk of this huge log > file is cleaned up by straightforward actions (my 0.02 cents advice): > > 1) Part of the SLD (and below) in .arpa zone is signed (by ripe NCC). > This would explain the "no valid DS" messages. So, extend your own > private thing to sign the .arpa zone with the DS records that correspond > to the trusted keys by ripe NCC, or go to step 2) > > 2) Once a particular log message is understood and considered harmless, > isn't it normal to remove it at the source? I.e. it seems that either > your "default configuration" setup needs refined configuration and/or > the bind source code require patch about which log message gets which > priority, class , category, or whatever. > > Anyway, thanks for sharing this snapshot from your lab bench with us. > gla to share (some things) not panicing - just a general observation that when a islands of trust exist (for whatever reason) then default BIND configuration WILL trash your log files -if- your not expecting it. so #1... unlinking trust chains generates log messages. and #2... yet more patching of the BIND source code is not what many/most folks do. perhaps the ISC folks will tweek logging. perhaps not. --bill From bmanning at vacation.karoshi.com Thu Sep 7 17:16:29 2006 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 7 Sep 2006 21:16:29 +0000 Subject: [dnssec-deployment] yet another resource constraint In-Reply-To: References: Message-ID: <20060907211629.GB18645@vacation.karoshi.com.> a few things: ) islands of trust, when unexpected, generate lots of log messages. the potential impact is that when there a dropped DS handoff occurs, not only does the zone go insecure, the validating resolvers log every attempt ... so the majority of the impact is on the third-party servers in recording the logged failures. ) the current BIND logging messages are less than inutitive. being told that there is no valid DS is fine, but the target is a little mysterious... '901560.50.197.16.69.in-addr.arpa/SOA/IN' does not parse so well. --bill (just throwing some benchwork over the wall) On Thu, Sep 07, 2006 at 04:42:48PM -0400, Steve Crocker wrote: > My age is showing. I don't understand what you're trying to convey. > Can you translate into English? > > Thanks, > > Steve > > > Steve Crocker > steve at shinkuro.com > > Try Shinkuro's collaboration technology. Visit www.shinkuro.com. I > am steve!shinkuro.com. > > > On Sep 7, 2006, at 4:26 PM, bmanning at vacation.karoshi.com wrote: > > > > >so... disk size has come up. > > > > yeah, the zones get bigger. > > > >this might be more fun. in a default configuration (with DNSSEC > >enabled) and > >trusted keys only for the root... (yeah, its my own private hell) > > > >-rw-r--r-- 1 root root 1609523200 Sep 6 20:22 daemon > > > >in a 30 hour window... > > > >with lots and lots of this ... > > > > > >Sep 7 12:40:40 dot named[767]: no valid DS resolving > >'901560.50.197.16.69.in-addr.arpa/SOA/IN': 209.59.139.20#53 > >Sep 7 12:40:40 dot named[767]: no valid DS resolving > >'609735.50.197.16.69.in-addr.arpa/SOA/IN': 209.59.139.20#53 > >Sep 7 12:40:40 dot named[767]: no valid DS resolving > >'317084.50.197.16.69.in-addr.arpa/SOA/IN': 209.59.139.20#53 > >Sep 7 12:40:40 dot named[767]: no valid DS resolving > >'25303.50.197.16.69.in-addr.arpa/SOA/IN': 209.59.139.20#53 > >Sep 7 12:40:41 dot named[767]: no valid DS resolving > >'925700.176.187.59.69.in-addr.arpa/SOA/IN': 216.93.160.11#53 > >Sep 7 12:40:41 dot named[767]: no valid DS resolving > >'633639.176.187.59.69.in-addr.arpa/SOA/IN': 216.93.160.16#53 > >Sep 7 12:40:41 dot named[767]: no valid DS resolving > >'341245.176.187.59.69.in-addr.arpa/SOA/IN': 216.93.160.16#53 > >Sep 7 12:40:41 dot named[767]: no valid DS resolving > >'49407.176.187.59.69.in-addr.arpa/SOA/IN': 216.93.160.16#53 > >Sep 7 12:40:41 dot named[767]: not insecure resolving '72.69.in- > >addr.arpa/DS/IN': 2001:478:6::c620:242#53 > >Sep 7 12:40:41 dot named[767]: not insecure resolving '59.69.in- > >addr.arpa/DS/IN': 198.32.2.66#53 > >Sep 7 12:40:41 dot named[767]: not insecure resolving > >'201850.249.68.137.70.in-addr.arpa/SOA/IN': 198.32.2.66#53 > >Sep 7 12:40:41 dot named[767]: no valid DS resolving > >'113556743.234.3.87.70.in-addr.arpa/SOA/IN': 70.86.61.136#53 > >Sep 7 12:40:41 dot named[767]: no valid DS resolving > >'822358837.234.3.87.70.in-addr.arpa/SOA/IN': 70.86.61.133#53 > >Sep 7 12:40:41 dot named[767]: no valid DS resolving > >'529979750.234.3.87.70.in-addr.arpa/SOA/IN': 70.87.7.71#53 > >Sep 7 12:40:41 dot named[767]: no valid DS resolving > >'237175238.234.3.87.70.in-addr.arpa/SOA/IN': 70.87.7.72#53 > >Sep 7 12:40:41 dot named[767]: not insecure resolving '87.70.in- > >addr.arpa/DS/IN': 2001:478:6::c620:242#53 > >Sep 7 12:40:42 dot named[767]: unexpected RCODE (SERVFAIL) > >resolving '264426.240.75.97.129.in-addr.arpa/SOA/IN': 198.32.2.66#53 > >Sep 7 12:40:42 dot named[767]: unexpected RCODE (SERVFAIL) > >resolving '663667.240.75.97.129.in-addr.arpa/SOA/IN': 198.32.2.66#53 > > > > > >--bill > > > > > >############################################################# > >This message is sent to you because you are subscribed to > > the mailing list . > >To unsubscribe, E-mail to: > >A public archive is available here: >Lists/dnssec-deployment/> > >and older material is at > > > > > ############################################################# > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > A public archive is available here: > > and older material is at > From Mark_Andrews at isc.org Thu Sep 7 18:45:29 2006 From: Mark_Andrews at isc.org (Mark Andrews) Date: Fri, 08 Sep 2006 08:45:29 +1000 Subject: [dnssec-deployment] yet another resource constraint In-Reply-To: Your message of "Thu, 07 Sep 2006 21:16:29 GMT." Message-ID: <200609072245.k87MjT9d051966@drugs.dv.isc.org> > > a few things: > > ) islands of trust, when unexpected, generate lots of log messages. > the potential impact is that when there a dropped DS handoff occurs, > not only does the zone go insecure, the validating resolvers log > every attempt ... so the majority of the impact is on the third-part > y > servers in recording the logged failures. It's not islands of trust causing this. It's a broken trust chain. Failure to update the DS's when the KSK's are changed can cause "no valid DS". "not insecure" is generated when you get a insecure response but should, according to DNSSEC, have got a secure response. Not having all the servers for a secure zone be dnssec aware and enabled can cause this as can recovering from stupid firewalls which block EDNS responses. > ) the current BIND logging messages are less than inutitive. > being told that there is no valid DS is fine, but the target is > a little mysterious... '901560.50.197.16.69.in-addr.arpa/SOA/IN' > does not parse so well. I can't help with the target. That generated by one of the nameservers clients. > --bill (just throwing some benchwork over the wall) > > > > > On Thu, Sep 07, 2006 at 04:42:48PM -0400, Steve Crocker wrote: > > My age is showing. I don't understand what you're trying to convey. > > Can you translate into English? > > > > Thanks, > > > > Steve > > > > > > Steve Crocker > > steve at shinkuro.com > > > > Try Shinkuro's collaboration technology. Visit www.shinkuro.com. I > > am steve!shinkuro.com. > > > > > > On Sep 7, 2006, at 4:26 PM, bmanning at vacation.karoshi.com wrote: > > > > > > > >so... disk size has come up. > > > > > > yeah, the zones get bigger. > > > > > >this might be more fun. in a default configuration (with DNSSEC > > >enabled) and > > >trusted keys only for the root... (yeah, its my own private hell) > > > > > >-rw-r--r-- 1 root root 1609523200 Sep 6 20:22 daemon > > > > > >in a 30 hour window... > > > > > >with lots and lots of this ... > > > > > > > > >Sep 7 12:40:40 dot named[767]: no valid DS resolving > > >'901560.50.197.16.69.in-addr.arpa/SOA/IN': 209.59.139.20#53 > > >Sep 7 12:40:40 dot named[767]: no valid DS resolving > > >'609735.50.197.16.69.in-addr.arpa/SOA/IN': 209.59.139.20#53 > > >Sep 7 12:40:40 dot named[767]: no valid DS resolving > > >'317084.50.197.16.69.in-addr.arpa/SOA/IN': 209.59.139.20#53 > > >Sep 7 12:40:40 dot named[767]: no valid DS resolving > > >'25303.50.197.16.69.in-addr.arpa/SOA/IN': 209.59.139.20#53 > > >Sep 7 12:40:41 dot named[767]: no valid DS resolving > > >'925700.176.187.59.69.in-addr.arpa/SOA/IN': 216.93.160.11#53 > > >Sep 7 12:40:41 dot named[767]: no valid DS resolving > > >'633639.176.187.59.69.in-addr.arpa/SOA/IN': 216.93.160.16#53 > > >Sep 7 12:40:41 dot named[767]: no valid DS resolving > > >'341245.176.187.59.69.in-addr.arpa/SOA/IN': 216.93.160.16#53 > > >Sep 7 12:40:41 dot named[767]: no valid DS resolving > > >'49407.176.187.59.69.in-addr.arpa/SOA/IN': 216.93.160.16#53 > > >Sep 7 12:40:41 dot named[767]: not insecure resolving '72.69.in- > > >addr.arpa/DS/IN': 2001:478:6::c620:242#53 > > >Sep 7 12:40:41 dot named[767]: not insecure resolving '59.69.in- > > >addr.arpa/DS/IN': 198.32.2.66#53 > > >Sep 7 12:40:41 dot named[767]: not insecure resolving > > >'201850.249.68.137.70.in-addr.arpa/SOA/IN': 198.32.2.66#53 > > >Sep 7 12:40:41 dot named[767]: no valid DS resolving > > >'113556743.234.3.87.70.in-addr.arpa/SOA/IN': 70.86.61.136#53 > > >Sep 7 12:40:41 dot named[767]: no valid DS resolving > > >'822358837.234.3.87.70.in-addr.arpa/SOA/IN': 70.86.61.133#53 > > >Sep 7 12:40:41 dot named[767]: no valid DS resolving > > >'529979750.234.3.87.70.in-addr.arpa/SOA/IN': 70.87.7.71#53 > > >Sep 7 12:40:41 dot named[767]: no valid DS resolving > > >'237175238.234.3.87.70.in-addr.arpa/SOA/IN': 70.87.7.72#53 > > >Sep 7 12:40:41 dot named[767]: not insecure resolving '87.70.in- > > >addr.arpa/DS/IN': 2001:478:6::c620:242#53 > > >Sep 7 12:40:42 dot named[767]: unexpected RCODE (SERVFAIL) > > >resolving '264426.240.75.97.129.in-addr.arpa/SOA/IN': 198.32.2.66#53 > > >Sep 7 12:40:42 dot named[767]: unexpected RCODE (SERVFAIL) > > >resolving '663667.240.75.97.129.in-addr.arpa/SOA/IN': 198.32.2.66#53 > > > > > > > > >--bill > > > > > > > > >############################################################# > > >This message is sent to you because you are subscribed to > > > the mailing list . > > >To unsubscribe, E-mail to: > > >A public archive is available here: > >Lists/dnssec-deployment/> > > >and older material is at > > > > > > > > > ############################################################# > > This message is sent to you because you are subscribed to > > the mailing list . > > To unsubscribe, E-mail to: > > A public archive is available here: > > > > and older material is at > > > > ############################################################# > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > A public archive is available here: ec-deployment/> > and older material is at > -- ISC Training! October 16-20, 2006, in the San Francisco Bay Area, covering topics from DNS to DHCP. Email training at isc.org. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From bmanning at vacation.karoshi.com Thu Sep 7 18:55:37 2006 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 7 Sep 2006 22:55:37 +0000 Subject: [dnssec-deployment] yet another resource constraint In-Reply-To: References: Message-ID: <20060907225537.GA19253@vacation.karoshi.com.> On Fri, Sep 08, 2006 at 08:45:29AM +1000, Mark Andrews wrote: > > > > > a few things: > > > > ) islands of trust, when unexpected, generate lots of log messages. > > the potential impact is that when there a dropped DS handoff occurs, > > not only does the zone go insecure, the validating resolvers log > > every attempt ... so the majority of the impact is on the third-party > > servers in recording the logged failures. > > It's not islands of trust causing this. It's a broken trust > chain. Failure to update the DS's when the KSK's are changed > can cause "no valid DS". tada!!! broken trust chains create "islands" n'est pas? > "not insecure" is generated when you get a insecure response > but should, according to DNSSEC, have got a secure response. > Not having all the servers for a secure zone be dnssec aware > and enabled can cause this as can recovering from stupid > firewalls which block EDNS responses. yup... > > ) the current BIND logging messages are less than inutitive. > > being told that there is no valid DS is fine, but the target is > > a little mysterious... '901560.50.197.16.69.in-addr.arpa/SOA/IN' > > does not parse so well. > > I can't help with the target. That generated by one of the > nameservers clients. the client generated the 901560.... bitstring? Ok, i'll buy that. but surely the client didn't write out the log entry on the server. not sure how to use that snippet of data to troubleshoot problems. the point remains, there are going to be -LOTS- of logged messages for validator machines w/ the default configuration from BIND. RAID futures anyone? :) --bill > > > --bill (just throwing some benchwork over the wall) From Mark_Andrews at isc.org Thu Sep 7 19:08:26 2006 From: Mark_Andrews at isc.org (Mark Andrews) Date: Fri, 08 Sep 2006 09:08:26 +1000 Subject: [dnssec-deployment] yet another resource constraint In-Reply-To: Your message of "Fri, 08 Sep 2006 08:45:29 +1000." Message-ID: <200609072308.k87N8QpN072747@drugs.dv.isc.org> > > a few things: > > > > ) islands of trust, when unexpected, generate lots of log messages. > > the potential impact is that when there a dropped DS handoff occurs, > > not only does the zone go insecure, the validating resolvers log > > every attempt ... so the majority of the impact is on the third-part > > y > > servers in recording the logged failures. > > It's not islands of trust causing this. It's a broken trust > chain. Failure to update the DS's when the KSK's are changed > can cause "no valid DS". > > "not insecure" is generated when you get a insecure response > but should, according to DNSSEC, have got a secure response. > Not having all the servers for a secure zone be dnssec aware > and enabled can cause this as can recovering from stupid > firewalls which block EDNS responses. > > > ) the current BIND logging messages are less than inutitive. > > being told that there is no valid DS is fine, but the target is > > a little mysterious... '901560.50.197.16.69.in-addr.arpa/SOA/IN' > > does not parse so well. > > I can't help with the target. That generated by one of the > nameservers clients. > > > --bill (just throwing some benchwork over the wall) > > > > > > > > > > On Thu, Sep 07, 2006 at 04:42:48PM -0400, Steve Crocker wrote: > > > My age is showing. I don't understand what you're trying to convey. > > > Can you translate into English? > > > > > > Thanks, > > > > > > Steve > > > > > > > > > Steve Crocker > > > steve at shinkuro.com > > > > > > Try Shinkuro's collaboration technology. Visit www.shinkuro.com. I > > > am steve!shinkuro.com. > > > > > > > > > On Sep 7, 2006, at 4:26 PM, bmanning at vacation.karoshi.com wrote: > > > > > > > > > > >so... disk size has come up. > > > > > > > > yeah, the zones get bigger. > > > > > > > >this might be more fun. in a default configuration (with DNSSEC > > > >enabled) and > > > >trusted keys only for the root... (yeah, its my own private hell) > > > > > > > >-rw-r--r-- 1 root root 1609523200 Sep 6 20:22 daemon > > > > > > > >in a 30 hour window... > > > > > > > >with lots and lots of this ... > > > > > > > > > > > >Sep 7 12:40:40 dot named[767]: no valid DS resolving > > > >'901560.50.197.16.69.in-addr.arpa/SOA/IN': 209.59.139.20#53 > > > >Sep 7 12:40:40 dot named[767]: no valid DS resolving > > > >'609735.50.197.16.69.in-addr.arpa/SOA/IN': 209.59.139.20#53 > > > >Sep 7 12:40:40 dot named[767]: no valid DS resolving > > > >'317084.50.197.16.69.in-addr.arpa/SOA/IN': 209.59.139.20#53 > > > >Sep 7 12:40:40 dot named[767]: no valid DS resolving > > > >'25303.50.197.16.69.in-addr.arpa/SOA/IN': 209.59.139.20#53 > > > >Sep 7 12:40:41 dot named[767]: no valid DS resolving > > > >'925700.176.187.59.69.in-addr.arpa/SOA/IN': 216.93.160.11#53 > > > >Sep 7 12:40:41 dot named[767]: no valid DS resolving > > > >'633639.176.187.59.69.in-addr.arpa/SOA/IN': 216.93.160.16#53 > > > >Sep 7 12:40:41 dot named[767]: no valid DS resolving > > > >'341245.176.187.59.69.in-addr.arpa/SOA/IN': 216.93.160.16#53 > > > >Sep 7 12:40:41 dot named[767]: no valid DS resolving > > > >'49407.176.187.59.69.in-addr.arpa/SOA/IN': 216.93.160.16#53 > > > >Sep 7 12:40:41 dot named[767]: not insecure resolving '72.69.in- > > > >addr.arpa/DS/IN': 2001:478:6::c620:242#53 > > > >Sep 7 12:40:41 dot named[767]: not insecure resolving '59.69.in- > > > >addr.arpa/DS/IN': 198.32.2.66#53 > > > >Sep 7 12:40:41 dot named[767]: not insecure resolving > > > >'201850.249.68.137.70.in-addr.arpa/SOA/IN': 198.32.2.66#53 > > > >Sep 7 12:40:41 dot named[767]: no valid DS resolving > > > >'113556743.234.3.87.70.in-addr.arpa/SOA/IN': 70.86.61.136#53 > > > >Sep 7 12:40:41 dot named[767]: no valid DS resolving > > > >'822358837.234.3.87.70.in-addr.arpa/SOA/IN': 70.86.61.133#53 > > > >Sep 7 12:40:41 dot named[767]: no valid DS resolving > > > >'529979750.234.3.87.70.in-addr.arpa/SOA/IN': 70.87.7.71#53 > > > >Sep 7 12:40:41 dot named[767]: no valid DS resolving > > > >'237175238.234.3.87.70.in-addr.arpa/SOA/IN': 70.87.7.72#53 > > > >Sep 7 12:40:41 dot named[767]: not insecure resolving '87.70.in- > > > >addr.arpa/DS/IN': 2001:478:6::c620:242#53 > > > >Sep 7 12:40:42 dot named[767]: unexpected RCODE (SERVFAIL) > > > >resolving '264426.240.75.97.129.in-addr.arpa/SOA/IN': 198.32.2.66#53 > > > >Sep 7 12:40:42 dot named[767]: unexpected RCODE (SERVFAIL) > > > >resolving '663667.240.75.97.129.in-addr.arpa/SOA/IN': 198.32.2.66#53 > > > > > > > > > > > >--bill > > > > > > > > > > > >############################################################# > > > >This message is sent to you because you are subscribed to > > > > the mailing list . > > >To unsubscribe, E-mail to: > > > >A public archive is available here: > > >Lists/dnssec-deployment/> > > > >and older material is at > > > > > > > > > > > > > ############################################################# > > > This message is sent to you because you are subscribed to > > > the mailing list . > > > To unsubscribe, E-mail to: > > > A public archive is available here: > > > > > > and older material is at > > > > > > > ############################################################# > > This message is sent to you because you are subscribed to > > the mailing list . > > To unsubscribe, E-mail to: > > A public archive is available here: ss > > ec-deployment/> > > and older material is at > > > -- > ISC Training! October 16-20, 2006, in the San Francisco Bay Area, > covering topics from DNS to DHCP. Email training at isc.org. > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org > > ############################################################# > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > A public archive is available here: ec-deployment/> > and older material is at > Note it would most probably help if all the servers for 69.in-addr.arpa where something modern and didn't return NXDOMAIN for 16.69.in-addr.arpa. The correct response is NOERROR as 197.16.69.in-addr.arpa exists. --- 9.2.3rc1 released --- 1416. [bug] Empty node should return NOERROR NODATA, not NXDOMAIN. [RT #4715] Mark drugs:9.4.x 08:55 {3026} % foreach s ( basil.arin.net indigo.arin.net dill.arin.net epazote.arin.net henna.arin.net chia.arin.net figwort.arin.net ) foreach? dig +norec ds 16.69.in-addr.arpa +dnssec @$s foreach? end ; <<>> DiG 9.3.2 <<>> +norec ds 16.69.in-addr.arpa +dnssec @basil.arin.net ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 28969 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;16.69.in-addr.arpa. IN DS ;; AUTHORITY SECTION: 69.in-addr.arpa. 10800 IN SOA chia.arin.net. bind.arin.net. 2006090718 1800 900 691200 10800 ;; Query time: 370 msec ;; SERVER: 192.55.83.32#53(192.55.83.32) ;; WHEN: Fri Sep 8 08:57:07 2006 ;; MSG SIZE rcvd: 101 ; <<>> DiG 9.3.2 <<>> +norec ds 16.69.in-addr.arpa +dnssec @indigo.arin.net ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 38846 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;16.69.in-addr.arpa. IN DS ;; AUTHORITY SECTION: 69.in-addr.arpa. 10800 IN SOA chia.arin.net. bind.arin.net. 2006090718 1800 900 691200 10800 ;; Query time: 224 msec ;; SERVER: 192.31.80.32#53(192.31.80.32) ;; WHEN: Fri Sep 8 08:57:07 2006 ;; MSG SIZE rcvd: 101 ; <<>> DiG 9.3.2 <<>> +norec ds 16.69.in-addr.arpa +dnssec @dill.arin.net ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51018 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;16.69.in-addr.arpa. IN DS ;; AUTHORITY SECTION: 69.in-addr.arpa. 10800 IN SOA chia.arin.net. bind.arin.net. 2006090718 1800 900 691200 10800 ;; Query time: 192 msec ;; SERVER: 192.35.51.32#53(192.35.51.32) ;; WHEN: Fri Sep 8 08:57:08 2006 ;; MSG SIZE rcvd: 101 ; <<>> DiG 9.3.2 <<>> +norec ds 16.69.in-addr.arpa +dnssec @epazote.arin.net ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 54555 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;16.69.in-addr.arpa. IN DS ;; AUTHORITY SECTION: 69.in-addr.arpa. 10800 IN SOA chia.arin.net. bind.arin.net. 2006090718 1800 900 691200 10800 ;; Query time: 208 msec ;; SERVER: 192.41.162.32#53(192.41.162.32) ;; WHEN: Fri Sep 8 08:57:08 2006 ;; MSG SIZE rcvd: 101 ; <<>> DiG 9.3.2 <<>> +norec ds 16.69.in-addr.arpa +dnssec @henna.arin.net ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 11878 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;16.69.in-addr.arpa. IN DS ;; AUTHORITY SECTION: 69.in-addr.arpa. 10800 IN SOA chia.arin.net. bind.arin.net. 2006090718 1800 900 691200 10800 ;; Query time: 227 msec ;; SERVER: 192.26.92.32#53(192.26.92.32) ;; WHEN: Fri Sep 8 08:57:08 2006 ;; MSG SIZE rcvd: 101 ; <<>> DiG 9.3.2 <<>> +norec ds 16.69.in-addr.arpa +dnssec @chia.arin.net ; (2 servers found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29980 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;16.69.in-addr.arpa. IN DS ;; AUTHORITY SECTION: 69.in-addr.arpa. 10800 IN SOA chia.arin.net. bind.arin.net. 2006090718 1800 900 691200 10800 ;; Query time: 622 msec ;; SERVER: 2001:440:2000:1::21#53(2001:440:2000:1::21) ;; WHEN: Fri Sep 8 08:57:09 2006 ;; MSG SIZE rcvd: 101 ; <<>> DiG 9.3.2 <<>> +norec ds 16.69.in-addr.arpa +dnssec @figwort.arin.net ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 37860 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;16.69.in-addr.arpa. IN DS ;; AUTHORITY SECTION: 69.in-addr.arpa. 10800 IN SOA chia.arin.net. bind.arin.net. 2006090718 1800 900 691200 10800 ;; Query time: 178 msec ;; SERVER: 192.42.93.32#53(192.42.93.32) ;; WHEN: Fri Sep 8 08:57:09 2006 ;; MSG SIZE rcvd: 101 drugs:9.4.x 08:56 {3027} % drugs:9.4.x 08:55 {3026} % foreach s ( basil.arin.net indigo.arin.net dill.arin. net epazote.arin.net henna.arin.net chia.arin.net figwort.arin.net ) foreach? dig +norec ds 16.69.in-addr.arpa +dnssec @$s foreach? end ; <<>> DiG 9.3.2 <<>> +norec ds 16.69.in-addr.arpa +dnssec @basil.arin.net ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 28969 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;16.69.in-addr.arpa. IN DS ;; AUTHORITY SECTION: 69.in-addr.arpa. 10800 IN SOA chia.arin.net. bind.arin.net. 20 06090718 1800 900 691200 10800 ;; Query time: 370 msec ;; SERVER: 192.55.83.32#53(192.55.83.32) ;; WHEN: Fri Sep 8 08:57:07 2006 ;; MSG SIZE rcvd: 101 ; <<>> DiG 9.3.2 <<>> +norec ds 16.69.in-addr.arpa +dnssec @indigo.arin.net ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 38846 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;16.69.in-addr.arpa. IN DS ;; AUTHORITY SECTION: 69.in-addr.arpa. 10800 IN SOA chia.arin.net. bind.arin.net. 20 06090718 1800 900 691200 10800 ;; Query time: 224 msec ;; SERVER: 192.31.80.32#53(192.31.80.32) ;; WHEN: Fri Sep 8 08:57:07 2006 ;; MSG SIZE rcvd: 101 ; <<>> DiG 9.3.2 <<>> +norec ds 16.69.in-addr.arpa +dnssec @dill.arin.net ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51018 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;16.69.in-addr.arpa. IN DS ;; AUTHORITY SECTION: 69.in-addr.arpa. 10800 IN SOA chia.arin.net. bind.arin.net. 20 06090718 1800 900 691200 10800 ;; Query time: 192 msec ;; SERVER: 192.35.51.32#53(192.35.51.32) ;; WHEN: Fri Sep 8 08:57:08 2006 ;; MSG SIZE rcvd: 101 ; <<>> DiG 9.3.2 <<>> +norec ds 16.69.in-addr.arpa +dnssec @epazote.arin.net ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 54555 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;16.69.in-addr.arpa. IN DS ;; AUTHORITY SECTION: 69.in-addr.arpa. 10800 IN SOA chia.arin.net. bind.arin.net. 20 06090718 1800 900 691200 10800 ;; Query time: 208 msec ;; SERVER: 192.41.162.32#53(192.41.162.32) ;; WHEN: Fri Sep 8 08:57:08 2006 ;; MSG SIZE rcvd: 101 ; <<>> DiG 9.3.2 <<>> +norec ds 16.69.in-addr.arpa +dnssec @henna.arin.net ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 11878 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;16.69.in-addr.arpa. IN DS ;; AUTHORITY SECTION: 69.in-addr.arpa. 10800 IN SOA chia.arin.net. bind.arin.net. 20 06090718 1800 900 691200 10800 ;; Query time: 227 msec ;; SERVER: 192.26.92.32#53(192.26.92.32) ;; WHEN: Fri Sep 8 08:57:08 2006 ;; MSG SIZE rcvd: 101 ; <<>> DiG 9.3.2 <<>> +norec ds 16.69.in-addr.arpa +dnssec @chia.arin.net ; (2 servers found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29980 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;16.69.in-addr.arpa. IN DS ;; AUTHORITY SECTION: 69.in-addr.arpa. 10800 IN SOA chia.arin.net. bind.arin.net. 20 06090718 1800 900 691200 10800 ;; Query time: 622 msec ;; SERVER: 2001:440:2000:1::21#53(2001:440:2000:1::21) ;; WHEN: Fri Sep 8 08:57:09 2006 ;; MSG SIZE rcvd: 101 ; <<>> DiG 9.3.2 <<>> +norec ds 16.69.in-addr.arpa +dnssec @figwort.arin.net ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 37860 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;16.69.in-addr.arpa. IN DS ;; AUTHORITY SECTION: 69.in-addr.arpa. 10800 IN SOA chia.arin.net. bind.arin.net. 20 06090718 1800 900 691200 10800 ;; Query time: 178 msec ;; SERVER: 192.42.93.32#53(192.42.93.32) ;; WHEN: Fri Sep 8 08:57:09 2006 ;; MSG SIZE rcvd: 101 drugs:9.4.x 08:56 {3027} % drugs:9.4.x 09:01 {3029} % foreach s ( basil.arin.net indigo.arin.net dill.arin.net epazote.arin.net henna.arin.net chia.arin.net figwort.arin.net ) foreach? dig +norec 197.16.69.in-addr.arpa @$s foreach? end ; <<>> DiG 9.3.2 <<>> +norec 197.16.69.in-addr.arpa @basil.arin.net ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27784 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;197.16.69.in-addr.arpa. IN A ;; AUTHORITY SECTION: 197.16.69.in-addr.arpa. 86400 IN NS ns1.liquidweb.com. 197.16.69.in-addr.arpa. 86400 IN NS ns.liquidweb.com. ;; Query time: 552 msec ;; SERVER: 192.55.83.32#53(192.55.83.32) ;; WHEN: Fri Sep 8 09:01:50 2006 ;; MSG SIZE rcvd: 88 ; <<>> DiG 9.3.2 <<>> +norec 197.16.69.in-addr.arpa @indigo.arin.net ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10590 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;197.16.69.in-addr.arpa. IN A ;; AUTHORITY SECTION: 197.16.69.in-addr.arpa. 86400 IN NS ns1.liquidweb.com. 197.16.69.in-addr.arpa. 86400 IN NS ns.liquidweb.com. ;; Query time: 409 msec ;; SERVER: 192.31.80.32#53(192.31.80.32) ;; WHEN: Fri Sep 8 09:01:51 2006 ;; MSG SIZE rcvd: 88 ; <<>> DiG 9.3.2 <<>> +norec 197.16.69.in-addr.arpa @dill.arin.net ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53925 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;197.16.69.in-addr.arpa. IN A ;; AUTHORITY SECTION: 197.16.69.in-addr.arpa. 86400 IN NS ns1.liquidweb.com. 197.16.69.in-addr.arpa. 86400 IN NS ns.liquidweb.com. ;; Query time: 375 msec ;; SERVER: 192.35.51.32#53(192.35.51.32) ;; WHEN: Fri Sep 8 09:01:51 2006 ;; MSG SIZE rcvd: 88 ; <<>> DiG 9.3.2 <<>> +norec 197.16.69.in-addr.arpa @epazote.arin.net ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42137 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;197.16.69.in-addr.arpa. IN A ;; AUTHORITY SECTION: 197.16.69.in-addr.arpa. 86400 IN NS ns1.liquidweb.com. 197.16.69.in-addr.arpa. 86400 IN NS ns.liquidweb.com. ;; Query time: 337 msec ;; SERVER: 192.41.162.32#53(192.41.162.32) ;; WHEN: Fri Sep 8 09:01:51 2006 ;; MSG SIZE rcvd: 88 ; <<>> DiG 9.3.2 <<>> +norec 197.16.69.in-addr.arpa @henna.arin.net ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47408 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;197.16.69.in-addr.arpa. IN A ;; AUTHORITY SECTION: 197.16.69.in-addr.arpa. 86400 IN NS ns1.liquidweb.com. 197.16.69.in-addr.arpa. 86400 IN NS ns.liquidweb.com. ;; Query time: 420 msec ;; SERVER: 192.26.92.32#53(192.26.92.32) ;; WHEN: Fri Sep 8 09:01:52 2006 ;; MSG SIZE rcvd: 88 ; <<>> DiG 9.3.2 <<>> +norec 197.16.69.in-addr.arpa @chia.arin.net ; (2 servers found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27319 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;197.16.69.in-addr.arpa. IN A ;; AUTHORITY SECTION: 197.16.69.in-addr.arpa. 86400 IN NS ns1.liquidweb.com. 197.16.69.in-addr.arpa. 86400 IN NS ns.liquidweb.com. ;; Query time: 785 msec ;; SERVER: 2001:440:2000:1::21#53(2001:440:2000:1::21) ;; WHEN: Fri Sep 8 09:01:53 2006 ;; MSG SIZE rcvd: 88 ; <<>> DiG 9.3.2 <<>> +norec 197.16.69.in-addr.arpa @figwort.arin.net ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30656 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;197.16.69.in-addr.arpa. IN A ;; AUTHORITY SECTION: 197.16.69.in-addr.arpa. 86400 IN NS ns1.liquidweb.com. 197.16.69.in-addr.arpa. 86400 IN NS ns.liquidweb.com. ;; Query time: 333 msec ;; SERVER: 192.42.93.32#53(192.42.93.32) ;; WHEN: Fri Sep 8 09:01:53 2006 ;; MSG SIZE rcvd: 88 drugs:9.4.x 09:01 {3030} % -- ISC Training! October 16-20, 2006, in the San Francisco Bay Area, covering topics from DNS to DHCP. Email training at isc.org. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From Mark_Andrews at isc.org Thu Sep 7 19:12:16 2006 From: Mark_Andrews at isc.org (Mark Andrews) Date: Fri, 08 Sep 2006 09:12:16 +1000 Subject: [dnssec-deployment] yet another resource constraint In-Reply-To: Your message of "Thu, 07 Sep 2006 22:55:37 GMT." <20060907225537.GA19253@vacation.karoshi.com.> Message-ID: <200609072312.k87NCGAN074072@drugs.dv.isc.org> > On Fri, Sep 08, 2006 at 08:45:29AM +1000, Mark Andrews wrote: > > > > > > > > a few things: > > > > > > ) islands of trust, when unexpected, generate lots of log messages. > > > the potential impact is that when there a dropped DS handoff occurs, > > > not only does the zone go insecure, the validating resolvers log > > > every attempt ... so the majority of the impact is on the third-part > y > > > servers in recording the logged failures. > > > > It's not islands of trust causing this. It's a broken trust > > chain. Failure to update the DS's when the KSK's are changed > > can cause "no valid DS". > > tada!!! broken trust chains create "islands" n'est pas? No, a island of trust doesn't have any DS records. This is different from incorrect DS records. This is a broken chain of trust. > > "not insecure" is generated when you get a insecure response > > but should, according to DNSSEC, have got a secure response. > > Not having all the servers for a secure zone be dnssec aware > > and enabled can cause this as can recovering from stupid > > firewalls which block EDNS responses. > > yup... > > > > ) the current BIND logging messages are less than inutitive. > > > being told that there is no valid DS is fine, but the target is > > > a little mysterious... '901560.50.197.16.69.in-addr.arpa/SOA/IN' > > > does not parse so well. > > > > I can't help with the target. That generated by one of the > > nameservers clients. > > the client generated the 901560.... bitstring? Ok, i'll > buy that. but surely the client didn't write out the > log entry on the server. not sure how to use that snippet > of data to troubleshoot problems. resolving . > the point remains, there are going to be -LOTS- of logged messages > for validator machines w/ the default configuration from BIND. > RAID futures anyone? :) > > --bill > > > > > > --bill (just throwing some benchwork over the wall) -- ISC Training! October 16-20, 2006, in the San Francisco Bay Area, covering topics from DNS to DHCP. Email training at isc.org. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From Mark_Andrews at isc.org Thu Sep 7 19:32:58 2006 From: Mark_Andrews at isc.org (Mark Andrews) Date: Fri, 08 Sep 2006 09:32:58 +1000 Subject: [dnssec-deployment] yet another resource constraint In-Reply-To: Your message of "Thu, 07 Sep 2006 22:55:37 GMT." <20060907225537.GA19253@vacation.karoshi.com.> Message-ID: <200609072332.k87NWwmF096771@drugs.dv.isc.org> You can to a initial check of DS/DNSKEY relationships by comparing the results of dig +dnssec +multiline dnskey zone and dig +dnssec ds zone +multiline will cause dig to print out the key id's which can then be looked for in the DS RRset. If the key id's match then you need to generate the DS records and do a full compare. However every breakage I've found so far was identifiable by using just the key id's. You will notice that 37083 has the ksk set (flags=257) and that the DS records have 37083 in the key id fields. The same logic applies to DLV records. Mark ; <<>> DiG 9.3.2 <<>> +multiline dnskey dv.isc.org +dnssec ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13276 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 3, ADDITIONAL: 9 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1460 ;; QUESTION SECTION: ;dv.isc.org. IN DNSKEY ;; ANSWER SECTION: dv.isc.org. 60 IN DNSKEY 256 3 5 ( AQPGP80zt8pQS5xVaaaD054XBet8sCKaYZ9WrnYyuznq NXkS91j6qqHuw7Y9kKAVsFoWfNw0CpahdIJIhUPFM1JR JtXhNy1cg9Ok3kBnN+fwCe2LY3qOtweFbL9bSjgolQWr 42AlFOjZnJVW1cECgVBfinKHBIEIIwIdHGGuLyIQaQ== ) ; key id = 52595 dv.isc.org. 60 IN DNSKEY 257 3 5 ( AQO/WTD1QT9aOKORz8l7lcWgghCH0E+cxr3cnm7v0oLA 0NLMFa1NzZMtPVl6AGWu+jDo0y/y37lWUiNK9FLcmxzT vm2BgWHoZ3/aQcdxkR+SDIxBRu3HlGGZcrk80lT77OBr YjiJmImQt9cLefG0TxzwYbWEX2AwYCMil/GfFia11Cu3 HC2JER/Z7INIYiXgX42FWQtqYqSwl20TkH1NLGoWXDQZ EcUMBG/dz+o9JTTalQkIcohhxdJ9Bd1Yceq+4hEdN25m MvL2us8nJXa8nqryTEZ2iAce2RxYjhEAuZ4Dg0u0hgCv hOkEyf/M3erv1RkdB1UPMLgh7xiYcw5K87yd ) ; key id = 37083 dv.isc.org. 60 IN RRSIG DNSKEY 5 3 60 20061001221144 ( 20060901221144 37083 dv.isc.org. SLcBIjZjZh1GkK5zILIQbklDBDKlwVMLbih4rwvXm5Iu 72pYTJV6OrvdyTtplKYRx4RAPiCIgAkMuvCA+27UVxal b2mL15But4s2pPMzmuCTSfiyQWl/6W4/Ks+JAlbMvCyh iKdXnvHfI8mvAq1UBeH4KyR2HiYmIt+xVSN82rZUt0sf dO3TUhZh3q7DrgtahOCQLknNpbJQYmQNC/8/nY6NyMfr n0BYHha38T/Vlnl47CmGfP+Y9ZAAZGwR/H0qdDljmvFv Dagzjm8f/bwmc43FhpUhh8dUs0StmPF8AeHh4XjxJKq6 be8QS7u5IF4NYzjp5312MIzB7MGQuVqWpw== ) dv.isc.org. 60 IN RRSIG DNSKEY 5 3 60 20061001221144 ( 20060901221144 52595 dv.isc.org. FsCjLUnY7cprw1BoMb+dCUzITFx9JmQBv6FbRK/JiDTA zswH6JU0yiWGQDq7rNgnbsMykKvPdonKsNOsaU0R4de4 gQZ41Dj+w4MVNqTNiqkjwp52mY4/KfQa4FQWuzI5CFRr VAvds21pbFby6bUeKPGy78yjI7Shhk8LdtgmcEo= ) ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Sep 8 09:18:50 2006 ;; MSG SIZE rcvd: 1751 ; <<>> DiG 9.3.2 <<>> +dnssec ds dv.isc.org ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16413 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 5, ADDITIONAL: 5 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1460 ;; QUESTION SECTION: ;dv.isc.org. IN DS ;; ANSWER SECTION: dv.isc.org. 3600 IN DS 37083 5 1 B0C39FAF74C12292DBAF54E26B1C24B91364C77D dv.isc.org. 3600 IN DS 37083 5 2 434F5A10578BC89820E44BA796B7AF1979B13F70E5239DAA935F5738 2143F2B5 dv.isc.org. 3600 IN RRSIG DS 5 3 3600 20061004165042 20060904165042 57956 isc.org. lVKOi6hzBXN83xZ2lxGkwlkes2AvceZnfb5SdS630fCy5otfOArTaHso xCPaePIY7Guf0V4kSuxDmaGyIAtJ6onhyite2j+I8u8RCRFpL6AqFGRZ qalik6tvHm9j8NARdw0idUzIEgTwql4CQXeACNIXKSVWRdyuLJFRxk6d TSw= ;; Query time: 23 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Sep 8 09:20:37 2006 ;; MSG SIZE rcvd: 934 -- ISC Training! October 16-20, 2006, in the San Francisco Bay Area, covering topics from DNS to DHCP. Email training at isc.org. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From bmanning at vacation.karoshi.com Thu Sep 7 20:22:11 2006 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 8 Sep 2006 00:22:11 +0000 Subject: [dnssec-deployment] yet another resource constraint In-Reply-To: References: Message-ID: <20060908002211.GA19849@vacation.karoshi.com.> > Note it would most probably help if all the servers for > 69.in-addr.arpa where something modern and didn't > return NXDOMAIN for 16.69.in-addr.arpa. The correct response > is NOERROR as 197.16.69.in-addr.arpa exists. > > --- 9.2.3rc1 released --- > > 1416. [bug] Empty node should return NOERROR NODATA, not NXDOMAIN. > [RT #4715] yeah, sure... in a perfect world. reality sez there will be lots of servers that don't/won't upgrade. and with the current default logging behaviour, there will be a noticable, significant increase in the size of the log files. --bill From bmanning at vacation.karoshi.com Thu Sep 7 20:29:47 2006 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 8 Sep 2006 00:29:47 +0000 Subject: [dnssec-deployment] yet another resource constraint In-Reply-To: References: <20060907225537.GA19253@vacation.karoshi.com.> Message-ID: <20060908002947.GB19849@vacation.karoshi.com.> > > > It's not islands of trust causing this. It's a broken trust > > > chain. Failure to update the DS's when the KSK's are changed > > > can cause "no valid DS". > > > > tada!!! broken trust chains create "islands" n'est pas? > > No, a island of trust doesn't have any DS records. This is > different from incorrect DS records. This is a broken chain > of trust. hum... i guess we will have to agree to disagree. when the chain is broken, it creates two distinct islands... with the right SEP's in place, the validator is just fine. When an end system expects "seamless" chain of trust and does not see it, for whatever reason, there is a defacto gap, creating islands. --bill From Mark_Andrews at isc.org Thu Sep 7 20:32:50 2006 From: Mark_Andrews at isc.org (Mark Andrews) Date: Fri, 08 Sep 2006 10:32:50 +1000 Subject: [dnssec-deployment] yet another resource constraint In-Reply-To: Your message of "Fri, 08 Sep 2006 00:22:11 GMT." <20060908002211.GA19849@vacation.karoshi.com.> Message-ID: <200609080032.k880WpTK097534@drugs.dv.isc.org> > > Note it would most probably help if all the servers for > > 69.in-addr.arpa where something modern and didn't > > return NXDOMAIN for 16.69.in-addr.arpa. The correct response > > is NOERROR as 197.16.69.in-addr.arpa exists. > > > > --- 9.2.3rc1 released --- > > > > 1416. [bug] Empty node should return NOERROR NODATA, not NXDOMA > IN. > > [RT #4715] > > yeah, sure... in a perfect world. > > reality sez there will be lots of servers that don't/won't > upgrade. and with the current default logging behaviour, > there will be a noticable, significant increase in the size > of the log files. Bill you have yet to demonstate that this is nothing more that a broken chain of trust somewhere in your own test environment. There is no point in complaining about log messages until you can prove that they are just noise and not a indication of a real problem. As far as I am aware there is no way that the messages will be logged unless there was a validation failure and there was a real error. > --bill -- ISC Training! October 16-20, 2006, in the San Francisco Bay Area, covering topics from DNS to DHCP. Email training at isc.org. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From bmanning at vacation.karoshi.com Thu Sep 7 20:36:23 2006 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 8 Sep 2006 00:36:23 +0000 Subject: [dnssec-deployment] yet another resource constraint In-Reply-To: <200609072332.k87NWwmF096771@drugs.dv.isc.org> References: <20060907225537.GA19253@vacation.karoshi.com.> <200609072332.k87NWwmF096771@drugs.dv.isc.org> Message-ID: <20060908003623.GC19849@vacation.karoshi.com.> sure i could. and this is useful stuff to know... but not something that is intuitive, out of the box... and even when/if you can debug the problem, you can't always get the source of the problem to devote the resources to mitigate the issue.... so the statement stands... log files will be bigger, perhaps much bigger, when "trusted-keys" statements are deployed. --bill On Fri, Sep 08, 2006 at 09:32:58AM +1000, Mark Andrews wrote: > > You can to a initial check of DS/DNSKEY relationships by > comparing the results of > > dig +dnssec +multiline dnskey zone > > and > > dig +dnssec ds zone > > +multiline will cause dig to print out the key id's which > can then be looked for in the DS RRset. If the key id's > match then you need to generate the DS records and do a > full compare. However every breakage I've found so far was > identifiable by using just the key id's. > > You will notice that 37083 has the ksk set (flags=257) and > that the DS records have 37083 in the key id fields. The > same logic applies to DLV records. > > Mark > > ; <<>> DiG 9.3.2 <<>> +multiline dnskey dv.isc.org +dnssec > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13276 > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 3, ADDITIONAL: 9 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 1460 > ;; QUESTION SECTION: > ;dv.isc.org. IN DNSKEY > > ;; ANSWER SECTION: > dv.isc.org. 60 IN DNSKEY 256 3 5 ( > AQPGP80zt8pQS5xVaaaD054XBet8sCKaYZ9WrnYyuznq > NXkS91j6qqHuw7Y9kKAVsFoWfNw0CpahdIJIhUPFM1JR > JtXhNy1cg9Ok3kBnN+fwCe2LY3qOtweFbL9bSjgolQWr > 42AlFOjZnJVW1cECgVBfinKHBIEIIwIdHGGuLyIQaQ== > ) ; key id = 52595 > dv.isc.org. 60 IN DNSKEY 257 3 5 ( > AQO/WTD1QT9aOKORz8l7lcWgghCH0E+cxr3cnm7v0oLA > 0NLMFa1NzZMtPVl6AGWu+jDo0y/y37lWUiNK9FLcmxzT > vm2BgWHoZ3/aQcdxkR+SDIxBRu3HlGGZcrk80lT77OBr > YjiJmImQt9cLefG0TxzwYbWEX2AwYCMil/GfFia11Cu3 > HC2JER/Z7INIYiXgX42FWQtqYqSwl20TkH1NLGoWXDQZ > EcUMBG/dz+o9JTTalQkIcohhxdJ9Bd1Yceq+4hEdN25m > MvL2us8nJXa8nqryTEZ2iAce2RxYjhEAuZ4Dg0u0hgCv > hOkEyf/M3erv1RkdB1UPMLgh7xiYcw5K87yd > ) ; key id = 37083 > dv.isc.org. 60 IN RRSIG DNSKEY 5 3 60 20061001221144 ( > 20060901221144 37083 dv.isc.org. > SLcBIjZjZh1GkK5zILIQbklDBDKlwVMLbih4rwvXm5Iu > 72pYTJV6OrvdyTtplKYRx4RAPiCIgAkMuvCA+27UVxal > b2mL15But4s2pPMzmuCTSfiyQWl/6W4/Ks+JAlbMvCyh > iKdXnvHfI8mvAq1UBeH4KyR2HiYmIt+xVSN82rZUt0sf > dO3TUhZh3q7DrgtahOCQLknNpbJQYmQNC/8/nY6NyMfr > n0BYHha38T/Vlnl47CmGfP+Y9ZAAZGwR/H0qdDljmvFv > Dagzjm8f/bwmc43FhpUhh8dUs0StmPF8AeHh4XjxJKq6 > be8QS7u5IF4NYzjp5312MIzB7MGQuVqWpw== ) > dv.isc.org. 60 IN RRSIG DNSKEY 5 3 60 20061001221144 ( > 20060901221144 52595 dv.isc.org. > FsCjLUnY7cprw1BoMb+dCUzITFx9JmQBv6FbRK/JiDTA > zswH6JU0yiWGQDq7rNgnbsMykKvPdonKsNOsaU0R4de4 > gQZ41Dj+w4MVNqTNiqkjwp52mY4/KfQa4FQWuzI5CFRr > VAvds21pbFby6bUeKPGy78yjI7Shhk8LdtgmcEo= ) > > ;; Query time: 0 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Fri Sep 8 09:18:50 2006 > ;; MSG SIZE rcvd: 1751 > > > ; <<>> DiG 9.3.2 <<>> +dnssec ds dv.isc.org > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16413 > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 5, ADDITIONAL: 5 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 1460 > ;; QUESTION SECTION: > ;dv.isc.org. IN DS > > ;; ANSWER SECTION: > dv.isc.org. 3600 IN DS 37083 5 1 B0C39FAF74C12292DBAF54E26B1C24B91364C77D > dv.isc.org. 3600 IN DS 37083 5 2 434F5A10578BC89820E44BA796B7AF1979B13F70E5239DAA935F5738 2143F2B5 > dv.isc.org. 3600 IN RRSIG DS 5 3 3600 20061004165042 20060904165042 57956 isc.org. lVKOi6hzBXN83xZ2lxGkwlkes2AvceZnfb5SdS630fCy5otfOArTaHso xCPaePIY7Guf0V4kSuxDmaGyIAtJ6onhyite2j+I8u8RCRFpL6AqFGRZ qalik6tvHm9j8NARdw0idUzIEgTwql4CQXeACNIXKSVWRdyuLJFRxk6d TSw= > > ;; Query time: 23 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Fri Sep 8 09:20:37 2006 > ;; MSG SIZE rcvd: 934 > > -- > ISC Training! October 16-20, 2006, in the San Francisco Bay Area, > covering topics from DNS to DHCP. Email training at isc.org. > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From bmanning at vacation.karoshi.com Thu Sep 7 20:42:38 2006 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 8 Sep 2006 00:42:38 +0000 Subject: [dnssec-deployment] yet another resource constraint In-Reply-To: <200609080032.k880WpTK097534@drugs.dv.isc.org> References: <20060908002211.GA19849@vacation.karoshi.com.> <200609080032.k880WpTK097534@drugs.dv.isc.org> Message-ID: <20060908004238.GD19849@vacation.karoshi.com.> thanks mark. i was not and am not complaining about log messages. i am pointing out an emperical data point and suggesting that there was/is a missing point in the "roadmap" on resource contraints. or are you suggesting that there will never be a noticable increase in the level or number of log messages due to DNSSEC related considerations? --bill On Fri, Sep 08, 2006 at 10:32:50AM +1000, Mark Andrews wrote: > > > > Note it would most probably help if all the servers for > > > 69.in-addr.arpa where something modern and didn't > > > return NXDOMAIN for 16.69.in-addr.arpa. The correct response > > > is NOERROR as 197.16.69.in-addr.arpa exists. > > > > > > --- 9.2.3rc1 released --- > > > > > > 1416. [bug] Empty node should return NOERROR NODATA, not NXDOMA > > IN. > > > [RT #4715] > > > > yeah, sure... in a perfect world. > > > > reality sez there will be lots of servers that don't/won't > > upgrade. and with the current default logging behaviour, > > there will be a noticable, significant increase in the size > > of the log files. > > Bill you have yet to demonstate that this is nothing more > that a broken chain of trust somewhere in your own test > environment. > > There is no point in complaining about log messages until > you can prove that they are just noise and not a indication > of a real problem. As far as I am aware there is no way > that the messages will be logged unless there was a validation > failure and there was a real error. > > > --bill > -- > ISC Training! October 16-20, 2006, in the San Francisco Bay Area, > covering topics from DNS to DHCP. Email training at isc.org. > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From steve at shinkuro.com Thu Sep 7 20:48:18 2006 From: steve at shinkuro.com (Steve Crocker) Date: Thu, 7 Sep 2006 20:48:18 -0400 Subject: [dnssec-deployment] yet another resource constraint In-Reply-To: References: <20060908002211.GA19849@vacation.karoshi.com.> <200609080032.k880WpTK097534@drugs.dv.isc.org> Message-ID: <35ADC596-5737-4B3A-9A59-34126D70F42C@shinkuro.com> On Sep 7, 2006, at 8:42 PM, bmanning at vacation.karoshi.com wrote: > > thanks mark. i was not and am not complaining about > log messages. i am pointing out an emperical data point > and suggesting that there was/is a missing point in the > "roadmap" on resource contraints. or are you suggesting > that there will never be a noticable increase in the level > or number of log messages due to DNSSEC related considerations? I don't know if this will turn out to be an important aspect in operations, but I definitely think it's worth noting and seeing whether it does or doesn't become important. Thanks! Steve From Mark_Andrews at isc.org Thu Sep 7 21:01:00 2006 From: Mark_Andrews at isc.org (Mark Andrews) Date: Fri, 08 Sep 2006 11:01:00 +1000 Subject: [dnssec-deployment] yet another resource constraint In-Reply-To: Your message of "Fri, 08 Sep 2006 00:42:38 GMT." <20060908004238.GD19849@vacation.karoshi.com.> Message-ID: <200609080101.k88110T0097870@drugs.dv.isc.org> > thanks mark. i was not and am not complaining about > log messages. i am pointing out an emperical data point > and suggesting that there was/is a missing point in the > "roadmap" on resource contraints. or are you suggesting > that there will never be a noticable increase in the level > or number of log messages due to DNSSEC related considerations? I don't notice a lot of DNSSEC related error messages for the trust anchors I have configured. In the last month I've logged no DNSSEC related error messages from named. I have logged other error messages. I do know that if DNSSEC is mis-managed you will get a lot error messages. Mark > --bill -- ISC Training! October 16-20, 2006, in the San Francisco Bay Area, covering topics from DNS to DHCP. Email training at isc.org. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From bmanning at vacation.karoshi.com Thu Sep 7 22:39:55 2006 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 8 Sep 2006 02:39:55 +0000 Subject: [dnssec-deployment] yet another resource constraint In-Reply-To: <200609080101.k88110T0097870@drugs.dv.isc.org> References: <20060908004238.GD19849@vacation.karoshi.com.> <200609080101.k88110T0097870@drugs.dv.isc.org> Message-ID: <20060908023955.GE19849@vacation.karoshi.com.> On Fri, Sep 08, 2006 at 11:01:00AM +1000, Mark Andrews wrote: > > > thanks mark. i was not and am not complaining about > > log messages. i am pointing out an emperical data point > > and suggesting that there was/is a missing point in the > > "roadmap" on resource contraints. or are you suggesting > > that there will never be a noticable increase in the level > > or number of log messages due to DNSSEC related considerations? > > I don't notice a lot of DNSSEC related error messages for > the trust anchors I have configured. In the last month > I've logged no DNSSEC related error messages from named. > I have logged other error messages. > > I do know that if DNSSEC is mis-managed you will get a lot > error messages. bingo... thanks. > > Mark > > > --bill > Mark Andrews, ISC From ben at algroup.co.uk Fri Sep 8 06:40:44 2006 From: ben at algroup.co.uk (Ben Laurie) Date: Fri, 08 Sep 2006 11:40:44 +0100 Subject: BIND and OpenSSL's RSA signature forging issue Message-ID: <450148AC.3060400@algroup.co.uk> I've just noticed that BIND is vulnerable to: http://www.openssl.org/news/secadv_20060905.txt Executive summary: RRSIGs can be forged if your RSA key has exponent 3, which is BIND's default. Note that the issue is in the resolver, not the server. Fix: Upgrade OpenSSL. Issue: Since I've been told often that most of the world won't upgrade resolvers, presumably most of the world will be vulnerable to this problem for a long time. Solution: Don't use exponent 3 anymore. This can, of course, be done server-side, where the responsible citizens live, allegedly. Side benefit: You all get to test emergency key roll! Start your motors, gentlemen! Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff From thierry.moreau at connotech.com Fri Sep 8 08:05:54 2006 From: thierry.moreau at connotech.com (Thierry Moreau) Date: Fri, 08 Sep 2006 08:05:54 -0400 Subject: [dnssec-deployment] BIND and OpenSSL's RSA signature forging issue In-Reply-To: References: Message-ID: <45015CA2.9090807@connotech.com> Ben Laurie wrote: > I've just noticed that BIND is vulnerable to: > > http://www.openssl.org/news/secadv_20060905.txt > > Executive summary: > > RRSIGs can be forged if your RSA key has exponent 3, which is BIND's > default. Note that the issue is in the resolver, not the server. > See a more comprehensive report at Hal Finney, "Bleichenbacher's RSA signature forgery based on implementation error" Wed, 30 Aug 2006 http://www.mail-archive.com/cryptography at metzdowd.com/msg06537.html "based on implementation error" is somehow relevant to understand exactly where the vulnerability lies. I mean "somehow relevant" because the specific implementation error (a missing data validation check, where the check is useful *only* for preventing the Bleichenbacher's RSA signature forgery while the forgery was previously unknown) is very likely to be done by even dedicated implementation developers, and remain undetected in the SW testing phase because of its innocuous-ness. > Fix: > > Upgrade OpenSSL. > Or use the proper command-line argument in the BIND-specific dnssec-keygen utility? Or fix the BIND-specific dnssec-keygen utility to use the other allowed value (i.e 65537) as the default? > Issue: > > Since I've been told often that most of the world won't upgrade > resolvers, presumably most of the world will be vulnerable to this > problem for a long time. > > Solution: > > Don't use exponent 3 anymore. This can, of course, be done server-side, > where the responsible citizens live, allegedly. > > Side benefit: > > You all get to test emergency key roll! Start your motors, gentlemen! > Responsible citizens consult their family cryptographer before selecting an RSA public key exponent, and they stay away from public exponent=3 for number-theoretic reasons known only to the family cryptographers (of which the Bleichenbacher's RSA signature forgery is an acutely practical consequence)! > Cheers, Cheers, > > Ben. > - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau at connotech.com From ben at algroup.co.uk Fri Sep 8 09:01:07 2006 From: ben at algroup.co.uk (Ben Laurie) Date: Fri, 08 Sep 2006 14:01:07 +0100 Subject: [dnsop] Re: [dnssec-deployment] BIND and OpenSSL's RSA signature forging issue In-Reply-To: <45015CA2.9090807@connotech.com> References: <45015CA2.9090807@connotech.com> Message-ID: <45016993.9090101@algroup.co.uk> Thierry Moreau wrote: > > > Ben Laurie wrote: > >> I've just noticed that BIND is vulnerable to: >> >> http://www.openssl.org/news/secadv_20060905.txt >> >> Executive summary: >> >> RRSIGs can be forged if your RSA key has exponent 3, which is BIND's >> default. Note that the issue is in the resolver, not the server. >> > > See a more comprehensive report at > > Hal Finney, "Bleichenbacher's RSA signature forgery based on > implementation error" Wed, 30 Aug 2006 > http://www.mail-archive.com/cryptography at metzdowd.com/msg06537.html > > "based on implementation error" is somehow relevant to understand > exactly where the vulnerability lies. I mean "somehow relevant" because > the specific implementation error (a missing data validation check, > where the check is useful *only* for preventing the Bleichenbacher's RSA > signature forgery while the forgery was previously unknown) is very > likely to be done by even dedicated implementation developers, and > remain undetected in the SW testing phase because of its innocuous-ness. > >> Fix: >> >> Upgrade OpenSSL. >> > > Or use the proper command-line argument in the BIND-specific > dnssec-keygen utility? > > Or fix the BIND-specific dnssec-keygen utility to use the other allowed > value (i.e 65537) as the default? Neither of these measures will fix existing keys, of course. > >> Issue: >> >> Since I've been told often that most of the world won't upgrade >> resolvers, presumably most of the world will be vulnerable to this >> problem for a long time. >> >> Solution: >> >> Don't use exponent 3 anymore. This can, of course, be done server-side, >> where the responsible citizens live, allegedly. >> >> Side benefit: >> >> You all get to test emergency key roll! Start your motors, gentlemen! >> > > Responsible citizens consult their family cryptographer before selecting > an RSA public key exponent, and they stay away from public exponent=3 > for number-theoretic reasons known only to the family cryptographers (of > which the Bleichenbacher's RSA signature forgery is an acutely practical > consequence)! > >> Cheers, > > Cheers, > >> >> Ben. >> > > - Thierry Moreau > > CONNOTECH Experts-conseils inc. > 9130 Place de Montgolfier > Montreal, Qc > Canada H2M 2A1 > > Tel.: (514)385-5691 > Fax: (514)385-5900 > > web site: http://www.connotech.com > e-mail: thierry.moreau at connotech.com > > . > dnsop resources:_____________________________________________________ > web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html > mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html > > -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff From thierry.moreau at connotech.com Fri Sep 8 09:09:50 2006 From: thierry.moreau at connotech.com (Thierry Moreau) Date: Fri, 08 Sep 2006 09:09:50 -0400 Subject: [dnssec-deployment] yet another resource constraint In-Reply-To: References: Message-ID: <45016B9E.1020301@connotech.com> Mark Andrews wrote: > > I do know that if DNSSEC is mis-managed you will get a lot > error messages. > You mean (from the previous messages in the thread), as a "purely arbitrary" example, that if the ICANN/SSG-DOC-NTIA/Verisign trio delays, or abstains from, putting a secure delegation to .cn in the DNS root zone file (once the root is DNSSEC-aware), and that computers not distributed under the influence of the Chinese government do not have a "trusted-keys" configuration statement for .cn, this is mis-management from the part of ICANN/SSG-DOC-NTIA/Verisign (while it is allowed by RFC4033/4/5). Welcome to the ICANN politicking game! More generally, tailoring a system monitoring log during the global DNSSEC deployment effort is certainly not trivial! And Bill Manning report shows that it will use massive mass storage areas (hopefully temporarily). Cheers, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau at connotech.com From paul at xelerance.com Fri Sep 8 09:44:19 2006 From: paul at xelerance.com (Paul Wouters) Date: Fri, 8 Sep 2006 15:44:19 +0200 (CEST) Subject: [dnssec-deployment] BIND and OpenSSL's RSA signature forging issue In-Reply-To: References: Message-ID: On Fri, 8 Sep 2006, Thierry Moreau wrote: > > Upgrade OpenSSL. > > Or use the proper command-line argument in the BIND-specific dnssec-keygen > utility? For those using Olaf's Net-DNS-SEC-Maint-Key, change dnssecmaint.conf's dnssec_keygen= to include the '-e' option. Paul From roy at dnss.ec Fri Sep 8 10:05:28 2006 From: roy at dnss.ec (Roy Arends) Date: Fri, 8 Sep 2006 16:05:28 +0200 Subject: Ripe and SE keyroll In-Reply-To: References: Message-ID: <42DF5EBD-8D2D-4B34-A5B8-3D32AC84872A@dnss.ec> fyi I noticed that SE uses e=65537 for their KSK and e=3 for their ZSKs. This means that the keyroll (all zsk's need to be e<>3) should go smoothly and no emergency trust anchor rollover is needed. This is not the case for RIPE (194.in-addr.arpa). RIPE uses e=3 for both ZSK and KSK. Hence an emergency trust anchor roll is needed. Regards, Roy From Mark_Andrews at isc.org Fri Sep 8 10:15:53 2006 From: Mark_Andrews at isc.org (Mark Andrews) Date: Sat, 09 Sep 2006 00:15:53 +1000 Subject: [dnssec-deployment] yet another resource constraint In-Reply-To: Your message of "Fri, 08 Sep 2006 09:09:50 -0400." Message-ID: <200609081415.k88EFr0L037782@drugs.dv.isc.org> > Mark Andrews wrote: > > > > > I do know that if DNSSEC is mis-managed you will get a lot > > error messages. > > > > You mean (from the previous messages in the thread), as a "purely > arbitrary" example, that if the ICANN/SSG-DOC-NTIA/Verisign trio delays, > or abstains from, putting a secure delegation to .cn in the DNS root > zone file (once the root is DNSSEC-aware), and that computers not > distributed under the influence of the Chinese government do not have a > "trusted-keys" configuration statement for .cn, this is mis-management > from the part of ICANN/SSG-DOC-NTIA/Verisign (while it is allowed by > RFC4033/4/5). Welcome to the ICANN politicking game! No. Go re-read my previous responses. I was talking in the purely technical sense of mis-managemant. > More generally, tailoring a system monitoring log during the global > DNSSEC deployment effort is certainly not trivial! And Bill Manning > report shows that it will use massive mass storage areas (hopefully > temporarily). > > Cheers, > > -- > > - Thierry Moreau > > CONNOTECH Experts-conseils inc. > 9130 Place de Montgolfier > Montreal, Qc > Canada H2M 2A1 > > Tel.: (514)385-5691 > Fax: (514)385-5900 > > web site: http://www.connotech.com > e-mail: thierry.moreau at connotech.com > > > ############################################################# > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > A public archive is available here: ec-deployment/> > and older material is at > -- ISC Training! October 16-20, 2006, in the San Francisco Bay Area, covering topics from DNS to DHCP. Email training at isc.org. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From thierry.moreau at connotech.com Fri Sep 8 11:08:41 2006 From: thierry.moreau at connotech.com (Thierry Moreau) Date: Fri, 08 Sep 2006 11:08:41 -0400 Subject: [dnssec-deployment] Ripe and SE keyroll In-Reply-To: References: Message-ID: <45018779.2060701@connotech.com> Roy Arends wrote: > fyi > > I noticed that SE uses e=65537 for their KSK and e=3 for their ZSKs. > This means that the keyroll (all zsk's need to be e<>3) should go > smoothly and no emergency trust anchor rollover is needed. > > This is not the case for RIPE (194.in-addr.arpa). RIPE uses e=3 for > both ZSK and KSK. Hence an emergency trust anchor roll is needed. > Perhaps you may check if BIND DNSSEC signature verification, which is different from SSL X.509 security certificate signature verification, actually does have the implementation flaw?? The protocol formats are different, and the X.509 format is more fertile ground for implementation error, because the message payload length is self-encoded in ASN.1 encoding, and duplicated in the message header length. In RFC3035 section 5.3.2 and RFC3110, it is possible that either 1) BIND does not rely on OpenSSL for length checking concurrent with RSA validation, and/or 2) BIND software can in no circumstances pass erroneous length indications to OpenSSL (after all, DNSSEC spec tells implementers to *reconstruct* input to the RSA signature verification routine). If it (BIND + deployed SEP KSKs) isn't broken, don't fix it as an emergency response to a false alarm. On the other hand, we deprecate public exponent 3 in *any* operational use of RSA cryptosystem, so we spare ourselves a few emergency responses in a 10-year horizon. -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau at connotech.com From bmanning at vacation.karoshi.com Fri Sep 8 11:45:57 2006 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 8 Sep 2006 15:45:57 +0000 Subject: Fwd: [mph] the rs.net root key Message-ID: <20060908154557.GA24635@vacation.karoshi.com.> > one may get this key via: > > %finger apex at rs.net > > it has the large exponent. unfortuneately, i expect there to be many keys rolling, > so the existing DS records are likely out of date... more details on monday, 11sep --bill From bmanning at vacation.karoshi.com Fri Sep 8 12:52:02 2006 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 8 Sep 2006 16:52:02 +0000 Subject: what to hand your parent Message-ID: <20060908165202.GA25087@vacation.karoshi.com.> so, what is conventional wisdom here? after poking this dnssec thing for a while, i've been convinced that i don't want my childs keys so that i can create a DS rrset for them. why? because then I set the TTL... it would be better if the child created the DS w/ the appropriate TTL and then handed it to the parent, n'est pas? --bill From roy at dnss.ec Sat Sep 9 11:03:38 2006 From: roy at dnss.ec (Roy Arends) Date: Sat, 9 Sep 2006 17:03:38 +0200 Subject: [dnssec-deployment] Ripe and SE keyroll In-Reply-To: <45018779.2060701@connotech.com> References: <45018779.2060701@connotech.com> Message-ID: <133794A2-2659-4B6D-8351-0D55405861AA@dnss.ec> On Sep 8, 2006, at 5:08 PM, Thierry Moreau wrote: > > > Roy Arends wrote: > >> fyi >> I noticed that SE uses e=65537 for their KSK and e=3 for their >> ZSKs. This means that the keyroll (all zsk's need to be e<>3) >> should go smoothly and no emergency trust anchor rollover is needed. >> This is not the case for RIPE (194.in-addr.arpa). RIPE uses e=3 >> for both ZSK and KSK. Hence an emergency trust anchor roll is >> needed. > > Perhaps you may check if BIND DNSSEC signature verification, which > is different from SSL X.509 security certificate signature > verification, actually does have the implementation flaw?? > > The protocol formats are different, and the X.509 format is more > fertile ground for implementation error, because the message > payload length is self-encoded in ASN.1 encoding, and duplicated in > the message header length. In RFC3035 section 5.3.2 and RFC3110, it > is possible that either 1) BIND does not rely on OpenSSL for length > checking concurrent with RSA validation, and/or BIND uses openssl. There is a check during configure if the version is 0.9.5a or higher. I guess it should be either at least 0.9.7k or 0.9.8c for upcoming releases. > 2) BIND software can in no circumstances pass erroneous length > indications to OpenSSL (after all, DNSSEC spec tells implementers > to *reconstruct* input to the RSA signature verification routine). The issue here is not passing the erroneous length indication to openssl. The issue is that openssl did not check if the pkcs padding was long enough so that len(00 01 FF*) is equal to len(modulus)-288 before removing the padding, thus allowing trailing garbage. There is nothing that BIND or DNSSEC input reconstruction can do here in order to circumvent the issue in openssl, since the padding itself will only be visible after the RRSIG signature payload is decrypted. The padding is then subsequently removed, and the hash is matched with the hash over message. All this is outside the scope of isc's named. > > If it (BIND + deployed SEP KSKs) isn't broken, don't fix it as an > emergency response to a false alarm. it is broken. > On the other hand, we deprecate public exponent 3 in *any* > operational use of RSA cryptosystem, so we spare ourselves a few > emergency responses in a 10-year horizon. yes. Roy From thierry.moreau at connotech.com Sat Sep 9 12:16:24 2006 From: thierry.moreau at connotech.com (Thierry Moreau) Date: Sat, 09 Sep 2006 12:16:24 -0400 Subject: [dnssec-deployment] Ripe and SE keyroll In-Reply-To: References: <45018779.2060701@connotech.com> Message-ID: <4502E8D8.8090408@connotech.com> Dear Roy: Thanks for setting the record straight. See below for a suggestion as possible workaround in the BIND application for the OpenSSL weakeness for RSA signature verification with the public exponent=3. Roy Arends wrote: > > On Sep 8, 2006, at 5:08 PM, Thierry Moreau wrote: > >> >> Perhaps you may check if BIND DNSSEC signature verification, which is >> different from SSL X.509 security certificate signature verification, >> actually does have the implementation flaw?? >> >> The protocol formats are different, and the X.509 format is more >> fertile ground for implementation error, because the message payload >> length is self-encoded in ASN.1 encoding, and duplicated in the >> message header length. In RFC3035 section 5.3.2 and RFC3110, it is >> possible that either 1) BIND does not rely on OpenSSL for length >> checking concurrent with RSA validation, and/or > > > BIND uses openssl. There is a check during configure if the version is > 0.9.5a or higher. I guess it should be either at least 0.9.7k or 0.9.8c > for upcoming releases. > >> 2) BIND software can in no circumstances pass erroneous length >> indications to OpenSSL (after all, DNSSEC spec tells implementers to >> *reconstruct* input to the RSA signature verification routine). > > > The issue here is not passing the erroneous length indication to > openssl. The issue is that openssl did not check if the pkcs padding > was long enough so that len(00 01 FF*) is equal to len(modulus)-288 > before removing the padding, thus allowing trailing garbage. There is > nothing that BIND or DNSSEC input reconstruction can do here in order > to circumvent the issue in openssl, since the padding itself will only > be visible after the RRSIG signature payload is decrypted. The padding > is then subsequently removed, and the hash is matched with the hash > over message. All this is outside the scope of isc's named. "the padding itself will only be visible after the RRSIG signature payload is decrypted" actually, to be more accurate, this should read: "the padding itself will only be visible after the RRSIG signature payload is passed to the RSA encryptin function with the public signature key" and this leads to the suggestion below. > >> >> If it (BIND + deployed SEP KSKs) isn't broken, don't fix it as an >> emergency response to a false alarm. > > > it is broken. > I agree. Here is a suggestion for a workaroud in BIND as an OpenSSL appication: From the RSA public signature key, make a temporary RSA public encryption key (I don't know the OpenSSL API details, but key usage integrity is typically enforced by a crypto library, so the {DNSKEY RR conversion to OpenSSL RSA public signature key object} can be followed by a {DNSKEY RR conversion to OpenSSL RSA public encryption key object} using the same RSA modulus and exponent from the DNSKEY RR contents). Ask OpenSSL to encrypt the RRSIG signature payload with the temporary RSA public encryption key. Check that the padding length is adequate. This workaround in the BIND application is obviously neither a substitute for OpenSSL upgrade nor an endorsement of any public exponent 3 in any operational use of RSA cryptosystem. But it might assist the reduction of vulnerable portion of DNSSEC deployed technology (BIND version and OpenSSL version at the resolver side, DNSSEC RR public exponent values=3 anywhere along the chain of trust). This workaround idea is available to any application using OpenSSL. Feel free to circulate it in any other application forum. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau at connotech.com From ben at algroup.co.uk Sun Sep 10 02:12:52 2006 From: ben at algroup.co.uk (Ben Laurie) Date: Sun, 10 Sep 2006 07:12:52 +0100 Subject: [dnssec-deployment] Ripe and SE keyroll In-Reply-To: References: <45018779.2060701@connotech.com> Message-ID: <4503ACE4.3040806@algroup.co.uk> Thierry Moreau wrote: > Dear Roy: > > Thanks for setting the record straight. See below for a suggestion as > possible workaround in the BIND application for the OpenSSL weakeness > for RSA signature verification with the public exponent=3. > > Roy Arends wrote: > >> >> On Sep 8, 2006, at 5:08 PM, Thierry Moreau wrote: >> >>> >>> Perhaps you may check if BIND DNSSEC signature verification, which >>> is different from SSL X.509 security certificate signature >>> verification, actually does have the implementation flaw?? >>> >>> The protocol formats are different, and the X.509 format is more >>> fertile ground for implementation error, because the message payload >>> length is self-encoded in ASN.1 encoding, and duplicated in the >>> message header length. In RFC3035 section 5.3.2 and RFC3110, it is >>> possible that either 1) BIND does not rely on OpenSSL for length >>> checking concurrent with RSA validation, and/or >> >> >> BIND uses openssl. There is a check during configure if the version >> is 0.9.5a or higher. I guess it should be either at least 0.9.7k or >> 0.9.8c for upcoming releases. >> >>> 2) BIND software can in no circumstances pass erroneous length >>> indications to OpenSSL (after all, DNSSEC spec tells implementers to >>> *reconstruct* input to the RSA signature verification routine). >> >> >> The issue here is not passing the erroneous length indication to >> openssl. The issue is that openssl did not check if the pkcs padding >> was long enough so that len(00 01 FF*) is equal to len(modulus)-288 >> before removing the padding, thus allowing trailing garbage. There is >> nothing that BIND or DNSSEC input reconstruction can do here in order >> to circumvent the issue in openssl, since the padding itself will >> only be visible after the RRSIG signature payload is decrypted. The >> padding is then subsequently removed, and the hash is matched with >> the hash over message. All this is outside the scope of isc's named. > > "the padding itself will only be visible after the RRSIG signature > payload is decrypted" > > actually, to be more accurate, this should read: > > "the padding itself will only be visible after the RRSIG signature > payload is passed to the RSA encryptin function with the public > signature key" > > and this leads to the suggestion below. > >> >>> >>> If it (BIND + deployed SEP KSKs) isn't broken, don't fix it as an >>> emergency response to a false alarm. >> >> >> it is broken. >> > > I agree. > > Here is a suggestion for a workaroud in BIND as an OpenSSL appication: > > From the RSA public signature key, make a temporary RSA public > encryption key (I don't know the OpenSSL API details, but key usage > integrity is typically enforced by a crypto library, so the {DNSKEY RR > conversion to OpenSSL RSA public signature key object} can be followed > by a {DNSKEY RR conversion to OpenSSL RSA public encryption key object} > using the same RSA modulus and exponent from the DNSKEY RR contents). > > Ask OpenSSL to encrypt the RRSIG signature payload with the temporary > RSA public encryption key. > > Check that the padding length is adequate. > > This workaround in the BIND application is obviously neither a > substitute for OpenSSL upgrade nor an endorsement of any public exponent > 3 in any operational use of RSA cryptosystem. But it might assist the > reduction of vulnerable portion of DNSSEC deployed technology (BIND > version and OpenSSL version at the resolver side, DNSSEC RR public > exponent values=3 anywhere along the chain of trust). > > This workaround idea is available to any application using OpenSSL. Feel > free to circulate it in any other application forum. You don't need to work around it, since OpenSSL has been fixed for nearly a week now. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff From thierry.moreau at connotech.com Sun Sep 10 06:23:12 2006 From: thierry.moreau at connotech.com (Thierry Moreau) Date: Sun, 10 Sep 2006 06:23:12 -0400 Subject: [dnssec-deployment] Ripe and SE keyroll In-Reply-To: References: <45018779.2060701@connotech.com> Message-ID: <4503E790.9040909@connotech.com> Ben Laurie wrote: > Thierry Moreau wrote: > >>Dear Roy: >> >>[...] >> >>Here is a suggestion for a workaroud in BIND as an OpenSSL appication: >> >>>From the RSA public signature key, make a temporary RSA public >>encryption key (I don't know the OpenSSL API details, but key usage >>integrity is typically enforced by a crypto library, so the {DNSKEY RR >>conversion to OpenSSL RSA public signature key object} can be followed >>by a {DNSKEY RR conversion to OpenSSL RSA public encryption key object} >>using the same RSA modulus and exponent from the DNSKEY RR contents). >> >>Ask OpenSSL to encrypt the RRSIG signature payload with the temporary >>RSA public encryption key. >> >>Check that the padding length is adequate. >> >>This workaround in the BIND application is obviously neither a >>substitute for OpenSSL upgrade nor an endorsement of any public exponent >>3 in any operational use of RSA cryptosystem. But it might assist the >>reduction of vulnerable portion of DNSSEC deployed technology (BIND >>version and OpenSSL version at the resolver side, DNSSEC RR public >>exponent values=3 anywhere along the chain of trust). >> >>This workaround idea is available to any application using OpenSSL. Feel >>free to circulate it in any other application forum. > > > You don't need to work around it, since OpenSSL has been fixed for > nearly a week now. > Yes, but what if it is not convenient to upgrade OpenSSL in a given run-time environment and it is possible to install or upgrade to an application that uses OpenSSL. I do not argue that it is good practice to rely on an application workaround for a cryptographic library weakness, but in some circumstances, it could be unavoidable or very effort-efficient. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau at connotech.com From Ed.Lewis at neustar.biz Sun Sep 10 09:38:56 2006 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Sun, 10 Sep 2006 09:38:56 -0400 Subject: [dnssec-deployment] what to hand your parent In-Reply-To: References: Message-ID: At 16:52 +0000 9/8/06, bmanning at vacation.karoshi.com wrote: > it would be better if the child created the DS w/ the appropriate > TTL and then handed it to the parent, n'est pas? When we were designing the EPP extension for DNSSEC, we thought about this. he extension mechanism permits the client to submit a TTL with the DS information. The server retains the right to ignore this suggestion. After we designed in the the function, looking at it from an operations point of view, having the child set the TTL for the parent is not likely to catch on. For one, when you have a lot of delegations, customization is less likely to happen. More appropriately, the TTL of any RRSET really is a parameter belonging to the authority for the record set. The TTL is partly determined on the capacity and deployment of the server constellation. The TTL is not supposed to be sensitive to the RDATA contents, rather related to the control of behavior in caches. If the client is able to determine the TTL, there is the chance that the child can abuse the parent's service, by setting the TTL unnaturally low. This is a remote and probably low impact event, but still, if SLA's are to be met, why take the chance? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Secrets of Success #107: Why arrive at 7am for the good parking space? Come in at 11am while the early birds drive out to lunch. From paf at cisco.com Mon Sep 11 03:12:08 2006 From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Mon, 11 Sep 2006 09:12:08 +0200 Subject: [dnssec-deployment] New Microsoft bulletin - DNS issue In-Reply-To: References: Message-ID: <7005E4E3-3E54-45BF-B977-78F579F380F2@cisco.com> On 9 aug 2006, at 14.53, Marcus H. Sachs - SRI wrote: > Fully concur about this being a resolver problem. It's still a > "DNS issue" > but not on the server side. Unfortunately DNSSEC won't help in > cases like > this. Correct, but DNSSEC at least forces the DNS data to come from a zone that is signed, instead of from whatever random caching resolver, or injected response in the DNS query path. So I claim utilizing issues like these will be harder with DNSSEC completely deployed. Patrik > Marc > > -----Original Message----- > From: DNSSEC deployment [mailto:dnssec-deployment at shinkuro.com] On > Behalf Of > Jaap Akkerhuis > Sent: Wednesday, August 09, 2006 7:08 AM > To: DNSSEC deployment > Cc: Marcus H. Sachs - SRI > Subject: Re: [dnssec-deployment] New Microsoft bulletin - DNS issue > > > https://www.microsoft.com/technet/security/bulletin/ms06-041.mspx > > Remote code execution via a DNS response. This looks pretty > nasty, and > I > don't think that DNSSEC would prevent exploitation. > > This not an DNS issue but a broken dns resolver issue. > > jaap > > ############################################################# > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > A public archive is available here: > > and older material is at > From galvin at elistx.com Mon Sep 11 12:18:10 2006 From: galvin at elistx.com (James M Galvin) Date: Mon, 11 Sep 2006 12:18:10 -0400 Subject: meeting announcement: 13 September 2006 Message-ID: <38F850569DED9DF13AAD760E@[10.0.0.5]> This meeting will be held at the usual time of: 1200 Los Angeles, San Francisco 1200 Phoenix 1300 Salt Lake City 1500 Washington 1900 UTC 2000 London 2100 Netherlands 2200 Israel 0400 Tokyo (the next day) 0500 Melbourne (the next day) The usual teleconference logistics are as follows. These do not change. You will hear music until the moderator joins. USA Toll Free Number: +1 888-221-7341 USA Toll Number: +1 973-935-2305 Passcode: 599786 Leader: James Galvin employed by ICANN if speaking to an operator Jabber: dnssec-deployment at conference.jabber.org This is a public room. If your phone does not have a mute capability you can use "*6" to mute and unmute your connection. DIAL OUT: 1. ISC SIP Bridge - contact me for SIP identifiers DRAFT AGENDA * DNSSEC testbeds (or environments for operational experiments) Our discussion this meeting will be about testbeds: - what is available? - what are your needs or requirements for a testbed? - how do you use them? - what results do you get from them? - how do they fit into the transition? Anyone who has used, is using, or plans to use a testbed as part of their plan for deploying DNSSEC is invited to speak about their activities. I am putting together a list of speakers which I will distribute as people confirm their participation. If you know you will be available and want to speak please send me a note and let me know so I can include you on the list. Last minute entries will be welcome if there is time available. From olaf at NLnetLabs.nl Mon Sep 11 15:42:22 2006 From: olaf at NLnetLabs.nl (Olaf M. Kolkman) Date: Mon, 11 Sep 2006 21:42:22 +0200 Subject: [dnssec-deployment] what to hand your parent In-Reply-To: References: Message-ID: On 8Sep 2006, at 6:52 PM, bmanning at vacation.karoshi.com wrote: > > so, what is conventional wisdom here? after poking this dnssec > thing for a while, i've been convinced that i don't want my childs > keys so that i can create a DS rrset for them. > > why? because then I set the TTL... > > it would be better if the child created the DS w/ the appropriate > TTL and then handed it to the parent, n'est pas? Why is the TTL important in this context? (sincere open question) The signature validity interval of the RRSIG over the DS is a relevant parameter since that determines the time for which a child is vulnerable after its KSK has been compromised. The TTL is somewhat important for the duration of rollover steps. But as long as the child knows that TTL it should be fine. --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ From paul at xelerance.com Mon Sep 11 16:52:36 2006 From: paul at xelerance.com (Paul Wouters) Date: Mon, 11 Sep 2006 22:52:36 +0200 (CEST) Subject: [dnssec-deployment] what to hand your parent In-Reply-To: References: Message-ID: On Mon, 11 Sep 2006, Olaf M. Kolkman wrote: > Why is the TTL important in this context? (sincere open question) > > The signature validity interval of the RRSIG over the DS is a relevant > parameter since that determines the time for which a child is vulnerable after > its KSK has been compromised. The TTL is somewhat important for the duration > of rollover steps. But as long as the child knows that TTL it should be fine. Currently, RIPE has a TTL of two days on the DS and its RRISG, with a signature lifetime of 1 month. ;; ANSWER SECTION: 157.110.193.in-addr.arpa. 172800 IN DS 60588 5 1 ( F249F96E44E2D1056C6FFE2E28DBFBA57875891F ) 157.110.193.in-addr.arpa. 172800 IN RRSIG DS 5 5 172800 20061011185048 ( 20060911185048 8675 193.in-addr.arpa. BlTP7qc6rkyDQQPb3Gp52n/hzI6kQMteFs+Gx5DvHPZE +DqZ1yVqf5qxWaaDtkpHiNITro2F4rS5Anl0qftr8KHF 01eKtNWpZ22PaHm9y3jaVQ/tNV5Og4q+mV2nu/RIySdv hE6DiSbYtWqu4wRq5//OYI0gKpP8Pauw8yhl1xuBNO/N h/I9EXsCzMOw5Tg1j7A0R7mx ) I'm not sure how often RIPE reloads their nameservers and how often DS records get updated, but I would imagine that it would be at least once a day. This means that the current TTL would cause me to be vulnerable for 1 day after my KSK rollover has completed. Note that this relates to a KSK compromise on *my* end, not on RIPE's end. I am not sure what people mean with an "emergency ksk rollover" though. The way I've interpreted things is that an emergency KSK rollover is a one-step key replacmement, causing a temporary invalid DS record, whereas as normal KSK rollover involves a two-step KSK rollover where one ensures the DS is always pointing to a valid key for TTL+cache value. Using those definitions, the question is what is more damaging, an emergency KSK rollover or running with a compromised KSK and doing a proper two stage KSK rollover. Or in other words, do I want my domain vulnerable to (validated) spoofing, or do I want my domain to be down? Also, what is the procedure for the DS records when signed by a compromised key. In RIPE's case, shouldn't RIPE drop all the DS records it had within 194.in-addr.arpa, thereby clearly marking the underlying zones as insecure? If so, that clearly related directly to the TTL of the DS records. I do think RIPE's TTL value is a sane one. It allows their servers to screwup re-signing for 1 day without breakage. Paul From olaf at NLnetLabs.nl Tue Sep 12 01:08:38 2006 From: olaf at NLnetLabs.nl (Olaf M. Kolkman) Date: Tue, 12 Sep 2006 07:08:38 +0200 Subject: [dnssec-deployment] what to hand your parent In-Reply-To: References: Message-ID: <1AFDBDD4-E214-4807-9F9F-068F7F99028F@nlnetlabs.nl> On 11Sep 2006, at 10:52 PM, Paul Wouters wrote: > I'm not sure how often RIPE reloads their nameservers and how often DS > records get updated, but I would imagine that it would be at least > once > a day. This means that the current TTL would cause me to be vulnerable > for 1 day after my KSK rollover has completed. Note that this > relates to > a KSK compromise on *my* end, not on RIPE's end. Although RIPE would not be serving the DS, and the DS would have disappeared from most caches it would still be possible to replay the 'old DS' with a valid signature. That is what I mean with being vulnerable. But, when a KSK is lost (destroyed) by the child and it needs to be replaced then the short TTL on the parents side will help to quickly introduce a new key. The child would better notice while the signature over the keyset is still valid. > > I am not sure what people mean with an "emergency ksk rollover" > though. The way I've interpreted things is that an emergency KSK > rollover > is a one-step key replacmement, causing a temporary invalid DS record, > whereas as normal KSK rollover involves a two-step KSK rollover where > one ensures the DS is always pointing to a valid key for TTL+cache > value. > Yep. 4.3.1 of http://tools.ietf.org/wg/dnsop/draft-ietf-dnsop-dnssec-operational- practices/ (to be published as RFC4641 within days) > Using those definitions, the question is what is more damaging, an > emergency KSK rollover or running with a compromised KSK and doing a > proper two stage KSK rollover. Or in other words, do I want my domain > vulnerable to (validated) spoofing, or do I want my domain to be down? > In soon to be RFC4641 we (being the dnsop WG) say: "Local Policy" but we advise not to remove the KSK before the parent has a DS to a new KSK in place. > Also, what is the procedure for the DS records when signed by a > compromised > key. In RIPE's case, shouldn't RIPE drop all the DS records it had > within > 194.in-addr.arpa, thereby clearly marking the underlying zones as > insecure? > If so, that clearly related directly to the TTL of the DS records. > This is where I loose you. The DS RRs in RIPE NCC's zone do not turn invalid by the compromise of the key. (To exaggerate: You wouldn't remove all NS RRs in com if its key would be compromised). The RRSIGs need to be changed. Again the trade-off is continuation of service (with the change of somebody launching an attack with the compromised key) vs blackout and that, I think, is a local policy that depends to a large number of factors. > I do think RIPE's TTL value is a sane one. It allows their servers to > screwup re-signing for 1 day without breakage. Signature validity time determines the 're-signing' (currently that is a month). The TTL determines how long RIPE NCC's nameservers can be out of the air and the time it takes to replace the DS RRs under normal operations. But you have to assume that when a child's KSK is compromised, the DS RR pointing to it can be replayed for another month. --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ From paul at xelerance.com Tue Sep 12 11:09:58 2006 From: paul at xelerance.com (Paul Wouters) Date: Tue, 12 Sep 2006 17:09:58 +0200 (CEST) Subject: [dnssec-deployment] what to hand your parent In-Reply-To: References: Message-ID: On Tue, 12 Sep 2006, Olaf M. Kolkman wrote: > Although RIPE would not be serving the DS, and the DS would have disappeared > from most caches it would still be possible to replay the 'old DS' with a > valid signature. That is what I mean with being vulnerable. Oops. I have confused the impact of TTL vs SIG lifetime in a few of my thoughts. Thank you for correcting that. It does make me somewhat uncomfortable about the one month timescale for DS replay attacks though. That is quite a long time. > > Also, what is the procedure for the DS records when signed by a compromised > > key. In RIPE's case, shouldn't RIPE drop all the DS records it had within > > 194.in-addr.arpa, thereby clearly marking the underlying zones as insecure? > > If so, that clearly related directly to the TTL of the DS records. > > > > This is where I loose you. The DS RRs in RIPE NCC's zone do not turn invalid > by the compromise of the key. Though they are not invalid, they have lost some of their trust value since the key that signed them turned out to have issues. If you would remove the DS records, then the "endusers" (once applications become dnssec aware) would become aware of this. Perhaps a more concrete example. Say I have an IPSEC record in a.b.c.194-in.addr.arpa and I rely on that record being secure. Now RIPE's key is faulty/compromised, but as long as that key keeps signing and publishing DS records, I will never know, while (in this case) some validation checks could be bypassed because of the exponent=3 bug. > in com if its key would be compromised). The RRSIGs need to be changed. Again > the trade-off is continuation of service (with the change of somebody > launching an attack with the compromised key) vs blackout and that, I think, > is a local policy that depends to a large number of factors. But we wouldnt have a blackout, we would just be verifiably insecure? > > I do think RIPE's TTL value is a sane one. It allows their servers to > > screwup re-signing for 1 day without breakage. > > Signature validity time determines the 're-signing' (currently that is a > month). The TTL determines how long RIPE NCC's nameservers can be out of the > air and the time it takes to replace the DS RRs under normal operations. But > you have to assume that when a child's KSK is compromised, the DS RR pointing > to it can be replayed for another month. Isn't this a rather long period? Why is this period not a week or 3 days? Though I guess we are really getting into the realms of politics here, and companies in general are still not fond of reporting vulnerabilities, mistakes or compromises of their data (unless forced by law). And I guess in general people will want to quietly fix their keys instead of announcing it. Paul From bmanning at vacation.karoshi.com Tue Sep 12 11:26:15 2006 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 12 Sep 2006 15:26:15 +0000 Subject: concreate examples In-Reply-To: References: Message-ID: <20060912152615.GA26089@vacation.karoshi.com.> > Perhaps a more concrete example. Say I have an IPSEC record in > a.b.c.194-in.addr.arpa and I rely on that record being secure. Now > RIPE's key is faulty/compromised, but as long as that key keeps > signing and publishing DS records, I will never know, while (in this case) > some validation checks could be bypassed because of the exponent=3 bug. > chatting w/ Mr. Carr @ RIPE, i discover that RIPE is -not- creating DS records to hand to the parent (e.g. DS records for the in-addr.arpa zone) and so i have asked for permission to generate them myself for the rs.net testbed. He agreed. --bill From jeroen at unfix.org Wed Sep 13 07:36:39 2006 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 13 Sep 2006 13:36:39 +0200 Subject: Web-based / semi-automated DLV registry Message-ID: <4507ED47.1010303@unfix.org> Hi, A 'quick' question for the list, which maybe could be addressed on the call tonight if time allows and there is a interest in it. The majority of the domains (forward lookup) currently on the internet are not easily linked to a registry which also allows registration in either an official DNSSEC tree or DLV. The first in most cases don't support it (like trying to get AAAA's for NS's), the latter because it requires a manual registration and verification of credentials which is hard to establish especially when large amounts of people want it. The biggest problem with this is indeed the trust relationship. Still, for DNSSEC deployment to have a take-up a solid user base is required, sort of similar to the IPv6 chicken and egg problem: Content providers don't have it, thus Access providers don't see a reason to provide it, Access providers have it, but there is no content. By enabling an easy, but strict, method of verification this could allow the user-base to grow and more experience to be learned from it. To take an example, FreeSSL has a 'heavy' authentication, they charge for it which is maybe not a good idea. What they do when you sign up for an SSL cert for a domain is: - ask for domain name - ask for user's details - show admin contacts (whois, postmaster@, webmaster@) - send that domain an email - let the user verify itself using this email by going to a webpage in the email. - show the user a verification number - automated call the user on the number he/she gave in step 2 - user has to say his/her name (which is recorded for future ref and I guess for freessl to be able to say "this is the person" or something ;) - One then has to type the number you see on the screen. They thus have: - most likely your valid name + address and other details - a phone number where you are reachable on (could be a cell phone, a company line or a phonebooth if you know where to find those) - an email address that you can read at the domain or in the whois The voice-step is costly, as one would need to make voice calls. Also it doesn't really add much for security especially that one can walk into any place and use that phone. Email verification is what is done by most other services. eg hotmail does this for their SNDS service (https://postmaster.live.com/snds). Another angle to use could be PGP-Keys. It is not too difficult to get a key that is signed and into the strong set, quite some technical people, the ones who most likely want to join up to do DNSSEC, already have keys and can other wise create a strong-key easily by letting friends and colleagues sign it. Especially ISP's should not have a problem in that case. And of course we could simply ask the user to publish a special record in their DNS zone. The ability for them to publish records in the currently existing DNS server proves more or less that they can do with the zone anyway what they want to do (ignoring somebody who just stole microsoft.com's NS glue of course ;) One could ask them to publish in DNS a TXT record containing the verification code that they got send through email for instance. My proposal would be to have a service that, based on a combination of domain whois / common addresses / pgpkey / special record in the domain, "authenticate" people to allow them get a linkup into the DLV so that they can make their domain DNSSEC capable. Do people think this is: - a very extremely bad idea - great! but needs mods - ...other options... If the answer is in the 'that would be good to have' category, there exists of course a problem of 'who is going to do the work' and 'where will it link into'. For SixXS (http://www.sixxs.net for folks who don't know it) I've been doing a bit of polling on people who would want to have DNSSEC capabilities for, at least, their reverse zones. Though the responses where not overwhelming quite some people would like it. But they also noted that it was not very worthwhile if the forward zone did not do DNSSEC. The above, unless somebody else wants to set it up, could easily be done in the SixXS framework, allowing people to register, not only for an IPv6 connection, but also additionally/only for a DNSSEC hook. The first step of the user-auth is already handled a bit too thoroughly in SixXS (See http://www.sixxs.net/misc/requests/), thus people who are not able to provide valid informations won't easily be able to come into the DNSSEC hook either. Building in the additional checks etc should not be a big task, though it will take some time and testing. It will provide for a lot of happy people who can then suddenly enable DNSSEC on their domains. So what do folks think? (the mail turned out not to be that quick ;) Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature Url : http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20060913/14b14378/attachment.bin From olaf at NLnetLabs.nl Wed Sep 13 09:57:37 2006 From: olaf at NLnetLabs.nl (Olaf M. Kolkman) Date: Wed, 13 Sep 2006 15:57:37 +0200 Subject: [dnssec-deployment] what to hand your parent In-Reply-To: References: Message-ID: On 12Sep 2006, at 5:09 PM, Paul Wouters wrote: > > Though they are not invalid, they have lost some of their trust value > since the key that signed them turned out to have issues. If you would > remove the DS records, then the "endusers" (once applications become > dnssec aware) would become aware of this. > > Perhaps a more concrete example. Say I have an IPSEC record in > a.b.c.194-in.addr.arpa and I rely on that record being secure. To use the same argument. So what would happen if your KSK would be compromised, that would reduce some of the 'trust value' of your IPSEC RRs. Would you remove the IPSEC RRs in order to signal that? But, rereading your argument. Are you saying that RIPE NCC should pull the DS records that point to the child zones of 194.in- addr.arpa, or that it should ask the in-addr.arpa registry to remove the 194.in-addr.arpa DS RR? The latter would make sense given your argument. --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ From paul at xelerance.com Wed Sep 13 11:00:00 2006 From: paul at xelerance.com (Paul Wouters) Date: Wed, 13 Sep 2006 17:00:00 +0200 (CEST) Subject: [dnssec-deployment] what to hand your parent In-Reply-To: References: Message-ID: On Wed, 13 Sep 2006, Olaf M. Kolkman wrote: > > Though they are not invalid, they have lost some of their trust value > > since the key that signed them turned out to have issues. If you would > > remove the DS records, then the "endusers" (once applications become > > dnssec aware) would become aware of this. > > > > Perhaps a more concrete example. Say I have an IPSEC record in > > a.b.c.194-in.addr.arpa and I rely on that record being secure. > > To use the same argument. > > So what would happen if your KSK would be compromised, that would reduce some > of the 'trust value' of your IPSEC RRs. Would you remove the IPSEC RRs in > order to signal that? Probably not, because _I_ know already that there is a trust issue involved. (this assumes small scale personal domains without me having customers, otherwise I should follow the same guidelines indeed) > But, rereading your argument. Are you saying that RIPE NCC should pull the DS > records that point to the child zones of 194.in-addr.arpa, or that it should > ask the in-addr.arpa registry to remove the 194.in-addr.arpa DS RR? The latter > would make sense given your argument. I actually had not thought of that yet. I did mean the DS records in 194.in-addr.arpa, but you're right. Just pulling it from in-addr.arpa would make more sense, and accomplishes the same thing (provided no SEP / DLV would exist for 194.in-addr.arpa) Paul ps. btw. congrats on the ISOC-NL award :) From olaf at NLnetLabs.nl Wed Sep 13 12:04:58 2006 From: olaf at NLnetLabs.nl (Olaf M. Kolkman) Date: Wed, 13 Sep 2006 18:04:58 +0200 Subject: [dnssec-deployment] what to hand your parent In-Reply-To: References: Message-ID: >> >> So what would happen if your KSK would be compromised, that would >> reduce some >> of the 'trust value' of your IPSEC RRs. Would you remove the IPSEC >> RRs in >> order to signal that? > > Probably not, because _I_ know already that there is a trust issue > involved. > (this assumes small scale personal domains without me having > customers, > otherwise I should follow the same guidelines indeed) Hmmm. The core issue is that the keys at the child zones (and hence the DS- es) are still valid data. I don't think you should remove valid data from the DNS in order to signal that something is broken. The correct procedure is to roll the key and use off-band mechanisms that something is wrong. Obviously there is a trade-off what kind of urgency this should be done, with what kind of disruption in service and with what kind of communication. In this particular case one would role the key to protect individuals that have a broken library in place. If trust is that important for those folk you would expect them to upgrade their hardware. I think it is prudent to roll keys to a new exponent but I am not sure with what urgency and if this is the kind of situation where you'd yank the DS-es. (Yanking the DS-es in this case would mean that the folk that did upgrade to the latest open-ssl libs would not be protected). If a trust anchor is stolen (masked ninja turtles entering the vault) then the situation is a bit different. And you have to make the tradeoff do I roll key or do I continue operations and roll the key slowly. Would yanking a DS actually be noticed? I think that an application that would require a valid trust path would indeed notice that suddenly the app receives verifiably insecure data. But it could be that the compromised key is used (e.g. by the ninja's that also managed to hold a secondary server administrator at gunpoint) to launch an attack. Then the signal would not be seen. So, at this moment I am not yet convinced that yanking DS-es is a good idea. But I do think that a key-rollover (following the documented procedures so nobody is surprised) is actually the prudent thing to do. --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ From galvin at elistx.com Wed Sep 13 13:24:45 2006 From: galvin at elistx.com (James M Galvin) Date: Wed, 13 Sep 2006 13:24:45 -0400 Subject: [dnssec-deployment] meeting announcement: 13 September 2006 In-Reply-To: References: Message-ID: <4B2C122A4A02DE520A827621@[10.0.0.4]> Quick agenda update. The folks that have confirmed participation are as follows: Olaf Kolkman - NLnet Labs Paul Vixie - ISC Matt Larson - Verisign Several others have partial conflicts and will try to join late. Jim -- On Monday, September 11, 2006 12:18 PM -0400 James M Galvin wrote regarding [dnssec-deployment] meeting announcement: 13 September 2006 -- > This meeting will be held at the usual time of: > > 1200 Los Angeles, San Francisco > 1200 Phoenix > 1300 Salt Lake City > 1500 Washington > 1900 UTC > 2000 London > 2100 Netherlands > 2200 Israel > 0400 Tokyo (the next day) > 0500 Melbourne (the next day) > > The usual teleconference logistics are as follows. These do not > change. You will hear music until the moderator joins. > > USA Toll Free Number: +1 888-221-7341 > USA Toll Number: +1 973-935-2305 > > Passcode: 599786 > Leader: James Galvin > employed by ICANN if speaking to an operator > > Jabber: dnssec-deployment at conference.jabber.org > This is a public room. > > If your phone does not have a mute capability you can use "*6" > to mute and unmute your connection. > > DIAL OUT: > 1. ISC SIP Bridge - contact me for SIP identifiers > > > DRAFT AGENDA > > * DNSSEC testbeds (or environments for operational experiments) > > Our discussion this meeting will be about testbeds: > > - what is available? > - what are your needs or requirements for a testbed? > - how do you use them? > - what results do you get from them? > - how do they fit into the transition? > > Anyone who has used, is using, or plans to use a testbed as part > of their plan for deploying DNSSEC is invited to speak about > their > activities. > > I am putting together a list of speakers which I will distribute > as people confirm their participation. If you know you will be > available and want to speak please send me a note and let me > know > so I can include you on the list. Last minute entries will be > welcome if there is time available. > > > ############################################################# > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > A public archive is available here: > > and older material is at > From thierry.moreau at connotech.com Wed Sep 13 17:00:14 2006 From: thierry.moreau at connotech.com (Thierry Moreau) Date: Wed, 13 Sep 2006 17:00:14 -0400 Subject: Quick observations on alternate-rootism Message-ID: <4508715E.3000201@connotech.com> We had this presentation in the conference call earlier today: http://sa.vix.com/~vixie/alternate-rootism.pdf Basically, it's to have, ***under IANA control***, one (or more?) sets of root servers (e.g. from 1 to 13 servers) operating in parallel with the current set of DNS root servers. From two tiny or small scale experiences, the presenter reports no detrimental interference. Let IANA adopt DNSSEC for some, but initially not all, of the parallel sets of root servers. So it boils down to "signing the root" by ICANN/IANA, except that the operational stability would be less threatened by the recourse to parallel root servers. But is operational stability threatened by DNSSEC support at the root in the first place? The very formulation of the proposal may have the unexpected effect of suggesting a "maybe" answer! Anything that can assist "signing the root" by ICANN/IANA is OK. Cheers, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau at connotech.com From mcr at sandelman.ottawa.on.ca Wed Sep 13 17:07:13 2006 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Wed, 13 Sep 2006 17:07:13 -0400 Subject: [dnssec-deployment] Quick observations on alternate-rootism In-Reply-To: Message from Thierry Moreau of "Wed, 13 Sep 2006 17:00:14 EDT." References: Message-ID: <25161.1158181633@sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Thierry" == Thierry Moreau writes: Thierry> threatened by the recourse to parallel root servers. But is Thierry> operational stability threatened by DNSSEC support at the Thierry> root in the first place? The very formulation of the Thierry> proposal may have the unexpected effect of suggesting a Thierry> "maybe" answer! Thierry> Anything that can assist "signing the root" by ICANN/IANA Thierry> is OK. We may think that there is no issue with signing the root. Naysayers may fret. This gets rid of the concern. - -- ] Bear: "Me, I'm just a the shape of a bear." | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr at 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.4.3 (GNU/Linux) Comment: Finger me for keys iQEVAwUBRQhy/oCLcPvd0N1lAQI3Ygf8CS/6tbKYyZYJCRzr1RaNwel/HHP34TYE D0gt6HmW/EX/+ciuTaEHIlO4bP5xF/5MvF+tnM65Na4I0Q+QwybllD2q3xcY9pS8 xEGV5z2TwlLyYE1tPAtML/8FCy5VIWNYxzqCU9xR5svFq12nXt6H+S3JFf3+ttA3 qQmr3ucUYQexvODttgv9zybLIveU5aCu6lPrTYH2cK4M5Ymv7cNNzZRxGdR7ge+6 oJsgDQAFxw0635HAv5rjKNK7PRVwipigBEp+C+wsPOJA+qd9uG20X2RXokB0+pv4 Wf/Ach/aZ1obQXch6f8eYhAljHsWIRlSK5NTbOzTb8Vm0fSyLCsfMg== =ZHf3 -----END PGP SIGNATURE----- From sanz at denic.de Thu Sep 14 02:51:25 2006 From: sanz at denic.de (Marcos Sanz/Denic) Date: Thu, 14 Sep 2006 08:51:25 +0200 Subject: [dnssec-deployment] what to hand your parent In-Reply-To: Message-ID: Bill, > so, what is conventional wisdom here? after poking this dnssec > thing for a while, i've been convinced that i don't want my childs > keys so that i can create a DS rrset for them. Peter and I seemed to have different opinions about this point, so we had a somewhat longer discussion about it. FWIW these are the notes I took on the (hard and soft) operational advantages of handing a DNSKEY and a DS RR to your parent at the registration interface: DS advantages: + It's possible to deal with unknown hashes and algorithms of your children. Just blindly put the DS record in the zone. + No chance for making a mistake, since you don't have to calculate a DS out of a DNSKEY. Just blindly put the DS record in the zone. + It's unique information: you can always get the DNSKEY from your children in DNS, but the DS is not to be found there. + It's shorter and easier to deal with (imagine an extreme situation where the registration interface is the POTS). DNSKEY advantages: + It's possible to check for coherency with the DNSKEY published by your children in DNS. + It's original information: you can calculate the DS out of DNSKEY, but not the other way around. + It offers "security freedom" to the parent: he can calculate a new DS record whenever he wants and however he wants. + It has more information than a DS, e.g. whether you are dealing with a SEP or not. In the end we agreed that the purported hard advantages of a DS ("just put it blindly in the zone") are not realistic, because a parent will probably carry out some technical or policy-conformance tests on the data he is receiving. The "security freedom" argument for DNSKEY is very convincing. If the TTL for the record were to be needed at the parent, it could always be transmited as a sepparate parameter (like for instance EPP does). Regards, Marcos From Ed.Lewis at neustar.biz Thu Sep 14 08:29:37 2006 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 14 Sep 2006 08:29:37 -0400 Subject: [dnssec-deployment] what to hand your parent In-Reply-To: References: Message-ID: At 8:51 +0200 9/14/06, Marcos Sanz/Denic wrote: >In the end we agreed that the purported hard advantages of a DS ("just put >it blindly in the zone") are not realistic, because a parent will probably >carry out some technical or policy-conformance tests on the data he is >receiving. The "security freedom" argument for DNSKEY is very convincing. I'll add this to the argument because I have come to the different conclusion. In the spirit of leaving intelligence to the periphery, pushing computation and data transformation on to the client is desirable. Hence, having the client transmit the DS as it is to be presented is preferable over sending the ingredients for it. After all, the registry is associating the DS data with the registrant, not performing a security review (as in, did they do it right?). If the purpose of a registry is to associate values with objects (and only that) the DS ought to be what is transferred. If the purpose of the registry is to enforce a standard of behavior, and the standard includes data integrity with respect to the values registered, then the DNSKEY is needed in the transfer from client to server. One answer does not fit all though. It depends on the mission of the registry. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Secrets of Success #107: Why arrive at 7am for the good parking space? Come in at 11am while the early birds drive out to lunch. From steve at shinkuro.com Thu Sep 14 08:33:53 2006 From: steve at shinkuro.com (Steve Crocker) Date: Thu, 14 Sep 2006 08:33:53 -0400 Subject: [dnssec-deployment] what to hand your parent In-Reply-To: References: Message-ID: The transmission needs to be regularized. It won't be good for each parent to have it's own scheme. The CADR approach is to have the parent fetch the data from the child. This is the cleanest and most elegant approach I have seen. Steve Steve Crocker steve at shinkuro.com Try Shinkuro's collaboration technology. Visit www.shinkuro.com. I am steve!shinkuro.com. On Sep 14, 2006, at 8:29 AM, Edward Lewis wrote: > At 8:51 +0200 9/14/06, Marcos Sanz/Denic wrote: > >> In the end we agreed that the purported hard advantages of a DS >> ("just put >> it blindly in the zone") are not realistic, because a parent will >> probably >> carry out some technical or policy-conformance tests on the data >> he is >> receiving. The "security freedom" argument for DNSKEY is very >> convincing. > > I'll add this to the argument because I have come to the different > conclusion. In the spirit of leaving intelligence to the > periphery, pushing computation and data transformation on to the > client is desirable. Hence, having the client transmit the DS as > it is to be presented is preferable over sending the ingredients > for it. After all, the registry is associating the DS data with > the registrant, not performing a security review (as in, did they > do it right?). > > If the purpose of a registry is to associate values with objects > (and only that) the DS ought to be what is transferred. If the > purpose of the registry is to enforce a standard of behavior, and > the standard includes data integrity with respect to the values > registered, then the DNSKEY is needed in the transfer from client > to server. > > One answer does not fit all though. It depends on the mission of > the registry. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > =-=-=-=- > Edward Lewis > +1-571-434-5468 > NeuStar > > Secrets of Success #107: Why arrive at 7am for the good parking space? > Come in at 11am while the early birds drive out to lunch. > > ############################################################# > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > A public archive is available here: Lists/dnssec-deployment/> > and older material is at > From Ed.Lewis at neustar.biz Thu Sep 14 08:59:50 2006 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 14 Sep 2006 08:59:50 -0400 Subject: [dnssec-deployment] what to hand your parent In-Reply-To: References: Message-ID: What if there is no direct relationship between the parent and child? (Referring to the EPP environment.) I am not sure I'd agree with the need to be regularized. I don't think uniformity is a goal, nor something that scales. That's more than just a philosophical point, from my view of DNS is that the reason it has scaled to date is that it is so lose and forgiving of differing management styles. Of course, DNSSEC is supposed to be in the eyes of the resolver. So there is a call to make things somewhat regular or at least meet some basic expectations. Kind of what drove RFC 3007/8 (I keep getting those two numbers confused) to modify 2535. At 8:33 -0400 9/14/06, Steve Crocker wrote: >The transmission needs to be regularized. It won't be good for each >parent to have it's own scheme. > >The CADR approach is to have the parent fetch the data from the >child. This is the cleanest and most elegant approach I have seen. > >Steve > > >Steve Crocker >steve at shinkuro.com > >Try Shinkuro's collaboration technology. Visit www.shinkuro.com. I >am steve!shinkuro.com. > > >On Sep 14, 2006, at 8:29 AM, Edward Lewis wrote: > >> At 8:51 +0200 9/14/06, Marcos Sanz/Denic wrote: >> >>> In the end we agreed that the purported hard advantages of a DS ("just put >>> it blindly in the zone") are not realistic, because a parent will probably >>> carry out some technical or policy-conformance tests on the data he is >>> receiving. The "security freedom" argument for DNSKEY is very convincing. >> >> I'll add this to the argument because I have come to the different >>conclusion. In the spirit of leaving intelligence to the >>periphery, pushing computation and data transformation on to the >>client is desirable. Hence, having the client transmit the DS as >>it is to be presented is preferable over sending the ingredients >>for it. After all, the registry is associating the DS data with >>the registrant, not performing a security review (as in, did they >>do it right?). >> >> If the purpose of a registry is to associate values with objects >>(and only that) the DS ought to be what is transferred. If the >>purpose of the registry is to enforce a standard of behavior, and >>the standard includes data integrity with respect to the values >>registered, then the DNSKEY is needed in the transfer from client >>to server. >> >> One answer does not fit all though. It depends on the mission of >>the registry. >> >>---=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >> Edward Lewis >> +1-571-434-5468 >> NeuStar >> >> Secrets of Success #107: Why arrive at 7am for the good parking space? >> Come in at 11am while the early birds drive out to lunch. >> >> ############################################################# >> This message is sent to you because you are subscribed to >> the mailing list . >> To unsubscribe, E-mail to: >> A public archive is available here: >> >> and older material is at >> -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Secrets of Success #107: Why arrive at 7am for the good parking space? Come in at 11am while the early birds drive out to lunch. From bmanning at vacation.karoshi.com Thu Sep 14 10:37:56 2006 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 14 Sep 2006 14:37:56 +0000 Subject: [dnssec-deployment] what to hand your parent In-Reply-To: References: Message-ID: <20060914143756.GC7277@vacation.karoshi.com.> On Thu, Sep 14, 2006 at 08:51:25AM +0200, Marcos Sanz/Denic wrote: > Bill, > > > so, what is conventional wisdom here? after poking this dnssec > > thing for a while, i've been convinced that i don't want my childs > > keys so that i can create a DS rrset for them. > > Peter and I seemed to have different opinions about this point, so we had > a somewhat longer discussion about it. FWIW these are the notes I took on > the (hard and soft) operational advantages of handing a DNSKEY and a DS RR > to your parent at the registration interface: > > DS advantages: > + It's possible to deal with unknown hashes and algorithms of your > children. Just blindly put the DS record in the zone. > + No chance for making a mistake, since you don't have to calculate a DS > out of a DNSKEY. Just blindly put the DS record in the zone. > + It's unique information: you can always get the DNSKEY from your > children in DNS, but the DS is not to be found there. > + It's shorter and easier to deal with (imagine an extreme situation where > the registration interface is the POTS). all advatanges... but the term "...blindly put the {record} in the zone..." has negative conotations. don't you "blindly" put in the NS rrset the child tells you? :) > DNSKEY advantages: > + It's possible to check for coherency with the DNSKEY published by your > children in DNS. > + It's original information: you can calculate the DS out of DNSKEY, but > not the other way around. > + It offers "security freedom" to the parent: he can calculate a new DS > record whenever he wants and however he wants. > + It has more information than a DS, e.g. whether you are dealing with a > SEP or not. well... the 256/257 debate is still one of operational expediency. any DNSKEy -can- be used for a SEP... the "KSK/ZSK" split is not mandatory... right? > In the end we agreed that the purported hard advantages of a DS ("just put > it blindly in the zone") are not realistic, because a parent will probably > carry out some technical or policy-conformance tests on the data he is > receiving. The "security freedom" argument for DNSKEY is very convincing. just as convincing as the parent having "security freedom" to change the NS rrset of the child to suit her own percieved needs. imho of course. :) > If the TTL for the record were to be needed at the parent, it could always > be transmited as a sepparate parameter (like for instance EPP does). i was actually thinking of the fact that the TTL is incalculated in the generation of the DNSKEY - not sure if that has any relevence to the DS hash... > > Regards, > Marcos thanks for the considered followup. --bill From mcr at sandelman.ottawa.on.ca Thu Sep 14 17:03:41 2006 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Thu, 14 Sep 2006 17:03:41 -0400 Subject: [dnssec-deployment] what to hand your parent In-Reply-To: Message from Edward Lewis of "Thu, 14 Sep 2006 08:29:37 EDT." References: Message-ID: <10801.1158267821@sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Edward" == Edward Lewis writes: Edward> If the purpose of a registry is to associate values with Edward> objects (and only that) the DS ought to be what is Edward> transferred. If the purpose of the registry is to enforce a Edward> standard of behavior, and the standard includes data Edward> integrity with respect to the values registered, then the Edward> DNSKEY is needed in the transfer from client to server. Edward> One answer does not fit all though. It depends on the Edward> mission of the registry. -- I thought that the conclusion awhile ago was that the argument isn't between DS vs DNSKEY, but rather, which one was MUST, and which one was SHOULD. Except for the suggested POTS registration scheme, I just can't see how there will be many situations where there will be a size constraint. If I were a registrar (which I'm not, and I've never been one), I'd calculate a new DS from the one I'd been given. I'd then compare that to the DS that was handed to me. I'd then flag a problem if it didn't check out, but I'd have the ability to just use the DS (possibly multiple) that I was handed. (We've learnt how many ISPs have database systems that can not deal with anything other than PTR in reverse, and even ones that can't put CNAMEs in forward...) - -- ] Bear: "Me, I'm just a the shape of a bear." | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr at 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.4.3 (GNU/Linux) Comment: Finger me for keys iQEVAwUBRQnDqoCLcPvd0N1lAQL9yAf/Sl0ayoU6tFKFPN3ogS16U5ZpPilSFfPl 2+hnYH6BIryq9oNIkkFjrJVaBY5BEaFfdAnlewWSkscF3hwCH0Kia66sccx8gM/F Un6Ik+pzLz8kCAF2vkV+ArwRmFZY5ez+aGfEQSfkNUZgrdb2bArCn3Nxd9HJ09th d9GU6rUj17DrUMG7jsaYk7CUwOM8J3WIGg+4xyWk92RX+HDOBiXTuj+mql2yuJkN MUs2aOSmyS1HmtT2GyJdIjQAgZBWhGP6Fe0kwRQBBX3XAKPc0zQXLfMiyVJFAlG0 gpEgU8QqiDKZtNoZ+HEprphpmPYRoOxRPSYqmS77DYzleDx8ZSDlBA== =al7u -----END PGP SIGNATURE----- From jeroen at unfix.org Thu Sep 14 20:11:44 2006 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 15 Sep 2006 02:11:44 +0200 Subject: RFC 4641 on DNSSEC Operational Practices Message-ID: <4509EFC0.10801@unfix.org> Here we are with the long awaited RFC4641 brought to you by Olaf and Miek, thanks! Greets, Jeroen -------- Original Message -------- Subject: [dnsop] RFC 4641 on DNSSEC Operational Practices Date: Thu, 14 Sep 2006 15:53:55 -0700 From: rfc-editor at rfc-editor.org To: ietf-announce at ietf.org, rfc-dist at rfc-editor.org CC: rfc-editor at rfc-editor.org, dnsop at lists.uoregon.edu A new Request for Comments is now available in online RFC libraries. RFC 4641 Title: DNSSEC Operational Practices Author: O. Kolkman, R. Gieben Status: Standards Track Date: September 2006 Mailbox: olaf at nlnetlabs.nl, miek at miek.nl Pages: 35 Characters: 79894 Obsoletes: RFC2541 See-Also: I-D Tag: draft-ietf-dnsop-dnssec-operational-practices-08.txt URL: http://www.rfc-editor.org/rfc/rfc4641.txt This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC. The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies. This document obsoletes RFC 2541, as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the new DNSSEC specification. This memo provides information for the Internet community. This document is a product of the Domain Name System Operations Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: 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 at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at 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 at 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 at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature Url : http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20060915/ccfa17c0/attachment.bin From paf at cisco.com Fri Sep 15 01:14:01 2006 From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Fri, 15 Sep 2006 07:14:01 +0200 Subject: Microsoft and DNSSEC? Message-ID: Is there any support for DNSSEC validation (client/resolver side) in Microsoft software anywhere? Patrik From lutz at iks-jena.de Fri Sep 15 04:59:28 2006 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Fri, 15 Sep 2006 08:59:28 +0000 (UTC) Subject: [dnssec-deployment] Microsoft and DNSSEC? References: Message-ID: * Patrik F?ltstr?m wrote: > Is there any support for DNSSEC validation (client/resolver side) in > Microsoft software anywhere? Yes, but only for the outdated standards. It's unusable. From jeroen at unfix.org Fri Sep 15 05:31:14 2006 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 15 Sep 2006 11:31:14 +0200 Subject: Firefox: Auto-update compromise through DNS and SSL spoofing (1.5.0.7, is out) Message-ID: <450A72E2.5000801@unfix.org> Hmm, Maybe somebody should get in touch with the Firefox/Mozilla team and help them deploy DNSSEC for their domains, as that would avoid the below issue. Though most ignorant (that is the right political word is it? ;) users are on Windows, and as we just noticed there are no current DNSSEC implementations around. It would also still require lots of people to enable DNSSEC in their resolvers. NLNetLabs has a Drill extension for Firefox (http://www.nlnetlabs.nl/dnssec/drill_extension.html) but that is only available for *nix also. Might be a good thing to have a Windows edition of the ldns library? Greets, Jeroen http://www.mozilla.org/security/announce/2006/mfsa2006-58.html --- The Firefox and Thunderbird auto-update mechanism protects itself against DNS spoofing using SSL; only a site presenting a valid certificate for aus2.mozilla.org will be trusted as a source of update information. Jon Oberheide points out, however, that many users accept unverifiable self-signed certificates without much thought on "low value" sites, and this could be used as the basis of an attack on the update system. The attacker would have to be in a position to spoof the victim's DNS, causing them to connect to sites of the attacker's choosing rather than the sites intended by the victim. If they gained that control and the victim accepted the attacker's cert for the Mozilla update site, then the next update check could be hijacked and redirected to the attacker's site without detection. The attacker could then send an "update" that consisted of whatever programs they wished. --- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature Url : http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20060915/17fd6460/attachment.bin From roy at dnss.ec Fri Sep 15 05:36:49 2006 From: roy at dnss.ec (Roy Arends) Date: Fri, 15 Sep 2006 11:36:49 +0200 Subject: [dnssec-deployment] Firefox: Auto-update compromise through DNS and SSL spoofing (1.5.0.7, is out) In-Reply-To: References: Message-ID: On Sep 15, 2006, at 11:31 AM, Jeroen Massar wrote: > Hmm, > > Maybe somebody should get in touch with the Firefox/Mozilla team > and help them deploy DNSSEC for their domains, as that would avoid > the below issue. Though most ignorant (that is the right political > word is it? ;) users are on Windows, and as we just noticed there > are no current DNSSEC implementations around. It would also still > require lots of people to enable DNSSEC in their resolvers. > > NLNetLabs has a Drill extension for Firefox (http:// > www.nlnetlabs.nl/dnssec/drill_extension.html) but that is only > available for *nix also. Might be a good thing to have a Windows > edition of the ldns library? There is also http://www.dnssec-tools.org/ Not sure about windows environments. Roy From sra at isc.org Fri Sep 15 15:34:57 2006 From: sra at isc.org (Rob Austein) Date: Fri, 15 Sep 2006 15:34:57 -0400 Subject: [dnssec-deployment] Microsoft and DNSSEC? In-Reply-To: References: Message-ID: <20060915193457.E92755C53@thrintun.hactrn.net> At Fri, 15 Sep 2006 07:14:01 +0200, Patrik F?ltstr?m wrote: > > Is there any support for DNSSEC validation (client/resolver side) in > Microsoft software anywhere? Other than BIND9 running on Windows, you mean? :) From paf at cisco.com Sun Sep 17 16:31:31 2006 From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Sun, 17 Sep 2006 22:31:31 +0200 Subject: [dnssec-deployment] Microsoft and DNSSEC? In-Reply-To: <20060915193457.E92755C53@thrintun.hactrn.net> References: <20060915193457.E92755C53@thrintun.hactrn.net> Message-ID: On 15 sep 2006, at 21.34, Rob Austein wrote: > At Fri, 15 Sep 2006 07:14:01 +0200, Patrik F?ltstr?m wrote: >> >> Is there any support for DNSSEC validation (client/resolver side) in >> Microsoft software anywhere? > > Other than BIND9 running on Windows, you mean? :) Am I *really* supposed to comment on this? paf From sanz at denic.de Mon Sep 18 04:15:52 2006 From: sanz at denic.de (Marcos Sanz/Denic) Date: Mon, 18 Sep 2006 10:15:52 +0200 Subject: [dnssec-deployment] what to hand your parent In-Reply-To: Message-ID: Bill, > > DNSKEY advantages: [...] > > + It has more information than a DS, e.g. whether you are dealing with a > > SEP or not. > > well... the 256/257 debate is still one of operational expediency. > any DNSKEy -can- be used for a SEP... the "KSK/ZSK" split is not > mandatory... right? More precisely formulated: If you have a DNSKEY with a SEP bit flag set, you are most probably dealing with a KSK. This is, still, some information. > > The "security freedom" argument for DNSKEY is very convincing. > > just as convincing as the parent having "security freedom" to > change the NS rrset of the child to suit her own percieved needs. How do you mean that? I hope you can see a difference between the parent changing the NS records to point *somewhere else* and the parent changing the DS record but still pointing to the *same* DNSKEY. > > If the TTL for the record were to be needed at the parent, it could always > > be transmited as a sepparate parameter (like for instance EPP does). > > i was actually thinking of the fact that the TTL is incalculated in > the generation of the DNSKEY - not sure if that has any relevence > to the DS hash... No relevance. The DS hash is a digest of the DNSKEY owner concatenated to the DNSKEY rdata. Best, Marcos From olaf at NLnetLabs.nl Mon Sep 18 05:02:10 2006 From: olaf at NLnetLabs.nl (Olaf M. Kolkman) Date: Mon, 18 Sep 2006 11:02:10 +0200 Subject: [dnssec-deployment] what to hand your parent In-Reply-To: References: Message-ID: <40B6B085-0BDF-4E7C-A157-CA712515AFDF@NLnetLabs.nl> On 18Sep 2006, at 10:15 AM, Marcos Sanz/Denic wrote: >> well... the 256/257 debate is still one of operational expediency. >> any DNSKEy -can- be used for a SEP... the "KSK/ZSK" split is not >> mandatory... right? > > More precisely formulated: If you have a DNSKEY with a SEP bit flag > set, > you are most probably dealing with a KSK. This is, still, some > information. And the SEP flag _can_ be mandated by the parent in order e.g. to facilitate automatic key-exchanges with the parent. (For example: The RIPE NCC web interface mandates a SEP flag in order to do some selection. People can work around that but then they have to use the mail interface and do manual creation of their forms/ objects). --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ From jakob at rfc.se Mon Sep 18 06:38:54 2006 From: jakob at rfc.se (Jakob Schlyter) Date: Mon, 18 Sep 2006 12:38:54 +0200 Subject: [dnssec-deployment] what to hand your parent In-Reply-To: References: Message-ID: <31A4AEE2-2D43-4CA7-852F-BFDF63F82439@rfc.se> On 18 sep 2006, at 11.02, Olaf M. Kolkman wrote: > And the SEP flag _can_ be mandated by the parent in order e.g. to > facilitate automatic key-exchanges with the parent. what does people think about this? is it resonable that a registrar forces domains to use a KSK/ZSK scheme? if a child has both KSK and ZSK keys, we warn the child that selecting a ZSK as SEP is probably a bad idea. jakob From sra at isc.org Mon Sep 18 09:10:28 2006 From: sra at isc.org (Rob Austein) Date: Mon, 18 Sep 2006 09:10:28 -0400 Subject: [dnssec-deployment] what to hand your parent In-Reply-To: References: Message-ID: <20060918131028.CE11E5C1B@thrintun.hactrn.net> At Mon, 18 Sep 2006 12:38:54 +0200, Jakob Schlyter wrote: > > On 18 sep 2006, at 11.02, Olaf M. Kolkman wrote: > > > And the SEP flag _can_ be mandated by the parent in order e.g. to > > facilitate automatic key-exchanges with the parent. > > what does people think about this? is it resonable that a registrar > forces domains to use a KSK/ZSK scheme? Seems harmless. A child who really wants to use a single key can always mark that key as a SEP. This is one of the reasons why the validation algorithm doesn't look at the SEP flag. From paul at vix.com Mon Sep 18 10:11:07 2006 From: paul at vix.com (Paul Vixie) Date: Mon, 18 Sep 2006 14:11:07 +0000 Subject: [dnssec-deployment] what to hand your parent In-Reply-To: Your message of "Mon, 18 Sep 2006 12:38:54 +0200." References: Message-ID: <58165.1158588667@sa.vix.com> > > And the SEP flag _can_ be mandated by the parent in order e.g. to > > facilitate automatic key-exchanges with the parent. > > what does people think about this? is it resonable that a registrar forces > domains to use a KSK/ZSK scheme? yes. > if a child has both KSK and ZSK keys, we warn the child that selecting a > ZSK as SEP is probably a bad idea. that's not, imo, strong enough. From brettcarr at ripe.net Tue Sep 19 04:35:00 2006 From: brettcarr at ripe.net (Brett Carr) Date: Tue, 19 Sep 2006 10:35:00 +0200 Subject: [dnssec-deployment] Microsoft and DNSSEC? In-Reply-To: References: Message-ID: <005c01c6dbc6$7ed5dbb0$7c819310$@net> > -----Original Message----- > From: DNSSEC deployment [mailto:dnssec-deployment at shinkuro.com] On > Behalf Of Patrik F?ltstr?m > Sent: Friday, September 15, 2006 7:14 AM > To: DNSSEC deployment > Subject: [dnssec-deployment] Microsoft and DNSSEC? > > Is there any support for DNSSEC validation (client/resolver side) in > Microsoft software anywhere? > > Patrik No there isn't I did speak to somebody fairly senior at Microsoft about this last year but all I could get out of them was that they were looking into it. I have had a quick look at Vista and Longhorn server but can't see any references to dnssec in there, maybe in service pack 1 :) Brett -- Brett Carr RIPE Network Coordination Centre Systems Engineer -- Operations Group Amsterdam, Netherlands GPG Key fingerprint = F20D B2A7 C91D E370 44CF F244 B6A1 EF48 E743 F7D8 From jakob at rfc.se Wed Sep 20 02:45:18 2006 From: jakob at rfc.se (Jakob Schlyter) Date: Wed, 20 Sep 2006 08:45:18 +0200 Subject: [dnssec-deployment] what to hand your parent In-Reply-To: References: Message-ID: what about other constraints? for the .SE keyman interface, we have the following requirements for keys that will be published using DS: - a key MUST be a zone key (RFC4034 section 2.1.1) - a key MUST have protocol == 3 (RFC4034 section 2.1.2) - a key MUST NOT use a reserved algorithm (RFC4034 section 2.1.3, i.e. 0 & 255 are not possible) - a key MUST be marked as a Secure Entry Point (RFC4034 section 2.1.1 and RFC 3757) - at least one key in the keyset SHOULD use algorithm RSA/SHA1 - a key SHOULD NOT use algorithm RSA/MD5 - a key SHOULD NOT use an unknown algorithm - a key SHOULD NOT have bit 0-6 or bit 8-14 of the flag field set does the list think these are resonable requirements? jakob From weiler+lists.dnssec-deploy at watson.org Wed Sep 20 02:52:54 2006 From: weiler+lists.dnssec-deploy at watson.org (Sam Weiler) Date: Tue, 19 Sep 2006 23:52:54 -0700 (PDT) Subject: [dnssec-deployment] what to hand your parent In-Reply-To: References: Message-ID: <20060919234948.B42055@fledge.watson.org> On Wed, 20 Sep 2006, Jakob Schlyter wrote: > what about other constraints? > > for the .SE keyman interface, we have the following requirements for keys > that will be published using DS: > > - a key MUST be a zone key (RFC4034 section 2.1.1) > - a key MUST have protocol == 3 (RFC4034 section 2.1.2) > - a key MUST NOT use a reserved algorithm (RFC4034 section 2.1.3, i.e. 0 & > 255 are not possible) > - a key MUST be marked as a Secure Entry Point (RFC4034 section 2.1.1 and RFC > 3757) > > - at least one key in the keyset SHOULD use algorithm RSA/SHA1 > - a key SHOULD NOT use algorithm RSA/MD5 > - a key SHOULD NOT use an unknown algorithm > - a key SHOULD NOT have bit 0-6 or bit 8-14 of the flag field set > > does the list think these are resonable requirements? All except for the "MUST be marked as a Secure Entry Point" item, yes. The SEP flag is advisory and a registry should not be checking it. Strict enforcement of these SHOULDs and SHOULD NOTs would be bad, but I'm assuming that the SHOULDs generate only soft failures that are easy to work around, yes? -- Sam From olaf at NLnetLabs.nl Wed Sep 20 03:56:16 2006 From: olaf at NLnetLabs.nl (Olaf M. Kolkman) Date: Wed, 20 Sep 2006 09:56:16 +0200 Subject: [dnssec-deployment] what to hand your parent In-Reply-To: References: Message-ID: <03359F0E-331A-4F16-A50A-33BFE6DA8B14@NLnetLabs.nl> On 20Sep 2006, at 8:52 AM, Sam Weiler wrote: > On Wed, 20 Sep 2006, Jakob Schlyter wrote: > >> what about other constraints? >> >> for the .SE keyman interface, we have the following requirements >> for keys that will be published using DS: >> >> - a key MUST be a zone key (RFC4034 section 2.1.1) >> - a key MUST have protocol == 3 (RFC4034 section 2.1.2) >> - a key MUST NOT use a reserved algorithm (RFC4034 section 2.1.3, >> i.e. 0 & 255 are not possible) >> - a key MUST be marked as a Secure Entry Point (RFC4034 section >> 2.1.1 and RFC 3757) >> >> - at least one key in the keyset SHOULD use algorithm RSA/SHA1 >> - a key SHOULD NOT use algorithm RSA/MD5 >> - a key SHOULD NOT use an unknown algorithm >> - a key SHOULD NOT have bit 0-6 or bit 8-14 of the flag field set >> >> does the list think these are resonable requirements? > > All except for the "MUST be marked as a Secure Entry Point" item, > yes. The SEP flag is advisory and a registry should not be checking > it. Why wouldn't a registry policy be allowed to require something that is useful in order to work more efficiently? One of the main use cases of the SEP key is to ease interaction between parent and child. I think this is a perfectly valid set of operational requirements. What would be bad is if registries would not have the option to not use that requirement. (oops double negations... let me rephrase) It would be bad if registries would be required to implement systems where "a key MUST be marked as a Secure Entry Point (RFC4034 section 2.1.1 and RFC 3757)". But that is not the case. At the RIPE NCC a number of tests have been implemented; the error codes and explanations can be found on the webpage that links from the delegation checker page. The descriptions are at the bottom. http://www.ripe.net/rs/reverse/delcheck/ delcheck_descr.html#PROBLEM_NOT_ALL_SERVERS_RETURN_DNSSECDATA There are a few requirements with "score 20" that are not on Jacobs list. (Score 20 means that the delegation will not be accepted and maps to "MUST") - All nameservers MUST respond with DNSSEC information. - The SEP key (to which the DS would be pointing) needs to sign the keyset - The digest must match the key information (obviously) - There MUST be a valid chain of trust from the DS to the SOA RR in the zone Also note that this delegation checker works for any zone (even though it seems that you are requesting a delegation from RIPE NCC). --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ From steve at shinkuro.com Wed Sep 20 08:30:31 2006 From: steve at shinkuro.com (Steve Crocker) Date: Wed, 20 Sep 2006 08:30:31 -0400 Subject: [dnssec-deployment] what to hand your parent In-Reply-To: References: Message-ID: <55352E9E-4715-4FF5-B563-8B6DB6AC33F4@shinkuro.com> Where do we stand on transition to hash algorithms stronger than SHA1? I am hearing pressure to move beyond SHA1. Steve Steve Crocker steve at shinkuro.com Try Shinkuro's collaboration technology. Visit www.shinkuro.com. I am steve!shinkuro.com. On Sep 20, 2006, at 2:45 AM, Jakob Schlyter wrote: > what about other constraints? > > for the .SE keyman interface, we have the following requirements > for keys that will be published using DS: > > - a key MUST be a zone key (RFC4034 section 2.1.1) > - a key MUST have protocol == 3 (RFC4034 section 2.1.2) > - a key MUST NOT use a reserved algorithm (RFC4034 section 2.1.3, > i.e. 0 & 255 are not possible) > - a key MUST be marked as a Secure Entry Point (RFC4034 section > 2.1.1 and RFC 3757) > > - at least one key in the keyset SHOULD use algorithm RSA/SHA1 > - a key SHOULD NOT use algorithm RSA/MD5 > - a key SHOULD NOT use an unknown algorithm > - a key SHOULD NOT have bit 0-6 or bit 8-14 of the flag field set > > does the list think these are resonable requirements? > > jakob > > > ############################################################# > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > A public archive is available here: Lists/dnssec-deployment/> > and older material is at > From jakob at rfc.se Wed Sep 20 08:36:48 2006 From: jakob at rfc.se (Jakob Schlyter) Date: Wed, 20 Sep 2006 14:36:48 +0200 Subject: [dnssec-deployment] what to hand your parent In-Reply-To: References: Message-ID: <7D57F411-3C0D-4BD8-A4A1-38D1C62A267E@rfc.se> On 20 sep 2006, at 14.30, Steve Crocker wrote: > Where do we stand on transition to hash algorithms stronger than > SHA1? I am hearing pressure to move beyond SHA1. if your referring to the hash of the DS, .se publishes DS records with both SHA-1 and SHA-256. for DNSKEYs with RSA/SHA256, perhaps Jelte can fill us in on draft- ietf-dnsext-dnssec-rsasha256-01.txt. jakob From ogud at ogud.com Wed Sep 20 11:02:03 2006 From: ogud at ogud.com (=?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?=) Date: Wed, 20 Sep 2006 11:02:03 -0400 Subject: [dnssec-deployment] what to hand your parent In-Reply-To: References: Message-ID: <7.0.1.0.2.20060920093232.03d16a38@ogud.com> The DNSEXT working group has standardized DS with RSA256, and multiple implementations support it already. The WG decided to defer the specification of RSA + until later day when there is more guidance on which HASH to use. Because the DS is long lived, it was the most vulnerable point in DNSSEC. RRSIG's are "short" lived thus they are not as vulnerable. Furthermore due to the structured format of the data signed there is limited ability for attackers to put the data of their choice along with the random data required to forge data to yield signature that matches valid signature. RRSIG's are more resilient than the underlying HASH algorithm. Olafur At 08:30 20/09/2006, Steve Crocker wrote: >Where do we stand on transition to hash algorithms stronger than >SHA1? I am hearing pressure to move beyond SHA1. > >Steve > > >Steve Crocker >steve at shinkuro.com > >Try Shinkuro's collaboration technology. Visit www.shinkuro.com. I >am steve!shinkuro.com. > > >On Sep 20, 2006, at 2:45 AM, Jakob Schlyter wrote: > >>what about other constraints? >> >>for the .SE keyman interface, we have the following requirements >>for keys that will be published using DS: >> >>- a key MUST be a zone key (RFC4034 section 2.1.1) >>- a key MUST have protocol == 3 (RFC4034 section 2.1.2) >>- a key MUST NOT use a reserved algorithm (RFC4034 section 2.1.3, >>i.e. 0 & 255 are not possible) >>- a key MUST be marked as a Secure Entry Point (RFC4034 section >>2.1.1 and RFC 3757) >> >>- at least one key in the keyset SHOULD use algorithm RSA/SHA1 >>- a key SHOULD NOT use algorithm RSA/MD5 >>- a key SHOULD NOT use an unknown algorithm >>- a key SHOULD NOT have bit 0-6 or bit 8-14 of the flag field set >> >>does the list think these are resonable requirements? >> >> jakob >> >> >>############################################################# >>This message is sent to you because you are subscribed to >> the mailing list . >>To unsubscribe, E-mail to: >>A public archive is available here: >Lists/dnssec-deployment/> >>and older material is at >> > > >############################################################# >This message is sent to you because you are subscribed to > the mailing list . >To unsubscribe, E-mail to: >A public archive is available here: > >and older material is at > From srose at verisign.com Thu Sep 28 09:56:15 2006 From: srose at verisign.com (Rose, Scott) Date: Thu, 28 Sep 2006 09:56:15 -0400 Subject: NSEC3 workshop report and announcement Message-ID: <57989D9F107A7D4A84FACE7077EF7DFF3F11EC@DUL1WNEXMB06.vcorp.ad.vrsn.com> (apologies for those that get multiple copies of this message) The 2nd NSEC3 workshop was held Sept 18-20, at Verisign's offices in Dulles, VA. The draft report of the workshop can be found at: http://www.nsec3.org/cgi-bin/trac.cgi/wiki/WorkshopReport To summarize, the attendees considered the workshop a success, and many of the issues regarding the NSEC3 extension were settled. There are some new issues raise at the workshop, and summaries of those issues on the DNSEXT WG mailing list soon. Scott ----- Scott Rose srose at verisign.com Engineer, Verisign Info Services, APRG ph: +1 703-948-3364 -----