interaction of validation and local stubs and forwarders

[Yorgos Thessalonikefs]

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