Ondřej Surý wrote:
> 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ý" <ond...@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.
Hi, Ondřej:
I'm opposed to including the root zone in the same package as the
package containing the root trust anchors. Actually, I don't think the
root zone belongs in a Debian package at all.
Of course, the root zone changes very frequently, once a day or so, and
the signatures have a relatively short duration -- looking at a copy of
the zone, I see the signatures expire next week. So if the root zone
were in a Debian package, we would either have to update it extremely
frequently (qualifying it for volatile) to keep it validatable, or
update it infrequently enough that it would nearly always have expired
signatures. But with new TLDs being added to the root zone frequently,
it would still have to be updated fairly regularly (e.g., look at how
frequently the tzdata package is updated; or maybe a better example is
the publicsuffix package). Ideally the package containing the root
trust anchor would be updated so infrequently and the contents would be
so stable that many people would be able to scrutinize every single line
of changes between two versions of the package; if the root zone is in
the same package then the diff becomes much larger and makes it easier
to miss critical changes.
Can you identify a concrete use case for having the complete root zone
in a Debian package? Is there maybe something that wants an up-to-date
list of TLDs, or something like that? It seems to be a much different
use case from DNSSEC validation.
If we do need a way to get the root zone installed into a standard
location on Debian systems, I think it would be better to have a
separate "downloader" package. We can do this securely once we can
depend on a package containing the root trust anchor :-)
Something like a "dns-root-zone" package: it would depend on the package
containing the root trust anchor, but it would not contain a copy of the
root zone, instead shipping a script like "update-root-zone" that would
try to fetch the root zone from a few well-known authoritative locations
like:
http://ftp.internic.net/domain/root.zone.gz (ICANN)
ftp://rs.internic.net/domain/root.zone.gz (Verisign)
Then uncompress and dnssec-verify it in a temporary location before
installing it into /usr/share. Sort of like what you currently have in
dns-root-data's debian/rules, but it would be something that could be
run by the administrator periodically or on demand, kind of like
"update-pciids", rather than only by the package maintainers.
As for the root hints, I think that it might be a good idea to include
that in a Debian package. The bind9 and unbound daemons could be made
to directly consume that file as-is instead of relying on their built-in
root hints. (Though, unless we were to patch out the built-in hint
content entirely from those packages, which I don't think is a good
idea, we would still have to stable update a bunch of packages when a
root nameserver address changes.)
I think the package split should be between e.g. "dns-root-anchors"
(root anchor related content only) and "dns-root-zone" (containing root
zone hints and a downloader for the full root zone).
> 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.
No, I was specifically talking about the
"draft-icann-dnssec-trust-anchor" document, not the crypto material.
What you have in debian/copyright says:
ICANN asserts no property rights to any of the IANA registries or
public keys we maintain. You are free to redistribute the IANA
registry files, the root zone file and the root public keys.
I think "registry files" would not necessarily cover this technical
document with English prose. Similarly to how we have to repack source
packages to remove some RFCs due to inadequate licenses :-\ Maybe it
should say something like, "You are free to distribute the IANA registry
files, root zone technical documents, the root zone file and the root
public keys" if they wanted to explicitly make that file
redistributable.
Also, it looks like this document was generated by xml2rfc, so there is
an original source file that the .txt and .html files were generated
from that is missing. Not necessarily a problem, but a nitpick.
> > > 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.
+1, minimizing the Depends is a good idea.
Although, I think if the key is no longer intended to be updated by
unbound-anchor at runtime, it shouldn't include the unbound autotrust
"stuff". I.e., it should look like this:
. 172800 IN DNSKEY 257 3 8
AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=
Instead of like this:
; autotrust trust anchor file
;;id: . 1
;;last_queried: 1403774651 ;;Thu Jun 26 11:24:11 2014
;;last_success: 1403774651 ;;Thu Jun 26 11:24:11 2014
;;next_probe_time: 1403817219 ;;Thu Jun 26 23:13:39 2014
;;query_failed: 0
;;query_interval: 43200
;;retry_time: 8640
. 172800 IN DNSKEY 257 3 8
AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=
;{id = 19036 (ksk), size = 2048b} ;;state=2 [ VALID ] ;;count=0
;;lastchange=1403768934 ;;Thu Jun 26 09:48:54 2014
FWIW, I think the autotrust format is somewhat of a hybrid; it contains
both runtime state as well as crypto content. Since only
unbound/unbound-anchor is supposed to write to the file, that's why I
put unbound's working copy of the root autrotrust file in /var instead
of /etc or /usr.
> > > 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/
We should definitely provide the original root-anchors.xml file. This
is the canonical (and only?) format that the root trust anchor is
offered in by its original publisher. So if that file is used to
generate the master file "DS" and "DNSKEY" forms of the trust anchor, we
ought to expose the original as well.
That way you could verify that your Debian system's root-anchors.xml
exactly matches another copy of root-anchors.xml obtained through some
other authenticated path besides the Debian package archive, and you
could then mechanically generate the other DS/DNSKEY forms that are
shipped in the package. (Ideally those scripts could be shipped in the
package as well, maybe in /usr/share/doc/*/examples, plus a Suggests for
any dependencies needed by those scripts.)
That would make it as easy as possible to verify that we've not tampered
with anything, and without having to eyeball some long hexadecimal blobs
in different file formats.
> 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/)?
I think /etc/dns is not right. The root anchor is something that will
be (ought to be) updated very infrequently; if the local sysadmin is
having to update it by hand, then something has gone horribly wrong.
If the sysadmin needs to configure a root trust anchor from a *different
authority* besides the official source of root trust anchors (rather
than an updated trust anchor from the *same authority*), then the right
way to do that would be to configure a path to a different trust anchor
file into the software doing DNSSEC validation, not by overwriting the
content of a filesystem path which we've defined to contain the
ICANN/IANA root trust anchors. IMO.
This would be sort of similar to how the spi-inc.org SSL cert is shipped
in /usr/share/ca-certificates/spi-inc.org/spi-cacert-2008.crt. It's
static content, not configuration data, so it goes in /usr/share instead
of /etc.
As far the exact paths to be used, I think we should keep the
"root-anchors" name somehow. So maybe we have:
/usr/share/dns/root-anchors/*
(provided by Package: dns-root-anchors?)
/usr/share/dns/root-zone/root.hints
(provided by Package: dns-root-zone?)
/usr/share/dns/root-zone/root.zone
(installed by a downloader script in Package: dns-root-zone?)
However, if there is to be a "/usr/share/dns/" directory in Debian, I
think it should be reserved for implementation neutral DNS content. So,
it can have master file format data (root.hints, root.zone, the
DS/DNSKEY forms of the root trust anchors), and XML like the IANA
root-anchors.xml file. But no unbound autotrust files, or BIND
managed-keys stanzas, etc.
Also, this blog post is probably of interest if you haven't seen it
already:
http://0pointer.de/blog/projects/stateless.html
> > 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.
Hm, I think we should provide a bit more than that. Perhaps:
/usr/share/dns/root-anchors/
icann.pgp
icannbundle.pem
root-anchors.asc
root-anchors.p7s
root-anchors.xml
That would make it possible to do more offline verification, and maybe
enable running unbound-anchor in an offline mode.
And then the master file format versions which we have to generate,
which I think ought to be called:
/usr/share/dns/root-anchors/
root-anchors.dnskey
root-anchors.ds
> > 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.
It's also annoying that unbound-anchor does not have separate
input/output parameters. Instead there is just:
-a file
The root anchor key file, that is read in and written out.
Default is /etc/unbound/root.key. If the file does not exist,
or is empty, a builtin root key is written to it.
It would be nice if unbound-anchor could read from
/usr/share/dns/root-anchors/root-anchors.dnskey and write to
/var/lib/unbound/root.key, when we are initializing unbound's autotrust
anchor file. And not overwrite the input file.
> > 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ý <ond...@sury.org>
> Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
--
Robert Edmonds
edmo...@debian.org
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140627195720.ga32...@mycre.ws
