Sergei Gerasenko via Unbound-users <[email protected]> wrote: > > I’m kind of stuck with this problem. Hashicorp's consul doesn’t support > DNSSEC and as such, I can’t forward from my main bind instance (DNSSEC > enabled) to the consul daemon directly. I can’t turn off DNSSEC in the > bind instance either.
My guess is that Consul is using a domain which is not properly delegated, so BIND's validation fails when it tries to follow the delegation. I'm afraid your plan isn't going to work, for three reasons: * Unbound also validates so I would expect it to have the same problem. * DNSSEC is end-to-end not hop-by-hop, so you'll get the same validation failure wherever the data comes from. * DNSSEC is designed to be backwards-compatible, so (if there is a proper delegation) BIND should be able to resolve insecure domains hosted on Consul. If my guess is right, there are two ways to fix the problem: (1) Add a proper delegation to the domain hosted by Consul. If someone made a bad choice about which domain to use (i.e. not one that is properly registered) this might not be possible. (2) Add a negative trust anchor for the domain, to disable DNSSEC validation just for that domain, using `rndc nta`. This might be a bit annoying because (as RFC 7646 requires) negative trust anchors have a limited lifetime. Unbound's `domain-insecure` option is more permanent, but it probably won't help unless you can replace BIND with Unbound. BIND 9.14 will have a `validate-except` option which works a similar way. Tony. -- f.anthony.n.finch <[email protected]> http://dotat.at/ disperse power, foster diversity, and nurture creativity
