[Unbound-users] testing validation failure

[Taylor R Campbell]

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>, as of
2010-03-10.

anchors.mf is from <https://itar.iana.org/anchors/anchors.mf>, 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>, 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.