Hashicorp consul dns API and DNSSEC (newb)

[Sergei Gerasenko]

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

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.

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20181024/96b3c51e/attachment.htm>