Hi Måns,

Unbound needs to build a chain of trust to prove the existence or not of DNSSEC data. If access to the .se key is not possible (or the key is bogus, as an alternative) then the chain is not complete.

Is your domain signed? Then using either of the:
- trust-anchor-file [1], or
- trust-anchor [2]
options would start the chain of trust at your domain, no need for root or .se .

Is your domain not singed? Then using domain-insecure [3] would treat that domain as insecure, no need for a chain of trust to prove that.

Best regards,
-- Yorgos

[1] https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.conf.html#unbound-conf-trust-anchor-file [2] https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.conf.html#unbound-conf-trust-anchor [3] https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.conf.html#unbound-conf-domain-insecure

On 08/01/2026 14:56, Måns Nilsson via Unbound-users wrote:
Greetings,

Is it a recommended solution to have a local domain marked insecure
given the following setup?

server:
        # se is signed, as we know
        module-config: "validator iterator"
        # namn.se is our local domain name.
        private-domain: namn.se
        unblock-lan-zones: yes
         insecure-lan-zones: yes
stub-zone:
        name:   namn.se
        # internal name servers
        stub-addr:      192.0.2.53
        stub-addr:      192.0.2.54
forward-zone:
        name: "."
        # these are also unbound, and they validate
        forward-addr:   192.0.2.47
        forward-addr:   192.0.2.11

The question is that _if_ the forward-addrs are unreachable
or unresponsive, a stiuation we've had,  we have noticed
validation failures dependent on SE. for names in namn.SE.
Names which should have been completely found using the stub-
zone: directive. The log message is:

info: validation failure <some-host.namn.SE. A IN>: key for \
        validation se. is marked as invalid because of a previous

This message is originated on line 1964 in validator/validator.c
in "processInit()" and the comment is "key is bad, chain is bad,
reply is bogus" which sort of fits.

As is usual, I probably have talked myself into believing I've
found the issue but I hope someone is able to refute or affirm
my beliefs..

/Måns

Reply via email to