Maintained by: NLnet Labs

[Unbound-users] DNSSec validation

W.C.A. Wijngaards
Wed Oct 3 10:58:49 CEST 2012


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Nikos,

On 10/03/2012 10:49 AM, Nikos Mavrogiannopoulos wrote:
> On Wed, Oct 3, 2012 at 10:16 AM, W.C.A. Wijngaards
> <wouter at nlnetlabs.nl> wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> Hi Nikos,
>>> Hello, I'm trying to work with the DNSSec validation example in
>>> the unbound tutorial [0]. My issue is that at some point it
>>> calls: ub_ctx_add_ta_file() with a file called "keys" and that
>>> according to the comment this is the "public keys for DNSSEC
>>> verification". However what does that exactly mean? How do you
>>> obtain this list? I have a high level  understanding of dnssec,
>>> and I'd expect that if I set there the file
>>> /etc/unbound/root.key it should be able to verify any domain,
>>> is that correct? (it doesn't seem to work)
>> 
>> You need: ub_ctx_set_option(ctx, "auto-trust-anchor-file:", 
>> "/etc/unbound/root.key"); because that file is in the
>> 'auto-trust-anchor-file' format.
> 
> Thank you. I tried it, but in both cases I get the same error
> message: Result is bogus: validation failure <www.nlnetlabs.nl. A
> IN>: no signatures from 10.0.2.3 for trust anchor . while building
> chain of trust
> 
> I increased debugging but I cannot really follow the log, which 
> contains entries like: [1349253750] libunbound[3158:0] info: super
> is www.nlnetlabs.nl. A IN [1349253750] libunbound[3158:0] info:
> autotrust process for . DNSKEY IN [1349253750] libunbound[3158:0]
> debug: rrset failed to verify due to a lack of signatures 
> [1349253750] libunbound[3158:0] debug: Failed to match any usable 
> anchor to a DNSKEY. [1349253750] libunbound[3158:0] debug:
> autotrust: validate DNSKEY with anchor: sec_status_bogus 
> [1349253750] libunbound[3158:0] debug: autotrust: dnskey did not
> verify. [1349253750] libunbound[3158:0] debug: autotrust: write to
> disk: root.key.3158-0 [1349253750] libunbound[3158:0] debug:
> autotrust: replaced root.key [1349253750] libunbound[3158:0] debug:
> rrset failed to verify due to a lack of signatures [1349253750]
> libunbound[3158:0] debug: Failed to match any usable anchor to a
> DNSKEY.

The trust anchor was working all along, just fine.

The server at 10.0.2.3, is your DNS resolver, and it does not have
DNSSEC enabled.  Use unbound without it: comment out the
ub_ctx_resolvconf call.  Unbound then goes into full resolver mode.
It is wasteful and you have no fast cache hits, but it'll work with
DNSSEC.

It would be better (especially for bigger sites or bigger usage) to
upgrade the upstream cache.  Upgrade it to support DNSSEC.  It does
not actually have to validate, but it needs to have dnssec-enabled
(for BIND) or unbound (has that enabled by default).  You could also
have it validate - which is a good idea in case validation failures
need retries.  If this is your ADSL box, it may simply not be fixable,
instead change your resolv.conf(DHCP) to perhaps the actual upstream
DNS server from your ISP (many today actually have DNSSEC).  Another
is to deploy a separate resolver server for your network (that you
advertise via DHCP).   And there are more ways to setup your network.

Best regards,
   Wouter

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQa/5JAAoJEJ9vHC1+BF+Nnh8QAK0/VVmp9dzCuEeyVBj0vMoX
0+lYpi11k0tGJP38J1QzCbRX+Sf0T9x2rDN396P9AdAOcvo93aSmsNvuWnJijFoJ
qsVhaRKEE+wTW+EtpSt5YzN3mlDpTvuqqqEVmFK0lL9tWAjwzlFfEEaRySCmWiuQ
nHwN6sSo3vw67v75C+CxKLmWD16YZNTR64MsnD0Geia0MDwrJ00cx5IPeB4aLLpz
tP+vE6+Pq2xbacYX8odXgh9GpwuRgCc10pJQVCjQJ5VBwbXbOyxdwq5mUNoKIzeB
LTjA5CEA44U13PPHR2fLLHF0EZPpy/lWBZ8W+DnMxFCQ20v3DxCdWVGK+KAHxO2q
fGO2FSd31tGbkJoqP0qUYwPgo2x7Z7IoO7rz6ViLPakxiuwWeZG4ncH+9Bl7Q400
CkwjYChQVUgl4nF/5q+gdTSwaeJsvqy06fhAxTZFLMI76+ZtvzU9aRtmLpWaUAQU
d2UT5qoWW+ZY+P6x1YeFYN94JK6CaCJc2jbDHeOiP4p6JGzURz0M3uFwXx2jSexd
WlfFRJV7Mmlt55pHxjzsYhSTGkywFFw3GDymGBAAuDHuRBY+AqNbXGWHarri4QM0
hZ1RZGpWZ/i+rM7k+AWQAR45aaa2gJd4aKjEG+yQ3olU1lAOHWiVaUxayFs97Z2s
s9UfHH9/5Jd7JmpQn69Z
=3eDg
-----END PGP SIGNATURE-----