Root Zone DNSSEC Deployment Technical Status Update
Root Zone DNSSEC Deployment Technical Status Update 2010-07-16 This is the twelfth of a series of technical status updates intended to inform a technical audience on progress in signing the root zone of the DNS. RESOURCES Details of the project, including documentation published to date, can be found at <http://www.root-dnssec.org/>. We'd like to hear from you. If you have feedback for us, please send it to rootsign@icann.org. FULL PRODUCTION SIGNED ROOT ZONE The transition from Deliberately-Unvalidatable Root Zone (DURZ) to production signed root zone took place on 2010-07-15 at 2050 UTC. The first full production signed root zone had SOA serial 2010071501. There have been no reported harmful effects. The root zone trust anchor can be found at <https://data.iana.org/root-anchors/>. PLANNED DEPLOYMENT SCHEDULE Already completed: 2010-01-27: L starts to serve DURZ 2010-02-10: A starts to serve DURZ 2010-03-03: M, I start to serve DURZ 2010-03-24: D, K, E start to serve DURZ 2010-04-14: B, H, C, G, F start to serve DURZ 2010-05-05: J starts to serve DURZ 2010-06-16: First Key Signing Key (KSK) Ceremony 2010-07-12: Second Key Signing Key (KSK) Ceremony 2010-07-15: Distribution of validatable, production, signed root zone; publication of root zone trust anchor
In a message written on Fri, Jul 16, 2010 at 02:35:39PM +0000, Joe Abley wrote:
The transition from Deliberately-Unvalidatable Root Zone (DURZ) to production signed root zone took place on 2010-07-15 at 2050 UTC. The first full production signed root zone had SOA serial 2010071501. There have been no reported harmful effects. The root zone trust anchor can be found at <https://data.iana.org/root-anchors/>.
Perhaps you could explain why the keys are being made available in formats that, as far as I can tell, no nameserver software on the planet uses? Pretty much 100% of the users will need a conversion from one of the 6 formats you provided, when you could have provided 6 example configs for the 6 most popular nameserver packages and covered 99% of the users with cut and paste. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
Leo Bicknell wrote:
Perhaps you could explain why the keys are being made available in formats that, as far as I can tell, no nameserver software on the planet uses? Pretty much 100% of the users will need a conversion from one of the 6 formats you provided, when you could have provided 6 example configs for the 6 most popular nameserver packages and covered 99% of the users with cut and paste.
Ditto. Rapid deployment follows where cut-and-past mostly works to implement. (for better or worse)
Once upon a time, Leo Bicknell <bicknell@ufp.org> said:
Perhaps you could explain why the keys are being made available in formats that, as far as I can tell, no nameserver software on the planet uses? Pretty much 100% of the users will need a conversion from one of the 6 formats you provided, when you could have provided 6 example configs for the 6 most popular nameserver packages and covered 99% of the users with cut and paste.
There aren't 6 formats, there is just one format provided for the current trust anchor set: XML. A simple XSLT will transform it into any needed format. Individual trust anchors (there's only one at the moment) are provided in two formats: PKCS#10 (for signing) and X509 (signed by ICANN). There are also detached signatures (in PKCS#7 format for validation against the ICANN cert bundle and in OpenPGP format) of the XML anchor set file. This is all in the documentation in the same directory (in plain-text and HTML formats). -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
On Fri, 16 Jul 2010, Chris Adams wrote:
A simple XSLT will transform it into any needed format.
XSLT can't turn root-anchors.xml into the DNSKEY RR that BIND requires. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ TYNE DOGGER FISHER: SOUTHERLY VEERING WESTERLY 5 TO 7, DECREASING 4 OR 5. MODERATE OR ROUGH, OCCASIONALLY VERY ROUGH AT FIRST IN FISHER, BECOMING SLIGHT OR MODERATE. SQUALLY, THUNDERY SHOWERS. MODERATE OR GOOD.
On Fri, Jul 16, 2010 at 1:12 PM, Joel Jaeggli <joelja@bogus.com> wrote:
On 7/16/10 11:07 AM, Tony Finch wrote:
On Fri, 16 Jul 2010, Chris Adams wrote:
A simple XSLT will transform it into any needed format.
XSLT can't turn root-anchors.xml into the DNSKEY RR that BIND requires.
anchors2keys will.
Actually, it won't. The ITAR anchors.xml and anchors2keys use a different XML schema than the root-anchors.xml does. -- Jeff Ollie
Yeah oops. Just noticed that Joel's iPad On Jul 16, 2010, at 5:34 PM, Jeffrey Ollie <jeff@ocjtech.us> wrote:
On Fri, Jul 16, 2010 at 1:12 PM, Joel Jaeggli <joelja@bogus.com> wrote:
On 7/16/10 11:07 AM, Tony Finch wrote:
On Fri, 16 Jul 2010, Chris Adams wrote:
A simple XSLT will transform it into any needed format.
XSLT can't turn root-anchors.xml into the DNSKEY RR that BIND requires.
anchors2keys will.
Actually, it won't. The ITAR anchors.xml and anchors2keys use a different XML schema than the root-anchors.xml does.
-- Jeff Ollie
On Fri, 16 Jul 2010, Jeffrey Ollie wrote:
The ITAR anchors.xml and anchors2keys use a different XML schema than the root-anchors.xml does.
*sigh* Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ NORTHWEST FITZROY SOLE: SOUTHWESTERLY 5 OR 6, DECREASING 3 OR 4 LATER. MODERATE OR ROUGH. RAIN, SHOWERS LATER. MODERATE OR POOR, BECOMING GOOD LATER.
Jeffrey Ollie <jeff@ocjtech.us> writes:
On Fri, Jul 16, 2010 at 1:12 PM, Joel Jaeggli <joelja@bogus.com> wrote:
On 7/16/10 11:07 AM, Tony Finch wrote:
On Fri, 16 Jul 2010, Chris Adams wrote:
A simple XSLT will transform it into any needed format.
XSLT can't turn root-anchors.xml into the DNSKEY RR that BIND requires.
anchors2keys will.
Actually, it won't. The ITAR anchors.xml and anchors2keys use a different XML schema than the root-anchors.xml does.
Just for the fun of it, I explored how difficult it would be implementing something similar in perl using the excellent Net::DNS::SEC module. It was really simple: http://www.mork.no/~bjorn/rootanchor2keys.pl Ugly as hell as usual with my perl code, but it works. And it is simple enough to be verifiable. You will need Net::DNS::SEC and XML::Simple from CPAN or your friendly OS distribution (libnet-dns-sec-perl and libxml-simple-perl in Debian) Bjørn
Once upon a time, Tony Finch <dot@dotat.at> said:
On Fri, 16 Jul 2010, Chris Adams wrote:
A simple XSLT will transform it into any needed format.
XSLT can't turn root-anchors.xml into the DNSKEY RR that BIND requires.
That sounds like a problem with BIND then. :-) -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
At 7:53 -0700 7/16/10, Leo Bicknell wrote:
Perhaps you could explain why the keys are being made available in formats that, as far as I can tell, no nameserver software on the planet uses?
(My guess:) There's no standard input format for name servers, especially regarding configuration information. The problem isn't (just) that the root anchor isn't in the format for any name server, the problem is that name servers can't read the formats given. If you want it for BIND, for example, ISC would be the place to get it in the "trusted-keys" syntax. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Spouses, like Internet protocols, lack necessary troubleshooting tools. Sigh.
Hi Leo, Late reply! Sorry. Have been neglecting this folder. On 2010-07-16, at 16:53, Leo Bicknell wrote:
In a message written on Fri, Jul 16, 2010 at 02:35:39PM +0000, Joe Abley wrote:
The transition from Deliberately-Unvalidatable Root Zone (DURZ) to production signed root zone took place on 2010-07-15 at 2050 UTC. The first full production signed root zone had SOA serial 2010071501. There have been no reported harmful effects. The root zone trust anchor can be found at <https://data.iana.org/root-anchors/>.
Perhaps you could explain why the keys are being made available in formats that, as far as I can tell, no nameserver software on the planet uses?
There seem to be two related issues, here: 1. Why use a format that is non-native to any particular implementation? We made the decision to publish the trust anchor in a vendor-independent fashion. We also wanted a way of publishing a full set of current plus historic trust anchors (for which there is no obvious prior art). The XML representation you've seen has the advantage that precisely because it is not in a format directly amenable to cut and paste (although obviously you can scrape the RDATA out of it easily; it's just a text file) there's reduced risk that someone would paste an old trust anchor into a validator's configuration and experience great user hilarity. We have already seen people produce tools which can process the XML-published trust anchor set to configure validators. No doubt we will see more tools in future. Maybe some vendors will decide to support it directly. 2. Why publish the trust anchor as a hash of the public key (DS RDATA) rather than the public key itself (DNSKEY RDATA)? Because as far as we can identify, that's the consensus in the relevant IETF working groups for how trust anchors should be published. I've heard the argument both ways. Don't shoot the messenger. On a more general note we first published the document which described the trust anchor format back in January, and since then we've been soliciting input on that (and other documents) in more or less every ops meeting and ops mailing list you could mention. We got zero feedback on that document, and perhaps unreasonably we interpreted that as a lack of concern over (e.g.) the point you mentioned. Here's a link to the final version: http://www.root-dnssec.org/wp-content/uploads/2010/07/draft-icann-dnssec-tru... Joe
participants (11)
-
Bjørn Mork -
Chris Adams -
Edward Lewis -
Jeffrey Ollie -
Joe Abley -
Joe Abley -
Joel Jaeggli -
Leo Bicknell -
Mike -
Steven Bellovin -
Tony Finch