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ý 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.
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ý ond...@sury.org
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with
Bug#752745: ITP: dnssec-root-key -- This package contains DNSSEC root key
Hi, Ondřej Surý: 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/)? root.key and root.ds are read-only data (from the local admin's PoV). Why would they reside in /etc? -- -- Matthias Urlichs -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140627154836.gk27...@smurf.noris.de
Bug#752745: ITP: dnssec-root-key -- This package contains DNSSEC root key
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.
Bug#752745: ITP: dnssec-root-key -- This package contains DNSSEC root key
Package: wnpp Severity: wishlist Owner: Ondřej Surý ond...@debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: dnssec-root-key Version : 20100715 Upstream Author : ICANN/IANA * URL : http://data.iana.org/root-anchors/ * License : Public Data (same as with root.zone) 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. - -- 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. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJTq8iuAAoJEAyZtw70/LsHnXAQALn7VdqAb19f8lfon4xErVTl X51iFSNoqIFJQgl1y80sFsStVbPgwGgqPmRnrviVmjXvYphJs6YpZkIZCG1EMbz6 ICUHdVrH9//hbjHkY265W2SOECo2uRXPYZ6EgHl0keKJbZPodnlxrxlhPeQ9y68Q srh7/glB/BMxU1k6VJwut50w00Cr9vmYX4mtG0I8GNBmWhQU0GXS/4qdNWMnIqaL qGaDN2sheFHsaEqL0pZquK4U7tL0Ah0J/6VUHiPbnqI49olii7N3IXtH7i9KM3V1 2JFPTN2S0I8qGh/e4kbZzko2zULbwKwFYRP9hymU/CQ1WMnYpmonN+iHgVL0K2rO 6qF4OQKS/Fw/mttym5fir3aBL+mKhbuVtVnH3WsC6Lra3hyB1sPTFAZZyfgTLe7v N1shbIznaUtDXQ/rey/n9ljC3HJa6hUQ9s1ae7SmkmVj9cbbuMZNFEkCUgco6VXM O1D5q5oJ/F0xsWLutJ0BirkGqKHqiL7/6sofWRyysNrRdqM63p7XNCeOy8o06YUH P/FkaL/Uk1sTabL07pFjknYmRORWdhglNaUD1Xy9r8LlHpDyk/qf8vkBzN0Y4dHH XgLKm6UDMm5tjhlIyjArIVT4Q22i+ZVsvkPCsEXrglimrrMQxDTI6Gi8q6FbfuD8 iczDv8qKX0dehB2IoRBe =afU7 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140626071603.2788.54208.report...@howl.nic.cz
Bug#752745: ITP: dnssec-root-key -- This package contains DNSSEC root key
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 :-) Similarly, s/key/trust anchors/g in the descriptions? 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: 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. 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. -- 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). 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.) 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.) 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 And, finally, is it known that the root DNSSEC key will be rolled over with RFC 5011 semantics? Anyway, consider this email an offer to co-maintain :-) -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140626223252.ga2...@mycre.ws
Bug#752745: ITP: dnssec-root-key -- This package contains DNSSEC root key
On Thu, Jun 26, 2014 at 09:16:03AM +0200, Ondřej Surý wrote: This package contains DNSSEC root key in all available formats that all packages doing DNSSEC validation can use as a common data source. Hi Ondřej, unbound-anchor is already packaged for Debian. What does this package provide that the unbound-anchor package doesn't provide? Iain. -- urn:x-human:Iain R. Learmonth http://iain.learmonth.me/ mailto:i...@fsfe.org xmpp:i...@jabber.fsfe.org tel:+447875886930 GPG Fingerprint: 1F72 607C 5FF2 CCD5 3F01 600D 56FF 9EA4 E984 6C49 Please verify out-of-band before trusting with sensitive information. This email was composed Thu 26 Jun 23:44:23 BST 2014. pgplIOu4Xn1CT.pgp Description: PGP signature
Bug#752745: ITP: dnssec-root-key -- This package contains DNSSEC root key
Hi Ondřej, On Thu, Jun 26, 2014 at 09:16:03AM +0200, Ondřej Surý wrote: 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 already packaged in Debian. What does this package provide that the unbound-anchor doesn't? Iain. -- urn:x-human:Iain R. Learmonth http://iain.learmonth.me/ mailto:i...@fsfe.org xmpp:i...@jabber.fsfe.org tel:+447875886930 GPG Fingerprint: 1F72 607C 5FF2 CCD5 3F01 600D 56FF 9EA4 E984 6C49 Please verify out-of-band before trusting with sensitive information. This email was composed Thu 26 Jun 23:48:03 BST 2014. pgp1zelyL9oJI.pgp Description: PGP signature
Bug#752745: ITP: dnssec-root-key -- This package contains DNSSEC root key
Iain R. Learmonth wrote:
unbound-anchor is already packaged in Debian. What does this package provide
that the unbound-anchor doesn't?
The output of unbound-anchor is intended for use by the unbound daemon
only, more or less; what unbound calls an autotrust anchor file. It
looks like this:
$ unbound-anchor -a /tmp/root.key
$ cat /tmp/root.key
; autotrust trust anchor file
;;id: . 1
;;last_queried: 1403825702 ;;Thu Jun 26 19:35:02 2014
;;last_success: 1403825702 ;;Thu Jun 26 19:35:02 2014
;;next_probe_time: 1403866063 ;;Fri Jun 27 06:47:43 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=1403825702 ;;Thu Jun 26 19:35:02 2014
(Though, it tries to use master zone file format for the DNSKEY
record, and keep its state isolated to what would be considered comments
by a zone file parser.)
It uses embedded key material in the unbound-anchor source code to
produce this. This embedded key material could be provided by this new
package, instead.
BIND, on the other hand, expects something that looks like this:
managed-keys {
# ROOT KEY: See https://data.iana.org/root-anchors/root-anchors.xml
# for current trust anchor information.
# NOTE: This key is activated by setting dnssec-validation auto;
# in named.conf.
. initial-key 257 3 8
AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
QxA+Uk1ihz0=;
};
dnsmasq wants a third format:
# The root DNSSEC trust anchor, valid as at 30/01/2014
# Note that this is a DS record (ie a hash of the root Zone Signing Key)
# If was downloaded from https://data.iana.org/root-anchors/root-anchors.xml
trust-anchor=.,19036,8,2,49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
So, the idea is that instead of each program capable of performing
DNSSEC validation having its own copy of the DNSSEC root trust anchor
(and handling key rollover, or not), that we centralize the key material
in a single package, rather than the upstream developers being
responsible for keeping the key updated. But then we need to figure out
how to get the key material into the format that the various programs
expect. (I haven't looked to see what format getdns and hash-slinger
expect.)
--
Robert Edmonds
edmo...@debian.org
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140626234628.ga7...@mycre.ws
