Hashicorp consul dns API and DNSSEC (newb)
gerases at gmail.com
Wed Oct 24 11:58:23 UTC 2018
Thank you for the very detailed reply.
Just to be clear, we’re dealing with internal DNS here. No registrars are involved. I don’t know much about registrars/delegations but I think it applies mostly to public domains? Anyway, yes, I’ve looked at NTA and it starts being supported with bind 9.11 — we’re below that. So that’s out. I *was* using the “domain-insecure” option of Unbound hoping that it would help with the Bind -> Unbound -> Consul scenario but since as you’re saying it’s hop-to-hop, that’s not going to be possible.
Idea, can Unbound not “vouch” for (trust) this zone DNSSEC-wise and reply to other DNS servers with correctly signed responses?
One thing that does work is going straight to Unbound, but the question is how to make our internal DNS aware of that and “redirect” the client to it (without listing the Unbound server in /etc/resolv.conf). So is it possible in the DNS world to reply to the client with a “referral” instead of doing anything recursive for it? As in "if you’re looking for “something.consul.", go to this DNS server. I won’t do the recursion for you.”?
Sorry for the silly DNS questions!
Thanks a bunch,
> On Oct 24, 2018, at 5:25 AM, Tony Finch <dot at dotat.at> wrote:
> Sergei Gerasenko via Unbound-users <unbound-users at nlnetlabs.nl> 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
> 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.
> f.anthony.n.finch <dot at dotat.at> http://dotat.at/
> disperse power, foster diversity, and nurture creativity
More information about the Unbound-users