Hashicorp consul dns API and DNSSEC (newb)

[Petr Špaček]

On 24. 10. 18 15:48, Sergei Gerasenko via Unbound-users wrote:
> Hi Tony,
> 
>> It's problematic that Consul's defaults guide its users to make this
>> mistake. I think it should configure its domain option based on the
>> Consul server's FQDN, rather than using an unwise fixed value.
> 
> Consul does have configuration directives to change its domain. By
> default it’s anything under /consul., /but I can make it anything I
> want. I’m not quite sure how this would help though. To be sure we’re on
> the same page, a few words of what Consul does in general and its DNS
> API in particular. Let’s say there’s some service /X/ that is provided
> by a number of machines. Let’s say also that this service is an
> Active-Standby service where exactly 1 member serves a function. Let’s
> designate that member the “active” member. What consul allows you to do
> is have all these members register with Consul and let Consul choose the
> active member by issuing a pre-defined health check. It does much more
> (like store the service’s data in a distributed way), but this will
> suffice for our discussion. As part of its DNS API, Consul allows
> queries like this:
> 
> *active.X.service.consul*

The problem is caused by fact that DNS root zone (.) is DNSSEC-signed so
DNSSEC validator in BIND (or anywhere else) can prove that domain
`consul.` is not supposed to exist. This proof contradicts data received
from network and this contradiction is treated as an attack (which is
technically correct and expected).

Recommended configuration is to use domain name like
`consul.internal.example.com.` where `internal.example.com.` is an
existing but insecure zone (i.e. a zone which is not signed using DNSSEC).

Using insecure parent zone will automatically disable DNSSEC validation
on subtree `consul.internal.example.com.` and allow you to do whatever
thick Consult is doing.

I hope it clarifies the problem.


> which would return the IP of the currently active member of service X.
> This is incredibly convenient for applications.
> 
> Given the dynamic nature of the operation, is DNSSEC even possible in
> this case no matter what the prefix would be? I thought that with
> DNSSEC, a zone needs to be resigned each time a change happens? If
> that’s true, I’m not sure how this would work because the “active”
> portion of that name can change 10 time a day.

This is not a problem, reasonably modern DNS server can handle thousands
of updates per second including automatic DNSSEC resigning.

Petr Špaček  @  CZ.NIC


> 
>> That's how the recursive -> authoritative part of the DNS protocol works,
>> but not the stub -> recursive part. Stub resolvers need to get a complete
>> answer, they aren't clever enough to follow referrals. But what you might
>> be able to do is get your client machines to talk direct to Unbound only,
>> and configure Unbound to forward internal queries to Consul and other
>> queries to BIND. (I didn't suggest this before because I thought you said
>> they have to use BIND as their recursive server, but I might have
>> misunderstood how strong this requirement is.)
> 
> That could be a decent workaround with the only concern being the
> possible additional load on these Consul machines. Ideally, they should
> do only Consul stuff, but maybe this will not add too much.
> 
>> No problem, this is a legitimately murky corner, so the questions aren't
>> silly. Fake internal domains, on the other hand ... :-)
> 
> 
> Cool :)
> 
> Thanks again,
>   Sergei