Re: Bug#752745: ITP: dnssec-root-key -- This package contains DNSSEC root key
Hi Robert,
On Fri, Jun 27, 2014, at 00:32, Robert Edmonds wrote:
> Ondřej Surý wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: "Ondřej Surý" <ondrej@debian.org>
> >
> > * Package name : dnssec-root-key
>
> Hm, I would maybe call this dnssec-root-anchors. Technically there
> should be very few copies of the root key :-)
I ended up with dns-root-data, and also included root.zone and
root.hints.
The git repo resides at github.com at the moment as I feel it's not
appropriate for collab-maint:
https://github.com/oerdnj/dns-root-data
> Similarly, s/key/trust anchors/g in the descriptions?
Yep, already fixed that:
Package: dns-root-data
Architecture: all
Depends: ${misc:Depends}
Description: DNS root data including root zone and DNSSEC key
This package contains various root zone related data as published
by IANA to be used by various DNS software as a common source
of DNS root zone data, namely:
.
* Root Hints and Zone Files (root.hints, root.zone)
* Root Trust Anchors (root.key, root.ds)
> > Version : 20100715
> > Upstream Author : ICANN/IANA
> > * URL : http://data.iana.org/root-anchors/
>
> > * License : Public Data (same as with root.zone)
>
> It might be nice to include a copy of this document in /usr/share/doc:
True, fixed in git.
> http://data.iana.org/root-anchors/draft-icann-dnssec-trust-anchor.txt
>
> Since it looks like this is the only place where a schema is defined for
> the root-anchors.xml file.
>
> But I guess we would need a better (non-)license than this:
>
> Copyright (c) 2010 Internet Corporation For Assigned Names and
> Numbers.
We do, I spoken with Kim Davies and the IANA published data is basically
public domain.
> > Programming Lang: None
> > Description : This package contains DNSSEC root key
> >
> > This package contains DNSSEC root key in all available
> > formats that all packages doing DNSSEC validation can
> > use as a common data source.
> > .
> > unbound-anchor is used to keep the root.key up-to-date
> > via RFC5011 mechanism.
I have removed the unbound-anchor runtime dependency in the end. Somehow
I feel it would be better to update this package via s-p-u mechanism.
> > PERSONAL NOTE: I now maintain at least two packages that
> > need DNSSEC root.key (hash-slinger and getdns[1]). There
> > are at least bind9, unbound and dnsmasq that can use this
> > as well.
> >
> >
> > 1. Waiting for next upstream release with proper libtool
> > flags.
>
> So, I wonder if this package should be responsible for providing the
> root-anchors.xml file, and the bind9/unbound/dnsmasq/etc. packages
> should be responsible for converting that from XML to whatever format
> they use (and unfortunately it appears every different program uses a
> different trust anchor format).
I provide root.key and root.ds in /etc/dns/. It's probably not a bad
idea to also provide root-anchors.xml in /usr/share/dns-root-data/
As a side note - do you think that /etc/dns/ is OK, or we should use
/usr/share/dns-root-data/ (or /usr/share/dns/)?
> Or by "all available formats" do you mean that this source package
> should take the root-anchors.xml file and generate several common
> formats (at package build time?) and provide them in /usr/share
> alongside the original root-anchors files from iana.org, so that DNSSEC
> software packages don't need an XML dependency? (Though, bind9 and
> unbound-anchor already pull in XML parsing libraries, but e.g. dnsmasq
> currently does not.)
My thought is to provide just root.key and root.ds and adjust if the
users of the package needs more.
> Should we patch unbound-anchor so that its fallback mode (where it tries
> to fetch files from https://data.iana.org/root-anchors/) can be made to
> check file:///usr/share/dnssec-root-anchors/ first? (And if so, it'd be
> nice to upstream that.)
Yes, I was surprised that upstream unbound-anchor cannot be used
in offline mode.
> Should we do anything about the built-in static content in
> unbound-anchor that would be duplicative of the content in this package?
> I'm talking about this:
>
> http://anonscm.debian.org/gitweb/?p=users/edmonds/unbound.git;a=blob;f=smallapp/unbound-anchor.c;h=8ea4726b06313bf2f910d07f870d4e5350e25bce;hb=HEAD#l207
>
> And this:
>
> http://anonscm.debian.org/gitweb/?p=users/edmonds/unbound.git;a=blob;f=smallapp/unbound-anchor.c;h=8ea4726b06313bf2f910d07f870d4e5350e25bce;hb=HEAD#l237
That's probably up to you. It seems to be a good idea to look for the
dns-root-data contents first before falling back to the compiled in
defaults.
> And, finally, is it known that the root DNSSEC key will be rolled over
> with RFC 5011 semantics?
To be honest, I thought so, but when you have asked, I now don't know
for sure :).
> Anyway, consider this email an offer to co-maintain :-)
Sure, you are always welcome to comaintain. Fixed in git :).
Ondrej
--
Ondřej Surý <ondrej@sury.org>
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Reply to: