Query forwarding & DNSSEC

[Havard Eidnes]

Hi,

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:

----------
server:
    auto-trust-anchor-file: "/etc/unbound/root.key"
    prefetch: yes
    prefetch-key: yes
    unblock-lan-zones: yes
    insecure-lan-zones: yes

forward-zone:
    name: "."
    forward-addr: a.b.c.d
    forward-addr: a.b.f.g
----------

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

  domain-insecure: example.no

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
unbound.

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?

Confused,

- Håvard