Consul: DNSSEC support

Created on 23 Oct 2014 · 12Comments · Source: hashicorp/consul

It would be good to support DNSSEC for internal DNS, especially with custom domain support.

themoperator-usability typenhancement

Source

armon

👍15

Most helpful comment

This would be especially useful if machines can reliably publish their SSH server fingerprints, which clients can trust explicitly if signed by DNSSec.

davidstrauss on 24 Mar 2015

👍6

All 12 comments

This would be especially useful if machines can reliably publish their SSH server fingerprints, which clients can trust explicitly if signed by DNSSec.

davidstrauss on 24 Mar 2015

👍6

@armon Has there been any progress on this?

maticmeznar on 3 Feb 2016

Hi @maticmeznar unfortunately we haven't been able to work this into an upcoming release yet. We will update this once we get some time to work on it.

slackpad on 13 Feb 2016

What's a size/ difficulty estimate for this? Where should someone start working on a PR?

pnovotnak on 4 Jan 2018

Seems like a possible working solution, however it has not been tested. https://github.com/hashicorp/consul/blob/master/vendor/github.com/miekg/dns/README.md

I think it might be usable in an unstable way. it seems pretty cool though.

th31nitiate on 8 Jan 2018

+1 for official release and support of DNSSEC for Consul please

8uachaille on 21 Feb 2018

Still on the oven? Would be great to see these feature

joaquin386 on 11 Apr 2018

+1 for official release and support of DNSSEC for Consul please

ruben-herold on 9 Oct 2018

hmm 2014, clearly this has been underestimated how difficult it is to implement correctly. Can we have a status report so others can maybe help?

gertcuykens on 16 Dec 2018

It seems like DNS over HTTPS (DoH) is maybe the way of the future instead. Would that be preferred to DNSSEC?

jboero on 10 Sep 2019

DNS over HTTPS or even DNS over plain TLS do not replace the need for DNSSEC. With DNSSEC the owner of a domain can digitially sign the DNS records for that domain. Then those digitally signed records can be transmitted via normal UDP/TCP DNS and the resolver can verify the authenticity of the data.

Encrypting the DNS protocol itself (via HTTPS or plain TLS) provides privacy between the resolver and the server. Basically it prevents and intermediate IP router from being able to discover which domains you are querying for. You still cannot blindly trust that the entity on the other end of that TLS connection hasn't altered the data in some way but must instead still rely on DNSSEC to provide the data authenticity.