Testing validation failure

Unbound
1

I am trying to make Unbound act as a recursive resolver that answers
with and caches secure and insecure data, but not bogus data, using
the IANA ITAR trust anchors. In particular, I want replies with the
AD bit clear to mean that the relevant data are insecure, and I want
the resolver to return an error when all it can find is bogus data.
However, my attempts so far have been met with failure, so I assume I
must be doing something wrong, and I should like to know how to do it
right.

I installed Unbound 1.4.2 (on a 32-bit machine not running Mac OS X or
Solaris, so I haven't upgraded to 1.4.3) and ran it with the following
configuration:

server:
        verbosity: 1
        interface: 0.0.0.0
        interface: ::0
        do-daemonize: no
        access-control: 0.0.0.0/0 allow
        access-control: ::0/0 allow
        chroot: "/var/chroot/unbound"
        directory: ""
        logfile: ""
        use-syslog: no
        log-time-ascii: yes
        pidfile: "/var/run/unbound.pid"
        root-hints: "named.cache"
        do-not-query-address: 127.0.0.1/8
        do-not-query-localhost: yes
        trust-anchor-file: "anchors.mf"
        val-log-level: 1

named.cache is from <ftp://ftp.internic.net/domain/named.cache&gt;, as of
2010-03-10.

anchors.mf is from <https://itar.iana.org/anchors/anchors.mf&gt;, as of
2010-03-01.

Both files are in /var/chroot/unbound. unbound-checkconf is happy
with my configuration file.

When I query Unbound for badsign-a.test.dnssec-tools.org's A record,
it happily hands back an A record, even though the authoritative
nameserver gives a bad signature:

% dig @localhost. badsign-A.test.dnssec-tools.org. a
...
;; ANSWER SECTION:
badsign-A.test.dnssec-tools.org. 86400 IN A 75.119.216.33
...
% drill @localhost. badsign-A.test.dnssec-tools.org. a
...
;; ANSWER SECTION:
badsign-A.test.dnssec-tools.org. 86386 IN A 75.119.216.33
...

I want Unbound to give an error in this case, not simply an answer
with the AD bit clear.

If I replace

  trust-anchor-file: "anchors.mf"

by

  dlv-anchor-file: "dlv.isc.org.key"

then I get back SERVFAIL as I expected. dlv.isc.org.key is from
<http://ftp.isc.org/www/dlv/dlv.isc.org.key&gt;, as of 2010-03-10, and is
also stored in /var/chroot/unbound.

Let me know if you would like to see log messages, or any other
information about my configuration or tests.

2

Hi Taylor,

Thanks for enabling DNSSEC.

The issue is simply that dnssec-tools.org does not have a secure
delegation from .org, the DS is not returned by the .org servers:
dig @d0.org.afilias-nst.org. dnssec-tools.org +dnssec

I found this with unbound-host -vd which said (in lots of output):
info: Successfully primed trust anchor <ORG. DNSKEY IN>
info: NSEC3s for the referral proved no DS.
info: Verified that response is INSECURE

They presumably have a dlv entry, thus the dlv anchor works.

I would advise you to install a cron job to pull the anchors.mf and
update it. A script that does so and checks the PGP signature is in the
unbound source tarball contrib/update-itar.sh :slight_smile:

This makes sure that you have the latest trust anchors, otherwise they
go stale and things stop working next year.

Best regards,
   Wouter

3

The issue is simply that dnssec-tools.org does not have a secure
   delegation from .org, the DS is not returned by the .org servers:
   dig @d0.org.afilias-nst.org. dnssec-tools.org +dnssec

Thanks. I see that this is spelled out precisely in RFC 4033 in the
definitions of `insecure' and `bogus'. If I put dnssec-tools.org's
DNSKEY among Unbound's trust anchors, I get SERVFAIL as expected.

   I would advise you to install a cron job to pull the anchors.mf and
   update it. A script that does so and checks the PGP signature is in the
   unbound source tarball contrib/update-itar.sh :slight_smile:

Yep, I planned to do that once I got Unbound behaving as I expect.

   This makes sure that you have the latest trust anchors, otherwise they
   go stale and things stop working next year.

Next year? Isn't the root zone supposed to be signed in July, at
which point the IANA ITAR will turn into a pumpkin?