Query forwarding & DNSSEC
he at uninett.no
Mon Sep 23 12:59:37 UTC 2019
we're trying to configure unbound to
1) get access to a "local view" of the DNS, accessible via a
couple of local recursors
2) get DNSSEC validation working, since the local recursors are
not configured to do validation
via a configuration similar to this:
We've tried both unbound 1.6.0 (Debian...) and 1.9.3.
For some "external" DNSSEC-secured domain under .no, this works,
and the 'ad' flag lights up as it should in the response. Also,
for known-insecure external zones under .no this seems to work as
intended (I get the expected response).
However, for whatever reason, lookups in what can be called the
"local domain" fails with SERVFAIL. Cranking up the logging of
unbound, I find in the log
info: Could not establish a chain of trust to keys for example.no. DNSKEY IN
(actual name withheld). I've run "dig" towards both of the
forward-addr listed name servers, and they both return a "nodata"
response when queried for the DNSKEY or the DS record for the
"example.no" domain (as they should). So why does unbound think
it has a DNSKEY to validate against?!?
If I add
to the configuration (it's not really desireable to have to set
up and maintain this list) I can do lookups of NS, SOA etc., and
get data from the "local view". I can even get a nodata response
to a DNSKEY query for "example.no", but looking up the DS record
for the domain even after this marking still fails with SERVFAIL,
and the above message can once again be found in the log from
A side note: I did notice that unbound still wants to do RFC 8145
signaling, so sends "_ta-4f66. NULL IN" queries to the
forward-addr name servers, and they both respond with SERVFAIL...
Does anyone have a good explanation to why with the first config,
unbound seems to think it has a DNSKEY for "example.no" to do
validation against? And in the second, with an empty DNSKEY
response, why does the DS record lookup still return SERVFAIL?
More information about the Unbound-users