Hashicorp consul dns API and DNSSEC (newb)

[Sergei Gerasenko]

Hi Peter,

> 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 <http://consul.internal.example.com/>.` where `internal.example.com <http://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 <http://consul.internal.example.com/>.` and allow you to do whatever
> thick Consult is doing.
> 
> I hope it clarifies the problem.

Very cool! It does seem to working when I’ve changed the consul domain name to consul.ourdomain.net <http://consul.ourdomain.net/>! I don’t quite understand the logic of this behavior, but I’m glad we have a simple solution for this. This is working even without an intermediate bind server. Forwarding straight from our main dns servers is working. So thank you VERY much, Peter, for this valuable insight.

>> 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.

Got it, but it’s not going to be necessary anymore.

Thank you!!
  Sergei
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20181025/fae0bfe1/attachment.htm>