From olaf at ripe.net Tue Jul 5 17:56:35 2005 From: olaf at ripe.net (Olaf M. Kolkman) Date: Tue, 5 Jul 2005 17:56:35 +0200 Subject: [dns-wg] DNSSEC deployment on the reverse tree. Message-ID: <20050705175635.18000789.olaf@ripe.net> [Apologies for duplicates] Dear Colleagues The RIPE NCC has been involved with the development of the DNSSEC protocol. Now that the protocol has become available, we plan to implement DNSSEC on our domains in the reverse DNS tree. The deployment of DNSSEC is the second and last phase of the Reverse DNS restructuring project. You can find more information about this project at: http://www.ripe.net/rs/reverse/dnssec/index.html To implement DNSSEC, we propose extending the policy for Policy for Reverse Address Delegation of IPv4 and IPv6 Address Space in the RIPE NCC Service Region. You can find the proposed policy at: http://www.ripe.net/rs/reverse/dnssec/draft-dnssec-policy.html. We welcome your feedback on this poposal before 1 August 2005. Please send your comments to the DNS Working Group Mailing List. We are also introducing two new procedures: "DNSSEC Key Maintenance Procedure" http://www.ripe.net/rs/reverse/dnssec/key-maintenance-procedure.html and "Procedure for Requesting DNSSEC Delegations" http://www.ripe.net/rs/reverse/dnssec/registry-procedure.html Your feedback on these drafts is also welcome, again please send this to the DNS Working Group Mailing List. As part of the "Procedure for Requesting DNSSEC Delegations" we plan to add a "ds-rdata:" attribute to DOMAIN objects. Regards Olaf M Kolkman New Projects, RIPE NCC. From randy at psg.com Wed Jul 6 03:28:50 2005 From: randy at psg.com (Randy Bush) Date: Tue, 5 Jul 2005 15:28:50 -1000 Subject: [dns-wg] Re: [db-wg] DNSSEC deployment on the reverse tree. References: <20050705175635.18000789.olaf@ripe.net> Message-ID: <17099.13266.104893.536098@roam.psg.com> hi olaf, for us simple-minded folk who do not track dnssec details, could you tell us what trusted key(s) we will have to load to securely verify the signed zones? and is there an idiot's howto? randy From weiler at watson.org Wed Jul 6 05:13:59 2005 From: weiler at watson.org (Sam Weiler) Date: Tue, 5 Jul 2005 20:13:59 -0700 (PDT) Subject: [dns-wg] DNSSEC deployment on the reverse tree. In-Reply-To: <20050705175635.18000789.olaf@ripe.net> References: <20050705175635.18000789.olaf@ripe.net> Message-ID: <20050705194405.D55912@fledge.watson.org> I'm delighted to see that the NCC has set an aggressive schedule for DNSSEC deployment. Here are some comments on the draft procedures, as requested: > "DNSSEC Key Maintenance Procedure" > http://www.ripe.net/rs/reverse/dnssec/key-maintenance-procedure.html At a first pass, this document looks very good. > "Procedure for Requesting DNSSEC Delegations" > http://www.ripe.net/rs/reverse/dnssec/registry-procedure.html Many things in this look good (not rejecting keys without the SEP bit set, dealing with unsupported message digests, allowing multiple DS records), but I have a few concerns. First, do you need to specify the encoding of the ds-rdata attribute in more detail? I'm worried about the first two rules in the "Delegation Checks" portion of this procedure. Assuming a working delegation chain is in place for each algorithm present in the DS set, it is really necessary to have each of the DNSKEYs present in the zone (the first rule)? I suggest instead: -- For each algorithm present in the set of ds-rdata attributes, is there a matching DNSKEY available in the DNS for at least one of the ds-rdata attributes with that algorithm? (Apologies for the poor word-smithing.) Also, the second test (valid RRSIG, presumably on the DNSKEY RRset) is only possible for supported crypto algorithms. Private algorithms may confound this rule. I suggest: -- "For each of the supported algorithms (3 and 5) present in the set of ds-rdata attributes, is there a valid RRSIG on the DNSKEY RRset made with a DNSKEY that both matches the ds-rdata attribute and is published in the DNS?" or -- "For each of the DNSKEYs identified by rule #1, is there at least one valid RRSIG on the DNSKEY RRset made with a DNSKEY of each algorithm?" And in the text below, say "Tests #2 and #4 will only be performed for supported algorithms". (Again, I suggest 3 and 5). Lastly, I don't understand this description of the web interface: "It will use the "ds-rdata:" attribute of the domain object currently available in the RIPE Whois Database to select the appropriate default DNSKEY RR. It will then select a new "ds-rdata:" attribute." Does this mean that the current ds-rdata will always be replaced? -- Sam From olaf at ripe.net Wed Jul 6 09:44:04 2005 From: olaf at ripe.net (Olaf M. Kolkman) Date: Wed, 6 Jul 2005 09:44:04 +0200 Subject: [dns-wg] Re: [db-wg] DNSSEC deployment on the reverse tree. In-Reply-To: <17099.13266.104893.536098@roam.psg.com> References: <20050705175635.18000789.olaf@ripe.net> <17099.13266.104893.536098@roam.psg.com> Message-ID: <20050706094404.2b4e4bfa.olaf@ripe.net> On Tue, 5 Jul 2005 15:28:50 -1000 Randy Bush wrote: > hi olaf, > > for us simple-minded folk who do not track dnssec details, could > you tell us what trusted key(s) we will have to load to securely > verify the signed zones? and is there an idiot's howto? > Hello Randy, [Moved the discussion to dns-wg only, apologies for not setting the reply-to header] In the absence of a signed parent domain the trusted-keys will be made available through a secured web page. The keys will only be made available after we start signing the zone in production. Also see the last part of: http://www.ripe.net/rs/reverse/dnssec/key-maintenance-procedure.html For a howto on to configure a validating server see: http://www.ripe.net/projects/disi/dnssec_howto/ or: http://www.ripe.net/projects/disi/dnssec_howto/dnssec_howto.pdf I hope this answers your question. -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC From olaf at ripe.net Wed Jul 6 10:24:42 2005 From: olaf at ripe.net (Olaf M. Kolkman) Date: Wed, 6 Jul 2005 10:24:42 +0200 Subject: [dns-wg] DNSSEC deployment on the reverse tree. In-Reply-To: <20050705194405.D55912@fledge.watson.org> References: <20050705175635.18000789.olaf@ripe.net> <20050705194405.D55912@fledge.watson.org> Message-ID: <20050706102442.7d941a1e.olaf@ripe.net> Hello Sam, Thanks for the quick review. > (...) > Many things in this look good (not rejecting keys without the SEP bit > set, dealing with unsupported message digests, allowing multiple DS > records), but I have a few concerns. > > First, do you need to specify the encoding of the ds-rdata attribute > in more detail? This text is in the "Procedure for Requesting DNSSEC Delegations" The "ds-rdata:" attribute contains the RDATA of the DS Resource Records related to the domain (as shown in the "domain:" attribute). ds-rdata: 64431 5 1 278BF194C29A812B33935BB2517E17D1486210FA Is it ambiguous? > > I'm worried about the first two rules in the "Delegation Checks" > portion of this procedure. Assuming a working delegation chain is in > place for each algorithm present in the DS set, it is really necessary > to have each of the DNSKEYs present in the zone (the first rule)? I > suggest instead: > -- For each algorithm present in the set of ds-rdata attributes, is > there a matching DNSKEY available in the DNS for at least one of > the ds-rdata attributes with that algorithm? (Apologies for the > poor word-smithing.) > The reason for this somewhat strong requirement is to prevent "DS lameness", just like you do not want delegation NS records pointing off to no-no-land you do not want to have DS records point to DNSKEYS that do not exist in the DNS. Although I could not quickly find a strong MUST for this requirement in RFC 4033-4035 I think it is good operational practice and will prevent many possible troubleshooting hours. (explaining the jargon: "security lameness" is a term from draft-ietf-dnsop-dnssec-operational-practices-04). > Also, the second test (valid RRSIG, presumably on the DNSKEY RRset) is > only possible for supported crypto algorithms. Private algorithms may > confound this rule. I suggest: > -- "For each of the supported algorithms (3 and 5) present in the > set of ds-rdata attributes, is there a valid RRSIG on the > DNSKEY RRset made with a DNSKEY that both matches the ds-rdata > attribute and is published in the DNS?" or > -- "For each of the DNSKEYs identified by rule #1, is there at > least one valid RRSIG on the DNSKEY RRset made with a DNSKEY of > each algorithm?" And in the text below, say "Tests #2 and #4 > will only be performed for supported algorithms". (Again, I > suggest 3 and 5). After we fixed these text a week or so ago we have been working on the more detailed specifications of the checks. We follow your above suggestion. That is, we provide a warning if we cannot validate the signatures because of the algorithm not being implemented (1,3 and 5). We provide information if the algorithm is not implemented. But we do plan to enforce a valid DS->DNSKEY->RRSIG(DNSKEY) chain. I think that a broken DS->DNSKEY->RRSIG(DNSKEY) chain is a recipee for operational trouble and is in 99.9% unintended. If operators really want to enter this dark spots in the corner case universe we can accommodate them and if it turns out that operators make this common practice than we can always relax the test. I should note that these delegations checks intended to prevent misconfigurations that can lead to hours of troubleshooting at the "client" end. The tests designed for DNSSEC are I think reasonable armour against shooting oneself in the foot. (When misconfiguring DNS you used to hurt your toe, when making mistakes with DNSSEC its amputation time). > Lastly, I don't understand this description of the web interface: "It > will use the "ds-rdata:" attribute of the domain object currently > available in the RIPE Whois Database to select the appropriate default > DNSKEY RR. It will then select a new "ds-rdata:" attribute." Does > this mean that the current ds-rdata will always be replaced? The idea that the web-interface provides an aid to construct the Domain object. It takes sensible defaults. If somebody proceeds in a roll over the assumption is that the DS currently at the parent is replaced by a new one. You look at the keys in the zone with the SEP bit set. In the common case there will be two of those during a roll over, you pick the one not currently published by the parent as the new one. -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC From randy at psg.com Wed Jul 6 17:17:28 2005 From: randy at psg.com (Randy Bush) Date: Wed, 6 Jul 2005 05:17:28 -1000 Subject: [dns-wg] Re: [db-wg] DNSSEC deployment on the reverse tree. References: <20050705175635.18000789.olaf@ripe.net> <17099.13266.104893.536098@roam.psg.com> <20050706094404.2b4e4bfa.olaf@ripe.net> Message-ID: <17099.62984.250518.155161@roam.psg.com> > In the absence of a signed parent domain the trusted-keys will be made > available through a secured web page. The keys will only be made available > after we start signing the zone in production. > > Also see the last part of: > http://www.ripe.net/rs/reverse/dnssec/key-maintenance-procedure.html sigh. and the rirs can not get together and do a ksk system for in-addr.arpa? randy From olaf at ripe.net Thu Jul 7 11:59:36 2005 From: olaf at ripe.net (Olaf M. Kolkman) Date: Thu, 7 Jul 2005 11:59:36 +0200 Subject: [dns-wg] Re: [db-wg] DNSSEC deployment on the reverse tree. In-Reply-To: <17099.62984.250518.155161@roam.psg.com> References: <20050705175635.18000789.olaf@ripe.net> <17099.13266.104893.536098@roam.psg.com> <20050706094404.2b4e4bfa.olaf@ripe.net> <17099.62984.250518.155161@roam.psg.com> Message-ID: <20050707115936.5b2e5d0c.olaf@ripe.net> On Wed, 6 Jul 2005 05:17:28 -1000 Randy Bush wrote: > > In the absence of a signed parent domain the trusted-keys will be made > > available through a secured web page. The keys will only be made available > > after we start signing the zone in production. > > > > Also see the last part of: > > http://www.ripe.net/rs/reverse/dnssec/key-maintenance-procedure.html > > sigh. and the rirs can not get together and do a ksk system for > in-addr.arpa? > Randy, Positive experiences gained during the rollout by the RIPE NCC will no-doubt be of influence on the timeframe on which we'll see DNSSEC deployed on the in-addr.arpa domain. --Olaf (quickly turning into a politician :-) ) From jim at rfc1035.com Fri Jul 8 16:16:30 2005 From: jim at rfc1035.com (Jim Reid) Date: Fri, 8 Jul 2005 15:16:30 +0100 Subject: [dns-wg] Policy development process for deployment of Secure DNS Message-ID: <71bc53d225999724480751780d3b8e41@rfc1035.com> This announcement is required as part of the policy development process described in: http://www.ripe.net/ripe/draft-documents/pdp.html Olaf Kolkman sent a policy proposal to the DNS-WG list on Tuesday, July 5th. On behalf of the DNS WG co-chairs, I would like to invite your comments on this proposal. This invitation formally opens the policy discussion phase that is to end no sooner than 4 weeks from today: ie August 5th, 2005. The policy proposal is posted at: http://www.ripe.net/rs/reverse/dnssec/draft-dnssec-policy.html. Discussion takes place on the dns-wg at ripe.net list. I would also like to use this policy proposal to get the WG to formally endorse the NCC's efforts on DNSSEC deployment. To the best of my knowledge the WG has never requested that the NCC undertake any DNSSEC activities. [Of course the DISI project has been voted on in the annual Activity Plan for a couple of years now.] So I suppose as we go forward, this is as good a time as any for the WG to formalise this work. <\wg chair hat on> From john at sackheads.org Fri Jul 29 18:08:06 2005 From: john at sackheads.org (John Payne) Date: Fri, 29 Jul 2005 12:08:06 -0400 Subject: [dns-wg] Delegation checker Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have had a long running issue with the delegation checker. I appreciate that I may be unique, but having to get the database manager to help out with (infrequent, admittedly) exception handling is irritating to say the least. The problem is with the PROBLEM_WRONG_REVERSE_MAPPING check. Background. I work for a company that has a very large "non-network". We have lots of islands of infrastructure mainly not on "our" IP space, but provider PA space where we don't control the rDNS (I'm not saying we couldn't, but we only run into issues with RIPE - so the pay off doesn't seem to be worth the effort). The PROBLEM_WRONG_REVERSE_MAPPING is assigning 4 points for each nameserver missing "correct" rDNS. With 8 nameservers, that's 12 points more than failure. Now, I could work around this by only submitting 4 nameservers, but that seems contrary to the goal of having a stable in-addr.arpa delegation. The description for PROBLEM_WRONG_REVERSE_MAPPING refers to RFC1912, section 2.1 which says "should", not "must", so such a high penalty for no technical problem does not seem valid. I can't think of a truely operational problem caused by missing rDNS on an auth nameserver. I would like to propose either changing this to a 0 point Information, or a 1 point Warning. Thanks for listening John (BTW, PROBLEM_MAILCHECK_CONNECTION_FAILED also doesn't seem to be doing an MX lookup before attempting a connection. The A record for $company.com does not point to a mailserver which is why RIPE gets connection refused... but the MX records are correctly set up). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFC6lRr3TsPuH6oTJ8RAiXnAKDbgkGdV6+OIQ2FP/wvKsZWcSNF8gCghScv Ry07wV96ZJT7Ty/DGa10pjk= =IRKq -----END PGP SIGNATURE----- From pk at DENIC.DE Fri Jul 29 19:29:22 2005 From: pk at DENIC.DE (Peter Koch) Date: Fri, 29 Jul 2005 19:29:22 +0200 Subject: [dns-wg] Delegation checker In-Reply-To: References: Message-ID: <20050729172922.GK23617@denics7.denic.de> John, > The PROBLEM_WRONG_REVERSE_MAPPING is assigning 4 points for each > nameserver missing "correct" rDNS. With 8 nameservers, that's 12 just to be clear: "wrong" means inconsistent reverse mapping, not a missing one. While reverse mapping may be absent, inconsistencies are almost always a sign of a problem. The reverse mapping is not required for the resolution processs but is helpful (and in the case of inconsistencies: less helpful) for debugging. > points more than failure. Now, I could work around this by only > submitting 4 nameservers, but that seems contrary to the goal of having > a stable in-addr.arpa delegation. I wonder why you're having so many name servers all suffering from the same problem. Maybe they're administratively *and* topologically close? Could you give details, please? > The description for PROBLEM_WRONG_REVERSE_MAPPING refers to RFC1912, > section 2.1 which says "should", not "must", so such a high penalty > for no technical problem does not seem valid. I can't think of a > truely operational problem caused by missing rDNS on an auth > nameserver. RFC 1912 predates RFC 2119, so this 'should' vs 'must' deliberations must(sic!) be taken with a grain of salt. > I would like to propose either changing this to a 0 point Information, > or a 1 point Warning. One could also argue that the same warning produced by several servers should be limited in its impact, but OTOH this accumulation of warnings, even of the same type, suggests a deeper inspection is due. -Peter From john at sackheads.org Fri Jul 29 21:11:48 2005 From: john at sackheads.org (John Payne) Date: Fri, 29 Jul 2005 15:11:48 -0400 Subject: [dns-wg] Delegation checker In-Reply-To: <20050729172922.GK23617@denics7.denic.de> References: <20050729172922.GK23617@denics7.denic.de> Message-ID: On Jul 29, 2005, at 1:29 PM, Peter Koch wrote: > John, > >> The PROBLEM_WRONG_REVERSE_MAPPING is assigning 4 points for each >> nameserver missing "correct" rDNS. With 8 nameservers, that's 12 > > just to be clear: "wrong" means inconsistent reverse mapping, not a > missing one. > While reverse mapping may be absent, inconsistencies are almost always > a > sign of a problem. The reverse mapping is not required for the > resolution > processs but is helpful (and in the case of inconsistencies: less > helpful) > for debugging. OK... well, the inconsistancy is there because we do get the providers to put generic rDNS in place in most places. Of course, we don't always have matching fwds for the reverse, because, well, nobody every uses the rDNS we have :) >> points more than failure. Now, I could work around this by only >> submitting 4 nameservers, but that seems contrary to the goal of >> having >> a stable in-addr.arpa delegation. > > I wonder why you're having so many name servers all suffering from the > same > problem. Maybe they're administratively *and* topologically close? > Could you give details, please? When we setup locations, we don't always know in advance what machines are going in. We move stuff around a lot... and have procedures in place to handle A records, because, well we control those. We don't control the rDNS, nor do we really want/need to. >> The description for PROBLEM_WRONG_REVERSE_MAPPING refers to RFC1912, >> section 2.1 which says "should", not "must", so such a high penalty >> for no technical problem does not seem valid. I can't think of a >> truely operational problem caused by missing rDNS on an auth >> nameserver. > > RFC 1912 predates RFC 2119, so this 'should' vs 'must' deliberations > must(sic!) > be taken with a grain of salt. Heh... well, I would be surprised if it was updated that it would be set to a must rather than should :) > >> I would like to propose either changing this to a 0 point Information, >> or a 1 point Warning. > > One could also argue that the same warning produced by several servers > should > be limited in its impact, but OTOH this accumulation of warnings, even > of > the same type, suggests a deeper inspection is due. Potentially, but I still disagree that 4 points is valid for a non-technical issue.