Root Zone DNSSEC Deployment Technical Status Update

Mailman List Mirror (Read Only)
1

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

2

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/&gt;\.

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.

3

Wonderful news!

4

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)

5

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).

6

(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.

7

XSLT can't turn root-anchors.xml into the DNSKEY RR that BIND requires.

Tony.

8

anchors2keys will.

9

Once upon a time, Tony Finch <dot@dotat.at> said:

10

Actually, it won't. The ITAR anchors.xml and anchors2keys use a
different XML schema than the root-anchors.xml does.

11

Yeah oops.

Just noticed that

Joel's iPad

12

*sigh*

Tony.

13

Jeffrey Ollie <jeff@ocjtech.us> writes:

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

14

Hi Leo,

Late reply! Sorry. Have been neglecting this folder.

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/&gt;\.

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:

  DNSSEC Project Archive

Joe