<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Tony,<div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class=""><div class="">It's problematic that Consul's defaults guide its users to make this<br class="">mistake. I think it should configure its domain option based on the<br class="">Consul server's FQDN, rather than using an unwise fixed value.<br class=""></div></div></blockquote><div><br class=""></div><div>Consul does have configuration directives to change its domain. By default it’s anything under <i class="">consul., </i>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 <i class="">X</i> 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:</div><div><br class=""></div><div><b class="">active.X.service.consul</b></div><div><br class=""></div><div>which would return the IP of the currently active member of service X. This is incredibly convenient for applications.</div><div><br class=""></div><div>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.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class="">That's how the recursive -> authoritative part of the DNS protocol works,<br class="">but not the stub -> recursive part. Stub resolvers need to get a complete<br class="">answer, they aren't clever enough to follow referrals. But what you might<br class="">be able to do is get your client machines to talk direct to Unbound only,<br class="">and configure Unbound to forward internal queries to Consul and other<br class="">queries to BIND. (I didn't suggest this before because I thought you said<br class="">they have to use BIND as their recursive server, but I might have<br class="">misunderstood how strong this requirement is.)<br class=""></div></div></blockquote><div><br class=""></div><div>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.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">No problem, this is a legitimately murky corner, so the questions aren't<br class="">silly. Fake internal domains, on the other hand ... :-)<br class=""></div></div></blockquote><div><br class=""></div><div><br class=""></div><div>Cool :)</div><div><br class=""></div><div>Thanks again,</div><div> Sergei</div></div></div></body></html>