[Unbound-users] Effect of val-bogus-ttl

Florian Weimer fweimer at bfk.de
Mon Oct 26 10:35:12 UTC 2009

I've run the following test with Unbound 1.3.4:

  1. Set up Unbound with the IANA DNSSEC testbed root and approriate
     trust anchors.

  2. Check that the AD bit is set for some secure RRsets (to verify
     that step 1 has been implemented correctly).

  3. Modify the system such that queries for all name servers of a
     certain domain (let's say "example.com") are answered by a name
     server which has got an A wildcard at the root, does not
     implement DNSSEC, and returns NOERROR for all the DNSSEC RR
     types.  (Except for the IPv6 servers, which are not reachable
     anyway despite IPv6 support being enabled in Unbound because the
     kernel does not support IPv6.  Disabling IPv6 altogether does not
     seem to make a difference.)

  4. Send a query for www.example.com to the Unbound resolver.  As
     expected, it results in a validation failure and a SERVFAIL

  5. Send another query for www.example.com.  It results an immediate
     SERVFAIL response from Unbound.  Also expected.

  5. Wait (longer than the configured val-bogus-ttl value).

  6. Send a query for www.example.com.  Again, an immediate SERVFAIL
     response is sent by Unbound (and nothing is logged).

The result of step 6 is not what I would expect.  I think there should
be a fresh upstream transaction.  If I lift the redirection
established in step 3, queries for non-cached names are stilled
answered with SERVFAIL responses, after an upstream transaction.

Looking at the log for the cache-miss case, it seems that Unbound
still caches the NODATA DNSKEY response for example.com:

[1256554227] unbound[28667:0] info: Missing DNSKEY RRset in response to DNSKEY query.

Could Unbound lower the TTL on the DNSKEY RRset in such cases?

Florian Weimer                <fweimer at bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

More information about the Unbound-users mailing list