[128018] in North American Network Operators' Group
Re: Root Zone DNSSEC Deployment Technical Status Update
daemon@ATHENA.MIT.EDU (Joe Abley)
Thu Jul 22 23:53:11 2010
From: Joe Abley <jabley@hopcount.ca>
In-Reply-To: <20100716145315.GA19935@ussenterprise.ufp.org>
Date: Fri, 23 Jul 2010 05:52:58 +0200
To: Leo Bicknell <bicknell@ufp.org>
X-SA-Exim-Mail-From: jabley@hopcount.ca
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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/>.
>=20
> 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-t=
rust-anchor-01.txt
=20
Joe=
