As far as I know, the only format of secure distribution for the root
trust anchor is an XML file. Here is a Makefile and a XSLT script to
translate this file to a trust anchor that Unbound will
recognize. Just type "make"
Makefile (1.28 KB)
anchors2ds.xsl (855 Bytes)
Hi Stephane,
you should add the -o option to wget, otherwise you may have asecurity risk
of unexpected download filenames.
I've attached a corrected version of this Makefile.
Regards
Hauke
Makefile (1.31 KB)
a message of 76 lines which said:
you should add the -o option to wget, otherwise you may have asecurity risk
of unexpected download filenames.
Thanks, I was not aware that wget used the COntent-Disposition header
Fixed on my local copy as well. Apart from that, does it work for you?
you should add the -o option to wget, otherwise you may have asecurity risk
That should be "-O". In older versions of wget (1.10.2/Debian Etch),
this option does not works together with "-nc". The empty output file is
created first, therefore "-nc" never downloads anything.
Another thing I noticed is that newer wget always sets a downloaded
file's mtime to the timestamp received in the headers, with no apparent
way to disable it.
Fixed on my local copy as well. Apart from that, does it work for you?
It does work for me. I attached a modified version that also outputs
"root-anchors.mkey" with the key wrapped in BIND's "managed-keys" clause.
Thanks Stéphane. With your Makefile and XSLT, it's very easy to verify
and convert the root anchors from IANA for use with Unbound an BIND.
root-anchors.txt for unbound and "(auto-)trust-anchor-file".
root-anchors.mkey for RFC5011 mangement with BIND.
root-anchors.dnskey for static "trusted-keys" configuration.
Hauke
Makefile (1.77 KB)
Thank you Stephane and Hauke; this latest iteration appears to work fine.
I now have root-anchors.mkey and root-anchors.dnskey; where do I put
them, and how do I incorporate them into unbound.conf?
TIA
Oops....... not so fine. 
I deleted all of the root-anchors files, re-ran, and got this:
make
wget -nc -O root-anchors.xml https://data.iana.org/root-anchors/root-anchors.xml && touch root-anchors.xml
--2010-07-20 20:17:50-- https://data.iana.org/root-anchors/root-anchors.xml
Resolving data.iana.org (data.iana.org)... 192.0.32.25
Connecting to data.iana.org (data.iana.org)|192.0.32.25|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 418 [text/xml]
Saving to: `root-anchors.xml'
100%[=======================================================================>] 418 --.-K/s in 0s
2010-07-20 20:17:51 (403 MB/s) - `root-anchors.xml' saved [418/418]
wget -nc -O root-anchors.asc https://data.iana.org/root-anchors/root-anchors.asc && touch root-anchors.asc
--2010-07-20 20:17:51-- https://data.iana.org/root-anchors/root-anchors.asc
Resolving data.iana.org (data.iana.org)... 192.0.32.25
Connecting to data.iana.org (data.iana.org)|192.0.32.25|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 189 [text/plain]
Saving to: `root-anchors.asc'
100%[=======================================================================>] 189 --.-K/s in 0s
2010-07-20 20:17:51 (112 MB/s) - `root-anchors.asc' saved [189/189]
gpg --verify root-anchors.asc root-anchors.xml || \
sh -c 'echo "Invalid root-anchors.xml"; rm -f root-anchors.xml root-anchors.asc; exit 1;'
gpg: Signature made Tue Jul 6 18:49:10 2010 EDT using DSA key ID 0F6C91D2
gpg: Good signature from "DNSSEC Manager <dnssec@iana.org>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 2FBB 91BC AAEE 0ABE 1F80 31C7 D1AF BCE0 0F6C 91D2
OK, root-anchors.xml is correct
xsltproc -o root-anchors.txt anchors2ds.xsl root-anchors.xml
dig DNSKEY . | grep -w 257 > untrusted.key
# Verify the key
# Thanks to Kazunori Fujiwara for the idea
dnssec-dsfromkey -2 untrusted.key > untrusted.ds
/bin/sh: dnssec-dsfromkey: command not found
make: *** [root-anchors.txt] Error 127
You find the dnssec-dsfromkey in the bind distribution.
Patrik
Hi,
I now have root-anchors.mkey and root-anchors.dnskey; where do I put
them, and how do I incorporate them into unbound.conf?
I used the auto-trust-anchor-file directive in unbound.conf:
auto-trust-anchor-file: "/etc/unbound/anchors/root/root-anchors.txt"
Once you restart unbound, that file should have the automatically
retrieved root anchor, via rfc5011 magic. If you are running unbound as
a different user, make sure the file is owned by that user as unbound
will need to write to it periodically.
rg
Ah, thank you Rob Gallagher for the tip re: the configuration; unbound
started up and immediately revised the .txt file.
Thank you Patrik Fältström for the explanation re the script failure.
Perhaps an extra comment in the script?
echo " NOTE, the following dnssec-dsfromkey command will fail if you
are not using bind. Not a problem; the other files are good."
Thanks
There is also a very simple method, but with other dependencies. Made by Bjørn Mork:
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 <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)
Hi,
Hauke's version of the Makefile doesn't work for me unfortunately.
Here's what I get (on ubuntu 9.10 karmic)...
Hi Jeff.
..where's the pubkey supposed to come from to validate it? If GPG is
supposed to suck it over the net, maybe that's the problem?
gpg needs to have IANA's DNSSEC public key in its keyring.
You can retrieve the key from public keyservers:
gpg --search-key dnssec@iana.org
or download it from IANA here:
http://data.iana.org/root-anchors/icann.pgp
Now that you have the key, you can either trust that its the right one.
That's what I did.
Or you would have to verify the key's fingerprint with IANA staff,
although I don't know if that's even an option[*].
JFTR, the key in my keyring has these IDs and fingerprint:
pub 1024D/0F6C91D2 2007-12-01 [expires: 2011-11-25]
Key fingerprint = 2FBB 91BC AAEE 0ABE 1F80 31C7 D1AF BCE0 0F6C 91D2
uid DNSSEC Manager <dnssec@iana.org>
sub 2048g/1975679E 2007-12-01
[*] How about a voice recording on a POTS extension? 
Hauke.
Thanks Hauke, I'm past that particular issue now. but anther reared its head (down at end).
>
> > ..where's the pubkey supposed to come from to validate it? If GPG is
> > supposed to suck it over the net, maybe that's the problem?
>
> gpg needs to have IANA's DNSSEC public key in its keyring.
>
> You can retrieve the key from public keyservers:
> gpg --search-key dnssec@iana.org
Ok, that worked for me on one of my systems..
> gpg --search-key dnssec@iana.org
gpg: searching for "dnssec@iana.org" from hkp server subkeys.pgp.net
(1) DNSSEC Manager <dnssec@iana.org>
1024 bit DSA key 0F6C91D2, created: 2007-12-01
Keys 1-1 of 1 for "dnssec@iana.org". Enter number(s), N)ext, or Q)uit > 1
gpg: requesting key 0F6C91D2 from hkp server subkeys.pgp.net
gpg: key 0F6C91D2: public key "DNSSEC Manager <dnssec@iana.org>" imported
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: Total number processed: 1
gpg: imported: 1
> Now that you have the key, you can either trust that its the right one.
> That's what I did.
>
> Or you would have to verify the key's fingerprint with IANA staff,
> although I don't know if that's even an option[*].
the latter sounds like a question for dnssec-deployment@ 
> JFTR, the key in my keyring has these IDs and fingerprint:
>
> pub 1024D/0F6C91D2 2007-12-01 [expires: 2011-11-25]
> Key fingerprint = 2FBB 91BC AAEE 0ABE 1F80 31C7 D1AF BCE0 0F6C 91D2
> uid DNSSEC Manager <dnssec@iana.org>
> sub 2048g/1975679E 2007-12-01
ok, so does the one in my keyring..
> gpg --fingerprint dnssec@iana.org
pub 1024D/0F6C91D2 2007-12-01 [expires: 2011-03-04]
Key fingerprint = 2FBB 91BC AAEE 0ABE 1F80 31C7 D1AF BCE0 0F6C 91D2
uid DNSSEC Manager <dnssec@iana.org>
sub 2048g/1975679E 2007-12-01
Now however, there's another problem with the Makefile <http://unbound.nlnetlabs.nl/pipermail/unbound-users/attachments/20100720/0fa5e52f/attachment-0005.txt>, at least for me: (listing starts after root-anchors.* files are sucked over)..
gpg --verify root-anchors.asc root-anchors.xml || \
sh -c 'echo "Invalid root-anchors.xml"; rm -f root-anchors.xml root-anchors.asc; exit 1;'
gpg: Signature made Tue 06 Jul 2010 03:49:10 PM PDT using DSA key ID 0F6C91D2
gpg: Good signature from "DNSSEC Manager <dnssec@iana.org>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 2FBB 91BC AAEE 0ABE 1F80 31C7 D1AF BCE0 0F6C 91D2
OK, root-anchors.xml is correct
xsltproc -o root-anchors.txt anchors2ds.xsl root-anchors.xml
dig DNSKEY . | grep -w 257 > untrusted.key
# Verify the key
# Thanks to Kazunori Fujiwara for the idea
dnssec-dsfromkey -2 untrusted.key > untrusted.ds <<<====!!!
dnssec-dsfromkey: invalid keyfile name untrusted.key: algorithm is unsupported
make: *** [root-anchors.txt] Error 1
note the "algorithm is unsupported" error msg from dnssec-dsfromkey.
the dnssec-dsfromkey version I'm using is 9.6.1-P2.
thoughts?
thanks,
=JeffH
As the root is signed with RSA/SHA-256, you need BIND 9.6.2 or later to validate signatures.
jakob
That version of dnssec-dsfromkey is too old, it does not support SHA256.
You need to upgrade your BIND tools package to a version that does
SHA256, like BIND 9.7.1-P2 or BIND 9.6.2 (and up).
-- Carsten
note the "algorithm is unsupported" error msg from dnssec-dsfromkey.
the dnssec-dsfromkey version I'm using is 9.6.1-P2.
thoughts?
That version of dnssec-dsfromkey is too old, it does not support SHA256.
You need to upgrade your BIND tools package to a version that does
SHA256, like BIND 9.7.1-P2 or BIND 9.6.2 (and up).
When it turned out I didn't have this installed.
I just did part of it by hand ones with unbound-host and setup the
auto-trust-anchor:
- downloaded the files using https and verified the CA-cert(s).
- imported the PGP key in a temporary account.
- checked the files with the PGP-key
- grabbed the DS-record from the file(s) which were just checked before that
- munched the DS-record a bit (I think replace the IN with a .)
- and verified the root with unbound-host -vj "..."
after that I setup unbound to use auto-trust-anchor-file
I think this should be ok and shouldn't need to look at it ever again.
As the root is signed with RSA/SHA-256, you need BIND 9.6.2 or later to
> validate signatures.
thanks for the hint. rather than muck with my (stock) ubuntu system's DNS underpinnings/tools, I noticed that the ldns tools I have also address this and tried this in the Makefile rather than dnssec-dsfromkey..
ldns-key2ds -${HASHALG} -n untrusted.key > untrusted.ds
..which worked.
However, my awk and cut (or something) must be different than Stephane's because I couldn't get the stuff after the dnssec-dsfromkey/ldns-key2ds parts in the Makefile to work, even hacking around by hand.
However, Leen's "rootanchor2keys.pl" <http://unbound.nlnetlabs.nl/pipermail/unbound-users/2010-July/001267.html> apparently did the trick..
> wget -q -O- https://data.iana.org/root-anchors/root-anchors.xml | ./rootanchor2keys.pl -
/* created by ./rootanchor2keys.pl at 2010-08-25T19:21:51 */
trusted-keys {
/* id="Kjqmt7v", keytag=19036 */
"." 257 3 8
"AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0
EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/Q
Zxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hO
A2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8
ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=";
};
Now, it apparently is printing to stdout what the Makefile would have output as root-anchors.dnskey, yes?
My interest in getting the root-anchor set up on my system at this time is to be able to use ldns tools such as drill et al -- so do i need to produce a root-anchors.mkey ("managed keys"?) file also? and how does it differ syntactically from the above ?
and also, where do I need to place these files such that the ldns tools such as drill et al will find them ?
thanks for the help,
=JeffH
FWIW, I've updated http://www.kirei.se/xfiles/dnssec/ta-tool.pl so it can also print bind9 compatible trusted-keys and managed-keys statement, e.g.:
# perl ta-tool.pl --managed root-anchors.xml
managed-keys {
"." initial-key 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=";
};
jakob