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..
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.
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.
Thanks for replying. Yes, we today have done some in-house stress
tests and realised what is the right answer for this deployment. It is
good to have confirmation that we understand the problem.
I think you want to be independent on parent domain. That should be possibly by configuring your own trust anchor for namn.se KSK key.
Then it should be possible to query your DS or DNSKEY, choose only KSK key and add it as trust anchor to your validating clients. Unbound should validate only up to first trusted anchor. If that is your domain, it should not need to validate any parent records.
Fetch the DS record:
dig +short ds example.org
Then add it to trust-anchor-file: or trust-anchor: unbound.conf options.
You can test your zone signing before adding DS record to public .se zone this way.
I think you want to be independent on parent domain. That should be possibly
by configuring your own trust anchor for namn.se KSK key.
Then it should be possible to query your DS or DNSKEY, choose only KSK key
and add it as trust anchor to your validating clients. Unbound should
validate only up to first trusted anchor. If that is your domain, it should
not need to validate any parent records.
Yes, that makes sense for when the child is signed.